Asking for wanna-build actions ============================== Intro ----- Members of the release team have wanna-buildd access, and can perform actions as needed, if appropriate. In particular, the release team takes care of scheduling all binNMUs, and can also perform other actions, particularly if they are blocking some package from migrating to testing. As announced in , give-backs and dep-waits should be requested by sending email to . This includes requests for experimental, but please mark them as such. binNMUs should be requested via bugs in the release.debian.org pseudo-package, with the usertag 'binnmu'. Using reportbug (>= 4.7) partially automates this, and is recommended. Syntax ------ Send a mail to the appropriate address with a more or less descriptive subject, and requests in the format described below. Please also include in the body any needed explanations, such as "build dependencies should be installable now", or (always) the reason a particular binNMU is needed. Each request goes in its own line, and specifies the type of request, a list of packages with versions, and a list of arches. All arches apply to all packages, so if two packages do not exactly share the list of arches, it's wiser to just give each package its own line. For dep-waits and binNMUs, a list of packages on which to dep-wait or a changelog entry, respectively, is needed. These are specified with -m, please do not forget it. The syntax is (note the dots, they are required): PKGS_VER . ARCHES [ . -m 'changelog entry/dep-wait expr.' ] gb is a "give-back" - a request to set the package's state to *needs-build*, i.e. to ask the buildds to try building it again, as if it was a new upload. A give-back does not directly move a package to the needs-build state, it first moves to "BD-Uninstallable", where it stays until the wanna-build system has ensured that build dependencies are installable. This check is done on a regular basis, several times a day. dw is a request to set the package's state to *dep-wait*. The string following '-m' is a dpkg dependency string, such as 'libfoo (>= 1.2.3)'. See for descriptions of the needs-build and dep-wait states. nmu is a request for a binary NMU, as described in the Debian Developers' Reference. The string following '-m' is a changelog entry, such as 'recompile against the new libfoo'. In the list of arches, "ALL" will be expanded to all architectures present in the suite; see the example below. Notes ----- * If your request applies to a suite other than unstable, the suite should be included as the third parameter. For example: nmu foo . amd64 . experimental . -m "Rebuild against the new libbar" * If you are asking for a dep-wait, an additional give-back is not needed. * If your request is for a dep-wait to be cleared, the syntax would be: gb pkg . arch . -o * If you're asking for binNMUs for a transition, you need not use this syntax, nor give a comprehensive list of packages: the release team has tools to auto-generate it, and will do so anyway. Just mention if any package should *not* be binNMUed for some reason. Full example ------------ To: debian-release@lists.debian.org Subject: Please binNMU foo and bar against fixed libfrob Hello, there was a bug in libfrob (<= 2.1-3) that made packages built against it DT_NEED libfrog1 instead of libfrob1. Only foo and bar seem affected. New libfrob is not built everywhere yet, some dep-waits are needed. Also, libfrob's build-dependencies are installable on mips now. nmu foo_4.3-3 . ALL -i386 . -m 'Rebuild against fixed libfrob, see #111.' nmu bar_2:1.0-7 . ALL . -m 'Rebuild against fixed libfrob, see #111.' dw foo_4.3-3 bar_2:1.0-7 . amd64 ia64 s390x . -m 'libfrob1 (>= 2.1-4)' gb libfrob_2.1-4 . mips Thanks.