The manual hint described in the previous commit turned out
to be impossible to solve. This was not due to the autohinter.
Revert "Disable autohinting again"
This reverts commit 61ebd414d49bd6d3df90a9df324812d4f35c31e5.
The autohinter seemed to be grouping packages together
and creating hints for them, but it seems manual hints
were not being processed correctly.
e.g. there was a recur: [] line, but no got: line
and no indication whether the hint was successful or not,
and packages included in the hint did not migrate.
Revert "Re-enable autohinting"
This reverts commit ad8f36c2d1899aaec3688dc6f9ee28b3e22774ff.
This will hopefully help with the ocaml transition, but more in general
we'd like to see if this improves britney's heuristics. The commit that
implemented the auto-hint skip (3e28539c17e020ecf) mentions a recursion
problem, but what exactly caused that and what the consequences were is
not clear. Re-enabling autohinting will allow us to reassess that.
Revert "Temporarily disable autohinter due to a recursion problem"
This reverts commit 3e28539c17e020ecf6233f41fba2a1fdf3816b59.
the autohinter is currently hitting the default Python stack limit; we should
try raising it, this is the intended britney behavior and the system is here
primarily to run proposed-migration so we should not be constrained by the
default
For rolling out britney on a new machine, we want to generate update_excuses
and update_output to confirm it's working correctly all the way through, so
we don't want to use the global --dry-run option; but we *do* want to
disable queuing tests and instead let the production instance of britney
queue the tests while we simply query the results. Add support for
ADT_ENABLE=dry-run in britney.conf, parallelling the behavior of other
policies.
This check has been present for a long time but there is no reason for it -
there is code elsewhere that explicitly checks for both options being set
together and DTRT. And this saves a minute on each britney run to not
regenerate uninstallability information that was just generated.
Launchpad currently doesn't enforce this, so it doesn't make too much
sense to do so in proposed-migration.
Once https://bugs.launchpad.net/launchpad/+bug/1868558 is fixed, we
should think about probably re-enabling this.
On some distros (Ubuntu), arch:all packages are built along with one of
the architectures. We shouldn't be listing 'all' as its own arch in this
case. Instead we filter out the binaries except for on the
'all_buildarch'.
It works like this. We wait until all tests have finished running. and
then grab their results. If there are any regressions, we mail each bug
with a link to pending-sru.html. There's a state file which records the
mails we've sent out, so that we don't mail the same bug multiple times.
We want to treat linux-$flavor and linux-meta-$flavor as one set in
britney which goes in together or not at all. We never want to promote
linux-$flavor without the accompanying linux-meta-$flavor.
Add a new LinuxPolicy which runs after most of the other policies, which
invalidates linux-foo if linux-meta-foo is invalid.
Hint to allow smooth update, even if the section isn't allowed in the
configuration.
Note that this takes the source name and the source version IN TESTING
of the binaries that must be allowed to stay around to allow a smooth
update.
Adding a source parameter to the SourcePackage allow finding the source
the object is referring to, so that parameter doesn't have to be passed
along separately.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When an allow-uninst hint is added for an unversioned binary package, items
are allowed to migrate, even if they make that binary package uninstallable
(on the architecture specified in the hint, if one was specified, or on all
architectures otherwise).
Using this hint should avoid using force-hint to allow specific breakage.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
When do_all fails, and there is no transaction to rollback, we will probably
leave a broken state behind. This codepath probably isn't triggered unless
something else is broken.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
If the cruft removal item has a different version than the binary currently in
testing, then the cruft item was replaced since it was added, or it was added
in error. In this case, the item should not be processed.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
