launchpad-dev team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Fri, Oct 03, 2014 at 11:26:18AM -0400, Barry Warsaw wrote:
> I'm in favor of it in general.  I think this will also more closely align with
> how I do local testing of packages before uploading.  As many of the packages
> I touch are arch-indep and my local machine is amd64, I usually end up
> building and testing in that environment.  Yeah, I probably should have used
> i386 chroots, but it almost never makes a difference and it's more convenient
> to use amd64.

Right.

> I have been bitten by this once or twice though.  An example is system-image
> which originally had a hashing algorithm that unknowingly required 64 bits.
> At the time I didn't have an appropriate test case for this and it sneaked
> through to the touch image, where it broke on 32 bit ARM.  Once the issue was
> identified, it was easy enough to rework the hash algorithm to be 32 bit
> friendly, and of course add a test.  Now for that package I'm careful to run
> the builds and adt-run on 32 bit chroots.
> 
> I don't suspect it's possible to accommodate that by setting a flag or
> d/control header or some such.

We can't make this per-package without significant infrastructure work.
I would suspect that most cases where this kind of thing is an issue
would have been a problem in other ways sooner or later ...

> Or maybe an arch restriction in the DEP-8 control file for post-build
> testing?

DEP-8 testing is unaffected by this either way; and we already run DEP-8
tests on both amd64 and i386, so if your example of system-image were to
break then that would still be caught before reaching the release
pocket.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]