In my previous post, I explained about the “age” excuse in Britney. In this post, I will cover the slightly more tricky “out of date” excuse. A simple example of excuse is:
out of date on mipsel: blinken (from 4:4.8.4-1)
In this simple case, Britney simply states that the binary “blinken” on mipsel has not yet been rebuilt.
Generally, the presence of an excuse like this is sufficient to stop testing migration. The exception to this rule is if the architecture has been marked as “not keeping up”. At the moment we do not have any such architectures.
The tricky part of an “out of date”-excuse is that Britney simply identifies a symptom and not a cause. In the excuse above, it is not possible to determine if the build failed on that architecture or simply has not finished yet.
But the part that probably confuses the most, is when Britney lists binaries no longer built from that source:
out of date on i386: libfsoframework0 (from 0.11.0-1.1)
This case actually happens quite often and is (usually) a sign of a transition has been started. The part that confuses many is that the “build-state” of their package will be “Installed” (as in “It was built successfully and has been uploaded to the archive”). From there they tend to conclude “Britney is broken”, where “The excuse information is a bit unhelpful” might be more accurate.
- If the source package has not yet been built on that architecture, these old binaries are interleaved into the “regular” list of “out of date”-binaries.
- The list of excuses are updated twice a day (and there is also a delay between its update and the PTS picking it up). Thus, if the “build-state” of your package for that architecture has been “Installed” for less than 24 hours, you may just want double check before jumping to conclusions.
The problem is that the binary still has reverse dependencies in unstable, so it cannot migrate to testing. When the last reverse dependency has been updated, the FTP masters will usually semi-automatically “decruft” your package and the excuse will disappear.
On the other hand, if the binary still has reverse dependencies, you probably started a transition. In that case, your package will be stuck in unstable until all the reverse dependencies are ready (or, at least, rebuilt to use the replacement package). Generally, it is good if the Release Team was involved before you did this (see “this page“).
In summary, if your package has “Out of date on [architecture]” in its excuses it can be one (or more) of:
- Your package is not built yet on the architecture. This is a transient problem, wait for the build servers to build your package.
- Your package FTBFS on that architecture. This is usually a permanent problem where you need to investigate why it happened and how to solve it. Sadly, often it can take weeks before someone files a bug against your package for this build failure, so being proactive might be worth your time.
- The binary is no longer built binary. This is usually a transition. If the binary packages listed has no reverse dependencies in sid and testing, then just wait for the FTP masters to decruft your package.