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@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
