[07:54] <pete-woods> hi there release folks! can anyone spare some time to look at my HUD upoad in trusty?
[10:16] <xnox> 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.
[14:44] <sil2100> 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] <sil2100> infinity: would you have a moment for that?
[14:44] <sil2100> Oh, and actually I need some archive admin as well
[14:45] <cjwatson> what's the change?
[14:46] <sil2100> 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] <sil2100> cjwatson: there is a new binary package there as well
[14:47] <cjwatson> sil2100: Is libqt5sql5-sqlite some kind of plugin that can't be detected with shlibdeps?
[14:49] <sil2100> cjwatson: oh, I actually mis-read that for QML bindings, but I see now that it's actually a normal lib, hm
[14:49] <sil2100> cjwatson: let me check that up
[14:49] <cjwatson> 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] <cjwatson> sil2100: wait, belay that, I'm reading the wrong bit of the file listing
[14:52] <cjwatson> sil2100: ack (both ~ubuntu-core-dev and ~ubuntu-archive) - I think this is fine
[14:52] <cjwatson> just double-check that there isn't a better way to do the libqt5sql5-sqlite dep
[14:53] <sil2100> 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] <cjwatson> oh, -sqlite is in fact a plugin
[14:53] <sil2100> I can't remember how Qt DB support works, but it might be plugin-based
[14:54] <cjwatson> cjwatson@pepo:~$ dpkg -c ubuntu/pool/main/q/qtbase-opensource-src/libqt5sql5-sqlite_5.2.1+dfsg-1ubuntu17_i386.deb | fgrep .so
[14:54] <cjwatson> -rw-r--r-- root/root     51196 2014-05-13 05:43 ./usr/lib/i386-linux-gnu/qt5/plugins/sqldrivers/libqsqlite.so
[14:54] <cjwatson> that's fairly clear :)
[14:54] <sil2100> cjwatson: thanks for the review :)
[14:54] <sil2100> o/
[14:54] <cjwatson> and no shlibs control file in the .deb, so there won't be a better option for this
[14:54] <cjwatson> glad to see the new-binary-package check in citrain there
[14:55] <sil2100> Yeah, I added that since it was really easy to forget about archive-admin-poke whenever a new binary package pops up
[14:56] <cjwatson> Hopefully I'll figure out the remaining issues with my copies-respect-new branch this week
[14:57] <cjwatson> If I can remember what my plan for fixing the ancestry calculation was
[15:06] <Trevinho> 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] <Trevinho> was the security uploaded package already tracked for these errors, right?
[15:39] <slangasek> 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] <slangasek> s/in$/it/
[15:42] <slangasek> Trevinho: could this have been caused by code changes nearby that changed the stack signature of an existing crash?
[15:52] <Trevinho> 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] <Trevinho> 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] <slangasek> Trevinho: what trace is partially incomplete?  You're not going to have a better stack trace coming
[15:55] <Trevinho> slangasek: https://errors.ubuntu.com/problem/8fc148da910ae3d63758f6e96174a502860a6b95
[15:55] <Trevinho> slangasek: there are no nuch infos about the unity code
[16:00] <slangasek> 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] <slangasek> bdmurray: ^^ do you know if this is related to ddeb availability?
[16:01] <slangasek> I would have thought that, without ddebs, it would refuse to retrace at all
[16:02] <Trevinho> slangasek: there is a similar issue also in other errors (such as https://errors.ubuntu.com/problem/1e4a09ec7376628035e64b1600bef4e3c5b36d93 )
[16:02] <Trevinho> that's still from 13.10
[16:03] <bdmurray> slangasek: not off the top of my head, but the stacktrace on a bucket page is the first one that did retrace
[16:03] <bdmurray> 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] <slangasek> well, in this case the crash has only ever been seen in a single versino
[16:04] <slangasek> version
[16:05] <slangasek> 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] <bdmurray> slangasek: I'm bit involved in the cassandra migration at the moment. Maybe its some non standard compiz plugin?
[16:24] <slangasek> bdmurray: the missing symbols relate to the unity .so itself
[16:25] <slangasek> but maybe they're not actually "missing", I'm not sure
[16:27] <bdmurray> slangasek: this is the problem yes? https://errors.ubuntu.com/problem/8fc148da910ae3d63758f6e96174a502860a6b95
[16:27] <slangasek> bdmurray: yeah
[16:28] <bdmurray> and lines 26,27,31,32 are the concerns?
[16:28] <bdmurray> or something else?
[16:29] <slangasek> 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] <slangasek> but maybe Trevinho was talking about 26,27,31,32
[16:30] <slangasek> Trevinho: ?
[16:31] <Trevinho> slangasek: mostly 9
[16:31] <slangasek> ok
[16:35] <Trevinho> slangasek: as basically all the reports we get about unity don't include local variables or line numbers
[16:38] <bdmurray> it'd be interesting to know if that is true in Launchpad too
[16:38] <Trevinho> bdmurray: generally stacktraces in lp are more informative
[16:40] <bdmurray> Trevinho: an example would be helpful
[17:00] <bdmurray> Okay, I found one
[17:04] <Trevinho> bdmurray: ok, nice as the lp timeouts were blocking my searches here :/
[17:05] <bdmurray> bug 1328180
[18:03] <slangasek> Trevinho: yet another new crash: https://errors.ubuntu.com/problem/f5a955d67c42bb688386e1fa695af37cfe9ee20a
[18:04] <slangasek> same issue with symbol table info
[18:05] <slangasek> I wonder if this is something about the way unity is built
[18:05] <Trevinho> slangasek: I've no idea... these stacks also seems to be unrelated...
[18:05] <Trevinho> 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] <Trevinho> nor with the final destructor... It looks like there's something messed up with the stack
[18:07] <Trevinho> and still there are a lot of missing intermediate frames...
[18:09] <Trevinho> also I don't think we changed the way we build unity..
[18:09] <Trevinho> bregma: any idea?
[18:10] <bregma> we definitely didn;t change anything in the way we build things
[18:10] <bregma> other than using ci-train instead of a distro builder
[18:11] <bregma> I suppose that could make some sort of difference, but is beyond my kenning
[18:11] <Trevinho> 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] <slangasek> 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] <slangasek> this latest one shows a code path that goes via __GI___pthread_mutex_lock, that certainly looks dodgy
[18:18] <bdmurray> The bug I reported (1328180) has something and examples in it
[18:25] <slangasek> 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] <bdmurray> the former for sure, the latter I'm not certain