On 14/02/14 08:13, Paul Tagliamonte wrote: > On Thu, Feb 13, 2014 at 09:10:15PM +0000, Dimitri John Ledkov wrote: >> On 13 February 2014 16:13, Holger Levsen <email@example.com> wrote: >>> Hi, >>> >>> On Donnerstag, 13. Februar 2014, Ondřej Surý wrote: >>>> this is just a pledge to you all fellow debian developers to update your >>>> build environment before you build a package. >>> >>> I want all binary packages to be rebuild on *.debian.org hosts. Everything >>> else is just an ugly workaround. >>> >> >> All that's needed, I guess, is for someone to write a patch to dak / >> wanna-build ... and schedule _all.deb builds on amd64 ? >> Or if arch-restricted package, on one of the arches it will build on? > > The LP folks wanted to sync on this. I also wrote this for Debile, I > called it arch affinity (I think LP uses the same name). We should pick > a name and use it for all 3. > > I also think it should be a static arch (rather then any arch that > can build it), so that things are a bit easier to duplicate and debug. > Might as well. Right, "arch affinity" is the term we use for the desirable feature of being able to override the architecture that by default builds architecture-independent packages ("nominated arch-indep" in LP parlance). We have https://bugs.launchpad.net/launchpad/+bug/217427 about supporting that. It's simple to fix, but has mostly been blocked on needing to decide on a field name with other interested parties. It sounds like we should really just work something out together -- this has been going on long enough :) (There are still some cases for which the semantics of the Architecture field are unclear, even with arch affinity. https://bugs.launchpad.net/launchpad/+bug/1063188 is one such example: hhsuite is "Architecture: amd64 all", our nominated arch-indep is i386, so the arch-indep bits don't get built. Presumably once we have an arch affinity field we can assume that its absence means we can just pick one of the buildable archs and do indep there, but wanna-build, LP and other implementations should probably decide on the same behaviour here. Other than that it all seems like mostly a naming thing.) William.
Description: OpenPGP digital signature