[04:44] <pitti> Good morning
[04:45] <pitti> slangasek: udev sru> wiki page says "one week without a regression report" (of which we didn't get any, I'm subscribed to udev bugs)
[04:45] <pitti> slangasek: lp retracers> mostly me; unfortunately the failure cron mail sometimes doesn't get set, so I don't notice errors often
[04:46] <pitti> slangasek: restarting i386 one, it indeed was crashed
[04:46] <pitti> gdb segfaulted, yay
[04:48] <pitti> slangasek: we don't stop them on transient LP bugs any more, I fixed that ages ago
[04:48] <pitti> but for anything unexpected we do, but I need to get told about them
[04:48] <pitti> slangasek: so the uninvestigated issue is "sometimes cron mail doesn't get sent" :/
[05:08] <robert_ancell> pitti, I think I remember you complaining about the autotools tests no longer producing output on server builds - did you ever come up with a clever solution for that?
[05:09] <robert_ancell> The dreaded see tests/test-suite.log which you can't see
[05:11] <pitti> robert_ancell: for umockdev I just switched back to the serial test runner
[05:11] <robert_ancell> pitti, what is the incantation for that?
[05:11] <pitti> robert_ancell: for debian/rules you might use something like "dh_auto_test || { cat testsuite.log; exit 1 }
[05:11] <pitti> but that's unwieldy for upstream
[05:12] <robert_ancell> pitti, ah, I was trying to do that but my shell-fu failed me
[05:12] <pitti> robert_ancell: add "serial-tests" to AM_INIT_AUTOMAKE
[05:12] <pitti> robert_ancell: but hang on, I actually removed that again, as with that you can't build on automake 1.11 and older any more
[05:13] <pitti> robert_ancell: so now I don't use the AM test runner at all, and do it by hand: https://github.com/martinpitt/umockdev/commit/25c46869f18
[05:18] <cjwatson> I think the parallel runner is enough of a good thing that it's worth small workarounds such as the above || { ... } hack to continue being able to use it.
[05:18] <pitti> I didn't find an equivalent for that for upstream Makefile.am, though
[05:18] <robert_ancell> cjwatson, yeah, I like it too :)
[05:19] <cjwatson> pitti: https://lists.gnu.org/archive/html/automake/2013-06/msg00051.html ?
[05:20] <cjwatson> Though I guess that requires that target to be invoked explicitly
[05:21] <pitti> the "display-testsuite-logs" looks like a manual one
[05:21] <pitti> and "require am >= 1.12" is not an option
[05:21] <pitti> as I want this to work in daily PPA builds
[05:21] <pitti> and also don't fend off developers on stable releases
[05:28] <cjwatson> pitti: Actually, doesn't VERBOSE = yes work for you?  AFAICT it only doesn't work for James' quite specialised requirement that he wants to show the test log even for passed tests
[05:29] <pitti> cjwatson: I'll try that (need to run off for a bit)
[05:33] <TheMuso`> c
[06:00] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203211 => Somebody can check this out ? :)
[06:37] <pitti> cjwatson: adding "VERBOSE = yes" to Makefile.am has no visible effect here
[06:38] <pitti> "make check VERBOSE=yes" seems to  help, though
[06:39] <pitti> ah, "export VERBOSE = yes" helps
[06:41] <cjwatson> Right, it's used as a shell variable not a make variable
[06:56] <pitti> wgrant_: hm, still nothing on https://translations.launchpad.net/ubuntu/saucy/+language-packs ?
[08:15] <Laney> @pilot in
[08:41] <jamespage> doko, available for a chat re go policies?
[08:45] <doko> jamespage, in 15min, need a coffee ....
[10:21] <ejat> friends-app : Depends: qtdeclarative5-hud1.0 but it is not installable
[10:21] <ejat> ?
[10:31] <infinity> ejat: Are you running -proposed?  friends-app installs fine here on saucy without proposed.
[10:31] <infinity> ejat: If you're using proposed, don't. :P
[11:51] <doko> mlankhorst, ping
[11:54] <doko> tjaalton, ping
[11:59] <mlankhorst> pong
[11:59] <mlankhorst> what's up
[12:07] <doko> mlankhorst, please see message
[12:14] <Laney> @pilot out
[13:15] <seb128> apw, hey, thanks for the lightdm patch ... it looks good to me, you should perhaps upload, robert_ancell is not going to be online before another half a day and it seems quite some users are running into the bug
[13:15] <seb128> apw, can you upload the fix and do a merge request for it on trunk? or do you prefer if I do that?
[13:18] <apw> seb128, i can do that no problem, if you know where the master one is, it doesn't seem to have a link in the pakcaging
[13:20] <seb128> apw, just propose the fix for upstream code (e.g lp:lightdm), there is no packaging vcs afaik
[13:20] <apw> seb128, ahh great will do so indeed
[13:20] <seb128> apw, thanks
[13:34] <barry> uh oh.  looks like the greeter is feeling unhappy this morning.  super tiny font syndrome
[13:36] <jodh> pitti: got a fix for the zero-length core files - bug 1203744
[13:37] <apw> seb128, merge proposed:https://code.launchpad.net/~apw/lightdm/lp1203711-fix-uninitialised-glist/+merge/176193
[13:38] <apw> seb128, and i am just re-testng for upload
[13:38] <seb128> apw, excellent, thanks!
[13:38] <pitti> jodh: argh, brown paperbag one.. thanks!
[13:39] <pitti> jodh: saucy has 2.11-0ubuntu1, which is what is in bzr (that even has a staged commit which isn't uploaded)
[13:39] <pitti> jodh: it's in Vcs-Bzr:, not the UDD branch
[13:40] <jodh> pitti: ok, thanks.
[13:52] <zul> mterry:  ping any update on python-heatlclient?
[13:52] <mterry> zul, not yet.  I'll assign or review today
[14:04] <rbasak> mdeslaur: OK for me to touch apache2? I want to merge 2.4.6-1 to fix bug 1202653.
[14:05] <mdeslaur> rbasak: sure, thanks!
[14:05] <rbasak> Great, thanks.
[14:10] <xnox> rbasak: that's my bug! \o/
[14:10] <xnox> rbasak: thanks!
[14:18] <doko> I HATE ARCH INDEP all PACKAGES!
[14:18] <doko> -dev packages even
[14:19] <davmor2> doko: use ubuntu instead of arch /me runs for the bunker............ :D
[14:25] <pitti> rbasak, jibel, apw: hm, in today's saucy /dev/kvm doesn't exist any more; dmesg says "kvm_intel: Unknown parameter `nested'"; known?
[14:26] <pitti> ah, /etc/modprobe.d/qemu-system-x86.conf:options kvm_intel nested=1
[14:26] <pitti> modinfo kvm_intel still shows it, though
[14:38] <apw> pitti, yes a known issue, will be fixed in the next upload
[14:38] <pitti> apw: thanks
[14:38] <apw> pitti, parameter handling has gone to pot
[14:40] <jodh> pitti: bug 1203211.
[14:40] <rbasak> When doing a merge, is it normal to include changelog entries for bugs fixed by virtue of them being fixed in Debian? Or should I just make sure to include those bug numbers in my changes file?
[14:43] <xnox> rbasak: if debian used "LP: #NNNNNNN" you are fine (in addition to Closes: #), otherwise in your merge changelog you'd need to include "LP: #######", or otherwise the bug will stay open, and you'd have to manually close it.
[14:44] <cjwatson> rbasak: I occasionally stick a parenthesised comment in about such-and-such a Debian version fixing such-and-such an LP bug
[14:44] <cjwatson> But sometimes it reads oddly and I just close manually
[14:44] <xnox> rbasak: look at the .changes file and make sure there is LP-* bugs closing stanza in there with things you want to close.
[14:44] <xnox> may require -v option, when building the source package.
[14:44] <rbasak> OK, got it, thanks. In this case Debian used LP: #XXX so I should be fine. I'll make sure to check the changes file.
[14:58] <doko> roaksoax, ping
[15:06] <slangasek> pitti: hmm, would you like to add me to the cron mail, so I could help track it down?
[15:06] <pitti> slangasek: that's for the apport retracers?
[15:07] <slangasek> pitti: yeah
[15:07] <pitti> seb128: did you get apport failure cron mail recently? I didn't
[15:07] <pitti> slangasek: done; but I have a feeling that the problem is on the sending side
[15:08] <slangasek> pitti: sure, I expect so too - but at least this doubles the odds of someone noticing that the mails haven't been sent :)
[15:09] <pitti> indeed
[15:11] <seb128> pitti, I got an email on friday from the dup checker, that's all recently
[15:12] <pitti> seb128: yes, I got that one, too
[15:12] <pitti> but never one from the i386 crash
[16:00] <doko> seb128, pitti: is glib2.0 buildable without python-gi and python-dbus?
[16:53] <cjwatson> bdmurray: copy-set-phase now available
[16:57] <cjwatson> bdmurray: So if we deploy set-pup now, is the cron job already running somewhere sensible and will it adjust the phases up over time?
[17:45] <SpamapS> nobody    2444  0.0  0.0  28900  1528 ?        S    Jul21   0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d
[17:45] <SpamapS> what is the point of having a local dnsmasq..
[17:45] <SpamapS> if --cache-size=0 ?!
[18:13] <jbicha> zul: there's a typo with horizon, it depends on python-neturonclient
[18:13] <zul> jbicha: ?
[18:14] <jbicha> shouldn't it be neutron?
[18:14] <zul> jbicha:  crap thanks for spotting it
[18:15] <zul> jbicha:  ill fix that up
[18:18] <jbicha> neturon does sound kinda cool though
[19:48] <pitti> doko: glib2.0 python-gi and python-dbus sound like test dependencies; you certainly don't need them for build
[19:49] <xnox> pitti: yeah, i thought so to. trying to use jhbuild to cross-bootstrap gnome =)
[20:02] <jdstrand> @pilot in
[20:30] <doko> xnox, pitti: thanks, in that case I won't need the jhbuild
[20:31] <xnox> doko: yeah, but autoconf cache is incomplete for arm64 =)
[20:31] <doko> xnox, ?
[20:32] <xnox> well, not enough to cross-compile glib. going through it now.... unless the cache is not loaded, one sec.
[20:32] <doko> ahh
[20:40] <xnox> compiling. and it needs to be taught about multiarch include dirs *sigh*
[20:45] <roaksoax> mterry: so I've been looking into the test of libqb and haven't been able to find a way to fix them. So I'll disable the failing ones for now, since it is blocking other packages that I need to upload to have a functional cluster stack in saucy
[20:46] <mterry> roaksoax, OK, but can you file a bug to fix the rest of them and assign to someone (maybe you) for tracking purposes?  It would be nice to see those addressed, in case they are real problems
[20:46] <roaksoax> mterry: I talked to the debian maintainer too and he's also gonna look into that.
[20:47] <roaksoax> and will do
[20:47] <roaksoax> :)
[21:09] <roaksoax> mterry: done! https://launchpad.net/ubuntu/+source/libqb/0.14.4-1ubuntu1 should be published soon
[21:09] <mterry> roaksoax, don't know what's wrong with my IRC, but I'm all over the place  :(
[21:11] <roaksoax> mterry: :(
[21:17] <roaksoax> mterry: thanks! :)
[21:20] <xnox> too hot, must shut down my pc
[21:25] <ari-tczew> xnox: or buy a cooling mat
[21:25] <mterry> roaksoax, thank you!
[21:26]  * ScottK has set his laptop on a bag of ice before.
[21:26] <ScottK> Need to take it off before condensation gets too bad though.
[21:26] <dobey> anyone know why this command line would result in a file that is statically linked, rather than a dynamic lib? http://pastebin.ubuntu.com/5901979/
[21:31] <sarnold> dobey: wild-guess territory, perhaps one of the .o files was compiled without -fPIC? does 'file' on all the .o files look sensible?
[21:32] <dobey> sarnold: yeah, all ELF LSB relocatable SYSV not stripped
[21:32] <slangasek> dobey: "statically linked" - defined how?  what does file say on the resulting object?
[21:33] <dobey> slangasek: ldd says "statically linked", file says "dynamically linked"
[21:33] <dobey> so uh, wtf :)
[21:33] <slangasek> what does objdump -p $file | grep NEEDED' say?
[21:34] <dobey> slangasek: it's empty
[21:34] <dobey> (the library has no symbols at the moment, but this problem only happens on saucy, not on raring)
[21:34] <slangasek> there's no way that command could result in a statically linked object with no missing refs, because you're passing the path to the .so's specifically - the linker isn't going to randomly substitute the .a's
[21:34] <slangasek> oh
[21:35] <slangasek> "the library has no symbols at the moment" is exactly your problem.
[21:35] <slangasek> the linker has outsmarted you
[21:35] <dobey> but why is it only an issue on saucy?
[21:35] <dobey> ld is trying to be smart?
[21:35] <slangasek> I thought this default was changed pre-saucy, but maybe not
[21:36] <slangasek> but in any case, the default behavior is -Wl,--as-needed
[21:36] <dobey> on raring ld reports the libc and ld deps
[21:36] <dobey> err, ldd reports
[21:36] <slangasek> so if you ask to link to a library that you don't actually need, ld discards this reference
[21:37] <slangasek> you can force the linkage with -Wl,--no-as-needed for testing
[21:37] <dobey> that's fine, but ldd reporting "statically linked" is obviously wrong
[21:37] <slangasek> not really
[21:37] <slangasek> it has no dynamic library dependencies
[21:37] <slangasek> so it's statically linked
[21:38] <slangasek> the definition of a dynamically linked library is one that has external runtime dependencies.  This library has none, so it's a statically linked library (by virtue of the fact that it's completely empty).
[21:39] <dobey> ls
[21:40] <dobey> so i should just ignore lintian complaining about the shlibs for now?
[21:41] <slangasek> whether the library is statically linked is entirely unrelated to whether it's *consumable* as ashared library
[21:42] <slangasek> the shlibs are for the latter, and the lintian error ought to be fixed
[22:01] <robert_ancell> mterry, how did you mark the mir MIR "no longer affects unity-system-compositor"?
[22:11] <dobey> slangasek: thanks. would you mind taking a look at https://bugs.launchpad.net/ubuntu/+bug/1199017 ? finally got the issues fixed with symbols exporting and that as-needed problem. just decided to drop the empty lib from the packaging for now.