=== jalcine is now known as jalcine_ [00:47] jasoncwarner_, beware the dreaded rls-p-tracking tag :) [00:50] 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] robert_ancell: I've got a bunch of things which infuriatingly *don't* work. [00:52] RAOF, do you know if anything has changed? This all used to work [00:52] Did it? At what point did it work? [00:52] last cycle (at least for me) [00:53] 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] but it used to switch to the bg and then get replaced by the session [00:54] RAOF, did you try XCopyArea from the window to the root window? [00:54] robert_ancell: I did, yes. [00:54] robert_ancell: Did it work on *all* drivers last cycle? [00:54] I can't say for sure [00:55] 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] there's a good chance it didn't [00:55] if XCopyArea doesn't work that's really odd - that should be 100% safe from the X protocol point of view afaict [00:55] Intel works for me. Or, at least, worked until I started trying to fix it :) [00:55] Did you dive into the GDM code and check they're not doing anything special? The original code was based off them [00:56] robert_ancell: I think my problem with XCopyArea was that I did it before the root window was exposed; thus, it disappeared. [00:56] 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] Hm. That could work. [00:58] Alternatively, I could unmap unity-greeter's window and then XCopyArea. But that'd leave a flash, so not good. [01:00] The implementation was just to draw into the pixmap and set that as the background - you really *shouldn't* need to XCopyArea [01:01] Yeah. [01:01] Although, as mentioned in the bug, you should do that after you've actually *drawn* to the pixmap :) [01:02] Also, cairo doesn't guarantee that the pixmap contains anything sensible until you surface.flush() it. === cjwatson_ is now known as cjwatson [01:02] ah [01:02] Doing both of these things doesn't fix it, however. [01:02] also, doesn't Cairo use Surfaces instead of Pixmaps internally? So perhaps they have different behaviour to Pixmaps when the clients exit? [01:02] Does each driver essentially implement XRENDER themselves? [01:03] No; the acceleration architecture does that. [01:03] that's common code in X.org? [01:03] and then the drivers just have buffers etc [01:03] 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] ah [01:05] Where's the gdm code that does this? === jalcine_ is now known as jalcine [01:07] * robert_ancell hunts around [01:07] Looks to be in gdm-slave.c [01:08] it's probably based off gui/simple-greeter/greeter-main.c [01:09] but it may actually be using gnome-background from libgnome (?) [01:10] RAOF, yes, gnome-desktop/libgnome-desktop/gnome-bg.c [01:11] gnome_bg_set_root_pixmap_id [01:12] so it might work better if we have a separate process keeping the root window alive? [01:15] Maybe? [01:15] I thought the root window hung around, though. [02:16] pitti wins at being german [02:16] 1) make a claim using a numbers like 99.99995% [02:16] 2) cite a footnote that explains why this calculation is the actual accurate value [02:29] robert_ancell, ping about bug 880104 [02:29] 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] robert_ancell, it's because of the call to initgroups, which wipes the group list [02:30] 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] mterry, ok, cheers. I thought it might be something like that [02:31] 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] yeah, it's done in pam_setcred, so we just need to move the setgroups [02:35] robert_ancell, you mean move initgroups to before pam_setcred? [02:35] yes [02:35] robert_ancell, easy enough [02:36] I'm guessing that the group memberships doesn't affect any things that a root process wants to do [02:36] so the only thing we have to do last is drop privileges [02:36] Do group memberships matter for root? [02:41] mterry, I'll work up a patch for it [02:41] OK [03:14] who is reponsible for gnome-language-selector? === sikon is now known as lucidfox [03:37] Ok. I can definitely draw *something* to the root window's backing pixmap, and it works. [03:46] Aha. It *is* setting the root backing pixmap; it's just setting it to garbage. [03:52] Huh. We create the pixmap, but nothing ever draws to it. [04:02] Vala needs a debugger ☹ [04:06] RAOF: gdb? [04:07] Yeah, but then you need to read vala's c output to make sense. [04:07] compile with -g [04:07] then you get to read vala code instead [04:08] Ooh, that'd be much more fun! [04:09] 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] lightdm does its image loading in threads [04:10] i wonder if it's doing more than that in the thread accidentally [04:10] Well, it's already successfully drawn the background. [04:11] This is just trying to draw the background on a different cairo context. [04:11] 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] RAOF: forcing a draw when a size invalidation has been scheduled [04:12] could resolution changes be involved? [04:13] Well, it's drawing on a different-sized surface. [04:13] A framebuffer-sized pixmap, rather than whatever GTK normally thinks its drawing on. [04:14] this is unity-greeter? [04:14] Yu. [04:14] It's (now) doing everything to set the root window's backing pixmap, except actually drawing to it :) [04:15] why the hell is it being done this way? [04:16] I think because it's roughly what gnome-desktop does. [04:17] it doesn't punt through a widget [04:17] .draw() is not a pure vfunc, you must understand [04:17] calling background.draw() does NOT result in calling the draw() function on the Background class [04:17] it results in calling gtk_widget_draw() on the background instance [04:17] which will so some stuff [04:18] maybe calling that function will be in there somewhere [04:18] or maybe throwing an assert [04:19] are you trying to get the login box as part of what you are drawing? [04:19] or only the background? [04:20] Only the background. [04:20] Yeah, I know it's calling gtk_widget_draw. [04:20] 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] which will draw the container children -- like the login box [04:20] Hah. [04:21] probably you'd rather call draw_full() directly [04:21] that way you can skip the trip through gtk [04:21] 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] Win! [04:25] score [04:25] time for me to go to bed, then :) [04:25] Sweet dreams! [04:25] uh... you too. [04:25] :) [04:27] 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] jasoncwarner_: We've just hit step 2. [04:28] RAOF, \o/ [04:28] RAOF: !!! [04:28] It'll now be just as fast to fix it as to remove the transition. [04:28] Well, at least, if my xnest testing is accurate :) [04:30] robert_ancell: I'm *amazed* that code works on Intel. It's wrong in so many ways :) [04:30] RAOF, which code? [04:30] The code for setting the root window background pixmap. [04:31] what's the main way it's wrong? [04:31] It never draws to the pixmap. [04:31] Well, that's the *final* reason it's wrong :) [04:31] that one seems quite major [04:32] what's with the drivers allowing pixmaps with uninitialized memory? [04:32] Performance optimisation? [04:32] What's with Intel *accidentally* picking up the right pixmap? :) [04:32] so any X program can just allocate a pixmap and read from it? [04:32] Yeah, totally. [04:32] i.e. reading your video memory [04:33] Not sure about that; there may be guards on the reading. [04:33] Anyway, I need to go off to an appointment now. I'll come back and prepare a unity-greeter merge. [04:34] nice === JanC_ is now known as JanC [05:59] jasoncwarner_, what are these rls-p-tracking magic tags? [06:16] good morning [06:26] hey jibel [06:27] 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] Bah, Robert's gone. [07:23] Heh. No mterry, etiher. [07:44] didrocks, good morning [07:44] didrocks, on it [07:45] thanks :) [07:45] Huh. The latest unity-greeter's not in bzr. === tkamppeter_ is now known as tkamppeter [07:59] cjwatson, stgraber: you could also just get the last two values from the result, like call()[-2:] [07:59] cjwatson: your's also looks good [08:00] seiflotfy: right, bug report with test case appreciated [08:02] desrt: I was actually incorrect -- that number assumed that 50% of users couldn't find it, but I failed to neglect that [08:02] 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] 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] fever, sleepless night, feeling horrible, etc. [08:05] pitti: oh :( take care Martin [08:06] (that's why you commented at 2AM… I was afraid it was due to the dentist operation…) [08:06] * didrocks hugs pitti [08:08] didrocks: well, both -- I woke up due to fever, and then my brain didn't let me sleep again [08:08] I didn't have any fever last time [08:09] 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] hmm, ssh is asking my password again: Enter passphrase for key '/home/xclaesse/.ssh/id_rsa' [08:16] that's something that breaks times to times with ubuntu updates... [08:41] xclaesse, might be a problem with gnome-keyring which isnt running properly [08:43] ricotz, hm, ok... [08:44] ricotz, something else, do you know why there are no gdm 3.2/3.4 package, not even on gnome3 ppa? [08:44] is it that broken? [08:44] .xsession-errors might tell you something here [08:45] ricotz, I see nothing related to that in .xsession-errors :( [08:45] yeah, unfortunately gdm 3.2+ has its problems [08:46] is there a way to disable hud? [08:47] ricotz, ok, thanks [08:47] ok got it [08:47] xclaesse, the first few lines mentioning GNOME_KEYRING_CONTROL are important here [08:48] ricotz, I have that: http://fpaste.org/hhvE/ [08:48] xclaesse, if they dont refer to the same tmp folder something goes wrong [08:50] xclaesse, is this running the precise version or the gnome3-ppa one? [08:50] although this output isnt looking normal [08:51] but i might be mistaken [08:51] xclaesse, is the gpg-agent working for you? [08:51] seb128, hi [08:51] hey [08:51] how are you? [08:52] good thanks, how are you? [08:52] salut seb128, la forme? [08:52] seb128, fine ;) [08:52] hey didrocks, yes! you? [08:52] ça va ;) [08:52] seb128, there is a problem with your rhythmbox 2.96 upload :\ [08:53] ricotz, which one? [08:53] didrocks, I was better before checking -changes :p [08:53] seb128, ubuntu1 [08:53] ricotz, how can I know if it works? :p [08:53] ricotz, what problem I mean [08:53] * xclaesse uses only ssh keys [08:53] seb128, oh ;), you dropped some important *.install files [08:53] rhythmbox-oneiric/rhythmbox-mozilla.install [08:53] rhythmbox-oneiric/rhythmbox-plugin-magnatune.install [08:53] rhythmbox-oneiric/rhythmbox-plugin-visualizer.install [08:53] rhythmbox-oneiric/rhythmbox-plugin-zeitgeist.install [08:54] seb128: what do you mean? [08:54] ricotz, I didn't "drop" anything, I bet somebody didn't commit properly to the vcs when doing the previous update [08:54] 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] seb128, no, the vcs contains these file, but the upload itself doesnt [08:55] 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] ricotz, I used bzr builddeb [08:55] pitti is sick and won't be here [08:55] didrocks, ok, no worry ;-) [08:56] seb128, hmm, anyway, could you look at https://launchpad.net/ubuntu/+archive/primary/+files/rhythmbox_2.96-0ubuntu1.debian.tar.gz [08:56] ricotz, I will get it fixed, thanks for pointing it [08:56] seb128, ok [08:57] ricotz, but [08:57] (seb128, i just noticed it today while doing a snapshot) [08:57] ricotz, http://bazaar.launchpad.net/~ubuntu-desktop/rhythmbox/ubuntu/files [08:57] those files are not in the vcs [08:57] http://bazaar.launchpad.net/~ubuntu-desktop/rhythmbox/ubuntu/revision/160 [08:57] oh :\, i see [08:58] they were not added when pitti,dobey did the update [08:58] they probably forgot to bzr add them [08:58] alright [08:58] I take only half the blame :p [08:58] but thanks for pointing it! [08:58] ;) [08:59] Good Morning. [08:59] hey BigWhale [09:00] xclaesse, hmm, so ubuntu or gnome3-ppa version? [09:01] ricotz, oh it's the ppa one actually, that may explain it... [09:02] xclaesse, ok, i am running the ppa version too here, but without a problem [09:02] but with a gnome-shell sesssion which might matter [09:02] ricotz, hm, I see there is an update of g-k in your ppa [09:02] maybe that will fix it :) [09:03] there were just translation fixes in it [09:03] ricotz, I have a gnome-shell session as well ;) [09:03] but of course there a newer version of the other g-k part too which arent there yet [09:30] ricotz: any unforeseeable trouble with the backports or is everything good? [09:30] pitti: no team meeting today? [09:30] Sweetshark, seems fine so far, there is no build ready for testing yet though -- building in ppa:ricotz/ppa [09:31] seb128, do you mind sponsoring http://people.ubuntu.com/~ricotz/sponsor/cheese_3.3.90-0ubuntu3_3.3.90-0ubuntu4.debdiff ? [09:32] ricotz, can do, you didn't want to do the .92 update while you are at it? ;-) [09:33] ricotz: great. no hurry, just wanted to know if there is any trouble ;) [09:33] seb128, hmm, right, i just wanted to get rid of the annoying conflict ;), so i guess please upload u4 for now [09:33] ricotz, ok [09:34] Sweetshark, not yet ;) lucid amd64 built :P [09:36] Sweetshark, the problem will be the oneiric amd64 while the ppa builder might run out of space, natty amd64 got one which will work === jml` is now known as jml === mpt_ is now known as mpt [11:20] cnd, I think you broke my touchpad :-) === geser_ is now known as geser [11:33] (reported bug 960108) [11:33] 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] pitti, hi === greyback is now known as greyback|lunch [12:02] tkamppeter, he's unwell and not working today [12:05] lol, this is brilliant: https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/d30ae1c692ff53c3?pli=1 === chrisccoulson_ is now known as chrisccoulson [12:06] 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] tkamppeter, that's fine, I guess you can sync them later once pitti uploads to Debian [12:13] seb128, thanks. [12:14] yw [12:21] Is precise switching to 3.3 kernel or we're 'stuck' with 3.2? [12:22] this is rather a question for #ubuntu-kernel [12:23] but the answer is 3.2 with some bug fixes from the newer versions [12:24] well, with the new maintenance model for LTS, we will get the support from newer hw for 2 years [12:24] but again, not something for that channel :) [12:27] Thanks. You guys are all full of <3. Happy. :) [12:30] uh, so disabling hud by disabling the shortcut breaks any shortcut needing alt? [12:39] tjaalton, bug #945816 [12:39] 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] seb128: thank you [12:40] tjaalton, yw [12:40] tjaalton, what an idea to want to disable the hud :p [12:40] seb128: yeah, who would've thought ;) === greyback|lunch is now known as greyback [12:41] one more reason for some to install ccsm :/ [12:41] tjaalton, we have an increasing number of bugs because people turn off stuff and hit untested configs and bugs [12:42] the options must be hidden harder then :) [12:42] tjaalton, it's making me reconsider on options, I start leaning toward the reducing them [12:42] tjaalton, well I think we should stop supporting people trying to use unity without i.e hud or appmenu [12:42] like either you use unity as designed or you don't like it and use something else [12:42] hopefully unity is going enough that you use it ;-) [12:43] hud is constantly getting on the way though [12:43] still? the tapping issues for resolved in 5.6 we didn't get a lot of complains recently [12:44] well it's usually my fingers not keeping up, so while it technically should work it's not always so good for me :) === fenris is now known as Guest87935 [12:44] hard to explain [12:44] btw, objections on adding intuos5 support in libwacom? [12:45] i'm thinking of getting one, might replace my mouse.. [12:45] tjaalton, no idea what is untuos5 ;-) [12:45] wacom [12:45] with multitouch [12:45] well, you are the maintainer, your call, I've no option on that ;-) [12:45] ok, it's a new "feature" though it just adds the device definitions.. [12:46] needs driver support too of course, that's FFe material I guess [12:46] do it, it's easy enough to revert if that creates really issues [12:46] right [12:46] yeah, the driver side is likely a ffe [12:47] just for the record... indicator-weather is driving me crazy :> [12:47] BigWhale: you're not the only one [12:48] what's wrong with it? [12:48] crashes after a few hours of use [12:48] constantly crashing [12:48] been like that for a year [12:48] ie. from the start [12:51] luckily it's opensource so we can fix it ;-) [12:51] right [12:52] i did try to look at it once but then got other stuff to work on [12:52] I probably will... [12:57] good morning [12:57] desrt, morning! [12:58] pitti: ricotz rightfully said we should sync openclipart from debian. would you do that? [13:00] Sweetshark, unfortunately, pitti isnt around today [13:00] ah, meh [13:01] maybe didrocks likes to do it ^ [13:04] Sweetshark: it's a sync? openclipart source package, right? [13:09] didrocks: right [13:09] seb128: any new hud explosions since last night? [13:09] or am i in the clear for a change? :) [13:10] desrt, no but I just uploaded your new version today [13:10] oh [13:10] i thought you did that yesterday [13:10] i'll ask you the same question tomorrow, then :) [13:10] desrt, it slipped out due to GNOME 3.3.92 busyness ;-) [13:10] ack. [13:10] desrt, works fine for me in any case [13:11] * desrt has learnt to expect exotic races when dbusmenu is involved :) [13:11] just because it works for you doesn't mean there aren't edge cases to iron out [13:11] desrt, you still have some hud bugs assigned though, the DoS stuff and the stripping [13:11] indeed [13:11] the dbus message work as well [13:11] most of what's left there is work in dbusmenu, though [13:17] jbicha, hey [13:18] 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] didrocks, :-( [13:19] didrocks, do you need help? [13:19] pitti: hey. what's the story with the language selector panel? [13:19] desrt, he's off sick [13:19] ah [13:19] seb128: no, just taking time [13:19] but thanks :) [13:19] desrt, what about the language selector? [13:19] didrocks, yw ;-) [13:19] seb128: when i click the icon there's a bit of a delay and then a new window opens [13:20] desrt, right, rodrigo was supposed to improve the upstream region panel enough so we use that [13:20] desrt, that was before rodrigo left Canonical though [13:20] i see [13:20] desrt, nobody had time to pick it up this cycle [13:20] so next cycle [13:20] fair enough [13:25] seb128: is there any gconf user left in g-s-d after the keybindings? [13:25] desrt, yes [13:25] what else? [13:25] desrt, the gsettings to gconf glue (I was pondering turning it off by default on precise though) [13:25] ah. right. [13:26] like the code which replicates proxy settings etc to gconf [13:26] it almost seems like we could abuse that code to deal with the keybindings [13:26] desrt, it feels like stacking hacks on hacks [13:26] i disagree.... [13:26] i was going to patch the control centre in a somewhat similar way [13:27] for the wm keys, have a map of gsettings keys and their corresponding 'old' locations in gconf [13:27] as a way of keeping the surface area of the patch as small as possible [13:28] 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] desrt, is that your understanding as well? [13:29] yes [13:29] but i took a look at g-c-c as well last night [13:29] 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] the way it handles things i'm not so sure that it will be easy to cleanly separate like that [13:29] ie: separate gconf vs. gsettings [13:29] 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] desrt, can't we just write wm to both? [13:29] and just do it like that [13:30] yes. that's the plan [13:30] seb128: bad pitti! :) [13:30] when it sees a write to gsettings, it will do the appropriate gconf write [13:30] dobey, bad you to not do a merge request I guess? ;-) [13:30] desrt, sounds good to me [13:30] seb128: so my next logic is that we already have the migration code in g-s-d.... [13:31] seb128: if you tell me we could rip that out entirely then i think we should do it [13:31] desrt, do you want to try dropping both patches and see if things just work? [13:31] seb128: i did do a merge proposal for it [13:31] seb128: i guess WM keybindings would stop working :) [13:31] desrt, why? [13:31] (for compiz) [13:31] desrt, the gsettings<->gconf glue should do the replication [13:31] it replicates keybindings? [13:32] desrt, you don't want to know what that code does [13:32] okay :) [13:32] desrt, I will tell you anyway :p [13:32] well, let me check something [13:32] desrt, it parses all the installed .convert to get the mapping [13:32] i have an unpatched g-c-c here [13:32] let me try to set some keybindings and see if they land in gconf or not [13:32] desrt, and use it to write any key listed there to gconf [13:32] uh [13:32] desrt, so any gsettings key in a .convert will be written to gconf [13:32] the one-time GConf conversion files, you mean? [13:32] desrt, yes [13:33] oi. [13:33] desrt, that's how it gets the mapping [13:33] that's.... thorough [13:33] and just a tiny bit INSANE [13:33] lol [13:33] I knew you would like it ;-) [13:33] it's ballsy [13:33] and somewhat effective [13:33] seb128: https://code.launchpad.net/~dobey/ubuntu/precise/rhythmbox/prereleases-2-95-5/+merge/96671 and those files are in the .diff :) [13:33] I was pondering addering a whitelist list of keys [13:33] GAAAH! STOP remapping my kbd on upgrades [13:33] 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] hallyn: indeed [13:34] hallyn, we don't do that [13:34] Alt+F4 doesn't work for me under Unity any more :( [13:34] desrt, well I hate writting back to applications gconf tree, it's just a waste [13:34] dobey, wfm [13:34] seb128: ya. that's totally stupid. [13:34] it should only be for various 'well known values' [13:34] things like proxy, etc [13:35] desrt, right, what I was just saying, I was pondering building a whilelist with a dozen of keys [13:35]