[00:48] rickspencer3: good evening [01:46] * desrt downloads the beta [02:01] chrisccoulson: Another bug the desktop might want to take a look and reply. gnome bug 613509 forwarded from bug 531491 [02:01] Gnome bug 613509 in general "Switch "Shut Down" to "Switch Off" and "Suspend" to "Sleep"" [Trivial,Assigned] http://bugzilla.gnome.org/show_bug.cgi?id=613509 [02:01] Launchpad bug 531491 in gnome-power-manager "Switch "Shut Down" to "Switch Off" and "Suspend" to "Sleep"" [Undecided,Fix released] https://launchpad.net/bugs/531491 [02:24] desrt, hi [03:27] /c/c [06:44] Good morning [06:46] Good morning :) [08:02] good morning [08:02] bonjour didrocks [08:03] Guten Morgen pitti, did you have a good week-end, [08:03] yes, it was great; went hiking on Saturday, and had a Taekwondo training camp yesterday [08:04] my body is aching everywhere now :-P [08:04] didrocks: how was your's? [08:06] pitti: excellent. Lot of walking though the town with Julie as the weather begins to be a little bit better :) [08:11] yeah, it's finally spring time here, too (except that yesterday it was raining like mad) === tkamppeter_ is now known as tkamppeter [08:14] I'm off for ~ 1 hour for a doctor appointment and supermarket [08:14] see you pitti [08:24] hello there! [08:29] hey seb128, how was your week-end? [08:35] hello didrocks, good, what about you? [08:36] seb128: yeah, the weather at least enables to walk outside, it's good :) [08:36] does it sometime stop going out? [08:37] * seb128 goes for a walk every weekened [08:39] * didrocks don't like to walk when it's raining [08:40] Whyever not? :) [08:41] Evening, didrocks :) [08:41] good evening RAOF :) [08:43] didrocks: Have you seen https://code.launchpad.net/~raof/netbook-remix-launcher/fix-bug-467474/+merge/21349 ? [08:43] good evening RAOF [08:43] seb128: Good morning :) [08:43] didrocks: I know you were busy last week, so it may have slipped through. [08:46] RAOF: right, I wasn't subscribed to merges, looking at this now. Thanks! [09:01] RAOF: sweet, that should fix most of issues with OpenGL driver which doesn't support well clutter [09:11] tseliot, hey [09:11] hi seb128 [09:12] tseliot, thanks for fixing this nautilus crash [09:13] seb128: no problem, it was affecting me too and I found it a bit annoying ;) [09:13] ;-) [09:13] I need to check with bratsche why it was crashing though [09:14] I'm wondering if there is a bug in gtk too [09:14] seb128: there is another problem now. Compiz' sync to vblank doesn't seem to work on the 2nd screen [09:14] seb128: yes, I was planning on asking him about that [09:15] I think that patch relied on another patch that he wrote to set the colourmap [09:15] bonjour seb128! had a nice weekend? [09:15] hi pitti [09:15] hey pitti [09:15] tseliot: hey Alberto, how are you? [09:15] pitti, yes, out of freaking out on saturday when reading my emails ;-) [09:15] morning [09:15] seb128: yes, I'm terribly sorry about that [09:15] pitti, what about you? [09:16] lut huats [09:16] pitti: much better now, thanks. You? [09:16] hello seb128 [09:16] I prepared a fixed cdbs now, and this time I also added four test cases [09:16] pitti, not your fault, I kept running around on friday saying we should unfreeze before friday evening [09:16] seb128: I was hiking on Saturday, and had a Taekwondo training camp yesterday *rubbing bones* [09:16] was great [09:16] good ;-) [09:16] :-) [09:16] seb128: well, it was my fault; should've tested it better [09:16] but oh well, things happen [09:16] right [09:16] I don't blame you [09:17] test cases FTW :) [09:17] I'm unhappy about how much the unfreezing took after beta was announced [09:17] it perfectly reproduces the bug now [09:17] we would have noticed when people were still around if it didn't take them hours to flush the queue [09:19] seb128: we talked about that with chriscoulson and cjwatson on Saturday (about not unfreezing on Friday when it's becoming late for a part of the world), not sure that had any needful conclusion [09:20] I told them on friday that it was a good idea [09:20] but no point to discuss it for ages now, things have been fixed quickly thanks to people who hang around on weekend ;-) [09:21] I understand the need for freezes but once it was clear there was no respinning but just announces to send they could have let the uploads through [09:21] that was early in the afternoon [09:21] it some some hours to unfeeze and then again some hours for steve to accept uploads from the queue [09:41] heya good morning folks [09:43] TheMuso: can I assign bug 528524 to you? you already seem to have started debugging it; it seems that resampling in PA/alsa is broken on ARM? might there be some platform specific code to optimize resampling? [09:43] Launchpad bug 528524 in pulseaudio "Sound not working in all apps on dove" [High,Confirmed] https://launchpad.net/bugs/528524 [09:43] good morning baptistemm [09:44] heya didrocks [09:44] is it still possible to add an apport hook to a package now? [09:45] baptistemm, yes [09:45] lut baptistemm [09:45] I think a hook for bluez would be really valuable [09:45] http://bazaar.launchpad.net/~bmillemathias/apport/bluez-support/annotate/head:/source_bluez.py [09:46] can you open a bug about this and subscribe ubuntu-sponsors? [09:46] sure, I just wanted to make sure it was okay [09:48] pitti, is there any way to install a package temporarly for apport hook? getfacl is not installed by default but would be useful for /dev/rfkill [09:48] baptistemm, it's ok in any case if the change doesn't go in lucid it will go in lucid+1 so still good to have it on a bug [09:51] baptistemm: sorry, no; you could try using ctypes and use libacl, though [09:51] seb128, k, but I think it's still on-progress, I need to tweak some ouput of the commands [09:52] seb128: but if you just want to know whether the user has the fg console, you could evaluate ck-list-sessions and/or os.access('/dev/rfkill', 'w') [09:52] baptistemm, ^ I think that was for you [09:52] argh, sorry, yes [09:53] pitti, okay [10:00] hello everyone [10:03] hey chrisccoulson, how are you? [10:03] hey pitti, yeah, i'm good thanks (a bit tired though) [10:03] how are you? [10:06] hey chrisccoulson [10:06] had a good week end? [10:07] seb128 - yeah, it was ok thanks. did you have a good weekend too? [10:07] quite ok [10:07] too short [10:07] yeah, i sometimes think that too ;) [10:08] and I managed to hurt my neck at sport some days ago so my back is hurting now [10:08] ouch, that's not good. i hope that gets better soon [10:12] that's already a bit better, thanks [10:25] \o/ [10:25] libgnome-keyring and gnome-keyring updates, upstream replied to my email and fixed most issues I listed as stopper this weekend [10:26] the updates closes 5 lucid milestoned bugs [10:26] which were all lucid milestoned bugs we had on those [10:26] I started feeling uncomfortable with the new version in lucid [10:27] sweet \o/ [10:28] * didrocks will try to update the new clutter stack today [10:28] didrocks, nice [10:28] pitti, how does your shutdown hook works [10:28] pitti, we receives bugs on random session softwares about it [10:29] seb128: yes, I'm going to triage them in a bit [10:29] pitti, thanks [10:29] we probably should disable the hook again, it's now turning from a small bug fix into a project [10:29] still curious to know what we should be doing about those [10:29] seb128: it's called from /etc/init.d/sendsigs [10:29] to be honest that seem rather buggy to me [10:29] seb128: so, that script sends SIGTERM to all processes [10:29] then waits 10 s [10:29] and then SIGKILLs then [10:30] the latter causes long shutdown times, and indicates hung processes [10:30] seb128: basically, the script collects info for all pids which are still running after 10 s after SIGTERM [10:30] why does it create long shutdown? [10:30] because it waits 10 s for everythign to terminate [10:30] nothing wait on ie g-s-d to be closed to shutdown does it? [10:31] sendsigs does [10:31] oh ok [10:31] I always though that those, ie g-s-d were supposed to just go away when xorg is taken down [10:31] the intention is to TERM first, so that processes have a chacne to clean up, save state, etc. [10:31] seb128: yes, and usually they are [10:31] ie that nothing would ever care about those being still running or not [10:31] I don't get any hung process here except plymouth [10:31] well we do receive bugs on those [10:32] I'm not sure what we are supposed to do with those... [10:32] did you just want to collect datas? [10:32] seb128: actually, at this point in shutdown, there shouldn't be _any_ user processes left [10:32] if you log out, g-session/X should tear them down [10:32] right [10:32] which is why I'm not sure what to do with those [10:32] or how to debug [10:32] seb128: yes, sabdfl asked me to add this to investigate long shutdown times [10:32] seb128: it did uncover a legitimate problem with plymouth [10:33] seb128: as I said, I'll disable it again now and then triage the bugs in a day or two [10:33] ok thanks [10:33] good enough for me [10:33] thanks for the explanation, still interesting to know what's going on [10:33] I'm still curious to know why some things are not taken down when the session close though [10:34] I will read your comments on those bugs ;-) [10:34] so, I don't know why those hang so often either [10:35] I'm wondering if one reason could be crash at shutdown [10:35] in which case apport would keep those up long enough for your script to list them [10:35] matej 1428 0.0 1.0 90164 9896 ? Ds 17:44 0:03 /usr/lib/gnome-settings-daemon/gnome-settings-daemon [10:36] since usually the dumping crash part is taking over 10s [10:36] seb128 / pitti - i'm slightly surprised that g-s-d is still around at shutdown [10:36] seb128: here it's in "uninterruptible kernel sleep", and thus unkillable [10:36] pitti, would it be in this state if it was in crash collecting state? [10:36] seb128: that's a plausible cause [10:36] yes, I think so [10:36] k [10:49] seb128: ah, I just got the FFE for policykit-desktop-privileges (bug 455694); do you have a minute to source-NEW it? (it's a really trivial package, just shipping a single .pkla) [10:49] Launchpad bug 455694 in policykit-1 "FFE: Provide some policykit privileges by default on desktops" [Medium,Triaged] https://launchpad.net/bugs/455694 [10:50] seb128: (to main, please; its basically moving out the policy from the udisks package, and adding two more privs) [10:50] pitti, ok [10:56] pitti: I saw you recommited the last gdm changes to bzr branch in -ubuntu3 from Keybuk, but he did also some changes in -ubuntu2 out of tree too and that's not in bzr currently. Do you want me to finish this or it wasiignored on purpose? [10:56] urg gdm, I need to look at gdmsetup and get that in today [10:56] didrocks, or are you on that now? [10:57] seb128: I was jumping on it just once clutter is finished and tested enough [10:57] ok thanks [10:57] now that I know that the issue should be around seteuid :) [10:57] I'm still busy with other things [10:57] ask pitti maybe [10:57] didrocks: can you rebase the pending changes on top of 2.29.92-0ubuntu3? [10:58] he can probably tell you quickly what you are doing wrong with seteuid [10:58] since that was uploaded, bzr should have it, too [10:58] yes, I'm happy to help out here [10:58] pitti: sure, but 2.29.92-0ubuntu2 is not into bzr [10:58] pitti: ok, I will ping you about the seteuid issue once clutter is finished :) [10:58] hm, it is here, from RoberT? [10:59] "bzr missing" says up to date [10:59] pitti: Keybuk didn't take the branch, it was an unreleased version [10:59] pitti, no, bzr lacks an upload from keybuk [10:59] seb128: ^ I thought I committed that [10:59] pitti, you commited 0ubuntu3 not 0ubuntu2 [10:59] pitti: you commited 2.29.92-0ubuntu3 content, not 2.29.92-0ubuntu2 [10:59] oh, I see [10:59] pitti, there were 2 of those [10:59] Robert's 2.29.92-0ubuntu2 is misisng [10:59] sorry for not explaining that well enough :) [11:00] I just saw the 0ubuntu3 upload from Keybuk [11:00] right, that'll need some untangling, to rebase Robert's changes on top of 2.29.92-0ubuntu3 and commit the 0ubuntu2 from Scott [11:00] pitti: robert's one is not ready to be uploaded (it contains my work too) [11:00] right [11:00] didrocks: right, that should be 0ubuntu4 UNRELEASED now [11:00] exactly [11:01] didrocks: so, wrt. your original question, it wasn't done on purpose [11:01] pitti: ok, I'll do it in the same round, the bzr history will be a little bit strange, but well… [11:01] didrocks: let's not worry about it too much [11:01] you should be able to cherry-pick the comment from the proper bzr branch that I committed to ;-) [11:02] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/gdm/lucid/revision/198 [11:02] s/comment/commit/ [11:02] no, those are unmergeable [11:02] I said cherry-pick, not merge [11:02] Keybuk: getting the uploaded diffs isn't a problem [11:02] it's retroactively fixing the history of the real bzr branch to match reality ;) [11:02] bzr merge -c tag:2.29.92-0ubuntu2 lp:ubuntu/gdm [11:03] erm, -r surely? there should be two commits? [11:03] no, -c [11:03] Keybuk: you don't change package and do dch -r/debcommit -r separately? [11:03] I did, but it doesn't look like I pushed before the importer saw it [11:03] so there's just one commit there [11:03] ah, ok [11:04] Revision ID: james.westby@ubuntu.com-20100311200642-douwocvebf20drrg [11:04] that means "importer beat bzr push" [11:04] ah, this guy james_w commits an awful lot of code these days! [11:04] * pitti hugs james_w [11:05] it's a huge shame that -desktop aren't using the lp:ubuntu/* branches :-( [11:05] they work really well for everything else [11:07] Keybuk, right, for some value of work well [11:07] Keybuk, like having to wait half an hour to get your source [11:07] what's the status of hal in lucid? [11:10] hyperair: we install it by default, but not started on boot; gnome-power-manager will use it if the system doesn't support XBACKLIGHT [11:10] hyperair: it's dbus-activated now [11:11] pitti: i see. i wonder how that works with podsleuth.. [11:12] hmm i think podsleuth relies on hal to do its polling or whatever [11:12] this is problematic. [11:12] at some point we'll need something like shallow branches/light checkouts, to avoid downloading tons of uninteresting history [11:12] you mean like "bzr checkout --lightweight"? :) [11:12] that's slow [11:13] well, it was a year ago, havent' tried it since then [11:13] bzr branch lp:ubuntu/upstart 9.39s user 0.58s system 20% cpu 47.727 total [11:13] bzr co --lightweight lp:ubuntu/upstart 0.72s user 0.20s system 2% cpu 38.880 total [11:13] at some point we'll switch over, too, but it's not a priority right now [11:14] it's really nice when upstream code is in bzr [11:14] and we still need to honor Vcs-Bzr: for packages where the import fails (like cdbs or sysvinit) [11:14] but otherwise it doesn't bring us a lot [11:14] seb128: well, one obvious on-topic thing is brings you is that uploads by other people are automatically committed to your bzr repo [11:15] and it brings us that everything in Ubuntu uses one set of repositories [11:15] pitti: sysvinit has an lp:ubuntu/sysvinit branch [11:15] that's karmic [11:15] cdbs also looks like it has an lp:ubuntu/sysvinit branch [11:15] it didn't import any lucid version [11:15] similar to cdbs [11:15] Keybuk: yes, but they are out of date [11:15] $ time bzr get lp:ubuntu/gnome-panel [11:15] real0m58.496s [11:16] see, that's hardly "half an hour" [11:17] and you only need do it once; ever after "bzr pull" will update it - even to new upstream versions [11:17] well, that's only one side of the story; you have to push back orig.tar.gz's to the (slim) upstream on commit, and additionally upload the package [11:17] that will get better once we have builds from branches [11:17] pitti: no you don't, you only push back the diff between orig.tar.gz [11:19] Keybuk: do you know how to get a new tarball into the pristine-tar bzr? [11:19] pitti: merge-upstream [11:19] last time I wondered about this, I got told "that doesn't work yet" [11:19] oh, nice [11:20] is there any clear documentation about what the workflow is supposed to be? [11:20] bzr merge-upstream --version=1.0.0 ../foo-1.0.0.tar.gz [11:20] and what commands to use while doing an update [11:20] seb128: yes, plenty on the distributed development wiki pages [11:20] Keybuk, plenty is the issue, we need something clear everybody follows, not a zillion of different ways [11:20] that's precisely my point [11:20] this is a single way that everyone should be following [11:21] we fail at communicating it properly though [11:21] no really, when upstream has a bzr branch, we should use bzr merge-upstream --version=1.0.0 ../foo-1.0.0.tar.gz ../foo [11:21] which leads to people not using it [11:21] didrocks: it usually figures that last bit out itself [11:21] so, not sure about what differences are involved between the two "modes" [11:21] Keybuk: oh really? should have a try then :) [11:21] the true way seems to change every second month [11:22] seb128: I think yours is the only team that isn't using this [11:22] and it hasn't changed design in a long time [11:22] there's been plenty of UDS demos and sessions about it [11:22] Keybuk, I'm sure you will find plenty of people not using what you described [11:22] (assuming we don't count kernel for a moment) [11:22] most people still just upload [11:22] and don't use bzr [11:23] sure, and the great thing about the UDD work is that it doesn't matter if they do! [11:23] $ time bzr get lp:ubuntu/gdm [11:23] \ 28805KB 122KB/s | Fetching revisions:Inserting stream [11:23] still running... [11:23] it takes me like 30 seconds to apt-get it or get the ubuntu-desktop bzr [11:23] and it takes you what, a minute to bzr get it? [11:23] and you only need to bzr get once [11:23] no [11:24] it's running for over 5 minutes now [11:24] and still running [11:24] grrr [11:24] it's already 10 times slower [11:24] * ogra whacks gnome-terminal [11:24] and still going [11:25] hum ... seems it is not gnome-terminal that makes my desktop stuck with the currently focused app :/ [11:25] * ogra cant alt-tab anymore and the mouse constantly stays as text cursor [11:25] even if it was 10 times slower, that'd be only 5 minutes to branch - which is hardly forever [11:25] i cant click on anything either [11:25] anyway, I give up [11:25] you're clearly not interested [11:25] if you don't want to use your colleague's work, that's your business ;-) [11:26] ~/.xsession-errors shows a lot of glib messages every time i alt-tab or click on something [11:26] but don't complain when the rest of us do [11:26] and it causes more work for you [11:26] well, I think we'll migrate eventually, but not in one big leap [11:26] Keybuk, you are not being constructive there [11:26] first, we'd loose the history from existing bzr, and second it's still too painful for some packages [11:26] dropping vcs-bzr: one by one seems fine [11:26] Keybuk, not respecting the vcs being used and not caring about other people workflow is not constructive [11:27] real 6m58.771s [11:27] but right now it is a huge regression in performance, so we don't just want to throw away an established workflow wholesale for little benefit [11:27] to get gdm bzr there [11:27] Keybuk, we are interested by what is making job easier [11:28] (as I said, throwing it away piece by piece is fine) [11:28] not harder [11:28] your unique branches, in which you don't even have buildable or editable source is harder for me [11:29] bzr bd-do and you are there [11:29] it's not that hard [11:29] using james_w's work isn't hard either [11:29] no, but there is no reason everybody should not make efforts [11:29] we will slightly get there and use the common workflow [11:29] but meanwhile you can try to be nice citizen when touching something not converted yet [11:30] I do generally try to [11:30] but will frequently fail [11:30] and we will frequently drop your changes :-( [11:30] and I will frequently complain to your line manager when you do [11:30] well you can, but you are the one at fail [11:30] I still get a lot of bad merge requests against apport, too, so I feel your pain [11:31] sorry, I don't agree [11:31] debcheckout get you the right source [11:31] if you upload, and find a version already there [11:31] then you have no excuse for dropping changes [11:31] ever [11:31] but right now there's no way around having Vcs-Bzr: still, I'm afraid [11:31] except bloody mindedness [11:31] right, when we do it it's not on purpose [11:31] yes you do [11:31] every time [11:31] drop changes> uh, did we? [11:31] and you know it [11:31] when? [11:31] except for the gdm ubuntu2 upload which I just missed (just committed ubuntu3) [11:31] we did merge your gdm changes in our bzr [11:32] I don't think every time is fair [11:32] debcheckout -> doesn't do lp:ubuntu/* [11:32] we should fix that [11:32] only if it can also validate that the branch is current [11:32] (which sohuldn't be a problem with rmadison) [11:32] but would be nice to have, indeed [11:33] make it a different tool, please [11:33] ubucheckout [11:34] Laney: it's from a debian source package [11:34] and is a common tool between Debian and Ubuntu [11:34] hulp ! [11:34] I know, and I often use it to get Debian packaging branches [11:34] if it starts pulling from LP then it will break my workflow [11:34] i seem to hit a heavy glib bug where i cant get my focus out of a running app [11:34] Laney, well it's your issue [11:35] Laney, seems normal that on ubuntu it pulls the ubuntu source [11:35] Laney, that's what most people working on ubuntu want usually [11:35] it seems normal that it pulls the branch defined in the control file to me [11:35] Laney, you should be using a flag telling to use the debian vcs if you want that [11:35] Laney, out of the fact that we don't specify canonical bzr locations there [11:35] we would have to change every source package for nothing [11:36] indeed, that's why I think it should be a separate mode [11:36] I think it should be default [11:36] with an option to turn it off [11:36] the default should be what makes sense on ubuntu [11:36] and at one point we'll hopefully have the entire archive in bzr, so that we can stop worrying [11:36] pitti, well that doesn't fix Laney's usecase to not want to ubuntu source but the debian one [11:37] seb128: I meant we wouldn't need debcheckout any more [11:37] debcheckout -> get from Debian, bzr get -> get from LP [11:37] right [11:37] that's my workflow [11:37] bzr get what? [11:37] whatever is appropriate [11:37] not getting into your argument ;) [11:37] well that's the interest of debcheckout [11:38] to not have to specify that [11:38] or to figure what it is [11:38] right now that should be first the control Vcs if one [11:38] and if there is none default to the canonical location [11:39] and ignore it if it's not LP? [11:39] no [11:39] when merging with debian you should rename the Vcs if that's not the one used for Ubuntu [11:39] or drop it [11:39] or right [11:39] I remember now [11:40] (was just browsing my history for why I wasn't using the right gdm branch in the first place) [11:40] * ogra_ curses [11:40] quest tmp% debcheckout gdm [11:40] declared bzr repository at https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu [11:40] bzr branch https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu gdm ... [11:40] bzr: ERROR: Invalid http response for https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu/.bzr/branch-format: Unable to handle http code 405: expected 200 or 404 for full response. [11:40] checkout failed (the command above returned a non-zero exit code) [11:40] -- [11:40] I tried [11:40] and when I got that, I checked whether there was an lp:ubuntu/gdm with the right version === ogra_ is now known as ogra [11:40] and assumed (not unreasonably) that you must have switched and forgotten to update the header [11:41] and that's why I used the lp:ubuntu/gdm branch [11:41] and since it was already checked out in my lucid folder, I've just used "bzr pull" ever since [11:42] k [11:42] we will revisit things next cycle [11:42] but now we have other issues to work on for lucid [11:43] on the subject of bzr.... [11:43]