Didier Raboud dijo [Wed, Nov 21, 2012 at 09:21:19PM +0100]: > > > > I am asking why, when I had a reason to do so, was not able to do a > > > > source-only upload. > > > > Is this a feature of dak, or a policy enforcement? > > > > > > Both. > > > > I'd argue that it's a bug in both. > > > > BTW, can we have this as a release goal for jessie, that all packages have > > been build on Debian buildd infrastructure? ;-) > > Actually, I like that way to put it as it leaves us with multiple ways > forward: > > * accept source-only; > * drop uploaded binaries;
I would join this camp as well. Without the working knowledge of being a DSA or buildd-admin, I cannot assure how much would this increase our workload, but it would probably just mean rebuilding for the most popular architectures (that is, AMD64 or i386), hardware for which is readily available and should pose no additional effort to get. And it would mean IMO a good leap forward in ensuring buildability — Even more with arch:all > * (optionally: ) diff built and uploaded binaries, blame; This can be a bit more tricky. Of course, diffing the .build fails would not work, to begin with, because of the pathnames. But even diffing the shipped files — two shipped files are not guaranteed to be bit-by-bit identical, even if compiled in the same hardware. > What is yet unclear is if we want to build all (as in arch:any+all) or all > (as > in arch:any) packages on buildds. Rebuilding arch:all packages is quite important IMO. I would probably add a "rebuild when entering testing" where this to be a perfect world, to ensure continued buildability. But I know it's probably too much to ask... And it would still be incomplete (as "rebuilding anything that build-depends on this package" could still be added — And down this path we can find madness...) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121123163002.ga6...@gwolf.org