/srv/irclogs.ubuntu.com/2013/12/20/#ubuntu-release.txt

dokoslangasek, do you remember which one?00:00
slangasekdoko: the flag?  not offhand00:00
slangasekdoko: google suggests 'expect stderr' restriction00:01
dokohmm, it alreadys has: Restrictions: allow-stderr00:01
bdmurrayRiddell: oh, its mostly arm64 except for perlkde00:01
Riddellbdmurray: so probably fine to release all except perlkde then00:02
slangasekdoko: right, https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1197005 says that's the right syntax; I don't know then00:02
ubot2`Launchpad bug 1197005 in autopkgtest (Ubuntu) "Add "expect stderr" restriction" [Medium,Fix released]00:02
dokoslangasek, ok, I'll check with piotr tomorrow. care to unblock it? the test did always fail00:03
xnoxdoko: 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
dokobut then, who did overwrite it in the past?00:04
xnoxdoko: i don't think it ever migrated from trusty-proposed to trusty.00:05
xnoxdoko: the previous one was copied from saucy i think.00:05
slangasekno00:05
slangasekthere's a previous 'force-badtest' hint from infinity00:05
xnoxdoko: and tests did not pass.00:06
xnoxdoko: if [ -x /usr/bin/python2.6 ]; then\00:06
xnoxtest -f debian/python-foo/usr/lib/python2.6/dist-packages/foo/__init__.p;\00:06
xnoxtest ! -f debian/python-foo/usr/lib/python2.6/dist-packages/foo/spam.py;\00:06
xnoxfi00:06
xnoxgrep -qe "Depends: .*python\(:any\)\? (<<" debian/python-foo/DEBIAN/control00:06
xnox[ "`readlink debian/python-foo/usr/lib/python2.7/dist-packages/foo/absolute_link_to_tmp`" = "/tmp" ]00:06
xnoxmake[1]: *** [check] Error 100:06
xnoxmake[1]: Leaving directory `/tmp/adt-run.Vm3DtR/dsc0t-dh-python-testtmp/adttmp/tests/t201'00:06
xnoxmake: *** [test201] Error 200:06
xnoxhttps://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:06
infinityThat's the same test that failed on the previous version and doko assured me it was fine and it would be fixed. :P00:07
slangasekdoko: 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 bug00:07
xnoxthat's for 1.20131021-1ubuntu300:07
xnoxhm. me tries to find actual results in jenkins00:07
slangasekugh pbuilder00:08
slangasekthis is why I don't have autopkgtest installed on my laptop. :P00:08
xnoxdoko: are you asking unblock for ubuntu3 or ubuntu4 ? cause britney hasn't asked to test ubuntu4 yet.00:08
xnoxslangasek: i use scripts from lp:auto-package-testing which don't have side effects of installing garbage on my machines.00:09
dokoxnox, 400:10
xnoxslangasek: 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
dokoinfinity, did I? can't remember00:10
infinitydoko: Yeah. :)00:10
dokoslangasek, I do want this for the test rebuild00:11
infinitydoko: 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
infinityUnless you're upstream.00:11
infinityThen, it was by you. :P00:11
xnoxdoko: 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:11
dokono, python helpers are a thing I'm staying away from. too many hostile people out there ...00:12
slangasekxnox: needing to grab a cloud image when I have perfectly good, pbuilder-free schroots here also seems onerous ;)00:12
dokohmm, I need to learn how to run autopkgtests locally ...00:12
xnoxslangasek: adt tests are expected to be able to break test-beds =/ so, lxc or kvm, no chroots here when running those.00:13
xnoxdoko: an sbuild hook would be nice, to install and run the tests at the end of the build, wouldn't it?00:13
xnoxor just use a schroot run to do them.00:13
slangasekdoko: sudo adt-run /path/to/dh-python_1.20131021-1ubuntu4.dsc  --- adt-virt-schroot trusty00:13
dokoinfinity, 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:13
xnoxslangasek: oh, nice.00:14
dokowill try to address this tomorrow00:14
infinitydoko: Given my hint unblocking it, you must have asked me.00:14
dokoanyway, have to wait for an eglibc upload for the test rebuild00:14
slangasekinfinity: you only add hints when doko asks you?00:14
=== xnox is now known as doko_
doko_infinity: can you please unblock cmake?00:15
infinitydoko: eglibc being worked on right now.00:15
=== doko_ is now known as xnox
infinityxnox: By fixing libarchive?00:15
=== Ursinha-afk is now known as Ursinha
xnoxinfinity: 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:16
infinityxnox: If it uses strstr, it could be.00:17
infinityAnd pretty much everything uses strstr.00:17
infinitySo, we'll see.00:17
xnoxinfinity: but seriously, can you migrate cmake before/for the archive rebuild ? cause it's only invalidated by dependency....00:47
infinityxnox: Uhm, no.00:47
xnoxUhm, ok.00:47
infinityxnox: "invalidated by dependency" means it DEPENDS on that other package.00:47
infinityxnox: As in, it depends on that version of libarchive.00:48
infinityI'm not sure why that would be, in this case, mind you.00:50
xnoxinfinity: i don't see how though =/ hm, not a condition i've seen before from britney.00:50
infinityHappens all the time during ABI transitions, etc.00:50
infinityOh, it might be because of ppc64el.  cmake on ppc64el depends on libarchive13, which only exists in -proposed.00:51
infinityWe could temporarily break that, but I'd prefer not to.00:51
infinityOr I could cheat, by moving the ppc64el libarchive into the bootstrap repo.00:52
xnoxyeah... cause there is cmake/ppc64el in trusty-release....00:52
slangasekdoko: 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
slangasekdebian/python-foo/usr/lib/python2.7/dist-packages/foo:00:53
slangaseklrwxrwxrwx 1 root root 51 Dec 20 00:43 absolute_link_to_tmp -> ../../../../share/pyshared/foo/absolute_link_to_tmp00:53
slangasekthat is obviously not an absolute symlink, and the test should be fixed00:53
slangasek(or dh-python itself fixed)00:53
infinityOh, it's already in the bootstrap repo, not as easy to cheat as I was thinking.00:54
infinityxnox: Anyhow, let's see if my glibc magically fixes it shortly.00:54
infinityWell, "shortly"... Once I've built it.00:54
xnoxinfinity: ah britney doesn't consider bootstrap repo. makes sense.00:55
slangasekquite00:55
xnoxand 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:56
slangasekwe could equally force-migrate libarchive before it's fixed on i38600:57
slangasekbut if it's done soon... why bother00:57
infinityxnox: britney sort of does consider the bootstrap repo to avoid too much pain, actually.00:58
infinityBut I may have missed a corner case.00:58
infinityAnd I don't much care in this case, we should just fix the bugs.00:58
infinityxnox: Huh.  So, I can't reproduce that libarchive test failure.01:20
xnoxinfinity: on i386?01:21
xnoxinfinity: i can, but then again i haven't rebooted my machine into fresh kernels in a while.01:22
infinityxnox: On i386, yes.  In the same chroot where I *can* reproduce the java vs strstr bug.  So, it's not that.01:22
xnoxinfinity: yeah, it did smell fishy, and not fully related to the eglibc bug.01:22
xnoxinfinity: went to try wacking it again, but i guess it's you who have retriggered a rebuild ;-)01:23
infinityYeah.01:24
infinityIf it fails on the buildd, I'll start comparing package versions.01:24
infinityThis chroot is stale by a few days, since I haven't upgraded it since I started looking at the java thing.01:25
infinityNope, it passed on the buildds now.01:25
infinitySo, racy test, or problem solved elsewhere.01:25
=== Ursinha-afk is now known as Ursinha
slangasekdoko_: 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 unblocking01:57
infinityGrr.  I do love it when people sync -f over my changes and then DON'T FIX THE RESUTLING FTBFS.02:00
infinityresulting, too.02:00
StevenK"It built locally, must be a buildd issue!"02:05
* StevenK hides.02:05
slangaseksome kind of irony that I installed autopkgtest to verify a dh-python bug, and on removal it left behind .pyc files02:15
infinityStevenK: 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
infinityexcuse, too.02:17
infinityAnd the old patches applied cleanly too, so "I think upstream might have fixed it" would also not work. :P02:18
LaneyIt's easy to miss sync FTBFSen given that they don't mail09:05
infinityLaney: It's easy to miss the FTBFS, it's a bit harder to miss the patches you overwrote. ;)09:31
infinityLaney: But we chastised him appropriately with "I can't test it" doesn't mean "drop the patches", it means "ask someone who can".09:31
LaneyOh yeah, it's still naughty to do that, but usually you'd get shouted at by soyuz before anyone else notices.09:33
infinityAgreed that people who copy packages should get FTBFS grump mail.09:34
infinitywgrant: Why don't they?  Bug, or actually hard to do for some reason?09:34
wgrantinfinity: Both.09:34
infinitywgrant: Let me guess, we have no concept of creator on those, just the signer?09:35
wgrantinfinity: It needs to guess at the publication to use.09:35
infinitywgrant: How so?  Isn't the build record a bit more specific in its lineage than the source?09:36
wgrantinfinity: The build just lists an archive, suite, architecture and sourcepackagerelease.09:36
infinitywgrant: 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
wgrantNotifications have historically gone to SPR.creator because derp.09:37
wgrantThey need to go to SPPH.creator09:37
infinitywgrant: Okay, but do we know who copied the SPR into the archive?09:37
wgrantBut for that we need to guess at which SPPH is relevant.09:37
wgrantWhich apparently doesn't always work.09:37
wgrantThere's a similar problem with attributing translations for copies, not quite sure what's going wrong.09:38
infinityWould it be mean for me to assign the bug to Celso and make him fix it the day he starts?09:38
wgrantYes :)09:40
infinityYou're no fun.09:41
apwthat would be very [just do it] mean thing to [just] do [it]09:44
LaneyCruel to be kind09:50
=== doko_ is now known as doko
sergiusenscan someone please check on golang-gocheck and golang-go-flags please?13:46
sergiusensfrom the new queue13:46
xnoxinfinity: doko: demote python-pyste to universe (got denewed into main?!) & demote gccxml src+bin  to universe. Ready as per component-mismatches.13:55
dokoxnox, done14:01
xnoxcheers!14:04
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!