On 14-Jul-2024, Chris Hofstaedtler wrote: > TTBOMK the rules currently are: source-only uploads are perfectly fine > and desirable. In a few exceptional cases, binaries must be provided; > these are (at least): introduction of new source package (= "NEW"), > introduction of new binary package (= "binNEW"), upload of a non-free > package that is not auto-built. > > > > > Where can I read more to understand what went wrong here and how to > > > > not have a package blocked this way? > > > > > > https://lists.debian.org/debian-devel-announce/2019/07/msg00002.html > > > second section. > > > > Oh, I had interpreted that differently: that the binary packages would > > not migrate, but that the source package would be re-built and *that* > > would migrate to testing. > > > > You mentioned that the build daemons do not build “Architecture: all” > > packages? Is that a temporary fault, or is it intentional? > > The buildds can build "Architecture: all" packages. However, large > parts of our infrastructure and customs are not prepared to deal > with rebuilds of "Architecture: all" packages, so this is not done. > > I'll point out that any rebuilds on buildds also change the version > number, e.g. by appending +b1 (or higher).
Thank you both. I can guarantee that this complex knowledge will not stick, and I can't find it laid out anywhere obvious (e.g. the FTP masters site) to find for authoritative reference later. Are these rules and conditions and branching instructions, for when and what to upload with a package release, explicitly and clearly laid out, in an obvious place (not a paragraph addressing a single release in a mailing list discussion) for any Debian developer to find? If not, it seems these confusions and delays and blocked migrations are far more likely to continue indefinitely. -- \ “Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney <bign...@debian.org>
signature.asc
Description: PGP signature
