cmp is gone in python3. Also add a sorting method to Excuse that is
compatible with its __eq__/__hash__ methods.
Signed-off-by: Julien Cristau <jcristau@debian.org>
It doesn't exist in python3, but 1000 days should be safe enough as a
fallback for a package without urgency.
Signed-off-by: Julien Cristau <jcristau@debian.org>
- split the one-liner into a for and an if
- use open() as a context manager
- don't use string.strip which is gone in python3
Signed-off-by: Julien Cristau <jcristau@debian.org>
Done as kFreeBSD is not a release architecture and it has started to
block migration of release related changes. I have kept it out of
"BREAK_ARCHES" as I do not yet see a reason to add it there.
Signed-off-by: Niels Thykier <niels@thykier.net>
The "remark" hint is only intended for showing up in the output of "d"
(or via hint grep). It has no effect on Britney's behaviour.
Admittedly, the original code would have ignored it as well. But this
change makes it explicit and not simply a "ignored due to insufficient
permissions".
Signed-off-by: Niels Thykier <niels@thykier.net>
For out-of-date binaries, generate different excuses when the build is
missing, or when old (cruft) binaries for previous version are still around.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
No longer necessary during the freeze, since they'll need an unblock
anyway, at which point age can be adjusted as well if necessary.
This reverts commit 6891fa39f6.
Signed-off-by: Julien Cristau <jcristau@debian.org>
As agreed in the Jessie timetable, mandatory 10-day
ageing is in place for the freeze, starting today.
Signed-off-by: Jonathan Wiltshire <jmw@debian.org>
As part of a migration, we remove all the existing binaries built by
the source (possibly on a particular architecture) from testing; this
includes architecture-independent binary packages. However, when a
binNMU is in *pu, only the arch-dependent binary pakcages are present.
As a result, after the migration the architecture-independent packages
are no longer present in testing. This usually isn't a practical
problem, as dak will re-add them when it generates the packages files.
It is, however, wrong and will break if a source migration is tempted
during the same run as (and after) the *pu binary migration happened.
The simple fix is to not remove the architecture-independent packages
when performing such migrations.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
In the rare case that a hint removed an uninstallable binary, the
binary could still be included in the nuninst counter.
Regression introduced in a46dd88.
Signed-off-by: Niels Thykier <niels@thykier.net>
sort_actions() can be quite expensive and it is wasteful to resort
actions after each successful "easy"-hint.
Signed-off-by: Niels Thykier <niels@thykier.net>
There are no uses of "lundo" left for a non-hint recurse run (i.e.
the "main run"), so there is no point in building it.
The "lundo"-list is still used in the recurse run of a "hint"-hint.
Signed-off-by: Niels Thykier <niels@thykier.net>
The "do_all"-method now checks the architectures of all changes
applied. If they entirely consist of items from "break archs", then
"do_all" will disregard the current "break archs" setting when
comparing nuninst counters.
This change avoids unintended installability regressions on break
arches when a hint (manual or automatic) apply only to packages on
break arches.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rename local variables and avoid repeated chained lookups. In
particular, avoid confusing cases like:
[...]
version = binaries[parch][0][binary][VERSION]
[...]
binaries[parch][0][binary] = self.binaries[item.suite][parch][0][binary]
version = binaries[parch][0][binary][VERSION]
Where "version" here will refer to two different versions. The former
the version from testing of a hijacked binary and the latter the
version from the source suite (despite the look up using the "testing"
table, due to the testing copy being updated).
Notable renamings:
* binaries => packages_t (a.k.a. self.binaries['testing'])
* binaries[parch][0] => binaries_t_a
* binaries[parch][1] => provides_t_a
* Similar naming used for "item.suite" instead of "testing"
The naming is based on the following logic:
* self.binaries from "packages" files
(by this logic, it ought to be "self.packages", but that is
for later)
* The "_X_a" is short for "[<suite>][<parch>]" look ups.
* binaries_X_a and provides_X_a are the specialised parts of
packages_X_a that deal with (real) binary packages and
provides (i.e. virtual packages) respectively.
Signed-off-by: Niels Thykier <niels@thykier.net>
When trying to break a choice, try the candidate out and see if we can
pick it without any consequences. Basically, if the candidate causes
no new conflicts or choices, we can safely pick it.
Signed-off-by: Niels Thykier <niels@thykier.net>
For some cases, like aspell-dictionary, a number of packages can
satisfy the dependency (e.g. all aspell-*). In the particular
example, most (all?) of the aspell-* look so similar to the extent
that reverse dependencies cannot tell two aspell-* packages apart (IRT
to installability and co-installability).
This patch attempts to help the installability tester by detecting
such cases and reducing the number of candidates for a given choice.
Reported-In: <20140716134823.GA11795@x230-buxy.home.ouaza.com>
Signed-off-by: Niels Thykier <niels@thykier.net>
Extract a specialised iter_packages_hint from iter_packages that only
deals with applying hints. This simplifies iter_packages AND avoids
having to re-compute the uninstallability counters after each single
item in the hint.
This means that a hint can now avoid triggering expontential runtime
provided only that the "post-hint" stage does not trigger expontential
runtime. Previously the hint had to be ordered such that none of the
items in the hint caused such behaviour (if at all possible).
Signed-off-by: Niels Thykier <niels@thykier.net>