| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
For some reason I have them in my log file.
|
| |
|
|
|
| |
This will particularly be useful in the next commit; just
strip the path form the commandline.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
autopkgtest run on stable can have an uname like "6.12.41+deb13-amd64".
The +deb13 being relatively new in the package name. The code doing the
autoremoval has no problem with it and its a legal package name, but
the test that wants to check if the right regexes are generated does not
escape the + correctly (aka at all) so it isn't finding the regex it is
looking for failing the test.
|
| |
|
|
|
|
|
|
| |
Tests usually print the command they run, but it can be overridden with
a chosen message to make clearer what is actually tested. To debug
failures it can be useful to know the command run through especially if
its a partly generated command depending on the test environment
(like in the kernel autoremove test).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Lots of people have pinned an older version that is no longer
installable, or more common yesterday, we saw a lot of people
who seemingly manually installed a newer version of a deb than
in the repositories, causing the package to be considered obsolete,
which does not make much sense.
Oops: 4c39d922-410f-11f0-bbf9-fa163ec44ecd
Oops: a64054f6-4140-11f0-bbfd-fa163ec44ecd
Oops: a32196c1-661d-11f0-a97c-fa163ec8ca8c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of inadvertently sorting dependency targets against
the first alternative in an or group, sort them against the
current alternative as we should.
Otherwise we ended up sorting
gnome-shell | notification-daemon
With
Package: notification-daemon
Package: awesome
Provides: notification-daemon
into
gnome-shell | awesome | notification-daemon
<-we sorted this part wrongly->
This fixes a minor difference in test-release-candidate-switching
in one case, but not the other where the difference was actually
caused by the loss of install argument ordering information in
the new solver, so just flip the arguments so both solvers produce
the same outcome.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a server responds with two InRelease files, but one
is good, and the other indicates a temporary error, we
queued the other indices from the good repository for
downloading and then queued the retry.
The resulting queue ended up with items having fetchAfter=0
before the item with fetchAfter=<something>, causing the
Run() loop to not detect a stuck queue.
Change the order of the queue such that the highest retry-after
items comes first; this ensures that we always see stuck queues.
This of course changes the behavior of retries in that if one
file fails temporarily we block the entire server. This does
seem more beneficial in the common case - if one file fails,
probably all of them fail, and there's no point bombarding
the server with requests for indices from good repositories
until all have failed.
The actual root cause is more that the remaining items are
Enqueued like this:
1. Enqueue jammy/InRelease (delayed)
2. Enqueue jammy-updates/main all Packages
The resulting queue ended up being:
jammy-updates/main all Packages
jammy/InRelease (delayed)
But Enqueue() only calls Cycle() when there are no items in
the queue already - after all, any item that is already running
will call Cycle() eventually. Or so was the case until we added
the retry-after handling.
It's unclear why we don't Cycle() all the time when enqueuing
a new item, given that our pipeline might not be filled yet,
and we could send the request to the server while waiting for
data on a running item.
Trying to always Cycle() however led to regressions that still
need investigating. Given that, this solution certainly is the
more easy to reason about one.
LP: #2003851
|
| |
|
|
|
|
| |
When inspecting Recommends of installed packages, filter
them to the installed packages only, as we want to avoid
switching between alternatives of recommended packages.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In case a new version of the source package is published, we
check that if there's a newer binary for the same architecture
and then consider the binary obsoleted.
This logic did not properly account for Architecture: all packages
which are considered as native architecture package with an "All"
multi-arch flag set, and hence a native architecture package may
inadvertently be considered obsoleted by a package that only built
on Architecture: all.
|
| |
|
|
|
| |
Avoid or groups and dependencies on different (virtual) packages,
to avoid some common pitfalls like the added xorg test case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge any hard clauses into optional clauses, such that
optional clauses don't end up with more choices.
For example if you have
Depends: a | b
Recommends: a | c
This becomes:
Depends: a | b
Recommends: a
We have simulated this with the chaos-actor in the test case
and a
Depends: git (not satisfied by chaos provider)
Recommends: git (satisfied by chaos provider)
and the latter constraint is limited to the former.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a package declares multiple dependencies that can be solved by
the same packages we should use the common set of packages to
solve them.
A common example is requiring the same Debian source version, or the
same upstream version as in our test case:
git-ng Depends: git (>> 1:2.26.2), git (<< 1:2.26.2-.)
The solver expands this to the concrete objects:
git-ng Depends: "real git" (= 1:2.26.2-1) | chaos-actor, "real git" (= 1:2.26.2-1) | "real git" (= 1:2.25.1-1)
When given an upgrade request, the solver would now choose
chaos-actor to satisfy git (>> 1:2.26.2)
"real git" (= 1:2.25.1-1) to satisfy git (<< 1:2.26.2-.)
To satisfy the two constraints, which is not the intended outcome.
Address this problem by introducing a concept of merged clauses:
If two dependencies of a package have overlapping solutions, replace
the dependency by the intersection, and record the merged clause
instead, this leads to a single clause:
Depends: git (>> 1:2.26.2) and git (<< 1:2.26.2-.)
which expands to just the real git binary.
The implementation is a bit finicky in that it removes the variables
from the original clause which may not be helpful for debugging, but
it records the clauses merged with, as seen in the test case, so the
reasoning is clear.
LP: #2111792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we have allowed the removal of manual packages, assume them
all before starting the solver. This should ensure that as long
as there is a solution that does not remove a manually installed
package, it is found.
This requires a sweeping set of changes in the test suite, but
ensures that we get "safe" behavior from the solver. We have
in particular seen that without asserting the installed packages,
several people ended up with ubuntu-minimal and perl removed in
a situation where that was not warranted, that is, they install
winehq, and then pull in some new perl packages in a newer version
than the installed one, and the solver chose to create a mismatched
version set, which then caused the main perl package to not be
installable.
Oops: 1b55173a-3526-11f0-b7ac-fa163e171f02
Oops: dbd5149e-36b9-11f0-bb74-fa163ec44ecd
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
These are implemented somewhat differently from aptitudes
why and why-not commands: They produce the actual solver
trace for why a particular decision has been taken.
For the why-not case, we need to explicitly discover our
specified package, as if nothing else depends on it in
our graph, it would otherwise always be undiscovered and
conflicts not detected (see e.g. level-3 in the test).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
'Include' allows limiting a repository to a allowlist of packages,
'Exclude' allows removing packages from a repository.
Implementation wise this is not the nicest as it goes via the
IndexTarget options, so we first parse our option value into a
vector, then we turn the vector into a string, and then vectorize
it again. That said, we support both "," and " " as separators due
to the construction (we split by "," then we join using " ").
Gbp-Dch: full
|
| |
|
|
| |
Make the test suite independent of the host sequoia config.
|
| |
|
|
|
| |
There was an accidental exit in the if causing the test to exit
early, but the test suite still to pass.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This implements a simple check where we first run `sqv` with
`--policy-as-of` 1 year in the future. If the file is validly
signed one year in the future, it is validly signed now.
If the file is not validly signed 1 year in the future, we check
if it is validly signed now, and otherwise print an error message.
The --policy-as-of feature was added in sqv 1.3.0, hence we add a
version requirement to the dependency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We inadvertently considered more upgrades as a better solution in
all cases, but if we are *installing* rather than upgrading, we
should count upgrades as a negative.
Change the code to accomodate that. This requires a few more
tricks:
- We remove the keep count check. This does not appear to work
correctly and would have prevented the fix. We are already
counting all possible changes, so why bother.
- We need to subtract the upgrade count from the install count
(upgrades are a class of installs) since we now allow comparing
solutions with different upgrade counts for install counts.
- After comparing the "new install count", we now compare upgrade
count too, in the opposite direction of upgrading.
To test, we abuse that solver 3.0 does not upgrade all packages
in a source package when using the install command.
LP: #2105395
|
| |
|
|
|
|
|
|
|
|
|
| |
Sync the LESS environment with systemd to make it more user-friendly
than just a blinking colon:
- S disables the terminal bell
- M makes the output verbose, so the prompt is not ":" but "lines 1-n"
- K means that Ctrl+c exits the command
Also fix the LV= environment variable to use -c and not C.
|
| |
|
|
|
|
| |
The error messages are multi-line now, so need correct escaping.
LP: #2104276
|
| |
|
|
|
|
| |
Use setenv() to avoid overriding user defined variables.
LP: #2103921
|
| |
|
|
|
|
|
|
|
|
| |
As a followup to the previous commit, restore the exact behavior
of the old solver to break the Suggests on upgrade here by erasing
any choices not previously installed.
This ensures that the Suggests never installs any new package, but
it will still retain previously installed packages when solver3 is
doing autoremove.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #2103556 we can see that avahi-daemon Suggests avahi-autoipd,
which is previously satisfied by dhcpcd-base due to a Provides;
that Provides has now been dropped; and solver3 keeps the update
back.
As in LP: #2102720 this is a Suggests and it seems wrong for the
Suggests to actually influence dependency choices and be able to
hold back updates.
Instead, satisfy previously satisfied Suggests at the end. For the
particular case in this bug report, this results in avahi-autoipd,
the real package, to be installed to keep the Suggests working
which needs further consideration whether that is the right choice
(we can argue either way), but in any case this is a better solution.
This in turn breaks the conkeror test which is a somewhat awkward
unrealistic test these days as it has no automatically installed
packages; because previously something must have had a Suggests
on say libdatrie1 or something that was processed first.
This would be fine before 5daf6dbfd272be2f8e3c59d4bab4be8c119b7aa1
but as of that commit we no longer rewrite
conkeror Depends xulrunner-1.9 | xulrunner-1.9.1
into
conkeror Depends xulrunner-1.9.1 | xulrunner-1.9
Because xulrunner-1.9 is manually installed. Mark xulrunner-1.9
as automatically installed to fix the test case.
The resulting behavior seems correct: If you manually want
xulrunner-1.9 specifically we should not replace it with
xulrunner-1.9.1; but if it's automatically installed we should.
LP: #2103556
|
| |
|
|
| |
whoopsie does not accept empty values
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Store the solver dumps with zstd compression and base64-encode
them in the crash report; such that they take up significantly
less space and can fit in cassandra's schema.
Base64 is wrapped at 76 characters as the base64 tool does. Do
some magic std::string_view conversion to avoid string copies
for the substr() used to get 76 characters at a time.
Note we can rely on substr(i, 76) to handle less than 76 characters
just fine; it uses std::min(76, size() - i) characters.
|
| |
|
|
| |
These are faster to generate and significantly smaller.
|
| |
|
|
| |
indextargets --format
|
| |
|
|
|
|
|
|
| |
Particularly as Helmut pointed out we need to show which version we
selected for install if there is only one but there is a versioned
conflicts.
Reported-By: Helmut Grohne <helmut@subdivi.de> on IRC
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reorder the if branches a bit to simplify the understanding
of the promotions, and allow us to keep track of which
dependency existed in the installed version.
Change the rule for promoting new recommends to only promote
new recommends to depends in *upgrade* and not *dist-upgrade*
per the test-resolve-by-keep-new-recommends test case.
This makes some sense: In a dist-upgrade, the solver could
otherwise decide to remove an installed package if both the
following hold:
(1) something needs the upgraded version | something else
(2) the upgraded version is not installable due to unsat recommends
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We accidentally considered an Enhances a reason to keep
a package installed, which of course it is not, fix the
determination of "existing soft dependency" to only include
soft dependencies that should keep a package installed in
the autoremover to solve the issue.
This also fixes edsp/mantic-upgrade-rel-to-2024-05-29.edsp
to not install llvm-13-dev for clang-13 which is an installed
package with no upgrade.
Also ensure we stop after the first match; the DependsList()
is ordered by decreasing priority and we don't want to override
Recommends by Suggests in case a package declares both...
LP: #2101800
|
| | |
|
| |
|
|
|
|
| |
We incorrectly used the DependencyData of the first or group
member, however that only checked that the first or group member
was the same and that both either had a next member or not.
|
| |
|
|
|
|
|
|
| |
The upgrade code may also set Upgrade: yes, and this sets both to
yes, so `apt upgrade` dumps behave like `apt-get upgrade` ones,
which of course is not intentional.
moo
|
| |
|
|
|
|
|
|
|
|
| |
Only move obsolete packages last that are automatically installed,
as we don't want to remove manually installed obsolete packages.
Add some missing const annotations to the operator[] arguments as
well that were needed.
LP: #2100247
|
| |
|
|
|
|
|
|
|
|
| |
This can provide useful additional context.
To avoid updating the whole test suite for it, introduce a new
option `quiet::NoSolver3Explanation` and set it by default. All
the other tests that assert output will already have matching
tests for --solver 3.0 with the correct messages asserted, it
makes no sense to duplicate them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Always run the 3.0 solver after the internal solver. If the internal
solver failed, and the 3.0 solver did not, use the 3.0 result.
If 3.0 solver failed or produced a worse result than the internal
solver, write an apport crash dump.
We exclude situations which we now the solver can't handle, i.e.
removals are forbidden and you requested removals, and stuff like
that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new function, LongWhyStr() that returns a longer
reason for why something is being installed (or not).
This does the same path walk as the other function does, but
it renders the clauses at each level, and one per line, so
the whole output is a lot more informative.
It is a separate function to keep the existing debug messages
use the simple single line implication graph
We remove the other special case in AddWork() for empty solutions
to mke use of the general case in Solve() instead, and then adapt
the case in Solve() to the same case as in Enqueue(). This also
happens to fix the bug that when we encountered an empty clause
we just printed the clause had no solution, but not how we got
to install the package with the clause.
Adapt the test suite for the changes which is an annoying amount
of paperwork.
|
| |
|
|
|
| |
This is important for upcoming multi-line solver error message
work.
|
| |
|
|
| |
Reported-by: cacin on irc
|
| |
|
|
|
|
| |
This allows solvers to optimize by download size; and gives us
a better means of interpreting "downloadable" debs (they must have
a size > 0 after all).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
apt-ftparchive skips regenerating Contents if they are newer than
the Packages files. Most of the time, the test ended up generating
Contents and Packages files with the same-second timestamp; so we
ended up regenerating them and passing the test.
However, sometimes, the timestamp of the Contents file was 1s
higher and we ended up not regenerating the Contents file and
hence failed the test case.
Ensure the timestamps actually are the same to avoid the race
condition and make this stable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VersionExtra holds, at runtime, the SHA256 of the packages being
added to try to avoid deduplicating obviously different packages;
the SHA256 itself is too large to store in the cache.
When volatile sources are used, the VersionExtra array is not
initialized, or rather it used to be initialized to 32*1024
zero elements as a performance optimization.
This meant that specifying --with-source with a package that
looks like a duplicate of a version with an ID >= 32*1024 triggered
the assertion; so we could not reproduce it easily in the test
suite.
Remove the optimized initialization to make the behavior more
uniform; and treat too large version IDs as having no SHA256.
Closes: #1098702
|
| |
|
|
|
|
|
|
|
|
|
| |
We don't really care about solver progress messages in testing;
hide them when comparing output, and hide them better than before.
Previously testsuccessequal ... --solver 3.0 behaved differently
than tests run with globally forced on 3.0 solver.
Stop cleaning up autoremovals, but do clean up "Calculating upgrade"
as well.
|
| |
|
|
|
| |
Implement the moving of the auto bit. The whole auto-bit management
is not entirely optimal yet, but this works.
|
| |
|
|
| |
string{=> _view})
|
| | |
|
| | |
|
