[00:00]  * robert_ancell heads to lunch, be back in 30-60
[00:01] <ali1234> i can report a bug, but what do you want me to reproduce with? trusty, ubuntu-desktop in virtualbox (assuming i can?)
[00:03] <ochosi> ali1234: that would be great, i'm not in a good mindset anymore now to write something that makes sense..
[00:03] <ali1234> also... maybe we're only seeing it now because of my patches, which change the RetainPermanent stuff in lightdm-gtk-greeter, xfwm4, and xfdesktop
[00:03] <ochosi> think i'll head to bed and look at this again tomorrow
[00:03] <ochosi> makes more sense
[00:03] <ochosi> ali1234: i'm not using your patches atm
[00:03] <ali1234> ah yes, good point
[00:03] <ochosi> and i had that issue way before you started working on this
[00:04] <ochosi> s/that/these/
[00:04] <ali1234> i'll do some tests with clean isos in virtualbox
[00:04] <ochosi> so you're certainly not to blame ;)
[00:04] <ochosi> cool
[00:04] <ochosi> i'll check in again tomorrow
[00:04] <ochosi> night everyone!
[00:51] <ali1234> well, it didn't happen with trusty daily in virtualbox
[00:54] <robert_ancell> ali1234, oh really? I could reproduce it reliably in trusty yesterday
[00:54] <ali1234> i reproduced it with the guest session
[00:54] <robert_ancell> seb128 said that downgrading to 1.8 seemed to make the problem go away
[00:54] <robert_ancell> ali1234, but not lock screen?
[00:54] <ali1234> it's put a greeter on top of my user session :/
[00:55] <ali1234> i couldn't reproduce it by login, logout, login, lock
[00:55] <robert_ancell> that sounds bad!
[00:55] <ali1234> switched to virtualbox console and the display has gone completely mad
[00:56] <ali1234> i didn't install the guest drivers either
[00:56] <ali1234> lightdm just bombed out and sent me back to the login screen
[00:57] <ali1234> i'm not convinced this is the same issue. i'm going to try on real hardware
[01:29] <ali1234> actually now i think about it, what i saw in virtualbox sounds like what someone else described with trusty
[01:29] <ali1234> and from looking at it, it looks like two xservers are fighting for the same framebuffer
[01:30] <ali1234> so a theory: on saucy the second x server simply fails to load because the first one owns the framebuffer. on trusty it somehow gets past that and they fight...
[01:30] <ali1234> or perhaps the result is X server implementation specific
[01:34] <ali1234> ah... again, i can only reproduce with the guest session
[01:35] <ali1234> and the result is the same: intel x server fails to start due to permission error
[01:37] <ali1234> it seems like locking the screen on unity/trusty does not create a second X server instance. i only have Xorg.1.log and not Xorg.1.log.old
[01:38] <ali1234> robert_ancell: what package do you want me to report it against?
[01:38] <robert_ancell> ali1234, mark it against lightdm and I'll also mark it against xorg
[01:40] <ali1234> "the problem cannot be reported. this is not an official ubuntu package..."
[01:40] <ali1234> i just installed from the daily iso...
[01:41] <ali1234> on the console: cat: /etc/lightdm/lightdm.conf: No such file or directory
[01:45] <ali1234> i did touch /etc/lightdm/lightdm.conf and now the report is uploading....
[01:48] <ali1234> bug 1256150
[01:48] <ubot2> Launchpad bug 1256150 in lightdm (Ubuntu) "Xorg guest session fails to start if the user has logged out and logged in again" [Undecided,New] https://launchpad.net/bugs/1256150
[02:01] <robert_ancell> ali1234, thanks!
[02:02] <ali1234> "log out" has now stopped working completely
[02:03] <robert_ancell> !
[02:03] <robert_ancell> I have to go, but I will have a look next week at this
[02:03] <ali1234> i'm going to wipe this install for trusty/xubuntu now, the bug should still be easily reproducable there, and i need to test a bunch of things
[02:04] <ali1234> ah... log out just took 4 minutes for no reason...
[07:23] <pitti> Good morning
[07:25] <Mirv> hello
[07:32] <JackYu> morning
[08:06] <damianatorrpm> GM all :)
[08:07] <damianatorrpm> larsu: how are you :)
[08:32] <larsu> damianatorrpm: good morning. I'm good thanks. How are you?
[08:33] <seb128> good morning desktopers
[08:33] <larsu> damianatorrpm: I saw your emails. Do you get any other output on stdout?
[08:38] <damianatorrpm> larsu: Thanks. I'm fine too, it's Friday :-)
[08:39] <damianatorrpm> larsu: no other stdout output. I also started QtCreator from terminal to see for any more output, nada. I also tried qmlscene and run the main.qml
[08:39] <damianatorrpm> larsu: stii no difference.
[08:40] <damianatorrpm> *still
[08:43] <larsu> damianatorrpm: hm, I'm starting to run out of ideas :-/
[08:43] <damianatorrpm> larsu: Can I show you via teamviewer?
[08:45] <larsu> damianatorrpm: never used that. Do they have a linux version?
[08:46] <damianatorrpm> larsu: yes :) .deb for 64 and 32 bit Ubuntu as well as .rpm for suse and fedora http://www.teamviewer.com/en/download/linux.aspx
[08:46] <damianatorrpm> larsu: It's free of charge for personal use and works *always*
[08:46] <damianatorrpm> :)
[08:47] <larsu> and is not free software :P  (I'll install it, give me a sec)
[08:48] <damianatorrpm> larsu: really appreciated. Thanks
[09:02] <Laney> morning
[09:02] <larsu> hi Laney, how's it going?
[09:02] <Laney> pretty good, happy to have made it to friday ;-)
[09:02] <Laney> you?
[09:04] <larsu> same same :)
[09:07] <Laney> what's this dbus-daemon thing?
[09:09] <didrocks> Laney: ps4 on the way? ;)
[09:09] <Laney> delivered 10:04-11:04 :D
[09:10] <didrocks> ;)
[09:11] <Laney> didrocks: did you go out for a midnight launch? ;-)
[09:11] <didrocks> Laney: no, I don't plan to buy it before a year at least
[09:12] <Laney> oho
[09:12] <didrocks> I want games I'm interested in on the platform first ;)
[09:12] <didrocks> like watch dogs
[09:12] <Laney> fair enough
[09:20] <seb128> back
[09:20] <ogra_> front
[09:21] <seb128> Laney, ogra_, hey, happy friday ;-)
[09:21] <ogra_> same to you :)
[09:21] <Laney> hey seb128
[09:21] <seb128> Laney, how are you?
[09:23] <seb128> Laney, you made rb unhappy, no music today :-(
[09:23] <Laney> does banshee work? :-)
[09:24] <seb128> lol
[09:24] <Laney> (good thanks)
[09:24] <seb128> do I look like I use GTK2 apps still?
[09:24] <Laney> that is one sexy GTK2 app
[09:24] <seb128> you are so old fashion... ;-)
[09:25] <seb128> (but yeah, banshee works ;-)
[09:25] <seb128> (you did that on purpose to made people use banshee, admit it!)
[09:25] <Laney> :-)
[09:25] <Laney> anyway, I saw the bug, hopefully we can get a fix today
[09:26] <Laney> we should get that i-power fix out too
[09:26] <seb128> yeah
[09:26] <seb128> hum, glib migrated to trusty
[09:27] <seb128> (it hadn't yesterday due to libffi but infinity fixed that)
[09:27] <seb128> Laney, btw did you see my ping about GTK build?
[09:27] <Laney> yes
[09:27] <Laney> want to understand what changed there
[09:27] <seb128> ok
[09:27] <seb128> just making sure it didn't get lost in the backlog
[09:28] <seb128> it seems suboptimal if we have to make glib-dev depends on dbus
[09:28] <Laney> I don't see any changes in that code in glib
[09:29] <seb128> hum, maybe GTK started used something in glib that was not used before?
[09:29] <Laney> checking that
[09:32] <seb128> speaking about indicator-power
[09:32] <seb128> larsu, did you ever get desrt to +1 or -1 your action change?
[09:33] <Laney> ah, I think it's a new Ubuntu patch
[09:33] <Laney> gtk-object-tests-run-under-local-environment calls g_test_dbus_up()
[09:34] <seb128> oh
[09:35] <Laney> which uses dbus-daemon, but that's nothing new
[09:35] <Laney> so I'd probably add the BD
[09:35] <seb128> that seems wrong though
[09:35] <seb128> if glib provides an api
[09:35] <seb128> it should bring with it what is needed for the api to work
[09:36] <seb128> or handle the case where the depends are missing...
[09:38] <Laney> it would be quite heavy though http://162.213.35.4/search?weighted=1&q=g_test_dbus_up
[09:40] <seb128> the indicators use dbus-test-runner so b-d on it, and that brings in dbus
[09:40] <Laney> yeah
[09:40] <seb128> but yeah, options are
[09:40] <seb128> 1- add a dbus depends to libglib2.0-dev
[09:40] <seb128> 2- workaround it by adding a dbus b-d to packages using that api
[09:40] <Laney> dbus-x11
[09:41] <larsu> seb128: he said he needed to drink coffee first. And then he didn't ever look at it
[09:41] <larsu> I'll ping him again today
[09:41] <seb128> 3- split the glib files out in a new binary which has the depends
[09:41] <seb128> larsu, thanks
[09:41] <seb128> I don't like any of the 3 options :/
[09:42] <seb128> but I guess the b-d is the less annoying one
[09:42] <Laney> same
[09:42] <Laney> maybe glib could improve its message in that case, but it's quite obvious currently anyway
[09:42] <seb128> let's do a ppa upload with dbus-x11 b-d
[09:42] <Laney> k, ta
[09:43] <seb128> thanks for looking at it!
[09:43] <Laney> xnox: Do you have some time to help out on those libtimezonemap reviews?
[09:44] <Laney> I feel bad for not looking at them sooner, but I honestly have never looked at this code before
[09:44] <Laney> kind of got dumped in it there really
[09:44] <xnox> yeah. i should review them. they do look good.
[09:44] <Laney> he seems to have done 1 commit per change-ish
[09:44] <Laney> so I'll take some of them and cherry-pick them
[10:02] <Laney> omg bzr-gtk went away?
[10:03] <seb128> yes, in saucy
[10:04] <Laney> guess the fact that I only just noticed says something :P
[10:04] <seb128> it needed porting to the new version of something and nobody wanted to do the work iirc
[11:03] <seb128> desrt, wake up, I need you :p
[11:09] <seb128> desrt, n-m is having an issue similar to rhythmbox, http://paste.ubuntu.com/6493541/
[11:09] <seb128> desrt, I'm going to have a look at reverting this glib commit
[11:09] <seb128> Laney, ^ or do you want to do that?
[11:11] <Laney> seb128: go ahead, would be good to confirm it actually does fix things before uploading it though
[11:12] <seb128> Laney, right, I'm not going to upload glib without testing, no worry
[11:12] <seb128> I'm going to wait for desrt to be up, but I can as well start testing building/running it
[11:12] <Laney> seems unsafe anyway if we've discovered two applications in the first day
[11:12] <Laney> they might want to rethink it upstream
[11:12] <seb128> right
[12:15] <seb128> shrug
[12:15] <seb128> GTK build still not happy :/
[12:15] <seb128> https://launchpadlibrarian.net/157877308/buildlog_ubuntu-trusty-i386.gtk%2B3.0_3.10.5-0ubuntu1~build1.3_FAILEDTOBUILD.txt.gz
[12:15] <seb128>   /properties/GtkColorChooserDialog:
[12:15] <seb128> (/build/buildd/gtk+3.0-3.10.5/debian/build/shared/testsuite/gtk/.libs/lt-object:20493): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
[12:15] <seb128> FAIL
[12:16] <seb128> I guess it's looking in the system location, not the source
[12:16] <seb128> larsu, ^
[12:20] <seb128> brb, session restart with glib and the constructore change reverted
[12:26] <Laney> xnox: reviewed a few of the changes, left some for you
[12:27] <ali1234> seb128: so, you know this lightdm/guest session bug... apparently it went away when you downgraded lightdm to 1.8? but i can reproduce it in saucy, which uses 1.8.4
[12:27] <seb128> ali1234, hey, weird ... it's rock solid for me with 1.8.4
[12:28] <seb128> ali1234, it maybe is a timing issue and I just happen to be one side of the timing issue with 1.9 and on the other side with 1.8
[12:28] <ali1234> we reproduced it in saucy not with guest session, but with the screen lock dialog, which xubuntu opens on :1, causing an identical problem
[12:28] <ali1234> it's not a timing issue, lightdm actually tells Xorg to run on the wrong VT
[12:28] <seb128> ok
[12:28] <seb128> is that the same one?
[12:29] <ali1234> well, maybe, maybe not
[12:29] <ali1234> but it's reproducable the exact same way
[12:29] <ali1234> if you've logged out and logged in, and then ask lightdm to start a display on :1, it will attempt to start it on VT7, which is already used by :0
[12:29] <seb128> in trusty I get xorg hitting a "no screen found" error
[12:30] <ali1234> the result depends on driver. you get no screen found with intel
[12:30] <ali1234> with others, you get two xorgs on the same VT and they fight each other
[12:30] <seb128> right, I'm using intel
[12:30] <seb128> right
[12:30] <seb128> for me it's like a get a vt over my xorg
[12:30] <ali1234> but checking lightdm logs, it's explicitly telling Xorg to use the wrong VT
[12:30] <seb128> e.g my vt7 is blank, but I can move the cursor and see it change shape where there are windows from my session
[12:30] <seb128> ok, good
[12:30] <seb128> seems like a bug for robert_ancell to fix then
[12:31] <seb128> ali1234, thanks for figuring that out!
[12:31] <ali1234> alreday reported. he's the one who told me you said 1.8 fixes it
[12:31] <seb128> well, it does for me
[12:31] <ali1234> perhaps it handles guest and "lock" slightly different
[12:31] <seb128> could be
[12:31] <ali1234> and only one got fixed
[12:31] <seb128> what I do is
[12:31] <seb128> - log in
[12:31] <seb128> - log out
[12:31] <seb128> - log in
[12:31] <seb128> - start a guest from indicator-session
[12:32] <seb128> that works in saucy
[12:32] <seb128> but screws my session with 1.9
[12:32] <ali1234> i haven't tried that on saucy, what we do is same: log in, log out, log in, lock screen with light-locker (that tries to start :1 and does exactly the same thing in saucy and trusty)
[12:33] <ali1234> guest session also does it in trusty, but never tested that in saucy cos we didn't know that was also an issue at the time
[12:33] <seb128> ok
[12:35] <seb128> ali1234, yeah, I can confirm that in the log I sent to robert_ancell
[12:36] <seb128> DEBUG: Launching process 4073: /usr/bin/X -core :1 -auth /var/run/lightdm/root/:1 -nolisten tcp vt7 -novtswitch
[12:36] <seb128> well, let's see if resolving that issue fixes things for the different scenarios
[12:36] <ali1234> yeah. bug 1256150 btw
[12:36] <ubot2> Launchpad bug 1256150 in xorg (Ubuntu) "Xorg guest session fails to start if the user has logged out and logged in again" [High,Confirmed] https://launchpad.net/bugs/1256150
[12:38] <seb128> right, I saw it in my bug emails box this morning
[13:09] <larsu> seb128: seems related to my patch for https://bugzilla.gnome.org/show_bug.cgi?id=711715
[13:09] <ubot2> Gnome bug 711715 in general "gtk object tests: run under local environment" [Normal,New]
[13:09] <larsu> seb128: (sorry, I was out for lunch)
[13:10] <seb128> larsu, no worry, I tested the hack debian is doing
[13:10] <seb128> larsu, https://launchpadlibrarian.net/157881868/gtk%2B3.0_3.10.5-0ubuntu1~build1.3_3.10.5-0ubuntu1~build2.diff.gz
[13:11] <seb128> larsu, tested -> I'm testing rather (it's building)
[13:14] <larsu> seb128: ya that'll probably work. I'm waiting for desrt to tell me how to do it properly for the tests
[13:16] <seb128> larsu, I hope desrt has coffee before looking at IRC, seems there is a stack of questions queued for him today
[13:18] <larsu> seb128: he should move to a better time zone
[13:19] <seb128> we have the best tz and the best cities, no reason to not come ;-)
[13:20] <larsu> hehe :)
[13:22] <seb128> larsu, btw Cimi reviewed on overlay-scrollbar changes and just pinged me on #ubuntu-devel, I asked him to join here/on a channel where you are as well
[13:22] <seb128> larsu, seems like he picked another channel...
[13:48] <desrt> hello hackers!!
[13:48] <desrt> seb128: et tu, n-m?
[13:48] <seb128> desrt, hey, how are you?
[13:49] <desrt> okay
[13:49] <desrt> i got coffee beside me :)
[13:49] <seb128> desrt, should I revert the 2 commits from dan? just 1? just comment the g_error?
[13:49] <desrt> i'd do both
[13:49] <seb128> I did that
[13:49] <seb128> just wanted to check with you before uploading
[13:50] <seb128> though it refuses to build on amd64 in the ppa
[13:50] <desrt> sigh
[13:50] <seb128> FAIL: gwakeup
[13:50] <seb128> FAIL: gwakeup-fallback
[13:50] <popey> looks like we have the "hud-service eating my RAM" issue back again in 13.10.
[13:50] <seb128> but of course no details in the build log
[13:50] <seb128> popey, talk to pete-woods on #ubuntu-touch
[13:50] <desrt> seb128: that seems highly suspicious
[13:50] <popey> bug 1253593
[13:50] <ubot2> Launchpad bug 1253593 in hud (Ubuntu) "hud memory usage grows over time" [Undecided,Confirmed] https://launchpad.net/bugs/1253593
[13:50] <popey> ok
[13:50] <seb128> popey, wrong channel
[13:50] <desrt> seb128: considering your reverts are in libgobject
[13:50] <popey> this is on the desktop though ☻
[13:51] <seb128> popey, you want ted or pete, ted is off for thanksgiving
[13:51] <popey> not phone.
[13:51] <desrt> seb128: and the gwakeup test doesn't link against that
[13:51] <seb128> desrt, right, so maybe another reason/something with the ppa
[13:51] <seb128> desrt, https://launchpadlibrarian.net/157875681/glib2.0_2.39.1-0ubuntu1_2.39.1-0ubuntu2~build1.diff.gz
[13:51] <desrt> seb128: maybe a new kernel version?  wouldn't be the first time this testcase found a kernel bug...
[13:51] <seb128> desrt, can you sanity check? (ignore the "git" file in there)
[13:52] <desrt> +++static inline gboolean
[13:52] <seb128> desrt, well, it's basically reverting those 2 commits
[13:52] <desrt> you said SANITY? ;)
[13:52] <seb128> lol
[13:52] <seb128> desrt, yeah, not a lot to check, that are the 2 upstream commits
[13:52] <seb128> desrt, you saw the pastebin in the backlog (from nm)
[13:52] <seb128> ?
[13:53] <seb128> desrt, can you upstream that one as well?
[13:53] <desrt> no
[13:53] <desrt> got it
[13:53] <seb128> cool
[13:53] <desrt> the good news is that these projects were legit buggy/leaking
[13:53] <desrt> and now we find out about it
[13:54]  * desrt files a bug for the other danw
[14:01] <desrt> seb128: of course everyone in USA is on their 5-day eatfest/buyfest
[14:01] <seb128> desrt, oh, right
[14:01] <desrt> that includes both danw and dcbw, i guess
[14:01] <seb128> desrt, well, anyway with the revert that can wait
[14:01] <desrt> kinda curious about this gwakeup issue
[14:03] <desrt> the irony builds
[14:03] <desrt> the last person to touch this file.... you guessed it.... danw
[14:04] <desrt> (in fairness, though, dcbw wrote the offending code)
[14:04] <didrocks> seems like a running joke
[14:04] <didrocks> ;)
[14:04] <desrt> didrocks: the joke started last night
[14:04] <didrocks> desrt: yeah, seb128 told me :)
[14:04] <didrocks> with your bug report?
[14:04] <desrt> with seb seeing rhythmbox crashes
[14:05] <didrocks> yep
[14:05] <didrocks> and who wrote the libsoup code
[14:05] <didrocks> :)
[14:13] <seb128> larsu, gtk 3.10 built in the ppa \o/
[14:14] <larsu> seb128: yay!
[14:14] <seb128> everyone: ^ new gtk in the desktop team ppa if you want to give it a try
[14:16] <Laney> exciting!
[14:17] <seb128> I'm going to follow up on the list with that and the list of known issue
[14:17] <seb128> glib with the gobject constructor restriction reverted uploaded to trusty as well
[14:17] <seb128> would be nice if people could grab it/test in half an hour when it's built
[14:18] <seb128> didrocks: ^ that should fix nm on the touch image
[14:24] <seb128> bbiab
[14:26] <desrt> bumpy ride
[14:26] <desrt> i bet seb's appetite for a taste of gtk 3.12 has subsided
[14:27] <larsu> desrt: morning!
[14:27] <desrt> larsu: hi :)
[14:27] <desrt> you finally put o-s to bed?
[14:27] <Laney> ah, such fun
[14:27] <larsu> desrt: let me know when you had coffee. I have two things for ya
[14:27] <desrt> larsu: i'm coffeed
[14:27] <larsu> desrt: no...
[14:27] <larsu> I tried hard!
[14:27] <larsu> desrt: https://code.launchpad.net/~larsu/indicator-power/use-gsettings-actions/+merge/197066
[14:28] <desrt> oh.  that.
[14:28] <desrt> i forgot to actually comment on that
[14:28] <desrt> i see lots of red.  oddly enough, that means that i'm in a good mood.
[14:28] <larsu> is it okay?
[14:29] <desrt> my mind is blown by how bad this code was before
[14:29] <desrt> what in the hell....
[14:30] <larsu> desrt: ya, we found it because of the non-stateful actions that had their state set later on
[14:30] <larsu> thanks for putting that check into gio ;)
[14:30] <desrt> which was only possible if using g_object_set()...
[14:30] <desrt> ...which you were ;)
[14:30] <larsu> I?
[14:30] <desrt> the collective 'you'
[14:30] <desrt> who wrote this?
[14:30]  * larsu is innocent!
[14:30] <larsu> charels
[14:31]  * desrt shakes fist
[14:31] <desrt> charles_: if you're using my APIs and you ever find yourself having to do something so ugly again, please talk to me about it :)
[14:31] <larsu> well, binding the settings isn't that ugly
[14:31] <desrt> the gvalue shuffling...
[14:32] <larsu> that is, definitely
[14:32] <desrt> i'm actually trying to understand what the old code is doing.  don't see it yet.
[14:32] <desrt> okay.  got it.
[14:32] <desrt> the binding is directly manipulating the state of the action from the outside
[14:32] <larsu> yes
[14:32] <desrt> you're right... it's not actually _that_ bad
[14:33] <larsu> it's very reasonable if you don't know about GSettingsAction
[14:33] <desrt> and about GAction...
[14:33] <larsu> ha, yeah :(
[14:33] <desrt> the API very much has a 'state comes from within' feel about it
[14:34] <larsu> well, simpleaction goes against that
[14:34] <larsu> and if you're used to using that....
[14:34] <desrt> ya... strictly speaking, if implementing a simpleaction (as this code is doing) then it's legit to say that the binding is part of the implementation itself
[14:34] <desrt> as it is here...
[14:34]  * desrt always perceives bindings as something outside of an object
[14:35] <larsu> I agree, it should have triggered the smelly code detector
[14:35] <desrt> my complaint, specifically: GAction::state is readonly and the binding is modifying the state of a GACtion
[14:35] <desrt> but... it's also a GSimpleAction, so hey...
[14:35] <larsu> yeah
[14:35] <larsu> thanks for having a second look
[14:35] <desrt> so why do you keep the action around?
[14:36] <larsu> I don't know
[14:36] <larsu> it's charles' code, I didn't want to mess too much with it
[14:36] <desrt> there's almost nothing that you can meaningfully do with a gsettingsaction beyond adding it to the map
[14:36] <larsu> but he's on tg holiday
[14:37] <desrt> commented
[14:37] <desrt> in summary: i want to see more red :)
[14:37] <larsu> there is more code to be cut, but please let's fix the bug first
[14:38] <larsu> I know what you'll say now.
[14:38] <larsu> "You'll never get around to removing that anyway"
[14:38] <desrt> also: it will take you less than 5 minutes to do what i asked
[14:38] <desrt> and most of those 5 minutes will consist of tapping your 'd' key in a very satisfying way
[14:39] <larsu> well, there are other actions kept around as well
[14:39] <larsu> anyway, I'll have a look of you do me a second favor and have a look at how I install the schema in https://bugzilla.gnome.org/show_bug.cgi?id=711715
[14:39] <ubot2> Gnome bug 711715 in general "gtk object tests: run under local environment" [Normal,New]
[14:39] <larsu> it's causing problems on the builders
[14:40] <larsu> but I didn't want to fix it because you probably have a very specific opinion on that
[14:40]  * desrt has no idea what he's looking at
[14:40]  * desrt becomes curious
[14:40] <desrt> i guess this is some fallout from your gtk 3.10 work?
[14:40] <larsu> desrt: yes. Running the tests in the session didn't work
[14:41] <larsu> because schemas were missing if you didn't have 3.10 installed
[14:41] <desrt> ahhhh
[14:41] <desrt> i'm very surprised that gnome-continuous didn't pick that up
[14:41] <larsu> same problem on the builders
[14:41] <larsu> because its using installed tests
[14:41] <larsu> it's
[14:41] <desrt> right.
[14:41] <desrt> probably also because it doesn't do clean rebuilds
[14:42] <desrt> so even if it did 'make check' it would have a system image there
[14:42] <seb128> desrt, glib built on amd64 on the buildders, I'm going to do another ppa upload with VERBOSE=1 just to see
[14:42] <desrt> seb128: blame the kernel!!
[14:42] <larsu> seb128 is back!
[14:42] <seb128> larsu, yeah ;-)
[14:42] <larsu> seb128: good news, giving only GtkPaned a background fixes the theme issues
[14:42] <Laney> damn that colonel
[14:42] <larsu> but I don't know if there are more
[14:42] <larsu> so testing is in order
[14:42] <seb128> larsu, \o/
[14:43] <desrt> $(GLIB_COMPILE_SCHEMAS) $(top_srcdir)/gtk --targetdir=$(builddir)
[14:43] <desrt> oh man...
[14:43] <seb128> Laney, please test https://launchpad.net/ubuntu/+source/glib2.0/2.39.1-0ubuntu2/+build/5281151
[14:43] <seb128> Laney, thanks ;-)
[14:43] <desrt> larsu: strictly speaking, this is no longer valid....
[14:43]  * seb128 doesn't want to be the one who screwed glib on a friday evening
[14:43] <Laney> seb128: anything in particular?
[14:43] <larsu> desrt: why not?
[14:43] <larsu> what's you issue with it?
[14:43] <larsu> *your
[14:43] <desrt> larsu: gsettings now assumes the xml will be in the same directory as gschemas.compiled, so this will break out-of-tree
[14:43] <seb128> Laney, just make sure rhythmbox & sessions are working on amd64 (I tested on i386)
[14:44] <Laney> ok, sec
[14:44] <desrt> but it only breaks if you call _get_description() or _get_summary() in the testcase
[14:44] <desrt> which i assume you're not
[14:44] <larsu> desrt: so ... --target-dir is now useless?
[14:44] <seb128> Laney, thanks
[14:44] <desrt> larsu: i was going to remove it... that's why i mention it
[14:44] <desrt> i stopped using it from the glib testcases
[14:44] <desrt> maybe i'll keep it around if others use it, though
[14:45] <larsu> no, please remove it
[14:45] <desrt> larsu: as long as you're not looking at summary/description, you're in the clear...
[14:45] <larsu> desrt: I'm not, but this line seems to be causing issues anyway
[14:46] <larsu> seb128 is now compiling with this https://launchpadlibrarian.net/157881868/gtk%2B3.0_3.10.5-0ubuntu1~build1.3_3.10.5-0ubuntu1~build2.diff.gz
[14:46] <desrt> larsu: fwiw, i'd also advise not to give a dir like you did there but rather specify the individual schema files
[14:47] <desrt> although maybe it makes sense this way if people add other tests that use schemas
[14:47] <larsu> this is for the generic test
[14:47] <desrt> but in general, having wildcards in makefile depends is a _big_ no-no
[14:47] <larsu> I agree
[14:47] <desrt> i think the gmake manual has a section about why not to do that :p
[14:47] <larsu> but I thought people won't think about addind their new schemas to this test
[14:48] <desrt> larsu: they will when the test stops working?
[14:48] <larsu> but then, they probably will after running `make check`
[14:48] <larsu> ya
[14:48] <desrt> there is some --schema-file= flag that you can use
[14:48] <desrt> you can probably use $(addprefix,--schema-file=,$(files)) or something to generate what you need
[14:49] <larsu> okay, thanks
[14:49] <larsu> desrt: any idea why the test still fails?
[14:49] <desrt> let me apply it
[14:49] <larsu> https://launchpadlibrarian.net/157877308/buildlog_ubuntu-trusty-i386.gtk%2B3.0_3.10.5-0ubuntu1~build1.3_FAILEDTOBUILD.txt.gz
[14:49] <desrt> i still don't fully understand what's going on here
[14:50] <larsu> desrt: I'm installing the things and then set GSETTINGS_SCHEMA_DIR from inside the test (with g_test_build_filename)
[14:54] <mhr3> is trusty screwed?
[14:54] <mhr3> https://code.launchpad.net/~ubuntu-unity/+archive/daily-build-next/+recipebuild/596169
[14:54] <mhr3> seb128, ^?
[14:56] <seb128> mhr3, ask on #ubuntu-devel
[14:56] <seb128> seems like a launchpad/soyuz issue
[14:56] <seb128> maybe those builders are having a too old apt/dpkg or something
[14:56] <mhr3> will do, thx
[14:56] <seb128> yw
[14:58] <ali1234> so i did a make install of lightdm, and it totally broke the system. what's the fastest way to get test builds installed?
[15:00] <seb128> ali1234, build a deb, install it
[15:00] <ali1234> lame. that takes ages :(
[15:00] <seb128> ali1234, you can also "debuild" once, so it's built with the right configure options, etc
[15:01] <seb128> and hack; make; sudo cp binary
[15:01] <seb128> if there is one specific binary you hack on
[15:01] <seb128> like the main lightdm binary
[15:01] <ali1234> that sounds like a plan, thanks
[15:01] <seb128> ali1234, yw
[15:08] <desrt> larsu: so it's the installed case that's failing?
[15:08] <larsu> desrt: no
[15:09] <larsu> I don't think the gtk debian package does installed tests
[15:09] <desrt> so "make check" is the fail
[15:11] <seb128> yes
[15:11] <larsu> make check on an out-of-tree build
[15:11] <larsu> seb128: right?^^
[15:11] <seb128> yes
[15:11] <larsu> seb128 is very efficient
[15:12] <Laney> would be nice to add installed tests too ;-)
[15:13] <larsu> Laney: yup, but let's make it build without hacks, first ;)
[15:13]  * Laney fast forwards 60 years to himself as a skeleton in a library covered in dust writing a changelog entry "Enable installed tests"
[15:14] <Laney> :P
[15:14] <larsu> haha
[15:15]  * larsu would definitely do different things if he were a skeleton in a library
[15:17] <desrt> larsu: so you have an interesting problem here
[15:17] <larsu> no brain?
[15:17] <desrt> no...
[15:17] <desrt> it's a bit of an annoying catch 22
[15:18] <desrt> you can't use g_test_build_filename() until after you call g_test_init()
[15:18] <desrt> but in these tests, it's gtk_test_init()
[15:18] <larsu> bah
[15:18] <desrt> which calls gtk_init()
[15:18] <desrt> which presumably initialises the schemas sources
[15:18] <larsu> right
[15:18] <desrt> so by the time you set GSETTINGS_SCHEMA_DIR it's too late
[15:18] <seb128> desrt, larsu: as much as I like you figuring that out, can we get the indicator-power fix approved so it lands before the w.e?
[15:19] <seb128> then we can go back to fixing stuff that are not hitting users
[15:19] <larsu> seb128: good point. Let me fix it up for desrt
[15:19] <seb128> larsu, thanks
[15:19] <desrt> larsu: i'll see if i can figure out a way around this.  i have an idea.
[15:19]  * larsu already has it open, was just distracted
[15:19] <larsu> desrt: is this the problem why the build fails?
[15:20] <desrt> the _build_ fails?  or make check?
[15:20] <larsu> make check
[15:20] <desrt> maybe
[15:20] <desrt> i'm checking my assumptions and finding them to be false, in fact
[15:20] <desrt> it looks like gtk_init() doesn't bring up the schemas sources
[15:21] <larsu> seb128: in the meantime, do you have time to test/approve https://code.launchpad.net/~larsu/overlay-scrollbar/fix-for-3.10/+merge/196920
[15:21] <seb128> larsu, sure
[15:22]  * seb128 discovers that gnome-keyring dialogs also stopped wrapping with the new GTK
[15:22] <larsu> seb128: I have that fix open somewhere as well. Crazy Friday.
[15:23] <seb128> larsu, crazy week you can say, it feels like every day has been like that
[15:23] <seb128> soon the w.e though!
[15:23] <larsu> desrt: now I remember. Charles kept the actions around to disconnect from the notify signal
[15:24] <desrt> i'd rewrite that using g_settings_bind()
[15:24] <larsu> hm?
[15:24] <desrt> i assume you're using the notify to update some sort of [something] when the value changes, right?
[15:25] <larsu> yes, but bind() binds a property, no?
[15:25] <desrt> (which means, btw.... your patch may be introducing a bug... since the first notify:: will no longer come as it would have before your patch)
[15:25] <larsu> desrt: he's calling the same function after anyway
[15:25]  * larsu checked for that
[15:25] <desrt> anyway... the point is maybe a bit theoretical, but it's a good point:
[15:25] <larsu> isn't connecting to changed::show-time the right approach?
[15:26] <desrt> whatever that's tied to is interested in what the gsettings say
[15:26] <desrt> the fact that the gsettings is changed via a GAction tied into some UI somewhere is a totally separate point
[15:26] <desrt> so to have these two things tied together is inappropriate coupling
[15:26] <larsu> yes, I agree. Still, I'd connect it to 'changed' instead of using bind()
[15:26] <desrt> ie: don't connect to the notify:: signal on the action... connect to the changed signal on GSettings
[15:27] <desrt> ya.  that's totally fine too.
[15:27] <larsu> I think we talked about different things but came to the same conclusion :)
[15:27] <larsu> thanks
[15:27] <desrt> ya
[15:27] <desrt> i just had bind() in my head because i always try to do that first
[15:27] <larsu> right
[15:28] <seb128> desrt, https://launchpadlibrarian.net/157891618/buildlog_ubuntu-trusty-amd64.glib2.0_2.39.1-0ubuntu3~build1_FAILEDTOBUILD.txt.gz
[15:28] <seb128> desrt, "GLib:ERROR:/build/buildd/glib2.0-2.39.1/./glib/tests/gwakeuptest.c:109:context_clear: assertion failed: (ctx->pending_tokens == NULL)"
[15:28] <desrt> larsu: i don't understand your problem with this 'make check' failure
[15:28] <seb128> desrt, just mentioning it, don't bother about it today, it only happens on the ppa builders for some reason
[15:28] <desrt> i mean... i found the bug, but i don't understand why you didn't find it
[15:29] <desrt> larsu: specifically... you set GSETTINGS_SCHEMA_DIR from the defaultvalue test... and it worked
[15:29] <desrt> you simply did not do the same from the object test...
[15:29] <desrt> do that, and it works too
[15:30] <larsu> desrt: the object test failed?
[15:30]  * larsu looks
[15:30]  * larsu slaps forehead
[15:30] <larsu> desrt: sorry :-/
[15:30] <desrt> larsu: happy to help :)
[15:31] <larsu> thanks a lot. I should maybe stop doing 10 things at once
[15:32] <seb128> larsu, sorry about the crazy day/week, I hope it's better next week
[15:32] <larsu> seb128: no worries :(
[15:32] <seb128> desrt, saw the build link? (just mentioning it so I'm sure it doesn't get lost in the middle of crossed discussions)
[15:32] <larsu> s/:(/:)/ of course
[15:33] <seb128> larsu, speaking of doing 10 things at once, scrollbars work with gtk2 3.8.7 and 3.10.5
[15:33] <seb128> larsu, I can't change the status on that project though, so I comment approve it
[15:33] <larsu> seb128: I love how small the patch has become after cimi reviewed the patch
[15:33] <seb128> larsu, ;-)
[15:34] <seb128> larsu, so you spent 10 days to write 3 lines of code?
[15:34] <larsu> seb128: I can't approve either
[15:34]  * seb128 likes that joke
[15:34] <seb128> larsu, sorry, it has been a long week ;-)
[15:34] <Laney> aww
[15:35] <seb128> Laney, feel unwell? your ps4 arrived? :p
[15:36] <larsu> :)
[15:36] <Laney> feeling hurt by your mean joke!
[15:36] <seb128> oh
[15:36] <seb128> lol
[15:37] <seb128> it's friday, I need to do some trolling
[15:37] <didrocks> seb128: \o/
[15:37] <seb128> didrocks, glib works?
[15:37] <didrocks> seb128: no, just read your message
[15:37] <Laney> go troll on your menu gnome bugs ;-)
[15:37] <seb128> didrocks, or just liking trolls? ;-)
[15:37] <didrocks> and back from running :p
[15:37] <seb128> didrocks, nice!
[15:37] <didrocks> trolls \o/ is just a coincidence
[15:38] <seb128> Laney, that's a good point, I spent monday trolling this week
[15:38] <didrocks> can't type, need to do one letter after another
[15:38] <seb128> didrocks, freezing out there?
[15:38]  * Laney gets back to adding the nicer looking axes to the battery graph
[15:38] <seb128> didrocks, or is it raining?
[15:38] <seb128> Laney, \o/
[15:38] <didrocks> seb128: just freezing
[15:38] <didrocks> so my hands can't type
[15:38] <Laney> still don't look that good though
[15:38] <didrocks> it's like if I typed in slow motion :p
[15:38] <seb128> didrocks, hot shower time:
[15:38] <seb128> !
[15:39] <didrocks> I guess so ;)
[15:39] <Laney> I look with envy at the gnome-system-monitor graphs
[15:39] <desrt> larsu: we're good?
[15:40] <seb128> Laney, those which make the system monitor uses 25% of the cpu displaying you what is using cpu? :-)
[15:40] <larsu> desrt: yes, thanks a lot. If you want another look, I just pushed the fix we talked about: https://code.launchpad.net/~larsu/indicator-power/use-gsettings-actions/+merge/197066
[15:40] <Laney> haha, they seem alright here (but then again I have a nice i7)
[15:40] <Laney> even so they look damn sexy while doing it :P
[15:40] <seb128> (it's better nowadays)
[15:40] <larsu> desrt: more red \o/
[15:41] <ali1234> back in the day it was more like 75%
[15:44]  * desrt resists urge to complain about connect_swapped
[15:45] <larsu> desrt: I hate doing unrelated changes in one commit
[15:45] <desrt> one small issue
[15:45] <larsu> seb128: o-s is approved by cimi. Does it have auto landing?
[15:46] <desrt> you introduced a race
[15:46] <seb128> larsu, looks to the bzr log it seems so
[15:47] <desrt> Laney: here's the other one: https://bugzilla.gnome.org/show_bug.cgi?id=719555
[15:48] <ubot2> Gnome bug 719555 in general "nm-device constructor() wrongly finalizes object during construction" [Critical,Unconfirmed]
[15:48] <larsu> desrt: it's always about races with you!
[15:48] <larsu> desrt: which one?
[15:48]  * larsu doesn't see it
[15:48] <desrt> larsu: if a signal comes in while you unref the gsettings object, the signal will still be delivered after the unref because the worker thread will have picked up an extra ref
[15:48] <seb128> larsu, just put a sleep(1) in there, that ought to fix a race if there is one
[15:48] <larsu> lol
[15:48] <seb128> ;-)
[15:49] <Laney> desrt: ta, subscribed
[15:49] <desrt> larsu: ie: you cannot assume that just because you unref() your [presumed only] copy of the gsettings object, it will stop firing signals
[15:49] <larsu> desrt: how did I introduce that? (And why is it a problem?)
[15:49] <desrt> larsu: you don't disconnect from the change signal on the gsettings...
[15:50] <larsu> desrt: what? This call was there before, I simply changed it
[15:50] <larsu> I assumed it did the unconnect as well
[15:50] <desrt> i see addition of a connect, but no addition of a disconnect
[15:50] <larsu> I don't see an addition of a connect
[15:51] <larsu> and I was right it's disconnected from
[15:51] <larsu> charles_ didn't dissapoint!
[15:51] <desrt> oooh
[15:51] <desrt> - g_signal_connect_swapped (p->settings, "changed::" SETTINGS_ICON_POLICY_S,
[15:51] <desrt> 121	- G_CALLBACK(rebuild_header_now), self);
[15:51] <desrt> 122	+ g_signal_connect_swapped (p->settings, "changed", G_CALLBACK(rebuild_header_now), self);
[15:51] <desrt> you just expanded the scope
[15:51] <larsu> yep
[15:51] <desrt> and it already had a disconnect?
[15:52] <larsu> yes
[15:52] <desrt> sorry.  misread the patch.
[15:52] <larsu> just checked
[15:52] <larsu> no worries. Can you approve it please?
[15:52] <larsu> at the top, I mean
[15:52] <desrt> already did
[15:53] <larsu> thanks!
[15:53] <desrt> seb128: larsu didn't need sleep()
[15:53] <desrt> he fixes his race conditions using IRC
[15:53] <larsu> I fix race conditions by explaining them away
[15:53] <larsu> much better than using sleep()
[15:54] <desrt> this patch now looks very nice :)
[15:54] <desrt> +10/-70
[15:54] <larsu> I agree. This review thing kinda works
[15:54] <seb128> desrt, larsu: thanks ;-)
[15:54] <desrt> normally i like lots of green
[15:55] <desrt> (coverage reports, test output, jhbuild results, damned lies)
[15:55] <desrt> but today i like red
[15:55] <larsu> desrt: the original bug could have been solved with +2/-0
[15:55] <larsu> wait, +2/-2
[15:55] <desrt> adding an initial state of the correct type?
[15:55] <larsu> yep
[15:55] <desrt> thanks for not doing that :)
[15:55] <larsu> twice, for the two actions
[15:55] <larsu> ya..
[15:55] <larsu> I knew you wouldn't let _that_ slide :P
[15:56]  * larsu wouldn't have shown it to you, probably
[15:56] <seb128> desrt, I'm asking again in case, saw the glib build log a bit earlier?
[15:56] <seb128> too much going on today :p
[15:56] <desrt> i think i missed that one :p
[15:56] <larsu> desrt: speaking of which, did you see the glib build log that seb128 pointed you to earlier?
[15:56] <seb128> desrt, https://launchpadlibrarian.net/157891618/buildlog_ubuntu-trusty-amd64.glib2.0_2.39.1-0ubuntu3~build1_FAILEDTOBUILD.txt.gz
[15:56] <seb128>  desrt, "GLib:ERROR:/build/buildd/glib2.0-2.39.1/./glib/tests/gwakeuptest.c:109:context_clear: assertion failed: (ctx->pending_tokens == NULL)"
[15:56] <desrt> oh
[15:56] <desrt> you said not to bother looking at that one :p
[15:57] <seb128> desrt, that's only happening for ppas, not on the archive builder (or it's not constant and ppas got unlucky)
[15:57] <desrt> seb128: there was a kernel bug at one point that was causing this
[15:57] <seb128> desrt, right, I just wanted to make sure you saw it
[15:57] <desrt> maybe the ppa builders still have that old kernel?
[15:57] <seb128> could be
[15:57] <seb128> I've the feeling we had the same conversation like a year ago
[15:57] <Laney> you can see the kernel version at the top
[15:57] <Laney> looks kinda old
[15:58] <seb128> that's a recurring topic :p
[15:58] <desrt> 2.6?  WHAT YEAR IS IT?!?
[15:58] <desrt> january 2008.  christ.
[15:59] <Laney> they're probably running hardy or something
[15:59] <seb128> lol
[15:59] <desrt> ya.... i hope you don't mind if i don't look further into this one :p
[15:59] <Laney> Buildd toolchain package versions: launchpad-buildd_119~0.IS.08.04 python-lpbuildd_119~0.IS.08.04 bzr-builder_0.7.2+bzr156-0ubuntu1~1.IS.8.04 bzr_2.4.0-0ubuntu2~11.IS.8.04.
[15:59] <Laney> yeah ...
[15:59] <seb128> desrt, ;-)
[15:59] <Laney> see those version numbers encoded there
[15:59] <desrt> pretty sure this was before the kernel bug got fixed
[15:59] <desrt> although...
[15:59] <desrt> that kernel may be old enough that it lacks eventfd
[15:59] <seb128> desrt, at least I can discard that as being an issue now
[16:00] <desrt> in which case this could be a legit bug with our pipe fallback
[16:01] <desrt> nope.  that kernel had eventfd.
[16:01] <desrt> oh.  curious.
[16:02] <desrt> we create the eventfd with EFD_CLOEXEC | EFD_NONBLOCK
[16:02] <desrt> which didn't exist until 2.6.27
[16:02] <desrt> failing that, we assume eventfd is not supported and fallback to pipes
[16:02] <xclaesse> A regression in 13.10 that's getting on my nerves is that every time I suspend when the laptop is docked, if I resume when undocked the screen stay black and the only thing I can do is long-press the shutdown button
[16:02] <desrt> so it could be that we're seeing a failure of the pipe fallback here (and we don't see it on newer kernels because that codepath doesn't get hit)
[16:03] <desrt> this would impact non-linux systems too, so it may be worth looking into
[16:03] <desrt> the weird thing though, is that we have a separate testcase to exercise this fallback, and it doesn't seem to be failing....
[16:07] <desrt> ...but even in the fallback, we use pipe2()... which is also unsupported on that kernel version...
[16:10] <larsu> seb128: GtkInfoBar. This is a hack though. https://code.launchpad.net/~larsu/ubuntu-themes/dont-set-all-bgs/+merge/197234
[16:10] <larsu> but it's a better hack than the one we had before
[16:10] <larsu> ochosi: ^^
[16:11] <larsu> and like I said, it might be breaking other stuff as well
[16:11] <seb128> larsu, looks fine to me, can you nudge Cimi about it?
[16:11] <seb128> I don't know those css stuff enough to approve it
[16:11] <larsu> he doesn't seem to either. I'm mostly looking for people to try it out
[16:12] <seb128> ok, I can do that
[16:12] <ochosi> larsu: thanks, will take a look at that
[16:13] <larsu> ochosi: it's not the right fix and you'll still need a patch, but at least it's not as intrusive
[16:13] <desrt> seb128: the fallback fallback case is running well here.  i blame the old kernel.
[16:13] <seb128> larsu, seems to work for me (at least for infobars), I'm going to keep running it and watching for glitches
[16:13] <desrt> and i don't really feel like reproducing my thinking from a year ago
[16:13] <seb128> desrt, ok, great, don't bother more about it then
[16:13] <seb128> desrt, thanks for checking
[16:13] <larsu> ochosi: and I'd appreciate some more testing. It might be that it still breaks some stuff, I've only been running it for half a day
[16:14] <seb128> desrt, yeah, I forgot we had that discussion before, I wouldn't have pinged you otherwise
[16:15] <ochosi> larsu: i'll see what i can do!
[16:15] <ochosi> larsu: i can't but wonder why this problem can't be tackled in the overlay-scrollbars directly so themes wouldn't have to jump through extra hoops
[16:17] <seb128> ok, dropping offline for another 15 minutes, brb
[16:17] <larsu> ochosi: ya, we tried. overlay-scrollbars installs a window filter function which (I think) forces the parent window to become native
[16:17] <larsu> which breaks bg rendering
[16:17] <larsu> it would need a refactor of o-s to make this work properly
[16:18] <larsu> and since we don't know if or how long we'll keep them, we don't want to spend too much time on it right now
[16:18] <ochosi> maybe gtk will get something like that natively at some point...
[16:18] <larsu> I highly doubt it
[16:18] <ochosi> yeah, i understand, the focus is elsewhere at the moment
[16:27] <Laney> glib autopkgtest failed on i386
[16:27] <Laney> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/21/ARCH=i386,label=adt/consoleFull
[16:28] <Laney> I can't find the failure
[16:28] <Laney> too much output
[16:28] <Laney> ah got it
[16:28] <Laney> no, not got it
[16:29] <Laney> yes, yes I have
[16:29] <Laney> GLib:ERROR:/build/buildd/glib2.0-2.39.1/./tests/testglib.c:590:timer_tests: assertion failed (elapsed <= g_timer_elapsed (timer, NULL)): (5e-06 <= 5e-06) Test glib/testglib.test failed: Child process killed by signal 6
[16:33] <desrt> cute....
[16:33] <desrt> i love floating point
[16:37] <seb128> xclaesse, I've that, but it's only visual, e.g if I type my password I'm back to my desktop
[16:38] <xclaesse> seb128, hm, didn't try typing the password
[16:38] <seb128> xclaesse, you should ;-)
[16:38] <seb128> but agreed it's a confusing/annoying be
[16:38] <seb128> bug
[16:38] <xclaesse> I tried ctr-alt-f1 then ctr-alt-delete to reboot but it doesn't work
[16:39] <seb128> weird, maybe it's another issue then
[16:39] <seb128> going to a vt works for me
[16:40] <seb128> do you get any apport report about kernel oops or video gpu error?
[16:40] <xclaesse> I'll let you know if typing the pwd works next time it happens
[16:40] <xclaesse> seb128, should they appear in /var/crash? nothing related to that there
[16:40] <seb128> righ
[16:41] <seb128> right
[16:41] <seb128> you can also check dmesg/syslog/Xorg.0.log.old I guess
[16:41] <seb128> but try first if typing your password works
[16:41] <seb128> in which case that's the same issue I'm seeing here
[16:41] <seb128> it's a bit weird though, gnome-screensaver didn't change for ages
[16:41] <seb128> and I didn't remember it doing that before
[16:42] <seb128> could be a compiz/unity issue of course...
[16:42] <seb128> bregma, ^ do you know?
[16:42] <xclaesse> seb128, I don't know if it's the same issue, but a collegue has the same problem on F20
[16:43] <xclaesse> same symptoms on the same hw
[16:43] <seb128> weird
[16:43] <seb128> maybe a video driver issue...
[16:43] <xclaesse> it's even worse on f20 because it does that when resuming on the dock
[16:43] <xclaesse> here it fails only when resuming outside of the dock
[16:44] <seb128> your description sounds like my issue
[16:44] <seb128> I'm just surprised that going to a vt didn't work
[16:44] <xclaesse> dunno if f20 has the same kernel/intel drv than 13.10
[16:45] <ochosi> larsu: hm, i applied that patch to our xubuntu theme, but it seems i still get black areas in gedit's tab-bar. what other fixes are you expecting?
[16:46] <larsu> ochosi: do you have the new overlay-scrollbars?
[16:46] <ochosi> larsu: hm, no, i'm still on saucy here
[16:46] <larsu> https://code.launchpad.net/~larsu/overlay-scrollbar/fix-for-3.10
[16:46] <larsu> ochosi: I didn't test that, sorry
[16:47] <ochosi> larsu: i assume this isn't packaged anywhere?
[16:47] <larsu> ochosi: no, but it should be, soon
[16:48] <ochosi> ok, would be nice if there could be some update for saucy too (or at least a PPA)
[16:49] <xclaesse> seb128, just tested, typing pwd doesn't work
[16:49] <seb128> xclaesse, :-(
[16:50] <seb128> xclaesse, can you ssh to the machine when that happens? or is it down/locked/frozen?
[16:50] <xclaesse> sshing it is what I'm trying now, need to find another machine :p
[16:51]  * xclaesse is alone at office atm
[16:51] <seb128> cyphermox, hey, can we get indicator-power and overlay-scrollbars landing in trusty?
[16:52] <cyphermox> seb128: sure
[16:52] <seb128> indicator-power is needed to fix an issue with the new glib (which is already in trusty) (changing the preferences doesn't work with it)
[16:52] <cyphermox> indicator-power is also used by touch though, so we need to take the time to test it
[16:52] <seb128> the scrollbar is to prepare gtk 3.10
[16:52] <Laney> oh dear
[16:52] <Laney> just spilt a bit of tea inside my desktop
[16:52] <cyphermox> oh
[16:52] <seb128> Laney, turn it off and clean I guess
[16:53] <xclaesse> "please insert a bootable floppy" --> seriously, latest lenovo laptop's bios are still asking for floppy when the disk is not bootable oO
[16:53] <Laney> yeah, checking if any actually went inside
[16:54] <ochosi> larsu: one more question, i thought 14.04 will come with gtk3.8 not 3.10?
[16:54] <larsu> ochosi: looks like we're getting 3.10
[16:55] <ochosi> oh
[16:55] <ochosi> i wasn't aware of that
[16:56] <larsu> you don't sound very happy about those news ...
[17:01] <desrt> ...maybe 3.12 :)
[17:01]  * desrt coughs
[17:02] <seb128> desrt, yeah, let's see about that
[17:02] <seb128> desrt, I'm sure larsu is looking forward spending another 10 days fixing some issues in unity due to a GTK update ;-)
[17:02] <desrt> seb128: after the bumpy ride we've been having with glib and gtk 3.10 i'm surprised you still want to try 3.12 gtk at all :)
[17:03] <desrt> but i guess it is work that we'd have to do anyway
[17:03] <seb128> desrt, I should have written "rrrrrrrrrrrrrrrrright, let's see about that"
[17:03] <Laney> I always knew seb128 was a crack pu$ha
[17:03] <seb128> ;-)
[17:03] <larsu> desrt: and it seems to be a slow gtk cycle... compared to the last one
[17:04] <seb128> larsu, LOL
[17:04] <larsu> but if I have to touch scrollbars again, I'm out
[17:04] <seb128> larsu, you want to sign for this one?
[17:04]  * larsu runs far, far away
[17:04] <seb128> see
[17:04] <larsu> ;)
[17:04] <desrt> glib is the fun one this cycle (after a slow last cycle)
[17:04] <seb128> it's going to take us a good cycle to recover from all the fun we are having
[17:04] <seb128> desrt, yeah, making rhythmbox and n-m not run, you are having a good start
[17:05] <desrt> seb128: i'm sure we'll get a pair of fixes there on monday or tuesday
[17:05] <larsu> you broke rhythmbox?!
[17:05] <desrt> larsu: soup, more specifically
[17:05] <larsu> how so?
[17:05] <desrt> larsu: soup has a gobject constructor that finalizes the constructed object, during construction
[17:05] <larsu> what does rhythmbox use soup on startup for?
[17:05] <seb128> larsu, but putting a new construction restriction with a g_error, without checking if anyone was doing the stupid things out there
[17:05] <larsu> desrt: lol
[17:05] <desrt> larsu: soup-service... presumably media sharing
[17:06] <seb128> what desrt said
[17:06] <larsu> we have that enabled by default?
[17:06] <seb128> the bt is in the daap code
[17:06] <seb128> well, I do on my laptop
[17:06] <larsu> ah, okay
[17:06] <seb128> I'm sure others do
[17:06] <larsu> I think it's not enabled by default, but many people have it
[17:06] <desrt> amusingly, the person who added the assert to glib is danw
[17:06] <desrt> and the person who wrote that constructor in soup is.... danw
[17:06] <larsu> who also maintains soup?
[17:06] <larsu> ya :D
[17:06] <desrt> it gets better
[17:07] <desrt> the last person to touch the constructor code in n-m is...... danw
[17:07] <larsu> how do you write a constructor that finalizes the object?
[17:07] <larsu> ha, brilliant
[17:07] <mhr3> seb128, i know how we can get most of the bugs fixed - we just need to ensure they happen on your computer ;)
[17:07] <ochosi> larsu: nah, i've prepared our themes already for 3.10. usually gtk3 updates suck because they break theming everywhere (otherwise, what would themers do all day?)
[17:07] <desrt> think GInitable
[17:07] <ochosi> larsu: i was just really sure 14.04 was going with 3.8 for some reason
[17:07] <desrt> implemented via g_object_new() returning NULL
[17:08] <larsu> ochosi: ya, that was the original play I think. Or at least, it was discussed
[17:08] <larsu> desrt: ugh
[17:08] <seb128> ochosi, you probably remember https://lists.ubuntu.com/archives/ubuntu-desktop/2013-October/004311.html
[17:08] <desrt> larsu: ya...
[17:08] <desrt> larsu: thing is, it's never been valid... it always leaked memory
[17:08] <seb128> ochosi, read https://lists.ubuntu.com/archives/ubuntu-desktop/2013-November/004343.html if you are interested in the current plans
[17:08] <desrt> because we keep a linked-list of in-construction objects in gobject.c
[17:09] <Laney> err
[17:09] <Laney> now the tests failed on amd64
[17:09] <desrt> and if you return NULL from your custom constructor, it never gets removed from that list
[17:09] <Laney> http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/22/ARCH=amd64,label=adt/consoleFull
[17:09] <ochosi> thanks seb128
[17:09] <desrt> Laney: is there a way for us normal humans to view these webpages?
[17:09] <Laney> oops I meant to link to the public one
[17:10] <Laney> http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/22/ARCH=amd64,label=adt/consoleFull
[17:10] <Laney> WHAT
[17:10] <larsu> that tea is messing with your clipboard!
[17:10] <desrt> just one of those days
[17:10] <Laney> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/22/ARCH=amd64,label=adt/consoleFull
[17:11] <Laney> suspicious one to fail ...
[17:11] <ochosi> seb128: nice to read that you're also taking into account the CSD problem for non-gnome desktops. xubuntu folks will happy to hear
[17:12] <seb128> ochosi, ;-)
[17:13] <desrt> GLib-GObject:ERROR:/build/buildd/glib2.0-2.39.1/./gobject/tests/object.c:134:test_object_constructor_infanticide: stderr of child process (/object/constructor/infanticide/subprocess [17405]) failed to match: *finalized while still in-construction*
[17:13] <desrt> seb128: looks like you forgot to revert the testcase that tested those comits you reverted :)
[17:13] <seb128> desrt, I didn't
[17:13] <seb128> or was that a different commit ?
[17:14] <seb128> it passed fine on i386
[17:14] <seb128> wth?
[17:14] <Laney> why doesn't it fail all the time?
[17:14] <Laney> it passed on amd64 previously too
[17:14] <seb128> desrt, that's the revert, https://launchpadlibrarian.net/157885850/glib2.0_2.39.1-0ubuntu1_2.39.1-0ubuntu2.diff.gz
[17:14] <desrt> i wonder if we're running the old set of installed tests against the new glib?
[17:15] <Laney> ah, could be
[17:15] <desrt> and by old i mean new and by new i mean reverted
[17:15] <xclaesse> seb128, just tested, I cannot even ping my laptop after resume
[17:15] <seb128> xclaesse, seems like a kernel issue then :/
[17:15] <xclaesse> seb128, I see /var/crash/susres.2013-11-29_12:12:51.860919.crash
[17:15] <xclaesse> dunno if it's related
[17:15] <seb128> xclaesse, do you have an oops in dmesg/syslog?
[17:15] <seb128> xclaesse, seems likely yes
[17:15] <Laney> + spec=/tmp/adt-run.yxo4nf/dsc0/glib2.0_2.39.1-0ubuntu1.dsc
[17:16] <Laney> that's the previous one
[17:16] <Laney> argh
[17:16] <seb128> how is that happening?
[17:16] <Laney> JENKIIIIIIIINNNNNNNNSSSSSSSSSSSSS
[17:17] <desrt> in general i think it does make sense to run the old set of installed tests against the new library
[17:17] <desrt> can catch ABI break type issues
[17:17] <desrt> but in this case it's obviously a problem since reverting that patch intentionally broke ABI...
[17:18] <Laney> W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ftpmaster.internal_ubuntu_dists_trusty-proposed_main_source_Sources Hash Sum mismatch
[17:19] <Laney>  E: Some index files failed to download. They have been ignored, or old ones used instead.
[17:19] <Laney> actually W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ftpmaster.internal_ubuntu_dists_trusty_universe_binary-amd64_Packages Hash Sum mismatch is more relevant
[17:19] <xclaesse> seb128, I don't see anything special in dmesg, but I think it only contains the msg from last boot
[17:19] <desrt> Laney: you're back in your world now and out of mine :)
[17:19]  * Laney stabs
[17:19] <larsu> seb128: bad news about the message dialog problem (which I've finally gotten around to)
[17:19]  * desrt goes back to happily hacking on dconf
[17:19] <larsu> seb128: my fix doesn't work for many apps (including gedit), because they use custom dialogs
[17:21] <Laney> hmm, I don't know if I believe that though
[17:22] <xclaesse> seb128, another really annoying issue is windows changing its virtual desktop every time there is a screen change
[17:22] <Laney> jibel: you around?
[17:22] <seb128> larsu, *great*
[17:22]  * seb128 head->desk
[17:22] <seb128> loving GTK
[17:22] <larsu> seb128: I had a feeling this is how you'd respond
[17:23] <larsu> so now, we'd really have to fix apps themselves...
[17:23] <seb128> larsu, that's fine, it's almost beer'o'clock
[17:23] <larsu> right. I don't plan on doing it now :)
[17:23] <attente> seb128, is ctrl+alt+t working for you under a russian layout?
[17:23] <seb128> attente, no, and it was no in 13.04 stock issue either when I tried iirc
[17:24] <attente> seb128, i don't know why, but it seems to be working in 14.04
[17:24] <Laney> jibel: if/when you are - could you take a look at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/22/ARCH=amd64,label=adt/consoleFull please?
[17:24] <attente> seb128, and there's also no conflict with ctrl+shift+t in gnome-terminal either
[17:24] <seb128> attente, that doesn't make sense, we didn't change things there
[17:25] <Laney> jibel: The installed-tests test installs an old libglib2.0-tests which makes the test fail
[17:25] <attente> seb128, it's really weird... everything's working :/
[17:25] <Laney> but the 'build' test got the current correct glib
[17:25] <seb128> attente, can you try with another keybinding? ctrl-alt-t is handled by compiz as well
[17:25] <seb128> it's a special case
[17:25] <seb128> like ctrl-alt-l might be a better one
[17:25] <seb128> or assign ctrl-alt-c to gnome-calculator
[17:26] <attente> ah. ok. things make sense again
[17:26] <attente> it doesn't really explain why ctrl-shift-t would work though...
[17:26] <attente> oh right... never mind
[17:26] <attente> the key binding wasn't set properly
[17:27] <xclaesse> seb128, larsu: why can't you just revert the commit that introduce the regression? or maybe just in ubuntu package...
[17:27] <xclaesse> (about the gtk issue, I've read backlog on #gtk+)
[17:27] <seb128> xclaesse, I'm thinking about it
[17:27] <seb128> it would have been nice to fix it properly/upstream though
[17:28] <xclaesse> if the fix only fix something in anaconda, and make everything else regress, that really seems a good candidate for revert
[17:28] <xclaesse> at least for ubuntu which is not impacted at all
[17:28] <seb128> right
[17:28] <desrt> seb128, Laney, xclaesse: is there some kind of 'best practice' for upstreams that want accounts created for their software?
[17:28] <seb128> well, the previous behaviour was sort of a hack
[17:28] <seb128> the thing is that half the universe rely on that wrapping at 640
[17:28] <desrt> or is it more or less something that the packager is supposed to recognise and take care of?
[17:28] <seb128> desrt, "accounts"?
[17:29] <desrt> ya... like gdm for example
[17:29] <desrt> it needs a gdm user/group created
[17:29] <seb128> oh
[17:29] <seb128> you mean system accounts
[17:29] <desrt> ya
[17:29] <seb128> like gdm running under its own user?
[17:29] <seb128> that's something done in the postinst etc
[17:29] <desrt> yes.  precisely.
[17:30] <seb128> so no, just file a bug request is in the distro bug tracker
[17:30] <seb128> or put a note in NEWS and hope the packager see it
[17:30] <desrt> is there a best practice for the upstream project to indicate that it wants distro packages to create such an account?
[17:30] <desrt> hrmph.
[17:30] <desrt> walters: how does gnome-continuous deal with this, if you don't mind?
[17:31] <desrt> seb128: i guess you can't fail the ./configure because the account doesn't exist... because the account would only be created in the postinst....
[17:32]  * desrt wonders about 'make install' rules that need to install files with correct ownership
[17:32] <seb128> desrt, right
[17:33] <desrt> tricky business, this is :)
[17:33] <seb128> desrt, same issue, make install is often ran as anuser
[17:33] <seb128> desrt, yeah, we change permissions in the postinst when needed as well
[17:34] <desrt> seems like there ought to be a better way....
[17:34]  * desrt wants /var/lib/dconf for the phone stuff, but wants it owned by dconf:dconf for the future when system dbs are written there
[17:36] <desrt> if the way you normally deal with that is chown from a postinst script anyway then maybe i should just wait until when the account is actually needed, and then the (existing) dir can be chowned at that point?
[17:36] <seb128> right
[17:36]  * desrt takes a look at some of the prior art here
[17:41] <walters> desrt: i have a hardcoded list https://git.gnome.org/browse/gnome-ostree-integration/tree/src/lib-passwd
[17:42] <walters> which works fine because the set of software is also a hardcoded list
[17:48] <Laney> seb128: lp:~laney/ubuntu-system-settings/graph-dashed-axes
[17:49] <Laney> not MPing it yet because I think I need to adjust the drawing of the actual line to not go over the axes
[17:49] <Laney> but you could branch off that to do your labels stuff
[17:52]  * Laney is off, have a good weekend all
[18:12] <desrt> walters: might break when i add an account for dconf...
[18:15] <desrt> seb128: so....
[18:15] <desrt> if [ -d /var/lib/gdm ]; then chown gdm:gdm /var/lib/gdm chown -R gdm:gdm /var/lib/gdm/.gconf* chmod 0750 /var/lib/gdm
[18:15] <desrt> fi
[18:16] <desrt> ie: we only chown/chmod in the case that we create the directory for the first time
[18:16] <desrt> which i think is a pretty sane thing to do
[18:16] <desrt> because you don't want to override the sysadmin's preference if he set it to something else and you're just upgrading the existing package
[18:17] <desrt> seb128: sort of suggests that i should ask you to make the account even if i'm not using it yet, so that you can create the directory with the correct perms
[18:17] <seb128> desrt, right, we can also do trick like "if upgrade from version <; then chown"
[18:17] <desrt> that's possible?
[18:18] <seb128> yes
[18:18] <desrt> neat
[18:18] <seb128> that's how we do migrations
[18:18] <desrt> maybe i shouldn't worry, then
[18:18] <seb128> but the snippet you copied would do it every time no?
[18:18] <seb128> if [ directory exists ] ...
[18:18] <desrt> oh uh ya.. i read that backwards
[18:18] <desrt> what a strange rule
[18:19] <seb128> well, if postinsts hit an error your upgrade/install fails
[18:19] <seb128> so you need to check that something exists before trying to chown it
[18:19] <desrt> i'm guessing gdm creates that dir in 'make install' and it's in an .install file
[18:19] <seb128> otherwise if somebody delete the dir it screws the package installation
[18:19] <desrt> or maybe adduser makes it
[18:20] <desrt> okay.  so if we don't care about this sort of stuff then i _really_ don't care :)
[18:20] <seb128> well, better we safe than sorry
[18:20]  * desrt proceeds naively
[18:20] <seb128> ;-)
[18:20] <seb128> we->be
[18:20] <seb128> but yeah, don't worry about that
[18:21] <seb128> Laney, ok, I'm not going to work on that before next week but good to know ;-)
[18:24] <desrt> Laney: how's the u-s-d/u-c-c stuff going?
[18:27] <seb128> desrt, robert_ancell is working on it, he has a vcs for both, he sent me an email this morning on u-c-c being working
[18:27]  * seb128 needs to test that next week
[18:27] <desrt> that's going to be fun.... how do you think you manage the transition there?
[18:27] <seb128> what transition?
[18:27] <desrt> straight replaces/conflits stuff?
[18:28] <seb128> robert_ancell is doing it in a way where they don't conflict
[18:28] <desrt> seb128: like... what if we see that gnome-shell is installed and unity is not, at the time of dist-upgrade?
[18:28] <seb128> which I think is crazy
[18:28] <desrt> seb128: i mean how do we decide which of (new g-c-c)/(u-c-c) to install at time of upgrade?
[18:28] <seb128> unity is going to depends on u-c-c
[18:28] <desrt> that'll do it
[18:28] <seb128> which is going to bring it for sure
[18:28] <seb128> how we clean out g-c-c is to be seen
[18:28] <seb128> we have hooks in update-manager
[18:29] <seb128> worth thing it's a leftover on disk
[18:29] <desrt> right.  makes sense as a dist-upgrade task
[18:29] <seb128> it shouldn't show in unity, it's going to be OnlyShowIn=GNOME
[18:29] <desrt> if someone does it via apt manually then they get extra packages.  no big deal.
[18:29] <seb128> right
[18:30] <desrt> seb128: i'd rather suggest NotShowIn=Unity
[18:30] <seb128> yeah, it's friday evening, I was not thinking details
[18:30] <desrt> cool.   glad to hear it's coming along nicely, in any case
[18:30] <seb128> just that we are going to tweak visibilities
[18:30] <seb128> yeah
[18:30] <seb128> we "just" need to solve the libgnome-desktop issue
[18:30] <desrt> being able to keep up to date with g-s-d/g-c-c will be really nice... a good reason for having latest gtk
[18:31] <seb128> I'm pondering just having a code copy of the functions of the old version in u-c-c
[18:31] <desrt> what's the problem here?
[18:31] <larsu> desrt just won't stop trying :)
[18:31] <seb128> they changed the xrandr code
[18:31] <larsu> "a good reason for having latest gtk"
[18:31] <desrt> oh.  right.
[18:31] <seb128> rather than talking xrandr
[18:31] <seb128> it's talking gnome-shell dbus
[18:31] <seb128> ideally we would have compatible dbus interfaces in unity
[18:31] <seb128> but I don't think that's going to happen this cycle
[18:31] <desrt> hard to argue about this being unfriendly to non-gnome desktops when it's in a library called libgnome-desktop :p
[18:32] <seb128> hehe
[18:32] <seb128> well, anyway, that's fine, just copy a couple of .c in u-c-c
[18:32] <desrt> we'll eventually need such an interface no matter what
[18:32] <seb128> until we get a similar interface in unity
[18:32] <desrt> since xrandr is going away
[18:32] <seb128> right
[18:32] <desrt> might be a good topic for the desktop summit
[18:32] <seb128> I just don't want to block anyone on that to happen
[18:32] <seb128> oh, desktop summit
[18:33] <seb128> did I mention that I want a common dbus interface for session stuff
[18:33] <desrt> inhibit and such?
[18:33] <seb128> like close the session
[18:33] <larsu> hm, interesting
[18:33] <seb128> or "show me the logout dialog"
[18:33] <desrt> ya.  we hope to talk about this
[18:33] <desrt> trying to get bastien to come this year....
[18:33] <seb128> or rather the "reboot" dialog
[18:33] <larsu> that could make unity stop exposing an interface in the org.gnome namespace
[18:33] <seb128> right
[18:33] <desrt> this stuff ought to be in org.freedesktop to the greatest extent possible
[18:34] <seb128> it could also make e.g software-properties stop calling gnome-session-quit
[18:34] <desrt> even the resolution stuff.... i can't imagine mir would be that different from wayland
[18:34] <desrt> so we may as well just copy gnome designs there
[18:34] <seb128> right
[18:34] <desrt> and rename to org.freedesktop...
[18:34] <seb128> otherwise it's going to be the same as the session stuff
[18:34] <larsu> last time we talked about this, there was some controversy around how to end a session
[18:34] <larsu> like, should apps be able to inhibit
[18:34] <desrt> larsu: KILLALL
[18:34] <seb128> we are going to claim being org.gnome.shell or something
[18:34] <seb128> and some people are going to be angry at us
[18:34] <desrt> larsu: there is no controvery.  there is only one right way :)
[18:35] <larsu> desrt: obviously you were on the one side of the controversy
[18:35] <desrt> seb128: ya... that would just be ridiculous
[18:35] <desrt> larsu: apps can register blocks to logout _with user visible reason only_
[18:35] <desrt> this will cause dialogs to be shown when the user picks 'logout'
[18:35] <larsu> hm? How would that look in practice?
[18:36] <larsu> ah the shell shows a dialog with a string that the apps giveit?
[18:36] <desrt> beyond that, if the logout is going to proceed _nothing_ can stop it
[18:36] <desrt> larsu: yes.  that's why we have inhibit 'reasons'
[18:36] <larsu> ew have those now?
[18:36] <larsu> *we
[18:36] <desrt> but a very simple desktop environment could also implement it by poking each of those apps asking them to resolve the issue
[18:37] <desrt>  gtk_application_inhibit             (GtkApplication *application, GtkWindow *window, GtkApplicationInhibitFlags flags, const gchar *reason);
[18:37] <larsu> right - but does gnome shell support this?
[18:37] <desrt> yes
[18:37] <desrt> when you logout the dialog shows something like:
[18:37] <larsu> mind = blown
[18:37] <desrt> Can't log out because:
[18:37] <desrt>  - gedit
[18:37] <desrt>    2 unsaved documents
[18:38] <desrt> ( Do it anyway )  ( Cancel )
[18:38] <larsu> does unity do this as well?
[18:38] <desrt> this is the really correct way
[18:38]  * larsu tries
[18:38] <desrt> but it's also acceptable, i think, to have the app in question pop up the dialog for itself
[18:38] <desrt> particularly if there is only one
[18:39] <larsu> no, it doesn't :-/
[18:39] <larsu> ya, that's what unity does
[18:39] <desrt> what is absolutely unacceptable, however, is for apps to have "tell me when you're about to logout and i may or may not stop the process and/or may do some cleanup..."
[18:39] <larsu> apparently only for one app at a time, thought
[18:39] <larsu> *though
[18:39] <larsu> desrt: ya, that's ridiculous
[18:39] <seb128> unity doesn't do anything
[18:39] <seb128> gnome-session does that
[18:39] <desrt> larsu: it's currently possible.  it needs to go away.
[18:39] <larsu> seb128: right, I meant unity-as-the-desktop
[18:40] <desrt> cleanup needs to go in SIGTERM handlers
[18:40] <desrt> and if someone wants to _stop_ the logout, they need to know ahead of time that they will do so, and they must give a user-visible reason
[18:40] <larsu> and most of the time, no cleanup should be necessary
[18:40] <desrt> well
[18:40] <desrt> apps may want to sync their state
[18:40] <desrt> something like bijiben for example
[18:41] <desrt> anyway.... this really ought to be on the desktop summit agenda
[18:41] <desrt> it's shameful that this isn't a freedesktop-level spec yet
[18:41] <larsu> let's write one :)
[18:56] <seb128> ok, calling it a week, have a nice w.e everyone!