pitti | Good morning | 04:43 |
---|---|---|
didrocks | good morning | 06:55 |
seb128 | good morning didrocks & desktopers! | 07:04 |
didrocks | re seb128 | 07:09 |
seb128 | re! | 07:09 |
pitti | bonjour tout le monde ! | 07:22 |
seb128 | hey pitti, wie gehts? | 07:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:29 |
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 | 07:30 |
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:16 |
tsdgeos | so here i am if anyone has time | 08:17 |
larsu | this is for charles really, but he's probably not awake yet... | 08:18 |
larsu | tsdgeos: is indicator-datetime-service running? | 08:19 |
larsu | and does it respond to dbus? | 08:19 |
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:20 |
larsu | also `gdbus call --session --dest com.canonical.indicator.datetime --object-path /com/canonical/indicator/datetime/desktop --method org.gtk.Menus.Start [0]` | 08:21 |
tsdgeos | larsu: that looks bad | 08:23 |
tsdgeos | http://paste.ubuntu.com/10444363/ | 08:23 |
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:25 |
* 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:26 |
tsdgeos | on shutdown time | 08:27 |
larsu | if you kill the process, does it work? | 08:27 |
larsu | upstart should respawn it... | 08:27 |
tsdgeos | kill -9 ? -15 ? | 08:28 |
larsu | doesn't matter | 08:28 |
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:29 |
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 |
ubot5 | bug 1421919 in indicator-datetime (Ubuntu) "clock is missing ~10% of the time" [Undecided,New] https://launchpad.net/bugs/1421919 | 08:30 |
seb128 | tsdgeos, larsu, ^ | 08:30 |
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:31 |
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:32 |
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:33 |
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:34 |
* larsu gets lots of warnings when running the cmake script | 08:39 | |
larsu | also, the build fails. Srsly? | 08:40 |
larsu | ah, apparently it can't build in parallel | 08:41 |
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:01 |
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:04 |
Laney | hey ho | 09:05 |
larsu | hey ho Laney! | 09:06 |
didrocks | morning Laney | 09:06 |
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:07 |
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:08 |
larsu | the what? | 09:09 |
Laney | no no nothing, never mind | 09:10 |
* Laney sweats | 09:10 | |
Laney | oh btw, resume failure this morning >:( | 09:10 |
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:16 |
Laney | yeah, that guy sucks | 09:17 |
seb128 | indeed he does | 09:17 |
larsu | oh wow | 09:20 |
larsu | what's going on here? | 09:20 |
didrocks | larsu: better to ignore for your own sanity :p | 09:21 |
Laney | ah | 09:38 |
Laney | it's like being back in your old armchair | 09:38 |
seb128 | lol | 09:38 |
* 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:32 |
didrocks | pitti: thoughts? ^ | 10:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
pitti | today's train ride is a bit of a challenge, train derailled an hour ago (not mine) | 10:42 |
didrocks | argh, so rerouted? | 10:42 |
=== MacSlow is now known as MacSlow|lunch | ||
pitti | didrocks: yeah, quite a bit; we'll probably arrive an hour late or so, no big deal | 11:26 |
Laney | larsu: is bug #1426163 what you've been working on? | 12:00 |
ubot5 | bug 1426163 in gnome-terminal (Ubuntu) "no locally integrated menus in gnome-terminal" [Undecided,New] https://launchpad.net/bugs/1426163 | 12:00 |
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:02 |
larsu | that's LIM... | 12:03 |
Laney | not in the terminal it isn't | 12:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:10 |
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:13 |
didrocks | (it's just a draft, the tests would be a little bit different, but there are those 2 phases) | 12:14 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 | |
didrocks | putting better comments now :) | 12:23 |
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 |
ubot5 | Launchpad bug 1351890 in gtk+2.0 (Debian) "Changing external screen resolution with dual monitors" [Unknown,Confirmed] | 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:54 |
flexiondotorg | debdiffs attached for all 3 version from the MATE dev who prepared the original GTK2 upstream patch. | 12:55 |
Laney | ok, thanks | 12:55 |
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:56 |
seb128 | me? no thanks | 12:57 |
seb128 | just keep it in the sponsoring queue for next sponsor otherwise | 12:57 |
Laney | no I'm happy to look, just sounded like you had formulated some opinions already | 12:58 |
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:00 |
=== alan_g is now known as alan_g|lunch | ||
flexiondotorg | seb128, Isn't it support until 2017 though? | 13:05 |
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:06 |
=== MacSlow|lunch is now known as MacSlow | ||
didrocks | pitti: ah, plymouth doesn't start because the kernel parameter doesn't contain "splash" | 13:46 |
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:47 |
=== alan_g|lunch is now known as alan_g | ||
pitti | didrocks: you can change the grub config in the test itself :) | 13:53 |
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:55 |
pitti | didrocks: enjoy! | 13:56 |
didrocks | thanks ;) | 13:56 |
Laney | ... | 13:56 |
Laney | can someone try launching terminator? | 13:57 |
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:04 |
pitti | Laney: wasn't he supposed to come in 2029 only? | 14:05 |
pitti | (SCNR -- TGIF! | 14:05 |
Laney | hah | 14:05 |
cyphermox | Laney: what's wrong with terminator? | 14:26 |
ogra_ | cyphermox, it kills people | 14:29 |
cyphermox | you just need to be on it's good side | 14:29 |
ogra_ | ha | 14:29 |
davmor2 | ogra_: nothing wrong with the terminator it's a great piece of music | 14:30 |
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:34 |
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:35 |
cyphermox | ok | 14:36 |
dednick | 3.18.0-13-generic | 14:36 |
cyphermox | dednick: try to remove quiet splash from the command-line so you can see whether it's booting anything | 14:37 |
dednick | cyphermox: can't remove it. can't do anything. | 14:40 |
cyphermox | dednick: I meant in grub | 14:41 |
dednick | cyphermox: ah. i'll try. bbiab | 14:42 |
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:51 |
cyphermox | not even 'starting version ' ? | 14:56 |
dednick | nope. hang on. i'm trying again | 14:56 |
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 :/ | 14:59 |
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:02 |
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:04 |
Laney | cyphermox: did you try and run it? | 15:07 |
Laney | TypeError: type 'gio.MemoryOutputStream' is not dynamically allocated but its base type '__main__.GPollableOutputStream' is dynamically allocated | 15:09 |
Laney | pythonnnnnnnnnnnnn | 15:09 |
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:10 |
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:11 |
cyphermox | Laney: yeah | 15:13 |
cyphermox | where did you report it? can I go +1? | 15:13 |
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:14 |
ubot5 | 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:14 |
cyphermox | https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294 | 15:15 |
ubot5 | 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 |
Laney | yes a few apps have it reported | 15:15 |
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:16 |
cyphermox | heh | 15:17 |
cyphermox | dednick: have you got a crash file in /var/crash then? | 15:19 |
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:25 |
didrocks | pitti: well, I'll ship a 91- then! (but thanks for the head's up :)) | 15:32 |
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:35 |
charles | larsu, thanks for doing some initial triage on this | 15:36 |
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:37 |
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:38 |
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:39 |
charles | ah I see larsu said more or less the same thing in-ticke t:) | 15:40 |
charles | hm | 15:41 |
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:42 |
charles | tedg, yes | 15:43 |
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:44 |
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:45 |
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:46 |
tedg | Wow, all of a sudden really pretty snow. | 15:48 |
cyphermox | tedg: what's that? | 15:48 |
cyphermox | *pretty* snow? | 15:48 |
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:49 |
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:56 |
charles | but I think the odds are higher the culprit's in datetime | 15:57 |
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:05 |
charles | tedg, is there a cli way to see what process owns a name? | 16:09 |
charles | I mean, obviously you can ping the name to see if you get anything back, but outside of that | 16:10 |
tedg | charles, You can query the server | 16:13 |
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:14 |
* charles annotates 1425297 with a request for that info | 16:15 | |
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: ;) | 16:20 |
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! | 17:58 |
=== alan_g is now known as alan_g|EOD | ||
Laney | happy weekend! | 18:06 |
larsu | charles: it doesn't own the name anymore (we're getting a NoSuchName error) | 20:07 |
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:08 |
charles | larsu, does gdb give us anything interesting? | 20:09 |
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:10 |
charles | the thing is, the path from g_bus_own_name()'s name-lost callback to main returning is pretty short | 20:11 |
charles | I don't see many opportunities to deadlock there, I suspect it's happening elsewhere in the code | 20:12 |
larsu | ya... | 20:16 |
* larsu is unsure as well | 20:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!