On 2013-06-13 10:34, Ansgar Burchardt wrote:
On 06/13/2013 10:49, Santiago Vila wrote:The web page "update excuses" today says this about base-files: Generated: 2013.06.12 22:06:17 +0000 * base-files_pu (7.2 to 7.1wheezy1) + Maintainer: Santiago Vila + ALERT: base-files is newer in testing (7.2 7.1wheezy1) which I don't understand, specially the "7.2 to 7.1wheezy1" part. Is any program trying to update from 7.2 to 7.1wheezy1 "somewhere"?
No.
Such thing should certainly not happen in stable (as stable has 7.1)and it should not happen in testing either (as the 7.1wheezy1 upload wasfor stable only). Should I worry about this?
No.
Is which way is this information correct?
It's certainly not incorrect, but I can appreciate it may be confusing. Hopefully the explanation below helps there.
That should be the release team's playground.I don't know why they report on version in p-u compared to testing, butit probably doesn't mean anything bad.
So... there are several packages in p-u currently that have a version which is higher than that in testing. Those will need to be resolved before or during the point release, in order to ensure that the archive's version constraints are maintained; this is not an uncommon situation in itself. Where possible, we do that by making sure that the package in unstable migrates in time. However, in several cases that's not possible right now due to RC bugs, ongoing transitions or similar.
In such problematic cases, the available solution is therefore to copy the package from p-u in to testing. We can ask ftp-master to do so during the point release (and will for those packages which also need to be copied to unstable, such as user-mode-linux and d-i) but where possible it makes more sense for us to handle it directly. Previously we used to hand-modify the result of a britney run and import that dataset, but that has the potential for errors (on our part) and provides no sanity checking in terms of installability.
We've therefore enabled a function in britney which allows _on demand_ for a package from p-u to be considered for migration to testing, in the same way as t-p-u packages are (in fact, it's exactly the same code branches). This allows us to say "please migrate package X from p-u" and have britney perform the usual checks on installability. The default condition, as with t-p-u, is that nothing happens for a particular package unless a member of the release team adds a hint to "approve" the migration.
This is the first time we've used the code "in anger", as the early stage of the cycle means that there are currently several situations where we're unable to migrate packages from unstable but still need to take some action in order to be able to include packages in the point release. I anticipate that we may well disable the functionality again in a day or so, but will look at how we can make things less confusing. As an aside, the information is not visible unless one is reading the excuses file directly, or uses the "right" package name - that is, "grep-excuses base-files" will *not* show the warning quoted; one would need to use "grep-excuses base-files_pu".
Regards, Adam