Packages going through NEW need to have binaries uploaded to enable the ftp-masters to do their review work. However, the Release Team doesn't allow binaries built by the uploader into testing. Until 2025, this meant that packages that have to go through NEW had to be uploaded twice before they could migrate to testing. Source packages that don't build arch:all binaries can be binNMU'd instead, but that doesn't work for arch:all binaries.

The DebianDak instance of Debian has functionality to throw away binaries after NEW review. That fixes the problem for most uploads to NEW.

Impact for most uploads

For most uploads, either nothing changes, or the additional source-only upload is no longer required.

NEW uploads to unstable main

For most uploads to NEW, this means that a second source-only upload is no longer needed to allow the package to migrate to testing.

For uploads to NEW targeted at unstable main, the binaries will be thrown away after the package is accepted. They will never get into unstable. The buildds will build binaries that will get into unstable and be able to migrate to testing (if the package is fine otherwise)

NEW uploads to unstable contrib, non-free or non-free-firmware

For uploads to contrib, non-free or non-free-firmware, the binaries are *NOT* thrown away. Some package here can not be built on the buildds, so they must be uploaded by a developer.

These binaries are allowed to migrate to testing.

If your package in contrib, non-free or non-free-firmware can be built on the buildds, it is still best to do a source-only upload after it goes through NEW, to ensure testing and unstable contain binaries built on the buildds. This can be done before or after the upload from NEW migrated to testing.

NEW uploads to experimental

Uploads to experimental are not affected. Binaries will not be thrown away. The binaries uploaded by the maintainer will go into experimental.

non-NEW uploads

Uploads that are not going to NEW are not affected. If a source is uploaded with binaries to unstable and it doesn't go to NEW, the binaries will not be thrown away (and if the package is in main, it will not be able to migrate to testing).

uploads to backports

For uploads to BACKPORTS-NEW targeted at stable-backports main or oldstable-backports-sloppy main the binaries will be thrown away after the package is accepted. The uploaded binary packages will never made available in stable-backports or oldstable-backports-sloppy directly. Instead the buildds will build binary packages from source that will become available in stable-backports and oldstable-backports-sloppy after they got uploaded by the buildds. This does not apply to uploads to contrib, non-free or non-free-firmware (see also above).

uploads to other suites

Uploads to other suites (testing-proposed-updates, (old-)stable-proposed-updates, security, ...) are not affected. Note that all these suites have their own specific workflow, and in most cases, pre-approval is needed before uploading.

binary only uploads

Binary only uploads to any suite are not affected.

Corner cases

There are some corner cases were specific actions are needed due to this change.

Bootstrapping binaries

If you package (transitively) Build-Depends on its own binaries, you'll need to take extra steps to ensure the package can be built.

When a source package that (transitively) Build-Depends on its own binaries is accepted from NEW, and the binaries uploaded by the maintainer are thrown away, the buildds will not be able to build the package. After 2 days, the source will be thrown away, because it has no binaries. This leaves only a small windows to do an upload of the binaries.

This problem only exists in unstable. Uploads to experimental don't have this problem, because binaries from NEW are not thrown away for experimental.

To avoid this race condition, packages that need bootstrapping should do the following: