Hi 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 found <testing-version>). * 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 ftp.debian.org. Note that some of these are not introduced by the new version that was uploaded, but were introduced in one of its dependencies. Cheers Luk 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe6bfbf.6050...@debian.org