[08:06] <didrocks> good morning
[08:18] <crevette> òla
[08:19] <didrocks> lut crevette
[08:19] <crevette> salut didrocks
[08:27] <didrocks> hey seb128
[08:27] <seb128> hello didrocks
[08:27] <seb128> ca va ?
[08:28] <seb128> brb after upgrade session restart
[08:31] <seb128> ok
[08:31] <seb128> should be good now
[08:34] <seb128> hum, does anybody know if suspend is supposed to work on desktop configs?
[08:34] <seb128> it crashes my desktop apparently
[08:35] <seb128> robert_ancell, hey
[08:35] <seb128> robert_ancell, libgdata is waiting in debian NEW we will sync from there when ti's accepted
[08:35] <robert_ancell> hey seb128
[08:35] <robert_ancell> seb128, the all knowing seb :)
[08:36] <seb128> ;-)
[08:42] <seb128> robert_ancell, we don't need blueprint for every changes
[08:43] <seb128> robert_ancell, ie a binary split is good for bug or mailing list discussions
[08:43] <robert_ancell> seb128, I wanted to bring all the info into one place.  Things get very frayed in email :)
[08:44] <seb128> robert_ancell, the bug would be good enough for that I think
[08:44] <robert_ancell> seb128, sure
[08:48] <robert_ancell> ok, I'm outta here - have a good weekend
[08:49] <mvo> bye robert_ancell
[08:49] <robert_ancell> cya
[08:53] <didrocks> seb128: bien, et toi ? :)
[08:59] <seb128> didrocks, très bien merci ;-) juste un peu fatigué comme tous les vendredis
[09:14] <seb128> ArneGoetje, hello
[09:15] <seb128> ArneGoetje, I switched language-selector to gtkbuilder could you review it?
[09:19] <mac_v> mvo: hi... just wondering...why are you accepting feature tweak/request bugs when synaptic is going to be replaced by AppCenter?
[09:20] <mac_v> i feel ,its unnecessary work/duplication load for you
[09:20] <mvo> mac_v: sentimental reasons?
[09:20] <mac_v> :) oh... ok
[09:21] <mvo> mac_v: but I also don't think it will go away, its still a nice tool and has users that love it
[09:22] <mvo> mac_v: at least the initial appcenter will not work on a package level (later versons will) so its still useful until then at least to keep synpatic in shape
[09:22] <mac_v> mvo: yeah, there are a *lot* of fans.
[09:23] <ArneGoetje> seb128: I can try
[09:23] <mac_v> mvo: BTW , are you working on Appcenter too?
[09:24]  * proppy reading https://wiki.ubuntu.com/AppCenter
[09:24] <mvo> mac_v: yes, mostly research/non ui stuff up until now
[09:24] <seb128> ArneGoetje, good, one minute I do a small change and push that online
[09:24] <mvo> like xapian integration
[09:24] <ArneGoetje> seb128: although it might be better if mvo reviews and does the merge... I don't have upload rights anyways.
[09:24] <seb128> ArneGoetje, I've upload rights no worry
[09:25] <mac_v> mvo: can anything be done so that update-xapian doesn eat resources?
[09:25] <mac_v> doesnt^
[09:25] <mvo> during the indexing?
[09:25] <mac_v> yeah
[09:25] <mvo> or later when its actually used?
[09:26] <mvo> well, some improvements are there now, there is a --upate switch that only re-indexes changed packages. so on my system a re-index in the morning takes ~4s instead of 40 now
[09:26] <mvo> its also run with ionice, but its difficult to get it down even further
[09:26] <mac_v> \o/ nice
[09:27] <rodrigo_> shouldn't REVU send mails for the comments added to the submission?
[09:27] <rodrigo_> I don't recall getting one for the last comment from pitti in http://revu.ubuntuwire.com/p/evolution-couchdb
[09:31] <mvo> ArneGoetje: I can review it, a second pair of eyes would be nice though (and/or a bit of testing)
[09:32]  * mvo looks at the diff
[09:33] <seb128> ArneGoetje, lp:~seb128/language-selector/gtkbuilder
[09:42] <mvo> ArneGoetje, seb128: diff looks fine to me (code-wise). I have not tested/loaded the UI
[09:48] <chrisccoulson> good morning everyone
[09:49] <seb128> hey chrisccoulson
[09:49] <seb128> chrisccoulson, do you plan to fix the g-s-d .install today or should I do it? ;-)
[09:50] <chrisccoulson> seb128 - i did it last night didn't i?
[09:50] <seb128> chrisccoulson, didn't get any bug comment
[09:50] <seb128> or, you just changing it to new but didn't write anything
[09:50] <seb128> I didn't get that was done sorry
[09:51] <chrisccoulson> ah. i pinged you in IRC i think. perhaps you missed that?
[09:51] <seb128> yes
[09:51] <chrisccoulson> sorry, i probably should have commented on the bug too
[09:51] <seb128> sorry about that
[09:51] <chrisccoulson> thats ok:)
[09:51] <seb128> yeah, everything alright
[09:52] <chrisccoulson> so, everybody is winding down for the weekend now are they?;)
[09:52] <seb128> annoying that it stil use glade
[09:52] <seb128> chrisccoulson, yeah, did you get a day off work?
[09:55] <chrisccoulson> seb128 - not today - i had yesterday afternoon off instead
[09:55] <seb128> ok
[09:55] <chrisccoulson> although, there's never any point in coming to work on fridays really
[09:55] <seb128> ;-)
[09:55] <chrisccoulson> friday's are a "slow work day" for me;)
[09:55] <seb128> good, you can triage some ubuntu bugs :-p
[09:56] <chrisccoulson> i could do. but i have to finish my coffee first;)
[09:56] <seb128> lol
[09:59] <seb128> chrisccoulson, g-s-d looks good now ;-)
[09:59] <seb128> out of the fact that they still use glade grrr
[10:00]  * chrisccoulson breathes sigh of relief
[10:00] <chrisccoulson> yeah, i didn't realise they still used glade. that's why i renamed .glade to .ui in the install file
[10:00] <chrisccoulson> there's not much using glade though is there? perhaps it could be something easy for me to port
[10:01] <seb128> would be nice to automate dh_install --list-missing in builds and break if it's not empty or something
[10:01] <chrisccoulson> yeah, that would be nice
[10:01] <chrisccoulson> although it wouldn't be good to break in builds where you deliberately miss out files
[10:02] <seb128> well you could clean debian/tmp in the rules
[10:03] <seb128> well or at least have a variable to set to stop you on dh_install --list-missing when not empty
[10:03] <seb128> asking to ack that you want to ignore those
[10:04] <chrisccoulson> yeah, that's quite a good idea
[10:04] <seb128> chrisccoulson, g-s-d is fixed in git already
[10:04] <seb128> I mean the remaining .glade has been converted there
[10:05] <chrisccoulson> seb128 - thanks, thats good to know. so thats one more package that won't depend on glade soon then:)
[10:05] <seb128> anybody wanting to tackle some of the available upgrades today? ;-)
[10:06] <seb128> chrisccoulson, yeah, I'm keeping track of those on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnome-3
[10:08] <seb128> we will still have some libglade use in default karmic
[10:08] <seb128> but should manage to tackle those before the lts
[10:11] <chrisccoulson> yeah, there still looks like there's a fair bit left to do, but at least upstream are quite active with porting the remaining applications across too
[10:13] <seb128> chrisccoulson, well, if you clean apps fixed in git or those with patches ready you only have 7-8
[10:59] <seb128_> ArneGoetje, any comment on the gtkbuilder version?
[13:10] <mvo> seb128_: I put something that we may need for the install-updates-on-shutdown to lp:~mvo/gnome-session/run-on-shutdown
[13:14] <vuntz> mvo: hrm, is this something like http://bugzilla.gnome.org/show_bug.cgi?id=528812 ?
[13:14] <seb128_> mvo, ok, I've no real objection with the change but upstream might not agree with it
[13:15] <seb128_> vuntz, no, it's to run a command in a sync way before closing
[13:15] <seb128_> mvo, open a bugzilla bug for it?
[13:15] <vuntz> seb128_: you didn't read the bug ;-)
[13:16] <seb128_> vuntz, ah right
[13:16] <seb128_> mvo, ^
[13:17]  * mvo reads
[13:18] <mvo> seb128_: upstream may not like it? I'm sure with enough ice-cream ...
[13:18] <vuntz> pretty sure that the bug I linked too is the right way to do it
[13:18] <vuntz> if you need to do things on shutdown only, we might just set an environment variable before running the stuff
[13:18] <seb128_> mterry rocks ;-)
[13:18] <vuntz> like GNOME_SESSION_LEAVING={logout,reboot,shutdown}
[13:19] <seb128_> mvo, I'm still not sure if that should be run in the user session though
[13:19] <mvo> vuntz: that sounds pretty good - will it be able to block the logout a certain amount of time too?
[13:19] <seb128_> ie I feel it would be cleaner to close the session and run an upgrade session
[13:19] <seb128_> but that might be not as easy
[13:19] <mvo> seb128_: my initial idea was to run it in usplash even
[13:20] <seb128> that's what I was thinking this morning
[13:20] <vuntz> mvo: well, we were talking about having a timeout to not block forever
[13:20] <seb128> but I figured it would not be nice looking
[13:20] <seb128> vuntz, context there is to do upgrades before shutdown
[13:20] <vuntz> would this imply having some graphical stuff running?
[13:20] <mvo> vuntz: yes
[13:20] <vuntz> hrm
[13:21] <vuntz> hopefully, they don't need to interact with anything else on the desktop since, well, everything else would be dead ;-)
[13:21] <mvo> thats ok
[13:21] <mvo> the idea was that its totally non-interactive
[13:21] <mvo> but its still nice to have X around :)
[13:21] <mvo> much nicer progress bars
[13:23] <vuntz> so the thing is that you really can't have a timeout for the upgrade case
[13:23] <vuntz> since you don't want to kill it
[13:23] <mvo> vuntz: if that patch is the right way forward, I will clean it up and merge it into our packages
[13:23] <mvo> vuntz: yeah
[13:23] <seb128> mvo, do you need to be able to click on button, ie skip the upgrade or something?
[13:23] <mvo> vuntz: it will have a timeout, but it will be a internal one
[13:23] <mvo> vuntz: internal to the updates-on-shutdown stuff
[13:23] <mvo> seb128: yes, there will be buttons too (to cancel)
[13:23] <seb128> ok
[13:24] <vuntz> mvo: by default, gnome-session should have a timeout. It's just that there should be a way to disable it for your use case, I guess
[13:24] <mvo> seb128: it should also be part of the shutdown dialog (I guess) - shutdown, shutdown with applying patches
[13:24] <mvo> vuntz: sounds ok to me
[13:24] <seb128> mvo, the way microsoft does it I think is to use a modifier when clicking the action or click on an icon next to it
[13:25] <seb128> mvo, I wouldn't like having yet another option in the list
[13:25] <mvo> I don't mind how its triggered :)
[13:25] <mvo> I guess I will sumon the design team and ask for input
[13:26] <vuntz> mvo: so yeah, I think it'd make sense to clean up the upstream patch. Just not sure how to add the "disable gnome-session timeout" part
[13:26] <seb128> yeah
[13:26] <seb128> why not having a some hour timeout?
[13:26] <vuntz> especially since, well, you don't want random stuff to disable this timeout
[13:27] <seb128> do we have cases were upgrades run over 6 hours?
[13:27] <mvo> yeah, I guess if the timeout is long enough?
[13:27] <mvo> or maybe just have something in (system) gconf that adds a process name for exceptions from the timeout
[13:27] <mvo> so timeout by default for everything that is not in this exception list
[13:45] <seb128> MacSlow, the fact that notify-osd doesn't call gtk function directly doesn't make the bug not be a bug
[13:46] <seb128> MacSlow, ie the bug could be an incorrect gtk use, or a gtk bug, or a confusing gdb stacktrace
[13:47] <MacSlow> seb128, but how should I debug that?
[13:47] <seb128> MacSlow, well ask for a valgrind log or a debug stacktrace or ask for steps to trigger the issue
[13:47] <seb128> MacSlow, if apport catch a crash that's usually because the application crashed and there is a reason
[13:48] <seb128> could be a gtk bugs in which case they should be reassigned and not closed
[13:51] <seb128> MacSlow, anyway you are right to focus on bugs which are clearly notify-osd issues first ;-)
[16:15] <asac> seb128: my system hung up for the second time today (e.g. suddenly no keyboard anymore) ... i got this in my syslog: http://paste.ubuntu.com/230629/
[16:15] <asac> have you seen this? maybe it triggered this problem?
[16:20] <seb128> asac, nop, didn't see anything similar
[16:20] <asac> i booted with previous kernel now. if it doesnt happen again its -3
[16:20] <seb128> asac, what gnome-session version do you have?
[16:20] <asac> otherwise i probably will see the same in syslog again and come back
[16:20] <asac> let me check
[16:20] <asac> 2.27.4-0ubuntu1
[16:20] <seb128> ok, so that's not it
[16:21] <asac> seb128: what debug packages should i install to make the backtrace more useful?
[16:21] <asac> (in case i get one again)
[16:21] <seb128> could you install gnome-session-dbgsym?
[16:21] <seb128> trying to get an useful stacktrace
[16:21] <asac> anything else?
[16:21] <seb128> libglib2.0-0-dbg
[16:21] <seb128> libgtk2.0-0-dbg
[16:21] <asac> seb128: yeah sure. does gnom-setssion catch segfaults?
[16:21] <seb128> should be enough
[16:21] <asac> maybe it should re-throw them so apport could pick them up
[16:21] <asac> yes will install those
[16:21] <seb128> it didn't use to but your log seems to suggest it does now
[16:22] <seb128> ok
[16:31] <dobey> Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers.
[16:31] <dobey> nice :(
[16:32] <dobey> how do i figure out why the hell the rhythmbox import helper binary thing is SIGABRTing? apport seems to ignore SIGABRT, and i can't import my new music into rbox :(
[16:43] <mat_t_> hi all
[16:45] <mat_t_> seb128: pitti: do you think we could show the animated throbber between the gdm and the user session? Right now it takes a long time to load the desktop session and nothing happens on the screen
[16:52] <chrisccoulson> seb128 - i'm confused about gnome-session catching crashes. it doesn't seem to do that intentionally
[16:52] <chrisccoulson> is it possible for external libraries to register signal handlers
[16:52] <chrisccoulson> ?
[16:52] <chrisccoulson> i had this issue when debugging the last gnome-session crash (which didn't actually crash in the end, but it froze in the signal handler after catching the SIGSEGV)
[16:54] <chrisccoulson> ah
[16:55] <chrisccoulson> actually, it does catch it
[17:01] <seb128> mat_t_, we had a transition effect but Keybuk turned it down because it takes login time
[17:01] <Keybuk> that wasn't a transition effect
[17:01] <Keybuk> that was a pointless animation from a black screen
[17:01] <Keybuk> done at a random time while everything else was busy
[17:02] <seb128> chrisccoulson, gnome-session/gdm-signal-handler.c:        gdm_signal_handler_add (handler, SIGSEGV, NULL, NULL);
[17:03] <chrisccoulson> seb128 - thanks, i just spotted that
[17:03] <seb128> mat_t_, the goal was rather to have things loading fast than to add animations though
[17:03] <mat_t_> seb128: yeah good point
[17:04] <seb128> but I guess we could do a small animation if that's not fast enough
[17:04] <seb128> better than the one we had which had issue as Keybuk said
[17:04] <mat_t_> seb128: yes, just a small throbber
[17:04] <mat_t_> that should not slow the boot down I guess
[17:04] <seb128> probably not much
[17:05] <Keybuk> mat_t_: if it does, I know where you live
[17:05] <seb128> lol
[17:06] <mat_t_> hahaha
[17:06] <mat_t_> Keybuk: I make sure it does, just to check how quickly you can move ;)
[17:09] <mat_t_> Keybuk: btw, do you think there is any reliable way of smoothing the transitions on user-switch? Basically now we reset the X session, which is a sudden "blackout" and then the screen pops back in
[17:10] <Keybuk> mat_t_: not for karmic
[17:10] <Keybuk> that would involve re-using the X server
[17:10] <mat_t_> uhm
[17:10] <Keybuk> and I don't think anyone's even thought about thinking about that yet
[17:10] <mat_t_> yeah
[17:11] <mat_t_> at least it is fast now :)
[17:46] <chrisccoulson> seb128 - how would you feel about stopping gnome-session from catching SIGSEGV for now, so people can submit crash reports with apport in the usual way?
[18:11] <seb128> chrisccoulson, +1
[18:12] <chrisccoulson> seb128 - just looking at bug 404219
[18:13] <chrisccoulson> seems upstream changed the location of the gconf keys :-/
[18:15] <chrisccoulson> they were in /desktop/gnome/peripherals/mouse in the old version but are in /desktop/gnome/peripherals/touchpad in the new version, which I assume means that gnome-control-center modifies the wrong keys now
[18:16] <seb128> chrisccoulson, could be
[18:17] <seb128> would be easy enough to add copy to read old key if it has a value and copy it
[18:17] <chrisccoulson> so, i don't know whether to reassign that to g-c-c and change the gconf keys there. if we do that, then we probably need some way of migrating existing configs from jaunty
[18:17] <seb128> and clean it
[18:17] <chrisccoulson> ok, so we can update g-c-c and also patch g-s-d to copy the old config to the new location?
[18:18] <seb128> right
[18:18] <chrisccoulson> i can work on that then if you agree that's the right way to do it
[18:21] <seb128> well we don't have good ways to do user config changes on upgrade
[18:21] <seb128> so I don't see a better way right now
[18:21] <seb128> that forces us to keep a patch but that should be easy enough and work
[18:22] <seb128> time for dinner
[18:22] <seb128> bbl
[18:22] <chrisccoulson> seb128 - agreed. i'll work on a patch for that
[18:23] <chrisccoulson> enjoy your dinner
[18:23] <seb128> thanks, you too
[18:44] <didrocks> quickly 0.1 is released \o/ Check it out at https://launchpad.net/quickly :)
[18:45] <crevette> what is quickly
[18:45] <didrocks> crevette: The main page should give a good description of what it is :)
[18:45]  * crevette is looking at the page
[19:02] <rickspencer3> didrocks: congrats!
[19:02] <rickspencer3> $quickly release
[19:04] <didrocks> rickspencer3: thanks, congrats to you too :)
[19:04] <kenvandine> didrocks, quickly 0.1...  awesome!  thanks!
[19:52] <chrisccoulson> hey, congrats didrocks \o/
[19:53] <didrocks> thanks chrisccoulson :)
[23:16] <chrisccoulson> hey didrocks - not sure if you're still awake or not. are you working on the g-c-c update still?
[23:17] <chrisccoulson> i'm going to push a change to fix bug 404219 shortly. if you're quite close to finishing, then you could probably incorporate the change in to your update
[23:42] <chrisccoulson> asac - did you figure out what happened with your gnome-session crash?
[23:42] <asac> chrisccoulson: nope. i think the complete hang was really rather linux ralted ... its working now since i have -4
[23:42] <asac> i instlaled the -dbg packages and didnt have a crash yet
[23:43] <chrisccoulson> asac - thanks. i've just pushed a change to gnome-session to stop it catching these crashes now anyway
[23:43] <chrisccoulson> it would be useful if apport caught them so people could report them
[23:46] <asac> thx. thats good.