=== duflu_ is now known as duflu === thumper is now known as thumper-afk === lifeless_ is now known as lifeless [04:58] morn [05:42] Good morning [06:43] good morning desktopers === ohama_ is now known as ohama [07:26] morning! === thumper-afk is now known as thumper [08:32] since today's dist-upgrade unity panel crashes every few mins, bug 1248446 [08:32] Launchpad bug 1248446 in unity (Ubuntu) "unity-panel-service crashed with SIGSEGV in g_object_unref()" [Undecided,New] https://launchpad.net/bugs/1248446 [08:33] this keeps rearranging windows and screen flicker, so it's quite noticeable [08:34] pitti, hey [08:34] bonjour seb128, ça va ? [08:34] pitti, that's an ido-trusty issue, I'm debugging it with tsdgeos on #ubuntu-unity, downgrade libido-3-0 if you need a workaround [08:34] pitti, oui, et toi ? [08:40] seb128: ah, so known? thanks [08:40] seb128: I'm good, thanks! [08:40] pitti, "known", you are the second one to ping me about it, tsdgeos is getting a valgrind log [08:41] apport traces arrived, too [08:41] seb128: i'll add the valgrind log to the bug [08:41] tsdgeos, thanks [08:42] pitti, retraces matches http://paste.ubuntu.com/6369241/ from tsdgeos [08:42] the valgrind log is not very interesting though [08:44] tsdgeos, doesn't tell where the other unref is? [08:44] according to the trace it'd seem it's not a double delete, just a bad delete :D [08:45] but i haven't done much/any glib "bad deletion" code on valgrind so no idea if this is what one would expect from a double delete or not [08:50] you usually get a rather clear warning if you try to unref an already free'd object [08:50] (on stderr) [08:50] s/warning/critical/ [09:05] morning desktopperinos [09:06] Laney, hey [09:06] larsu, there? [09:06] * seb128 wonders wth about this code [09:20] seb128: now I am [09:20] * larsu was up long last night [09:20] larsu, good morning! [09:21] larsu, the issue is the g_object_unref (file); in l308 [09:21] seb128: wait, are we talking about the same thing here as in #ubuntu-unity? [09:21] larsu, I knew I should have waited for you to be around, that you fix it easily :p [09:21] * seb128 just spent 30min looking to the changes to come to the conclusion you had directly :-( [09:22] larsu, yes, we moved there because pitti reported the issue as well [09:23] seb128: I wonder how this wasn't a problem during my testing [09:23] * seb128 gets the bug as well since today's update [09:23] larsu, yeah, me too :/ [09:23] larsu, it segfaults every time there is a as refresh it seems [09:23] I can trigger by calling SetIconFile in dfeet [09:23] or just by waiting a bit [09:26] ah, doesn't happen in the loader… [09:26] oh, it does when closing it :) [09:26] larsu, you didn't test the changes on your real session? no cookie :p [09:27] :'( [09:27] larsu, you can still get cookies by get a fix up for review ;-) [09:27] * seb128 hugs larsu [09:27] \o/ [09:28] larsu, bug #1248446 if you want a bug reference [09:28] Launchpad bug 1248446 in ido (Ubuntu) "unity-panel-service crashed with SIGSEGV in g_object_unref()" [High,Confirmed] https://launchpad.net/bugs/1248446 [09:31] seb128: thanks. https://code.launchpad.net/~larsu/ido/remove-superfluous-unref/+merge/194088 [09:32] tsdgeos, pitti: sorry for that crash :/ (and thanks for tracking it down) [09:32] larsu: no worries [09:33] it took me a while to see it was crashing for how fast it restarts, but the konsole area was shirking/enlarging when switching tabs, and there's been no konsole update so i thought "WHAT?¿?" [09:33] larsu, I wish the glib documentation was better about those things, I looked at it earlier but "transfer-none" doesn't speak to me [09:34] seb128: you should learn those, they're all over the docs. I agree its not very intuitive, but it's _very_ consistent [09:34] transfer-none: ownership is not transferred in any way (no freeing/unreffing) [09:34] larsu, I though they were tags for gir, not human documentation :p [09:34] transfer-full: free all the things you get back [09:35] transfer-container: free the passed back array/list, but not its contents [09:35] seb128: they're used for both :) [09:35] larsu, thanks for the explanations ;-) [09:35] larsu, btw I set the commit message on the mr (and fixed the "trans*f*er-none" typo) [09:36] tsdgeos: I've long been a proponent of _not_ restarting things that crash so that it's more noticable. I'm very alone with that opinion though [09:36] and I can understand the other side of it [09:36] seb128: oh, thanks! [09:36] yeah [09:37] larsu: for devels it's better the permanent crash, for Joe User it's better the restart [09:37] i guess [09:37] maybe we should only enable restarting on releases? [09:38] larsu, what would we win of not restarting? [09:38] that wouldn't give us more infos on the segfault [09:39] but it would let those of us who run $unstable without a working desktop [09:39] it seems getting the annoyance for no benefit [09:39] people would complain louder [09:39] seems like many just click away the crash reporter [09:39] but yeah, I totally see your point about a working system [09:40] you can't really "click away the reporter", since closing it submits by default (you have to uncheck before closing to don't report) [09:40] larsu, the current system didn't stop you to have several users reporting the issue the day the bug landed as well... [09:41] ha, fair enough [09:41] but they still had to revert to a lower version [09:41] sil2100, can we get a new ido landing once https://code.launchpad.net/~larsu/ido/remove-superfluous-unref/+merge/194088 is in trunk? [09:42] seb128: I think we can do that, let me keep that on the radar [09:43] sil2100, ok, earlier is better, unity-panel-service keeps segfaulting with yesterday's update which is going to be annoying for trusty users [09:43] lol, "trusty users" [09:44] ;) [09:44] ;-) [09:44] seb128: if I would miss the moment when it's merged in, please poke me if you can [09:44] larsu, best release codename ever :p [09:44] And I'll spin stuff [09:44] sil2100, ok [09:53] sil2100, it's merged [10:02] mlankhorst: ping regarding bug #1244324 [10:02] Launchpad bug 1244324 in glamor-egl (Ubuntu) "glamor-egl crashes when running autopilot tests" [High,In progress] https://launchpad.net/bugs/1244324 [10:03] mlankhorst: can you get the fix in ubuntu while it's dealt it upstream so we can restore the ci service ? [10:03] *dealt with [10:04] patience ;) [10:04] https://launchpad.net/ubuntu/+source/glamor-egl/0.5.1-0ubuntu6 [10:05] mlankhorst: wow, magic ! [10:05] should autoclose the bug in an hour or so [10:05] ohhhhh [10:07] seb128: ok, spinning! [10:07] sil2100, thanks [10:58] mlankhorst: hmm, I'm not sure I understand, none of xserver-xorg-glamoregl libglamor0 libglamor-dev in installed on qa-radeon-7750 [11:00] mlankhorst: did your fix propagates somewhere else I should look for ? [11:01] vila: 7750 is radeonsi right? [11:01] xserver-xorg-video-ati pulls it in [11:02] not installed either [11:02] err wait [11:02] wait wait wait [11:02] ;) [11:03] I'm looking at the host not at the container ;) scratch everything I said in the last minutes ;) [11:04] I had a feeling [11:05] considering 7750 wouldn't work otherwise [11:06] bah, hate tests [11:07] gdk-pixbuf fails to build due to tests, of course it works locally [11:07] ;) [11:07] https://launchpadlibrarian.net/155950592/buildlog_ubuntu-trusty-i386.gdk-pixbuf_2.30.0-0ubuntu1_FAILEDTOBUILD.txt.gz [11:07] tried on a i386 chroot? [11:07] I should [11:08] it looks like they might be running installed-tests are build-time [11:08] or at least relying on the package to be installed [11:09] seems that way [11:10] mlankhorst: yeah, xserver-xorg-glamoregl installed in the container [11:10] seb128: yeah same failure here in a pbuilder [11:10] mlankhorst: but I'm hitting a different bug so will need to tweak before confirming your fix ;) [11:12] ERROR:animation.c:11:test_animation: assertion failed (error == NULL): Couldn't recognize the image file format for file '/tmp/buildd/gdk-pixbuf-2.30.0/tests/test-animation.gif' (gdk-pixbuf-error-quark, 3) [11:12] after i created the file it asked for, but empty [11:12] mlankhorst, it seems to be because it looks for the loader in the system location [11:13] yeah [11:13] I'm pondering just disabling the tests :p [11:13] but Laney and pitti are going to look angry at me if I do that [11:13] seb128: convert to autopkgtest or figure out how to override it? [11:13] :> [11:14] * Laney stares [11:14] or define failure as another way to succeed. should be laney approved [11:15] that's going to teach me to update to new versions when they seem fine, it was mostly new tests there [11:15] go ask mclasen, he fiddled with that stuff [11:16] https://bugzilla.gnome.org/show_bug.cgi?id=703012 [11:16] Gnome bug 703012 in general "make check fails: Cannot open pixbuf loader module file '.../gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory" [Normal,Unconfirmed] [11:16] seb128: that doesn't fail on a local build? [11:16] seems strange [11:16] it doesn't sound very sensitive to a buildd environment [11:16] pitti: not really, it can use the system version to test [11:16] pitti, it doesn't fail on my system which has gdk-pixbuf installed [11:16] it fails in a clean chroot [11:16] oh, you didn't build in sbuild/chroot/pbuilder, I figure [11:16] no I didn't [11:17] I can't be bother to test build everything in pbuilder :p [11:17] (that's what I get in return :/) [11:17] sbuild == ♥ :) [11:17] * seb128 needs a bigger disk than 80G [11:17] well, sbuild + apt-cacher-ng + lots of RAM and building everything in /tmp, that is (/tmp on tmpfs) === alan_g is now known as alan_g|afk [11:18] hehehhehe [11:19] pbuilder-dist + 16 gb ram to build in works for me [11:20] I think you need to set GDK_PIXBUF_MODULEDIR [11:20] after I modded pbuilder to kill the archives after installing deps, before building, using 8 gb for copies of archive was a recipe for disaster [11:20] for the testsuite [11:21] Laney: maybe, but the testsuite should do that upstream [11:21] ?!?!?!?! [11:22] of course, any fix is going to be an upstream fix [11:25] Laney, do you want to have a look at it, since it seems you already have an idea what to do? ;-) [11:25] I don't :P [11:25] I just looked at the manpage for gdk-pixbuf-query-loaders === alan_g|afk is now known as alan_g [11:38] sil2100, what happened to the ido landing? [11:39] seb128: the indicator stack is running, when it is done we can release [11:40] sil2100, ok, that's taking ages it seems [11:40] on that note, lunch [11:40] bbiab [11:40] seb128: yes, it was like that since all the stacks got ran, and this meant that indicators wasn't allowed to run by itself and was halted by waiting on other dependent stacks to finish [11:41] seb128: so platform had to be built first etc... [11:41] seb128: there was no way of dealing with this without breaking the stack builds that others prepared [11:57] sil2100, ok, well as long as it lands soon that's ok [11:58] sil2100, it would be nice if the fix was in by the time the US wakes up and start upgrading ... which is soon ... do you know when the stack is going to be ready? [11:58] seb128: sorry about that in overall, hope we'll release it in like 15 minutes or such [11:58] ok === MacSlow is now known as MacSlow|lunch [12:08] oh [12:08] I got the tests to pass [12:09] now to see where to insert that into the build system [12:20] Laney, gdk-pixbuf? [12:20] ye [12:20] oh, great ;-) [12:20] it was what I said [12:20] I was just about to start looking at it, I though said "no" earlier [12:20] thanks ;-) [12:20] yeah, I did [12:20] but then I thought "oh, I'll just try it quickly" [12:21] ;-) [12:21] sil2100: please don't land anything that is installed on touch [12:21] seb128: what about the ido landing? [12:22] is there a regression? [12:22] didrocks, the landing from yesterday makes unity-panel-service segfaults every few minutes [12:22] * sil2100 checks for ido in the touch [12:22] sil2100: it is in touch [12:22] didrocks, that's fixed in trunk, I really want that to land before U.S wake up/upgrade [12:22] seb128: well, we can as well backout [12:22] I first want to know if ido is what is getting one indicator crazy [12:22] didrocks, "backout"? [12:22] (the name is cut) [12:22] revert to previous ido [12:22] shrug [12:23] the fix is a one liner [12:23] it seems it wasn't network-manager [12:23] dropping an incorrect g_free [12:23] hm, I was really sure that ido had nothing to do with touch [12:23] seb128: yeah, but we have no idea if ido is what making all touch testss failing [12:23] didrocks, I fail to see how ido could be used on the phone [12:23] sil2100: ok, do you have any other idea? [12:23] seb128: I just know it is in the phone by a dependency, I'm unsure if it's loaded or not [12:23] didrocks, that doesn't make any sense to me, I checked the rdepends, no phone component uses it [12:24] didrocks, do you have a log/error from a failing test? [12:24] didrocks, what components have failing tests? [12:24] seb128: it's not a failing tests, it's one indicator going crazy [12:24] taking all CPU [12:24] which one? [12:24] and so a lot of tests failing [12:24] indicator-* [12:25] it's truncated, as said [12:25] oh, "fun" [12:25] indeed [12:25] I was hoping for indicator-network [12:25] is there any way to untruncate? [12:25] as we got a network-manager update [12:25] seb128: not that I know of [12:25] didrocks, what's the diff between not-buggy and buggy? [12:25] seb128: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes [12:26] hmm [12:26] psivaa downgraded all nm component [12:26] we still have this indicator [12:26] hum [12:26] didrocks, can somebody reproduce the issue on an actual device? [12:26] psivaa: can you try downgrading ido? [12:27] seb128: https://jenkins.qa.ubuntu.com/job/trusty-touch-maguro-smoke-ubuntu-rssreader-app-autopilot/9/artifact/clientlogs/top_before.log/*view*/ [12:27] sil2100: already what I asked 10 minutes ago [12:27] seb128: see different top run (for 2 minutes) [12:27] seb128: we are trying on the test env directly now [12:27] easier to rerun the tests [12:27] didrocks, if an actual human could reproduce on a device where we can adb to that would be useful [12:27] sil2100: downgraded to 13.10.0+13.10.20131031-0ubuntu1 and running a test now [12:28] psivaa: thanks! [12:28] didrocks, psivaa, sil2100: do you have an uptodate device? what is apt wanting to do if you apt-get remove libido3-0.1-0 [12:28] ? [12:28] system settled. SUCCESS [12:28] * seb128 has saucy still there, needs to upgrade [12:29] seb128: no, I don't have it handy, trying to get back production working first [12:29] didrocks, what does "system settled. SUCCESS" means? [12:29] seb128: that the system was "quiet enough" [12:30] didrocks, e.g that the ido downgrade fixes the issue? [12:30] which should indicate that the indicator wasn't at that CPU % usage [12:30] maybe, I want multiple runs before affirming it's the case [12:33] seb128: seems to indicate ido is guilty: http://10.97.0.1:8080/job/trusty-touch-maguro-smoke-ubuntu-calculator-app-autopilot/12/artifact/clientlogs/top_before.log [12:33] see the last top run [12:33] no indicator* [12:34] psivaa: running others? [12:35] didrocks, so it's unity-services which brings ido on the image [12:35] seb128: but unity-services isn't started, right? [12:35] on the device [12:35] didrocks, well, if it's not a fail to see how ido can impact on indicators :/ [12:36] seb128: let's see with other runs, but at least, if we identify that one as being the cause… there is clearly something to look into [12:36] didrocks, can you see if unity-panel-service is running on that test machine? [12:36] psivaa: you are the one connected ^ [12:36] sil2100, meanwhile please publish the new ido [12:37] that can't hurt [12:37] if we need to do a revert we can still do it [12:37] but at least we don't stay on a buggy version while deciding on the revert [12:37] sil2100: no, please don't publish it [12:37] grrrr [12:37] I would rather go with a backout versoin [12:37] * seb128 manual upload [12:37] seb128: come on, you screw us [12:37] didrocks, and you screw us [12:37] so please try to be cooperative [12:37] difference is that desktop is in production [12:37] seb128: I wasn't the one pushing a broken version to the archive [12:38] where your image doesn't reach users [12:38] seb128: yeah, so let's rollback [12:38] I'm happy to handle that rollback [12:38] didrocks, that version is not broken afaik, but it seems unity8 is doing something weird trying to load gtk components [12:38] seb128: well, we don't know, you thought yesterday's version wasn't broken [12:39] and it segfaults [12:39] you better fix whatever tries to load a gtk library [12:39] so I'm trying the safest path for now [12:39] didrocks, still, something on the device is doing something stupid [12:39] didrocks, and you better get at the bottom of it [12:39] seb128: I don't say the contrary [12:39] seb128: *but* we are doing a complex 1.4 AP transition [12:39] I still don't have a status on the 1.3 last release because of this [12:40] so let's get some other test runs [12:40] (and no, no unity-panel-service is running now on my device with a recent image) [12:40] didrocks, I guess no indicator is using 100% cpu either? [12:41] seb128: I don't have latest [12:41] seb128: sorry, but keep being interrupted, even no coffee from this morning [12:41] mostly because of that issue [12:41] didrocks, stop starting IRC before coffee! [12:42] that's not related to it [12:42] * seb128 installs new ido on his saucy [12:43] psivaa: around at all? [12:43] seb128: didrocks: so with nm downgraded (maguro) i still see some systemsettle failures. but with ido downgraded (mako) i see some improvements [12:43] didrocks: yes, the tests take time to run :) [12:43] psivaa: how many tries with ido downgraded? [12:43] just one or more? [12:43] psivaa, "some improvements" or "it's fixed"? [12:44] didrocks: seb128: one test, still running [12:44] psivaa, can you "grep ido /proc/*/maps" [12:44] and see if that returns something? [12:45] (flashed latest image and of course, can't reproduce…) [12:45] * sil2100 is confused [12:45] didrocks, ok, so you want to revert ido in trusty now? [12:45] seb128: I wish we can wait for 30 minutes to get more results [12:45] I'll just get back to fixing AP issues maybe... ;) [12:45] * sil2100 walks away silently [12:45] didrocks, well, if we wait for 30 min we can land the segfault fix, so it's in, then we can revert [12:45] if needed [12:46] * seb128 doesn't get what blocking the 1 liner segfault fix brings us [12:46] seb128: as you wish, but if we see that ido is really the faulty one, I don't want that we wait for testing the ido fix, agreed? [12:46] seb128: i ran that command on both devices and both return nothing [12:46] didrocks, sure [12:47] sil2100: ok, please release this ido ^ know that we maybe we'll revert all ido soon though [12:48] didrocks, I've installed the new ido on my device (saucy) and it creates no issue [12:48] psivaa: what do we have on mako? [12:49] didrocks: downgraded ido [12:49] downgraded network-manager as well? [12:49] didrocks: no [12:49] ok, so calendar-app seems to show that ido is really guilty [12:49] really really weird… [12:50] didrocks, calendar-app?! wth... [12:50] seb128: the test of calendar-app (systemsettle one) [12:50] seb128: basically ALL tests were screwed because of this indicator [12:51] seb128: http://reports.qa.ubuntu.com/smokeng/trusty/touch/ [12:51] didrocks, calendar-app is not an indicator though [12:51] http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/12:20131105:20131031.1/4903/ [12:51] seb128: yeah, but if an indicator is using all the CPU… [12:51] the tests will fail [12:51] ok [12:51] 67% of mem for an indicaotr [12:52] how do we go about debugging the issue next? [12:52] seb128: so, if it's not ido as it seems it can't, if it's not netowkr-manager, what can it be? [12:52] can we figure out what loads ido [12:52] and what indicator uses the cpu? [12:53] seb128: I guess that's more a question for upstream to figure it out [12:53] didrocks, we had an unity8 landing, did we rul that one to be buggy? [12:53] right now, I'm trying to ensure we find the right guilty [12:53] didrocks, or are we sure than downgrading ido is workaround it? [12:53] seb128: it can be unity8, indeed [12:53] seb128: what I'm telling, I'm not ensured it's ido right now [12:53] didrocks, also, whoever "downgraded nm", did they include the libs or just the network-manager binary? [12:54] seb128: psivaa told me he dowgraded all binaries from nm source [12:54] ok [12:54] if only we knew which indicator was at fault… [12:55] where is the script doing the top? can we tweak it? [12:55] seb128: we can tweak it, do you know what's the parameter for top to not truncate? [12:55] it's in utah test suite [12:55] seb128, didrocks: ido publishing [12:56] didrocks: seb128: http://pastebin.ubuntu.com/6370333/ is the nm related packages in the nm downgraded device [12:56] sounds like the whole selection [12:56] system settled. SUCCESS [12:56] with friends tests [12:56] on mako [12:56] (with thus only ido downgraded) [12:57] didrocks: yes [12:57] so 3 on 3 runs? === alan_g is now known as alan_g|lunch [12:59] seb128: ido should be in soon [13:00] local run on a really fresh install -> nothing [13:02] * didrocks wonders why he's the only one caring about this [13:02] ok, giving up… [13:02] didrocks, top -b -n1 -c > log [13:02] didrocks, that gives non truncated commands [13:03] didrocks, sorry was googling for the top truncating === Rodge is now known as Rodge_ [13:05] Laney, thanks for the gdk-pixbuf fix! [13:05] didrocks: terminal app tests, systemsettle success: http://10.97.0.1:8080/job/trusty-touch-mako-smoke-ubuntu-terminal-app-autopilot/15/console [13:05] which earlier failed with the latest ido [13:05] seb128: np! [13:06] don't really understand these new test harnesses [13:06] so I have trusty/13 on my mako [13:06] psivaa: ok, continue running mako with this ido downgraded, let's try to reflash maguro [13:06] how do I get this bug? [13:07] didrocks: do you want me to get maguro with the latest image and downgrade ido as well? [13:07] Laney: I don't get it as well, locally [13:07] psivaa: no, just get latest image on maguro, then, let me give you a branch so that we know which indicator is failing [13:08] didrocks: ack [13:08] psivaa: can you apply that to the systemsettle script branch? http://paste.ubuntu.com/6370377/ [13:08] hopefully, the command name won't be truncated anymore [13:09] so that we see what indicator is guilty [13:09] (so just run one test) [13:09] then, let's downgrade ido [13:09] didrocks: ack [13:09] and retry all tests on maguro as well [13:11] are there any crash files? [13:12] Laney: none from the dashboard. For instance: http://reports.qa.ubuntu.com/smokeng/trusty/touch/maguro/12:20131105:20131031.1/4905/ubuntu-terminal-app-autopilot/ [13:12] mmm [13:15] seb128: I don't htink that will work through adb though [13:15] didrocks, the top? [13:16] yep [13:16] because of adb TERMCAP [13:16] just try adb shell [13:16] and your command [13:16] -> see top being truncated [13:17] didrocks, COLUMNS=900 top -b -n1 -c > log [13:17] that works [13:18] psivaa: mind prepending this COLUMNS=900 as well? [13:18] seb128: nice catch [13:18] didrocks: ack will do. the flashing ongoing btw for maguro [13:18] btw: [13:19] phablet@ubuntu-phablet:~$ aptitude why libido3-0.1-0 [13:19] i ubuntu-touch Depends unity8 [13:19] i A unity8 Depends unity8-private (= 7.83+14.04.20131105.1-0ubuntu1) [13:19] i A unity8-private Depends libunity-core-6.0-8 (>= 7.0.0) [13:19] i A libunity-core-6.0-8 Depends unity-services (= 7.1.2+13.10.20131014.1-0ubuntu1) [13:19] i A unity-services Depends libido3-0.1-0 (>= 13.10.0daily13.06.19) [13:19] ahah, so unity8 is using it [13:19] yeah but [13:19] libunity-core-6.0-8 doesn't start unity-services [13:19] it's probably unused [13:19]