On 2015-08-22 19:19, Steve Langasek wrote: > On Sat, Aug 22, 2015 at 10:52:38PM +0200, Aurelien Jarno wrote: > > > This is all great news! > > > > If I'm not mistaken, the last feature that needs to be implemented in > > > wanna-build for us to be able to drop all maintainer-uploaded binaries, and > > > only ship binaries built on the buildds, is build architecture affinity for > > > architecture: all packages. What's the outlook on this happening? > > > We don't support architecture affinity, we basically treat arch:all > > almost like a normal architecture, and we have currently chosen to build > > it on amd64 (but we might decide to change that at some point or even > > built it on multiple architectures). > > Ok, I'm aware we don't currently support architecture affinity, but this > means that dropping maintainer-built binaries would give us a regression vs. > the state of the archive. There are various Architecture: all packages in > Debian that can *only* be built on a particular architecture. In fact you > appear to maintain most of them (openbios-ppc, openbios-sparc, qemu-slof, > seabios...) - packages which contain architecture-specific firmware, that > can only be built using the tools for that architecture. As said we can do some exceptions for these packages and allow them to be uploaded with the binaries. That will be a *progression*, not a regression and that means 99.9% of the archive will be built on the build daemons. > > I personally consider that if a user can install an arch:all package, > > he/she should be able to download sources, make changes, and build it. > > This is basically the spirit of the DFSG. > > Anyone can download packages for any architecture, regardless of whether > they have the infrastructure for that architecture that would allow them to > build the package. I don't agree that having one of these packages be Arch: > all instead of Arch: yogabbagabba means that the DFSG requires us to hold > them to a different standard. I don't talk about changing the Arch: field. I talk about downloading, modifying the source code, and rebuilding it. Currently we only allow that if the uses buy some expensive hardware just for this package. That's where the DFSG stands. > > I therefore believe that we should try to work to ensure arch:all > > packages can be built on all major architectures. That said, as a > > maintainer of such a package, I understand there is still some work to > > do first, for example by getting cross-compilers in the archive to build > > the firmwares. It would be quite interesting to build a list of such > > packages to have a better view of the work that has to be done. > > Unless there's other demand for these cross-compilers in the archive, this > sounds like a lot of busywork. Sure, a cross-compiler is a good option for > building firmware for some qemu architecture that's not self-hosting in > Debian, but are you really volunteering to maintain a sparc cross-compiler > just for openbios? Yes, and I already do that. For almost a year now, openbios can be built on all architectures. And the code for doing that is just less than 100 of lines (see debian/cross-toolchain.mk). I still have to do the same for the other similar packages. > > So in short we should try to fix these packages, but given they are not > > always easy to fix, we should just temporarily allow the upload of such > > binaries. > > This means that, in the meantime, we continue to be unable to prove the > correctness of (some subset of) the binary packages in the Debian archive. > I don't see why convenience of being able to rebuild an arch: all package on > arbitrary architectures, something that up to this point has never been > supported, should block / take precedence over providing our users the > surety of reproducible builds. It's clearly going to block reaching 100%, but it's not a good reason enough to block everything when we can easily reach 99.9%. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: Digital signature