[00:47] <robert_ancell> jasoncwarner_, beware the dreaded rls-p-tracking tag :)
[00:50] <robert_ancell> RAOF, did you have any luck with the u-g background corruption on exit issue?  If you're not working on it I'm going to have a look at that today
[00:51] <RAOF> robert_ancell: I've got a bunch of things which infuriatingly *don't* work.
[00:52] <robert_ancell> RAOF, do you know if anything has changed?  This all used to work
[00:52] <RAOF> Did it?  At what point did it work?
[00:52] <robert_ancell> last cycle (at least for me)
[00:53] <robert_ancell> my current machine shows a black screen between the greeter and the session, which is I assume my driver clearing the memory where others don't
[00:53] <robert_ancell> but it used to switch to the bg and then get replaced by the session
[00:54] <robert_ancell> RAOF, did you try XCopyArea from the window to the root window?
[00:54] <RAOF> robert_ancell: I did, yes.
[00:54] <RAOF> robert_ancell: Did it work on *all* drivers last cycle?
[00:54] <robert_ancell> I can't say for sure
[00:55] <RAOF> Intel still works, presumably because it's acceleration architecture works in such a way that the wrong things unity-greeter was doing did the right thing.
[00:55] <robert_ancell> there's a good chance it didn't
[00:55] <robert_ancell> if XCopyArea doesn't work that's really odd - that should be 100% safe from the X protocol point of view afaict
[00:55] <RAOF> Intel works for me.  Or, at least, worked until I started trying to fix it :)
[00:55] <robert_ancell> Did you dive into the GDM code and check they're not doing anything special?  The original code was based off them
[00:56] <RAOF> robert_ancell: I think my problem with XCopyArea was that I did it before the root window was exposed; thus, it disappeared.
[00:56] <robert_ancell> actually you'd have to do an XCopyArea to a pixmap and set that as the root window background I supose - windows don't remember their content in X
[00:57] <RAOF> Hm.  That could work.
[00:58] <RAOF> Alternatively, I could unmap unity-greeter's window and then XCopyArea.  But that'd leave a flash, so not good.
[01:00] <robert_ancell> The implementation was just to draw into the pixmap and set that as the background - you really *shouldn't* need to XCopyArea
[01:01] <RAOF> Yeah.
[01:01] <RAOF> Although, as mentioned in the bug, you should do that after you've actually *drawn* to the pixmap :)
[01:02] <RAOF> Also, cairo doesn't guarantee that the pixmap contains anything sensible until you surface.flush() it.
[01:02] <robert_ancell> ah
[01:02] <RAOF> Doing both of these things doesn't fix it, however.
[01:02] <robert_ancell> also, doesn't Cairo use Surfaces instead of Pixmaps internally?  So perhaps they have different behaviour to Pixmaps when the clients exit?
[01:02] <robert_ancell> Does each driver essentially implement XRENDER themselves?
[01:03] <RAOF> No; the acceleration architecture does that.
[01:03] <robert_ancell> that's common code in X.org?
[01:03] <robert_ancell> and then the drivers just have buffers etc
[01:03] <RAOF> Which would be my guess as to why Intel works, and radeon/nouveau do not; Intel's using their own home-brewed UXA acceleration arch, radeon/nouveau are using the in-server EXA implementation.
[01:04] <robert_ancell> ah
[01:05] <RAOF> Where's the gdm code that does this?
[01:07]  * robert_ancell hunts around
[01:07] <RAOF> Looks to be in gdm-slave.c
[01:08] <robert_ancell> it's probably based off gui/simple-greeter/greeter-main.c
[01:09] <robert_ancell> but it may actually be using gnome-background from libgnome (?)
[01:10] <robert_ancell> RAOF, yes, gnome-desktop/libgnome-desktop/gnome-bg.c
[01:11] <robert_ancell> gnome_bg_set_root_pixmap_id
[01:12] <robert_ancell> so it might work better if we have a separate process keeping the root window alive?
[01:15] <RAOF> Maybe?
[01:15] <RAOF> I thought the root window hung around, though.
[02:16] <desrt> pitti wins at being german
[02:16] <desrt> 1) make a claim using a numbers like 99.99995%
[02:16] <desrt> 2) cite a footnote that explains why this calculation is the actual accurate value
[02:29] <mterry> robert_ancell, ping about bug 880104
[02:29] <ubot2`> Launchpad bug 880104 in lightdm "Using pam_group results in: pam_group(lightdm:setcred): unable to set the group membership for user: operation not permitted" [Medium,Confirmed] https://launchpad.net/bugs/880104
[02:29] <mterry> robert_ancell, it's because of the call to initgroups, which wipes the group list
[02:30] <mterry> robert_ancell, I think we need something smarter like a call to getgroups, merge with existing groups, and then a call to setgroups or something like that.  I'm about to go to bed, and will deal with it tomorrow unless you're feeling frisky
[02:30] <robert_ancell> mterry, ok, cheers.  I thought it might be something like that
[02:31] <robert_ancell> It might be that the groups are set after authenticate but before pam_open_session.  So we just need to do it after the authenticate (i.e. once we know what user we have)
[02:33] <robert_ancell> yeah, it's done in pam_setcred, so we just need to move the setgroups
[02:35] <mterry> robert_ancell, you mean move initgroups to before pam_setcred?
[02:35] <robert_ancell> yes
[02:35] <mterry> robert_ancell, easy enough
[02:36] <robert_ancell> I'm guessing that the group memberships doesn't affect any things that a root process wants to do
[02:36] <robert_ancell> so the only thing we have to do last is drop privileges
[02:36] <mterry> Do group memberships matter for root?
[02:41] <robert_ancell> mterry, I'll work up a patch for it
[02:41] <mterry> OK
[03:14] <desrt> who is reponsible for gnome-language-selector?
[03:37] <RAOF> Ok.  I can definitely draw *something* to the root window's backing pixmap, and it works.
[03:46] <RAOF> Aha.  It *is* setting the root backing pixmap; it's just setting it to garbage.
[03:52] <RAOF> Huh.  We create the pixmap, but nothing ever draws to it.
[04:02] <RAOF> Vala needs a debugger ☹
[04:06] <desrt> RAOF: gdb?
[04:07] <RAOF> Yeah, but then you need to read vala's c output to make sense.
[04:07] <desrt> compile with -g
[04:07] <desrt> then you get to read vala code instead
[04:08] <RAOF> Ooh, that'd be much more fun!
[04:09] <RAOF> Hm.  ‘[+20.72s] CRITICAL: gtk_widget_draw: assertion `!widget->priv->alloc_needed' failed’ is why lightdm is drawing garbage to the root window.
[04:10] <desrt> lightdm does its image loading in threads
[04:10] <desrt> i wonder if it's doing more than that in the thread accidentally
[04:10] <RAOF> Well, it's already successfully drawn the background.
[04:11] <RAOF> This is just trying to draw the background on a different cairo context.
[04:11] <RAOF> desrt: What can cause that assertion to fail?
[04:12]  * desrt wonders how it happens that sometimes the amd64 builders get so far behind and other times it's the i386 ones
[04:12] <desrt> RAOF: forcing a draw when a size invalidation has been scheduled
[04:12] <desrt> could resolution changes be involved?
[04:13] <RAOF> Well, it's drawing on a different-sized surface.
[04:13] <RAOF> A framebuffer-sized pixmap, rather than whatever GTK normally thinks its drawing on.
[04:14] <desrt> this is unity-greeter?
[04:14] <RAOF> Yu.
[04:14] <RAOF> It's (now) doing everything to set the root window's backing pixmap, except actually drawing to it :)
[04:15] <desrt> why the hell is it being done this way?
[04:16] <RAOF> I think because it's roughly what gnome-desktop does.
[04:17] <desrt> it doesn't punt through a widget
[04:17] <desrt> .draw() is not a pure vfunc, you must understand
[04:17] <desrt> calling background.draw() does NOT result in calling the draw() function on the Background class
[04:17] <desrt> it results in calling gtk_widget_draw() on the background instance
[04:17] <desrt> which will so some stuff
[04:18] <desrt> maybe calling that function will be in there somewhere
[04:18] <desrt> or maybe throwing an assert
[04:19] <desrt> are you trying to get the login box as part of what you are drawing?
[04:19] <desrt> or only the background?
[04:20] <RAOF> Only the background.
[04:20] <RAOF> Yeah, I know it's calling gtk_widget_draw.
[04:20] <desrt> so that draw function chains up to the GtkFixed draw
[04:20]  * RAOF has been hitting the C code, as unity-greeter doesn't (by default) build with -g
[04:20] <desrt> which will draw the container children -- like the login box
[04:20] <RAOF> Hah.
[04:21] <desrt> probably you'd rather call draw_full() directly
[04:21] <desrt> that way you can skip the trip through gtk
[04:21] <RAOF> Ok.  So, it's entirely the wrong thing to do, and the only reason it wasn't obvious is that (a) GTK critical assertions aren't fatal, and (b) the Intel driver accidentally used the right contents for the uninitialised pixmap.
[04:25] <RAOF> Win!
[04:25] <desrt> score
[04:25] <desrt> time for me to go to bed, then :)
[04:25] <RAOF> Sweet dreams!
[04:25] <desrt> uh... you too.
[04:25] <desrt> :)
[04:27] <jasoncwarner_> hey robert_ancell , I mentioned to RAOF , but a black screen is better than the corruption that we are seeing, so that might be step 1. step 2 would be to fix the corruption. Step 3 is probably ??? and step 4 is our friend profit
[04:27] <RAOF> jasoncwarner_: We've just hit step 2.
[04:28] <robert_ancell> RAOF, \o/
[04:28] <jasoncwarner_> RAOF: !!!
[04:28] <RAOF> It'll now be just as fast to fix it as to remove the transition.
[04:28] <RAOF> Well, at least, if my xnest testing is accurate :)
[04:30] <RAOF> robert_ancell: I'm *amazed* that code works on Intel.  It's wrong in so many ways :)
[04:30] <robert_ancell> RAOF, which code?
[04:30] <RAOF> The code for setting the root window background pixmap.
[04:31] <robert_ancell> what's the main way it's wrong?
[04:31] <RAOF> It never draws to the pixmap.
[04:31] <RAOF> Well, that's the *final* reason it's wrong :)
[04:31] <robert_ancell> that one seems quite major
[04:32] <robert_ancell> what's with the drivers allowing pixmaps with uninitialized memory?
[04:32] <RAOF> Performance optimisation?
[04:32] <RAOF> What's with Intel *accidentally* picking up the right pixmap? :)
[04:32] <robert_ancell> so any X program can just allocate a pixmap and read from it?
[04:32] <RAOF> Yeah, totally.
[04:32] <robert_ancell> i.e. reading your video memory
[04:33] <RAOF> Not sure about that; there may be guards on the reading.
[04:33] <RAOF> Anyway, I need to go off to an appointment now.  I'll come back and prepare a unity-greeter merge.
[04:34] <robert_ancell> nice
[05:59] <robert_ancell> jasoncwarner_, what are these rls-p-tracking magic tags?
[06:16] <didrocks> good morning
[06:26] <didrocks> hey jibel
[06:27] <didrocks> jibel: with the QA lab shutted down, I think that it's up again (can connect to wazn), but no vm running on it
[07:20] <RAOF> Bah, Robert's gone.
[07:23] <RAOF> Heh.  No mterry, etiher.
[07:44] <jibel> didrocks, good morning
[07:44] <jibel> didrocks, on it
[07:45] <didrocks> thanks :)
[07:45] <RAOF> Huh.  The latest unity-greeter's not in bzr.
[07:59] <pitti> cjwatson, stgraber: you could also just get the last two values from the result, like call()[-2:]
[07:59] <pitti> cjwatson: your's also looks good
[08:00] <pitti> seiflotfy: right, bug report with test case appreciated
[08:02] <pitti> desrt: I was actually incorrect -- that number assumed that 50% of users couldn't find it, but I failed to neglect that
[08:02] <pitti> that's what you get when you write this stuff in the middle of the night :) But it didn't let me sleep, so I had to get up and off my chest
[08:05] <pitti> didrocks, jasoncwarner_: I think today I'll actually take the sick day I put in yesterday (but then did not actually get to not working)
[08:05] <pitti> fever, sleepless night, feeling horrible, etc.
[08:05] <didrocks> pitti: oh :( take care Martin
[08:06] <didrocks> (that's why you commented at 2AM… I was afraid it was due to the dentist operation…)
[08:06]  * didrocks hugs pitti
[08:08] <pitti> didrocks: well, both -- I woke up due to fever, and then my brain didn't let me sleep again
[08:08] <pitti> I didn't have any fever last time
[08:09] <didrocks> for my first tooth, I had some, then none for the 3 followings, it's pretty random. take some rest and try to sleep :)
[08:15] <xclaesse> hmm, ssh is asking my password again: Enter passphrase for key '/home/xclaesse/.ssh/id_rsa'
[08:16] <xclaesse> that's something that breaks times to times with ubuntu updates...
[08:41] <ricotz> xclaesse, might be a problem with gnome-keyring which isnt running properly
[08:43] <xclaesse> ricotz, hm, ok...
[08:44] <xclaesse> ricotz, something else, do you know why there are no gdm 3.2/3.4 package, not even on gnome3 ppa?
[08:44] <xclaesse> is it that broken?
[08:44] <ricotz> .xsession-errors might tell you something here
[08:45] <xclaesse> ricotz, I see nothing related to that in .xsession-errors :(
[08:45] <ricotz> yeah, unfortunately gdm 3.2+ has its problems
[08:46] <tjaalton> is there a way to disable hud?
[08:47] <xclaesse> ricotz, ok, thanks
[08:47] <tjaalton> ok got it
[08:47] <ricotz> xclaesse, the first few lines mentioning GNOME_KEYRING_CONTROL are important here
[08:48] <xclaesse> ricotz, I have that: http://fpaste.org/hhvE/
[08:48] <ricotz> xclaesse, if they dont refer to the same tmp folder something goes wrong
[08:50] <ricotz> xclaesse, is this running the precise version or the gnome3-ppa one?
[08:50] <ricotz> although this output isnt looking normal
[08:51] <ricotz> but i might be mistaken
[08:51] <ricotz> xclaesse, is the gpg-agent working for you?
[08:51] <ricotz> seb128, hi
[08:51] <seb128> hey
[08:51] <ricotz> how are you?
[08:52] <seb128> good thanks, how are you?
[08:52] <didrocks> salut seb128, la forme?
[08:52] <ricotz> seb128, fine ;)
[08:52] <seb128> hey didrocks, yes! you?
[08:52] <didrocks> ça va ;)
[08:52] <ricotz> seb128, there is a problem with your rhythmbox 2.96 upload :\
[08:53] <seb128> ricotz, which one?
[08:53] <seb128> didrocks, I was better before checking -changes :p
[08:53] <ricotz> seb128, ubuntu1
[08:53] <xclaesse> ricotz, how can I know if it works? :p
[08:53] <seb128> ricotz, what problem I mean
[08:53]  * xclaesse uses only ssh keys
[08:53] <ricotz> seb128, oh ;), you dropped some important *.install files
[08:53] <ricotz>   rhythmbox-oneiric/rhythmbox-mozilla.install
[08:53] <ricotz>   rhythmbox-oneiric/rhythmbox-plugin-magnatune.install
[08:53] <ricotz>   rhythmbox-oneiric/rhythmbox-plugin-visualizer.install
[08:53] <ricotz>   rhythmbox-oneiric/rhythmbox-plugin-zeitgeist.install
[08:54] <didrocks> seb128: what do you mean?
[08:54] <seb128> ricotz, I didn't "drop" anything, I bet somebody didn't commit properly to the vcs when doing the previous update
[08:54] <seb128> didrocks, I was hoping you or pitti would have tackled some of the GNOME updates, I'm not looking toward another day of tarball updates ;-)
[08:54] <ricotz> seb128, no, the vcs contains these file, but the upload itself doesnt
[08:55] <didrocks> seb128: I'll do some, but I told you that with the last minutes g-c-c changes, I'm not very available for this round of update :)
[08:55] <seb128> ricotz, I used bzr builddeb
[08:55] <didrocks> pitti is sick and won't be here
[08:55] <seb128> didrocks, ok, no worry ;-)
[08:56] <ricotz> seb128, hmm, anyway, could you look at https://launchpad.net/ubuntu/+archive/primary/+files/rhythmbox_2.96-0ubuntu1.debian.tar.gz
[08:56] <seb128> ricotz, I will get it fixed, thanks for pointing it
[08:56] <ricotz> seb128, ok
[08:57] <seb128> ricotz, but
[08:57] <ricotz> (seb128, i just noticed it today while doing a snapshot)
[08:57] <seb128> ricotz, http://bazaar.launchpad.net/~ubuntu-desktop/rhythmbox/ubuntu/files
[08:57] <seb128> those files are not in the vcs
[08:57] <seb128> http://bazaar.launchpad.net/~ubuntu-desktop/rhythmbox/ubuntu/revision/160
[08:57] <ricotz> oh :\, i see
[08:58] <seb128> they were not added when pitti,dobey did the update
[08:58] <seb128> they probably forgot to bzr add them
[08:58] <ricotz> alright
[08:58] <seb128> I take only half the blame :p
[08:58] <seb128> but thanks for pointing it!
[08:58] <ricotz> ;)
[08:59] <BigWhale> Good Morning.
[08:59] <seb128> hey BigWhale
[09:00] <ricotz> xclaesse, hmm, so ubuntu or gnome3-ppa version?
[09:01] <xclaesse> ricotz, oh it's the ppa one actually, that may explain it...
[09:02] <ricotz> xclaesse, ok, i am running the ppa version too here, but without a problem
[09:02] <ricotz> but with a gnome-shell sesssion which might matter
[09:02] <xclaesse> ricotz, hm, I see there is an update of g-k in your ppa
[09:02] <xclaesse> maybe that will fix it :)
[09:03] <ricotz> there were just translation fixes in it
[09:03] <xclaesse> ricotz, I have a gnome-shell session as well ;)
[09:03] <ricotz> but of course there a newer version of the other g-k part too which arent there yet
[09:30] <Sweetshark> ricotz: any unforeseeable trouble with the backports or is everything good?
[09:30] <Sweetshark> pitti: no team meeting today?
[09:30] <ricotz> Sweetshark, seems fine so far, there is no build ready for testing yet though -- building in ppa:ricotz/ppa
[09:31] <ricotz> seb128, do you mind sponsoring http://people.ubuntu.com/~ricotz/sponsor/cheese_3.3.90-0ubuntu3_3.3.90-0ubuntu4.debdiff ?
[09:32] <seb128> ricotz, can do, you didn't want to do the .92 update while you are at it? ;-)
[09:33] <Sweetshark> ricotz: great. no hurry, just wanted to know if there is any trouble ;)
[09:33] <ricotz> seb128, hmm, right, i just wanted to get rid of the annoying conflict ;), so i guess please upload u4 for now
[09:33] <seb128> ricotz, ok
[09:34] <ricotz> Sweetshark, not yet ;) lucid amd64 built :P
[09:36] <ricotz> Sweetshark, the problem will be  the oneiric amd64 while the ppa builder might run out of space, natty amd64 got one which will work
[11:20] <mpt> cnd, I think you broke my touchpad :-)
[11:33] <mpt> (reported bug 960108)
[11:33] <ubot2`> Launchpad bug 960108 in xserver-xorg-input-synaptics "Right-click simulation (two-finger hold+click) no longer works on MacBook touchpad" [Undecided,New] https://launchpad.net/bugs/960108
[11:56] <tkamppeter> pitti, hi
[12:02] <seb128> tkamppeter, he's unwell and not working today
[12:05] <chrisccoulson_> lol, this is brilliant: https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/d30ae1c692ff53c3?pli=1
[12:06] <tkamppeter> seb128, OK, so I will override Debian for the cups and cups-filters uploads to get them in for some testing before beta2.
[12:07] <seb128> tkamppeter, that's fine, I guess you can sync them later once pitti uploads to Debian
[12:13] <tkamppeter> seb128, thanks.
[12:14] <seb128> yw
[12:21] <BigWhale> Is precise switching to 3.3 kernel or we're 'stuck' with 3.2?
[12:22] <didrocks> this is rather a question for #ubuntu-kernel
[12:23] <jbicha> but the answer is 3.2 with some bug fixes from the newer versions
[12:24] <didrocks> well, with the new maintenance model for LTS, we will get the support from newer hw for 2 years
[12:24] <didrocks> but again, not something for that channel :)
[12:27] <BigWhale> Thanks. You guys are all full of <3. Happy. :)
[12:30] <tjaalton> uh, so disabling hud by disabling the shortcut breaks any shortcut needing alt?
[12:39] <seb128> tjaalton, bug #945816
[12:39] <ubot2`> Launchpad bug 945816 in compiz "[regression] Changing the HUD shortcut disables all Alt-based combinations. And changing the Dash shortcut disables all Super-based shortcuts." [Medium,Fix committed] https://launchpad.net/bugs/945816
[12:39] <tjaalton> seb128: thank you
[12:40] <seb128> tjaalton, yw
[12:40] <seb128> tjaalton, what an idea to want to disable the hud :p
[12:40] <tjaalton> seb128: yeah, who would've thought ;)
[12:41] <tjaalton> one more reason for some to install ccsm :/
[12:41] <seb128> tjaalton, we have an increasing number of bugs because people turn off stuff and hit untested configs and bugs
[12:42] <tjaalton> the options must be hidden harder then :)
[12:42] <seb128> tjaalton, it's making me reconsider on options, I start leaning toward the reducing them
[12:42] <seb128> tjaalton, well I think we should stop supporting people trying to use unity without i.e hud or appmenu
[12:42] <seb128> like either you use unity as designed or you don't like it and use something else
[12:42] <seb128> hopefully unity is going enough that you use it ;-)
[12:43] <tjaalton> hud is constantly getting on the way though
[12:43] <seb128> still? the tapping issues for resolved in 5.6 we didn't get a lot of complains recently
[12:44] <tjaalton> well it's usually my fingers not keeping up, so while it technically should work it's not always so good for me :)
[12:44] <tjaalton> hard to explain
[12:44] <tjaalton> btw, objections on adding intuos5 support in libwacom?
[12:45] <tjaalton> i'm thinking of getting one, might replace my mouse..
[12:45] <seb128> tjaalton, no idea what is untuos5 ;-)
[12:45] <tjaalton> wacom
[12:45] <tjaalton> with multitouch
[12:45] <seb128> well, you are the maintainer, your call, I've no option on that ;-)
[12:45] <tjaalton> ok, it's a new "feature" though it just adds the device definitions..
[12:46] <tjaalton> needs driver support too of course, that's FFe material I guess
[12:46] <seb128> do it, it's easy enough to revert if that creates really issues
[12:46] <tjaalton> right
[12:46] <seb128> yeah, the driver side is likely a ffe
[12:47] <BigWhale> just for the record... indicator-weather is driving me crazy :>
[12:47] <tjaalton> BigWhale: you're not the only one
[12:48] <seb128> what's wrong with it?
[12:48] <tjaalton> crashes after a few hours of use
[12:48] <BigWhale> constantly crashing
[12:48] <tjaalton> been like that for a year
[12:48] <tjaalton> ie. from the start
[12:51] <seb128> luckily it's opensource so we can fix it ;-)
[12:51] <tjaalton> right
[12:52] <tjaalton> i did try to look at it once but then got other stuff to work on
[12:52] <BigWhale> I probably will...
[12:57] <desrt> good morning
[12:57] <mterry> desrt, morning!
[12:58] <Sweetshark> pitti: ricotz rightfully said we should sync openclipart from debian. would you do that?
[13:00] <ricotz> Sweetshark, unfortunately, pitti isnt around today
[13:00] <Sweetshark> ah, meh
[13:01] <ricotz> maybe didrocks likes to do it ^
[13:04] <didrocks> Sweetshark: it's a sync? openclipart source package, right?
[13:09] <Sweetshark> didrocks: right
[13:09] <desrt> seb128: any new hud explosions since last night?
[13:09] <desrt> or am i in the clear for a change? :)
[13:10] <seb128> desrt, no but I just uploaded your new version today
[13:10] <desrt> oh
[13:10] <desrt> i thought you did that yesterday
[13:10] <desrt> i'll ask you the same question tomorrow, then :)
[13:10] <seb128> desrt, it slipped out due to GNOME 3.3.92 busyness ;-)
[13:10] <desrt> ack.
[13:10] <seb128> desrt, works fine for me in any case
[13:11]  * desrt has learnt to expect exotic races when dbusmenu is involved :)
[13:11] <desrt> just because it works for you doesn't mean there aren't edge cases to iron out
[13:11] <seb128> desrt,  you still have some hud bugs assigned though, the DoS stuff and the stripping
[13:11] <desrt> indeed
[13:11] <desrt> the dbus message work as well
[13:11] <desrt> most of what's left there is work in dbusmenu, though
[13:17] <seb128> jbicha, hey
[13:18] <didrocks> phew, the g-c-c changes are not fun with all the mirror screen, dragging bar, delayed apply… and unity-2d/3d not using the same key
[13:19] <seb128> didrocks, :-(
[13:19] <seb128> didrocks, do you need help?
[13:19] <desrt> pitti: hey.  what's the story with the language selector panel?
[13:19] <seb128> desrt, he's off sick
[13:19] <desrt> ah
[13:19] <didrocks> seb128: no, just taking time
[13:19] <didrocks> but thanks :)
[13:19] <seb128> desrt, what about the language selector?
[13:19] <seb128> didrocks, yw ;-)
[13:19] <desrt> seb128: when i click the icon there's a bit of a delay and then a new window opens
[13:20] <seb128> desrt, right, rodrigo was supposed to improve the upstream region panel enough so we use that
[13:20] <seb128> desrt, that was before rodrigo left Canonical though
[13:20] <desrt> i see
[13:20] <seb128> desrt, nobody had time to pick it up this cycle
[13:20] <seb128> so next cycle
[13:20] <desrt> fair enough
[13:25] <desrt> seb128: is there any gconf user left in g-s-d after the keybindings?
[13:25] <seb128> desrt, yes
[13:25] <desrt> what else?
[13:25] <seb128> desrt, the gsettings to gconf glue (I was pondering turning it off by default on precise though)
[13:25] <desrt> ah.  right.
[13:26] <seb128> like the code which replicates proxy settings etc to gconf
[13:26] <desrt> it almost seems like we could abuse that code to deal with the keybindings
[13:26] <seb128> desrt, it feels like stacking hacks on hacks
[13:26] <desrt> i disagree....
[13:26] <desrt> i was going to patch the control centre in a somewhat similar way
[13:27] <desrt> for the wm keys, have a map of gsettings keys and their corresponding 'old' locations in gconf
[13:27] <desrt> as a way of keeping the surface area of the patch as small as possible
[13:28] <seb128> desrt, so looking at g-s-d I think those keys are only multimedia ones, so no compiz interaction, so dropping that patch should be fine if g-c-c writes to gsettings for the corresponding entries
[13:29] <seb128> desrt, is that your understanding as well?
[13:29] <desrt> yes
[13:29] <desrt> but i took a look at g-c-c as well last night
[13:29] <seb128> desrt, so we basically just need a way to make sure the g-c-c changes to wm keys land to gconf for compiz?
[13:29] <desrt> the way it handles things i'm not so sure that it will be easy to cleanly separate like that
[13:29] <desrt> ie: separate gconf vs. gsettings
[13:29] <desrt> so i was thinking that the best way to do that patch would be a list of gsettings keys and a mapping to gconf locations
[13:29] <seb128> desrt, can't we just write wm to both?
[13:29] <desrt> and just do it like that
[13:30] <desrt> yes.  that's the plan
[13:30] <dobey> seb128: bad pitti! :)
[13:30] <desrt> when it sees a write to gsettings, it will do the appropriate gconf write
[13:30] <seb128> dobey, bad you to not do a merge request I guess? ;-)
[13:30] <seb128> desrt, sounds good to me
[13:30] <desrt> seb128: so my next logic is that we already have the migration code in g-s-d....
[13:31] <desrt> seb128: if you tell me we could rip that out entirely then i think we should do it
[13:31] <seb128> desrt, do you want to try dropping both patches and see if things just work?
[13:31] <dobey> seb128: i did do a merge proposal for it
[13:31] <desrt> seb128: i guess WM keybindings would stop working :)
[13:31] <seb128> desrt, why?
[13:31] <desrt> (for compiz)
[13:31] <seb128> desrt, the gsettings<->gconf glue should do the replication
[13:31] <desrt> it replicates keybindings?
[13:32] <seb128> desrt, you don't want to know what that code does
[13:32] <desrt> okay :)
[13:32] <seb128> desrt, I will tell you anyway :p
[13:32] <desrt> well, let me check something
[13:32] <seb128> desrt, it parses all the installed .convert to get the mapping
[13:32] <desrt> i have an unpatched g-c-c here
[13:32] <desrt> let me try to set some keybindings and see if they land in gconf or not
[13:32] <seb128> desrt, and use it to write any key listed there to gconf
[13:32] <desrt> uh
[13:32] <seb128> desrt, so any gsettings key in a .convert will be written to gconf
[13:32] <desrt> the one-time GConf conversion files, you mean?
[13:32] <seb128> desrt, yes
[13:33] <desrt> oi.
[13:33] <seb128> desrt, that's how it gets the mapping
[13:33] <desrt> that's.... thorough
[13:33] <desrt> and just a tiny bit INSANE
[13:33] <seb128> lol
[13:33] <seb128> I knew you would like it ;-)
[13:33] <desrt> it's ballsy
[13:33] <desrt> and somewhat effective
[13:33] <dobey> seb128: https://code.launchpad.net/~dobey/ubuntu/precise/rhythmbox/prereleases-2-95-5/+merge/96671 and those files are in the .diff :)
[13:33] <seb128> I was pondering addering a whitelist list of keys
[13:33] <hallyn> GAAAH!  STOP remapping my kbd on upgrades
[13:33] <desrt> good for days when you're in a "i don't want to have to write and maintain this huge list of shit" mood
[13:33] <dobey> hallyn: indeed
[13:34] <seb128> hallyn, we don't do that
[13:34] <dobey> Alt+F4 doesn't work for me under Unity any more :(
[13:34] <seb128> desrt, well I hate writting back to applications gconf tree, it's just a waste
[13:34] <seb128> dobey, wfm
[13:34] <desrt> seb128: ya.  that's totally stupid.
[13:34] <desrt> it should only be for various 'well known values'
[13:34] <desrt> things like proxy, etc
[13:35] <seb128> desrt, right, what I was just saying, I was pondering building a whilelist with a dozen of keys
[13:35] <desrt> seb128: do you also have gconf keybinding patches in metacity?
[13:35] <dobey> seb128: in a gnome-terminal winodw, i just get ";35" printed when i press it :-/
[13:35] <seb128> dobey, do you use a ppa for compiz or unity?
[13:35] <dobey> no
[13:35] <seb128> dobey, https://code.launchpad.net/~dobey/ubuntu/precise/rhythmbox/prereleases-2-95-5/+merge/96671 was buggy indeed, so both your fault and pitti's fault
[13:35] <dobey> seb128: buggy how?
[13:35] <seb128> dobey, you used the wrong vcs, so pitti had to copy stuff over by hand
[13:36] <seb128> dobey, the desktop team ppa are not lp:ubuntu they are lp:~ubuntu-desktop and debian dir only
[13:36] <seb128> dobey, i.e what is in the control file or what apt-get source or debcheckout tells you
[13:36] <dobey> bah
[13:37] <seb128> desrt, no, we just didn't update that one
[13:37] <desrt> dobey: you should do what i do.  claim ignorance and get seb to do all your future uploads for you :)
[13:37] <desrt> seb128: what happens for unity 2d, then?
[13:37] <seb128> desrt, unity-2d is using it as well which makes things harder to use
[13:37] <seb128> desrt, well, same as compiz, still using gconf
[13:37] <desrt> ohhh
[13:37] <desrt> no update = old version
[13:37] <seb128> right
[13:37] <desrt> right
[13:37] <desrt> was it just the keybinding thing?
[13:38]  * desrt can't imagine metacity has seen a lot of activity this cycle
[13:38] <seb128> yes
[13:38] <desrt> oh wow.  2.34 even.
[13:38] <seb128> desrt, so another crazy idea
[13:38] <dobey> desrt: even better, "the tools should handle it, or should at least inform me (as should the reviewer)"
[13:38] <seb128> desrt, which might be easier than what we are speaking about here
[13:38] <desrt> seb128: i like crazy ideas.  hit me.
[13:38] <desrt> seb128: particularly ones that involve less patches :D
[13:38] <dobey> why the hell does lp:ubuntu/foo not pull lp:~ubuntu-desktop/foo/blah in these cases?
[13:38] <seb128> desrt, drop the gsd patch, drop the gcc patch, cp -r keybinding-3-2 oldkeybindings
[13:39] <seb128> desrt, and ship the 3.2 panel with ShowOnlyIn=Unity
[13:39] <seb128> desrt, and the new one under shell
[13:39] <seb128> OnlyShowIn
[13:39] <seb128> desrt, i.e ship keybinding 3.2 and 3.4 as different panels
[13:39] <seb128> and tweak showin
[13:39] <seb128> desrt, so we have no patching, just shipping old and new version side to side
[13:39] <hallyn> seb128: wasn't blaming you personally :)  just some piece in the otherwise lovely ubuntu desktop.  cause, you know, that's what i'm using :)
[13:40] <desrt> seb128: back in 15.  local 'situation' :)
[13:40] <seb128> desrt, ttyl
[13:48] <jbicha> seb128: happy Spring!
[13:49] <kenvandine> jbicha, seems to me spring started a month ago here :)
[13:49] <kenvandine> pitti, can you look at https://bugzilla.gnome.org/show_bug.cgi?id=668903
[13:49] <ubot2`> Gnome bug 668903 in introspection "Broken marshalling on big endian architectures" [Major,Reopened]
[13:51] <seb128> jbicha, hey, thanks, to you as well!
[13:51] <seb128> jbicha, how are you?
[13:51] <seb128> kenvandine, he's off sick today but I guess he will read feedback
[13:51] <seb128> scrollback
[13:52] <kenvandine> i just noticed
[13:52] <jbicha> kenvandine: I thought this was summer!
[13:53] <kenvandine> i wish this is what summer felt like... 80F is much better than 98F :)
[13:53] <jbicha> it's been in the 80s in Wisconsin for instance
[13:53] <seb128> jbicha, btw if you want to do some of the .92 updates like gnome-themes-standard, cheese, etc feel free ;-)
[13:53] <desrt> seb128: back
[13:54] <desrt> seb128: so basically you're saying have two copies of the panel -- one writing entirely to gconf and the other writing entirely to gsettings?
[13:54] <seb128> desrt, yes
[13:54] <desrt> seems like it wouldn't work
[13:54] <jbicha> seb128: I'm a bit swamped with Docs Freeze & my day job is working on posscon.org which happens next week so I won't be able to do the updates as much this week :)
[13:54] <desrt> because g-s-d has to read from one place or the other
[13:54] <seb128> desrt, the 3.2 and 3.4 codebases
[13:54] <seb128> jbicha, ok
[13:54] <desrt> unless we want to have onlyshowin for the media-keys g-s-d plugin (and i don't think it works like that) :)
[13:54] <seb128> desrt, oh right :-(
[13:55] <desrt> seb128: okay.  here's what's involved (add any i miss): g-c-c, g-s-d, mutter, metacity, compiz
[13:55] <desrt> right?
[13:55] <seb128> yes
[13:56] <desrt> if we followed upstream, absolutely everything would be happy except compiz?
[13:56] <seb128> well, and unity-2d
[13:56] <desrt> (including new metacity version)
[13:56] <desrt> if we took the new metacity, unity-2d would be happy
[13:56] <seb128> not sure how unity-2d keys interact with the wms one
[13:56] <desrt> oh.  it has its own keys?
[13:56] <seb128> that's assuming the unity-2d code doesn't use gconf
[13:56] <seb128> desrt, I don't know the unity2d codebase, I can't tell
[13:57] <didrocks> hey desrt, small hint, you probably should put a commit message now to https://code.launchpad.net/~desrt/unity/no-average-bg-color-gsettings/+merge/96863 and approve your branch :)
[13:57] <didrocks> yeah, 2d has its own keys
[13:57] <desrt> didrocks: what do they do?
[13:58] <didrocks> choosing launcher placement, putting barriers sensitivity, launcher items content
[13:59] <desrt> oh
[13:59] <desrt> not keybindings, though
[13:59] <seb128> desrt, not sure if they read any keybindings for i.e hud
[13:59] <desrt> a quick grep tells me not
[13:59] <didrocks> no, it's part of unity-2d as well
[13:59] <seb128> ok
[14:00] <desrt> so here's my insane idea:
[14:00] <desrt> 1) update metacity
[14:00] <desrt> 2) drop all the patches
[14:00] <desrt> 3) write a compiz plugin to do gsettings->gconf migration
[14:01] <kiwinote> st
[14:01] <kiwinote> whoops
[14:01] <jbicha> I had thought Precise was going to have compiz gsettings since there was a branch for it before oneiric was released
[14:01] <desrt> jbicha: the branch wasn't really ready....
[14:02] <jbicha> and of course now's way too late for that
[14:02] <Riddell> hello desktop team, who is able to make a decision on bug 882014 ?
[14:02] <ubot2`> Launchpad bug 882014 in indicator-weather "Please consider package removal or adding developers" [Undecided,Confirmed] https://launchpad.net/bugs/882014
[14:02] <desrt> ya.  i did a couple of rounds of review... it was a complicated patch
[14:02] <desrt> and it just dropped off
[14:05] <seb128> desrt, I think it's too much change at this point, beta2 freeze is in 2 days
[14:06] <seb128> desrt, you can try to get a ffe but that seems a crazy plan
[14:06] <seb128> desrt, I would try to go for "drop the g-s-d patch and make g-c-c write to both gconf and gsettings"
[14:06] <desrt> seb128: it's the metacity part that you object to, isn't it?
[14:06] <seb128> desrt, that and "write a compiz plugin"
[14:07] <desrt> that's trivial :)
[14:07] <desrt> okay
[14:07] <seb128> well, I feel like the "get g-c-c to write to both location" should be easier
[14:07] <desrt> so what is your plan for the g-s-d migration patch?
[14:07] <seb128> and less risky
[14:07] <desrt> whitelist-only or dropped entirely/
[14:07] <seb128> that's a different topic
[14:07] <desrt> it's related
[14:07] <desrt> because if we have something migrating keys from gsettings to gconf we could use it
[14:08] <seb128> hum, I was going to email ubuntu-desktop list suggesting dropping it
[14:08] <desrt> i think that's a good idea
[14:08] <desrt> so then i agree with you
[14:08] <desrt> i'm going to write a very very small g-c-c patch
[14:08] <desrt> it will basically be a list of gsettings keys and corresponding gconf keys
[14:09] <desrt> when a write happens to the gsettings key in question, it will also go to the proper gconf key
[14:09] <desrt> piece of cake
[14:10] <seb128> desrt, you can probably copy the gsettings-desktop-schemas wm convert for that mapping table
[14:10] <desrt> sounds good
[14:10] <desrt> it's all the keys in /app/metacity, right?
[14:11] <seb128> should be
[14:12] <seb128> but I've little experience with wms and keybindings so maybe check with didrocks
[14:12] <desrt> well
[14:12] <desrt> if it's in the conversion file then it's just a straight port
[14:12] <desrt> gsettings-data-convert migrations are.... not clever :)
[14:12] <desrt> "oh.  i see a string.  it must be a string!"
[14:12] <jibel> Sweetshark, I re-ran oneiric->precise upgrade and bug 916291 is still there with LO 3.5.1-1ubuntu1
[14:13] <ubot2`> Launchpad bug 916291 in libreoffice "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [Critical,Triaged] https://launchpad.net/bugs/916291
[14:13] <desrt> that's about as advanced as the logic is :p
[14:13] <didrocks> what are you trying to fix?
[14:13] <seb128> didrocks, is /usr/share/GConf/gsettings/gsettings-desktop-schemas.convert basically what compiz needs?
[14:13] <desrt> didrocks: reducing the patches on g-c-c and g-s-d
[14:13] <seb128> didrocks, reduce the patch crazyness and write to gsettings as well as gconf for shell benefit
[14:14] <desrt> seb128: the saddest part about this plan is that g-c-c has to keep its gconf depend
[14:14] <didrocks> the mapping is actually already exposed (the metacity keys we steal)
[14:14] <Sweetshark> jibel: Ok, I need an exact virtualbox image of that run then as I cannot reproduce that here.
[14:14] <seb128> didrocks, /usr/share/GConf/gsettings/wm-schemas.convert I meant
[14:14] <didrocks> no
[14:14] <jbicha> didrocks: yeah, currently users who try to change keyboard shortcuts in GNOME Shell are met with failure, we can refer them to dconf-editor but that's a pain
[14:14] <didrocks> /usr/share/gnome-control-center/keybindings/*compiz*
[14:14] <seb128> didrocks, well, I was wondering if all the keys in the mapping are listed there
[14:15] <didrocks> (which is a sed from metacity)
[14:15] <didrocks> this is the keys that are used
[14:15] <seb128> thanks
[14:15] <desrt> oh.  that.
[14:15] <desrt> ya.  that's going to be an issue, i think
[14:15] <desrt> the control centre looks at the files in that directory
[14:15] <desrt> and they're going to have gconf paths, not gsettings keys :X
[14:16] <didrocks> right
[14:16] <Sweetshark> jibel: What I did to try to get that error was: 1) install vanilla oneiric 2) apt-get update && apt-get upgrade 3) do-release-update -d
[14:16] <Sweetshark> jibel: should I have left out 2) ?
[14:17] <desrt> seb128: i start to like my idea more again :p
[14:17] <desrt> unless we can get compiz not to install those files
[14:18] <didrocks> if compiz doesn't install those files, it has no idea where to look though :p
[14:18] <desrt> i'm confused.  those files are for the benefit of compiz or for the control centre?
[14:18] <didrocks> both
[14:18] <didrocks> control center to expose them
[14:18] <didrocks> compiz is reading them
[14:18] <didrocks> and has a giant conversion table within code
[14:19] <desrt> this is really quite dreadful :)
[14:19] <didrocks> but IIRC, they need to exist
[14:19] <desrt> lemme check something, then
[14:21] <desrt> hum
[14:21] <desrt> the control centre actually doesn't seem to be bothered by then
[14:21] <desrt> it just ignores them
[14:21] <bcurtiswx> good morning
[14:21] <didrocks> desrt: it will only expose those corresponding to the wm running
[14:22] <desrt> didrocks: is this the patched or unpatched behaviour?
[14:22] <desrt> because we plan to remove all the patches...
[14:22] <didrocks> desrt: unpatched behavior
[14:22] <didrocks> all the g-c-c patches or just the revert? :)
[14:22] <desrt> i wish all :)
[14:22] <didrocks> aha
[14:22] <desrt> the gconf reverts, basically
[14:24] <desrt> so here's what i don't get
[14:24] <desrt> the new format (gsettings) keybindings files have description strings in them
[14:24] <desrt> the gconf ones don't....
[14:24] <desrt> where do the descriptions come from?
[14:25] <didrocks> desrt: gconftool --short-docs
[14:25] <desrt> huh.
[14:25] <didrocks> they are matching
[14:25] <desrt> fascinating use of introspection
[14:27] <didrocks> see, description on keys are used :-)
[14:28] <desrt> right.  so the compiz ones will be ignored
[14:28] <desrt>   if (schema == NULL &&
[14:28] <desrt>       keylist->schema == NULL) {
[14:28] <desrt>     g_debug ("Ignored GConf keyboard shortcut '%s'", name);
[14:29] <desrt> because they don't have a schema='' attribute
[14:29] <desrt> that's perfect
[14:30] <desrt> seb128: okay.  we do it your way.  this shouldn't be too hard at all.
[14:31] <seb128> desrt, \o/
[14:35] <desrt> weird... the keyboard 'item' code is like a copy of the background 'item' code
[14:35]  * desrt has a strong sense of deja vu
[14:45] <Sweetshark> chrisccoulson: any objections against an annoying libreoffice roomie at uds-q?
[14:54]  * desrt wonders what would be higher -- the electricty consumption due to the parallel building of libreoffice (on björn's laptop no less) and firefox -- or the noise complaints generated by passionate levels of dbusmenu bitching
[14:57] <Sweetshark> desrt: we should combine those to use the synergy: high power noise complains ...
[15:03] <didrocks> desrt: btw, did you read my message about the commit message not set and so, your wonderful branch not merged?
[15:03] <desrt> didrocks: i did read it, but i didn't understand what i was supposed to do
[15:04] <didrocks> desrt: go to the merge proposal page
[15:05] <didrocks> desrt: see the "add a commit message"
[15:05] <didrocks> be tempted by it and add one :)
[15:05] <didrocks> then, on top
[15:05] <didrocks> change needs review -> approved
[15:06] <desrt> that was... easy
[15:06] <desrt> :)
[15:07] <desrt> i just had to copy-paste the commit message to ... the commit message
[15:07] <desrt> perplexing :)
[15:08] <didrocks> desrt: thanks! :)
[15:12] <seb128> desrt, yeah, that's a stupid ui
[15:12] <seb128> especially when your merge request has 1 commit
[15:12] <seb128> it should automatically use the commit message as merge message for those
[15:17] <seb128> ok, I'm out for some exercice
[15:17] <seb128> will be back for the meeting time in case we have a meeting today ;-)
[15:17] <seb128> if people feel bored the pad still has a stack of GNOME updates to claim, so feel free to pick one
[15:18] <desrt> seb128: quick update
[15:18] <seb128> desrt, yes?
[15:18] <desrt> seb128: the way keybindings are handled in upstream gnome is very stupid presently
[15:18] <desrt> metacity is installing the g-c-c keybinding description files for the schemas in gsettings-desktop-schemas
[15:19] <desrt> those should be moved either to g-c-c or g-d-s
[15:19] <desrt> because otherwise the new metacity is required for mutter's keybindings to be set at all -- which is just wrong, and which we don't have
[15:20] <seb128> hum, it start feeling like we will have broken keybindings for shell in the lts
[15:20] <desrt> i plan to fix this upstream ASAP
[15:21] <seb128> ok
[15:21] <seb128> that said, bbl, need to go if I want to be back for meeting time ;-)
[15:22] <dobey> Reading package lists... U Bë
[15:22] <dobey> i'm also getting that "U Be" printed a lot when doing apt-get update and apt-get upgrade stuff
[15:48] <chrisccoulson> hi Sweetshark
[15:48] <chrisccoulson> yeah, that's fine :)
[16:33] <kenvandine> jbicha, have you looked at the clutter-gst build failures?
[16:34] <jbicha> kenvandine: no, I couldn't get an ARM chroot working so there wasn't too much I could do to test besides pushing random things into Precise
[16:35] <seb128> re
[16:36] <seb128> didrocks, kenvandine, chrisccoulson, Sweetshark, cyphermox, mterry, agateau, Riddell: it's meeting time if somebody has a topic
[16:36] <jbicha> I don't understand ARM much, that's why it would be random
[16:36] <chrisccoulson> hi!
[16:36] <didrocks> no topic for me
[16:36] <chrisccoulson> sorry, been looking at memory leaks in firefox today :)
[16:36] <seb128> hey chrisccoulson, how are you?
[16:37] <chrisccoulson> seb128, yeah, not too bad thanks. how are you?
[16:37] <seb128> I'm good thanks!
[16:37] <Riddell> 14:02 < Riddell> hello desktop team, who is able to make a decision on bug 882014 ?
[16:37] <ubot2`> Launchpad bug 882014 in indicator-weather "Please consider package removal or adding developers" [Wishlist,Incomplete] https://launchpad.net/bugs/882014
[16:38] <seb128> Riddell, it's an universe package, motu call
[16:38] <seb128> but it seems like it's not buggier than lot of universe stuff
[16:38] <seb128> could be one or two bugs to solve
[16:38] <chrisccoulson> and i think i agree with https://bugs.launchpad.net/ubuntu/+source/indicator-weather/+bug/882014/comments/4
[16:38] <ubot2`> Launchpad bug 882014 in indicator-weather "Please consider package removal or adding developers" [Wishlist,Incomplete]
[16:38] <seb128> I would rather like to see it fixed
[16:39] <chrisccoulson> with it not on the default install, being a bit crashy doesn't seem like good enough justification to remove it
[16:39] <seb128> right, especially that the feature is wanted
[16:39] <seb128> we should look if there is an obvious bug in the code leading to those issues
[16:39] <seb128> Riddell, thanks for bringing it up though
[16:39] <seb128>  
[16:39] <stgraber> mterry: ping
[16:39] <seb128> other topics?
[16:40] <kenvandine> not from me
[16:40] <stgraber> oops, sorry, didn't see it was a meeting
[16:40] <Riddell> I have ubuntu desktop working on an arm computer now, although only using the ubuntu server image
[16:40]  * kenvandine should really go update the wiki :)
[16:40] <cyphermox> well, I want to land NM 0.9.4; but need to do a FFE now
[16:40] <chrisccoulson> did everyone switch to https://launchpad.net/~mozillateam/+archive/firefox-next yet? ;)
[16:40] <mterry> stgraber, yo
[16:40] <chrisccoulson> (well, for those who aren't using chrome)
[16:41] <kenvandine> chrisccoulson, nope... i can do that
[16:41] <jbicha> chrisccoulson: I'm on it, Firefox 12 is totally more awesome than 11 was :)
[16:41] <chrisccoulson> excellent, thanks :)
[16:41] <seb128> ok, seems there was no other topic, thanks everyone
[16:41] <seb128> don't forgot to update your workitems
[16:41] <seb128> chrisccoulson, you still have a gsd boot time one ;-)
[16:41] <chrisccoulson> seb128, yeah :)
[16:42] <jbicha> we could have jorge threaten to remove indicator-weather from the archives, hey it worked for CCSM I guess ;)
[16:42] <kenvandine> hehe
[16:42] <seb128> chrisccoulson, I bet it would be easier to find issues in gsd than in firefox :p
[16:42] <chrisccoulson> seb128, yeah, i'd imagine it probably would be. at least i don't need to rebuild gsd in order to run it in valgrind :)
[16:42] <seb128> ;-)
[16:43] <didrocks> jbicha: didn't really work for ccsm, but that's another discussion :p
[16:43] <jbicha> we got 2 patches, right?
[16:43] <didrocks> yeah, but none for fixing the real issue
[16:44] <chrisccoulson> the real issue being that it is awful? :)
[16:44] <seb128> jbicha, btw I commited your evince update to the vcs, my upload to fix the file conflict issue with the new version got rejected because the vcs was outdated ;-)
[16:44] <didrocks> not, that you can on some cirumstance removing some plugin by conflicts :p
[16:44] <seb128> i.e I commited the archive version and rebase my fix on it
[16:45] <didrocks> Sweetshark: hey, openclipart FTBFS
[16:46] <jbicha> seb128: thanks, bzr push is tough to remember some times
[16:46] <didrocks> Sweetshark: I was thinking you test build it at least
[16:46] <Sweetshark> didrocks: link?
[16:46] <seb128> jbicha, indeed ;-)
[16:46] <kenvandine> chrisccoulson, when is firefox 12 going to be released?
[16:46] <chrisccoulson> kenvandine, 2 days before 12.04 is released ;)
[16:46] <didrocks> Sweetshark: https://launchpad.net/ubuntu/+source/openclipart/2.0-1/+build/3303173
[16:46] <didrocks> you can look at it yourself btw :)
[16:47] <kenvandine> chrisccoulson thx
[16:47] <Sweetshark> didrocks: no, sorry. that was out-of-order-execution because ricotz brought it up ... :/
[16:47] <jbicha> we should write a script that does bzr push and then dput
[16:47] <didrocks> Sweetshark: ok, can you please fix it now then?
[16:48] <Sweetshark> didrocks: yes
[16:48] <didrocks> 17:48:04         micahg | didrocks: FWIW, ajmitch gave me a patch, but I haven't test built it yet, was waiting to finish with something else first
[16:48] <didrocks> Sweetshark: can you please check with micahg? ^
[16:49] <Sweetshark> didrocks: fwiw that is not the new upload that broke, but 3.5.X breaking all openclipart packages.
[16:50] <micahg> Sweetshark: since we have 3.5.x in precise, that means that the openclipart upload is broke :)
[16:53] <Sweetshark> micahg: sure, sure
[16:54]  * Sweetshark is fixing
[16:54] <micahg> Sweetshark: I already have the patch from Debian experimental if you want to review it
[16:54] <micahg> I'll attach it to a bug
[16:58] <micahg> Sweetshark: Bug #960389
[16:58] <ubot2`> Launchpad bug 960389 in openclipart "openclipart 2.0-1 FTBFS in precise" [Medium,In progress] https://launchpad.net/bugs/960389
[17:01] <Sweetshark> micahg: debdiff is looking good
[17:02] <desrt> seb128: so the keybinding stuff is ... bad
[17:03] <desrt> the translations of keybindings in gnome is currently completely broken
[17:03] <seb128> desrt, I'm somewhat glad I went for the "stay on 3.2" code by then rather than on the "let's try to fix compiz" ;-)
[17:03] <desrt> seb128: it needs to be fixed before we can release gnome 3.4
[17:03] <seb128> desrt, could you keep the current code and add gsettings set calls?
[17:04] <desrt> i'm shocked nobody noticed
[17:04] <desrt> seb128: no... i think that's really the wrong way
[17:04] <desrt> i'm going to spend the rest of today trying to make this work
[17:04] <seb128> desrt, well, hard freeze was yesterday
[17:04] <seb128> desrt, ok, good luck
[17:04] <desrt> seb128: this is no code changes
[17:04] <desrt> i just have to do a lot of translating :)
[17:04] <seb128> desrt, just schemas?
[17:04] <desrt> seb128: basically, here's the story:
[17:05] <desrt> the keybinding description strings are in the gsettings schemas in gsettings-desktop-schemas
[17:05] <desrt> so they get translated there
[17:05] <desrt> unfortunately, very few people have done translations of that module
[17:05] <desrt> like, not even 'fr', for example
[17:05] <desrt> so -- no translations
[17:06] <seb128> desrt, like no translation in the control center ui ?
[17:06] <desrt> i'm going to write a scrip that collects a list of all of the strings that need to be translated and attempt to steal them from the existing translations in metacity or mutter
[17:06] <desrt> seb128: correct
[17:06] <seb128> desrt, and nobody noticed?!
[17:06] <desrt> apparently not...
[17:06] <seb128> desrt, you should tell bastien to run a french locale back :p
[17:06] <desrt> i just verified it by switching my fedora install to french and opening the control centre
[17:07] <desrt> only these ones are translated properly: cs.po  de.po  eo.po  es.po  gl.po  ja.po  nb.po  pt_BR.po  sl.po  sv.po  vi.pozh_CN.po
[17:07] <seb128> desrt, well translators still have a week, maybe just email their list telling them to check on that component
[17:08] <desrt> right
[17:08] <desrt> fair enough
[17:08] <seb128> desrt, 2 reasons to that
[17:08] <desrt> anyway.. if that gets sorted, then it's not much problem at all
[17:08] <seb128> desrt, 1- your time might be more valuable than fixing translations
[17:09] <seb128> desrt, 2- translators don't like much having "similar strings" being pulled in for them ;-)
[17:09] <desrt> seb128: the problem is that there are a large number of strings here -- and many of them are not visible in UI
[17:09] <micahg> Sweetshark: thanks for looking
[17:09] <desrt> seb128: these are not really similar strings
[17:09] <desrt> they're the same string that got moved from one module to another
[17:09] <seb128> desrt, translators know how to use intltool-merge to reuse those I think
[17:10] <seb128> I would just drop them a note telling them to sort it
[17:10] <seb128> you will probably have most team who will do it by next week
[17:10] <desrt> hum
[17:10] <desrt> okay.  i will try that
[17:10] <desrt> i can always fill in the missing gaps later
[17:10] <seb128> right
[17:10] <desrt> anyway -- except for that, i think we're in good shape
[17:11] <desrt> moving the xml files from metacity to g-c-c is really straight-forward
[17:11] <desrt> i already have a patch for it
[17:11] <seb128> good
[17:11] <desrt> g-c-c will simply ignore the old gconf files once you remove your patch reverts
[17:11] <desrt> so there's no worries there
[17:11] <seb128> desrt, do we want that?
[17:11] <desrt> yes
[17:12] <seb128> desrt, I'm still unsure why they were there
[17:12] <seb128> I though it was to list compiz specific bindings
[17:12] <desrt> seb128: so basically those xml files are what populate the keybindings panel
[17:12] <seb128> desrt, right, but are all the compiz ones in the upstream panel?
[17:12] <desrt> are there compiz-specific ones?
[17:12] <seb128> or will we loose actions by doing that?
[17:12] <seb128> desrt, well I assume those were added because compiz had some specific ones
[17:12] <desrt> i thought it just steals all the metacity ones...
[17:12] <seb128> desrt, like maybe "expose" or dunno
[17:13] <desrt> seb128: i assume they were added so that you can uninstall metacity and not lose your settings
[17:13] <desrt> i'll be sure to double-check that
[17:13] <seb128> desrt, no, I think it's not that
[17:13] <seb128> desrt, we had in the past when integration was broken stuff that stopped being listed in g-c-c
[17:13] <desrt> seb128: it looks like most of these are just metacity ones...
[17:14] <seb128> didrocks, ^ do you remember what happens without the compiz xml to the gcc?
[17:14] <didrocks> well, you have not the keys exposed anymore
[17:15] <didrocks> I don't remember, but I'm pretty sure some keys were not working on compiz either
[17:15] <desrt> i just did a comparison -- the list of keys compiz installs is exactly equal the list installed by metacity
[17:15] <didrocks> desrt: not a surprise, it's a sed :)
[17:15] <desrt> just a different name
[17:15] <didrocks> in the packaging
[17:15] <desrt> right -- so there is nothing compiz-specific there
[17:18] <m4n1sh> didrocks: ping
[17:18] <didrocks> hey m4n1sh
[17:18] <m4n1sh> rolling out one more release of a-l-m
[17:18] <m4n1sh> with i18n fixes
[17:18] <m4n1sh> some bug fixes
[17:18] <didrocks> m4n1sh: btw, did you look at bug #949849?
[17:19] <ubot2`> Launchpad bug 949849 in pkgbinarymangler "Should use official "Keywords" instead of X-GNOME-Keywords" [Low,Fix released] https://launchpad.net/bugs/949849
[17:19] <didrocks> m4n1sh: would be nice to get it
[17:19] <m4n1sh> this looks good
[17:19] <m4n1sh> will fix it
[17:20] <m4n1sh> didrocks: but there are UI changes which makes it as per the mockups
[17:21] <m4n1sh> filing for another UIFe
[17:24] <desrt> seb128: is there anything that stops you from updating metacity?
[17:24] <desrt> seb128: my life would become _really_ a lot easier if you did :)
[17:24] <desrt> seb128: and the lives of many many translators
[17:25] <didrocks> m4n1sh: please do and keep me posted
[17:25] <m4n1sh> sure
[17:25] <seb128> desrt, the desire to want to stay out of any issue that could create for unity-2d and the lack of interest for it
[17:25] <seb128> desrt, i.e talk to didrocks if you want to convince somebody ;-)
[17:25] <desrt> didrocks: can we pretty please have the new metacity?
[17:25] <didrocks> not like if we were already in a rush
[17:25] <seb128> desrt, I managed to stay out of any wm work for some years and I intend to keep it this way :p
[17:26] <didrocks> and every new metacity broke unity-2d in some interesting way
[17:26] <didrocks> not speaking of the stack of patch we have
[17:26] <Sweetshark> micahg: building with the patch now
[17:27] <seb128> desrt, you should probably move the defintions to g-c-c and make g-c-c write to gsettings as well on the current codepath, anything else start to seem out of scope
[17:27] <seb128> desrt, this way we wouldn't change anything but g-s keybindings change would work
[17:27] <desrt> seb128: it's not that easy due to the translations, unfortunately
[17:27] <seb128> desrt, we already have the translations
[17:27] <desrt> seb128: and i really want to drop those g-s-d patches
[17:27] <desrt> that's my main interest
[17:28] <desrt> seb128: wrong gettext domain, unfortunately
[17:28] <desrt> how do we deal with translations in gnome packages in ubuntu anyway?
[17:28] <desrt> isn't there some launchpad stuff there that does.. something?
[17:28] <seb128> desrt, launchpad has them and export
[17:29] <desrt> so they're periodically synced upstream or vendor patch or what?
[17:29] <seb128> desrt, dropping the gsd patch should be that hard
[17:29] <RainCT> didrocks, mhr3: uploaded the new versions of zeitgeist and libzeitgeist to Debian (the first to experimental)
[17:29] <seb128> desrt, that doesn't impact the wm
[17:29] <desrt> so here's why i want new metacity (and the only reason, really): the translations for these strings are in there
[17:29] <seb128> desrt, you "just" need to update gcc to write to gsettings for the multimedia keys and keep the gconf stuff for the wm ones
[17:30] <didrocks> RainCT: thanks a lot! Will sync tomorrow :)
[17:30] <mhr3> RainCT, datahub as well?
[17:30] <seb128> desrt, but you already have the translations, precise is translated
[17:30] <RainCT> mhr3: we have a new datahub?
[17:30] <desrt> seb128: the issue is that maybe some strings changed
[17:30] <RainCT> mhr3: we have a mailing list, you know? :P
[17:30] <seb128> desrt, well if you don't change anything but add gsettings set call you are out of any ui change
[17:30] <desrt> i think "Toggle window on all workspaces or one" is different wording than it used to be, for example
[17:31] <desrt> true....
[17:31] <desrt> so i could just do what i was going to do before
[17:31] <desrt> but in the other direction instead
[17:31] <seb128> desrt, and it allows you to drop the gsd patch
[17:31] <seb128> since if you write the gsettings action keys you can drop the gsd part
[17:31] <mhr3> RainCT, mailing list? you mean twitter? :P
[17:31] <seb128> right
[17:31] <desrt> these patches are so ugly :)
[17:31] <seb128> yeah, we will drop them next cycle
[17:31] <desrt> oh well -- i guess that's the bed we make for ourselves
[17:32] <desrt> and now we have to lie in it
[17:32] <desrt> at least for another 6 months
[17:32] <seb128> right
[17:32] <seb128> or another 2 months
[17:32] <seb128> until we jump on q
[17:32] <desrt> i have a local copy of g-c-c that i run without patches anyway
[17:32] <seb128> is that called gnome3 ppa?
[17:32] <desrt> no
[17:32] <desrt> afaik they have the g-c-c patches?
[17:33] <desrt> some of them are really necessary in order to not break the entire distro
[17:33] <desrt> like the library patch
[17:34] <seb128> desrt, oh, without any patch, I though you meant without the keybinding revert one
[17:38] <desrt> ya... the vast majority of patches are annoying and pointless
[17:39] <desrt> randomly changing the UI for no reason
[17:39] <desrt> like switching the side of the images pane on the background panel
[17:40] <seb128> desrt, I guess that will be fixed next cycle
[17:40] <desrt> what will fix that?
[17:40]  * desrt can imagine 3 possible answers to that question
[17:40] <seb128> desrt, I want to make a ubuntu-control-center source
[17:40] <seb128> and restore g-c-c as the upstream one
[17:40] <jbicha> desrt: but putting it on the right makes it .1% better! I agree that Design should think a bit more about whether a diff with GNOME is worth it
[17:40] <desrt> ah.  that's the answer i was hoping for :)
[17:41] <seb128> the amonth of patching is suffisant that I think it's worth it
[17:41] <desrt> you laughed at me when i suggested that at the rally :)
[17:41]  * didrocks sneaks some more distro-patch to g-c-c meanwhile
[17:41] <seb128> yeah, I didn't want to have to deal with that for this cycle
[17:41] <seb128> didrocks, ;-)
[17:41] <didrocks> phew, I wasn't thinking I would get to it that fast seeing the rate of ping I had! :)
[17:41] <desrt> my g-c-c has 3 distropatches :)
[17:41] <seb128> desrt, I want to also do it in a way where we can keep rebasing in a sane way
[17:42] <jbicha> that would fix the keyboard shortcuts problem though, wouldn't it?
[17:42] <seb128> jbicha, that wouldn't no
[17:42] <seb128> but the shortcut problem will be fixed next cycle
[17:42] <desrt> the revert-removal-of-datettime-mechanism will be fixed next cycle too =) =)
[17:43] <seb128> desrt, yeah, one way or another
[17:43]  * desrt has good feelings about that
[17:44] <desrt> lennart is actually going out of his way to act friendly to help with the changes
[17:44] <seb128> I'm staying out of init system discussions
[17:44] <desrt> even offering some possibility for upstart backwards compatibility ideas
[17:44] <seb128> I would prefer we don't change
[17:44] <desrt> :)
[17:44] <seb128> but not my call
[17:45] <seb128> I would prefer people would let my init the way it is, it's working and I've no interest of changing it or of dealing with side effect of a migration
[17:45] <seb128> ;-)
[17:48] <desrt> seb128: do you write custom init scripts?
[17:48] <seb128> desrt, no, but I maintain packages with init scripts
[17:49] <desrt> ah.  true.
[17:49] <desrt> well the good news about that is that probably upstream maintainers will start thinking about including systemd integration with their software
[17:49] <seb128> desrt, and I know that any such transition has hiccups for users (counting me as an init user)
[17:49] <desrt> so less of that work will fall on packagers
[18:15] <desrt> seb128: so what's this a11y gsettings stuff?
[18:15] <desrt> there are patches for it in g-c-c and g-s-d -- somewhere else as well?
[18:16] <seb128> desrt, it's the visible bell stuff, that's handled by the wm
[18:16] <seb128> those are tiny
[18:22] <desrt> seb128: how do i deal with undesired source changes because automake decided to randomly rewrite some files?
[18:22] <desrt> so far i've been doing it by saying dpkg-source --commit then poping the patch and removing it from the series
[18:22] <seb128> desrt, what do you try to do
[18:23] <desrt> seb128: debuild -S after building a binary....
[18:23] <seb128> desrt, oh, I never do that
[18:23] <seb128> well ideally the "clean" target brings you back the the original state
[18:23] <seb128> but often that's buggy
[18:23] <seb128> I tend to wipe the dir and dpkg-source -x .dsc
[18:24] <seb128> to unpack
[18:24] <desrt> not so good when you made changes you want to keep :)
[18:24] <seb128> but nowadays I just work with debian dir in the vcs and bzr bd
[18:24] <seb128> well usually I copy my updated patches back to the packaging vcs
[18:25] <seb128> and when I'm happy I bzr bd --source
[18:25] <seb128> in the vcs
[18:25] <desrt> packaging is a dark art :)
[18:25] <seb128> ;-)
[18:28] <jalcine> It's possible to unlock a session in a programmatic manner, no?
[19:01] <Sweetshark> micahg: k, openclipart successfully build with the debdiff from the patch.
[19:02] <ajmitch> damn, I commented too late then
[19:22] <desrt> ajmitch: hey.  what's up?
[19:28] <chrisccoulson> wow, i can't believe how memory hungry chrome is these days - http://techsplurge.com/8147/firefox-11-vs-chrome-17-released-features-3d-page-view-chrome-bookmarks-import-extensive-tests/ ;)
[19:28] <ajmitch> desrt: was just commenting on the openclipart bug about 2 minutes before sweetshark said it built
[19:29] <ajmitch> & just swearing profusely at thunderbird using 3GB of RAM & making my desktop awfully slow :)
[19:30] <micahg> Sweetshark: thanks
[19:31] <mdeslaur> chrisccoulson: wow, that's impressive
[19:34] <seb128> chrisccoulson, well, firefox 11 vs chrome 17, firefox is 6 versions behind... ;-)
[19:36] <desrt> i love firefox
[19:36] <desrt> and i love chrome for giving firefox the kick in the ass that it needed
[19:36] <seb128> ;-)
[19:36] <desrt> seb128: i HATE this patch
[19:36] <chrisccoulson> seb128, you're one of these version number trolls, aren't you? :-)
[19:36] <seb128> chrisccoulson, doh, you got me! ;-)
[19:37] <seb128> chrisccoulson, well you have to reckon, if it's higher it has to be better
[19:37] <chrisccoulson> lol
[19:37] <seb128> chrisccoulson, I leart at school that 17 > 11
[19:37] <seb128> learnt
[19:37] <seb128> ;-)
[19:37] <desrt> chrisccoulson: unfortunately, they couldn't quite get through to him on the issue of spelling
[19:38] <chrisccoulson> lol
[19:38] <seb128> who need writing when you got counting!
[19:38] <desrt> seb128: *needs
[19:38] <seb128> 16541 1351 1 61 64 616
[19:38] <desrt> seb128: *you've
[19:38] <seb128> 46 41 645 646
[19:38] <chrisccoulson> and who needs counting when you've got 17?
[19:38] <seb128> desrt, 152 :p
[19:39] <seb128> (I can't believe it's only tuesday)
[19:39] <desrt> ya.  seriously
[19:39] <desrt> something about this week....
[19:39] <seb128> desrt, just counted, 37 GNOME updates done by myself in 2 days
[19:39] <seb128> I blame chrisccoulson for being busy on firefox, didrocks on unity, and pitti for loosing teeth
[19:39] <desrt> seb128: 37 is a smaller number than the number of patches we have in g-c-c + g-s-d + metacity :p
[19:40]  * desrt just tried to roll a new upstream metacity and apply our patches to it
[19:40] <desrt> wanna guess how that went? :)
[19:40] <seb128> desrt, it's a smaller number of patches than we have in g-c-c you mean?
[19:40] <desrt> seb128: ya.  probably :)
[19:40] <seb128> desrt, lol, I guess "not good"
[19:40] <desrt> seb128: like 50% of them had conflicts
[19:40] <desrt> plus we add a bunch of new gconf keys like some 'strict' mode from lamont
[19:41] <seb128> desrt, that's one of the reasons I think we should stay on compiz
[19:41] <desrt> i'd have to port all of those over to gsettings
[19:41] <desrt> seb128: hm?
[19:41] <seb128> desrt, not playing "use a GNOME component but distro patch it enough that it works for us"
[19:41] <seb128> I would hate having mutter with a 35 patches stack
[19:41] <seb128> so it "works for unity"
[19:42] <desrt> seb128: just do the renaming trick
[19:42] <desrt> metacity + clutter = mutter
[19:42] <desrt> mutter + ubuntu patches = ... hm.... buck-futter?
[19:42] <seb128> desrt, right, unitter
[19:42] <seb128> lol
[19:42] <seb128> but yeah, I just want to stop distro patching to no end stuff
[19:43] <desrt> indeed
[19:43] <seb128> better to just fork and rebase
[19:43] <desrt> debian vendor patches are not the best form of VCS :)
[19:50] <desrt> seb128: can you explain a bit of debian version numbers to me?
[19:50] <desrt> what is the best practice for shipping a git version of an upstream?
[19:51] <desrt> like if i wanted to make a metacity 2.34.3 package before it is released
[19:51] <desrt> 2.34.3~git20120320-0ubuntu0 or something?
[19:53] <seb128> desrt, yeah, that works
[19:53] <seb128> usually <version>~something
[19:53] <desrt> that will be "before" 2.34.3?
[19:53] <seb128> there are 2 "schools"
[19:53] <seb128> yes, ~ is "just before"
[19:53]  * desrt sits down for a lesson
[19:53] <seb128> well some people do 2.34.2+git
[19:53] <desrt> the other way is to do 2.34.2+git?
[19:53] <desrt> right...
[19:54]  * desrt is doing .3 because that's what's in configure.ac already (due to post-release bumping)
[19:55] <desrt> """The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part."""
[19:55] <desrt> good to know.
[19:56] <seb128> desrt, dpkg --compare-versions v1 gt v2; echo $?
[19:56] <seb128> desrt, is your friend
[19:56] <desrt> these rules are my friend, really
[19:56] <desrt> that one sentence tells you all you need to know
[19:56] <desrt> i guess it's actually not true, though
[19:56] <desrt> a simple ascii compare would sort 1.10 before 1.2
[19:57] <desrt> ah.  next paragraph explains that :)
[19:59] <seb128> desrt, I think you will have an hard time to find stuff in there not correctly laid out
[20:00] <desrt> ya.   nothing says "obsessive compulsive obsession with order" like the letters 'DD'
[20:00] <seb128> the Debian documentation is usually quite rigorous
[20:00] <seb128> ;-)
[21:37] <jbicha> desrt: looks like metacity 2.34.3 is out now
[21:47] <jasoncwarner_> hey TheMuso RAOF bryceh https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-03-20 if anything to discuss, please put in the agenda. Otherwise, fill in your updates and we are good to go...
[21:48] <TheMuso> Done.
[21:48] <TheMuso> I tend to try and get it done before meeting time.
[21:48] <bryceh> jasoncwarner_, heya.  my stuff's filled in.  no agenda topics.
[21:50]  * Sweetshark waves at jasoncwarner_ at the other end of the world.
[21:50] <jasoncwarner_> evening Sweetshark !
[21:50] <jasoncwarner_> thanks bryceh
[21:52] <RAOF> Evening Sweetshark :)
[21:54] <desrt> jbicha: ah.  great news.
[21:54] <Sweetshark> bryceh: btw, 3.5.1-1ubuntu1 is in now. even if you didnt end up with the upload, thank you very much for the help and support ;)
[21:55] <Sweetshark> RAOF: hi there (must be day on the other side of the globe -- everyone there is awake ;) )
[21:56] <Sweetshark> jasoncwarner_: I booked and registered UDS btw.
[21:57] <bryceh> Sweetshark, sure thing, glad it got sorted
[22:02]  * Sweetshark starts a armel build on a porter box
[22:03]  * Sweetshark is feeling a bit sardistic towards the porter box today.
[22:06] <RAOF> A LO build on the porter box?  That'll be done this time next week? :)
[22:06] <micahg> RAOF: it's a panda now :)
[22:07] <desrt> RAOF: ya... shouldn't take longer than 3 or 4 days.  didn't you know?
[22:10] <Sweetshark> RAOF: The last time I tried that the build was interrupted by ~3 reboots. Likely someone considered the box "unresponsive" (ummm, yeah?) and applied the 3R rule of windows administration: retry, reboot, reinstall ...
[22:11] <robert_ancell> RAOF, is everyone saying the greeter->session transition is now working just a coincidence?  That patch hasn't been released yet?!
[22:11] <RAOF> :)
[22:11] <RAOF> robert_ancell: No, I also uploaded a new unity-greeter with the patch applied.
[22:11] <robert_ancell> oh, good
[22:11] <RAOF> On the basis that it seemed like a good idea :)
[22:12] <robert_ancell> RAOF, but not applied to lp:~ubuntu-desktop/unity-greeter/ubuntu?
[22:12] <RAOF> robert_ancell: The last *two* uploads aren't in lp:~ubuntu-desktop/unity-greeter/ubuntu.
[22:12] <RAOF> I'm not sure why, so I didn't touchit.
[22:13] <robert_ancell> RAOF, so you made it more out of date :P
[22:14] <TheMuso> VCs for packaging is not going to work unless we switch wholesale.
[22:14] <RAOF> Or use the udd package branches.
[22:14]  * RAOF much prefers full source branches.
[22:14] <TheMuso> Yes, use the UDD branches, but nothing else.
[22:15] <TheMuso> s/but/and/
[22:15] <TheMuso> But of course there are those packages in debian maintained in git... and so it goes again.
[22:15] <RAOF> All that they need is for quilt to die, and 3.0 (bzr) to become our standard source format :)
[22:15] <TheMuso> heh
[22:24] <mterry> desrt, heyo.  So how bad/difficult is having a sudo process talk to a user's session dbus?
[22:24] <desrt> mterry: i wouldn't recommend it
[22:25] <desrt> mterry: why do you ask?
[22:25] <desrt> something to do with a screensaver?
[22:25] <mterry> desrt, deja-dup sometimes will run duplicity under sudo, but ideally would pass gio URLs to it
[22:25] <mterry> desrt, I can pass gvfs fuse paths, but that is always a bit buggy
[22:26] <desrt> presumably it runs as root in order to gain access to some files that it wouldn't normally have access to
[22:26] <mterry> right
[22:26] <desrt> oh
[22:26] <mterry> for restoring purposes
[22:27] <desrt> and the gvfs path is presumably the destination...
[22:27] <desrt> that's really tricky.
[22:27] <mterry> desrt, in these cases, the source, and is restoring into non-home directories
[22:27] <desrt> you could try setting the session bus environment variable on the other side of the sudo
[22:27] <desrt> but that would interact badly with dconf, for example (which i assume duplicity doesn't use)
[22:27] <mterry> desrt, I tried sudo -E  (preserve env) but dbus_bus_get returns NULL
[22:28] <mterry> desrt, only if gio ends up using it client side
[22:50] <seb128> bah, bug #929437 is annoying
[22:50] <ubot2`> Launchpad bug 929437 in software-center "gvfsd-http crashed with SIGSEGV in __nscd_get_mapping()" [High,Confirmed] https://launchpad.net/bugs/929437
[22:51]  * desrt wonders why builders bother uninstalling packages from the pbuilder root instead of just blowing it away
[22:53] <lifeless> desrt: lp-buildd, patches appreciated
[22:57] <desrt> seb128: i think your glib trigger scripts are broken :/
[23:00] <desrt> seb128: not very serious breakage... but with the recent changes in gio-querymodules to please automake by removing the cache file on an empty directory, we see this turning up in build logs: Unable to open directory /usr/lib/gio/modules: Error opening directory '/usr/lib/gio/modules': No such file or directory
[23:02]  * micahg would think that's more related to not checking the multiarch path
[23:02] <desrt> oh.  that's quite possible as well
[23:02]  * desrt just assumed that it was caused by a more recent change
[23:02] <micahg> /usr/lib/x86_64-linux-gnu/gio/modules
[23:03] <seb128> desrt, that's only a warning
[23:03] <desrt> i know
[23:03] <seb128> desrt, we kept the old path listed and a || true iirc
[23:03] <seb128> just for compat reason
[23:03] <desrt> to cleanup leftovers just in case?
[23:03] <desrt> fair enough
[23:04] <seb128> but thanks for pointing it ;-)p
[23:04] <seb128> ;-)
[23:04]  * desrt saw it at the bottom of a failed build log and assumed it was the cause of the failure
[23:04] <desrt> then i scrolled up...
[23:24] <thumper> Ursinha: ping
[23:24] <Ursinha> thumper, pong
[23:24] <thumper> Ursinha: I was just calculating time zones wondering if you'd still be around
[23:25] <thumper> Ursinha: can you see bug 953963 ?
[23:25] <Ursinha> sure
[23:25] <thumper> Ursinha: it is a private bug that others are being made dupes of
[23:25] <thumper> Ursinha: hard to fix if I can't see it :)
[23:25] <Ursinha> haha okay
[23:26] <Ursinha> thumper, I subscribed you, if you feel the info there can be deleted/disclosed just make it public
[23:26] <thumper> Ursinha: thanks
[23:27] <Ursinha> thumper, np