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