[05:22] <pitti> Good morning
[06:31] <Fudge> ~/j andlinux
[07:42] <darkxst> hi pitti
[07:43] <darkxst> ok to update gsettings-desktop-schemas?
[07:44] <pitti> hey darkxst, how are you?
[07:44] <darkxst> yeh good, you?
[07:45] <pitti> pretty well, thanks; cleanup on last day this year :)
[07:46] <darkxst> pretty sure all removed keys, have been reverted in my package. don't think there is anything that will blow up the world
[09:03] <Laney> g'morning
[09:15] <mlankhorst> g'day
[09:19] <Laney> happy last day!
[09:21] <sil2100> Morning! Happy last day indeed ;)
[09:30] <mlankhorst> happy 1-day-before-shortest-day!
[09:33] <Laney> yeah then it's basically summer right
[09:36]  * RAOF basks in the evening sun
[09:37] <Laney> you crazy upside down people
[09:39] <Laney> desrt: hrm, the gdbus-names test has started being unreliable: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/
[09:39] <Laney> & the log: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/37/ARCH=i386,label=adt/consoleText
[09:39] <Laney> what could be up there?
[09:45] <larsu> Laney: can you reproduce this on your machine?
[09:45]  * larsu tries
[09:50] <Laney> haven't seen it there
[09:50] <Laney> let me run it under gnome-desktop-testing
[09:55] <Laney> I ran it 50 times and it passed (not under the testing runner)
[09:56] <Laney> hmm, it eventually ran out of inotify watches
[09:57] <Laney> well, "Cannot initialize inotify"
[09:57] <larsu> the gdbus-names test?
[09:57]  * larsu is confused
[09:58] <Laney> yep
[09:59] <Laney> Might have been my fault for running dbus-launch n times though ... :-)
[09:59] <larsu> :)
[10:00] <larsu> the test launches its own bus btw
[10:00] <Laney> nod
[10:01] <Laney> yeah this seems saner
[10:01] <Laney> ran it 1000 times, passed
[10:01] <larsu> so the connection that g_bus_get() returns is marked as closed
[10:01] <larsu> and then signal_subscribe() prints that error on stdout
[10:01] <larsu> Laney: same for me, I'm going by the log
[10:03] <larsu> is there any way to get at that backtrace?
[10:04] <Laney> let's see, maybe there's a crash file
[10:04] <larsu> looks like there was some error uploading it
[10:04] <Laney> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/37/ARCH=i386,label=adt/ there's one linked here
[10:05] <larsu> ah cool, thanks
[10:08] <larsu> hm, not very helpful
[10:59] <Laney> larsu: you shouldn't g_source_remove (id) after g_main_loop_run (loop) returns, right?
[11:00] <Laney> https://launchpadlibrarian.net/160125510/buildlog_ubuntu-trusty-amd64.whoopsie_0.2.24.2_FAILEDTOBUILD.txt.gz
[11:01] <larsu> Laney: that shouldn't be a problem
[11:01] <Laney> oh ok, I thought that might remove the sources for you
[11:02] <larsu> no, it doesn't. Sources are added to main contests, not loops
[11:02] <larsu> the problem in that link is that somebody is removing a source that was already removed
[11:02] <larsu> glib started warning about that recently
[11:02] <Laney> right
[11:03] <Laney> I know the problem
[11:03] <Laney> let me get the code
[11:03] <Laney> https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/tests/test_monitor.c#L150
[11:04] <larsu> the one in line 150 is the one that causes this warning?
[11:06] <Laney> no, lies, it's the one at 207 isn't it
[11:06] <larsu> ya, I was about to say
[11:06] <larsu> time sources need to return something, g_main_loop_quit() doesn't
[11:07] <larsu> if they return FALSE, they're removed. You can't call g_source_remove() again on those
[11:07] <Laney> the 150 one happened locally
[11:07] <Laney> I think, it's kind of hard to read
[11:11] <Laney> so I think you could make them both return FALSE and then not g_source_remove() i t
[11:11] <Laney> yes?
[11:13] <larsu> yes. That might leak the source though
[11:13] <larsu> when it never gets triggered
[11:13] <larsu> but I guess that's okay for the test
[11:14] <Laney> ya, otherwise I could pass a boolean in to track that
[11:14] <Laney> not sure it's worth it
[11:15] <larsu> aren't these callbacks just to timeout the test?
[11:15] <larsu> so that it doesn't run too long? You could just assert in the callback
[11:15] <Laney> yeah but I don't think g_test_fail () stops the test
[11:15] <Laney> stuff happens after
[11:15] <larsu> ah, okay
[11:16] <Laney> the second one doesn't g_test_fail () actually
[11:16] <Laney> not entirely keen on unwinding the logic :P
[11:18] <larsu> ah, because it waits for two seconds to test that the callback is never triggered
[11:19] <larsu> so it shouldn't fail in the timeout
[11:19] <larsu> kind of a weird thing to test
[12:19] <sabdfl> join #yandex
[12:19] <sabdfl> hehe
[12:20] <ochosi> oops :)
[13:46] <Laney> buh, glib-networking is failing too
[14:01] <desrt> Laney: i hate unreliable tests :p
[14:01] <larsu> desrt: speaking of which, do you in which situation g_bus_get() can return a connection that is closed?
[14:02] <larsu> I thought it returns NULL if it can't establish the connection
[14:02] <Laney> they were all super reliable until 2.39
[14:02]  * larsu done with duolingo for the day. Back to work!
[14:03] <desrt> larsu: i can't help but wonder if this is something wrong with our tester rig
[14:04] <larsu> hm
[16:18] <Laney> attente: the 'preview' thing seems to have gotten broken
[16:18] <Laney> where it changes the language on the selection screen
[16:19] <attente> Laney, yeah, that's been broken for a long time now
[16:19] <Laney> oh ok
[16:19] <Laney> I thought it worked
[16:19] <attente> it did
[16:19] <attente> but something changed in the toolkit and i didn't figure out what it was
[16:22] <Laney> alright, I'll file a bug
[16:22] <Laney> this looks good now, will approve
[18:03] <Laney> happy holidays desktoppers!