On Fri 2013-02-08 11:21:32 -0500, Daniel Kahn Gillmor wrote: > On 02/08/2013 04:58 AM, Adam D. Barratt wrote: >> Unfortunately that FTBFS in the same way that +deb7u1 did. :-( I'm >> wondering if this is related to the build environment in some way. >> Daniel - did you use sbuild, pbuilder or something else for your upload? > > I used a manually-built minimal kvm guest instance. I will try to > reproduce the build failure in a wheezy cowbuilder instance over this > weekend :(
ok, now i'm quite confused. I just built xdotool_2.20100701.2961-3+deb7u2 in a freshly-created wheezy cowbuilder instance within a stock wheezy amd64 kvm guest. The package built with no problems. i created the cowbuilder instance by setting DISTRIBUTION=wheezy in /etc/pbuilderrc and then: cowbuilder --create then i transferred the following files to the machine in question: xdotool_2.20100701.2961-3+deb7u2.debian.tar.gz xdotool_2.20100701.2961-3+deb7u2.dsc xdotool_2.20100701.2961.orig.tar.gz and then did: cowbuilder --build xdotool_2.20100701.2961-3+deb7u2.dsc This succeeds cleanly. It also succeeds if i set ARCHITECTURE=i386 in /etc/pbuilderrc, recreate the cowbuilder instance, and rebuild, yielding an i386 package. It's interesting to note that the xdotool versions currently in sid and experimental have both succeeded on all architectures: https://buildd.debian.org/status/package.php?p=xdotool&suite=experimental https://buildd.debian.org/status/package.php?p=xdotool&suite=sid Both of these packages use the same setup → setup_launch_xterm → readline backtrace that triggers the EOFError for the This makes me think something is wrong with ruby on the buildds somehow, but i'm pretty perplexed by it. I don't know what the right thing to do is, frankly. I could support either completely disabling the test suite (despite that seeming rather wrong) or just dropping xdotool from wheezy, given how out-of-date the candidate package is. I'm open to other suggestions. --dkg
pgpSWJyEcjBFt.pgp
Description: PGP signature
