hi Simon, On Sun, Nov 13, 2022 at 03:49:13PM +0000, Simon McVittie wrote: > I've had the attached sitting in my outbox for a while and I think it's at > least a good start towards what Marc requests? yes, thanks a lot! > I have deliberately not documented the precise meaning of needing to > include binary packages for NEW, on the basis that the conservative thing > to do is to include a complete set (debuild --full). My understanding is > that *technically*, the upload does not need to include *every* binary > package, but that the ftp team would prefer uploads to NEW to include > everything from debuild --full, except in rare special cases such as > the kernel, whose maintainers already know what all the tradeoffs are. this could also change very easily, there's already an option in dak which allows throwing away binaries after the package passed NEW. (=this would mean one needs to upload a binary build to NEW still, however the binaries would be thrown away when the packages moves to unstable, thus automatically triggering a build on the buildds, allowing testing migration later.) this option has not been enabled yet however. > Similarly, I have deliberately been a bit vague about whether uploads > that will add a package to a suite other than unstable/experimental > need binaries, because I don't know whether they do or > not. unstable/experimental NEW definitely needs binaries, I *think* > backports-NEW also needs binaries but I'm not sure, I think so too. > but I think new > additions to -security can/should be source-only? no idea :) > I have also not attempted to improve §5.10 "Porting and being ported", > which seems to have been written from a circa 1998 perspective where all > maintainers uploaded source+i386, binaries for other architectures were > often hand-built by porting teams, and the ability for a package to be > autobuilt successfully was somewhere between "optional but recommended" > and "newly required". It could probably benefit from restructuring or a > rewrite, but I don't think I'm the right writer for that. *nods* > > I THINK that arch any packages get an automatic binNMU to avoid that. > My understanding is that the release team often schedule a binNMU to > be helpful, but it is not automatic. yes, it's scripted but needs to be triggered manually. also this doesnt work for arch:all packages. > We can give simpler advice if we > ignore these binNMUs, which seems better to me anyway - maintainers of > source packages with at least one "Architecture: all" binary package > have to do a sourceful upload regardless, and I'd prefer to encourage > maintainers to be responsible for their packages' migration to testing > rather than centralising that responsibility into the release team. same here. thanks again, will merge and upload now! :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Punk ist nicht tot. Punk trägt Maske, ist solidarisch und schützt sich und andere. (@Kreuzpirat)
Attachment:
signature.asc
Description: PGP signature