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 [[email protected]] _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
