[00:48] <desrt> rickspencer3: good evening
[01:46]  * desrt downloads the beta
[02:01] <nigelb> chrisccoulson: Another bug the desktop might want to take a look and reply.  gnome bug 613509 forwarded from bug 531491
[02:24] <rickspencer3> desrt, hi
[03:27] <TheMuso> /c/c
[06:44] <pitti> Good morning
[06:46] <RAOF> Good morning :)
[08:02] <didrocks> good morning
[08:02] <pitti> bonjour didrocks
[08:03] <didrocks> Guten Morgen pitti, did you have a good week-end,
[08:03] <pitti> yes, it was great; went hiking on Saturday, and had a Taekwondo training camp yesterday
[08:04] <pitti> my body is aching everywhere now :-P
[08:04] <pitti> didrocks: how was your's?
[08:06] <didrocks> pitti: excellent. Lot of walking though the town with Julie as the weather begins to be a little bit better :)
[08:11] <pitti> yeah, it's finally spring time here, too (except that yesterday it was raining like mad)
[08:14] <pitti> I'm off for ~ 1 hour for a doctor appointment and supermarket
[08:14] <didrocks> see you pitti
[08:24] <seb128> hello there!
[08:29] <didrocks> hey seb128, how was your week-end?
[08:35] <seb128> hello didrocks, good, what about you?
[08:36] <didrocks> seb128: yeah, the weather at least enables to walk outside, it's good :)
[08:36] <seb128> 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] <RAOF> Whyever not? :)
[08:41] <RAOF> Evening, didrocks :)
[08:41] <didrocks> good evening RAOF :)
[08:43] <RAOF> didrocks: Have you seen https://code.launchpad.net/~raof/netbook-remix-launcher/fix-bug-467474/+merge/21349 ?
[08:43] <seb128> good evening RAOF
[08:43] <RAOF> seb128: Good morning :)
[08:43] <RAOF> didrocks: I know you were busy last week, so it may have slipped through.
[08:46] <didrocks> RAOF: right, I wasn't subscribed to merges, looking at this now. Thanks!
[09:01] <didrocks> RAOF: sweet, that should fix most of issues with OpenGL driver which doesn't support well clutter
[09:11] <seb128> tseliot, hey
[09:11] <tseliot> hi seb128
[09:12] <seb128> tseliot, thanks for fixing this nautilus crash
[09:13] <tseliot> seb128: no problem, it was affecting me too and I found it a bit annoying ;)
[09:13] <seb128> ;-)
[09:13] <seb128> I need to check with bratsche why it was crashing though
[09:14] <seb128> I'm wondering if there is a bug in gtk too
[09:14] <tseliot> seb128: there is another problem now. Compiz' sync to vblank doesn't seem to work on the 2nd screen
[09:14] <tseliot> seb128: yes, I was planning on asking him about that
[09:15] <tseliot> I think that patch relied on another patch that he wrote to set the colourmap
[09:15] <pitti> bonjour seb128! had a nice weekend?
[09:15] <tseliot> hi pitti
[09:15] <seb128> hey pitti
[09:15] <pitti> tseliot: hey Alberto, how are you?
[09:15] <seb128> pitti, yes, out of freaking out on saturday when reading my emails ;-)
[09:15] <huats> morning
[09:15] <pitti> seb128: yes, I'm terribly sorry about that
[09:15] <seb128> pitti, what about you?
[09:16] <seb128> lut huats
[09:16] <tseliot> pitti: much better now, thanks. You?
[09:16] <huats> hello seb128
[09:16] <pitti> I prepared a fixed cdbs now, and this time I also added four test cases
[09:16] <seb128> pitti, not your fault, I kept running around on friday saying we should unfreeze before friday evening
[09:16] <pitti> seb128: I was hiking on Saturday, and had a Taekwondo training camp yesterday *rubbing bones*
[09:16] <pitti> was great
[09:16] <seb128> good ;-)
[09:16] <tseliot> :-)
[09:16] <pitti> seb128: well, it was my fault; should've tested it better
[09:16] <pitti> but oh well, things happen
[09:16] <seb128> right
[09:16] <seb128> I don't blame you
[09:17] <pitti> test cases FTW :)
[09:17] <seb128> I'm unhappy about how much the unfreezing took after beta was announced
[09:17] <pitti> it perfectly reproduces the bug now
[09:17] <seb128> we would have noticed when people were still around if it didn't take them hours to flush the queue
[09:19] <didrocks> 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] <seb128> I told them on friday that it was a good idea
[09:20] <seb128> but no point to discuss it for ages now, things have been fixed quickly thanks to people who hang around on weekend ;-)
[09:21] <seb128> 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] <seb128> that was early in the afternoon
[09:21] <seb128> it some some hours to unfeeze and then again some hours for steve to accept uploads from the queue
[09:41] <baptistemm> heya good morning folks
[09:43] <pitti> 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] <didrocks> good morning baptistemm
[09:44] <baptistemm> heya didrocks
[09:44] <baptistemm> is it still possible to add an apport hook to a package now?
[09:45] <seb128> baptistemm, yes
[09:45] <seb128> lut baptistemm
[09:45] <baptistemm> I think a hook for bluez would be really valuable
[09:45] <baptistemm> http://bazaar.launchpad.net/~bmillemathias/apport/bluez-support/annotate/head:/source_bluez.py
[09:46] <seb128> can you open a bug about this and subscribe ubuntu-sponsors?
[09:46] <baptistemm> sure, I just wanted to make sure it was okay
[09:48] <baptistemm> 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] <seb128> 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] <pitti> baptistemm: sorry, no; you could try using ctypes and use libacl, though
[09:51] <baptistemm> seb128, k, but I think it's still on-progress, I need to tweak some ouput of the commands
[09:52] <pitti> 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] <seb128> baptistemm, ^ I think that was for you
[09:52] <pitti> argh, sorry, yes
[09:53] <baptistemm> pitti, okay
[10:00] <chrisccoulson> hello everyone
[10:03] <pitti> hey chrisccoulson, how are you?
[10:03] <chrisccoulson> hey pitti, yeah, i'm good thanks (a bit tired though)
[10:03] <chrisccoulson> how are you?
[10:06] <seb128> hey chrisccoulson
[10:06] <seb128> had a good week end?
[10:07] <chrisccoulson> seb128 - yeah, it was ok thanks. did you have a good weekend too?
[10:07] <seb128> quite ok
[10:07] <seb128> too short
[10:07] <chrisccoulson> yeah, i sometimes think that too ;)
[10:08] <seb128> and I managed to hurt my neck at sport some days ago so my back is hurting now
[10:08] <chrisccoulson> ouch, that's not good. i hope that gets better soon
[10:12] <seb128> that's already a bit better, thanks
[10:25] <seb128> \o/
[10:25] <seb128> libgnome-keyring and gnome-keyring updates, upstream replied to my email and fixed most issues I listed as stopper this weekend
[10:26] <seb128> the updates closes 5 lucid milestoned bugs
[10:26] <seb128> which were all lucid milestoned bugs we had on those
[10:26] <seb128> I started feeling uncomfortable with the new version in lucid
[10:27] <didrocks> sweet \o/
[10:28]  * didrocks will try to update the new clutter stack today
[10:28] <seb128> didrocks, nice
[10:28] <seb128> pitti, how does your shutdown hook works
[10:28] <seb128> pitti, we receives bugs on random session softwares about it
[10:29] <pitti> seb128: yes, I'm going to triage them in a bit
[10:29] <seb128> pitti, thanks
[10:29] <pitti> we probably should disable the hook again, it's now turning from a small bug fix into a project
[10:29] <seb128> still curious to know what we should be doing about those
[10:29] <pitti> seb128: it's called from /etc/init.d/sendsigs
[10:29] <seb128> to be honest that seem rather buggy to me
[10:29] <pitti> seb128: so, that script sends SIGTERM to all processes
[10:29] <pitti> then waits 10 s
[10:29] <pitti> and then SIGKILLs then
[10:30] <pitti> the latter causes long shutdown times, and indicates hung processes
[10:30] <pitti> seb128: basically, the script collects info for all pids which are still running after 10 s after SIGTERM
[10:30] <seb128> why does it create long shutdown?
[10:30] <pitti> because it waits 10 s for everythign to terminate
[10:30] <seb128> nothing wait on ie g-s-d to be closed to shutdown does it?
[10:31] <pitti> sendsigs does
[10:31] <seb128> oh ok
[10:31] <seb128> I always though that those, ie g-s-d were supposed to just go away when xorg is taken down
[10:31] <pitti> the intention is to TERM first, so that processes have a chacne to clean up, save state, etc.
[10:31] <pitti> seb128: yes, and usually they are
[10:31] <seb128> ie that nothing would ever care about those being still running or not
[10:31] <pitti> I don't get any hung process here except plymouth
[10:31] <seb128> well we do receive bugs on those
[10:32] <seb128> I'm not sure what we are supposed to do with those...
[10:32] <seb128> did you just want to collect datas?
[10:32] <pitti> seb128: actually, at this point in shutdown, there shouldn't be _any_ user processes left
[10:32] <pitti> if you log out, g-session/X should tear them down
[10:32] <seb128> right
[10:32] <seb128> which is why I'm not sure what to do with those
[10:32] <seb128> or how to debug
[10:32] <pitti> seb128: yes, sabdfl asked me to add this to investigate long shutdown times
[10:32] <pitti> seb128: it did uncover a legitimate problem with plymouth
[10:33] <pitti> seb128: as I said, I'll disable it again now and then triage the bugs in a day or two
[10:33] <seb128> ok thanks
[10:33] <seb128> good enough for me
[10:33] <seb128> thanks for the explanation, still interesting to know what's going on
[10:33] <seb128> I'm still curious to know why some things are not taken down when the session close though
[10:34] <seb128> I will read your comments on those bugs ;-)
[10:34] <pitti> so, I don't know why those hang so often either
[10:35] <seb128> I'm wondering if one reason could be crash at shutdown
[10:35] <seb128> in which case apport would keep those up long enough for your script to list them
[10:35] <pitti> matej     1428  0.0  1.0  90164  9896 ?        Ds   17:44   0:03 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
[10:36] <seb128> since usually the dumping crash part is taking over 10s
[10:36] <chrisccoulson> seb128 / pitti - i'm slightly surprised that g-s-d is still around at shutdown
[10:36] <pitti> seb128: here it's in "uninterruptible kernel sleep", and thus unkillable
[10:36] <seb128> pitti, would it be in this state if it was in crash collecting state?
[10:36] <pitti> seb128: that's a plausible cause
[10:36] <pitti> yes, I think so
[10:36] <seb128> k
[10:49] <pitti> 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:50] <pitti> seb128: (to main, please; its basically moving out the policy from the udisks package, and adding two more privs)
[10:50] <seb128> pitti, ok
[10:56] <didrocks> 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] <seb128> urg gdm, I need to look at gdmsetup and get that in today
[10:56] <seb128> didrocks, or are you on that now?
[10:57] <didrocks> seb128: I was jumping on it just once clutter is finished and tested enough
[10:57] <seb128> ok thanks
[10:57] <didrocks> now that I know that the issue should be around seteuid :)
[10:57] <seb128> I'm still busy with other things
[10:57] <seb128> ask pitti maybe
[10:57] <pitti> didrocks: can you rebase the pending changes on top of  2.29.92-0ubuntu3?
[10:58] <seb128> he can probably tell you quickly what you are doing wrong with seteuid
[10:58] <pitti> since that was uploaded, bzr should have it, too
[10:58] <pitti> yes, I'm happy to help out here
[10:58] <didrocks> pitti: sure, but 2.29.92-0ubuntu2 is not into bzr
[10:58] <didrocks> pitti: ok, I will ping you about the seteuid issue once clutter is finished :)
[10:58] <pitti> hm, it is here, from RoberT?
[10:59] <pitti> "bzr missing" says up to date
[10:59] <didrocks> pitti: Keybuk didn't take the branch, it was an unreleased version
[10:59] <seb128> pitti, no, bzr lacks an upload from keybuk
[10:59] <pitti> seb128: ^ I thought I committed that
[10:59] <seb128> pitti, you commited 0ubuntu3 not 0ubuntu2
[10:59] <didrocks> pitti: you commited 2.29.92-0ubuntu3 content, not 2.29.92-0ubuntu2
[10:59] <pitti> oh, I see
[10:59] <seb128> pitti, there were 2 of those
[10:59] <pitti> Robert's 2.29.92-0ubuntu2 is misisng
[10:59] <didrocks> sorry for not explaining that well enough :)
[11:00] <pitti> I just saw the 0ubuntu3 upload from Keybuk
[11:00] <pitti> 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] <didrocks> pitti: robert's one is not ready to be uploaded (it contains my work too)
[11:00] <didrocks> right
[11:00] <pitti> didrocks: right, that should be 0ubuntu4 UNRELEASED now
[11:00] <didrocks> exactly
[11:01] <pitti> didrocks: so, wrt. your original question, it wasn't done on purpose
[11:01] <didrocks> pitti: ok, I'll do it in the same round, the bzr history will be a little bit strange, but well…
[11:01] <pitti> didrocks: let's not worry about it too much
[11:01] <Keybuk> you should be able to cherry-pick the comment from the proper bzr branch that I committed to ;-)
[11:02] <Keybuk> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/gdm/lucid/revision/198
[11:02] <Keybuk> s/comment/commit/
[11:02] <pitti> no, those are unmergeable
[11:02] <Keybuk> I said cherry-pick, not merge
[11:02] <pitti> Keybuk: getting the uploaded diffs isn't a problem
[11:02] <pitti> it's retroactively fixing the history of the real bzr branch to match reality ;)
[11:02] <Keybuk> bzr merge -c tag:2.29.92-0ubuntu2 lp:ubuntu/gdm
[11:03] <pitti> erm, -r surely? there should be two commits?
[11:03] <Keybuk> no, -c
[11:03] <pitti> Keybuk: you don't change package and do dch -r/debcommit -r separately?
[11:03] <Keybuk> I did, but it doesn't look like I pushed before the importer saw it
[11:03] <Keybuk> so there's just one commit there
[11:03] <pitti> ah, ok
[11:04] <Keybuk> Revision ID: james.westby@ubuntu.com-20100311200642-douwocvebf20drrg
[11:04] <Keybuk> that means "importer beat bzr push"
[11:04] <pitti> ah, this guy james_w commits an awful lot of code these days!
[11:04]  * pitti hugs james_w
[11:05] <Keybuk> it's a huge shame that -desktop aren't using the lp:ubuntu/* branches :-(
[11:05] <Keybuk> they work really well for everything else
[11:07] <seb128> Keybuk, right, for some value of work well
[11:07] <seb128> Keybuk, like having to wait half an hour to get your source
[11:07] <hyperair> what's the status of hal in lucid?
[11:10] <pitti> 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] <pitti> hyperair: it's dbus-activated now
[11:11] <hyperair> pitti: i see. i wonder how that works with podsleuth..
[11:12] <hyperair> hmm i think podsleuth relies on hal to do its polling or whatever
[11:12] <hyperair> this is problematic.
[11:12] <pitti> at some point we'll need something like shallow branches/light checkouts, to avoid downloading tons of uninteresting history
[11:12] <Keybuk> you mean like "bzr checkout --lightweight"? :)
[11:12] <pitti> that's slow
[11:13] <pitti> well, it was a year ago, havent' tried it since then
[11:13] <Keybuk> bzr branch lp:ubuntu/upstart  9.39s user 0.58s system 20% cpu 47.727 total
[11:13] <Keybuk> bzr co --lightweight lp:ubuntu/upstart  0.72s user 0.20s system 2% cpu 38.880 total
[11:13] <pitti> at some point we'll switch over, too, but it's not a priority right now
[11:14] <seb128> it's really nice when upstream code is in bzr
[11:14] <pitti> and we still need to honor Vcs-Bzr: for packages where the import fails (like cdbs or sysvinit)
[11:14] <seb128> but otherwise it doesn't bring us a lot
[11:14] <Keybuk> 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] <Keybuk> and it brings us that everything in Ubuntu uses one set of repositories
[11:15] <Keybuk> pitti: sysvinit has an lp:ubuntu/sysvinit branch
[11:15] <pitti> that's karmic
[11:15] <Keybuk> cdbs also looks like it has an lp:ubuntu/sysvinit branch
[11:15] <pitti> it didn't import any lucid version
[11:15] <pitti> similar to cdbs
[11:15] <pitti> Keybuk: yes, but they are out of date
[11:15] <pitti> $ time bzr get lp:ubuntu/gnome-panel
[11:15] <pitti> real0m58.496s
[11:16] <Keybuk> see, that's hardly "half an hour"
[11:17] <Keybuk> and you only need do it once; ever after "bzr pull" will update it - even to new upstream versions
[11:17] <pitti> 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] <pitti> that will get better once we have builds from branches
[11:17] <Keybuk> pitti: no you don't, you only push back the diff between orig.tar.gz
[11:19] <pitti> Keybuk: do you know how to get a new tarball into the pristine-tar bzr?
[11:19] <Keybuk> pitti: merge-upstream
[11:19] <pitti> last time I wondered about this, I got told "that doesn't work yet"
[11:19] <pitti> oh, nice
[11:20] <seb128> is there any clear documentation about what the workflow is supposed to be?
[11:20] <Keybuk> bzr merge-upstream --version=1.0.0 ../foo-1.0.0.tar.gz
[11:20] <seb128> and what commands to use while doing an update
[11:20] <Keybuk> seb128: yes, plenty on the distributed development wiki pages
[11:20] <seb128> Keybuk, plenty is the issue, we need something clear everybody follows, not a zillion of different ways
[11:20] <Keybuk> that's precisely my point
[11:20] <Keybuk> this is a single way that everyone should be following
[11:21] <seb128> we fail at communicating it properly though
[11:21] <didrocks> 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] <seb128> which leads to people not using it
[11:21] <Keybuk> didrocks: it usually figures that last bit out itself
[11:21] <didrocks> so, not sure about what differences are involved between the two "modes"
[11:21] <didrocks> Keybuk: oh really? should have a try then :)
[11:21] <seb128> the true way seems to change every second month
[11:22] <Keybuk> seb128: I think yours is the only team that isn't using this
[11:22] <Keybuk> and it hasn't changed design in a long time
[11:22] <Keybuk> there's been plenty of UDS demos and sessions about it
[11:22] <seb128> Keybuk, I'm sure you will find plenty of people not using what you described
[11:22] <Keybuk> (assuming we don't count kernel for a moment)
[11:22] <seb128> most people still just upload
[11:22] <seb128> and don't use bzr
[11:23] <Keybuk> sure, and the great thing about the UDD work is that it doesn't matter if they do!
[11:23] <seb128> $ time bzr get lp:ubuntu/gdm
[11:23] <seb128> \  28805KB   122KB/s | Fetching revisions:Inserting stream
[11:23] <seb128> still running...
[11:23] <seb128> it takes me like 30 seconds to apt-get it or get the ubuntu-desktop bzr
[11:23] <Keybuk> and it takes you what, a minute to bzr get it?
[11:23] <Keybuk> and you only need to bzr get once
[11:23] <seb128> no
[11:24] <seb128> it's running for over 5 minutes now
[11:24] <seb128> and still running
[11:24] <ogra> grrr
[11:24] <seb128> it's already 10 times slower
[11:24]  * ogra whacks gnome-terminal
[11:24] <seb128> and still going
[11:25] <ogra> 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] <Keybuk> even if it was 10 times slower, that'd be only 5 minutes to branch - which is hardly forever
[11:25] <ogra> i cant click on anything either
[11:25] <Keybuk> anyway, I give up
[11:25] <Keybuk> you're clearly not interested
[11:25] <Keybuk> if you don't want to use your colleague's work, that's your business ;-)
[11:26] <ogra> ~/.xsession-errors shows a lot of glib messages every time i alt-tab or click on something
[11:26] <Keybuk> but don't complain when the rest of us do
[11:26] <Keybuk> and it causes more work for you
[11:26] <pitti> well, I think we'll migrate eventually, but not in one big leap
[11:26] <seb128> Keybuk, you are not being constructive there
[11:26] <pitti> first, we'd loose the history from existing bzr, and second it's still too painful for some packages
[11:26] <pitti> dropping vcs-bzr: one by one seems fine
[11:26] <seb128> Keybuk, not respecting the vcs being used and not caring about other people workflow is not constructive
[11:27] <seb128> real	6m58.771s
[11:27] <pitti> 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] <seb128> to get gdm bzr there
[11:27] <seb128> Keybuk, we are interested by what is making job easier
[11:28] <pitti> (as I said, throwing it away piece by piece is fine)
[11:28] <seb128> not harder
[11:28] <Keybuk> your unique branches, in which you don't even have buildable or editable source is harder for me
[11:29] <seb128> bzr bd-do and you are there
[11:29] <seb128> it's not that hard
[11:29] <Keybuk> using james_w's work isn't hard either
[11:29] <seb128> no, but there is no reason everybody should not make efforts
[11:29] <seb128> we will slightly get there and use the common workflow
[11:29] <seb128> but meanwhile you can try to be nice citizen when touching something not converted yet
[11:30] <Keybuk> I do generally try to
[11:30] <Keybuk> but will frequently fail
[11:30] <seb128> and we will frequently drop your changes :-(
[11:30] <Keybuk> and I will frequently complain to your line manager when you do
[11:30] <seb128> well you can, but you are the one at fail
[11:30] <pitti> I still get a lot of bad merge requests against apport, too, so I feel your pain
[11:31] <Keybuk> sorry, I don't agree
[11:31] <seb128> debcheckout get you the right source
[11:31] <Keybuk> if you upload, and find a version already there
[11:31] <Keybuk> then you have no excuse for dropping changes
[11:31] <Keybuk> ever
[11:31] <pitti> but right now there's no way around having Vcs-Bzr: still, I'm afraid
[11:31] <Keybuk> except bloody mindedness
[11:31] <seb128> right, when we do it it's not on purpose
[11:31] <Keybuk> yes you do
[11:31] <Keybuk> every time
[11:31] <pitti> drop changes> uh, did we?
[11:31] <Keybuk> and you know it
[11:31] <seb128> when?
[11:31] <pitti> except for the gdm ubuntu2 upload which I just missed (just committed ubuntu3)
[11:31] <seb128> we did merge your gdm changes in our bzr
[11:32] <seb128> I don't think every time is fair
[11:32] <Keybuk> debcheckout -> doesn't do lp:ubuntu/*
[11:32] <seb128> we should fix that
[11:32] <pitti> only if it can also validate that the branch is current
[11:32] <pitti> (which sohuldn't be a problem with rmadison)
[11:32] <pitti> but would be nice to have, indeed
[11:33] <Laney> make it a different tool, please
[11:33] <Laney> ubucheckout
[11:34] <Keybuk> Laney: it's from a debian source package
[11:34] <Keybuk> and is a common tool between Debian and Ubuntu
[11:34] <ogra_> hulp !
[11:34] <Laney> I know, and I often use it to get Debian packaging branches
[11:34] <Laney> if it starts pulling from LP then it will break my workflow
[11:34] <ogra_> i seem to hit a heavy glib bug where i cant get my focus out of a running app
[11:34] <seb128> Laney, well it's your issue
[11:35] <seb128> Laney, seems normal that on ubuntu it pulls the ubuntu source
[11:35] <seb128> Laney, that's what most people working on ubuntu want usually
[11:35] <Laney> it seems normal that it pulls the branch defined in the control file to me
[11:35] <seb128> Laney, you should be using a flag telling to use the debian vcs if you want that
[11:35] <seb128> Laney, out of the fact that we don't specify canonical bzr locations there
[11:35] <seb128> we would have to change every source package for nothing
[11:36] <Laney> indeed, that's why I think it should be a separate mode
[11:36] <seb128> I think it should be default
[11:36] <seb128> with an option to turn it off
[11:36] <seb128> the default should be what makes sense on ubuntu
[11:36] <pitti> and at one point we'll hopefully have the entire archive in bzr, so that we can stop worrying
[11:36] <seb128> pitti, well that doesn't fix Laney's usecase to not want to ubuntu source but the debian one
[11:37] <pitti> seb128: I meant we wouldn't need debcheckout any more
[11:37] <Laney> debcheckout -> get from Debian, bzr get -> get from LP
[11:37] <seb128> right
[11:37] <Laney> that's my workflow
[11:37] <seb128> bzr get what?
[11:37] <Laney> whatever is appropriate
[11:37] <Laney> not getting into your argument ;)
[11:37] <seb128> well that's the interest of debcheckout
[11:38] <seb128> to not have to specify that
[11:38] <seb128> or to figure what it is
[11:38] <seb128> right now that should be first the control Vcs if one
[11:38] <seb128> and if there is none default to the canonical location
[11:39] <Laney> and ignore it if it's not LP?
[11:39] <seb128> no
[11:39] <seb128> when merging with debian you should rename the Vcs if that's not the one used for Ubuntu
[11:39] <seb128> or drop it
[11:39] <Keybuk> or right
[11:39] <Keybuk> I remember now
[11:40] <Keybuk> (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] <Keybuk> quest tmp% debcheckout gdm
[11:40] <Keybuk> declared bzr repository at https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu
[11:40] <Keybuk> bzr branch https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu gdm ...
[11:40] <Keybuk> 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] <Keybuk> checkout failed (the command above returned a non-zero exit code)
[11:40] <Keybuk> --
[11:40] <Keybuk> I tried
[11:40] <Keybuk> and when I got that, I checked whether there was an lp:ubuntu/gdm with the right version
[11:40] <Keybuk> and assumed (not unreasonably) that you must have switched and forgotten to update the header
[11:41] <Keybuk> and that's why I used the lp:ubuntu/gdm branch
[11:41] <Keybuk> and since it was already checked out in my lucid folder, I've just used "bzr pull" ever since
[11:42] <seb128> k
[11:42] <seb128> we will revisit things next cycle
[11:42] <seb128> but now we have other issues to work on for lucid
[11:43] <chrisccoulson> on the subject of bzr....
[11:43] <chrisccoulson> some of our desktop branches are out of date this morning after the breakage at the weekend
[11:44] <chrisccoulson> so, people might want to remember that :-)
[11:45] <pitti> *nod*
[11:46] <pitti> seb128, kenvandine: I think the first vcs-bzr: that we should drop are the indicator related ones
[11:46] <pitti> they already have full source in bzr, thus using lp:ubuntu/pkgname isn't any different wrt. working with the package
[11:46] <seb128> pitti, right, we did that already for some
[11:47] <seb128> I'm doing that on the way when doing an update and not in a hurry to get things done before freeze or end of day or whatever
[11:47] <pitti> *nod*
[11:47] <seb128> ie indicator-sound, ido etc are already managed this way
[11:47] <seb128> it really makes sense for those with upstream in bzr
[11:47] <seb128> and the sources are small enough
[11:48] <pitti> seb128: do you know when gnome 2.30 freezes?
[11:48] <pitti> i. e. until when we can get bug fixes in?
[11:48] <seb128> pitti, "freezes"?
[11:48] <seb128> one week ago
[11:49] <pitti> ah, ok
[11:49] <seb128> it's code frozen for a week
[11:49] <seb128> you can ask for freeze breaks if required though
[11:49] <pitti> ok, thanks
[11:49] <ogra> help ! glib and gdk are freaking out on me, i'm 100% stuck in the first app i start after X comes up, .xsession-errors shows gobject_unref assertion errors and gdk_window_get_events errors ... i cant file a bug because i cant get focus on the browser ubuntu-bug brings up
[11:50] <pitti> ogra: on arm?
[11:50] <ogra> pitti, on my laptop
[11:51] <ogra> it worked over the whole weekend, just started that behavior 1h ago, i rebooted several times already (after restarting X several times before)
[11:51] <pitti> what changed an hour ago? dist-upgrade?
[11:51] <ogra> i didnt upgrade or anything so the system is in the same state that worked the last days
[11:51] <ogra> i didnt do *anything*  special ... three terminals, browser, xchat and evo were open when it started
[11:52] <ogra> it seems to be a heavy issue with glib or gdk
[11:53] <ogra> seems gdk windows arent recognized as windows anymore if i read the errors right
[11:53] <ogra> nor does gobject_ref or _unref work
[11:58] <asac_> ogra: sure you rebooted before today?
[11:59] <pitti> ogra: you don't happen to have a PPA with client-side decorations still running or so?
[11:59] <asac_> he is gone ;)
[11:59] <didrocks> seb128: so, new clutter 1.2.x needs new clutter-gtk (ok, we had a released last week). This one use gobject-introspect and build-dep on gir1.0-gtk-2.0. But this one is an old version of gir-repository and needs a new one (2.19.5, so I assume directly from gtk source). So, if we want the new clutter version, I can split the gtk package or build without introspection
[12:00] <ogra> pitti, if i bring up a terminal after boot, i cant even move it :/
[12:00] <pitti> ogra: you don't happen to have a PPA with client-side decorations still running or so?
[12:00] <ogra> nope
[12:00] <pitti> ogra: try creating a new user or launch a guest session?
[12:00] <LaserJock> didrocks: hi, how was your weekend?
[12:01] <pitti> ogra: or metacity --replace
[12:01] <ogra> pitti, already done, its not the WM
[12:01] <pitti> ogra: (or compiz --replace if you are already running metacity)
[12:01] <didrocks> LaserJock: good, thanks, with at least a spring weather now :) Yours?
[12:01] <pitti> ogra: we had a fair bit of fallout over the weekend due to some mis-built nautilus/gnome-panel/etc.; you are on lucid current?
[12:01] <LaserJock> didrocks: sunny and very warm this weekend in Boston
[12:02] <ogra> pitti, i am, but the last time i upgraded was friday
[12:02] <tseliot> pitti: the fglrx binaries still don't seem to be in the archive, can you approve them, please?
[12:02] <asac_> ogra: just dist-upgrade ... just in case
[12:02] <ogra> pitti, and the system behaved until today
[12:02] <asac_> it cant get worse for you i figure ;)
[12:02] <ogra> heh, yeah, i guess so
[12:02] <pitti> tseliot: yep, looking
[12:02] <tseliot> thanks
[12:02] <tseliot> pitti: https://launchpad.net/ubuntu/+source/fglrx-installer/2:8.721-0ubuntu4/+build/1571790
[12:02] <pitti> tseliot: so those were renamed?
[12:03] <pitti> tseliot: what was the rationale for the renaming, especially that late in the cycle?
[12:03] <LaserJock> didrocks: I was thinking last night, do you think it'd be possible to do some sort of UNE Hug Day before Beta 2 gets here? Would that be useful at this stage?
[12:03] <tseliot> pitti: yes, to be consistent with nvidia
[12:03] <pitti> tseliot: and they don't build a transitional package, so I'm a bit worried about accepting that now
[12:04] <tseliot> pitti: would you like me to update a new version with the transitional packages before you approve them?
[12:04] <pitti> tseliot: that'd be better I think
[12:04] <pitti> tseliot: or just keep the name as it is :)
[12:04] <didrocks> LaserJock: right, we discussed that with seb128 at Portland. I guess that can be the right time now that we know/handle the bugs that can be interested. I just have to finish updating the clutter stack (I hope today, but it's getting a little bit more fuzzy) as it can have some impact, first
[12:05] <tseliot> pitti: that would be a bit confusing as upstream is using those names now
[12:05] <ogra> hmm, the upgrade only gets me keyring, libc and init stuff
[12:05] <pitti> tseliot: for packages?
[12:05] <tseliot> pitti: yes, as we share the same source, and I maintain both
[12:05] <pitti> tseliot: anyway, if it gets transitional packages, it's fine for me
[12:05] <tseliot> ok
[12:05] <LaserJock> didrocks: I noticed that netbook-launcher has something like 20 New bugs, I guess it would be good to get those all triaged
[12:05] <pitti> tseliot: we also need to update jockey then, I figure
[12:06] <tseliot> pitti: yes, of course, it's on my TODO list
[12:06] <pitti> tseliot: ok, please let me know when you uploaded, then I'll wave them through
[12:06] <didrocks> LaserJock: oh really? I tried to triage day-to-day them since I subscribed. But as I triaged at first shot more than 300 bugs, I can have miss some :)
[12:06]  * pitti lunches
[12:06] <didrocks> pitti: enjoy
[12:08] <tseliot> pitti: uploaded
[12:10] <seb128> re
[12:11] <seb128> didrocks, sorry I was at lunch
[12:11] <didrocks> seb128: no pb, take your time :)
[12:11] <seb128> didrocks, clutter, I would keep doing what we do now
[12:12] <seb128> ie don't build with introspection
[12:12] <ogra> pitti, guest session works ... *whine* i dont want to lose my settings :(
[12:12] <LaserJock> ogra: obviously you need a registry cleaner ;p
[12:13] <didrocks> seb128: clutter-gtk is using introspection
[12:13] <ogra> haha
[12:13] <seb128> didrocks, optional?
[12:13] <LaserJock> ogra: I'll sell you one for just $19.95
[12:13] <didrocks> seb128: I don't understand what means optional in that case, it build-deps on the gir-* package and it's a flag in configure turned on
[12:13] <ogra> LaserJock, i could also just say "ubuntu is so apple like now, we only support single tasking" :P
[12:14] <LaserJock> lol
[12:16] <ogra> oh my, the default fonts look horrible ...
[12:16] <seb128> didrocks, ok, it's not clear to me, are those using gir now?
[12:16] <seb128> didrocks, it do you want to turn that on?
[12:16] <ogra> everything is so huge suddenly
[12:16] <ogra> pitti, rm -rf .gconf helped
[12:16] <didrocks> seb128: it's using gir already
[12:16] <seb128> didrocks, or is that just that the requirement bump require the gtk version?
[12:17] <seb128> ok so it requires a newest gir than the gir one?
[12:17] <seb128> ie to build from gtk?
[12:18] <seb128> didrocks, what is your opinion about that?
[12:18] <didrocks> seb128: I guess the bump is just for gtk, but I don't know if "gtk gir" file has changed too. I'm not sure how you can test this
[12:18] <seb128> didrocks, right, well basically it means we should build the gtk gir from gtk now
[12:18] <didrocks> seb128: right, that's what I was proposing to you, I can handle this if we still want to build with introspection
[12:22] <Keybuk> pitti: #udev reminds me that I saw people complaining about a ConsoleKit issue last week/over the weekend?
[12:22] <Keybuk> did you see anything about that?
[12:23] <ogra> argh
[12:23] <ogra> didnt really work out seems its still partially there
[12:29] <chrisccoulson> Keybuk - i mentioned a consolekit issue last week, and your name was mentioned there
[12:29] <chrisccoulson> that might have been what you remember
[12:29] <Keybuk> can you remember more about what you mentioned?
[12:30] <chrisccoulson> Keybuk - a couple of times when I booted last week, consolekit was unable to determine what the active VT was
[12:31] <chrisccoulson> and it was throwing out errors like this:
[12:31] <chrisccoulson>  WARNING: Error waiting for native console 5 activation: Invalid argument
[12:31] <ogra> ok, it got wose now ... seems alt-F4 suddenly suspends my machine
[12:32] <chrisccoulson> Keybuk - that error is a result of "ioctl (console_fd, VT_WAITACTIVE, num);" failing with EINVAL
[12:32] <Keybuk> right
[12:32] <Keybuk> but why is consolekit using that ioctl?
[12:32] <Keybuk> that's only used when you switch VT
[12:32] <chrisccoulson> Keybuk - it spawns a thread for each VT, which waits for it to become active
[12:33] <chrisccoulson> so it can track where the active one is
[12:33] <Keybuk> ok
[12:33] <Keybuk> it'll fail with -EINVAL for a short period during boot
[12:34] <Keybuk> does it correctly back-off from that, and restart the thread again later?
[12:34] <Keybuk> (if it goes into an infinite loop, that's not good either)
[12:34] <chrisccoulson> Keybuk - no, that's probably the issue really. once it has failed, it just gives up
[12:34] <Keybuk> yeah
[12:34] <chrisccoulson> so, we probably need to fix consolekit then?
[12:34] <Keybuk> we caused X to have the same bug
[12:34] <chrisccoulson> ah, ok. that makes sense. and that explains why i can't recreate it all the time
[12:35] <Keybuk> you get -EINVAL from VT_WAITACTIVE in a very specific condition
[12:35] <Keybuk> the current foreground VT is in KD_GRAPHICS mode, but also VT_AUTO
[12:35] <Keybuk> ie. it's been left with painted graphics ... but no process running on it
[12:35] <Keybuk> since it's in graphics mode, the kernel prohibits VT switches
[12:36]  * ogra wonders if Keybuk's recent changes to plymouth cause his laptop to suspend on console switching 
[12:36] <Keybuk> can you guess when that condition is true?
[12:36] <Keybuk> ogra: doubtful
[12:36] <chrisccoulson> do you know how long it's in that condition for?
[12:36] <Keybuk> chrisccoulson: however long the X server takes to start ;-)
[12:36] <Keybuk> couple of seconds usually
[12:36] <asac_> good news is that i was able to boot with system clock reset to 0 ... and mountall didnt loop ;)
[12:36] <chrisccoulson> oh, right. that seems obvious now :)
[12:36] <asac_> thanks for that!
[12:37] <chrisccoulson> Keybuk - so the window is quite large then (and I think consolekit is activated after GDM starts isn't it?)
[12:37] <chrisccoulson> i think gdm is the first thing to use it anyway
[12:37] <ogra> asac_, btw, the workaround trick is to edit /lib/init/fstab in case it shows up again ... :)
[12:37] <ogra> asac_, i meant to tell you earlier
[12:38] <Keybuk> chrisccoulson: gdm activates it
[12:38] <chrisccoulson> yeah, i thought so
[12:38] <Keybuk> which means it's activated "before X starts or while X is starting"
[12:38] <chrisccoulson> thanks
[12:38] <Keybuk> ie. exactly in that window
[12:39] <asac_> ogra: i really hope its fixed now ;)
[12:40] <Keybuk> chrisccoulson: so, on the VT_WAITACTIVE+VT_AUTO thing ... you could kinda argue it's a kernel bug
[12:40] <Keybuk> because the kernel bug should deal with that case on its own
[12:41] <Keybuk> but the kernel guys will tell you that the whole VT_* stuff is a mess, and they'd rather leave it alone
[12:41] <chrisccoulson> yeah, it might be easier to work around it in consolekit for now
[12:41] <Keybuk> exactly
[12:41] <Keybuk> "for now" isn't really appropriate here
[12:41] <Keybuk> I suspect the kernel VT layer will never get fixed
[12:41] <chrisccoulson> i'll open a consolekit bug anyway
[12:42] <Keybuk> instead we'll just end up (in a thousand years) using wayland to manage the console, with VTE for "terminal" and switching between that and windows effortlessly
[12:42] <Keybuk> right
[12:42] <Keybuk> I mean consolekit will have to work around it forever
[12:42] <Keybuk> as the point at which the problem goes away is the point we also wouldn't need consolekit
[12:43] <Keybuk> http://lkml.indiana.edu/hypermail/linux/kernel/0907.0/00733.html
[12:43] <Keybuk> ^ interesting
[12:44] <chrisccoulson> thanks, i'll have a read of that later ;)
[12:44] <Keybuk> our kernel appears to have VT_WAITEVENT support
[12:45] <Keybuk> struct vt_event {
[12:45] <Keybuk>         unsigned int event;
[12:45] <Keybuk> #define VT_EVENT_SWITCH         0x0001  /* Console switch */
[12:45] <Keybuk> #define VT_EVENT_BLANK          0x0002  /* Screen blank */
[12:45] <Keybuk> #define VT_EVENT_UNBLANK        0x0004  /* Screen unblank */
[12:45] <Keybuk> #define VT_EVENT_RESIZE         0x0008  /* Resize display */
[12:45] <Keybuk> #define VT_MAX_EVENT            0x000F
[12:45] <Keybuk>         unsigned int oldev;             /* Old console */
[12:45] <Keybuk>         unsigned int newev;             /* New console (if changing) */
[12:45] <Keybuk>         unsigned int pad[4];            /* Padding for expansion */
[12:45] <Keybuk> };
[12:45] <Keybuk> #define VT_WAITEVENT    0x560E  /* Wait for an event */
[12:45] <Keybuk> dunno if that's any better, mind you
[12:59] <pitti> ogra, Keybuk: suspend-on-VT-switch is bug 515465; I just committed the fix upstream, FYI
[13:00] <pitti> ogra: well, at least it's very probable that this is what you see as well?
[13:05] <ogra> pitti, btw, back to normal here, seems it was somehow related to the USB hub in my monitor, detaching everything from the laptop made everything work again
[13:05]  * ogra checks the bug
[13:05] <baptistemm> can someone have a look to 534702 ? I would like to have it to be tested quickly
[13:05] <pitti> ogra: fun; that should have left some traces in kern.log/dmesg?
[13:05] <ogra> pitti, nothing at all
[13:05] <chrisccoulson> bug 534702
[13:05] <ogra> the only thing i saw were the ton of glib and gdk erros in ~/.xsession-errors
[13:06] <chrisccoulson> baptistemm, oh, i probably can't help you there ;)
[13:06] <ogra> pitti, bug is identical, lid also closed here
[13:06] <pitti> ogra: ok, fine
[13:06]  * ogra clicks the me too link :)
[13:06] <pitti> ogra: don't worry, it'll land in lucid :) I just got it upstream
[13:07] <ogra> uhm, since resetting my gconf setup the notification fonts got very very small
[13:07] <baptistemm> chrisccoulson, I reported upstream for bug 532101
[13:07] <chrisccoulson> ogra - do people actually use that link? i thought everybody just posted comments like "+1, please fix it now else I'll go back to windows"
[13:07] <chrisccoulson> baptistemm, thanks
[13:07] <chrisccoulson> that's on my list of things to fix, but it's quite far down the list at the moment
[13:08] <ogra> chrisccoulson, i'm annoyed be people doing that on my bugs so i usually try to be a good example and use the link :)
[13:08] <chrisccoulson> baptistemm, i suspect it will turn in to some weekend hacking ;)
[13:08] <chrisccoulson> ogra - yeah, i get annoyed by that too
[13:09] <ogra> though in ARM land i rarely even get me-too's :)
[13:09] <chrisccoulson> heh
[13:09] <ogra> just move your work focus ;)
[13:09] <baptistemm> chrisccoulson, yeah, some check is required like using some gnome-bluetooth API
[13:09] <chrisccoulson> baptistemm, yeah, i took a look at it a couple of weekends ago
[13:10] <chrisccoulson> i think i know what i need to do with it now, i just need to actually sit down and implement it
[13:10] <baptistemm> I don't understand if the bug is also about the presence of the bar always and a way to discard it
[13:10] <chrisccoulson> baptistemm, the complex part is that it also displays for webdav too
[13:10] <baptistemm> oh true ...
[13:10] <chrisccoulson> so, we need an ubuntu-specific part to hide that when apache is not installed, to match the other UI change i did
[13:12] <chrisccoulson> pitti - did you see hughsie's response to https://bugzilla.gnome.org/show_bug.cgi?id=613509 ?
[13:12] <pitti> chrisccoulson: I didn't, no
[13:12] <chrisccoulson> i get the impression that we might have upset him a bit. i hope not though
[13:12]  * pitti reads
[13:13] <pitti> chrisccoulson: TBH, I agree to him, though
[13:13] <pitti> this change completely broke translations
[13:13] <chrisccoulson> yeah, me too
[13:13] <pitti> until the weekend I had "Ruhe" and "Ruhezustand"
[13:13] <pitti> impossible to tell which is which
[13:13] <pitti> "Zustand" == "state"
[13:14] <chrisccoulson> ah
[13:14] <pitti> i. e. something like "suspend" and "suspend state"
[13:14] <pitti> and it was really late for such string changes to happen
[13:14] <chrisccoulson> yeah, that's a bit weird to see ;)
[13:15] <seb128> chrisccoulson, the switch off change has been undone btw
[13:15] <seb128> not sure if you did follow those
[13:15] <chrisccoulson> seb128 - thanks. i didn't notice that yet, but i've not upgraded since we unfroze on friday
[13:15]  * seb128 clears
[13:16] <chrisccoulson> i should probably upgrade now really
[13:16] <seb128> ups
[13:16] <pitti> right, I have the old names back again
[13:16] <seb128> the string was too british apparently
[13:16] <ogra> hmm, was the middle click on the windowlist disabled on purpose ? i cant move apps around in it
[13:16] <seb128> pitti, well suspend has not been switched back I think
[13:17] <chrisccoulson> seb128 - ah, i was just about to ask that
[13:17] <pitti> seb128: well, I only see the German translation, and they are fixed again
[13:17] <chrisccoulson> that's what hughsie has an issue with
[13:17] <seb128> pitti, we got a langpack update today
[13:17] <pitti> i. e. "Ruhe" (the new and wrong name for suspend) is back to "Bereitschaft"
[13:17] <pitti> seb128: perhaps it's that
[13:17] <seb128> that's the design team for you
[13:17] <seb128> deciding on wording changes for things nobody has issue with after freeze
[13:18] <pitti> hm, we keep telling them that string changes are expensive and painful..
[13:18] <seb128> which leads to extra work and discussions for no real win
[13:18] <ogra> pitti, well, it wasnt *that* wrong, RB surely stops playing when you suspend :P
[13:18] <seb128> right
[13:18] <pitti> ogra: heh
[13:18] <pitti> ogra: but "Ruhe" vs. "Ruhezustand"??
[13:18] <ogra> zustand ... heh
[13:19] <ogra> i like "bereitschaft"
[13:19] <pitti> not that I think that the German translation was particularly clever
[13:19] <seb128> rickspencer3, hey
[13:19] <pitti> rickspencer3: good morning
[13:19] <rickspencer3> hi seb128, pitti good morning
[13:19] <pitti> seb128: (too busy for the source NEW? I'll find someone else)
[13:19] <ogra> pitti, there are particular german words that cause bad pictures in my brain ... "wohnhaft" makes me think of jails :)
[13:19] <seb128> rickspencer3, did you have a good weekend?
[13:20] <rickspencer3> seb128, yes, quite nice
[13:20] <rickspencer3> seb128, you?
[13:20] <seb128> rickspencer3, quite good too though a bit short, thank you
[13:21] <didrocks> hey rickspencer3
[13:21] <kenvandine> good morning rickspencer3
[13:21] <rickspencer3> hi didrocks
[13:21] <rickspencer3> hi kenvandine
[13:22] <kenvandine> dpm, i merged all those fixes from the translation team, you guys rock!
[13:22] <seb128> seems kenvandine just show up to say hello to rickspencer3 ;-)
[13:22] <rickspencer3> hehe
[13:22] <seb128> kenvandine, we are important enough people to say hello to before rick joins right? ;-)
[13:23] <rickspencer3> he's got "good morning rickspencer3" wired into a bot
[13:23] <kenvandine> hehe
[13:23]  * kenvandine just looked at irc
[13:23] <kenvandine> seb128, you always preach about pushing updates on a friday... and we got bit :/
[13:24] <seb128> I'm a bit annoyed about that yes
[13:24] <kenvandine> none of us were happy late friday night :/
[13:24] <seb128> I tried for most of friday to tell people to not unfreeze on friday evening especially when it was clear we were not going to respin
[13:24] <seb128> ie to unfreeze early in the afternoon
[13:24] <kenvandine> i could just hear you saying i told you so
[13:25] <seb128> lol
[13:25] <kenvandine> :)
[13:25] <dpm> kenvandine, awesome, thanks Ken!
[13:25] <kenvandine> dpm, no problem.. keep them coming!
[13:25] <kenvandine> :)
[13:26] <seb128> I think it's clearly stupid but other people seem to think it's a non issue
[13:26] <dpm> sure ;)
[13:26] <seb128> *shrug*
[13:26] <seb128> anyway it happened after I went to bed and was fixed by time I read my email on saturday
[13:26] <seb128> I'm just sorry for the people who had to spend friday night or saturday morning fixing that
[13:28] <rickspencer3> kenvandine,  seb128, are you referring to "no panels" bug?
[13:28] <seb128> rickspencer3, it was not only gnome-panel, also nautilus, etc
[13:28] <seb128> rickspencer3, but yes
[13:28]  * pitti blushes
[13:29] <seb128> rickspencer3, to the "upgrade after beta1 breaks GNOME for every user letting an empty background after login"
[13:29] <kenvandine> rickspencer3, yeah... it was bad :)
[13:29] <seb128> pitti, we all do bugs not blaming you there
[13:30] <rickspencer3> no blame to be had
[13:30] <seb128> I'm unhappy about freeze handling though, I've been trying to push people to unfreeze for the whole friday afternoon to avoid that
[13:30] <pitti> oh, it's not that I feel bad enough to quit and shoot myself or so :)
[13:30] <pitti> sh*t happens
[13:30] <pitti> and it's all good now
[13:30] <rickspencer3> it was not catastrophic, and that's why we have betas and such
[13:31] <rickspencer3> kenvandine, one piece of feedback that we might want to respond to is about gwibber start time
[13:31] <seb128> rickspencer3, still I would like to have a discussion about unfreezing on friday evening
[13:31] <pitti> it was my secret plan to ensure that everyone relaxes on that weekend instead of using computers :-P
[13:31] <seb128> rickspencer3, what would be the best way to bring that for discussion?
[13:31] <seb128> I tried on IRC but failed
[13:31] <pitti> seb128: I can bring it up in the next release meeting
[13:31] <rickspencer3> seb128, I guess that would be with the release manager
[13:31] <seb128> pitti, I would appreciate than you
[13:31] <seb128> thank
[13:31] <kenvandine> rickspencer3, ryan and i both spent some time looking at start time this weekend
[13:32] <kenvandine> it will get a little better when one of the existing desktopcouch bugs gets fixed
[13:33] <kenvandine> rickspencer3, the biggest hit is desktopcouch startup time
[13:33] <kenvandine> some of it is UI startup, which can be improved but not this cycle
[13:33] <didrocks> seb128: rickspencer3: as told previously, we tried to discuss it with chrisccoulson and cjwatson on Saturday, but not sure that a solution or process has been decided at the end
[13:34] <seb128> didrocks, I will read the IRC logs later
[13:34] <didrocks> seb128: around 1 PM IIRC
[13:34] <kenvandine> rickspencer3, one thing we will do now that improves it some is db size
[13:34] <chrisccoulson> heh, friday night was "interesting"
[13:34] <LaserJock> kenvandine: is there a particular reason gwibber uses desktopcouch over traditional config files?
[13:35] <kenvandine> we now automatically compact the db, and are more efficient at storage
[13:35] <kenvandine> but we are also going to be cleaning the messages db, so we don't store an infinite amount of messages
[13:35] <kenvandine> LaserJock, one reason is sync, but there are quite a few nice things we get from it
[13:36] <kenvandine> including events, so when new messages are inserted into the database we trigger events like notifications, indicators, etc
[13:36] <kenvandine> ripped a bunch of buggy code out of gwibber :)
[13:36] <tseliot> pitti: approved?
[13:37] <kenvandine> LaserJock, and desktopcouch is very nice to work with
[13:37] <pitti> tseliot: last time I looked it was still waiting on the amd64 build; I'll have a look soon
[13:37] <tseliot> pitti: thanks
[13:37] <kenvandine> if we make the db size more reasonable, it will be a bit faster... we just need dc to start faster too
[13:37] <LaserJock> kenvandine: would it be possible (in the sense of being resonable) to have a non-couchdb backend?
[13:37] <kenvandine> LaserJock, not without a major overhaul again... the gwibber internals depend on couch
[13:38] <LaserJock> interesting
[13:38] <kenvandine> we use couch for a ton of stuff, not just storage
[13:38] <kenvandine> couch made gwibber considerably simpler
[13:39] <LaserJock> I see
[13:39] <kenvandine> since the last release, we have made our usage of couch more effecient
[13:40] <kenvandine> like we found we were storing redundant data, that is fixed
[13:40] <LaserJock> ah
[13:40] <kenvandine> and automatic compaction
[13:40] <kenvandine> db size will be considerably smaller
[13:40] <LaserJock> I've noticed that the messages db is ~ 70MB for me and gwibber is using about that much RAM
[13:41] <kenvandine> LaserJock, the RAM usage is relatively recent bug, it is a desktopcouch/dbus bug
[13:41] <kenvandine> they are trying to figure that out
[13:41] <LaserJock> it often annoys me that messaging apps are often the most resource hungry applications I run
[13:41] <kenvandine> we have been profiling it very closely, the rule has been to keep the backend down to below 15M on x86 and 30M on x86_64
[13:42] <kenvandine> which until about two weeks ago, maybe 3 weeks ago... the service never topped that
[13:42] <kenvandine> which is a huge improvement compared to 2.0 :)
[13:42] <kenvandine> which was more like 700M :)
[13:42] <kenvandine> anyway, the desktopcouch guys are working on that bug
[13:43] <LaserJock> yeah, hopefully that works out
[13:43] <seb128> pitti, policykit-desktop-privileges accepted btw
[13:43] <pitti> seb128: \o/ cheers
[13:44] <kenvandine> just a call to CouchDatabase in python grows RSS footprint by 64M, before that bug it was about 400K
[13:44] <seb128> np
[13:44] <LaserJock> so far I've been very unimpressed with desktopcouch/couchdb but I'm willing to be a little patient for them to work stuff out
[13:44]  * kenvandine has been very impressed, it makes so many things simple... it is really nice for an app developer
[13:45] <LaserJock> yeah, from what I've seen of examples it looks like it's great for developers
[13:45] <kenvandine> LaserJock, we just need to get implementations right
[13:46] <kenvandine> which i think we are close to in gwibber
[13:46] <kenvandine> it was a learning experience
[13:46] <LaserJock> sure
[13:46] <kenvandine> but the tweaks we have made in the past week will make it significantly more effecient
[13:46] <kenvandine> my gwibber-messages db was 418M
[13:46] <kenvandine> now 78M
[13:46] <LaserJock> but gwibber feels like a giant "learning experience", hopefully your hard work will help it mature
[13:47] <kenvandine> and when we start to purge old message data, it will get much smaller than that
[13:47] <LaserJock> yeah, I noticed that there was no option to set how many messages to keep
[13:47] <Ng> heh, my gwibber_messages is 211MB and my gwibber process is 729MB virt, 211MB RSS ;)
[13:48] <Ng> doesn't bother me with 4GB though, and I'm sure it'll get sorted :)
[13:48] <LaserJock> I've got 1GB
[13:48] <LaserJock> and it's the largest single user of RAM
[13:48] <LaserJock> which seems odd for a "peripheral" application
[13:48] <Ng> my firefox makes it look insignificant ;)
[13:49] <kenvandine> Ng, gwibber or gwibber-service?
[13:49] <kenvandine> gwibber-service should be no where near 211M RSS
[13:49] <Ng> kenvandine: gwibber. gwibber service is 422MB/48MB
[13:49] <kenvandine> ok
[13:50] <kenvandine> whew
[13:50] <pitti> tseliot: accepted
[13:50] <kenvandine> that is the one we are most concerned with
[13:50] <kenvandine> the client will be heavier because it has the UI stuff and webkit
[13:50] <kenvandine> and hopefully people will close it :)
[13:50] <Ng> yeah I never close it :D
[13:50] <LaserJock> why would I close it?
[13:50] <Ng> I run like 4 apps and I never close them
[13:51] <kenvandine> LaserJock, you only need it open when you are looking at it :)
[13:51]  * kenvandine always keeps it closed
[13:51] <LaserJock> I look at it all the time
[13:51] <kenvandine> i follow too many people to look at it all the time
[13:51] <LaserJock> you know, what's the point of having a messaging service if you never read the messages :-)
[13:51] <kenvandine> i skim it from time to time
[13:51] <tseliot> pitti: thanks a lot
[13:52] <Ng> I sometimes find it a little odd that -service notifies my of a reply, but the GUI doesn't show it yet
[13:53] <LaserJock> the UI is so slow, I can't imagine reopening it every time
[13:56] <Ng> yeah that does take a while to start
[13:56] <kenvandine> LaserJock, how slow is it to start?  if the backend is running, mine is usually about 2 or 3 seconds
[13:57] <kenvandine> unless firefox and evolution are grinding my laptop to a halt... then it can be a little slower
[13:57] <LaserJock> I just counted 18s
[13:57] <kenvandine> yikes!
[13:57] <Ng> kenvandine: say, the entries I get in the message notifier when people have @'d me on identi.ca - those should be cleared when I focus gwibber because I have a Replies stream visible and I don't really want to go and click on 10 menu entries to clear them :)
[13:57] <kenvandine> and the backend was running?
[13:57] <LaserJock> kenvandine: I think so
[13:57] <kenvandine> did you Gwibber-Quit or close?
[13:58] <kenvandine> gwibber->quit in the menu quits the backend too
[13:58] <kenvandine> but even with that, it i have never seen it at 18s
[13:58] <LaserJock> no, just the close button
[13:58] <LaserJock> gwibber-service is still running
[13:58] <Ng> closing the gwibber window (leaving gwibber-service running), then picking Broadcast from the messages menu produced a 7s load time, and that was the second time I tried it, so any cache involved should have been warm
[13:58] <kenvandine> i just did it 3 times, each was no more than 2s
[13:58] <kenvandine> humm
[13:59] <kenvandine> i wonder if it is because my db is much leaner and meaner now :)
[13:59] <kenvandine> lets see how fast it is for you guys after the next release
[13:59] <kiko> hi there
[13:59] <LaserJock> how big is your db?
[13:59] <kenvandine> mine is 78M
[13:59] <kenvandine> but compacted
[13:59] <LaserJock> mine is 68MB
[14:00] <kenvandine> so mine just has more messages, i think your's is still going to have more overhead because of the extra data and revisions
[14:00] <Ng> when will the new release land? :D
[14:00] <kenvandine> Ng, i hope mid week
[14:00] <Ng> groovy
[14:01] <Ng> where should I file a bug about the broadcast entries in the message notification menu?
[14:01] <LaserJock> kenvandine: after the initial 18s one, I get consistent 12s start times
[14:01] <kenvandine> against the gwibber package
[14:01] <Ng> ok, thanks
[14:01] <kenvandine> LaserJock, that is way too slow
[14:02] <LaserJock> it's about as fast is OO.o or FF
[14:03] <LaserJock> kenvandine: after killing gwibber-service (File-> Quit) start up time is ~ 55s
[14:04] <LaserJock> that's why I start it once at the beginning of the day and leav it
[14:04] <kenvandine> LaserJock, what kind of hardware?
[14:04] <kenvandine> it isn't that slow for me on my slow netbook :/
[14:04] <LaserJock> acer aspire one
[14:04] <kiko> hey
[14:04] <kenvandine> does it trash your CPU when it is doing that?
[14:04] <kiko> how do I mark lucid regressions?
[14:04] <kiko> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/538636
[14:04] <kiko> this one is absolutely a lucid regression
[14:04] <kenvandine> LaserJock, oh, that is a netbook huh?
[14:05] <kenvandine> LaserJock, with SSD?
[14:05] <LaserJock> kenvandine: no SSD
[14:06] <LaserJock> it is a netbook
[14:06] <kenvandine> ok, humm
[14:06] <LaserJock> it's using a lot of CPU
[14:06] <LaserJock> is beam.smp related to gwibber?
[14:06] <kenvandine> that is desktopcouch
[14:06] <LaserJock> that uses a lot of CPU
[14:06] <kenvandine> ok
[14:06] <kenvandine> i bet the new release will fix it quite a bit
[14:06] <seb128> kiko, which one?
[14:06] <LaserJock> my load average was around 0.7 or so
[14:07] <kenvandine> LaserJock, a couple people had beam.smp thrashing CPU at startup and it seemed to be related to they extra data we were storing
[14:07] <LaserJock> but I know for sure gwibber takes a lot more time than Chromium for instance
[14:07] <seb128> kiko, ignore that question, just reading log
[14:07] <LaserJock> longer than OO.o I think as well
[14:07] <kenvandine> LaserJock, that makes me sad... :/
[14:07] <kenvandine> lets hope it gets fixed :)
[14:08] <kenvandine> starting gwibber cold on my classmate is 12s
[14:08] <kenvandine> so no service and no couch running
[14:08] <kenvandine> but only one account configured on it
[14:08] <LaserJock> kenvandine: it's not totally swamping the CPU, but there are a lot of processes all using a fair amount
[14:08] <LaserJock> I have 1 twitter and 1 identi.ca account
[14:08] <kenvandine> lets hope we can get yours in that ballpark :)
[14:08] <LaserJock> I tried Facebook but that was just too much
[14:09] <LaserJock> ok, I look forward to trying the new release and I'll let you know if that improves things
[14:10] <pitti> kenvandine: is there a known bug that I have g-p-m icon twice in the panel? One is actually gdm, the other does nothing on left click and gives me a standard applet menu on right click; "about" says "notification field 2.29.92.1", (c) 2002 Red Hat
[14:10] <seb128> pitti, another instance of this display bug?
[14:10] <LaserJock> kenvandine: Chromium takes 6 s and OO.o takes 11s, for reference
[14:11] <kenvandine> pitti, i haven't seen that... no
[14:11] <seb128> pitti, there is a "known" bug happening randomly where notification area of other applets get randomly wrongly displayed
[14:12] <pitti> seb128: sounds plausible
[14:12] <seb128> chrisccoulson get it quite often apparently
[14:12] <pitti> killall gnome-panel usually "fixes" it, but it happens randomly
[14:12] <pitti> oh
[14:12] <chrisccoulson> yes, i get that frequently
[14:12] <pitti> I think it might have been network-manager
[14:12] <chrisccoulson> pitti - that's the same bug which affects nm-applet
[14:12] <chrisccoulson> yes
[14:12] <pitti> (what it actually should have displayed)
[14:13] <chrisccoulson> i've really got no idea how to debug this one at the moment
[14:13] <seb128> chrisccoulson, pitti: do you have any opinion on screen locking in indicator-session?
[14:13] <seb128> ted change it to be "start screensaver" now
[14:13] <seb128> in case where screensaver doesn't automatic lock the screen
[14:13] <pitti> hmm
[14:13] <seb128> I'm leaning toward undoing the change for lucid
[14:13] <pitti> couldn't it actually just lock the screen?
[14:14] <pitti> that seems much more useful to me
[14:14] <chrisccoulson> i thought it did actually just lock the screen
[14:14] <seb128> it could, but they argue that if you don't autolock on screensaver you might not know your password
[14:14] <seb128> and that users are using it as a "running away from the screen"
[14:14] <pitti> YAFIYGI?
[14:14] <seb128> not as a "lock the screen"
[14:14] <seb128> pitti, what? ;-)
[14:15] <pitti> "you asked for it, you got it"
[14:15] <seb128> ah right
[14:15] <seb128> but apparently some people don't realize what they ask for
[14:15] <seb128> and then complain ;-)
[14:15] <pitti> it seems much more useful to me to the majority of people who do know their password *shrug*
[14:15] <chrisccoulson> but the "autolock on screensaver" doesn't affect what the indicator does, does it?
[14:15] <seb128> ok, me too
[14:15] <pitti> seb128: I hope those people won't be able to file bugs either
[14:15] <chrisccoulson> (or did i miss something)
[14:15] <seb128> chrisccoulson, it does now
[14:16] <seb128> chrisccoulson, if you lock on screensaver it's "lock screen" now
[14:16] <pitti> chrisccoulson: but not necessarily
[14:16] <seb128> otherwise it's "start screensaver"
[14:16] <pitti> ctrl+alt+L has always locked your screen regardless of the prefs, too
[14:16] <seb128> tedg make indicator-session read the key
[14:16] <chrisccoulson> that behaviour seems weird to me
[14:16] <seb128> same here
[14:16] <seb128> I was just collecting opinion before undoing the change
[14:17] <seb128> I undo it on the basis it has been done after freeze btw
[14:17] <chrisccoulson> the preference is specifically to control automatic locking when the screensaver activates
[14:17] <pitti> right
[14:17] <seb128> not just because I disagree with it
[14:17] <pitti> but that's not the same
[14:17] <chrisccoulson> if i select the menu item in the indicator, i want the screen to lock regardless of the preference
[14:17] <seb128> same here
[14:17] <pitti> ^ +1
[14:17] <seb128> ok thanks pitti and chrisccoulson
[14:17] <pitti> seb128: thanks for sorting this
[14:17] <seb128> np
[14:18] <seb128> tedg, ^ for the record we have desktop team consensus on this one
[14:18] <tedg> Heh
[14:18] <seb128> tedg, but feel free to register an UDS spec for handling cases where users don't want to know about their password
[14:18] <tedg> seb128: Sure.
[14:19] <tedg> What about the case of switching users?  I think that should match the screensaver settings still.
[14:19] <tedg> It's roughly the same.
[14:19] <tedg> Sorry, same as idle.
[14:19] <seb128> I've no strong opinion about this one
[14:19] <kiko> seb128, so what do you think?
[14:19] <seb128> kiko, that I didn't read the bug because I don't work on gpm, but chrisccoulson might know better ;-)
[14:20] <seb128> kiko, we have a tag for regression though
[14:20] <seb128> it's potential-regression I think or something similar
[14:20] <kiko> chrisccoulson, can you confirm?
[14:20] <seb128> to check with the qa team or on launchpad
[14:20] <pitti> kiko, seb128: "regression-potential"
[14:20] <kiko> thanks pitti
[14:20] <pitti> de rien
[14:21] <seb128> tedg, user switch is tricky, I tend to agree usually you want the same
[14:21] <chrisccoulson> kiko - your bug is not a gpm bug
[14:21] <seb128> tedg, I also tend to think we should be on the secure side by default
[14:21] <kiko> chrisccoulson, ah?
[14:21] <chrisccoulson> its indicator-application (and also a duplicate)
[14:21] <chrisccoulson> it's tedg's bug ;)
[14:21] <pitti> tedg, seb128: I think we should keep locking the screen on user switching, too
[14:22] <seb128> tedg, so I'm not sure, I would prefer to have some people annoyed than creating a security issues for some people
[14:22] <pitti> if not for anything else, then for keeping existing behaviour
[14:22] <tedg> pitti: Well, if nothing else -- it wasn't existing behavior until Thursday ;)
[14:22]  * tedg fixed that bug
[14:22] <pitti> heh, ok
[14:22] <tedg> I think that it's roughly the same as idle.  It's the computer locking for you.
[14:22] <kiko> chrisccoulson, tedg: can you guys help sort it out?
[14:23] <chrisccoulson> if we make changes to the screen-locking behaviour, we should really discuss those with the security team too
[14:23] <tedg> kiko: Which bug?
[14:23] <chrisccoulson> kiko / tedg - bug 529052
[14:24] <seb128> tedg, well the behaviour was non consistant until previous week
[14:24] <seb128> ie switching in gdm was different than switching in the indicator
[14:24] <seb128> like "switch from"
[14:24] <seb128> and directly picking a name
[14:25] <tedg> I think they should be consistent now, it's because we didn't have the names in Karmic, so the name entries didn't get fixed.
[14:33] <pedro_> kenvandine, hello, may you please look into bug 391912 ? I'm getting that at least 5 times per day and we're having more than 100 affected users
[14:34] <baptistemm> Oh the fix is really really wanted ...
[14:36] <baptistemm> pedro_,what should I do to have permissions to edit importance properties of bugs ? at least just a few set I'm interested with.
[14:36] <rickspencer3> pedro_, so that bug was not targeted, milestoned, and it was set to Medium
[14:36] <istaz> pedro_: we have a patch in papyon upstream that would probably fix it (the last one), if you are able to reproduce the issue could you maybe test it?
[14:36] <rickspencer3> by definition kenvandine would not work on it
[14:37] <rickspencer3> pedro_, I made it a release blocker and set it to beta 2
[14:37] <istaz> pedro_: and if not produce a log? (the 2 or 3 lines just before the error should be enough)
[14:38] <seb128> istaz, do you have the upstream bug reference?
[14:38] <seb128> or git
[14:39] <istaz> http://git.collabora.co.uk/?p=papyon.git;a=commit;h=e7c2298acae3b68991c8bf11e049d2ef0da20f88
[14:39] <seb128> istaz, thanks
[14:39] <seb128> pedro_, ^ I will upload that to lucid let me know how it works for you
[14:40] <pedro_> baptistemm, you don't have those?, have a look into https://wiki.ubuntu.com/UbuntuBugControl
[14:40] <pedro_> baptistemm, if you're working on an upstream project which have a project in launchpad just ping jcastro
[14:41] <istaz> seb128: when is the limit date I should make a release before for lucid?
[14:41] <pedro_> seb128, will do it
[14:41] <baptistemm> I'm not particularly working on upstream but I'm following some yes
[14:41] <seb128> istaz, depends of the changes you have
[14:41] <vuntz> :w éé
[14:41] <vuntz> gah
[14:41] <seb128> hey vuntz ;-)
[14:41] <pedro_> salut vuntz
[14:41] <baptistemm> vuntz, : )
[14:42] <vuntz> you saw my secret password!
[14:42] <pitti> bonjour vuntz, comment vas-tu?
[14:42] <seb128> istaz, you still have around 3 weeks to fix bugs
[14:42] <seb128> istaz, but new versions the earlier the better
[14:42] <istaz> vim commands as password, why didn't think of that
[14:42] <seb128> since we try to lower the number of changes when we get close from stable
[14:42] <seb128> ie we will only backport fixes worth it
[14:43] <istaz> seb128: sure, but I still have a pile of works and branches to review :/
[14:43] <istaz> ok
[14:43] <vuntz> pitti: bien, j'ai pu embêter didrocks pendant une semaine !
[14:43]  * pitti tries to make a clueful face, pretending that he understand any of that
[14:44] <didrocks> vuntz: et apprendre la date de release de 2.30.0 aussi :p
[14:44] <vuntz> :-)
[14:44] <istaz> seb128: we are past feaure freeze already? because we have pending branch for file transfer in msn which still need some work
[14:44] <seb128> istaz, yes, month after that
[14:44] <seb128> I guess such changes will be for next cycle now
[14:44] <istaz> guess that will be for lucid+1 then
[14:45] <seb128> I would like to get the http login change in lucid though
[14:45] <seb128> did that land already?
[14:46] <istaz> seb128: I still need to review it but that can be done for the start of next week
[14:46] <istaz> seb128: or the end of this one if you are really  in a hurry
[14:46] <seb128> istaz, beta2 freeze is midweek next week
[14:46] <istaz> ok
[14:58] <nigelb> seb128: if a gnome bug is fixed upstream, do you prefer it to be marked fix commented on LP so you can get the patches in?
[14:58] <seb128> yes
[14:58] <nigelb> okay :)
[14:59] <seb128> pedro_, istaz: git change uploads to lucid let's see how it goes
[15:00] <seb128> pedro_, do you have contacts in your list using the messenger web client?
[15:00] <istaz> thanks
[15:00] <seb128> istaz, thank you!
[15:00] <seb128> istaz, you might want to close https://bugs.freedesktop.org/show_bug.cgi?id=22552
[15:00] <pedro_> seb128, awesome!, thanks
[15:00] <seb128> if that's the same issue
[15:00] <pedro_> seb128, yes i have a couple using that
[15:01] <seb128> pedro_, ok, so it's probably the same bug
[15:01] <pedro_> seb128, nice, will test and comment back to you guys
[15:01] <seb128> pedro_, you can maybe check by asking one to change status and see if it trigger the crash
[15:01] <pedro_> will do
[15:03] <rickspencer3> pitti, seb128 wow, we have quite some list of release blocking bugs for Lucid!
[15:03] <istaz> seb128: yep
[15:03] <seb128> rickspencer3, right I was saying to pitti before the meeting on friday
[15:03] <rickspencer3> 32
[15:04] <istaz> seb128: didn't notice it since it was filled again pymsn
[15:04] <seb128> istaz, sorry about that, it had been open a while ago
[15:06] <seb128> hum, where is mvo?
[15:07] <seb128> I got apt-get source ubuntu-mono doing "getting ubiquity source instead of ubuntu-mono"
[15:07] <seb128> wth?
[15:14] <pochu> ubiquity rewritten in mono? :-)
[15:15] <seb128> lol
[15:15] <seb128> no, ubuntu rewriten in mono!
[15:15] <seb128> ;-)
[15:16] <pitti> seb128: works fine here..
[15:16] <kenvandine> haha
[15:16] <seb128> pitti, here too now, but I was in the middle of an apt-get update
[15:16] <kenvandine> rickspencer3's evil plan
[15:16] <seb128> pitti, I get the index was in a weird state or something
[15:16] <cassidy> seb128, istaz: we should probably re-assign all the pymsn lp bugs to papyon
[15:16] <rickspencer3> kenvandine, ?
[15:17] <seb128> cassidy, the issue for this one was the fdo bug, but right that too
[15:17] <seb128> cassidy, we should perhaps do it on fdo too
[15:17] <kenvandine> ubuntu re-written in mono... boycottnovell would be so excited to hear that :)
[15:17] <seb128> ;-)
[15:17] <seb128> rickspencer3, ubuntu-mono = ubuntu in mono
[15:17] <istaz> cassidy: not really needed most of these bugs are outdated and if there were still valid they were reopened against papyon
[15:17] <rickspencer3> right
[15:17] <seb128> rickspencer3, well name is misleading it's an icon theme
[15:17] <istaz> so we would just end up with a lot of dups
[15:18] <rickspencer3> the reason that Microsoft paid me to quit and work in open source
[15:18] <istaz> and incomplete bugs
[15:18] <cassidy> istaz, your call :)
[15:18] <seb128> rickspencer3, the boycootnovell guys read clearly in your game and new it from the start!
[15:18] <seb128> knew
[15:18] <rickspencer3> I know
[15:18] <rickspencer3> I would have gotten away with it too, if it weren't for those darn kids
[15:18] <kenvandine> that was my first thought when i saw that package name... ubuntu-mono
[15:23] <Keybuk> what will those boycottnovell folks do when Novell inevitably either goes under or gets bought out?  where will all their anger be redirected to?
[15:24] <mdeslaur> Keybuk: boycottcanonical
[15:24] <Keybuk> let's register that now, while we still can!
[15:24] <mdeslaur> we should also register boycottboycottnovell :)
[15:25] <Keybuk> boycottgit.com
[15:25] <kklimonda> chrisccoulson: hey, do you have time to review my transmission update or should I look for another developer who isn't as tied up as you are? :)
[15:25] <chrisccoulson> kklimonda, i will do that today
[15:25] <chrisccoulson> sorry, i actually forgot about it ;)
[15:26] <pitti> Keybuk: boycottgit.com> unnecessary; it already does quite a fabulous job of not wanting people to use it :)
[15:26] <Keybuk> it's certainly making no friends with me today
[15:27] <rickspencer3> seb128, pitti, pedro_ I broke out our release blockers into 3 chunks:
[15:27] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Scratch/ReleaseBugs20100322
[15:27] <rickspencer3> thought I'd share if it helped
[15:27] <kklimonda> the boycottcanonical.com isn't that improbable - all we need is all the whiners to get some free time and they are going to launch it ;)
[15:27] <rickspencer3> that's as of the last time the chron job ran
[15:28] <seb128> rickspencer3, thanks
[15:28] <pitti> rickspencer3: ah, it's cron'ed? using bug tags or so?
[15:28] <rickspencer3> pitti, yeah, bdmurray runs the json searches
[15:28] <qense> djsiegel1: Are you aware that GMail (for Apps in my case) thinks your Canonical mail address may be hoaxy?
[15:28] <pitti> rickspencer3: I was about to say that large wikified bug lists don't generally work that well; e. g. the last bug is already fixed
[15:29] <rickspencer3> pitti, here's one you might like: http://qa.ubuntu.com/reports/team-subscribed/canonical-desktop-team-subscribed-bug-tasks.json
[15:29] <djsiegel1> qense: no I am not aware of that
[15:29] <rickspencer3> every bug on every package that someone on teh desktop team is assigned to
[15:29] <rickspencer3> pitti, right, but I just did it for myself to see where the problem areas seem to be
[15:29] <djsiegel1> qense: but I did notice some odd behavior -- I tried sending an email from my gmail acct to my work email and it ended up in my personal inbox...
[15:29] <rickspencer3> thoguht I'd share since I did the work
[15:29] <qense> djsiegel1: "Warning: This message may not be from the alleged person or organisation. Beware of following any links in it or of providing the sender with any personal information." It spammed bug mail from Launchpad you commeneted.
[15:30] <djsiegel1> qense: that is nuts
[15:30] <pitti> rickspencer3: right, I've seen that list; it's very useful
[15:30] <qense> djsiegel1: This could cause people to miss your comments
[15:30] <djsiegel1> qense: I realize
[15:30] <rickspencer3> pitti, without a cron job, you could never get a list like that
[15:30] <djsiegel1> qense: are you interested in running paper cuts project next cycle?
[15:30] <rickspencer3> well never == less than a few hours ;_
[15:31] <djsiegel1> qense: slash do you have plans to attend UDS?
[15:31] <pedro_> rickspencer3, thanks
[15:31] <rickspencer3> also that list shows how poorly performing by DictionaryGrid filtering and sorting code is :(
[15:33] <qense> djsiegel1: I have applied for sponsorship, so I do have plans, but it depends on the people giving away the sponsorship. I would be glad to help running the papercut project, but I'm not so sure whether I would have enough time. I'm already writing on a blueprint for another project, Ubuntu Wanted, and if that would get accepted I'd have to spend a lot of time on it.
[15:33] <rickspencer3> seb128, pitti do you think it's feasible for us to fix all those release blockers this week?
[15:33] <djsiegel1> qense: would you mind sending me a copy of your UDS sponsor application and the details of Ubuntu Wanted?
[15:33] <rickspencer3> and by "us" I mean everyone but me ;)
[15:33] <pitti> rickspencer3: no, I don't think so
[15:34] <rickspencer3> (not what I wanted to hear, obviously)
[15:34] <rickspencer3> pitti, ok, understood
[15:34] <seb128> rickspencer3, it''s probably not no
[15:34] <rickspencer3> seb128, pitti half?
[15:34] <rickspencer3> knock it down to 10
[15:34] <seb128> that should be possible yes
[15:35] <pitti> right, let's try
[15:35] <qense> djsiegel1: I'm not sure how much I've saved on my computer of the sponsorship application, but I will be able to send you details on Ubuntu Wanted.
[15:39] <chrisccoulson> hmmm, nautilus shows my 3G modem as having a CD drive
[15:39] <pitti> chrisccoulson: most of those have a fake CD-ROM to ship Windows drivers
[15:39] <pitti> chrisccoulson: that's where usb-modeswitch or modem-modeswitch come into play
[15:39] <chrisccoulson> pitti - ah, i didn't realise it actually faked a CD drive
[15:40] <chrisccoulson> i thought it was just a standard removable USB storage device
[15:40] <pitti> no, it's totally useless under Linux
[15:40] <chrisccoulson> am i meant to be able to use both components at the same time?
[15:41] <chrisccoulson> i can access the storage whilst i have a 3G connection
[15:41] <pitti> chrisccoulson: might depend on the hardware
[15:41] <chrisccoulson> my hardware seems to let me do both :)
[15:57] <seb128> didrocks, btw I pushed my gtk changes
[15:57] <seb128> didrocks, and uploaded
[15:57] <seb128> didrocks, you might want to rebase your work
[15:57] <didrocks> seb128: ok, I'm still striking at activating introspection, got a FTBFS :/
[15:58] <seb128> didrocks, ok, how does it break?
[15:58] <didrocks> seb128: one sec, trying something as paste the error if it still fails
[15:59] <seb128> didrocks, you enable it on the shared lib build only right?
[16:00] <didrocks> seb128: there are 3 girs, (I --enable-introspection=yes, shouldn't I?)
[16:01] <seb128> didrocks, right, I was speaking about the build target in gtk
[16:01] <seb128> gtk is build several times
[16:01] <seb128> static build, directfb build
[16:01] <seb128> you don't want to build gir in those cases
[16:02] <didrocks> I saw that, the issue come in directfb build (but it's maybe not the issue as it can be the first)
[16:02] <didrocks> ok, so, let's try to activate it only on shared lib build
[16:02] <seb128> you only need to build it once
[16:03] <seb128> so put it only in the shared configure options
[16:03] <seb128> I'm away for ~15minutes, let me know how it goes and I will read that when I'm back
[16:03] <didrocks> will do, thanks
[16:07] <seb128> ok, time for a small break
[16:27] <tseliot> pitti: shall I take care of the fglrx handler now (and upload whenever you're ok with it) and work on the "prevent Jockey from removing packages and just switch between alternatives instead" feature in a (future and) separate upload?
[16:27] <pitti> tseliot: sounds good; the former should be a trivial change, right?
[16:27] <pitti> tseliot: can you just commit that one to trunk for now?
[16:28] <pitti> tseliot: there's something else I want to work on in the next days, and the change is not that urgent (since there are transitional packages)
[16:28] <tseliot> pitti: yes, it's a small diff: http://pastebin.ubuntu.com/399372/
[16:29] <tseliot> and I would commit it in lp:~ubuntu-core-dev/jockey/ubuntu
[16:29] <pitti> ok
[16:29] <pitti> tseliot: I'm still not that convinced taht this shouldn't ever uninstall packages, though
[16:30] <pitti> if you switch back to the free driver, you'd still keep the dkms overhead around, not even mentioning the fact that some people want to actually remove the non-free bits for political reasons
[16:31] <tseliot> pitti: I see the current scenario: you can install as many drivers as you like (especially if you switch between free drivers quite often) and switch between them without having to uninstall and reinstall things every time.
[16:31] <tseliot> the more you install, the more modules you will have to rebuild
[16:31] <tseliot> of course ;)
[16:31] <pitti> tseliot: yes, but you can do that today, too
[16:32] <pitti> tseliot: the driver isn't uninstalled if you enable a different driver
[16:32] <pitti> it's just unisntalled if you explicitly disable a driver
[16:33] <tseliot> pitti: yes, by manually installing all of the drivers and by switching between drivers by doing the following things: 1) use update-alternatives 2) call ldconfig 3) update the initramfs 4) change your xorg.conf
[16:33] <pitti> also, it's not like people would switch drivers twice a day or so -- they might do that twice a year after an upgrade
[16:33] <tseliot> (not exactly easy, even if documented)
[16:33] <tseliot> that's a good point too
[16:33] <pitti> tseliot: no, I mean in the GUI; disable() is only called if you click "Deactivate", not if you activate a different driver version
[16:35] <tseliot> pitti: I guess that worked because packages could conflict/replace/provide with each other
[16:35] <pitti> correct
[16:35] <tseliot> so it's really a non-issue then
[16:35] <pitti> in previous releases enabling version 180 automatically removed version 96
[16:36] <tseliot> right, I forgot about the logic, even though I worked on it ;)
[16:37] <tseliot> and this means less work for me :-) . So I'll only commit the fglrx enablement code
[16:39] <tseliot> pitti: BTW people keep contacting me asking about an ETA for fglrx support in Jockey. I'm really glad to see that Jockey has become so popular :-)
[16:59] <pitti> :)
[17:20] <seb128> pitti, I just cc-ed you on a gnome-menus bug
[17:20] <seb128> pitti, we should probably not translate Icon=
[17:40] <solidslash> hello, i've got a question - where exactly is a piece of code that would let me get rid of the little 'back history' and 'forward history' arrows in nautilus? is it in nautilus-navigation-action.c ? where exactly?
[17:42] <tgpraveen12> solidslash: it would be better to ask in a channel for nautilus
[17:42] <solidslash> is there one?
[17:43] <ccheney`> new OOo uploads only require me to upload 4MB now instead of 186MB :) goes much faster
[17:44] <Nafai> solidslash: Probably on irc.gimp.net, many gnome related dev channels are there
[17:44] <solidslash> thanks
[17:47] <pitti> seb128: oh, do we?
[17:48] <seb128> pitti, we do translate those yes, and it leads to some bug apparently when the icon name matching a string in the software
[17:50] <pitti> ccheney`: ah, thanks for the OO.o upload; I didn't see any LP refs in the changelog, does that include the pending patches? (arm FTBFS, bug 516727, etc.)
[17:59] <ccheney`> pitti: includes arm patch, i forgot to note, i think it fixes 516727 but not completely sure it does so without any other breakage, as the pre-depends was needed so also didn't write a closes for it in it
[17:59] <ccheney`> pitti: silbs is going to see if it works ok for the office and let me know
[17:59] <seb128> istaz, do you know about bug #194494
[17:59] <seb128> ?
[18:01] <pitti> ccheney`: thanks
[18:02] <istaz> seb128: yup commented three times on it, but wasn't able to find what caused it, haven't been able to take a real look at it since logs have been provided though
[18:02] <istaz> Olivier Le Thanh Duong on the bug is me
[18:03] <seb128> istaz, I know who you are, sorry the question was not clear ;-)
[18:03] <ccheney`> pitti: i didn't fix any other issues with this upload though to get the potential fix for the upgrade problem resolved, will be doing another upload sometime before beta 2 freeze
[18:03] <seb128> istaz, I was wondering if there was any news about this issue or if the patch from jonny on https://bugs.freedesktop.org/show_bug.cgi?id=16945 was likely to fix the issue or is a different one
[18:04] <seb128> rickspencer3, pitti: any opinion on bug #543356 priority, ie is that something we care about enough to put in on the lucid list?
[18:04] <istaz> seb128: it's the same issue, but this is not a patch to fix the issue but to provide more debug logs to locate it
[18:05] <seb128> istaz, ok, so me getting the patch in lucid might help to fix it?
[18:05] <didrocks> pitti: I guess the gdm issue I get is because gconftools take its path regarding the uid and not the euid: stupid code for testing: http://paste.ubuntu.com/399443/, result with id and shutdown command: http://paste.ubuntu.com/399442/.
[18:05] <pitti> seb128: hm, at first sight it seems simple to fix
[18:05] <istaz> yes that's a nice idea actually
[18:06] <pitti> didrocks: perhaps set both effective and real uid? seems safer anyway
[18:06] <didrocks> pitti: as you can see when you'll have some time, I tried to override HOME as well, and it does nothing.
[18:06] <seb128> istaz, ok, will do that, thank you
[18:06] <didrocks> pitti: well, I was pondering about that, no side effect to change real uid as well?
[18:08] <pitti> didrocks: no, it's generally safer to set both with setresuid()
[18:08] <didrocks> pitti: ok, testing that
[18:09] <pitti> didrocks: oh, btw
[18:09] <didrocks> pitti: at least, it taking the right one now :) thanks!
[18:09] <pitti> setenv("HOME", "/var/lib/gdm/", 1);
[18:09] <didrocks> pitti: yeah?
[18:09] <didrocks> pitti: it was just for testing
[18:09] <pitti> didrocks: please use pwent->pw_dir instead of hardcoding
[18:09] <pitti> ok
[18:09] <didrocks> pitti: sure, it was just for testing if it won't take /root/… as HOME
[18:10] <pitti> didrocks: if nothing else helps, this is a more robust approach:
[18:10] <pitti> 1. fork()
[18:10] <pitti> 2. in the parent, wait()
[18:10] <pitti> 3. in the child, setuid(pwent)
[18:10] <pitti> this sets effective, real, file, and saved uid all at once, but can't be reversed any more
[18:10] <pitti> and it avoids changing $HOME for the main program
[18:11] <pitti> didrocks: otherwise you also have to save and restore $HOME
[18:12] <didrocks> pitti: sure, I'm just at least trying to make work this silly program to find a good way for communicating with gdm (still have new issue now that setresuid works), but I'm crossing my finger to find a proper way
[18:12] <pitti> and third, regardless of how badly the child screws up, you don't jeopardize the gdm daemon
[18:13] <rickspencer3> seb128, yes, this seems like terrible attention to detail
[18:13] <didrocks> pitti: sure, I will make a lot of test to not block the parent on that
[18:16] <didrocks> the issue is clearly about changing user, all works with sudo -u gdm … so root -> gdm makes something bad
[18:18] <pitti> didrocks: oh, and you should also change the gid, of course
[18:18] <seb128> time for sport and dinner
[18:18] <seb128> bbl
[18:18] <pitti> (first setgid, then setuid; or, without fork(), setresgid, then setresuid)
[18:18] <pitti> seb128: enjoy!
[18:19] <didrocks> pitti: do you think this is mandatory for gcontool call?
[18:19] <seb128> pitti, thanks
[18:19] <didrocks> seb128: enjoy :)
[18:19] <seb128> didrocks, thanks
[18:19] <pitti> didrocks: if it writes any file, yes
[18:19] <didrocks> pitti: oh sure, didn't think about that
[18:19] <pitti> didrocks: otherwise you'll end up with gdm:root files
[18:19] <didrocks> right
[18:21] <didrocks> well, still an issue, time to get some dinner for a break before retrying this
[18:35] <pitti> after three hours, /me now thinks that he finally understands bug 460328
[18:35] <pitti> but fixing is for tomorrow, Taekwondo o'clock now
[18:35] <pitti> have a nice evening everyone!
[18:45] <highvoltage> hi! How do I do a plymouth dry-run to test a theme?
[18:47] <jono> hey all
[18:48] <jono> I would like to provide a means for my app to add a PPA to someone's system, is there a python API for doing this?
[18:50] <qense> jono: You could see whether software-properties provides an importable implementation of the PPA adding support it is using.
[18:50] <qense> aquarius: When I pressed browse in the Ubuntu One musicstore I got directed to the 7Digitial home page. Could that be related to the fact that ubuntuone-syncdaemon keeps raising Apport error messages and that Ubuntu One isn't properly working on my system?
[18:51] <aquarius> qense, that's a known bug :(
[18:51] <aquarius> qense, please avoid pressing browse for now...
[18:52] <qense> ok, I will avoid Browse then
[18:52] <qense> thanks!
[18:52] <tedg> jono: There might be an apt-daemon API to do this.
[18:52] <tedg> jono: You can just use the command line.
[18:53] <tedg> jono: add-apt-repostory ppa:~ted/ppa
[18:53] <qense> of course! I forgot.  apt-daemon is probably the best way to do so.
[18:53] <jono> tedg, I know I could use subprocess, but I was hoping to avoid that :-)
[18:53] <qense> It could even be that it launches the PolicyKit dialogue by itself, but I'm not sure about that.
[18:54] <tedg> jono: Seems like org.debian.apt.AddRepository probably does what you want.
[18:55] <qense> jono: If you're looking for a snippet, Software Centre is probably the correct place since it should be capable of activating/adding PPAs.
[18:55] <jono> qense, a snippet would be awesome
[18:55] <jono> I just want to make setting up python-snippets-daily a one-click affair
[18:56] <qense> Maybe Quickly could help with that... Bazaar is one big Python library, after all.
[19:00] <qense> aquarius: By the way, I wish you success with handling the floodgates of madness that have been opened by enabling the music store. Maybe we should plan a Bug Day for the music store in the near future?
[19:00] <aquarius> qense, perhaps so, indeed. I'll see what sorts of bugs we get
[19:00] <qense> ok
[19:01] <qense> If you need any help with setting up such a bug day, feel free to ping me!
[19:01] <tedg> jono: I think it would be interesting to provide a way to have a generic application called "megaphone" that would work with PPAs that updated regularly and announce them.  So you could have something like Marin's font of the week, and when it gets installed you get a notification of it.  Obviously it wouldn't work with security updates, but for extra things you want to get excited about.  Haven't had time to write it though :(
[19:01] <aquarius> I will do, definitely :)
[19:02]  * tedg needs minions.  Anyone know an aging evil dictator that I can impersonate?
[19:03] <jono> tedg, indeed :)
[19:22] <didrocks> \o/ GDM has been *finally* defeated! we can change a gconf key now on the server side
[19:40] <kenvandine> didrocks, yay!
[20:30] <rickspencer3> didrocks, congrats
[20:30] <seb128> didrocks, congrats (just joined so I don't know about what :p)
[20:31] <didrocks> seb128: heh thanks ;) finally defeated the gdm/gconftool mess :)
[20:31] <didrocks> seb128: I'm refactoring the get/set code now and will probably finish tomorrow morning so that we can easily that different values later
[20:31] <didrocks> seb128: already back from sport?
[20:32]  * seb128 hugs didrocks
[20:32] <seb128> didrocks, how did you fix it?
[20:32] <seb128> didrocks, "already", I was away 2 hours
[20:32]  * didrocks hugs seb128 back
[20:32] <seb128> I didn't eat or take my shower yet though
[20:33] <seb128> just passing by and checking everything is already before doing that
[20:33] <didrocks> seb128: setting real uid/gid as well as effective uid/gid + home dir and --direct :) (dbus-launch spawn some processes without closing them)
[20:34] <didrocks> seb128: oh ok, enjoy your dinner then :)
[20:34] <seb128> didrocks, ok
[20:34] <seb128> didrocks, thanks
[20:52] <didrocks> ok, the get part is working after refactoring to take any value of any type. Will do the same for the set part tomorrow, time to enjoy the evening :)
[20:52]  * didrocks waves goodbye
[20:53] <seb128> didrocks, have fun, see you tomorrow
[20:53] <didrocks> seb128: thanks, have a good night
[21:00] <rickspencer3> didrocks, great job on GDM, congrats again!
[21:07] <kenvandine> rickspencer3, how long did it take to get your song downloaded?
[21:07] <rickspencer3> kenvandine, hard to say
[21:07] <rickspencer3> it was pretty much instantaneous
[21:08] <rickspencer3> I looked around for it on my hardrive and couldn't find it
[21:08] <rickspencer3> then I thought to look in Library, and it was already there
[21:08] <kenvandine> great
[21:08] <kenvandine> :)
[21:08] <kenvandine> don't expect it to always be that fast :)
[21:08] <rickspencer3> kenvandine, have there been issues?
[21:09] <kenvandine> well, when the download daemon was broken it took until someone kicked it manually :)
[21:09] <kenvandine> but it should start pretty quickly
[21:09] <rickspencer3> hehe
[21:09] <kenvandine> it will depend on how many people are downloading at any given time
[21:09] <rickspencer3> kenvandine, is it fixed now?
[21:09] <kenvandine> yup!
[21:09] <rickspencer3> makes sense
[21:09] <kenvandine> it gets queued up in the cloud to download
[21:09] <kenvandine> so if you are the only shopper it should be real fast
[21:09] <rickspencer3> U1 music store + iPod/iPhone support = main stream product
[21:09] <rickspencer3> !
[21:09] <kenvandine> ~/.ubuntuone/Purchased\ from\ Ubuntu\ One/
[21:09] <kenvandine> woot!
[21:10] <rickspencer3> kenvandine, right, but users should drag out of RB I assume, right?
[21:10] <kenvandine> rickspencer3, i know, amazing huh?
[21:10] <kenvandine> they should just trust RB knows :)
[21:10] <kenvandine> yeah, RB knows where they are
[21:10] <rickspencer3> but I mean if you wanted to back it up outside of U1
[21:11] <rickspencer3> copy it wherever you want, etc...
[21:11] <rickspencer3> we tell users to drag from RB, right?
[21:12] <kenvandine> yup
[21:12] <rickspencer3> nice too see so much Grateful Dead in the store
[21:12] <kenvandine> hehe
[21:12] <kenvandine> :)
[21:12] <rickspencer3> now it has credibility
[21:12]  * kenvandine still doesn't picture rickspencer3 as a dead head
[21:12] <rickspencer3> I have to wonder why they bother with other bands, really
[21:15] <LaserJock> so how do you go from Ubuntu One/RB to iPod?
[21:19] <seb128> dnd
[21:19]  * kenvandine doesn't have an ipod... but i would imagine just drag the music to the ipod
[21:20] <kenvandine> that is what i did on my G1
[21:20] <kenvandine> LaserJock, the U1 music just syncs to RB
[21:20] <kenvandine> so once it is in your library it behaves the same as any other music
[21:20] <LaserJock> kenvandine: right, but I've never been able to get music from RB to iPod
[21:20] <kenvandine> DRM free :)
[21:20]  * kenvandine can't help there
[21:21] <LaserJock> as far as I know RB is read-only for iPods
[21:21] <kenvandine> oh... actually i did do that
[21:21] <kenvandine> my daughter's ipod
[21:21] <kenvandine> she syncs it from rb
[21:21] <LaserJock> I was hoping somebody would do something simple-scan'esqe for iPods :-)
[21:21] <kenvandine> she is 7... she figured it out :)
[21:21] <kenvandine> i plugged it in for her the first time, that was about it
[21:21] <LaserJock> hmm
[21:22] <kenvandine> her's is old though
[21:22] <LaserJock> I spent 2 days trying to get it to work
[21:22] <kenvandine> old nano
[21:22] <seb128> LaserJock, dnd to ipod works fine
[21:22] <LaserJock> mine is from 2006
[21:22] <seb128> LaserJock, I'm doing that for several years
[21:22] <seb128> in rhythmbox
[21:23] <kenvandine> i plugged it in for her and it just worked... it was nice to see that considering i installed lucid for her at the same time we gave her the old ipod :)
[21:23] <seb128> rhythmbox works with pretty much all ipods
[21:24] <seb128> up to the most recent nano and touch and iphones
[21:28] <LaserJock> doesn't seem to work here
[21:29] <LaserJock> I rarely us drag-n-drop so maybe I'm doing it wrong
[21:29] <seb128> it's easy
[21:29] <seb128> click on something with the left mouse button
[21:29] <seb128> keep the button press
[21:29] <seb128> go over where you want to drop
[21:29] <seb128> stop clicking
[21:30] <LaserJock> ok, did that, but it just falls back to where it was
[21:30] <seb128> you can dnd a song, album, artist over the ipod device
[21:30] <seb128> what do you try to dnd and where?
[21:30] <TheMuso> pitti: re bug 528524 I personally don't know where to start in debugging this unfortunately, my skills with PA don't extend that far. :)
[21:30] <seb128> you need to dnd over the ipod icon in the sidebar
[21:31] <LaserJock> seb128: I was wanting to send a playlist
[21:31] <LaserJock> that doesn't seem to work
[21:31] <LaserJock> but I think maybe I got a song over there
[21:31] <seb128> not sure if playlist copies work
[21:31] <seb128> I never do that
[21:31] <seb128> I usually dnd albums there
[21:32] <LaserJock> I need playlists to be able to find music instead of podcasts
[21:33] <LaserJock> the whole music thing is an awful mess for me
[21:33] <LaserJock> I finally gave up and installed iTunes on a Windows 7 partition (yeah, that desperate)
[21:35] <LaserJock> ok, so it seems I can do individual songs and albums in RB, that's something anyway
[21:35] <LaserJock> I would never have guessed to try drag-n-drop
[21:35] <rickspencer3> fudge
[21:35] <rickspencer3> I got that Messaging Menu -> Xchat crash again
[21:35] <Nafai> :(
[21:35] <rickspencer3> but apport won't le me log the bug'
[21:36] <rickspencer3> plymouth version was out of date :(
[21:37] <Nafai> I just bought my first track via Rhythmbox!
[21:38] <Nafai> And, no, I won't share which track :)
[21:42] <ccheney`> rickspencer3: cc'd you on the email to stefan
[21:43] <rickspencer3> thanks ccheney`
[21:44] <seb128> Nafai, hey
[21:44] <Nafai> Hi seb128
[21:44] <seb128> Nafai, any news about those bugs you work on?
[21:44] <seb128> Nafai, I don't think I've seen any update from you in 10 days now :-(
[21:46] <Nafai> seb128: brb, need to reboot and then we can discuss this so I can make significant progress now that I've got a lot of stuff out of my way
[21:47] <seb128> ok
[21:47] <seb128> rickspencer3, any though on things like bug #533520?
[21:47]  * rickspencer3 looks
[21:48] <seb128> rickspencer3, I'm not sure if we should consider it as a lucid blocker or not, it's cosmetic but is also the sort of issues users will easily notice
[21:48] <rickspencer3> does not seem like a blocker, but I am looking
[21:49] <seb128> rickspencer3, see screenshot in comment #2
[21:49] <rickspencer3> it's a bit hard to read, but not impossible
[21:49] <seb128> comment #3 rather
[21:49] <rickspencer3> seems appropriately set to me
[21:49] <seb128> ok, thanks
[21:49] <seb128> I was just not sure how much we care about "looking good"
[21:49] <rickspencer3> I would ship like this, but might be good for "top bugs"
[21:50] <rickspencer3> seb128, of course we care, but hold up release? probably not
[21:50] <seb128> right, that was my though
[21:50] <rickspencer3> also, the fix is probably trivial enough that we could SRU it
[21:50] <seb128> right we can probably easily workaround
[21:51] <seb128> the proper fix would be to port the widget ot a gtkinfobar
[21:51] <seb128> hey robert_ancell
[21:51] <robert_ancell> seb128, hello
[21:51] <seb128> robert_ancell, how are you?
[21:51] <robert_ancell> seb128, good
[21:56] <robert_ancell> seb128, oh, I got a friend to install UNR on his EEE (he likes it more than the standard EEE image).  He didn't have enough space left though so I played the how many packages can I remove.  Long story short, I'm planning to go into battle next cycle and convince you splitting gnome-utils is a good idea :)
[21:58] <seb128> I think we have other issues to deal with that fighting to be able to remove the screenshooter
[21:58] <seb128> or the log viewer
[21:58] <seb128> but yeah, let's see how this discussion goes :p
[21:58] <robert_ancell> bring it on!
[21:58] <LaserJock> fight! fight! fight!
[21:58]  * LaserJock grabs some popcorn
[21:59] <robert_ancell> LaserJock, you have to wait for UDS.  Then there'll be real blood.  Got my flights booked yesterday :)
[21:59] <seb128> how much disk space did he have?
[21:59] <seb128> the lower ssd I could get on the dell mini was 8G
[21:59] <seb128> which is twice an ubuntu standard install
[21:59] <robert_ancell> seb128, afterwards 900M.  Didn't check before but it was probably about 300M
[22:00] <robert_ancell> seb128, the install came down to 2.4G after removing as much as I dared
[22:00] <rickspencer3> RAOF, hi
[22:00] <seb128> I would argue it's a corner case
[22:00] <seb128> you can't even buy a disk under 8G nowadays
[22:00] <RAOF> rickspencer3: Good morning.
[22:00] <robert_ancell> seb128, I would argue it's a bad user experience
[22:00] <seb128> right, for how many users?
[22:00] <robert_ancell> seb128, enough
[22:00] <seb128> we better spend time on making the system boot faster or looks better
[22:01] <seb128> than benefit higher number of users than those who don't have 5G of disk
[22:01] <robert_ancell> seb128, well, I'll probably end up doing while flying somewhere.  That's what I did last time...
[22:01] <seb128> I'm not sure I will let that one go in though :p
[22:01] <seb128> I dislike the explosion of binaries
[22:01] <robert_ancell> seb128, and you know I'll keep arguing so we'll waste more time arguing it that just doing it! ;)
[22:02] <seb128> it makes apt indexer harder to deal with
[22:02] <seb128> each apt-get update run slower
[22:02] <seb128> package management tools slower
[22:03] <robert_ancell> seb128, meh.  It's one package we're talking about... And then all the default installed packages behave sane
[22:04] <seb128> gnome-media?
[22:04] <seb128> gnome-applets?
[22:04] <seb128> gnome-panel?
[22:05] <robert_ancell> seb128, hmm
[22:05] <robert_ancell> though I only consider gnome-media a good candidate there
[22:05] <seb128> I just fail to see why users would care about uninstalling a tiny binary
[22:07] <robert_ancell> seb128, it's not the binary, it's more the .desktop file
[22:07] <seb128> they can edit the menu if they don't want them there ;-)
[22:08] <robert_ancell> seb128, that's not logical
[22:08] <robert_ancell> there's no logical connection between the screenshot tool and the dictionary
[22:09] <robert_ancell> we expose upstream development policy to users which is bad
[22:09] <seb128> there is no logic connection between cp and ls
[22:09] <robert_ancell> seb128, they're power tools
[22:09] <seb128> I hope you don't plan to split every binary in its own package :p
[22:10] <robert_ancell> I don't think there are a lot of other cases.  It's only projects in an umbrella organisation like GNOME that mix applications into one tarball
[22:10] <dyek> Hi! Can Ubuntu desktop (karmic) be setup to do xdmcp easily?
[22:10] <seb128> dyek, hi, user questions go on #ubuntu but I don't think so no
[22:11] <dyek> seb128: OK! Thanks!
[22:11] <seb128> robert_ancell, well I sort of see your point, I just feel we have other issues to work on which would better benefit users
[22:11] <seb128> robert_ancell, if you really care about that I guess just do the change that will be easier than arguing ;-)
[22:11] <seb128> robert_ancell, you would make an higher number of user happy by improving gdmsetup for example than doing that during the same time though ;-)
[22:13] <robert_ancell> seb128, It will make me happy :)
[22:13] <Nafai> seb128: ok, back.  I admit all I've got done (visible progress) is adding some logging to notify-osd which I intend to use for debugging things like the rhythmbox issues.  Been bad especially the last few days dealing with interruptions (paperwork, contracts, dr appts and such), but I'm ready to give full attention
[22:13] <seb128> Nafai, hey, no need to justify just tell me if you are not able to work on those so we can dispatch elsewhere and get them done for lucid
[22:13] <robert_ancell> didrocks, oh, did anything happen about gdmsetup?
[22:14] <seb128> Nafai, ok good
[22:14] <Nafai> seb128: Sure thing, I'll let you know as soon as tomorrow what I anticipate
[22:14] <seb128> robert_ancell, he's refactoring the changes apparently and got it working
[22:14] <seb128> Nafai, thanks
[22:14] <seb128> robert_ancell, writting to other users gconf config is no fun
[22:14] <robert_ancell> seb128, sweet!
[22:15] <seb128> I hope gsettings will fix that
[22:15] <robert_ancell> seb128, yeah, I've tried and failed at that a few times...
[22:15] <robert_ancell> seb128, yes, I was going to ask the same thing.  Perhaps we should raise that in case it hasn't been considered
[22:16] <Nafai> seb128: which is higher priority bug #451086 or bug #497883 -- I'm guessing the former because it is a bug in an existing feature, the other is a new feature (I just need to respond to Ken's reports/feeedback)
[22:16] <seb128> Nafai, right, I think it's too late now for a new feature, ie to do the vino change
[22:16]  * Nafai nods