When you want the unstable version of your package in the release, it
needs to be ready to migrate when it has aged enough in unstable.
Reasons why it can not be ready:
* RC bugs against the version in unstable that are not present in the
version in testing (according to the BTS). If the RC bug is also present
in the version in testing, you have to let the BTS know (with a bts
* package in unstable is not installable when migrated to testing. It
can conflict by means of a Conflicts or Breaks relationship with a
package in testing or it can need a version of a package which is not
available in testing.
* there are out of date binaries for some architectures. When you look
at the output of rmadison ls <binary-package>, you'll see that there are
multiple versions for the release architectures for sid. If there is
only a difference due to binNMUs or hurd-i386, it's no problem. In all
other cases it won't migrate and it has to be fixed either by getting
the builds done or by filing an architecture specific removal bug to
Note that some of these are not introduced by the new version that was
uploaded, but were introduced in one of its dependencies.
PS: The reason I send this clarification mail is because I saw that some
RC bugs are not fixed in testing because of new upstream versions that
do not build on all previous architectures anymore.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org