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
Attachment:
pgpBOhxN663rl.pgp
Description: PGP signature