[00:00] <doko> slangasek, do you remember which one?
[00:00] <slangasek> doko: the flag?  not offhand
[00:01] <slangasek> doko: google suggests 'expect stderr' restriction
[00:01] <doko> hmm, it alreadys has: Restrictions: allow-stderr
[00:01] <bdmurray> Riddell: oh, its mostly arm64 except for perlkde
[00:02] <Riddell> bdmurray: so probably fine to release all except perlkde then
[00:02] <slangasek> doko: right, https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1197005 says that's the right syntax; I don't know then
[00:02] <ubot2`> Launchpad bug 1197005 in autopkgtest (Ubuntu) "Add "expect stderr" restriction" [Medium,Fix released]
[00:03] <doko> slangasek, ok, I'll check with piotr tomorrow. care to unblock it? the test did always fail
[00:04] <xnox> doko: there could be other things, e.g. crash files generated (at least i'm under the impression that causes adt tests to fail, i can be wrong)
[00:04] <doko> but then, who did overwrite it in the past?
[00:05] <xnox> doko: i don't think it ever migrated from trusty-proposed to trusty.
[00:05] <xnox> doko: the previous one was copied from saucy i think.
[00:05] <slangasek> no
[00:05] <slangasek> there's a previous 'force-badtest' hint from infinity
[00:06] <xnox> doko: and tests did not pass.
[00:06] <xnox> doko: if [ -x /usr/bin/python2.6 ]; then\
[00:06] <xnox> 		test -f debian/python-foo/usr/lib/python2.6/dist-packages/foo/__init__.p;\
[00:06] <xnox> 		test ! -f debian/python-foo/usr/lib/python2.6/dist-packages/foo/spam.py;\
[00:06] <xnox> 	fi
[00:06] <xnox> grep -qe "Depends: .*python\(:any\)\? (<<" debian/python-foo/DEBIAN/control
[00:06] <xnox> [ "`readlink debian/python-foo/usr/lib/python2.7/dist-packages/foo/absolute_link_to_tmp`" = "/tmp" ]
[00:06] <xnox> make[1]: *** [check] Error 1
[00:06] <xnox> make[1]: Leaving directory `/tmp/adt-run.Vm3DtR/dsc0t-dh-python-testtmp/adttmp/tests/t201'
[00:06] <xnox> make: *** [test201] Error 2
[00:06] <xnox> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-dh-python/ARCH=amd64,label=adt/8/artifact/results/dsc0t-dh-python-stdout/*view*/
[00:07] <infinity> That's the same test that failed on the previous version and doko assured me it was fine and it would be fixed. :P
[00:07] <slangasek> doko: but I don't like kicking the can down the road indefinitely.  If there's not a pressing need for this fix in trusty, it should stay in -proposed and someone should fix the bug
[00:07] <xnox> that's for 1.20131021-1ubuntu3
[00:07] <xnox> hm. me tries to find actual results in jenkins
[00:08] <slangasek> ugh pbuilder
[00:08] <slangasek> this is why I don't have autopkgtest installed on my laptop. :P
[00:08] <xnox> doko: are you asking unblock for ubuntu3 or ubuntu4 ? cause britney hasn't asked to test ubuntu4 yet.
[00:09] <xnox> slangasek: i use scripts from lp:auto-package-testing which don't have side effects of installing garbage on my machines.
[00:10] <doko> xnox, 4
[00:10] <xnox> slangasek: those cleanly download ubuntu cloud image and do all the dirty work in a snapshot of thereof. and that's the same way adt tests are being executed in the lab.
[00:10] <doko> infinity, did I? can't remember
[00:10] <infinity> doko: Yeah. :)
[00:11] <doko> slangasek, I do want this for the test rebuild
[00:11] <infinity> doko: I think I let it in cause you said the version I unblocked was critical for some reason or other, but you also claimed the test would get fixed (perhaps by upstream).
[00:11] <infinity> Unless you're upstream.
[00:11] <infinity> Then, it was by you. :P
[00:11] <xnox> doko: then you don't get to claim all tests have passed, in the ADT environment, cause ADT has not run yet for ubuntu4 yet ;-)
[00:12] <doko> no, python helpers are a thing I'm staying away from. too many hostile people out there ...
[00:12] <slangasek> xnox: needing to grab a cloud image when I have perfectly good, pbuilder-free schroots here also seems onerous ;)
[00:12] <doko> hmm, I need to learn how to run autopkgtests locally ...
[00:13] <xnox> slangasek: adt tests are expected to be able to break test-beds =/ so, lxc or kvm, no chroots here when running those.
[00:13] <xnox> doko: an sbuild hook would be nice, to install and run the tests at the end of the build, wouldn't it?
[00:13] <xnox> or just use a schroot run to do them.
[00:13] <slangasek> doko: sudo adt-run /path/to/dh-python_1.20131021-1ubuntu4.dsc  --- adt-virt-schroot trusty
[00:13] <doko> infinity, looks like pitti did try to fix it, but didn't succeed. I don't think that I did ask you in the past ...
[00:14] <xnox> slangasek: oh, nice.
[00:14] <doko> will try to address this tomorrow
[00:14] <infinity> doko: Given my hint unblocking it, you must have asked me.
[00:14] <doko> anyway, have to wait for an eglibc upload for the test rebuild
[00:14] <slangasek> infinity: you only add hints when doko asks you?
=== xnox is now known as doko_
[00:15] <doko_> infinity: can you please unblock cmake?
[00:15] <infinity> doko: eglibc being worked on right now.
=== doko_ is now known as xnox
[00:15] <infinity> xnox: By fixing libarchive?
=== Ursinha-afk is now known as Ursinha
[00:16] <xnox> infinity: yes please. I'm a bit clueless about it. extracted the actual test-suite output and the test case is sane. not sure if it's symptoms of the same eglibc issue or not =/
[00:17] <infinity> xnox: If it uses strstr, it could be.
[00:17] <infinity> And pretty much everything uses strstr.
[00:17] <infinity> So, we'll see.
[00:47] <xnox> infinity: but seriously, can you migrate cmake before/for the archive rebuild ? cause it's only invalidated by dependency....
[00:47] <infinity> xnox: Uhm, no.
[00:47] <xnox> Uhm, ok.
[00:47] <infinity> xnox: "invalidated by dependency" means it DEPENDS on that other package.
[00:48] <infinity> xnox: As in, it depends on that version of libarchive.
[00:50] <infinity> I'm not sure why that would be, in this case, mind you.
[00:50] <xnox> infinity: i don't see how though =/ hm, not a condition i've seen before from britney.
[00:50] <infinity> Happens all the time during ABI transitions, etc.
[00:51] <infinity> Oh, it might be because of ppc64el.  cmake on ppc64el depends on libarchive13, which only exists in -proposed.
[00:51] <infinity> We could temporarily break that, but I'd prefer not to.
[00:52] <infinity> Or I could cheat, by moving the ppc64el libarchive into the bootstrap repo.
[00:52] <xnox> yeah... cause there is cmake/ppc64el in trusty-release....
[00:53] <slangasek> doko: fwiw, on the failing test ([ "`readlink debian/python-foo/usr/lib/python2.7/dist-packages/foo/absolute_link_to_tmp`" = "/tmp" ]), I see the following:
[00:53] <slangasek> debian/python-foo/usr/lib/python2.7/dist-packages/foo:
[00:53] <slangasek> lrwxrwxrwx 1 root root 51 Dec 20 00:43 absolute_link_to_tmp -> ../../../../share/pyshared/foo/absolute_link_to_tmp
[00:53] <slangasek> that is obviously not an absolute symlink, and the test should be fixed
[00:53] <slangasek> (or dh-python itself fixed)
[00:54] <infinity> Oh, it's already in the bootstrap repo, not as easy to cheat as I was thinking.
[00:54] <infinity> xnox: Anyhow, let's see if my glibc magically fixes it shortly.
[00:54] <infinity> Well, "shortly"... Once I've built it.
[00:55] <xnox> infinity: ah britney doesn't consider bootstrap repo. makes sense.
[00:55] <slangasek> quite
[00:56] <xnox> and copying across libarchive13/pp64el binary without source, to trick britney into migrating cmake, is wrong on so many levels..... right, i'll go bother about something else, whist infinity cooks eglibc =)
[00:57] <slangasek> we could equally force-migrate libarchive before it's fixed on i386
[00:57] <slangasek> but if it's done soon... why bother
[00:58] <infinity> xnox: britney sort of does consider the bootstrap repo to avoid too much pain, actually.
[00:58] <infinity> But I may have missed a corner case.
[00:58] <infinity> And I don't much care in this case, we should just fix the bugs.
[01:20] <infinity> xnox: Huh.  So, I can't reproduce that libarchive test failure.
[01:21] <xnox> infinity: on i386?
[01:22] <xnox> infinity: i can, but then again i haven't rebooted my machine into fresh kernels in a while.
[01:22] <infinity> xnox: On i386, yes.  In the same chroot where I *can* reproduce the java vs strstr bug.  So, it's not that.
[01:22] <xnox> infinity: yeah, it did smell fishy, and not fully related to the eglibc bug.
[01:23] <xnox> infinity: went to try wacking it again, but i guess it's you who have retriggered a rebuild ;-)
[01:24] <infinity> Yeah.
[01:24] <infinity> If it fails on the buildd, I'll start comparing package versions.
[01:25] <infinity> This chroot is stale by a few days, since I haven't upgraded it since I started looking at the java thing.
[01:25] <infinity> Nope, it passed on the buildds now.
[01:25] <infinity> So, racy test, or problem solved elsewhere.
=== Ursinha-afk is now known as Ursinha
[01:57] <slangasek> doko_: this autopkgtest has been broken since the first commit in the dh-python branch, one wonders why Piotr has tests if he's not going to use them. :P  I can't tell if it's the test or dh_python that should be fixed; I'm filing a bug in Debian and unblocking
[02:00] <infinity> Grr.  I do love it when people sync -f over my changes and then DON'T FIX THE RESUTLING FTBFS.
[02:00] <infinity> resulting, too.
[02:05] <StevenK> "It built locally, must be a buildd issue!"
[02:05]  * StevenK hides.
[02:15] <slangasek> some kind of irony that I installed autopkgtest to verify a dh-python bug, and on removal it left behind .pyc files
[02:17] <infinity> StevenK: Given that the changelog specifically stated the fix was powerpc-specific, "it built locally" would be a pretty lousy excude for sync -f.
[02:17] <infinity> excuse, too.
[02:18] <infinity> And the old patches applied cleanly too, so "I think upstream might have fixed it" would also not work. :P
[09:05] <Laney> It's easy to miss sync FTBFSen given that they don't mail
[09:31] <infinity> Laney: It's easy to miss the FTBFS, it's a bit harder to miss the patches you overwrote. ;)
[09:31] <infinity> Laney: But we chastised him appropriately with "I can't test it" doesn't mean "drop the patches", it means "ask someone who can".
[09:33] <Laney> Oh yeah, it's still naughty to do that, but usually you'd get shouted at by soyuz before anyone else notices.
[09:34] <infinity> Agreed that people who copy packages should get FTBFS grump mail.
[09:34] <infinity> wgrant: Why don't they?  Bug, or actually hard to do for some reason?
[09:34] <wgrant> infinity: Both.
[09:35] <infinity> wgrant: Let me guess, we have no concept of creator on those, just the signer?
[09:35] <wgrant> infinity: It needs to guess at the publication to use.
[09:36] <infinity> wgrant: How so?  Isn't the build record a bit more specific in its lineage than the source?
[09:36] <wgrant> infinity: The build just lists an archive, suite, architecture and sourcepackagerelease.
[09:37] <infinity> wgrant: I mean, if you FTBFS in a PPA, it's the person who uploaded/copied to that PPA, if you FTBFS in primary, it's obviously a build record that was created after a copy to primary, which you can only do once.  You can only create a record for a source once in any archive.
[09:37] <wgrant> Notifications have historically gone to SPR.creator because derp.
[09:37] <wgrant> They need to go to SPPH.creator
[09:37] <infinity> wgrant: Okay, but do we know who copied the SPR into the archive?
[09:37] <wgrant> But for that we need to guess at which SPPH is relevant.
[09:37] <wgrant> Which apparently doesn't always work.
[09:38] <wgrant> There's a similar problem with attributing translations for copies, not quite sure what's going wrong.
[09:38] <infinity> Would it be mean for me to assign the bug to Celso and make him fix it the day he starts?
[09:40] <wgrant> Yes :)
[09:41] <infinity> You're no fun.
[09:44] <apw> that would be very [just do it] mean thing to [just] do [it]
[09:50] <Laney> Cruel to be kind
=== doko_ is now known as doko
[13:46] <sergiusens> can someone please check on golang-gocheck and golang-go-flags please?
[13:46] <sergiusens> from the new queue
[13:55] <xnox> infinity: doko: demote python-pyste to universe (got denewed into main?!) & demote gccxml src+bin  to universe. Ready as per component-mismatches.
[14:01] <doko> xnox, done
[14:04] <xnox> cheers!
=== sil2100 is now known as KURWA
=== KURWA is now known as sil2100
=== psivaa is now known as psivaa-holiday
=== Ursinha-afk is now known as Ursinha