[00:28] <rickspencer3> wow gwibber_messages is a very bid database!
[00:45] <rickspencer3> kenvandine,  http://theravingrick.blogspot.com/2010/04/todays-slip-cover-feature.html
[06:48] <pitti> Good morning
[07:40] <czajkowski> morning
[08:11] <baptistemm> bonjour
[08:13] <didrocks> good morning
[09:11] <pitti> seb128: hm, sorry for all the python import warning cron spam -- no idea why it started doing that :-(
[09:11] <pitti> seb128: but at least it's running reasonably stable now
[09:11] <seb128> pitti, hello
[09:11] <seb128> pitti, that's ok, I though you have been restarting a lot when first looking ;-)
[09:12]  * pitti accepts gnome-games and hopes the new pkgbinarymangler will behave
[09:12] <seb128> pitti, thanks
[09:13] <didrocks> hey pitti, seb128
[09:13] <pitti> bonjour didrocks
[09:45] <pitti> seb128: meh, seems pkgbinarymangler on i386 buildd was held back and disabled  for some reason
[09:45]  * pitti pings lamont
[09:45] <seb128> pitti, :-(
[09:49] <vish> seb128: hi.. the humanity distribution upload was from last week or from the latest packagers branch..
[09:49] <vish> ?
[09:50] <seb128> vish, it was the one you asked me to upload one week ago which didn't get approved before beta2
[09:50] <vish> hmm .. :(
[09:50] <seb128> why ":("?
[09:51] <vish> seb128: well , i fixed a few others bugs in lp as well , after that , expecting them to be uploaded at the same time
[09:51] <seb128> ?
[09:51] <seb128> we can still do uploads
[09:51] <seb128> I don't see the issue and why the ":("
[09:51] <vish> ah , neat , then no problems
[09:52] <seb128> what got uploaded was what was in bzr when you asked for upload
[09:52] <vish> :)
[09:52] <seb128> I'm sure what else should have happened?
[09:52] <seb128> ok, good ;-)
[09:52] <vish> seb128: i thought that was the last possible uplaod for Lucid , obviously i was wrong :)
[09:53] <seb128> right
[09:53] <seb128> there is still a week for fixing bugs
[09:53] <vish> neat.. thanks
[10:10] <al-maisan> err .. "apt-get dist-upgrade" on the other lucid laptop wants to remove the compiz and compiz-gnome packages. That's not right, is it?
[10:13] <mvo> al-maisan: no, wait a little bit
[10:13] <mvo> al-maisan: until a new compiz is build
[10:13] <al-maisan> mvo: ok .. thanks!
[10:13] <mvo> seb128: that is the issue btw, metacity breaks older compiz, but new compiz is not the in the archive yet
[10:14] <seb128> oh ok
[10:14] <seb128> mvo, thanks
[10:21] <didrocks> mvo: heh, I guess we ask for rebuilding in the same time (just got i386, you got the others :))
[10:34] <mvo> didrocks: LP tells me "start in 12h"
[10:34] <mvo> didrocks: that is pretty bad
[10:34] <didrocks> mvo: yeah, I saw that too :( I think rescoring could be good if possible
[10:35] <mvo> I think seb128 has the magic for this
[10:35] <seb128> those got accepted yesterday night
[10:35] <seb128> I'm wondering what the buildds have been doing
[10:35] <seb128> mvo, no, pitti has, slangasek already pinged him about it
[10:35] <didrocks> seb128: they have been dep wait, we just relaunch the ping
[10:35] <didrocks> s/ping/build
[10:35] <seb128> mvo, I've archive admin powers, not buildds
[10:36] <seb128> didrocks, depwait should automagically work
[10:36] <seb128> didrocks, it's weird
[10:36] <seb128> do you depwait on the wrong version?
[10:36] <pitti> didrocks: what do you need bumped?
[10:36] <seb128> pitti, compiz
[10:36] <didrocks> seb128: I checked again, it seems not
[10:36] <pitti> yes, a failed build due to depwait will reset the build score to 0
[10:37] <pitti> Rescoring build amd64 to 5000...
[10:38] <seb128> pitti, danke
[10:39] <mvo> is LP lying to me? it looks like compiz/i386 is waiting too
[10:39] <didrocks> pitti: can you do the same for i386, please?
[10:39] <pitti> already done
[10:39] <pitti> except that LP timed out on me, bah
[10:40] <pitti> seems to be on the slow side today :/
[10:40] <pitti> nope
[10:40] <pitti> didrocks: I'll keep trying
[10:40] <didrocks> pitti: thanks
[10:40] <seb128> why was the updated build-depends needed for there?
[10:41] <seb128> do you statically use the lib?
[10:41] <seb128> ie do you need compiz to be "built" with the change
[10:43] <didrocks> seb128: compiz seems to take some part of the button rendering layout from the -dev. and the patch "13_better_support_for_button_layout.patch" in metacity show that we have weird behavior in compiz if not rebuilt
[10:44] <seb128> weird
[10:50] <pitti> . o O { nemiver is really nice }
[10:50] <seb128> pitti, ;-)
[11:06] <geser> in which corner should the notifications bubbles show up? because right now I see it show up in the upper left corner for a fraction of a second before it jumps to right corner (but sometimes I have two notifications bubbles for a short time: one in left corner and one in the right corner)
[11:06] <seb128> didn't change since karmic
[11:07] <seb128> right corner
[11:07] <geser> hmm
[11:07] <seb128> notify-osd code almost didn't change this cycle
[11:07] <geser> I guess I need to file a bug
[11:07] <seb128> do you use a multiscreen setup or something?
[11:07] <geser> yes
[11:09] <seb128> k, could be it
[11:11] <geser> I've a dual-screen setup and when there are 2 or more notifications event in the queue, I get two notification bubbles till the last event is shown (tested with notify send)
[11:40] <pitti> chrisccoulson, fta: wrt. bug 527138, should we just remove enigmail from the archive? it might better suited to install from tbird's extension manager?
[11:40] <pitti> (tbird should be fine now)
[11:46] <pitti> seb128: bug 530605 has a million tasks; should they really be all open against lucid? or is the libgnome-keyring fix sufficient?
[11:46] <chrisccoulson> pitti - i'm not sure. i thought we were going to fix that actually (but i need to check)
[11:46] <seb128> pitti, it has been used as a collector for all cpu eating issues
[11:47] <chrisccoulson> pitti - should bug 544139 be milestoned? it doesn't appear on the RC bugs, but i'm not sure who it should be assigned to...
[11:47] <seb128> pitti, I would close it and ask people who still have a bug to open new bugs
[11:47] <seb128> pitti, the gvfs cpu issue has been fixed in libgnome-keyring or should have been
[11:47] <pitti> seb128: ack
[11:48] <seb128> pitti, other bugs are mainly design issue as discussion this way, now that libgnome-keyring uses dbus it runs in new class of interesting issues if used out of the mainloop etc
[11:48] <seb128> discussion this way -> discussed this week
[11:49] <pitti> seb128: FYI, I reenabled karmic in the retracers, it's catching up now (it caught up with lucid)
[11:50] <seb128> \o/ on lucid catching
[11:50] <seb128> pitti, danke
[11:55] <pitti> chrisccoulson: I assigned bug 557640 to you, which seems related to the other search engine changes you were working on
[11:55] <pitti> chrisccoulson: it sounds like it'd magically fix itself once you switch back to google?
[11:56] <seb128> pitti, schedule seems tighter than usual this cycle to get GNOME .1 in lucid, is that still something we should count on?
[11:56] <chrisccoulson> pitti - i'm not sure the switch back to google will fix that
[11:56] <chrisccoulson> that's probably an issue with ubufox actually
[11:56] <seb128> pitti, or should we rather play backporting git changes
[11:56] <seb128> pitti, or do .1 in sru updates?
[11:57] <pitti> seb128: like hardy, we should probably put point releases into SRUs either way (up to .2 or .3?)
[11:57] <pitti> seb128: when will .1 be released?
[11:57] <cassidy> seb128, what's the deadline for a next Empathy stable release?
[11:57] <seb128> cassidy, wednesday next week
[11:57] <pitti> seb128: for bugs >= high I'd backport either way
[11:57] <seb128> if I read the calendar correctly
[11:57] <cassidy> seb128, ok, I'll release it this afternoon or at the beginning of next week
[11:58] <pitti> seb128: we can still accept some .1 packages during final freeze (the first week, anyway)
[11:58] <seb128> pitti, tarballs due on the 26
[11:58] <pitti> seb128: ugh, that's definitively outside the lucid final range
[11:59] <pitti> seb128: so, I guess .1 in SRU (so that they'll be in 10.04.1) and backporting important stuff?
[11:59] <chrisccoulson> pitti - did you recreate bug 557640? it's working as expected here (ie, it redirects to a local start page)
[11:59] <seb128> right, I wouldn't have asked if it was the week before
[11:59] <pitti> chrisccoulson: no, I just saw it on the RC bug list
[11:59] <seb128> pitti, ok, was my though too, I wanted to mention it and check with you
[11:59] <chrisccoulson> hmmm :-/
[11:59] <pitti> seb128: thanks
[11:59] <pitti> seb128: weird; we don't seem to release earlier than usual; does GNOME release later?
[11:59] <seb128> cassidy, thanks
[12:00] <pitti> chrisccoulson: if it's not reproducible, set it to incomplete and lower priority
[12:00] <seb128> pitti, I think they are one week off compared to usual
[12:00] <seb128> pitti, they did some schedules change for GNOME3
[12:00] <pitti> seb128: I remember that we usually even uploaded them right after RC
[12:00] <seb128> ie respinned a bit things around
[12:00] <seb128> pitti, right, it's usually one week earlier
[12:00] <seb128> which is tight but doable
[12:01] <seb128> one week later is out of scope
[12:01] <seb128> it will avoid the rush before rc
[12:01] <seb128> which is at least something ;-)
[12:01] <seb128> hum, lunch ready
[12:01]  * seb128 bbl
[12:01] <didrocks> seb128: enjoy
[12:02] <pitti> seb128: I'm sure people will cry for things like http://git.gnome.org/browse/gvfs/commit/?id=1cb5861795d375719b196ecf93fb0a10397414d3 :-)
[12:03] <pitti> seb128: I'm happy to do and test git snapshots of gvfs/gdu and some other bits if you want me to
[12:05] <didrocks> pitti: well, I mean, seeing the price of the iPad, they deserve to see "iPad" as a title :-)
[12:06] <pitti> kenvandine: can you please update https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus for DX/OLS?
[12:06] <pitti> hm, where is our favourite Kubutu rocker today?
[12:11] <al-maisan> Is there any chance of getting the enigmail plugin to work with thunderbird3 btw?
[12:13] <pitti> al-maisan: that's the point of that bug
[12:16] <al-maisan> pitti: ah, I see.
[12:17] <didrocks> some users have an unique UNE interface: http://launchpadlibrarian.net/43533691/The%20Blue%20Screenshots.png (that's a bug, still can't find it, he will try with a cleaned /home)
[12:17] <seb128> pitti, I will review all git changes next week
[12:17] <seb128> pitti, but I think we should "snapshot" git for some of the things
[12:17] <seb128> or git diff between stable and current and use that as a patch
[12:18] <pitti> seb128: yeah, whatever you prefer
[12:18] <seb128> gvfs being one
[12:18] <didrocks> seb128: will you need some help for the review?
[12:18] <pitti> seb128: but usually there are tons of translation updates, so a make distcheck in git trunk seems easier
[12:18] <seb128> didrocks, I can use help for this yes ;-)
[12:18] <seb128> pitti, right
[12:18]  * seb128 dessert and coffee, brb
[12:20]  * pitti -> lunch
[12:28] <chrisccoulson> pitti - ok, i reproduced that bug now (i had to clear my cache) ;)
[12:54] <Laney> is it worth deviating from Debian just to add an lpi patch?
[12:57] <seb128> Laney, depends
[12:58] <seb128> Laney, it's the case for quite some GNOME components
[12:58] <seb128> out of the fact that we package those before debian since we track unstable series where they don't
[12:58] <Laney> seb128: not this one (gbrainy)
[12:59] <seb128> robert_ancell wanted to work on an upstream vendor lib
[12:59] <seb128> which would make those deltas be reduced
[12:59] <Laney> I'm doing the merge anyway
[12:59] <Laney> just wondered whether we could sync it instead
[13:00] <seb128> I've no strong opinion on whether those entries are worth the diff for games
[13:00] <seb128> I would say it's low cost to keep it for lucid now
[13:00] <Laney> it needs some porting to the new upstream release
[13:00] <Laney> lets see if it worked
[13:21] <seb128> didrocks, how busy are you for lucid? looking to bug to work on still?
[13:22] <didrocks> seb128: I'm doing nothing important right now (update testing and minor things). So if you have something, I can handle it :)
[13:22] <seb128> didrocks, would you like to look at the desktop effects option hang issue?
[13:22] <didrocks> (btw, reinstalling karmic with the old theme seems *so ugly* now :))
[13:23] <didrocks> seb128: sure, is there a bug report for that?
[13:23] <didrocks> (noticed that but didn't look at g-c-c bug)
[13:23] <seb128> yes
[13:23] <seb128> one with quite some duplicates, let me get the number
[13:24] <didrocks> seb128: bug #554106 ?
[13:24] <seb128> right
[13:25] <seb128> didrocks, you start being faster than me it seems ;-)
[13:25]  * seb128 hugs didrocks
[13:25] <didrocks> seb128: I will never be, don't be afraid :)
[13:25]  * didrocks hugs seb128
[13:26] <seb128> hey pedro_
[13:26] <pedro_> bonjour seb128!
[13:27] <seb128> pedro_, how are you?
[13:28] <seb128> didrocks, I would not be surprised if that was another sideeffect of gtk-threading there
[13:28] <pedro_> seb128, good, thanks , what about you?
[13:28] <seb128> 2.30 had fixes for this which lead to look when things are not hanlded as they should
[13:28] <seb128> pedro_, I'm good thanks!
[13:29] <seb128> pedro_, how is lucid looking for you?
[13:29] <didrocks> seb128: yeah, I just saw "mutex" in the bt and become to be frigthened. Let's take it as a good exercice :)
[13:29] <seb128> didrocks, hehe
[13:29] <pedro_> seb128, is looking great here, can't wait for the final release :-)
[13:30] <pedro_> salut didrocks
[13:30] <seb128> didrocks, https://bugzilla.gnome.org/show_bug.cgi?id=614256 too
[13:30] <didrocks> hey pedro_
[13:30] <baptistemm> olà Pedro
[13:31] <didrocks> seb128: yes, I saw you discussed about that yesterday. Having a look too
[13:31] <seb128> didrocks, obviously the capplet still has locking issues, maybe looking at the recent changes as an inspiration and apply that where it needs to be still done would be a good start
[13:31] <seb128> didrocks, as you said a good learning experience too if you never looked at such issues ;-)
[13:31] <pedro_> bonjour baptistemm!
[13:31] <seb128> lut baptistemm
[13:31] <baptistemm> salut seb128
[13:31] <baptistemm> I feel better to have some power to triage all those blueooth bugs
[13:31] <didrocks> seb128: definitely :)
[13:32] <kenvandine> pitti, will do
[14:03] <seb128> bah
[14:03] <seb128> g-s-d is crash land on launchpad
[14:03] <seb128> it should really not crash because any of the .so is crashing
[14:03] <seb128> ie lot of those are due to keyboard or libgnomekbd issues
[14:05] <chrisccoulson> seb128 - yeah, i just noticed all those crashes in my inbox :(
[14:09] <pitti> shouldn't crash> hm, it's all in-process, isn't it?
[14:11] <seb128> pitti, right, "shouldn"t was a "would be nice if it was redesigned to not be this way"
[14:26] <chrisccoulson> pitti - ok, we figured out bug 557640 in the end
[14:26] <pitti> chrisccoulson: \o/
[14:26]  * kenvandine hugs rodrigo_ for always using a NEWS file :)
[14:27] <rodrigo_> kenvandine, I do it because I know you like it :D
[14:27] <kenvandine> :)
[14:27] <kenvandine> i wish tedg cared what i liked :)
[14:27] <rodrigo_> :)
[14:27] <kenvandine> he makes me guess what's changed
[14:28] <kenvandine> with ted was around for me to harass :)
[14:28] <kenvandine> s/with/wish
[14:29] <rodrigo_> kenvandine, talking about this, do you know how to see the bug# for bzr commits you used 'bzr commit --fixes lp:..." for?
[14:29] <kenvandine> rodrigo_, nope
[14:29] <kenvandine> there must be a way though
[14:30] <rodrigo_> yeah, that's the only thing preventing me from generating NEWS automatically :D
[14:33] <pitti> it's in bzr log
[14:33] <pitti> revno: 1757
[14:33] <pitti> fixes bug(s): https://launchpad.net/bugs/539427
[14:33] <pitti> committer: Martin Pitt <martin.pitt@canonical.com>
[14:33] <pitti> branch nick: trunk
[14:33] <pitti> [...]
[14:41] <rodrigo_> pitti, it's in the bzr log of the branch, but not in trunk it seems
[14:42] <pitti> rodrigo_: ah, it won't be kept across merging, I guess
[14:42] <rodrigo_> pitti, yeah, seems so, and when doing the release I just branch from trunk
[14:42] <pitti> rodrigo_: bzr log -n 2 might help
[14:42] <rodrigo_> seb128, btw, how can I know rhythmbox was started because a device was connected?
[14:43] <seb128> rodrigo_, it's called with the device as argument on the command line I guess
[14:43] <seb128> rodrigo_, ie "rhythmbox <device>"
[14:44] <rodrigo_> seb128, I can't get the command line of rhytmbox from the plugin, except via /proc, afaik, right?
[14:44] <seb128> rodrigo_, I don't know, better asking on #rhythmbox I guess
[14:44] <rodrigo_> pitti, ah, cool, that shows it indeed
[14:50] <chrisccoulson> i'm going to have hardly any bugs left after today!
[14:53] <kenvandine> pitti, see that mail i sent with the U1 bugs?
[14:53] <pitti> chrisccoulson: sounds great!
[14:53] <pitti> kenvandine: didn't get to it yet, sorry
[14:54] <kenvandine> pitti, no worries... it's a long list
[14:54] <kenvandine> pitti, should we put anything about those on the release status page?
[14:54] <kenvandine> or wait until they get targeted ?
[14:55] <pitti> kenvandine: feel free to add them
[14:55] <kenvandine> ok, will do
[14:55] <kenvandine> pitti, put them under RC bugs, Triaged problems?
[14:56] <pitti> yes
[15:04] <seb128> chrisccoulson, on a bug fixing rampage today? ;-)
[15:04] <pitti> go, chrisccoulson, go!
[15:05] <chrisccoulson> seb128 - the firefox upload which i will do later closes 5 bugs
[15:05] <seb128> chrisccoulson, do you still have the xulrunner startup notification one on your lucid list btw?
[15:05] <chrisccoulson> seb128 - yeah, that's been fixed upstream in the 1.9.2 branch, and will be in the FF3.6.4 update
[15:05] <pitti> kenvandine: looked at it now -- it's just accepting the nominations? doing that now
[15:06] <seb128> chrisccoulson, is that coming before lucid?
[15:07] <chrisccoulson> seb128 - that will come as a security update right after lucid
[15:07] <chrisccoulson> in fact, i'll probably be doing the update from UDS ;)
[15:07] <seb128> chrisccoulson, ok, fair enough, still looks weird to have that extra tasklist entry when you start your browser but I guess I'm picky there
[15:08] <pitti> kenvandine: I expect that we need to drop the milestones for most/many of them; but those can all be fixed in SRUs as well, so the lucid targetting still makes sense
[15:09] <pitti> kenvandine: ok, all nominations accepted
[15:10] <kenvandine> pitti, thx
[15:10] <kenvandine> saving wiki page now
[15:11] <pitti> kenvandine: hm, you added all of them? only high/critical should be on that list
[15:11] <pitti> (the release blockers)
[15:11] <kenvandine> oh... damn
[15:11]  * kenvandine edits
[15:12] <pitti> kenvandine: also, since these are by and large done by OLS, I don't think we need to track all of them on our status page
[15:12] <pitti> (but if it helps you, please do)
[15:12] <pitti> kenvandine: but usually those have an associated status
[15:12] <kenvandine> humm... do they have their own status for the release meeting?
[15:13] <pitti> usually yes, so that we can see at a glance where we are
[15:14] <pitti> i. e. which ones are well on track (some are also "fix committed" upstream, btw), which ones are difficult because they lack reproducers, etc.
[15:21] <kenvandine> pitti, ok moved the fixed committed ones and dropped < high
[15:21] <kenvandine> also FYI, the desktopcouch run_couchdb() bug is not fixed
[15:21] <kenvandine> bug 530541
[15:22] <kenvandine> chad is working on it still, he thought it was fixed, but not so much :/
[15:22] <pitti> kenvandine: yes, I thought I said so on the wiki page
[15:22] <kenvandine> you did
[15:23] <kenvandine> just making sure that wasn't stale info :)
[15:23] <kenvandine> it really is still broken
[15:23] <pitti> kenvandine: thanks for the info
[15:49] <chrisccoulson> pitti - is there any way to avoid uploading a tarball again when uploading a new revision of a package with dput?
[15:49] <chrisccoulson> (i should probably know the answer to that already)
[15:50] <chrisccoulson> but uploading 50MB tarballs takes a long time
[15:50] <pitti> chrisccoulson: not with dput, but you can specify -sd on debuild or dpkg-buildpackage
[15:50] <chrisccoulson> pitti - oh, i didn't know that. i'll give that a try, thanks
[15:50] <pitti> chrisccoulson: you can also drop it from the source_changes an re-debsign
[15:50] <pitti> (if building the source takes long)
[15:50] <chrisccoulson> building the source doesn't take long, but uploading the 50MB tarball that i only uploaded a week ago takes a long time ;)
[15:53] <chrisccoulson> heh, that was much quicker
[15:53] <chrisccoulson> about 3 seconds :)
[15:59] <seb128> chrisccoulson, does uploading a new revision with tarball work?
[15:59] <pitti> yes, it does, as long as it's identical
[15:59] <seb128> usually you get an error saying the tarball is already there no?
[15:59] <seb128> oh ok
[15:59] <seb128> I didn't do that for years
[15:59] <seb128> I though it would complain that you try to overwrite the tarball ;-)
[15:59] <seb128> I've a sucking ul, I avoid uploading tarballs twice ;-)
[15:59] <chrisccoulson> seb128 - yeah, it works. i always did that before just because i didn't know how to do it without the tarball ;)
[16:00] <chrisccoulson> but that's ok for small tarballs
[16:00] <chrisccoulson> but for 50MB firefox uploads, it's not so great ;)
[16:00] <pitti> chrisccoulson: the default behaviour should be quite fine
[16:00] <pitti> i. e. with tar for -1 and -0ubuntu1, and without tar otherwise
[16:01] <pitti> chrisccoulson: wow, you rock (just read the changelog)
[16:01] <chrisccoulson> pitti - heh, it got a few bugs closed :)
[16:02]  * pitti updates https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus for the one RC bug
[16:04] <seb128> chrisccoulson, nice update indeed ;-)
[16:04] <bcurtiswx> kenvandine: bug #559151 may become a heavy duplicate bug soon.  Introduced in Gwibber with the 2.29.95.0ubuntu1 just released (sorry if you're not the gwibber guy)
[16:05] <seb128> pitti, when is the meeting today?
[16:05] <seb128> pitti, dst changes confused my calendar
[16:05] <pitti> seb128: just started
[16:05] <seb128> pitti, thanks
[16:06] <kenvandine> bcurtiswx, looking
[16:10] <pitti> seb128: but our turn is still some 45 to 60 minutes out
[16:10] <Nafai> Good morning guys
[16:11] <pitti> good morning Nafai, how are you?
[16:11] <Nafai> pretty well
[16:11] <seb128> pitti, right, I'm just hanging there, end of week mood now :p
[16:11] <seb128> hey Nafai
[16:11] <bcurtiswx> hi Nafai
[16:12] <pitti> seb128: speaking of good moods: http://people.canonical.com/~fader/hw-testing/current.html :-)
[16:12] <pitti> really nice
[16:12] <seb128> waouh
[16:14] <didrocks> good :)
[16:14] <bcurtiswx> that is nice
[16:14] <pitti> so, lamont fixed the buildd chroots, let's give gnome-games another spin
[16:15] <seb128> pedro_, https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/528299
[16:15] <seb128> pedro_, did you bug watch the wrong bug?
[16:15] <pedro_> seb128, let me check
[16:15] <seb128> pitti, nice! what was the issue on the buildd?
[16:15] <pitti> seb128: yes, pkgbinarymangler is on hold and only gets updated manually
[16:16] <pitti> seb128: there were two catastrophes within 4 weeks, and both outside lamont's core hours :)
[16:16] <seb128> I see
[16:17] <kenvandine> bcurtiswx, ok, testing a fix
[16:17] <bcurtiswx> kenvandine: good, thank you
[16:22] <pedro_> seb128, all fixed now, thank you for checking ;-)
[16:23] <seb128> pedro_, np, thanks
[16:30] <pitti> chrisccoulson: you don't happen to have an updated idea about bug 447431 yet, do you?
[16:31] <chrisccoulson> pitti - not yet, i thought the upstream change would have fixed the crash
[16:31] <chrisccoulson> pitti - i'll see if i can still reproduce that in a bit
[16:31] <pitti> chrisccoulson: ah, you could in the past?
[16:32] <pitti> chrisccoulson: if not, perhaps you can arrange ssh access to slangasek's machine
[16:32] <chrisccoulson> pitti - yeah, it crashed for me before
[16:32] <pitti> it's a good SRU candidate, too, though
[16:32] <pitti> chrisccoulson: just mentioning in case you run out of RC bugs :)
[16:33] <chrisccoulson> pitti - i don't think i'll run out, but my list of assigned bugs is quite a bit shorter than it was this morning :)
[16:34] <seb128> bah this g-c-c hand on desktop effects change is weird
[16:34] <seb128> I'm wondering if that's another gtk locking issue similar to the crasher on theme dnd
[16:35] <mclasen> seb128: did you look more into that ?
[16:35] <Nafai> Has anyone filed a bug about the latest metacity?  I can't use alt-space to bring up the window menu and I get the following output in ~/.xsession-errors: http://paste.ubuntu.com/411659/
[16:35] <seb128> mclasen, didrocks is trying to look into it right now
[16:36] <seb128> mclasen, I'm wondering if it would not be easier to just do the theme install in an callback
[16:36] <seb128> or in a idle function or something
[16:37] <seb128> but that's maybe because I don't know how to debug locking issues
[16:38] <didrocks> I confirm that reverting this commit (http://git.gnome.org/browse/gnome-control-center/commit/?id=e34e6b4eebbb957107e88334faef2ed8a02d5eea) workaround the lock issue
[16:39] <seb128> shrug
[16:40] <didrocks> I still don't see why, we have one thread, not two… it's certainly a code path where a lock isn't freed before we try to get a new lock
[16:40] <mclasen> didrocks: 'the lock issue' ? are you seeing deadlocks ?
[16:41] <seb128> mclasen, our "desktop effects" is an extra tab in the same capplet, and it locks when closing the dialog displayed after wm change now
[16:41] <seb128> it being the capplet
[16:42] <didrocks> mclasen: the hang in selecting the desktop effect seems to be due to a deadlock
[16:42] <mclasen> of course, removing the locking will 'prevent' the deadlocks
[16:42] <didrocks> mclasen: it was for checking that the those locks were the one to blame there
[16:42] <didrocks> not a solution, for sure
[16:43] <mclasen> does your code ever take the gdk lock ?
[16:44] <seb128> no
[16:48] <seb128> mclasen, the code is basically the same as your desktop-effects one was some cyles ago
[16:48] <seb128> we didn't resync on what you did since but it was inspired of it
[16:48] <seb128> mclasen, we have a gtk_dialog_run() after selecting the option in the dialog
[16:49] <seb128> + a gtimeout for the default choice
[16:49] <seb128> and the capplet freezes when clicking on one of the buttons
[16:52] <chrisccoulson> if you need any help looking at this, then just let me know. i might have slightly more free cycles now ;)
[16:53] <pitti> seb128: our turn now, in case you want to join the meeting and bring up the thawing?
[16:53] <seb128> chrisccoulson, we do yes
[16:54] <seb128> neither me of didrocks have experience with those locking issues
[16:54] <seb128> pitti, ok
[16:54] <didrocks> so, removing only the gdk_threads_{enter,leave} don't fix that gdk_threads_init (); has to be removed too
[16:54] <seb128> pitti, let me know when,if I should speak up there ;-)
[16:54] <didrocks> chrisccoulson: ^ in capplets/appearance/appearance-main.c
[16:54] <pitti> seb128: the guys are just digesting my reports
[16:55] <chrisccoulson> didrocks - ok, thanks. i will take a look at that shortly and see if i can figure it out
[16:55] <didrocks> chrisccoulson: I'll just give a quick look at the path we take from your patch to see if we recall the function making the gdk_threads_init call
[16:56] <seb128> chrisccoulson, https://bugzilla.gnome.org/show_bug.cgi?id=614256 too
[16:56] <seb128> chrisccoulson, if you feel like looking at it
[16:56] <chrisccoulson> seb128 - ok, thanks :)
[17:07] <pitti> seb128: new gnome-games built, and got a nice diet :)
[17:08] <seb128> pitti, \o/
[17:10] <didrocks> bah, I don't see how gdk_thread_init() can be called twice (the first being at the capplet initialization) :/
[17:11] <didrocks> well, we have two process during the hang, maybe the second one?
[17:16] <seb128> didrocks, want a change from that while chrisccoulson look at it?
[17:16] <seb128> didrocks, you can do the empathy update if you want ;-)
[17:16] <didrocks> seb128: yeah, at least, I will have the impression to do something useful :)
[17:16] <didrocks> seb128: ok, on it!
[17:16] <pitti> bryceh: there are still three beta-2 WIs left on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-multitouch -- do you know whether they are on track?
[17:18] <pitti> four, actually; I moved them to final
[17:38] <pitti> good night and nice weekend everyone!
[17:39]  * pitti goes to prepare for his wife moving to Munich tomorrow for her summer internship
[17:41] <seb128> pitti, same, enjoy!
[17:42] <seb128> pitti, oh, good luck and say hello to her too ;-)
[17:42] <pitti> will do
[17:48] <didrocks> pitti: enjoy your week-end!
[17:51] <didrocks> grr, empathy code changed a lot and that's the second patch that doesn't apply at all
[17:52] <seb128> :-(
[17:52] <seb128> didrocks, I didn't know that when I gave you the update, sorry about it
[17:53] <didrocks> seb128: no pb, I just try to not break everything but as I don't really know the notification and indicator patches, I'll probably ask for a double check
[17:59] <seb128> pedro_, bug #559205 or similar are probably users who uninstalled compiz by dist-upgrading earlier today when it was not installable
[18:00] <pedro_> seb128, okay, will check that with the reporters, thanks!
[18:01] <didrocks> the NotificationData structure has been removed and we use it quite heavily in our patch
[18:01] <seb128> didrocks, check with cassidy or kenvandine if they have an hint maybe there?
[18:01] <didrocks> right
[18:02] <seb128> cassidy, not nice to do architectural changes in stable updates :p
[18:02] <mclasen> seb128: well, thats what you sign up for when you patch the world...
[18:02] <seb128> mclasen, right ;-)
[18:03] <didrocks> cassidy: kenvandine: empathy 2.30.0.1 removed NotificationData which is heavily used in both our indicator and notification patch. What do you think? Should we reintroduce them (commit db7ff361a82a72d0bcef94c82877ffc1e783e8ee in upstream git)?
[18:03] <seb128> we tried to get that change upstream but everybody disagrees on how compiz should be actived or not etc
[18:03] <seb128> mclasen, oh, speaking about the empathy change? my note was about the desktop effect change
[18:04] <didrocks> well, let's do something easy now. Updating metacity :)
[18:05] <Nafai> didrocks: Hopefully it will fix the bug I found this morning! :)
[18:05] <didrocks> Nafai: right clicking on the window bar? for some users, that crashes
[18:05] <chrisccoulson> hmmmm, my buttons have re-ordered themselves since i updated today :-/
[18:05] <Nafai> didrocks: no, alt-space no longer works
[18:06] <didrocks> Nafai: didn't saw that in upstream git
[18:06] <chrisccoulson> that might explain why i keep closing windows accidentally when i try to maximise them
[18:06] <Nafai> http://paste.ubuntu.com/411659/ <- I get this in ~/.xsession-errors
[18:06] <didrocks> Nafai: yeah, it's related so
[18:08] <seb128> chrisccoulson, right, theme updates, close in the corner is what lucid will use
[18:11] <Nafai> lunching
[18:15] <kenvandine> didrocks, eek
[18:17] <didrocks> kenvandine: well, you know this patch more than I, let's wait for cassidy reply?
[18:18] <kenvandine> i wonder why they removed it
[18:18]  * kenvandine is cloning
[18:22] <kenvandine> didrocks, it might not be a big deal, i'll look at it after lunch
[18:22]  * kenvandine just uploaded fix for the gwibber first run bug... whew
[18:30]  * kenvandine runs out to lunch
[18:46] <didrocks> kenvandine: enjoy
[18:46] <didrocks> taking my dinner now
[18:49] <seb128> dinner!
[19:09] <alphaelectric> Hi there
[20:57] <seb128> weekend now, have fun everybody
[20:57] <didrocks> have a good week-end seb128!
[20:57] <seb128> didrocks, thanks, you too!
[21:15] <kenvandine> didrocks, i have updated the patch for empathy
[21:15] <didrocks> kenvandine: sweet, what did you do?
[21:15] <kenvandine> didrocks, gonna do some testing before upload though
[21:15] <kenvandine> dropped all the NotificationData stuff
[21:15] <kenvandine> it wasn't that bad
[21:16] <didrocks> kenvandine: so, no more NotificationData? it wasn't used?
[21:16] <kenvandine> not really
[21:16] <kenvandine> we were using it to get references to EmpathyChat
[21:16] <kenvandine> but we don't need to
[21:16] <kenvandine> and now we don't have to free as much stuff
[21:17] <kenvandine> so probably better
[21:17] <didrocks> what is the EmpathyChat object?
[21:17] <didrocks> (sorry, not familiar with that stuff)
[21:17] <kenvandine> the reference to the chat
[21:17] <kenvandine> like which chat to raise
[21:17] <kenvandine> etc
[21:18] <kenvandine> so a couple places i had to change args from cb_data->chat to chat
[21:18] <didrocks> and so, the indicator used that to be able to raise the right chat window?
[21:18] <kenvandine> yeah
[21:18] <didrocks> oh, you still have the reference so
[21:18] <kenvandine> yeah
[21:18] <kenvandine> i don't think it used to
[21:18] <kenvandine> had to get it from NotificationData
[21:19] <kenvandine> but that seems to have been ported
[21:19] <didrocks> understood, sweet :)
[21:19] <kenvandine> the indicator stuff all just piggy backs off notifications
[21:20] <didrocks> right, I saw that. It's just difficult to dive into this if you don't have any reference :/
[21:50] <crimsun> pitti: the delaying of PA startup has revealed a race in two PA modules that now result in some desktop sessions falling back to a dummy/null sink, i.e., inaudible audio by default. I'm unsure whether to milestone it, but it is a rather poor user experience.
[21:50] <chrisccoulson> didrocks - ok, this gnome-appearance-properties locking is giving me a headache ;)
[21:50] <crimsun> pitti: this is bug 557421
[21:50] <chrisccoulson> i won't sleep now until it is fixed though
[21:50] <didrocks> chrisccoulson: please, take some sleep :)
[21:51] <didrocks> (I will have some soon ^^)
[21:51] <chrisccoulson> didrocks, i can't now i've started looking at it ;)
[21:51] <didrocks> chrisccoulson: I'm particularly interested in the way you will debug/solve this, as a case study :)
[21:51] <didrocks> chrisccoulson: you see, there are two process?
[21:51] <chrisccoulson> didrocks, i haven't figured out the best way of debugging it yet, but when i have, i will let you know ;)
[21:52] <didrocks> sweet :)
[21:52] <chrisccoulson> didrocks, there's 2 processes?
[21:52] <chrisccoulson> i see a single thread in gdb
[21:52] <didrocks> chrisccoulson: yeah, when it hangs
[21:52] <didrocks> chrisccoulson: so do I
[21:52] <didrocks> but ps aux | grep gnome-app
[21:52] <didrocks> you will see two processes, one being the son of the other
[21:53] <chrisccoulson> 1 second, i will just break on fork
[21:53] <didrocks> (I tried to add some g_printf() before the gdk_thread_init())
[21:53] <chrisccoulson> ah
[21:53] <didrocks> but it seems just to be used by the parent process on window initialization
[21:53] <chrisccoulson> one process is for the thumbnailing
[21:54] <didrocks> ah, ok
[21:54] <didrocks> how did you see that?
[21:54] <chrisccoulson> didrocks - http://paste.ubuntu.com/411799/
[21:54] <chrisccoulson> that's a guess anyway ;)
[21:55] <chrisccoulson> if it doesn't exec() another binary, then it will keep the same process name
[21:55] <didrocks> ok, "catch fork", right?
[21:55] <chrisccoulson> break fork
[21:56] <didrocks> never new the difference :)
[21:56] <didrocks> knew*
[21:56] <chrisccoulson> oh, i'm not sure if there's a difference either ;)
[21:56] <chrisccoulson> i never used catch before
[21:56] <didrocks> there are "catchpoints" and "breakpoint"
[21:57] <didrocks> "A catchpoint is another special breakpoint that stops your program when a certain kind of event occurs"
[21:57] <Nafai> Hi guys, I'm back around if anyone needs me.  Kind of was ill for a bit during lunch.
[21:57] <didrocks> seems like a breakpoint to me :)
[21:58] <chrisccoulson> didrocks, yeah, it seems similar
[21:58] <kenvandine> didrocks, uploaded....
[21:58]  * kenvandine heads out for a bit
[21:58] <kenvandine> :)
[21:58] <chrisccoulson> hey Nafai, i hope you feel better now ;)
[21:58] <didrocks> kenvandine: sweet :)
[21:58] <Nafai> yeah, I do, thanks
[21:58] <didrocks> Nafai: hey, time for week-end to me. If you don't know what to do, you can still read some triaging guide stuff and look at incoming bugs on UNE ;)
[21:59] <didrocks> me -> tired -> week-end -> will connect a little this week-end
[21:59] <didrocks> chrisccoulson: think to sleep ;)
[21:59] <Nafai> thanks, I might do that a bit.  I've got a bug to look at in the meantime
[21:59] <Nafai> have a great weekend
[21:59] <didrocks> thanks Nafai  ;) you too!
[22:00] <chrisccoulson> didrocks - i'm trying to figure out if i can get gdb to break when this particular mutex is locked/unlocked
[22:00] <didrocks> chrisccoulson: in fact, it should be the same, you can't break on "event"
[22:00] <didrocks> so, I guess it's an alias for those case
[22:00] <chrisccoulson> i'm not too sure how to do that yet, but i'm having a go with watch / rwatch on various memory locations at the moment
[22:01] <didrocks> chrisccoulson: in fact, if you want it to hang, you can even removed the locks, just keep gdk_thread_init()
[22:01] <didrocks> remove*
[22:05] <chrisccoulson> setting a watch on mutex->__data.__lock seems to be what i want to get gdb to break at the right place
[22:25] <chrisccoulson> didrocks - ok, now i've seen it with my own eyes in GDB (it attempts to lock the mutex when it's already locked)
[22:25] <chrisccoulson> i just need to figure out how it happens now :-/
[22:25] <chrisccoulson> it doesn't look like there's any other threads involved
[22:27] <chrisccoulson> ok, time for some ice cream, i will carry on debugging that in a bit
[23:41] <chrisccoulson> didrocks - fixed it :-)
[23:45] <chrisccoulson> didrocks - it seems that gtk_dialog_run needs to be guarded by a gdk_threads_enter/gdk_threads_leave (just like gtk_main, which also runs a main loop)
[23:46] <chrisccoulson> anyway, i really am going to get some food this time :)
[23:49] <mclasen> any gtk call needs to be protected by gdk_threads_enter