[00:09] <doko> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+sourcepub/5267908/+listing-archive-extra
[00:09] <doko> Laney, slangasek: apparently introduced by new gstreamer
[01:04] <synthor> heya
[01:04] <synthor> anyone knows about this one: https://twitter.com/temasek71/status/626688248841023488 ?
[01:04] <synthor> i'm sitting here since hours asking myself why cyanogenmod build fails with broken pipes
[01:04] <synthor> tested my memory modules
[01:05] <synthor> and then i find a twitter post, reboot the old kernel and the build runs through
[01:05] <synthor> 3.13.0-59 doesn't compile,  3.13.0-58 does
[01:08] <sarnold> synthor: can you reproduce on a current kernel?
[01:12] <synthor> not atm, i rebooted -58 and now the cyanogenmod build runs through for an hour or so
[01:12] <synthor> later i can, of course
[04:11] <pitti> Good morning
[05:49] <pitti> slangasek: gosh, what a shameful britney bug; reproduced in a test case and fixed now
[06:15] <jamespage> bdmurray, wily has a sufficently new version that it already contains the fix for that bug
[06:26] <pitti> infinity, slangasek: ah! http://anonscm.debian.org/cgit/debian-release/britney2.git/commit/?id=b9f6417351 introduces :any dependencies
[06:28] <pitti> hm, but we have that already
[06:33] <stgraber> kees: I'm in Europe this week, might be easier to chat next week when I'm back in north america :)
[06:33] <infinity> pitti: I don't think britney itself has issues with :any for migration/installability checks.
[06:34] <pitti> infinity: the reverse dep calculation does
[06:34] <pitti> I fixed it now
[06:34] <pitti> infinity: http://bazaar.launchpad.net/~pitti/britney/britney2-ubuntu-swiftresults/revision/464 ?
[06:36] <infinity> pitti: Hrm.  Curious.  What would that have affected other than autopkgtest triggers, I wonder?
[06:36] <infinity> pitti: If it was horribly broken, you'd think we'd have noticed.
[06:37] <pitti> infinity: well, it just didn't consider a Depends: python:any in rdepends, so any installability check etc. would ignore this
[06:38] <infinity> pitti: installability checks use forward deps, not revdeps.
[06:38] <infinity> pitti: Perhaps it might have tripped up the autohinter occasionally.
[06:38] <pitti> RDEPENDS is also being used in doop_source(), is that not used for installability checks?
[06:39] <pitti> in _check_packages() too
[06:39] <pitti> so I figure what *could* happen now is that this change now causes britney to hold back packages that it previously didn't
[06:39] <infinity> Dunno.  I'd have to read a lot more, I'm just pondering how it wasn't obviously broken (and it wasn't), given the numeber of things with foo:any deps.
[06:39] <pitti> hopefully this is actually justified in most cases, but if it's wrong, then it would err on the safe side, wouldn't it?
[06:40] <infinity> Anyhow, regardless, your patch seems safe and obvious enough.
[06:40] <pitti> is there any other suffix than :any?
[06:41] <infinity> :native
[06:41] <pitti> a split(':')[0] might be more appropriate
[06:41] <infinity> Although, wait.  Tell me the output from the thing you patched doesn't get fed to the bits Colin fixed?
[06:41] <infinity> Cause then they'd suddenly be wrong.
[06:41] <infinity> Since his stuff explicitly only allows an :any dep on things that are M-A:allowed (as the spec requires).
[06:42] <infinity> If you strip :any before you get to that check, then you're regressing that.
[06:42] <pitti> register_reverse() actually happens after that (cjwatson changed read_sources(),  which calls register_reverse near the end)
[06:42] <pitti> infinity: ipython doesn't have M-A: allowed
[06:43] <pitti> python does
[06:43] <infinity> pitti: No, python does.
[06:43] <infinity> You can only dep on foo:any if foo is M-A:allowed
[06:44] <pitti> ah no, not even read_sources, but get_dependency_solvers()
[06:44] <pitti> but a package without M-A: can have a Depends: foo:any, no?
[06:45] <infinity> pitti: Sure.  The point is that for installability checks, you need the full dep, a stripped version is a lie.
[06:45] <pitti> anyway, the above commit does not actually filter them out for the "packages" maps calculation, only in the subsequent installability test
[06:45] <pitti> yes, http://bazaar.launchpad.net/~pitti/britney/britney2-ubuntu-swiftresults/revision/464 does not modify the DEPENDS field
[06:46] <pitti> but when reading the DEPENDS field (which includes the :any) it currenlty tests whether that value is a known package
[06:46] <pitti> but "python:any" is not a package name
[06:46] <pitti> so in the dict lookup it must strip the :any suffix
[06:47] <pitti> of course packages[DEPENDS] should continue to have the :any suffix (and I'm not changing that)
[06:48] <infinity> pitti: Mmkay.
[06:50] <pitti> I'll send a Debian bug about that too
[06:50] <pitti> infinity: you don't happen to know the Debian britney2-tests suite? I'm getting http://paste.ubuntu.com/11971566/
[06:51] <infinity> pitti: Not sure how to make the testsuite go.
[06:51] <pitti> it doesn't cover ":any" stuff right now
[06:52] <infinity> pitti: Do we trigger on rbuilddeps too or just rdeps, I can never remember?
[06:52] <pitti> infinity: so far (in old and new infra) only on rdeps
[06:52] <infinity> I guess just rdeps, or we'd have a lot more tests running.
[06:52] <infinity> pitti: Anyhow, if rbuilddeps were ever in the cards, you'd have to worry about both :any and :native
[06:52] <pitti> ENOTENOUGHHORSEPOWER
[06:52] <pitti> we don't even trigger autodep8 tests ATM, for the same reason
[06:53] <infinity> :native is unique to build-deps (it doesn't make sense for deps, since "native" is the default assumption anyway).
[06:54] <pitti> infinity: if there's only these two, I think  split(':')[0] is better -- ':' can't ever occur in a package name, so stripping off all qualifiers for the package dict lookup seems safer
[06:54] <infinity> pitti: Yeah, that's what I did in the old-skool sbuild fork, since I didn't care about supporting cross-building. :P
[06:54] <infinity> pitti: Made life much simpler to just ignore M-A and pretend it wasn't a thing.
[06:55] <pitti> well, britney should take it into account
[06:55] <infinity> britney's meant to be growing actual MA support soon anyway.
[06:56] <infinity> Which means cross-arch deps without hacks.
[06:56] <infinity> Which I still think is a mistake, but we'll see if people abuse it. :P
[06:56] <infinity> Right now, we have exactly one cross-arch dep, I think (wine64->wine32), and I think that's about the right number.
[06:57] <infinity> Oh, and build-essential-$arch->libc:$arch.  So, two.
[06:57] <infinity> s/libc/libc-dev/
[07:00] <dholbach> good morning
[07:08] <pitti> infinity: ah, got the tests to work, still all pass
[07:10] <pitti> forwarded to Debian bug 794194
[07:53] <Laney> doko: fixing it, thx for noticing
[08:03] <Laney> doko: shall I just upload to 39 or wily or what?
[08:22] <doko> Laney, fixing in gstreamer, or thumbnailer?
[08:22] <Laney> thumbnailer?
[08:22] <Laney> you mean tp-qt5, and it's there
[08:27] <doko> Laney, yes, 39 would be fine.
[09:39] <pitti> sbeattie: FYI, new apparmor seems to break content-hub: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apparmor
[09:40] <jjohansen> pitti: do you know what kernel that was run on?
[09:41] <sbeattie> pitti: yeah, I haven't dug into it yet, need to dig out the bits to reproduce it.
[09:41] <doko> Laney, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+build/7741720  new gnome components?
[09:41] <pitti> sbeattie: ack, just wanted to make sure you're aware, as email notification isn't very effective for these
[09:41] <Laney> doko: sec, on the phone
[09:41] <pitti> jjohansen: https://jenkins.qa.ubuntu.com/job/wily-adt-content-hub/lastBuild/ARCH=amd64,label=adt/artifact/results/testbed-packages/*view*/ says 4.1.0-3.3
[09:42] <jjohansen> pitti: I asked because the kernel team is rolling out the 4.2 rebase it is possible that could cause some regressions as well
[09:42] <jjohansen> pitti: thanks
[09:43] <pitti> I should start referring to the new system on http://autopkgtest.ubuntu.com/packages/c/content-hub/wily/amd64/ :)
[09:43] <pitti> jjohansen: so, there ^ you can look at the debci log
[09:44] <pitti> you see in the "base system diff" that the kernel did not change, but apparmor changed from 2.9 to 2.10
[09:44] <pitti> (also, python3.4, but that's most probably not the cause)
[09:44] <jjohansen> got it
[09:44] <pitti> this is a much more useful view than the old jenkins stuff
[09:45] <pitti> sbeattie: please let me know if you have trouble reproducing it (using adt-run etc.)
[09:46]  * pitti runs it locally for fun
[09:46] <pitti> and yay for tests which just say "FAIL" without saying what/why
[09:48] <pitti> adt-run --apt-pocket=proposed -U content-hub --- qemu adt-wily-amd64-cloud.img
[09:49] <pitti> sbeattie: ^ reproduces locally; I suggest running with -s to get a shell after the failure
[10:04] <Laney> doko: why gnome?
[10:04] <Laney> doko: this is a touch component
[10:04] <doko> Laney, why not? it was a question
[10:04] <Laney> well if you have a reason then I want to know so that I can see it :)
[10:04] <doko> Laney, please could you merge the new glibmm2.4 into silo 39?
[10:05] <doko> seb128 isn't yet here
[10:05] <Laney> i.e. if it's something I might be able to fix easily
[10:05] <Laney> umm
[10:05] <Laney> you mean 2.45.41.is.2.44.0-0ubuntu1?
[10:06] <doko> probably, the ppa page says: glibmm2.4 - 2.45.41-0ubuntu3~gcc5.2 (Newer version available)
[10:06] <Laney> is it reapplying this diff https://launchpadlibrarian.net/213023058/glibmm2.4_2.45.41-0ubuntu1_2.45.41-0ubuntu3%7Egcc5.2.diff.gz ?
[10:07] <doko> yes, looks ok
[10:07] <Laney> ok, will do
[10:07] <doko> and then could you stop uploading stuff for 4-6 hours, which is in the ppa?
[10:08] <Laney> I know you want to push it today, won't upload anything :)
[10:08] <Laney> maybe mail -devel to tell everyone else
[10:13] <cjwatson> doko: do you want auto-sync disabled now then?
[10:15] <doko> Laney, sent
[10:15] <doko> cjwatson, yes, would be good
[10:16] <cjwatson> doko: done
[10:44] <caribou> I'm looking for a sponsor for the merge of rsyslog (Bug: #1464201)
[10:44] <caribou> I'm returning from vacation near feature freeze so I'd like to see this one in Wily so it gets shaken out before our next LTS
[10:52] <Laney> doko: glibmm2.4 merged
[11:01] <doko> Laney, ta, and I had to do a glib-networking rebuild in the ppa
[11:01] <doko> renamed libproxy
[11:03] <Laney> doko: will you NMU these renames?
[11:04] <doko> Laney, nmu where?
[11:04] <Laney> unstable
[11:04] <doko> surely not all, need to write an email first ... want to call for "adopt a library transition"
[13:32] <pitti> Laney: hmm, still stunned about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/u/ubuntu-system-settings-online-accounts/20150731_085942@/log.gz
[13:32] <pitti> Laney: it looks like cloud-init isn't done yet at this point and the host name is still "ubuntu", i. e. it didn't get around to updating it yet
[13:33] <Laney> pitti: it's happening through multiple retries?
[13:33] <pitti> but we wait until /var/lib/cloud/instance/boot-finished exists, so it should be done
[13:33] <Laney> why should that be package specific?
[13:33] <pitti> Laney: http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/wily/amd64/ (and i386) failed four times in a row yesterday
[13:33] <pitti> Laney: but if I run it manually on teh worker it succeeds
[13:33] <pitti> Laney: yeah, no idea
[13:33] <pitti> (package specific)
[13:33] <pitti> I suppose it isn't really, as it happened to other runs too
[13:34] <Laney> could just be unlucky
[13:34] <Laney> you mean if you run the same adt-run command it works?
[13:34] <pitti> e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/r/ruby-rails-assets-jquery-textchange/20150730_165419@/log.gz
[13:34] <pitti> right
[13:34] <pitti> it fails fast, as adjusting the apt sources (from --apt-pocket=proposed) is pretty much the first thing it does
[13:35] <pitti> I'm running a loop with /home/ubuntu/autopkgtest/tests/testpkg-simple/ (which is very quick), to see whether I can hit it
[13:35] <pitti> Laney: just wondering if you happen to have an idea abou that
[13:35] <pitti>     if ! timeout 30m $SSH 'while [ ! -e /var/lib/cloud/instance/boot-finished ]; do sleep 1; done'; then
[13:35] <pitti> I don't see what's wrong with that
[13:40] <Laney> why do you think that's the problem?
[13:40] <Laney> isn't it that this hostname error causes sudo to fail?
[13:40] <pitti> the sudo error points out that /etc/hostname is "ubuntu", not the correct host name yet
[13:41] <pitti> or cloud-init fails, but then it shuoldn't create /var/lib/cloud/instance/boot-finished
[13:47] <Laney> pitti: maybe some clue on the console?
[13:57] <pitti> Laney: I guess my first step will be to make it fail with 16 instead of 20, and then think how the ssh setup script can do nova console-log only in such failure cases
[13:58] <pitti> meh, restarted it again, failed again; so at least it's moderately reproducible
[14:20] <synthor> is a kernel-dev here?
[14:20] <pitti> that's a trick question -- better just ask your actual question
[14:20] <pitti> synthor: ^
[14:20] <synthor> the latest 14.04 kernel 3.13.0-59 causes segfaults
[14:20] <synthor> 3.13.0-58 seems to be fine
[14:20] <synthor> Jul 31 16:17:52 prosyn kernel: [11720.503201] ld[28708]: segfault at bae6b2d0 ip 00000000bae6b2d0 sp 00000000ea4e7d80 error 14 in ld-2.19.so[2b55bae6a000+23000]
[14:21] <synthor> while compiling cyanogenmod
[14:21] <synthor> if no segfault occurs, it'll create broken pipes
[14:21] <synthor> rebooting the old kernel, everything runs fin
[14:21] <synthor> e
[14:22] <pitti> synthor: can you please report this as a bug, with the complete dmesg and reproducer?
[14:22] <pitti> if possible, attach just a single ld command with pre-compiled object files that triggers this, as "build cyanogenmod" is not a very tractable (and well-defined) reproducer
[14:24] <synthor> i'll check the makefiles for the command which triggers the bug
[14:24] <pitti> synthor: if building doesn't show the full command line, but uses "quiet" output, running "make V=1" often helps
[14:25] <pitti> then, if you can reproduce the crash with just running the single ld that it runs -> win
[14:25] <synthor> clang: error: unable to execute command: Segmentation fault (core dumped)
[14:33] <bdmurray> pitti: is there any reason the security SRU of apport, version 2.14.1-0ubuntu3.11, would be producing less informative crashes about /sbin/ip from iproute2?
[14:39] <synthor> hard to track it down....those android makefile-system is just a monster ^^
[14:39] <synthor> i greped the calls, but now i have to look which programs they're callin
[14:40] <pitti> bdmurray: /bin/ip is not a suid/sgid program, behaviour for "normal" 755 executables shouldn't have changed
[14:40] <pitti> bdmurray: i. e. I don't see a reason
[14:44] <bdmurray> pitti: Could it be called another program?
[14:45] <pitti> bdmurray: what does "less informative" mean here? the security update would cause suid/sgid programs to not get a report at all, or a root owned one, i. e. you wouldn't get a bug report unless a user is an admin
[14:45] <pitti> is it that?
[14:45] <pitti> the update doesn't have any impact on the quality of stack traces if you mean that
[14:46] <bdmurray> pitti: The reports for iproute2 are incomplete - particularly missing StacktraceAddressSignature
[14:47] <bdmurray> pitti: example here https://errors.ubuntu.com/oops/1b8c3c20-3607-11e5-89c7-fa163e525ba7
[14:49] <pitti> bdmurray: do we have a core dump for those? maybe it's truncated or even 0 bytes?
[14:50] <doko> slangasek, ready to pull the trigger? and start the copy?
[14:50] <pitti> go, gcc, go!
[14:52] <bdmurray> pitti: no, we don't ask for a coredump if there is no SAS and its not on armhf
[15:00] <doko> started the copy now ...
[15:10]  * Laney hears the screams of britney from here
[15:10] <ogra_> teach her how to sing then !
[15:15] <pitti> Laney: hah!
[15:15]  * Laney hopes that this is a eureka moment hah
[15:15] <pitti> Laney: http://paste.ubuntu.com/11973890/
[15:15] <Laney> hahaha
[15:16] <pitti> I thought POSIX would allow up to 255 chars
[15:16] <pitti> cloud-init seems to think differently
[15:16] <Laney> seems to be passing through an error from hostname?
[15:16] <pitti> actually not c-i, it's hostname itself
[15:16] <doko> copy is finished
[15:17] <pitti> Laney: it seems the limit is 64 chars
[15:17] <Laney> why didn't this happen when you ran it yourself?
[15:17] <bdmurray> pitti: so no ideas about iproute2 crashes other than truncated crashes?
[15:17] <pitti> Laney: I used --name adt-test, to avoid interfering with the running tests; silly me :)
[15:17] <Laney> hehe
[15:18] <pitti> bdmurray: no, I'm afraid; I tried "ip route & killall -SEGV ip" in a loop, but that's too slow to crash it; I figure one had to re-compile ip to force a crash and see what happens
[15:19] <bdmurray> pitti: I used "ip monitor" and got a good crash
[15:20] <pitti> Laney: that also explains ruby-rails-assets-markdown-it-diaspora-mention and the other funny long one :)
[15:20] <pitti> "ones"
[15:22] <Laney> is it always setting the machine name to the instance name?
[15:22] <Laney> can't think that the hostname matters so much, unless I'm missing something
[15:22] <pitti> yeah, would probably be even better to just hardcode it to "ubuntu"
[15:23] <pitti> this seems to be the default, maybe c-i has some "hostname:" option
[15:24] <Laney> looks like it does
[15:25] <pitti> smoser: ^ it seems the host name defaults to the cloud instance name given to nova boot; is there a c-i option to change it? (nothing in http://cloudinit.readthedocs.org/en/latest/topics/examples.html)
[15:25] <pitti> ChangeLog: - added cloud-config option 'hostname' for setting hostname
[15:25] <pitti> ah!
[15:26] <smoser> pitti,  you can also do 'manage_etc_hosts: localhost'
[15:26] <smoser> which will make sudo not cry at you "unknown host" business.
[15:26] <pitti> ah, instead of "true"?
[15:26] <pitti> I have "manage_etc_hosts: true"
[15:26] <pitti> for exactly that reason
[15:27] <smoser> ah. maybe thats right. let me read doc that is there.
[15:28] <pitti> smoser: but if I give my instance a very long name, it'll overflow hostname's 64 char limit
[15:28] <pitti> smoser: I don't need that, just "adt" or so is enough as hostname; I just want to be able to identify my cloud instances from "outside"
[15:28] <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L447
[15:29] <pitti> cool, "hostname: adt" works fine
[15:29] <pitti> thanks smoser
[15:29] <smoser> for identifying them, if you launched them on openstack, you can provide that hostname at launch time
[15:29] <smoser> in fact you're required to provide one.
[15:30] <pitti> I didn't explicitly give one, it just seemed to default to the name of "nova boot"
[15:30] <smoser> ah. ok. i thought that nova boot required one.
[15:30] <smoser> nova boot --key-name=brickies --flavor=m1.small --image=b9a4cbd6-82ae-4d53-8231-dc956aca100d smoser-hostname
[15:30] <pitti> smoser: right, it does
[15:31] <pitti> smoser: but my name is e. g. adt-wily-amd64-ubuntu-system-settings-online-accounts-20150731-150456
[15:31] <pitti> and that causes http://paste.ubuntu.com/11973890/
[15:31] <smoser> ah.
[15:32] <pitti> Laney: ok, fixed and retrying tests
[15:32] <pitti> and with that, good weekend everyone!
[15:34] <Laney> pitti: prima! schönes Wochenende!