Release ======= For this team's purposes, the job is not done until the package gets into Debian Testing. This is a rigorous QA process the details of which can be read about elsewhere. The short version for us, is to run:: dev/rust-excuses.mk refresh all which will generate a nice pretty graph of packages trying to enter Debian Testing, along with their dependencies, and sometimes a colour representing the reason why it's being held back. (The colours could be more sophisticated, please help with improving the script. White does not always mean there is no problem; the excuses page is the authoritative source on the matter.) Generally, you should look at the bottom-most packages in this diagram, and deal with their issues first. More details for each package can be found at: https://qa.debian.org/excuses.php?package=rust-$crate or by clicking the relevant "Excuse" link on this team's `QA page`_. .. _QA page: https://email@example.com It should be fairly self-explanatory on how to deal with each of the issues mentioned on that page. Ask in #debian-rust or #debian-release or #debian-devel if you get stuck, whichever channel seems most suitable. Once you have dealt with all of the excuses, wait a day or so. If the excuses page then says "Will attempt migration (Any information below is purely informational)" and it remains in this state for more than 2 days, it means that we have failed "Migration phase 2", whose specific failure reasons are not mentioned in the excuses for `technical reasons`_. .. _technical reasons: https://release.debian.org/doc/britney/short-intro-to-migrations.html#migration-phase-2-installability-regression-testing However the reason is basically that there are other crates already in Debian Testing that depend on the old version of the $crate you were looking at, i.e. the one in Debian Testing not Debian Unstable. To view a summary of this, run:: dev/list-rdeps.sh $crate It will also give you some follow-up instructions to fix the problem. Source-only re-upload ===================== Two aspects of Debian infrastructure policy, run by two different teams, interact badly when it comes to the Debian Rust Team: 1. Uploads with new binary packages have to be done as binary (not source-only) uploads, into the FTP team's NEW queue. 2. Uploads that are valid candidates for Debian Testing have to be source-only uploads, to be considered by the Release team's migration script. For your convenience, ``./release.sh`` can do these quickly. After a binary-upload is accepted from the NEW queue, and you merge the relevant pending branch, do a source-only re-upload by simply running:: RERELEASE=1 ./release.sh <rust-crate-name> [<old-version>] Remove an obsolete package ========================== :: $ reportbug ftp.debian.org [..] What sort of request is this? [..] 6 ROM Package removal - Request Of Maintainer. [..] Choose the request type: 6 [..] Is the removal to be done in a suite other than "unstable"? Don't select anything for "unstable" [..] Choose the suite: # input nothing here, i.e. "unstable" Please enter the reason for removal: obsolete package, prevents others from migrating to testing Is this removal request for specific architectures? [y|N|?]? n [..] # An editor will spawn, probably nano. add # X-Debbugs-Cc: firstname.lastname@example.org # to the header, and then add the following text to the body: Hi, please remove this package on all architectures. It is an old rust library that is preventing newer ones from migrating to testing. Nothing else in the archive depends on it these days. # then save and exit, and proceed with submitting the report.