[02:06] <psusi> so after upgrading to utopic, after a bit Xorg decides it is going to burn several seconds of cpu time locking up on various benign activities like closing a tab in firefix, sometimes changing tabs in gnome-terminal, opening email in thunderbird... this doesn't seem to be a problem booting the livecd... any ideas how to debug this?
[02:15] <Sarvatt> psusi: guessing nvidia or fglrx drivers on the actual install and not on the livecd? :)
[04:01] <pitti> Bonjour tout le monde
[07:55] <seb128> good morning desktopers
[07:57] <seb128> hey robert_ancell
[07:57] <robert_ancell> seb128, hello
[07:57] <seb128> robert_ancell, how are you?
[07:57] <robert_ancell> good
[07:58] <seb128> robert_ancell, so the gnome-desktop new dbus service/api solution doesn't seem to be that easy, we are thinking we should land your work
[07:58] <seb128> robert_ancell, do you think you could continue/get it done?
[07:58] <robert_ancell> seb128, sounds good to me
[07:58] <robert_ancell> seb128, I'll sort it tomorrow
[07:58] <seb128> you were still missing some bits like idle monitor iirc?
[07:58] <seb128> thanks
[07:59] <robert_ancell> yeah, that's not too much more work
[07:59] <robert_ancell> I also have to fix unity-greeter
[07:59] <Laney> nice
[07:59] <robert_ancell> I have some branches for both of those somewhere
[07:59] <seb128> great
[08:00] <robert_ancell> seb128, so no more thoughts on my GTK+ issue? As I understand it, debuild does a clearenv(), then doesn't explicitly set XDG_RUNTIME_DIR. The tests require XDG_RUNTIME_DIR so I'm wondering how it could be set
[08:00] <robert_ancell> The other option is the Wayland backend is disabled on your system for some reason, but again, no idea why that should occur. AFAICT it's enabled for everyone right?
[08:02] <seb128> robert_ancell, I need to try again, but it's possible that wayland is not built for me, I seem to remember .symbols diff in wayland symbols
[08:02] <seb128> but not sure why that would be
[08:02] <Laney> XDG_RUNTIME_DIR> a few packages make this in debian/rules and then export it
[08:02] <Laney> same for HOM
[08:02] <Laney> E
[08:03] <seb128> but why would it be working for !robert_ancell?
[08:03] <Laney> I don't know what problem you're talking about :P
[08:04] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1342398
[08:04] <seb128> Laney, read comment #3
[08:04] <robert_ancell> Laney, ah, that might be worth looking at
[08:04] <seb128> robert_ancell, dpkg -l | grep libwayland ?
[08:05] <Laney> are you using sbuild and nobody else is?
[08:05] <robert_ancell> Laney, no, just bzr-buildpackage from the directory
[08:05] <Laney> hmm
[08:05] <robert_ancell> I know it's not a super-clean-build but it's always worked fine previously
[08:05] <seb128> robert_ancell, you have a local version of libwayland in /usr/local?
[08:05] <robert_ancell> I also haven't checked how the error callback is done in Wayland, I guess there's a possibility there's a race
[08:05] <robert_ancell> seb128, no
[08:05] <seb128> just trying to rule out difference
[08:06] <Laney> either way I think it's reasonable defensiveness to set this
[08:06] <robert_ancell> I'll copy the glib way it's set and try again
[08:06] <seb128> thanks
[08:07] <Laney> how do I bzr push a revision but not its tag?
[08:07] <robert_ancell> Laney, you want the tag locally?
[08:08] <Laney> yeah
[08:08] <Laney> I just want to keep it unpushed until the SRU is accepted
[08:08] <robert_ancell> I think you can only delete the tag, push, then create it again with the standard tools
[08:09] <Laney> okay
[08:09] <robert_ancell> I'm always bitten by the way you can't delete a tag once it's in an upstream branch, only move it it seems
[08:12] <Laney> I'm going to check in #bzr to be sure
[08:42] <robert_ancell> Laney, did you get an answer to your bzr tag question?
[08:42] <larsu> robert_ancell: Laney says no
[08:43] <larsu> robert_ancell: in #bzr that told him the same thing
[08:43] <robert_ancell> ah
[08:43] <robert_ancell> you guys all in Starbourg?
[08:43] <robert_ancell> you guys all in Strasbourg?
[08:44] <larsu> haha starbourg :)
[08:44] <larsu> yep, we are
[08:44] <robert_ancell> jealous
[08:44] <larsu> :)
[08:44] <larsu> we miss you
[08:44] <robert_ancell> have a beer for me :)
[08:44] <larsu> definitely!
[08:47] <seb128> robert_ancell, we are going to miss you in China as well, shame that was midway for you
[08:47] <robert_ancell> yeah, I'm really sad I'm going to miss that one
[08:48] <robert_ancell> Hopefully there will be other China opportunities in the future
[08:48] <seb128> yeah
[08:48] <seb128> you are off for a week or longer?
[08:48] <robert_ancell> two weeks
[08:48] <seb128> k
[08:48] <seb128> enjoy!
[08:48] <seb128> starting friday?
[08:48] <robert_ancell> I will do :)
[08:48] <robert_ancell> Monday
[08:48] <seb128> well, friday after work I guess ;-)
[08:49] <robert_ancell> I have the weekend to relax before my holiday :)
[08:49] <seb128> I see ;-)
[08:51] <happyaron> seb128: I'll deal with that mp when merging ibus 1.5.7, which is still sitting in NEW
[08:51] <seb128> happyaron, ok, thanks
[08:51] <happyaron> well, upstream just released 1.5.8...
[08:53] <seb128> happyaron, let's update then ;-)
[08:53] <happyaron> yup
[08:58] <robert_ancell> Laney, aw yeah. Your XDG_RUNTIME_DIR trick works perfectly
[08:58] <seb128> robert_ancell, nice, it still doesn't explain why it works for us and not you though
[08:58] <seb128> but I guess as long as it works..
[08:59] <robert_ancell> seb128, yeah, it's weird but the Wayland backend does require this and it could be invoked in tests so we should set XDG_RUNTIME_DIR
[08:59] <seb128> robert_ancell, so, since you are on holidays in some days, can you get gnome-desktop read
[08:59] <seb128> ready before that
[08:59] <seb128> I guess gtk/mir is going to be for after you are back?
[08:59] <robert_ancell> seb128, you mean the u-c-c changes?
[08:59] <seb128> ye
[08:59] <seb128> s
[09:00] <robert_ancell> I'll upload the gtk-mir changes tomorrow too now I can build it
[09:00] <seb128> great
[09:02] <robert_ancell> ok, I'm off. Enjoy GUADEC!
[09:03] <larsu> thanks!
[09:03] <seb128> robert_ancell, thanks, have a nice evening
[09:09]  * Sweetshark does a jump to the left.
[09:09]  * Sweetshark does a step to the right.
[09:09]  * Sweetshark puts the hands on his hips.
[09:10] <Sweetshark> well, you know the drill.
[09:10] <seb128> hey Sweetshark
[09:11] <Sweetshark> (FWIW, LibreOffice 4.3.0~rc4 successfully finished building on utopic-proposed/armhf)
[09:11] <Sweetshark> seb128: heya!
[09:11] <seb128> nice
[09:20] <seb128> no willcooke today?
[09:20]  * seb128 sends a no meeting email then
[09:21] <mvo_> Sweetshark: so you do a timewrap dance in order to make LO build?!?
[09:33] <Sweetshark> mvo_: that is part of the ceremony along with sacrifcing a chicken and a sardine to a cargo plane under a palm tree and other things ...
[09:34] <mvo_> heh
[09:39]  * Sweetshark refactored some 20+ year old writer core code hard to half the LOC last week. twas fun, a bit like http://i.imgur.com/9lAkenv.gif
[09:39] <Sweetshark> Im looking forward to the regression reports.
[09:40] <mvo_> :)
[09:56] <Sweetshark> seb128: since no meeting, here is a quick status update: We'll have LibreOffice FTBFS for a few days on utopic as there is a desparate need to transition all the stuff that has been stacking up on utopic-proposed.
[09:58] <Sweetshark> seb128: As said: 4.3.0 builds in proposed, so fixing up 4.2.4 again just for a few days seems like a waste of time. (esp. since when armhf is finished building, it will be broken again </sarc>)
[10:00] <seb128> Sweetshark, k
[10:00] <Sweetshark> seb128: and 4.2.6 is in the PPA and looking good so far, so could be SRUed in a week or so (well, when Im back from Uruguay) ...
[10:08] <willcooke> hi folks
[10:15] <seb128> willcooke, hey
[10:16] <seb128> willcooke, not sure if you wanted to have an IRC meeting with people who are not at GUADEC?
[10:17] <seb128> I sent an no-meeting email since you were not online and a part of the team is not going to be available today
[10:53] <ricotz> Sweetshark, hi :)
[10:56] <Sweetshark> ricotz: ho
[10:57] <ricotz> Sweetshark, sounds about time for a libreoffice-4-3 ppa ;)
[10:57] <Sweetshark> ricotz: heh, yeah.
[10:58] <ricotz> i would prefer to keep 4.3 out of the main ppa until the obvious regressions are fixed
[10:58] <ricotz> i mean for the backports
[11:01] <ricotz> i seems those new "lgw01-*" builders are quite something
[11:03] <Sweetshark> well, I wouldnt bother too much with waiting. After all thats what upstream releases and if you have the main PPA you should know what you are in for. Otherwise you should use the libreoffice-4-x ppa.
[11:03] <Sweetshark> and the best way to make regression go away fast, is to have some decent install base.
[11:03] <Sweetshark> ricotz: ^^
[11:03] <ricotz> Sweetshark, of course the conflicts needs to be fixed as well first
[11:04] <ricotz> and yeah, but some don't actually realized what they are committing too
[11:04] <Sweetshark> oh, yeah. Well, packaging conflicts are something else. It should install generally ;)
[11:04] <ricotz> meaning the libreoffice-common <-> libreoffice-base problem
[11:04] <ricotz> iirc
[11:05] <Sweetshark> ricotz: well, the PPA should do what it says it does and not what we think what people think it does. the latter is the road to madness. ;)
[11:08] <ricotz> Sweetshark, i see not sure i mentioned it already, but would it be reasonable to have a libreoffice-fresh and libreoffice-stable ppa too?
[11:11] <ricotz> (Sweetshark, better just "fresh" and "stable" to avoid this verbose naming)
[11:13] <Sweetshark> ricotz: IMHO no.
[11:14] <Sweetshark> ricotz: uptsream is pointlessly discussing renaming libreoffice-stable to soemthing else (there is a new proposal each week)
[11:14] <Sweetshark> ricotz: and the main PPA is already what libreoffice-fresh is.
[11:15] <ricotz> heh, ok, having a release named stable when it reached EOL is not useful anyway
[11:15] <Sweetshark> ricotz: having two ppas doing the same thing would just create endless confusion. And "killing"/deleting the main PPA makes you just lose a lot of subscribers.
[11:16] <Sweetshark> ricotz: I think we had this discussion a few times already.
[11:18] <ricotz> could be, but the organization is still confusing, people are just using libreoffice/ppa to avoid the need to look after things and blindly do updates imo
[11:19] <ricotz> so at least a "stable" ppa would make sense which will receive major-version updates if it is considered safe
[11:20] <Sweetshark> ricotz: actually a "stable" ppa will not work anyway for most people. example:
[11:21] <Sweetshark> When trusty was released it came with 4.2.3 (fresh), so trying to install "stable" 4.1.x on it would be a pain anyway.
[11:22] <ricotz> (the 9-month support cycle makes pockets obsolete quite fast as well)
[11:22] <ricotz> hmm, ok, i guess i have more the pov of precise users
[11:24] <ricotz> the numbers of trusty and precise ppa-users are already kind of the same
[11:25] <ricotz> (ca 11000 vs 13000)
[11:25] <Sweetshark> ricotz: well, for trusty we consider shipping a new series too (e.g. something like 4.3.6 when its there). So it would only be about precise ...
[11:26] <ricotz> Sweetshark, oh, has this decided already?
[11:33] <xnox> Sweetshark: doom has migrated to release pocket. So you are good to go with 4.3.0 =)
[11:41] <Sweetshark> xnox: yay, utopic doom follows trusty quake!
[11:43] <ricotz> what specs do the new ppa builders have?
[11:44] <ricotz> looks like the libreoffice precise i386 build will finish under 3 hours
[11:52] <ricotz> Sweetshark, of course dont upload it as long /usr/lib/libreoffice/presets/basic/script.xlc and /usr/lib/libreoffice/share/basic/dialog.xlc conflict ;)
[11:54] <Sweetshark> ricotz: is that on precise only? otherwise, do you have a bugref?
[11:55] <ricotz> Sweetshark, this is your utopic build, there is no bug
[11:55] <ricotz> i mentioned it to you for rc1 already
[11:55] <ricotz> libreoffice-common and libreoffice-base
[11:59] <ricotz> Sweetshark, this is more something for a bug report http://people.ubuntu.com/~ricotz/libreoffice/
[12:06] <Sweetshark> ricotz: well, what have those pdfs to do with those .xlc files and -common and -base?
[12:08] <ricotz> Sweetshark, nothing, this is just a problem which would prevent me from using 4.3.0 on a wider scale
[12:09] <Sweetshark> ricotz: well please file an issue proper. there are 27000 others to keep track of.
[12:11] <ricotz> Sweetshark, will try
[12:11] <ricotz> Sweetshark, i am wondering, aren't you installing the complete libreoffice stack for testing?
[12:14] <ricotz> another issue could be the "g++-" and "gcc-" references
[12:14] <Sweetshark> ricotz: I see no conflict on  /usr/lib/libreoffice/presets/basic/script.xlc
[12:15] <ricotz> seems the GCC_VERSION is not set on generation for you
[12:15] <ricotz> Sweetshark, oh, both files are in /usr/lib/libreoffice/share/basic/
[12:16] <ricotz> this considers the build-deps and deps of libreoffice-subsequentcheckbase in debian/control
[12:17] <ricotz> i will be back later
[12:46] <happyaron> Laney: I'm looking for how to create a packageset for cinnamon, is a mail to devel-permission suffice?
[12:46] <Laney> happyaron: you'll need to apply
[12:46] <Laney> wiki page + mail to devel-permissions
[12:47] <om26er> Laney, I believe you wrote the sound panel ?
[12:47] <happyaron> Laney: go through a complete ppu procedure right?
[12:47] <Laney> right
[12:47] <om26er> ah I see a comment from you, lemme first try that
[12:47] <Laney> om26er: erm, can't remember really, maybe parts
[12:47] <happyaron> ok
[13:11] <seb128> willcooke, hey, is that one 30 min talk each you want?
[13:11] <willcooke> seb128, hey - sorry I missed you earlier.  Was travelling, and then straight in to meetings.
[13:11] <seb128> no worry
[13:12] <willcooke> seb128, so about the talk
[13:12] <willcooke> seb128, if you have a topic which you would like to talk about to them, then yes, 1 talk each
[13:14] <seb128> k
[13:28] <om26er> Laney, the bug that I reported does not happen if I execute from phone's terminal
[13:29] <Laney> om26er: so this is intended behaviour
[13:29] <Laney> those settings can only be changed by a present user
[13:30] <Laney> I'm not sure how autopilot is run in this respect
[13:30] <om26er> Laney, when we login as phablet user isn't that the same ?
[13:30] <Laney> no
[13:34] <Laney> those are considered "inactive"
[14:00] <willcooke> attente, running a couple of mins late, sorry
[14:01] <willcooke> attente, ok, done - joining the hangout now
[14:02] <seb128> attente, he's at GUADEC with us and we are in a session
[14:02] <seb128> ups
[14:02] <seb128> willcooke, ^
[14:03] <willcooke> argh - I knew that
[14:03] <willcooke> thanks seb128
[14:03] <seb128> yw!
[14:03] <willcooke> sorry attente - we will catch up in person next week then :)
[14:03] <Laney> put a shirt on for no reason? ;-)
[14:03] <willcooke> :D
[14:03] <willcooke> rumbled
[14:05] <willcooke> yay!  Just got my visa
[14:09] <Laney> nice one!
[14:10] <seb128> nice
[14:11] <seb128> what flight do you take to get there btw? same as us? or got a different one?
[14:42] <om26er> bug 1349871
[14:42] <om26er> I have probably reported it against the wrong package, whats the correct package for it ?
[15:06] <willcooke> erk
[15:06] <willcooke> Some of my Chromium windows have disappeared.
[15:07]  * qengho appears!
[15:07] <willcooke> e.g. I've got a hangout going in a separate window, and I can hear the hangout, and my webcam is live - but I can't "find" the window
[15:07] <willcooke> ah
[15:07] <willcooke> just had a Chromium crash
[15:07] <willcooke> it's still running, but I have these missing window
[15:07] <willcooke> s
[15:08] <willcooke> qengho, probably just a one off, but is there anything useful I can do?
[15:08] <seb128> oh, speaking of chromium?
[15:08] <qengho> willcooke: I've seen some weirdness with F11 full screen and Unity and alt-tab switching. Were you doing anything like that?
[15:08] <seb128> what's the status of the 36 update?
[15:08] <seb128> it was to be uploaded during the week at our previous meeting
[15:08] <seb128> which was a week ago...
[15:09] <qengho> seb128: I still have bugs. I think I'll have these fixed today.
[15:09] <seb128> should we upload 35 then?
[15:09] <seb128> the reason it was delayed is because 36 was almost ready
[15:10] <seb128> but if it takes almost a week the "almost" is not true anymore...
[15:10] <qengho> seb128: I don't mind if ccc uploads 35. It costs me nothing.
[15:10] <seb128> chrisccoulson, ^
[15:11] <seb128> qengho, well, he was waiting on you to get 36 out which was supposed to happen during the week
[15:11] <seb128> that didn't happen
[15:11] <seb128> so maybe we should revisit the decision?
[15:14] <willcooke> that sounds like a good idea - as there might be more bugs in 36 which haven't been discovered yet.  If 35 is ready to go, I vote for uploading it
[15:14] <qengho> seb128: For my part in the decision, I don't know these will be the last bugs. Every day has seemed like it would be like the last problem to fix.
[15:14] <willcooke> qengho, yeah - agree.  So let's roll with 35 then
[15:14] <willcooke> ?
[15:14] <seb128> +1
[15:15] <qengho> seb128, chrisccoulson, okay, 35 now please.
[15:15] <willcooke> coolio
[15:15] <seb128> chrisccoulson, ^
[15:15] <seb128> thanks
[15:15] <chrisccoulson> I guess the problem is that it isn't zero cost for me (it's about half a day to a day of manual tests for each of the releases)
[15:15] <chrisccoulson> which is why I wanted to avoid doing it twice in the space of a couple of days
[15:16] <willcooke> chrisccoulson, can they be automated?  Just trying to understand if we have any scope for reducing that time and effort
[15:16] <seb128> chrisccoulson, well, it's not a couple of days
[15:16] <seb128> it's turning into a couple of weeks
[15:16] <seb128> (again, seems to be a recurrent issues, we are often late to roll chromium updates)
[15:18] <willcooke> seb128, qengho, chrisccoulson - would it help if we target a particular schedule to release?  Like, every Tuesday or whatever?  So that if we have two versions closely following each other we don't have to duplicate work - if we miss the date then the next time a release can happen is 7 days later? Or is that just asking for trouble?
[15:19] <qengho> willcooke: there are autopkgtests that could test, but it's probably hard to set up on earlier dists.
[15:20] <willcooke> qengho, so we're talking about a trade off between putting effort in to getting tests running on earlier dists vs the amount of effort required to do it manually?
[15:21] <qengho> willcooke: I think that's the trade-off. Manual testing is more likely to assure nothing is broken, I think.
[15:22] <qengho> willcooke: and it's not so often a release (not every week) that we get savings any time soon in setting up stable-release automated testing.
[15:22] <willcooke> riight - so quite a long time to see a return on investment
[15:22] <willcooke> hrm
[15:23] <willcooke> no easy answer here then ;)  (Because if there was you would have already done it!)
[15:23] <qengho> :)
[15:23] <willcooke> So - I think we should go with 35 now, just in case there are any more bugs, and then we can put some more thought in to how to improve things going forward.
[15:24] <willcooke> I dont think we need to *solve* the problem straight away, if we can make it a bit better, that's progress.
[15:24] <qengho> chrisccoulson: I'll need a day after this is done to get sign-off from webapps and qa anyway.
[15:24] <willcooke> then keep chipping away at it
[15:24] <willcooke> so, back to my original problem then :)
[15:25] <willcooke> qengho, I think what happened was something along the lines of...  super-L to lock screen, went to get a coke, came back and I could still see the desktop, but I couldnt click anything, went to vty 1, looked at syslog, libcontent.so segfaulted
[15:25] <willcooke> back to desktop
[15:25] <willcooke> the unlock screen appears, and I unlock
[15:25] <willcooke> back to my desktop
[15:25] <willcooke> join a hangout
[15:25] <willcooke> move that tab to its own window
[15:25] <willcooke> then probably minimized it
[15:26] <willcooke> then went to look for it, but it's not there
[15:26] <willcooke> launcher icon shows only a single window
[15:26] <qengho> Huh. libcontent is half the browser. :\
[15:26] <willcooke> yikes
[15:26] <willcooke> oohhhhhhhh
[15:26] <willcooke> hold on
[15:26] <willcooke> I tell you what
[15:26] <willcooke> I was also dicking around with VPNs
[15:26] <willcooke> I wonder if a network glitch upset something
[15:27] <willcooke> bah - I'll kill them and restart Chromium and see if I can reproduce it
[15:27] <willcooke> I expect I wont be able to
[15:28] <qengho> willcooke: could be VPN, but I'd expect it to break in a different library then.
[15:29] <willcooke> wooahhhh
[15:30] <willcooke> it reappear back where it was before I detached it in to its own window
[15:31] <willcooke> maybe I dreamt the whole thing
[15:31] <qengho> Ah, good old libvoodoo.
[15:33] <willcooke> just a reminder - there is no weekly meeting this week because lots of people are away
[15:33] <willcooke> unless anyone has anything they want to discuss
[15:33] <willcooke> ?
[15:34] <seb128> nothing specific from GUADEC afaik
[15:36] <willcooke> seb128, did you by any chance bump in the guy about the Gnome Session bug
[15:36] <willcooke> ?
[15:37] <willcooke> seb128 and did you meet happyaron yet?
[15:37] <seb128> willcooke, no, the gnome-session maintainer is not here afaik
[15:37] <willcooke> darn
[15:38] <willcooke> never mind
[15:38] <seb128> willcooke, yes, happyaron is there, we spent some time discussing input methods with attente and him earlier
[15:38] <willcooke> awesome!
[15:57] <willcooke> so qengho, chrisccoulson, seb128  - are we all set to upload Chromium 35 ?  Not sure if we reached consensus there.