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