[04:43] <pitti> Good morning
[06:55] <didrocks> good morning
[07:04] <seb128> good morning didrocks & desktopers!
[07:09] <didrocks> re seb128
[07:09] <seb128> re!
[07:22] <pitti> bonjour tout le monde !
[07:22] <seb128> hey pitti, wie gehts?
[07:23] <pitti> seb128: gut, danke ! nous allons à Dresden aujourd'hui, je l'attends avec impatience !
[07:23] <seb128> pitti, oh, bon voyage!
[07:23] <pitti> je vais avoir un bon temps calme dans le train pour ... hacking snappy tests :)
[07:23] <seb128> :-)
[07:24] <seb128> pitti, did you figure out the systemd issue btw? I know you found the commit that created the issue, but you said it was probably not a bug in that changeset?
[07:25] <pitti> seb128: yes, it has been fixed in vivid for several days
[07:25] <larsu> morning folks!
[07:25] <seb128> pitti, fixed or workarounded?
[07:25] <pitti> seb128: right, I still don't fully understand it; sometimes the new state keeping functionality confuses dbus, and you have to restart dbus in order to get things back to work
[07:25] <pitti> seb128: worked around by reverting the new feature
[07:26] <seb128> pitti, ok, that was what I was asking, if you figured out why dbus get confused
[07:26] <pitti> seb128: I'm still looking at it on and off, but I have several other urgent things to do too, so it's not my #1 prio ATM
[07:26] <seb128> seems not then
[07:26] <seb128> pitti, yeah, boot is working again, so not a top priority indeed
[07:26] <pitti> seb128: yesterday I installed F21 and upgraded to rawhide's dbus and systemd, and I couldn't reproduce it there
[07:26] <seb128> pitti, :-/
[07:26] <pitti> but my "fast reproducer" isn't good enough as it seems, it doesn't work on debian either
[07:26] <seb128> is Debian having the issue?
[07:26] <pitti> yes, they do
[07:26] <seb128> k
[07:26] <pitti> i. e. it's not one of our many dbus patches
[07:27] <pitti> so debian and rawhide have the same systemd, and almost the same dbus (I checked the  difference, it looks harmless)
[07:27] <pitti> we have quite an old polkit, but that's not the most likely culprit
[07:27] <pitti> i. e. I need to continue finding a better reproducer
[07:27] <seb128> right
[07:27] <seb128> pitti, good luck with that!
[07:29] <pitti> seb128: merci !
[07:29] <larsu> pitti: lol at your g+ post
[07:29] <didrocks> Really a hard issue… would have been better if debian didn't get it and we would, to find the culpurit easier
[07:30] <larsu> pitti: also, good morning and happy Friday!
[07:30] <pitti> hey larsu, Dir auch!
[07:30] <pitti> didrocks: yeah, so at this point I can't decide yet whether fedora is affected
[07:30] <pitti> I know mbiebl got the issue on sid+exp, but I haven't been able to reproduce it there yet
[07:30] <didrocks> yeah, I remember he told that the day after the fsckd backport :p
[08:16] <tsdgeos> guys, the time indicator is gone again
[08:16] <tsdgeos> last time it happened you told me not to manually start it
[08:16] <tsdgeos> so we could do some live debugging
[08:17] <tsdgeos> so here i am if anyone has time
[08:18] <larsu> this is for charles really, but he's probably not awake yet...
[08:19] <larsu> tsdgeos: is indicator-datetime-service running?
[08:19] <larsu> and does it respond to dbus?
[08:20] <tsdgeos> running i guess yes http://paste.ubuntu.com/10444330/
[08:20] <larsu> looks good. Can you paste the output of `gdbus call --session --dest com.canonical.indicator.datetime --object-path /com/canonical/indicator/datetime --method org.gtk.Actions.DescribeAll` please
[08:21] <larsu> also `gdbus call --session --dest com.canonical.indicator.datetime --object-path /com/canonical/indicator/datetime/desktop --method org.gtk.Menus.Start [0]`
[08:23] <tsdgeos> larsu: that looks bad
[08:23] <tsdgeos> http://paste.ubuntu.com/10444363/
[08:25] <larsu> tsdgeos: ah, so it lost the name for some reason and you can't dbus-activate it anymore (because tedg loves upstart)
[08:25] <larsu> tsdgeos: not sure what to do tbh
[08:26]  * larsu wonders why the process doesn't exit when it loses the name
[08:26] <tsdgeos> should it have an upstart log somewhere?
[08:26] <seb128> .cache/upstart/indicator-....
[08:26] <tsdgeos> yaeh
[08:26] <tsdgeos> nothing
[08:26] <larsu> tsdgeos: good idea, please paste that as well (though I have a feeling it won't help much)
[08:26] <tsdgeos> last .gz is from yesterda
[08:27] <tsdgeos> on shutdown time
[08:27] <larsu> if you kill the process, does it work?
[08:27] <larsu> upstart should respawn it...
[08:28] <tsdgeos> kill -9 ? -15 ?
[08:28] <larsu> doesn't matter
[08:29] <tsdgeos> yep it came back
[08:29] <larsu> head -> desk
[08:29] <larsu> this is _exactly_ why I tied lifecycle to dbus back then
[08:29] <larsu> tsdgeos: sorry I couldn't be of more help
[08:30] <tsdgeos> should i report a bug about it? or you think it's not worth?
[08:30] <larsu> ya please do
[08:30] <seb128> bug #1421919
[08:30] <seb128> tsdgeos, larsu, ^
[08:31] <larsu> ya
[08:31] <larsu> let's port indicators to dbus activation again
[08:31] <larsu> and this won't happen anymore
[08:31] <seb128> larsu, do you have any idea how we can end up in that situation?
[08:31] <seb128> larsu, well, it's not related to activation if the process is running?
[08:31] <larsu> seb128: I have an idea: (1) datetime loses the name, but doesn't exit
[08:32] <seb128> larsu, how can it lose the name?
[08:32] <larsu> (2) upstart doesn't notice because the process is still running, thus doesn't respawn it
[08:32] <larsu> seb128: I'm trying to find that out right now...
[08:33] <seb128> larsu, imho that's the real issue
[08:33] <seb128> larsu, if it was dbus activated, what would stop the process if it doesn't exit?
[08:33] <larsu> seb128: no, but it would spawn a new one
[08:33] <larsu> but yeah, still a bug
[08:34] <seb128> right
[08:34] <seb128> sounds like a workaround rather than a fix
[08:34] <larsu> at least not as visible *cough* *cough* :P
[08:34] <seb128> we don't want zombie processes around
[08:34] <larsu> we also want a clock around
[08:34] <seb128> right
[08:34] <seb128> so let's fix the real bug :-)
[08:39]  * larsu gets lots of warnings when running the cmake script
[08:40] <larsu> also, the build fails. Srsly?
[08:41] <larsu> ah, apparently it can't build in parallel
[09:01] <larsu> seb128: can't reproduce and the code looks to be doing the right thing ...
[09:01] <larsu> unless it's going into a deadlock of some kind
[09:01] <larsu> not sure if dbus would release the name in that case
[09:04] <seb128> larsu, we should have asked for a gdb bt before killing the process :-/
[09:04] <larsu> indeed
[09:04] <seb128> larsu, yeah, I can't reproduce either, but we got several reports in vivid so it's likely a real issue
[09:05] <Laney> hey ho
[09:06] <larsu> hey ho Laney!
[09:06] <didrocks> morning Laney
[09:07] <Laney> happy friday!
[09:07] <Laney> (/me checks it really is friday)
[09:07] <didrocks> it definitively is friday :)
[09:07] <seb128> hey Laney
[09:07] <Laney> hey seb128
[09:08] <seb128> is it friday? bah, too much to do for a friday!
[09:08]  * larsu can't check, debugging indicator-datetime
[09:08] <didrocks> ahah
[09:08] <Laney> just calculate it from the position of the sun
[09:09] <larsu> the what?
[09:10] <Laney> no no nothing, never mind
[09:10]  * Laney sweats
[09:10] <Laney> oh btw, resume failure this morning >:(
[09:16] <Laney> might go back to upstart to rule out systemd
[09:16] <Laney> good idea Laney, you do that
[09:16] <Laney> OK Laney, I will
[09:16] <seb128> Laney, stop talking to Laney
[09:17] <Laney> yeah, that guy sucks
[09:17] <seb128> indeed he does
[09:20] <larsu> oh wow
[09:20] <larsu> what's going on here?
[09:21] <didrocks> larsu: better to ignore for your own sanity :p
[09:38] <Laney> ah
[09:38] <Laney> it's like being back in your old armchair
[09:38] <seb128> lol
[10:32]  * didrocks tries to think of an elegant solution for the fsck reboot tests using unittests…
[10:32] <didrocks> maybe it won't fit in unit tests and needs a script which is branching depending on ADT_REBOOT_MARK
[10:33] <didrocks> pitti: thoughts? ^
[10:34] <pitti> didrocks: yeah, that's a classic integration test; for a unit test you'd have to mock everything else including the sockets
[10:34] <pitti> didrocks: systemd unit tests are mostly for algorithms and simple file handing
[10:34] <didrocks> pitti: I meant the "unittests" frameworks (to have the asserttrue and such)
[10:34] <pitti> an actual boot and bits talking together is better in QEMU
[10:35] <pitti> didrocks: ah
[10:35] <pitti> didrocks: well, the other autopkgtests do that all the time
[10:35] <didrocks> pitti: it's only one reboot though
[10:35] <didrocks> to reboot under systemd
[10:35] <didrocks> here, it will be multiple ones, with different config each time
[10:35] <pitti> didrocks: main() prepares stuff, calls autopkgtest-reboot, and after that start unittest.main()
[10:35] <didrocks> right
[10:36] <didrocks> but I mean each tests will need to reboot
[10:36] <pitti> didrocks: e. g. debian/tests/boot-and-services
[10:36] <didrocks> and then check tests
[10:36] <didrocks> debian/tests/boot-and-services only reboots one if I'm correct
[10:36] <pitti> didrocks: ah, you can't use unittest.main() then
[10:36] <didrocks> yeah
[10:36] <didrocks> or using a lot of skip unless()
[10:37] <didrocks> based on ADT_REBOOT_MARK
[10:37] <didrocks> but not really handy
[10:37] <pitti> didrocks: you could use unittest.TestLoader() to load a particular class (or even method) based on the marker
[10:37] <didrocks> could do that, maybe…
[10:37] <didrocks> pitti: how does autopkgtests btw knows that it didn't finish up with a test which rebooted?
[10:38] <didrocks> and should reexecute the same file?
[10:38] <pitti> didrocks: or you write it in shell or a simpler framework, like boot-smoke
[10:38] <pitti> didrocks: you don't call "reboot", you call /tmp/autopkgtest-reboot
[10:39] <didrocks> ah, so it puts a flags
[10:39] <pitti> that does the additional steps: save temp dir and artifacts, remember current test, reboot, restore artifacts/temp dir, resume
[10:39] <didrocks> which will tell to reexecute
[10:39] <didrocks> in addition to sett the MARK variable
[10:39] <pitti> yep
[10:39] <didrocks> ok, making sense :)
[10:39] <pitti> pure magic!
[10:39] <didrocks> hehe, nicely done :)
[10:39] <didrocks> so yeah, I guess I'll have to check the assertions myself
[10:39] <pitti> didrocks: BTW, I didn't mean to impose this on you, and even less so "do it now"
[10:39] <pitti> didrocks: it was more like loud thinking really
[10:40] <didrocks> pitti: no, but it was in my mind anyway, so thinking about it
[10:40] <didrocks> so no worry :)
[10:40] <pitti> didrocks: a simple smoke test whether it survives a reboot with fsck and verify that it run sounds like 20 lines of shell
[10:40] <pitti> didrocks: but it sounds like you are aiming way higher :)
[10:41] <didrocks> pitti: yeah, I want a little bit more use case
[10:41] <didrocks> like fsck dying
[10:41] <didrocks> and the cancellation, if possible
[10:41] <didrocks> at least
[10:41] <didrocks> oh, also, rebooting plymouth
[10:41] <pitti> didrocks: next station is coming up, will be offline for some 30 mins
[10:41] <didrocks> pitti: no worry, I'm just thinking about it while doing other things ;)
[10:42] <pitti> today's train ride is a bit of a challenge, train derailled an hour ago (not mine)
[10:42] <didrocks> argh, so rerouted?
[11:26] <pitti> didrocks: yeah, quite a bit; we'll probably arrive an hour late or so, no big deal
[12:00] <Laney> larsu: is bug #1426163 what you've been working on?
[12:02] <larsu> Laney: I don't understand that bug - LIM is clearly enabled in that screenshot..
[12:02] <Laney> oh I didn't see the first one
[12:02] <Laney> what's going on with his terminal there?
[12:03] <larsu> that's LIM...
[12:03] <Laney> not in the terminal it isn't
[12:04] <larsu> ok, step back. Which screenshot are we talking about?
[12:04] <Laney> that's "no Ubuntu crap"
[12:04] <Laney> in comment #1
[12:04] <larsu> that's LIM
[12:04] <Laney> it's underneath the title bar ...
[12:04] <larsu> menu is in the title basr
[12:05] <larsu> oh, I should actually look at comment #1
[12:05] <larsu> yes, that's ubuntu crap
[12:05] <larsu> my patches fix that
[12:05] <larsu> also they'll hide the "Show Menubar" option
[12:05] <larsu> because that doesn't make any sense on unity
[12:05] <larsu> all of this based on the Gtk/ShellShowsMenubar xsetting
[12:05] <Laney> and in comment #2 he has the app menu
[12:06] <Laney> I guess that goes away too
[12:06] <larsu> right, that's a high prio bug that Trevinho is working on
[12:06] <Laney> anyway, just wanted to check if this was the same bug
[12:06] <larsu> I guess something related to his recent i-appmenu changes
[12:06] <larsu> no, it's a different one
[12:06] <larsu> the "duplicate menus" part is what I'm working on
[12:06] <Laney> did you see that rishi is working on making vte use a proper scrolled window?
[12:07] <larsu> ya, pretty neat
[12:07] <Laney> happy days
[12:07] <larsu> definitely
[12:07] <Laney> on menus, lemme know when they approve your patches and we should be able to take them
[12:08] <larsu> will do
[12:08] <larsu> I havent't submitted them yet, but will today
[12:08] <larsu> (still got some minor bugs)
[12:08] <Laney> nod
[12:10] <Laney> man it's looking nice outside
[12:10] <Laney> just 5°c more or so and i'll be able to sit out to have lunch
[12:10] <Laney> come on the weather, you can do it
[12:13] <didrocks> pitti: what do you think about something like this? http://paste.ubuntu.com/10447566/
[12:13] <didrocks> pitti: that would enable having the test preparation and then, the after reboot check in the same unittest function
[12:14] <didrocks> (it's just a draft, the tests would be a little bit different, but there are those 2 phases)
[12:16] <pitti> ADT_REBOOT_MARK contains the test name to continue end in the result
[12:16] <pitti> # mode
[12:16] <pitti> didrocks: ^ I'm afraid I need some interpretation here, I don't understand that
[12:17] <didrocks> oupsss, I didn't rewrote it after changing the semantic
[12:17] <didrocks> so, basically, this would support tests with or without reboot
[12:17] <didrocks> hence the loop on remaining_tests
[12:17] <didrocks> remaining_tests contains in sorted order, all "test_" functions from the test class
[12:18] <didrocks> if a test needs a reboot before ending
[12:18] <didrocks> it will called reboot(), which marks ADT_REBOOT_MARK=<current_test_name>:<global_current_return_code>
[12:18] <pitti> didrocks: ah, you don't want to immediately exit after a failure?
[12:18] <didrocks> then, we reboot
[12:18] <didrocks> no, I want the other tests to restarts
[12:18] <didrocks> continue*
[12:19] <pitti> didrocks: please drop the apt-get install systemd-sysv, just make that a Depends:
[12:19] <didrocks> and so, then remaining_tests tuple restarts at current_test_name
[12:19] <pitti> (this works now in vivid)
[12:19] <didrocks> oh sure, so no need for the first reboot :)
[12:20] <didrocks> and so, we store the global return code and exit if needed
[12:20] <pitti> didrocks: oh, you still need to actually boot with systemd, you can just skip the manual pkg install
[12:20] <pitti> didrocks: ack
[12:20] <didrocks> pitti: ah ok, the test bed isn't reboot after installing the packages
[12:20] <pitti> didrocks: getAllTests() looks hairy, but I don't know unittests.TestLoader() enough whether it can introspect in a nicer way
[12:20] <pitti> didrocks: so, this looks fine to me
[12:21] <didrocks> pitti: I didn't find a way to filter on what I wanted
[12:21] <pitti> didrocks: shouldn't you also test that systemd-fsckd actually ran, not only that it is inactive?
[12:21] <didrocks> the nice thing in that approach is that we can mix tests that needs to reboot the testbed and test that doesn't need it
[12:21] <didrocks> pitti: that part was just for the example, I didn't work on the tests themselves yet
[12:21] <pitti> ah
[12:22] <didrocks> it was more on the "mixing tests that needs reboot and others" mechanism
[12:22]  * didrocks will rename "result_check" to "after_reboot"
[12:22] <didrocks> that will make more sense
[12:22] <pitti> didrocks: right; AFAIK that's the first multi-reboot unittest, nice to have a template now!
[12:22]  * pitti hugs didrocks
[12:22]  * didrocks hugs pitti back
[12:23] <didrocks> putting better comments now :)
[12:54] <flexiondotorg> Laney, you mentioned you'd sponsor GTK fixes for Precise, Trusty and Utopic?
[12:54] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1351890/comments/14
[12:54] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1351890/comments/15
[12:54] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1351890/comments/16
[12:55] <flexiondotorg> debdiffs attached for all 3 version from the MATE dev who prepared the original GTK2 upstream patch.
[12:55] <Laney> ok, thanks
[12:56] <seb128> I wouldn't bother backporting to precise, it's risky for little benefit
[12:56] <seb128> trusty/utopic should be useful though
[12:56] <Laney> you take care of it if you want
[12:57] <seb128> me? no thanks
[12:57] <seb128> just keep it in the sponsoring queue for next sponsor otherwise
[12:58] <Laney> no I'm happy to look, just sounded like you had formulated some opinions already
[13:00] <seb128> well, I didn't even look at those, just commenting on the usefulness to backport desktop work to precise
[13:00] <seb128> it's not even the current LTS
[13:05] <flexiondotorg> seb128, Isn't it support until 2017 though?
[13:06] <seb128> flexiondotorg, right, but support doesn't mean backporting every single bugfix which happened since 2012
[13:06] <seb128> it means dealing with security issues mostly, and backporting important fixes when the investiment is worth the benefit
[13:46] <didrocks> pitti: ah, plymouth doesn't start because the kernel parameter doesn't contain "splash"
[13:47] <didrocks> pitti: should I duplicate the service? (I already have to do that for systemd-fsck-root because of rw mode from the start) or is there a way to change those in autopkgtest config?
[13:53] <pitti> didrocks: you can change the grub config in the test itself :)
[13:55] <didrocks> pitti: yeah, not stupid ;)
[13:55]  * didrocks does
[13:55] <didrocks> but it seems it's going to stop raining for a bit, going for a run then :)
[13:55] <didrocks> thanks pitti!
[13:56] <pitti> didrocks: enjoy!
[13:56] <didrocks> thanks ;)
[13:56] <Laney> ...
[13:57] <Laney> can someone try launching terminator?
[14:04] <pitti> didrocks: that's not super-trivial, though; e. g. adt-setup-vm changes the grub config in /etc/default/grub.d/90-autopkgtest.cfg to enable serial console
[14:05] <pitti> Laney: wasn't he supposed to come in 2029 only?
[14:05] <pitti> (SCNR -- TGIF!
[14:05] <Laney> hah
[14:26] <cyphermox> Laney: what's wrong with terminator?
[14:29] <ogra_> cyphermox, it kills people
[14:29] <cyphermox> you just need to be on it's good side
[14:29] <ogra_> ha
[14:30] <davmor2> ogra_: nothing wrong with the terminator it's a great piece of music
[14:34] <dednick> can anyone help? I've just done an upgrade and installed some other packages and now when i restart laptop I can't just default boot option. Only thing that works is going into grub and selecting "$KERNELVERSION (systemd)".
[14:34] <dednick> just stalls on purple screen and can't get to vt either.
[14:35] <dednick> tty i mean
[14:35] <cyphermox> dednick: is that litterally how it's shown, not an actual kernel version?
[14:35] <dednick> cyphermox: no. it's the version
[14:36] <cyphermox> ok
[14:36] <dednick> 3.18.0-13-generic
[14:37] <cyphermox> dednick: try to remove quiet splash from the command-line so you can see whether it's booting anything
[14:40] <dednick> cyphermox: can't remove it. can't do anything.
[14:41] <cyphermox> dednick: I meant in grub
[14:42] <dednick> cyphermox: ah. i'll try. bbiab
[14:51] <dednick> cyphermox: no difference. doesnt seem to do anything when i get it to boot with systemd either.
[14:51] <dednick> ie. no boot log
[14:56] <cyphermox> not even 'starting version ' ?
[14:56] <dednick> nope. hang on. i'm trying again
[14:59] <dednick> cyphermox: hm. that's weird. i removed plymouth-theme-ubuntu-text and it worked.
[14:59] <dednick> cyphermox: went to terminal though. had to start lightdm manually :/
[15:02] <cyphermox> I'm not sure I follow, but maybe if you file a bug and put as much relevant information as you can (what pacakges you removed, maybe /var/log/apt/term.log, and some details about exactly what the grub menu looks like?
[15:02] <cyphermox> file it against plymouth for now
[15:04] <cyphermox> unless you did your updates very much not long ago and the systemd update from ~2 hours ago is breaking things...
[15:04] <cyphermox> which I will see soon because I need to reboot.
[15:04] <dednick> cyphermox: hm. well i did update about 2h ago
[15:07] <Laney> cyphermox: did you try and run it?
[15:09] <Laney> TypeError: type 'gio.MemoryOutputStream' is not dynamically allocated but its base type '__main__.GPollableOutputStream' is dynamically allocated
[15:09] <Laney> pythonnnnnnnnnnnnn
[15:10] <cyphermox> I see
[15:10] <cyphermox> you broke my terminal!
[15:10] <cyphermox> is that python or is that gobject-introspection of some sort?
[15:11] <Laney> it's using the old static bindings
[15:11] <Laney> http://bugs.python.org/issue22079 it is this change in python
[15:11] <dednick> hm. i did upgrade but i didnt get the new systemd.
[15:13] <cyphermox> Laney: yeah
[15:13] <cyphermox> where did you report it? can I go +1?
[15:14] <Laney> i just saw http://bugs.python.org/issue22079
[15:14] <Laney> erm
[15:14] <Laney> https://bugs.launchpad.net/ubuntu/+source/bleachbit/+bug/1426218
[15:15] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294
[15:15] <Laney> yes a few apps have it reported
[15:16] <dednick> cyphermox: getting this in dmeg log. http://pastebin.ubuntu.com/10450097/
[15:16] <attente_> any known workaround?
[15:16] <dednick> *dmes
[15:16] <dednick> bah
[15:16] <dednick> dmesg
[15:17] <cyphermox> heh
[15:19] <cyphermox> dednick: have you got a crash file in /var/crash then?
[15:25] <dednick> cyphermox: it's plymouthd that's crashing. the bridge just exits if it can't find it. got a crash dump for it; looking now
[15:32] <didrocks> pitti: well, I'll ship a 91- then! (but thanks for the head's up :))
[15:35] <Sweet5hark1> one hour in and libreoffice on ppc64el and arm64 is still building. lets see how far it gets ...
[15:35] <charles> tsdgeos, reading through scrollback now, do you still have the nonresponsive datetime session available?
[15:36] <charles> larsu, thanks for doing some initial triage on this
[15:37] <tsdgeos> charles: no, i killed it and got a working one, sorry
[15:37] <charles> tsdgeos, ack
[15:37] <charles> tsdgeos, datetime should exit when it loses the busname for whatever reason, and then upstart should restart it as per tedg's upstart work. Not sure why that's not happening here
[15:38] <charles> tsdgeos, possibly datetime is deadlocked somewhere s.t. it won't reach the exit() call
[15:38] <tsdgeos> i'll try to gdb it next time
[15:38] <tsdgeos> see if i can get a backtrace
[15:38] <charles> ack, that would be the next step
[15:38] <charles> thanks!
[15:39] <charles> tsdgeos, did it happen on boot, or later?
[15:39] <tsdgeos> charles: boot
[15:39] <charles> k
[15:39] <charles> that matches the other reports I've seen
[15:39] <charles> I'd love to get my hands on a live session of this :-)
[15:40] <charles> ah I see larsu said more or less the same thing in-ticke t:)
[15:41] <charles> hm
[15:42] <charles> larsu, is there a way to see if datetime actually still owns the name?
[15:42] <tedg> charles, I'm curious if it's not getting the name the first time.
[15:42] <charles> if it's deadlocked somewhere, it may still own the name but still not be responding
[15:42] <tedg> charles, Are you setting allow replacement?
[15:43] <charles> tedg, yes
[15:44] <tedg> charles, Perhaps it's getting replaced by something? Not sure why that'd be, but there's no reason to allow it.
[15:44] <charles> tedg, the main action is in a normal g_bus_own_name() call, where on_bus_acquired exports the menus/actions and name_lost() calls a core::Signal that should break out of main()'s g_main_loop_run()
[15:45] <charles> tedg, so name_lost_handler() would be called if either it coudln't get the bus, or it could get the bus but not name ownership, and the service would exit
[15:46] <tedg> Hmm, trying to brainstorm ideas.
[15:46] <charles> tedg, so I don't know what the actual problem is, but it's probably not failure to get bus
[15:46] <tedg> charles, Could it be not getting dbus at all?
[15:46] <cyphermox> dednick: thanks
[15:46] <tedg> i.e. it's still waiting.
[15:48] <tedg> Wow, all of a sudden really pretty snow.
[15:48] <cyphermox> tedg: what's that?
[15:48] <cyphermox> *pretty* snow?
[15:49] <tedg> cyphermox, It's like the first snow of the season for you :-)
[15:49] <cyphermox> heheh
[15:49] <cyphermox> after a few days the words change
[15:49] <tedg> Yeah, this will melt by Sunday
[15:49] <cyphermox> to something I won't repeat because I'm polite ;)
[15:56] <charles> tedg, according to g_bus_own_name()'s docs, we're "guaranteed" that name_lost_handler will be called if either we can't get the bus or can't get the name
[15:56] <charles> so again, I don't think that's the problem unless it's a bug in gio
[15:56] <charles> which is possible
[15:57] <charles> but I think the odds are higher the culprit's in datetime
[16:05] <tedg> charles, Yeah, just a weird state as it seems to be waiting for something. But it doesn't have the name.
[16:05] <tedg> I don't think that it lost it, as that case seems pretty clear, I think it must have never gotten it.
[16:09] <charles> tedg, is there a cli way to see what process owns a name?
[16:10] <charles> I mean, obviously you can ping the name to see if you get anything back, but outside of that
[16:13] <tedg> charles, You can query the server
[16:14] <tedg> charles, gdbus call --session --dest org.freedesktop.DBus --object-path / --method org.freedesktop.DBus.GetNameOwner com.canonical.indicator.datetime
[16:14] <charles> tedg, thanks
[16:15]  * charles annotates 1425297 with a request for that info
[16:20] <tedg> cyphermox, Snow stopped. Have to wait for next year. ;-)
[16:20] <tedg> Actually a chance of more tonight, we'll see.
[16:20] <cyphermox> tedg: ;)
[17:58] <Laney> I uploaded the g-t wrapper script to the ppa, maybe some people can give it a go
[17:58] <Laney> hey, everybody's gone!
[18:06] <Laney> happy weekend!
[20:07] <larsu> charles: it doesn't own the name anymore (we're getting a NoSuchName error)
[20:08] <larsu> charles: and I couldn't bring it into a state where it doesn't own the name but is still running
[20:08] <larsu> charles: I think the name-owning logic is sound - it's probably deadlocking or spinning in another thread
[20:09] <charles> larsu, does gdb give us anything interesting?
[20:10] <charles> larsu, are you saying you're seeing this right now?
[20:10] <larsu> charles: I haven't gotten into that state myself, unfortunately
[20:10] <charles> ok
[20:11] <charles> the thing is, the path from g_bus_own_name()'s name-lost callback to main returning is pretty short
[20:12] <charles> I don't see many opportunities to deadlock there, I suspect it's happening elsewhere in the code
[20:16] <larsu> ya...
[20:16]  * larsu is unsure as well