[07:54] hi there release folks! can anyone spare some time to look at my HUD upoad in trusty? === med_ is now known as 1JTAAEE11 === ogra_ is now known as 1JTAAEF0J === ogra_ is now known as 1JTAAEF3J [10:16] How to force-sync libusbmuxd from sid into utopic-proposed? src:usbmuxd got split into two src packages in debian and we want to sync both across. === Ursinha-afk is now known as Ursinha [14:44] infinity: hi! Are you around by any chance? Our standard core-dev responsible for CI Train packaging ACKs is off and we would need someone to +1/-1 a change before publication :) [14:44] infinity: would you have a moment for that? [14:44] Oh, and actually I need some archive admin as well [14:45] what's the change? [14:46] cjwatson: it's a big diff, I already browsed through it and it looked safe: https://ci-train.ubuntu.com/job/landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_webbrowser-app_0.23+14.10.20140609-0ubuntu1.diff [14:46] cjwatson: there is a new binary package there as well [14:47] sil2100: Is libqt5sql5-sqlite some kind of plugin that can't be detected with shlibdeps? [14:49] cjwatson: oh, I actually mis-read that for QML bindings, but I see now that it's actually a normal lib, hm [14:49] cjwatson: let me check that up [14:49] sil2100: qtdeclarative5-ubuntu-web-plugin being Multi-Arch: same looks very fishy; it's not structured like a usual M-A: same package [14:49] sil2100: wait, belay that, I'm reading the wrong bit of the file listing [14:52] sil2100: ack (both ~ubuntu-core-dev and ~ubuntu-archive) - I think this is fine [14:52] just double-check that there isn't a better way to do the libqt5sql5-sqlite dep [14:53] cjwatson: I can poke the upstream developer about that libqt5sql5-sqlite dep, but since I don't see it in any CMake files, I think it might not be easily detectable [14:53] oh, -sqlite is in fact a plugin [14:53] I can't remember how Qt DB support works, but it might be plugin-based [14:54] cjwatson@pepo:~$ dpkg -c ubuntu/pool/main/q/qtbase-opensource-src/libqt5sql5-sqlite_5.2.1+dfsg-1ubuntu17_i386.deb | fgrep .so [14:54] -rw-r--r-- root/root 51196 2014-05-13 05:43 ./usr/lib/i386-linux-gnu/qt5/plugins/sqldrivers/libqsqlite.so [14:54] that's fairly clear :) [14:54] cjwatson: thanks for the review :) [14:54] o/ [14:54] and no shlibs control file in the .deb, so there won't be a better option for this [14:54] glad to see the new-binary-package check in citrain there [14:55] Yeah, I added that since it was really easy to forget about archive-admin-poke whenever a new binary package pops up [14:56] Hopefully I'll figure out the remaining issues with my copies-respect-new branch this week [14:57] If I can remember what my plan for fixing the ancestry calculation was [15:06] slangasek: I've checked the errors you pointed out last week, that seems to be related to the latest unity SRU, but really nothing changed on our code might cause them... :/ [15:06] was the security uploaded package already tracked for these errors, right? [15:39] Trevinho: I believe the security pocket also gets error reports against it, yes; in any case, that security update had also been copied to -updates and was there for a month, so definitely would have had crash reports against in [15:40] s/in$/it/ [15:42] Trevinho: could this have been caused by code changes nearby that changed the stack signature of an existing crash? [15:52] slangasek: mh, I'd say no as nothing seems related to these calls... but I'd wait for better stack trace since the ones we have are partially incomplete [15:53] and anyway while one crash can be avoided (as it's triggered by gdk on X errors), the other one is really happening when setting up the the unity super short-cuts which are there since years [15:53] Trevinho: what trace is partially incomplete? You're not going to have a better stack trace coming [15:55] slangasek: https://errors.ubuntu.com/problem/8fc148da910ae3d63758f6e96174a502860a6b95 [15:55] slangasek: there are no nuch infos about the unity code [16:00] Trevinho: right, but there's not going to be a better backtrace coming either. I don't know why it's giving "no symbol table info available" for the unity calls... [16:00] bdmurray: ^^ do you know if this is related to ddeb availability? [16:01] I would have thought that, without ddebs, it would refuse to retrace at all [16:02] slangasek: there is a similar issue also in other errors (such as https://errors.ubuntu.com/problem/1e4a09ec7376628035e64b1600bef4e3c5b36d93 ) [16:02] that's still from 13.10 [16:03] slangasek: not off the top of my head, but the stacktrace on a bucket page is the first one that did retrace [16:03] slangasek: I think bjoern mentioned something about the line numbers being off in his email to ubuntu-devel - that's the same issue [16:04] well, in this case the crash has only ever been seen in a single versino [16:04] version [16:05] the fact that the backtrace includes a function name for the unity components implies that it's getting at least some debugging information [16:24] slangasek: I'm bit involved in the cassandra migration at the moment. Maybe its some non standard compiz plugin? [16:24] bdmurray: the missing symbols relate to the unity .so itself [16:25] but maybe they're not actually "missing", I'm not sure [16:27] slangasek: this is the problem yes? https://errors.ubuntu.com/problem/8fc148da910ae3d63758f6e96174a502860a6b95 [16:27] bdmurray: yeah [16:28] and lines 26,27,31,32 are the concerns? [16:28] or something else? [16:29] bdmurray: those addresses are clearly outside of any DSO; the bit I was looking at was frame 9, "No symbol table info available" [16:29] but maybe Trevinho was talking about 26,27,31,32 [16:30] Trevinho: ? [16:31] slangasek: mostly 9 [16:31] ok [16:35] slangasek: as basically all the reports we get about unity don't include local variables or line numbers [16:38] it'd be interesting to know if that is true in Launchpad too [16:38] bdmurray: generally stacktraces in lp are more informative [16:40] Trevinho: an example would be helpful [17:00] Okay, I found one [17:04] bdmurray: ok, nice as the lp timeouts were blocking my searches here :/ [17:05] bug 1328180 [18:03] Trevinho: yet another new crash: https://errors.ubuntu.com/problem/f5a955d67c42bb688386e1fa695af37cfe9ee20a [18:04] same issue with symbol table info [18:05] I wonder if this is something about the way unity is built [18:05] slangasek: I've no idea... these stacks also seems to be unrelated... [18:05] I mean, I get the computeGlowQuads call and then the Launcher::EmitEneedsRedraw but there's really no connection or call path between them [18:06] nor with the final destructor... It looks like there's something messed up with the stack [18:07] and still there are a lot of missing intermediate frames... [18:09] also I don't think we changed the way we build unity.. [18:09] bregma: any idea? [18:10] we definitely didn;t change anything in the way we build things [18:10] other than using ci-train instead of a distro builder [18:11] I suppose that could make some sort of difference, but is beyond my kenning [18:11] yeah, the same I knew... But these errors are quite weird... Nothing seems related to anything changed. And also inside the errors themselves there are unknown code paths [18:17] well, I don't know that it's a matter of the unity build having /changed/. Were you previously getting better backtraces from errors.u.c? [18:18] this latest one shows a code path that goes via __GI___pthread_mutex_lock, that certainly looks dodgy [18:18] The bug I reported (1328180) has something and examples in it [18:25] bdmurray: when you say "done against (13.10|14.04)", is that about the versions of the packages being retraced, or the version of gdb, or both? [18:25] the former for sure, the latter I'm not certain === ogasawara_ is now known as ogasawara