[01:14] <simoniz0r> :)
[06:09] <seb128> good morning desktopers
[06:56] <jibel> koza, hi, I followed your advice and removed bluez (which also remove its dependencies gnome-bluetooth and pulseaudio-module-bluez)
[06:57] <jibel> koza, but bluetoothd from the snap still doesn't start automatically
[06:57] <jibel> and then I cannot enable bluetooth at all from control center
[06:58] <jibel> g-c-c reports BT is 'On' but it is not
[07:06] <jibel> koza, and on artful the daemon fails to start with: D-Bus setup failed: Connection ":1.117" is not allowed to own the service "org.bluez" due to security policies in the configuration file
[08:26] <koza> jibel, im here now. sorryfor delays still in Taipei and simetimes i miss pings here
[08:27] <koza> jibel, which release process you have on your mind?
[08:45] <jibel> koza, the release of the bluez snap. when is it published to the different channels and the promotion criteria?
[08:45] <jibel> koza, i'm documenting the qa process
[08:46] <jibel> if there is nothing documented it's fine too, i'll propose something
[08:49] <koza> jibel, no, everything is documented?
[08:50] <koza> jibel, ce has all the processes done the *right* way and nothing slips to channels
[08:50] <koza> jibel, what is the purpose of your documentation, who will use the new process?
[08:51] <jibel> koza, the purpose is to describe how to test this snap on desktop.
[08:51] <koza> jibel, so more likely a test plan
[08:51] <jibel> and apart from the test plan is the spreadsheet i've nothing
[08:52] <jibel> koza, a test plan, but also how to install and run it on desktop
[08:52] <koza> the spreadshet is the most important part :-) it is being converted to checkbox btw
[08:52] <koza> jibel, ah ok got it. instructions you mean. for me process is a workflow since the build to release so I got confused
[08:53] <jibel> koza, it's important but making sure every tester is testing the same way on the same environment is also important
[08:53] <koza> jibel, running on desktop is quite not defined atm as we have not targeted desktop so far focusing on core
[08:54] <jibel> then when it should be tested by the desktop team, in which channel, which tests are done upstream, any automation, ... so there is no duplicated effort and a good coverage
[08:54] <jibel> koza, okay, lets discuss this during the bluez meeting with duflu when he is back
[08:54] <koza> jibel, correct and this is what im trying to achieve and convince to since like months. we have discussed it with willcooke number of times during bt sync meeting. nice that finally somethings is shaping out of this.
[08:55] <jibel> koza, i'll write a draft to use as a base for the discussion
[08:55] <koza> jibel, sure, or anytime you want we can jump on HO. for me it is important that we as a devs maintaining bluez follow the repetetive testing that we can benefit in a future by building up a database of past results. hence the test plan.
[08:56] <koza> jibel, sure, share with me once you have it, ill be more than happy to review and contribute to.
[08:56] <jibel> thanks
[08:56] <koza> willcooke hey and nice timing, i just have mentioned you :-)
[08:56] <willcooke> morning
[08:58] <willcooke> what did I miss?
[08:58] <koza> willcooke, a discussion about testing bluez on desktop. i referred to a number of our discussions about the process, test plans and such
[08:58] <willcooke> super
[09:02] <jibel> trying to understand where CE and desktop meet during the release of the bluez snap
[09:03] <Laney> hai
[09:05] <koza> jibel, we do meet. all of the snaps are tested by the developer, cert, testflinger and commercial qa.
[09:05] <koza> jibel, moreover for bluez releases i require test plan to be executed
[09:06] <koza> jibel, we do have a snap update verification board that is semi-automated (much like ci-train & britney) for tracking purposes.
[09:06] <koza> jibel, different qa teams are performing handovers to next in line qa teams as the snap travels from channel to channel
[09:07] <koza> jibel, responsibilities are defined and shared
[09:07] <jibel> koza, I know but at some point it lands on the desktop, and I cannot find any info about what is currently done on this platform
[09:07] <koza> jibel, what i see that at least for bluez and rest of the snaps maintained by ce you are part of this. as for the apps and other I have no idea.
[09:09] <koza> jibel, on desktop none as it did not landed there so far. for bluez you have the user tests set which is about using bluez through Unity (update to gnome on its way) UI plus Keyboards & Headsets which are tested also through the UI (not bluetoothctl) to check the integration.
[09:11] <seb128> hey Laney willcooke
[09:12] <seb128> (back online from the coffee place)
[09:12] <willcooke> morning seb128
[09:12] <koza> o/
[09:12] <seb128> willcooke, how are you today? having your office back in a work-suitable place?
[09:12] <seb128> hey koza
[09:13] <willcooke> seb128, yeah nice and quiet again here today, and the teeth aren't as painful (yet)
[09:14] <willcooke> on the plus side, my new office now has a floor, some electrical sockets and some network points
[09:14] <willcooke> and a window :)
[09:15] <seb128> nice
[09:16] <koza> willcooke, where have you been that you see windows and floors as a major improvements?
[09:16] <willcooke> koza, on a building site :D
[09:18] <koza> willcooke, sounds like fun
[09:18] <willcooke> it is, some days
[09:26] <Laney> seb128: sorry, missed your hey
[09:26] <Laney> hi!
[09:26] <Laney> how's it going?
[09:26]  * Laney nods willcooke koza too
[09:27] <seb128> good! could have slept longer though
[09:27] <seb128> and you, how are you?
[09:31] <Laney> mmmmmmmmmmmmmmmmmmmmmmm not bad
[09:31] <Laney> washing machine is broken though so having to go to the launderette
[09:31] <Laney> irritating
[09:31] <Laney> first world problem tho
[09:32] <seb128> hehe
[09:38] <willcooke> ha, an AO van just pulled up to deliver a new washing machine to my neighbour
[09:38] <willcooke> Looks like they're getting a Bosch one.  Good choice.
[09:38] <willcooke> #washingmachinenews
[09:38] <Laney> Sam Sung is coming at the weekend to look
[09:39] <Laney> we're getting error code 4E #washingmachinenews
[09:39] <willcooke> ohh
[09:39] <willcooke> now, that is interesting
[09:39] <willcooke> we had a Samsung, with I /think/ the same error.  They came out about 4 times before we gave up.
[09:39] <willcooke> and bought a new one
[09:39] <Laney> oh god
[09:39] <willcooke> It would just stop half way through a wash
[09:40] <Laney> it does like 5 minutes and gives up with that
[09:40] <willcooke> and wouldnt spin or turn the drum properlyt
[09:40] <willcooke> does it keep rocking the drum back and forth
[09:40] <willcooke> ?
[09:40] <willcooke> just a little bit
[09:40] <Laney> yeah chugs about a bit
[09:40] <willcooke> ha
[09:40] <willcooke> same
[09:40] <Laney> i think it decides that it's not getting water in
[09:40] <Laney> clearly is though
[09:40] <willcooke> Not buying a Samsung again
[09:40] <Laney> :(
[09:40] <Laney> was a which best buy!
[09:41] <willcooke> I dont trust Which anymore
[09:41] <willcooke> for the same reason
[09:41] <willcooke> I dont think they can do more than a couple of days of testing
[09:43] <Laney> just found the invoice
[09:43] <Laney> this thing was £599
[09:43] <Laney> that means I'm going to try to make them fix it :P
[09:45] <willcooke> oof, yeah
[09:46] <Laney> not in warranty tho
[09:52] <willcooke> :(
[09:52] <willcooke> Is there some sticker on the front about a 10 year warranty on the motor?
[09:59] <Laney> yeah
[10:00] <Laney> I was suspicious of that at the start
[10:00] <Laney> when I bought it
[10:00] <Laney> like that's the part that will probably never break
[10:00] <Laney> the fridge has one of those too about the compressor
[10:00] <willcooke> indeed
[10:01] <doko> willcooke, jbicha: updated https://bugs.launchpad.net/ubuntu/+source/ibus-libpinyin/+bug/1735362  looks like the way forward is ibus-libpinyin ... that would require a MIR, and subscribing to the package, before ibus-sunpinyin can be demoted (and one less gtk2/glade2 package in main ...)
[10:01] <koza> willcooke, jibel, seb, bt weekly?
[10:01] <koza> seb128 ^^
[10:02] <willcooke> humm,
[10:02] <willcooke> why is is marked as not coming in my calendar
[10:02] <willcooke> one sec
[10:02] <Laney> back in a min
[10:04] <seb128> koza, sorry, since duflu is  away and you are travelling I assumed we were not doing it, I'm currently in a noisy place without headphones
[10:04] <koza> seb128 ok no worries
[10:05] <seb128> koza, if you have any question I'm happy to reply on IRC
[10:07] <koza> seb128 no questions
[10:10] <seb128> k
[10:26] <joumetal> is there good chance to get bug #1168978 fixed in bionic release?
[10:28] <joumetal> bug is fixed upstream by small patch
[11:07] <seb128> Laney, thanks for adding the details to the shell theming trello card!
[11:08] <Laney> yw, thanks for pinging me
[11:14] <Laney> haha
[11:15] <Laney> the hub told me off for writing a crappy post
[11:15] <Laney> it was "yeeeeeeeeeeeahhhhhhhh"
[11:20] <seb128> lol
[11:21] <Laney> is it possible to get moderator privileges?
[11:22]  * Laney would like to close the guest session thread
[11:22] <Laney> at some point those "give me feedback on XYZ" threads stop being useful
[11:23] <willcooke> popey, ^ can we get some extra privs, or can you help Laney with closing the thread?
[11:32] <seb128> is that the sort of things we usually do to stop a discussion? does it create any noise issue for others who don't follow that topic?
[11:32] <seb128> (I'm fine with closing it, just wondering if we have "moderation guidelines" or such)
[11:32] <Laney> maybe that'd be useful
[11:34] <Laney> in this case I think it's just people basically +1ing and it makes at least me click on it when it's bumped
[11:34] <Laney> I think you could say thanks, this thread has been useful, the work is scheduled at this link, going to close it now
[11:37] <popey> Closing a thread is fine if it's wandering around or not productive
[11:37] <popey> Happy to have desktop team people moderate that category
[11:41] <seb128> good
[11:42] <popey> Can it wait until I am back at my desk later this evening? Am at a conference today
[11:43] <Laney> yeah no big deal
[11:43] <Laney> it's not that important anyhow
[11:43] <Laney> thanks!
[12:23] <joumetal> help /channel
[14:05] <jbicha> doko: GunnarHJ has been helping us with language related pacakges, maybe ask him what he thinks about switching those pinyin packages
[14:14] <doko> jbicha: I don't know who that is, just got feedback from Debian. Maybe subscribe him to the bug report?
[14:15] <jbicha> https://launchpad.net/~gunnarhj
[14:15] <seb128> what's the topic?
[14:15] <jbicha> LP: #1735362
[14:17] <jbicha> doko: I'd prefer if you asked Gunnar (instead of me asking him) since I'm not particularly interested in switching around our IM packages
[14:22] <seb128> jbicha, doko, i Cced Gunnar & asked on the bug, let's see
[14:27] <doko> ta
[14:33] <seb128> doko, jbicha, in fact that was already discussed a bit on https://lists.ubuntu.com/archives/ubuntu-desktop/2017-October/005269.html
[14:34] <seb128> we should probably switch, I'm going to look a bit more at the differences first though
[14:34] <jbicha> thanks, that shows how I wasn't paying careful attention to those pkgs :|
[14:35] <seb128> :)
[14:58] <doko> seb128: what was your solution regarding bittornado?
[14:59] <seb128> doko, what i wrote in the bug
[14:59] <seb128> remove it from the seed & demote
[14:59] <seb128> it seems so ancient decision of having a command line torrent client, I don't think that makes much sense on a desktop
[15:00] <seb128> could be more for server maybe
[15:00] <doko> hmm, I only got the message about the owner ...
[15:00] <seb128> doko, https://bugs.launchpad.net/ubuntu/+source/bittornado/+bug/1735346/comments/3
[15:03] <seb128> doko, re libglade2, the -dev depends on python, do you know why that binary is in main? http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/rdepends/libglade2/libglade2-dev is empty
[15:06] <doko> looking ...
[15:06] <Trevinho> good morning guys
[15:07] <doko> seb128: as a wrote ... ibus-sunpinyin ...
[15:08] <doko> hmm, that's python-glade2
[15:08] <seb128> doko, https://bugs.launchpad.net/ubuntu/+source/libglade2/+bug/1735369
[15:08] <seb128> I meant
[15:11] <doko> seb128: try adding it to extra-excludes in some seed?
[15:11] <seb128> what does that do and why is it needed?
[15:11] <seb128> can we just demote it and see if something tries to bring it back to main?
[15:12] <doko> sure, we could do that
[15:12] <seb128> I would start by trying that
[15:14] <jbicha> seb128: are you asking just about the -dev package, or are you asking about python-glade2 or what?
[15:15] <seb128> jbicha, I'm trying to understand the bug I just mentioned, it looks like what depends on "python" is libglade2-dev?
[15:15] <doko> that was just about the -dev package. But I assume that requires extra-excludes for other -dev packages of the gtk2 stack as well
[15:16] <seb128> i guess I don't understand what extra-excludes is/does
[15:16] <seb128> or why it is needed
[15:16] <jbicha> seb128: python-glade2 is kept in main because of LP: #1735872 and ibus-sunpinyin
[15:16] <doko>  * Extra-Include: *-dbg *-debug *-dev *-doc *-docs gir1.2-* *-examples
[15:16] <doko> this is the dangerous thing ...
[15:17] <seb128> jbicha, but that's not a binary from libglade2 source?
[15:17] <seb128> jbicha, or do I read https://launchpad.net/ubuntu/+source/libglade2/1:2.6.4-2 wrongly?
[15:17] <jbicha> python-glade2 then depends on libglade2-0
[15:17] <seb128> yes
[15:17] <seb128> that's fine
[15:18] <seb128> -dev is the one which depends on python
[15:18] <seb128> libglade2-0 doesn't depends on python right?
[15:18] <jbicha> I mean we could drop libglade2-dev from main but there's no point yet since s-c-kickstart depends on python-glade2 which depends on python and libglade2-0
[15:19] <doko> it would be nice if somebody could disable the flaky gvfs autopkg tests ...
[15:19] <jbicha> doko: file a  Debian bug since the gvfs pkg is in sync-ish with Debian
[15:20] <seb128> jbicha, well, one less is better than one more? ;-)
[15:20] <seb128> jbicha, also i don't understand why libglade2-dev has to be in main
[15:20] <doko> jbicha, maybe better done by some friendly people, rather than by me?
[15:21] <doko> as I tried to explain, it's pulled in by the Extra-Include
[15:21] <jbicha> what, you're not friendly enough? 😁
[15:22] <doko> I have some history with Debian gnome =)
[15:23] <jbicha> I'm uncomfortable messing with the glaky gvfs autopkgtests
[15:23] <jbicha> ggg
[15:23] <seb128> doko, ah ok, i saw that you copied that line but didn't understood it was to explain why it's in main, thanks
[15:24] <jbicha> this is generally the list of stuff keeping gtk2 in main https://bugs.launchpad.net/ubuntu/+bugs?field.tag=gtk2-demotion
[15:24] <jbicha> there's a couple more in progress like Firefox, avahi and colord but the missing ones from that list are fairly easy
[15:26] <doko> I'm afraid, openjdk isn't changing soonish
[15:26] <jbicha> seb128: we can override the Extra-Include rule like I did in http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.bionic/view/head:/supported#L344
[15:27] <seb128> jbicha, right, thanks
[15:28] <seb128> jbicha, debconf isn't likely to be ported this cycle is it?
[15:28] <seb128> said differently that's a nice goal but not likely
[15:28] <jbicha> seb128: ask cjwatson about it, I think it's probably not too difficult-ish for a perl person
[15:28] <seb128> I asked previous cycle
[15:29] <seb128> my feeling was that it was on his list but low priority enough that it wouldn't happen
[15:29] <seb128> so I don't count on it to be done this cycle
[15:30] <jbicha> I'm guessing it's a bit more interesting if it's literally the only thing keeping gtk2 in the default install for an LTS
[15:31] <seb128> right, but even if it is I don't think it's going to autocreate resources
[15:31] <seb128> and it's not in any case
[15:31] <jbicha> Firefox and Thunderbird are getting the gtk2 shlibdeps hack so debconf is the only thing
[15:35] <jbicha> ricotz: I opened https://bugzilla.mozilla.org/1423363 otherwise we can apply the same hack from Firefox to Thunderbird Beta too
[15:36] <jbicha> seb128: :)
[15:38] <seb128> jbicha, good surprises coming :)
[15:38] <jbicha> so basically, we're likely to have the default install not include gtk2 but the live ISO will still need it for some input methods (and gparted ?)
[15:40] <doko> |   +- libgtk2.0-dev
[15:40] <doko>  |   |  * Reverse Depends:
[15:40] <doko>  |   |   +- libavahi-ui-dev
[15:40] <doko>  |   |   +- libdbusmenu-glib-dev
[15:40] <doko>  |   |   |  * Reverse Depends:
[15:40] <doko>  |   |   |   +- libappindicator3-dev
[15:40] <doko>  |   |   |   +- libdbusmenu-gtk3-dev
[15:40] <doko>  |   |   |   +- libdbusmenu-jsonloader-dev
[15:40] <doko>  |   |   |   +- libunity-dev
[15:40] <doko>  |   |   +- libgail-dev
[15:40] <seb128> spam!
[15:40] <doko>  |   |   +- libglade2-dev
[15:40] <doko>  |   |   |  ! skipped
[15:40] <doko>  |   |   +- libgpod-dev
[15:40] <doko>  |   |   +- libgtkmm-2.4-dev
[15:40] <doko>  |   |   +- libgtkspell-dev
[15:40] <doko>  |   |   +- libindicator-dev
[15:40] <doko>  |   |   |  * Reverse Depends:
[15:40] <doko>  |   |   |   +- libindicator3-dev
[15:40] <doko> so it looks like you want to add all these to extra-excludes ...
[15:40] <doko> if they are gtk2 only
[15:41] <jbicha> doko: where did you get that list from?
[15:42] <doko> from the germinate output
[15:42] <Laney> https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.bionic/rdepends/gtk+2.0/libgtk2.0-dev
[15:42] <jbicha> gail is the same source pkg as gtk2
[15:42] <doko> right, the extra-excludes only help for some binary packages
[15:43] <jbicha> avahi just needs the Debian version merged, but see LP: #1735960
[15:43] <jbicha> gpod and gtkspell and indicator aren't in main any more
[15:44] <doko> $ apt-cache show libgtkspell-dev|grep ^File
[15:44] <doko> Filename: pool/main/g/gtkspell/libgtkspell-dev_2.0.16-1.1ubuntu1_amd64.deb
[15:44] <jbicha> I was kind of hoping sunweaver would take over libdbusmenu maintainership (details need to be worked out), but if we want things faster, there's a trivial packaging change I can apply to it
[15:46] <jbicha> doko: I believe you demoted gtkspell today https://people.canonical.com/~ubuntu-archive/madison.cgi?package=gtkspell&S=on
[15:47] <doko> ahh, ok, re-running my local germinate
[15:47] <jbicha> gtkmm2.4 is because of gparted
[17:03] <jbicha> seb128: see GNOME bug 791035
[18:06] <doko> jbicha: demoted libglade2-dev python-gtk2-dbg python-gtk2-dev python-gtk2-doc
[18:06] <doko> looks like you could try to demote other gtk2 -dev/-dbg packages too by adding extra-excludes
[18:10] <jbicha> I don't think it helps much to drop the -dev from main if we don't drop the library too…
[18:11] <jbicha> doko: but what do you think about LP: #1736620 where the -dev does actually end up pulling in gtk2 but the primary library does not depend on gtk2
[18:11] <doko> any recommends?
[18:11] <doko> any -dbg or -doc packages?
[18:12] <jbicha> the only thing that depends on libgvc6-plugins-gtk is libgraphviz-dev so I suggest #2 but I don't know much about graphviz
[18:13] <jbicha> or #3 if you think doing the Excludes thing is reasonable
[18:14] <mdeslaur> seb128: fyi, I added a list of problematic packages in bug 1735929
[18:14] <mdeslaur> seb128: just changing them to 700 seemed to work, but I'd appreciate being looked at by the desktop team in case those are used in some other way
[18:15] <doko> I'm a bit hesitant excluding -dev packages which are not just gtk2 related
[18:20] <jbicha> doko: oh I see, libgraphviz-dev has rdepends in main
[18:24] <seb128>  mdeslaur, ok, thanks, now is dinner time but I've a look later
[18:24] <mdeslaur> no rush
[18:24] <mdeslaur> thanks seb128
[19:37] <willcooke> night all
[22:25] <seb128> jbicha, that fix from L_aney makes sense to me
[22:34] <jbicha> ok
[22:35] <jbicha> seb128: for libdbusmenu, I thought we didn't really care about reviewing minor Unity-related uploads
[22:35] <seb128> in practice we don't care a lot
[22:35] <seb128> but it's still good practice to wait a bit in case somebody wants to give you a review
[22:35] <seb128> you can move ahead the next day or such if that's not the case
[22:36] <jbicha> ok
[22:38] <seb128> on that note calling it a day, good night everyone


[00:12] <alexabreu> fginther, thx !
[02:59] <fginther> robru, there is no documentation for those license checkers other then the code itself - http://bazaar.launchpad.net/~jenkaas-hackers/pbuilderjenkins/trunk/files/head:/hooks/
[03:13] <robru> fginther: ok, thanks
[04:49] <robru> Mein gott
[13:16] <alexabreu> fginther, so did you disabled the license checkers for the issue above, or disabled some of them?


[00:01] <Sarvatt__> hrm I'm not sure when it should go in, looks like main is frozen before beta freeze is lifted?
[00:55] <Sarvatt__> RAOF: err, compiz memory leak happening with the nvidia blob too not just intel
[00:55] <bjsnider> you got that right
[00:55] <bjsnider> have to restart compiz every few hours
[00:55] <RAOF> On alt-tab?
[00:56] <Sarvatt__> sarvatt   1911  0.5  0.7<PHONE_NUMBER>0 ?        Sl   Apr06  37:33 compiz is with the blob here, I never alt+tab
[00:57] <bjsnider> neither do i
[00:57] <Sarvatt__> was surprised the blob was doing it too though, rules out some of the places I was looking.. gonna need a valgrind
[00:57] <RAOF> Is there a bug filed, and can you valgrind it?
[00:57] <bjsnider> fixing cairo didn't help
[00:58] <RAOF> Fixing cairo was never *meant* to help compiz
[00:59] <RAOF> So we've got two known OMG bugs on the go, then :)
[01:00] <Sarvatt__> I hit the min/max under compiz one a crapload and didn't realize it
[01:01] <RAOF> The endless-waiting-in-_XReply one?
[01:01]  * Sarvatt__ has a bad habit of min/maxing windows passing time :)
[01:01] <Sarvatt__> yeah
[01:02] <RAOF> Ok.  Make a coffee, finish fixing mono, track down crazy _XReply bug.
[01:11] <Sarvatt__> bjsnider: do you use unity or a classic session?
[01:13] <bjsnider> unity
[01:13] <bjsnider> i thought that cairo was being run as a thread in compiz and with the cairo problem fixed the mem usage would be, but no joy
[01:14] <RAOF> bjsnider: No, the cairo problem was a fixed 5MiB cost for every process that linked to cairo (ie: every GUI app).
[01:15] <bjsnider> well, i think in my case looking at the numbers, compiz has been gobbling up lots of ram since i started using natty 2 weeks ago. the other processes are ok
[01:16] <Sarvatt__> gonna try to look at it in the morning and wanted to be sure you were using unity, I sure as heck can't reproduce it with the blob on a classic session at least
[01:17] <bjsnider> well, that narrows it down
[01:17] <bjsnider> i can see compiz ending up at >500 mb after a few hours
[01:18] <bjsnider> i don't have a swap file so i have to head that off before it goes too far
[01:50] <ScottK> Sarvatt__: We won't unfreeze.  Go ahead and upload and the release team will figure out the best time to get it in.
[02:04] <ScottK> Sarvatt__: I just uploaded it.
[02:08] <ScottK> It's in queue for release team review.
[03:15] <Sarvatt__> ScottK: thanks a ton for that
[03:40] <ScottK> Sarvatt__: It's in.
[09:07] <Sarvatt_> hrm got one http://paste.ubuntu.com/593017/
[09:07] <Sarvatt_> just close the lid with g-p-m set to blank the screen under unity on intel
[09:09] <Sarvatt_> comes back up in a weird state where you can interact with things partially but compiz is hung
[09:09] <RAOF> Partially?
[09:10] <Sarvatt_> yeah cursor is working, it changes when i hover over a resize area but cant change windows or anything
[09:11] <RAOF> Right.
[09:11] <Sarvatt_> i just attached gdb to compiz there while it was in that state
[09:11] <RAOF> I *think* that's another manifestation of the same bug.
[09:11] <RAOF> X is happily motoring along, compiz is sitting waiting for X to reply to its request.
[09:43] <Sarvatt_> hmm either http://cgit.freedesktop.org/xcb/libxcb/commit/?id=f0565e8f06aadf760a9065a97b8cf5ab9cbd18de helped or I just got lucky being able to reproduce it 3 times in a row there earlier :)
[09:44] <tjaalton> there was talk on the xcb list last month about a new release, but nothing came out of it, yet
[09:46] <RAOF> sarvatt: Hm.  If I read that commit correctly it should result in compiz dying with an IO error.
[09:47] <RAOF> Sarvatt_: Yeah; that'll result in the X connection being shut down, which compiz is unlikely to be happy with.
[09:53] <RAOF> Sarvatt: If you want a nice reproducer, revert bzr r1091 from unity.  That'll make maximize kill things again ;)
[09:53] <Sarvatt_> must just need to have it closed for a longer period of time to reproduce it then, had it closed >30 minutes each time before
[09:54] <Sarvatt_> oh maximize is fixed now?
[09:54] <Sarvatt_> woohoo
[09:54] <RAOF> Yeah.  Well, worked around, at least.
[10:28] <Sarvatt_> ugh, intels gonna need another upload now too
[10:28] <Sarvatt_> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=686018f283f1d131073ef5917213e6a8ac013f26 fixing all the 915gm hangs
[12:35] <seb128> could someone reassign, set bug settings as appropriate for bug #757906
[12:35] <ubot4> Launchpad bug 757906 in unity (Ubuntu) "compiz assert failure: compiz: intel_tex_image.c:726: intelSetTexBuffer2: La declaración `!texImage->Data' no se cumple. (affects: 6) (dups: 6) (heat: 56)" [Medium,New] https://launchpad.net/bugs/757906
[12:37] <tjaalton> seb128: done
[12:37] <seb128> tjaalton, thanks
[12:38] <seb128> tjaalton, I've dumped some similar bugs I found googling about the error in the comments
[12:38] <seb128> not sure how useful they are though ;-)
[12:39] <tjaalton> seb128: we'll see :)
[17:06] <lool> Hey
[17:06] <lool> syndaemon is using 100% here, even after logging out and back in; did anybody see this so far?
[17:07] <lool> looks like https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/754470
[17:07] <ubot4> Launchpad bug 754470 in xserver-xorg-input-synaptics (Ubuntu) "syndaemon consumes 100% CPU (affects: 31) (dups: 1) (heat: 150)" [Undecided,Confirmed]
[17:12] <lool> cnd: ^
[17:13] <cnd> lool, I haven't seen it
[17:13] <cnd> I thought syndaemon was deprecated...
[17:15] <cnd> I guess not since I'm running it :)
[17:15] <Sarvatt> the disable touchpad while typing option in the gnome capplet uses it
[17:16] <cnd> lool, can you install the dbgsym package and gdb it to see where it's stuck?
[17:21] <lool> cnd: Actually I rebooted after a kernel upgrade and it doesn't happen for me anymore
[17:23] <lool> I got it three times after logging out and killing it, but now that I rebooted it's gone
[17:23] <lool> cnd: I'll gdb it if I reproduce though
[17:23] <cnd> lool, ok, thanks!
[17:40] <Sarvatt> updating libxcb is always an adventure.. https://launchpadlibrarian.net/69144345/buildlog_ubuntu-natty-i386.libxcb_1.7%2Bgit20110412.42c4adef-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
[17:40] <Sarvatt> at least it doesnt need autoreconf patches refreshed every time now
[18:21] <bryceh_> Sarvatt, did that -intel patch get taken care of by anyone already?  Should I roll up a ppa and solicit testers?
[18:23] <Sarvatt> bryceh_: nope not yet, it'll need a bit of cleaning up for 2.14.0 because of has_kernel_flush
[18:23] <bryceh_> ok
[18:32] <bryceh_> Sarvatt, did everything get in yesterday that needed in?  mesa and whatnot?
[18:32] <Sarvatt> bryceh_: yep!
[18:32] <bryceh_> ok great
[19:04] <tjaalton> i bought an esprimo v5535 with sis mirage 3+ (672) on it, oh my..
[19:05] <bryceh_> tjaalton, get it for a good price?
[19:05] <tjaalton> bryceh_: that would've meant "free" :)
[19:05] <bryceh_> heh
[19:06] <bryceh_> guess it'll keep you busy at least
[19:06] <tjaalton> well, it's a bit faster than the old thinkpad t23, so once flash runs on it I'll pass it on to the kids
[19:07] <bryceh_> I got an old via system hereabouts (one of those walmart PCs back when they were selling linux)
[19:07] <tjaalton> does openchrome work with it?
[19:08] <bryceh_> unfortunately the cpu isn't well supported by the kernel so last I tested (which was a while ago) I couldn't even get it booting
[19:08] <bryceh_> figure I'd need to roll my own kernel with a custom config.  maybe someday
[19:09] <tjaalton> huh, that's.. bad
[19:09] <tjaalton> via cpu?
[19:09] <bryceh_> C3  iirc
[19:10] <tjaalton> right, so the optimizations make it unbootable
[19:10] <tjaalton> or the cpu family support in -generic
[19:10] <bryceh_> yeah at the time I looked at it, it just needed a config setting that we don't include by default
[19:11] <bryceh_> but even when it does work, the system is slow as snot
[19:11] <tjaalton> hehe
[19:11] <tjaalton> this one seems to be noisy
[19:11] <tjaalton> the fan is on full blast even when idling
[19:12] <bryceh_> ew
[19:12] <tjaalton> i suspect overheating issues
[19:12] <tjaalton> in the future
[19:12] <bryceh_> hot gpu or does it just not support power modes?
[19:12] <tjaalton> it was the same on win7
[19:12] <bryceh_> ah
[19:12] <tjaalton> i'll try with only the battery..
[19:13] <bryceh_> it's crazy how many gpu's I've burned through so far working on X
[19:13] <bryceh_> 4-5 I think
[19:13] <bryceh_> (mainly ati)
[19:13] <tjaalton> though seems like the live-session doesn't support cpu throttling
[19:13] <tjaalton> oh, just overheated them?
[19:15] <bryceh_> tjaalton, any theories on bug 747205?
[19:15] <ubot4> Launchpad bug 747205 in libdrm (Ubuntu) (and 1 other project) "[arrandale] Black screen on all outputs when external VGA is connected (affects: 7) (dups: 2) (heat: 50)" [High,Triaged] https://launchpad.net/bugs/747205
[19:17] <tjaalton> bryceh_: well, it's worse with compiz. but the register dumps are what ickle wants now
[19:18] <tjaalton> i mean with metacity it's almost equally broken, just that you get back to normal by unplugging the monitor
[19:20] <bryceh_> right
[19:57] <BlackZ> hello, are nvidia drivers expected to be broken on natty?
[19:58] <Sarvatt> only nvidia-173 and nvidia-96
[19:59] <BlackZ> Sarvatt: I can't get my video card working with nvidia-current
[20:00] <Sarvatt> what GPU is it? can ya describe how its broken? like can you not install the package at all?
[20:01] <BlackZ> Sarvatt: nvidia geforce 7500 LE; I can't run the default Ubuntu desktop session (even unity doesn't run completely); I can successfully install the package and build the kernel module
[20:02] <Sarvatt> BlackZ: yeah that one needs the nvidia-173 driver and not nvidia-current unfortunately :(
[20:02] <Sarvatt> oh wait, I'm sorry
[20:02] <bjsnider> no, it shuld work
[20:02] <bjsnider> 6k and onwards
[20:03] <bjsnider> BlackZ, have you got any crazy ppa add-ons?
[20:03] <BlackZ> bjsnider: no, fresh natty install
[20:04] <Sarvatt> BlackZ: can you pastebin a /var/log/Xorg.0.log (or .old) from a failed startup?
[20:06] <BlackZ> Sarvatt: http://pastebin.ubuntu.com/593259/
[20:07] <tjaalton> um, looks normal
[20:07] <Sarvatt> yeah that looks fine, how about ~/.xsession-errors?
[20:09] <BlackZ> Sarvatt: http://pastebin.ubuntu.com/593263/
[20:10] <Sarvatt> sudo apt-get purge nvidia-173 for starters
[20:11] <BlackZ> Sarvatt: it's not installed
[20:12] <BlackZ> Sarvatt: however I have no problems at booting time; I have problems when starting a session in gdm (e.g. the default Ubuntu one)
[20:13] <BlackZ> Sarvatt: if I use the nouveau drivers all works good
[20:15] <Sarvatt> i'm not sure whats going on with your sessions there but it looks like the nvidia driver is working fine, do you have any packages missing by any chance? sudo apt-get install ubuntu-desktop offer to install anything?
[20:16] <BlackZ> Sarvatt: no, it doesn't
[20:21] <BlackZ> Sarvatt: however I only have this problem on natty; on maverick the proprietary nvidia drivers works good
[20:28] <bjsnider> BlackZ, did you install all updates as of today?
[20:28] <BlackZ> bjsnider: yes
[20:28] <jcastro> Sarvatt: other than the occasional artifact in the dash the thinkpad X120E is running great with the open drivers, thanks for sorting out snagging the patch from upstream
[21:23] <bjsnider> Sarvatt, how much ram would you say compiz should typically be using in natty?
[21:34] <JanC> I think RAM usage depends on what plugins you have enabled and probably also on display size, number of workspaces, & such?
[23:08] <bjsnider> JanC, right. in this case, it's just stock default unity


[20:08] <BUGabundo> bRoas
[20:50] <BUGabundo> this is gonna be me in a couple of weeks! #Parashute-jump #tandem https://plus.google.com/u/0/110546133384368429145/posts/cZ4RH83okXu


[12:17] <adreba> aaa
[12:23] <theShirbiny> adreba: \o/
[12:31] <adreba> from?
[12:49] <theShirbiny> adreba: Earth
[13:01] <adreba> hhhh me to
[13:02] <theShirbiny> :D
[13:03] <theShirbiny> What brings you here adreba? :D
[13:06] <adreba> i went to learn c/c++
[13:07] <theShirbiny> try #programming and #friendly-coders :)
[13:09] <adreba> thanks
[13:10] <adreba> you speak other
[13:10] <adreba> ?
[13:10] <theShirbiny> I speak English and Arabic
[13:10] <theShirbiny> I joined this channel by mistake :)
[13:12] <adreba> mo to
[13:18] <adreba> kayfa 7alok bi5ayr?
[13:20] <theShirbiny> tamam :)
[13:20] <theShirbiny> You're from US?
[13:21] <adreba> morocco
[13:21] <theShirbiny> ah, join us in #linuxac :)
[13:40] <adreba> ok
[14:02] <adreba> كيف يمكن ان اوجه لك الكلام


[20:17] <adrian_1908> Hello. Recently "mpv" disabled DVB support by default which had always been there (https://git.srsfckn.biz/mpv/commit/?id=99cef59fc9a4d33ebbbb4405ec86faf0ff213f0c). I think the feature should be enabled for Ubuntu, which doesn't use old kernels. Who would I contact in that case? Do I file a launchpad issue?


[03:18] <Dandel> mlankhor1t, Any idea on what will happen now that XvMC is disabled by default in mesa? ( as a hint, it's due to failed unit tests on R300 and R600 gallium drivers )
[03:23] <RAOF> We'd like to turn on the actually useful acceleration (ie: vdpau).
[03:42] <Sarvatt> xvmc was never useful, xv and vdpau werent enabled in debian/ubuntu mesa because of the regressions it causes, what?
[03:43] <RAOF> Oh, what regressions does vdpau support cause?
[03:43] <RAOF> Applications start trying to use it, and fail?
[03:43] <Sarvatt> mpeg2 doesnt work on radeon for one
[03:44] <Sarvatt> if its enabled it tries to use it and just doesn't work
[03:45] <Sarvatt> i think the next stable 10.x mesa release might fix that at least
[03:47] <Sarvatt> some playback apps try to use vdpau if its available, trying to watch an mpeg2 video means it wont work
[03:48] <Sarvatt> aka it broke xbmc playback of recorded tv shows
[03:49] <Sarvatt> flash uses vdpau if its available too
[03:52] <Sarvatt> it advertises mpeg2 acceleration but doesnt work
[03:57] <Sarvatt> 10.0.2 should do shader based decoding on radeon afaik and make it work, not sure its actually been picked up in stable
[04:00] <RAOF> t
[04:00] <RAOF> We wouldn't actually be installing the vdpau libs by default though, would we?
[04:00] <RAOF> That'd be opt-in breakage :)
[04:01] <RAOF> Another option would seem to be patching out the "yah, I support mpeg2" bit.
[04:03] <Sarvatt> 14.04 will for sure have it, but mesa 10.x wasnt good enough imo
[04:05] <Sarvatt> 10.0.x rather
[04:13] <Sarvatt> i guess thats true, it could be opt in
[04:32] <jarkko_> i had 13.10 and not much happened there, but now i upgraded into 14.04 and i get lots of updates...
[04:32] <jarkko_> there was quite a lot some appamor skipping while installing/updating system
[05:43] <tjaalton> jarkko_: feel free to reinstall 13.10 if you don't like that. 14.04 isn't released yet so yes you get daily updates until late april or so..
[05:44] <jarkko_> daily updates?
[05:44] <jarkko_> someone must be busy then
[05:44] <jarkko_> i dont see any change in this
[05:44] <jarkko_> boot time could be better
[05:46] <tjaalton> well we tried to see if mesa 10 fixed radeon for you, then while it was updating you got the upstream bug report saying it's still broken
[05:46] <tjaalton> so if you like a quiet distro with fglrx, stick to 13.10
[05:46] <jarkko_> i am not going to switch back
[05:47] <jarkko_> no reason
[05:47] <jarkko_> installing closed source drivers this boots normally again
[05:50] <tjaalton> yes but they'll break soon :)
[05:50] <jarkko_> ?
[05:50] <jarkko_> what do you mean
[05:51] <tjaalton> the xserver will be updated and we don't have working fglrx for it just yet
[05:51] <tjaalton> but you can just not blindly update and wait until it's settled
[05:51] <jarkko_> to the newest x.org?
[05:51] <tjaalton> yes
[05:52] <jarkko_> would think that ati releases new drivers soon which has a newer kernel support or newer xorg support
[05:52] <jarkko_> there is something broken in this style of coding, if the api changes from every release that ati doesnt work
[05:54] <tjaalton> it was released last month, they're just slow
[05:57] <jarkko_> do you know when xorg is going to pushed?
[05:57] <tjaalton> maybe next week
[06:14] <jarkko_> what's new in latest xorg?
[08:21] <mlankhor1t> Dandel: not pretty much everything said above, if you want to enable vdpau you can build yourself :p