Debian NMU Delayed Queue System Explained

When a Debian contributor performs a Non-Maintainer Upload (NMU) to fix a bug in a package they do not officially maintain, the upload is typically routed through the Debian delayed queue system. This system acts as a temporary holding buffer on the Debian upload servers (ftp-master), giving the package's primary maintainer a designated grace period to review the proposed changes, acknowledge the fix, upload their own alternative revision, or cancel the upload altogether before it permanently enters the archive.

Purpose of the Delayed Queue

In the Debian workflow, maintaining package ownership and coordination is paramount. While NMUs allow contributors to fix release-critical bugs, apply important patches, or resolve long-standing issues, uploading directly without maintainer consultation can cause conflicts.

The delayed queue balances package velocity with maintainer autonomy. It provides:

  • A safety buffer against unintentional breakages or duplicate work.
  • Time for the package maintainer to react, review the diff, or apply a cleaner long-term fix.
  • A predictable timeline after which fixes automatically deploy if the maintainer is inactive or unresponsive.

How the Staging Process Works

When an uploader prepares an NMU, they specify a target delay window—typically ranging from 0 to 15 days—using their upload client (such as dput or dput-ng):

  1. Targeting the Queue: The contributor uploads the package to a specific delayed directory on the host (e.g., ftp-master.debian.org under DEFERRED/N, where N represents the number of days from 0 to 15).
  2. Notification: Once the package is received by the Debian Archive Kit (DAK), an automated notification including the .changes file and patch information is dispatched to the maintainer via the Debian bug tracking system (BTS) and the package's mailing list address.
  3. Daily Decrements: A scheduled cron job runs daily on the archive servers. Each day, packages move down one level (e.g., from DEFERRED/5 to DEFERRED/4).
  4. Archive Ingestion: When a package reaches DEFERRED/0, the archive software moves it directly into the regular incoming processing queue, where it is accepted into the unstable (Sid) repository.

Typical Delay Conventions

Debian NMU guidelines prescribe recommended waiting times based on the urgency and nature of the fix:

  • 0-day (DELAYED/0): Used when the maintainer has explicitly approved the NMU, for security team uploads, or during urgent release transitions with authorization.
  • 2 to 5 days: Common for release-critical (RC) bugs close to a release freeze, or when prior notice was already provided on the BTS.
  • 7 to 10 days: The standard default for regular NMUs addressing non-RC bugs or standard upstream updates, providing maintainers adequate time across work cycles and weekends.
  • 15 days: The maximum allowable delay, reserved for non-urgent changes or major disruptive updates.

Actions Maintainers Can Take

During the delay period, the maintainer retains full control and can take several actions:

  • Acknowledge and Accept: The maintainer can do nothing, allowing the package to count down and enter the archive automatically.
  • Supersede: The maintainer can upload their own new revision to the archive (using a higher version number), which supersedes the NMU.
  • Cancel or Reschedule: Both the maintainer and the original NMU uploader can interact directly with the delayed queue by uploading a cryptographically signed .commands file. This mechanism allows them to delete the queued files or alter the delay counter (either speeding it up or postponing it).