summaryrefslogtreecommitdiff
path: root/test/integration
Commit message (Collapse)AuthorAgeFilesLines
* aptwebserver: Refuse client immediately on TLS handshakeDavid Kalnischkies2026-06-102-8/+12
| | | | | | | | | | | We implement a HTTP-only server here (that is wrapped by stunnel for HTTPS support), so if a TLS handshake reaches us it is always wrong and we can just close the connection immediately instead of accepting it and letting the client run into a timeout as we will never receive the message(s) we expect. This happens e.g. with browsers like Firefox that opportunistically try https first (even if you ask for http and specify a port).
* Document and test combined `build-dep --arch-only --indep-only`Julian Andres Klode2026-05-201-0/+14
| | | | | This is a supported configuration to only use bare Build-Depends and Build-Conflicts.
* Warn if auth.conf is unreadable (LP: #2150631)Varun Varma2026-05-171-0/+37
| | | | LP: #2150631 is a bug where trying to access an authentication-locked repo without root sends a 401 error, which is misleading since the authentication information could be in auth.conf.d, but just inaccessible without root. This adds a warning in that scenario, as well as an integration test.
* solver3: Follow installed Suggests earlierJulian Andres Klode2026-05-171-2/+7
| | | | | | | We accidentally followed "keepauto" and friends earlier, breaking `apt why` for suggested packages. Reported-By: uau on IRC
* Drop warning about unstable CLI interfaceJulian Andres Klode2026-04-073-7/+0
| | | | | | | | A specific CLI version can now be requested using the --cli-version flag, and old versions can be deprecated on a reasonable cadence. Therefore, a warning is no longer necessary. Gbp-Dch: full
* Scale history-list to screen widthSimon Johnsson2026-04-071-15/+58
|
* Do not use unexpected operator in test-apt-get-satisfyDavid Kalnischkies2026-03-191-1/+1
| | | | | | | | | | | | | Observing a testrun carefully included: ./test-apt-get-satisfy: 101: [: unexpected operator Yes, == is not a valid operator here, should just be =. The result is that we unconditionally skip a single check, hardly so much the end of the world that we need to tell everyone as no tests were failed, but no good anyhow. Fixes: 5e8e69cdd6b512480f3208298725e1e44c80f06e Gbp-Dch: Ignore
* solver3: Upgrade by source packageJulian Andres Klode2026-02-173-34/+50
| | | | | | | | | | | | | | | | | | | | | | | | Implement the "APT::Get::Upgrade-By-Source-Package" option as the classic solver does. Here this is equally straight forward now: We enqueue optional, but eager, clauses of the form foo=2 -> foo-data=2 for each sibling in the source version, assuming they are currently installed, and the selection is not the current version. This softly enforces upgrades of already installed siblings, but in non-strict-pinning mode it will not affect the selection of new packages to be installed. A more complete solution to version selection by source package also seems feasible, where we change the "priority" of versions in the solver dynamically - currently they are statically evaluated. Such that, when you select foo=2, and something installs foo-data, foo-data would be installed in version 2 even if version 3 were its candidate.
* solver3: Use classical watchers for propagationJulian Andres Klode2026-01-3110-44/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of tracking dependencies and reverse dependencies, install classical watchers. This vastly streamlines the propagation code and allows us to easily switch to literals in the next step. This implementation watches _all_ solutions rather than using the modern 2-watched literals scheme or the intermediate head/tail watchers. Ultimately a more effective watcher scheme would be interesting but not a significant priority seeing as most of the solver runtime is spent not in propagation but in problem translation. decision trees -------------- The new watchers produce slightly different decision trees, sometimes subtly changing solutions. Notably in various observed examples in Ubuntu 25.04, courier was installed as an MTA instead of postfix: The old decision tree was: apcupsd:amd64 -> mailutils:amd64=1:3.18-1 -> mailutils:amd64 -> postfix:amd64=3.9.1-10ubuntu1 The new decision tree is: lsb:amd64 -> lsb-core:amd64 -> courier-mta:amd64=1.3.13-1 The difference here being that lsb-core declares a mail-transport-agent dependency whereas mailutils depends on `default-mta | mail-transport-agency`; but both are effectively subject to selection at similar time. Further work is needed to optimize selection. A notable choice may also be to deal with broken packages like lsb-core that declare dependencies solely on a virtual package by reconstructing the default provider for that package utilizing default-* dependencies or similar notions. Likewise in the test suite, explanations are different in some uninstallable cases. backtracking ~~~~~~~~~~~~ The following major changes were observed in the 25.04 test suite: -tmp/regression-remove/07f0a068-36c2-11f0-b7c1-fa163e171f02:18 +tmp/regression-remove/07f0a068-36c2-11f0-b7c1-fa163e171f02:3 -tmp/regression-remove/32078f70-3734-11f0-a75a-fa163ec8ca8c:64 +tmp/regression-remove/32078f70-3734-11f0-a75a-fa163ec8ca8c:19 Other test cases showed little deviation, +/- 1, generally the same amount of backtracking. performance ~~~~~~~~~~~ Running Ubuntu's regression test suite resulted in no significant performance difference being observable. Before: 290s user time; 16.66% solver After: 299s user time; 17.36% solver Tests where run with make -j 8 and solver performance extracted perf report --symbol-filter=ResolveExternal --stdio
* variants: Do not report unsupported variants in repositoriesJulian Andres Klode2026-01-231-4/+8
| | | | | We configure all variants the CPU supports as active, but repositories usually do not provide all of them, so let's not be noisy.
* why: Render info about all providers on virtual packagesJulian Andres Klode2026-01-201-0/+7
| | | | | | | | | | Refactor code into a doOne helper lambda, and then add loop over the providers to use it. This fixes a crash seen by Benjamin in a nice way than just failing :) Reported-by: Benjamin Drung
* solver3: Rename decision to assignmentJulian Andres Klode2026-01-0531-66/+66
| | | | | | | The previous use of decision here conflicted with the use of decision level and the general notion of having made a decision, because the assignment might have been propagated as a matter of fact.
* Correctly copy provided version in m-a lazy-initJulian Andres Klode2025-11-101-0/+24
| | | | | | | | When a provides was copied, we inadvertently copied the package version instead of the provided version. Copy the provided version instead. Closes: #1120463
* Revert "depcache: Allow changing multi-arch versions for removed siblings"Julian Andres Klode2025-10-261-20/+11
| | | | | | | | | | | | | | | | This reverts commit 74636b64a7ee56637a3ce4ddc1d060ca9f8b77e1. Adjust the test case accordingly, as it is no longer possible to install libgcc-s1:s390x. We need to sort this out in the ToDepCache translation layer at a later time. Sadly the depcache rejects valid solutions like this; solving this isn't trivial. Technically we need to split up the FromUser and auto-bit handling to solve this, but even then, MarkDelete() with FromUser=0 moves the auto-bit on metapackages; this doesn't happen when doing FromUser=1, so we can't always do FromUser=1. Fixes: a3fca052ca21ad222ac7f2fdd7f3fe84b44beb60
* test: Correctly skip tests when not using -jJulian Andres Klode2025-10-261-1/+1
| | | | | | We never implemented comment support in the skip test file for -j as we only run with -j, but the debian/tests/run-tests runs without parallelism.
* tests: Do not skip tests for --solver internalJulian Andres Klode2025-10-261-3/+3
| | | | | | | Remove the exports for the default as we don't want those inherited, they can just be reset. Set the skip file to /dev/null when a solver is selected, to make sure that tests don't fall back to the default skip file.
* Adjust test cases to treat 3.0 as default APT_SOLVER if not setJulian Andres Klode2025-10-268-10/+10
| | | | | Not needed so far because we export a default 3.0 APT_SOLVER, but quite useful if we stop doing so (next commit).
* solver3: Allow removing manually installed packagesJulian Andres Klode2025-10-259-38/+80
|
* Enable the new solver by default in 0.31, 1.21, 2.11, 3.1Julian Andres Klode2025-10-251-0/+3
| | | | | Enable the new solver by default and remove the vendor-specific configuration change in Ubuntu's drop-in.
* Implement architecture variantsJulian Andres Klode2025-10-253-2/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Architecture variants are children of an architecture that share the same ABI but are optimized for different ISA levels. They are available in Ubuntu 25.10 and newer, and not supported in Debian or other distributions. A deb built for a variant contains the Architecture-Variant field, and the Architecture field points to the baseline, for example: Architecture: amd64 Architecture-Variant: amd64v3 However, the apt-get indextargets command reports the variant in the Architecture: field, and most of the code in APT presents the variant as the architecture. There are two types of variants: 1. Standalone variants are recorded in the Architectures field of the Release file as if they were a real architecture: Architectures: amd64 amd64v3 Standalone architecture variants only fetch the standalone architecture variant's Packages file. To do this, this patch changes the code such that the variants indextargets "supplant" the base targets. This may have complicated outcomes on the apt-get indextargets command. 2. Other variants can only be identified by their files being recorded with hashes in the Release file. APT fetches both the base architecture's as well as the variant's Packages file. Variants are configured in the APT::Architecture-Variants list. Image builders may want to build specific variant images using APT::Architecture-Variants { "amd64v3"; } But this commit also implements an automatic discovery mechanism using the varianttable and /proc/cpuinfo. APT::Architecture-Variants "auto";
* ExecFork: Simplify closing and make it safeJulian Andres Klode2025-10-201-32/+0
| | | | | | | | | Implement a wrapper around FD_CLOEXEC and use it in place of the raw fcntl(). This wrapper _Exit()s the child if the operation failed. Restructure the close_range() handling to simply mark all fds for closing first and then "reopen" the ones we should keep.
* Add some comments and tests around Keep-Fd orderingJulian Andres Klode2025-10-201-0/+7
|
* ExecFork: Use close_range() if availableJulian Andres Klode2025-10-201-0/+25
| | | | | | | | | | | | | Use close_range() if we have it in preference to iterating over /proc/self/fd and falling back to closing all possible fds. This builds sets of ranges to close that take into account the APT::Keep-Fds vector, and a test case is provided to ensure correctness of the splitting logic. Preference is given to close_range() over /proc as in the optimal case, this results in a single system call!
* Let APT::Get::Mark-Auto satisfy APT::Get::Build-Dep-AutomaticJochen Sprickerhof2025-10-071-0/+9
| | | | | | | | This allows: apt build-dep --mark-auto apt Closes: #973260
* Fix history command error when no ID was givenSimon Johnsson2025-10-061-0/+4
|
* Add history undo, redo, and rollback featuresSimon Johnsson2025-10-021-1/+42
|
* test-history: Adjust for as-installed testingJulian Andres Klode2025-09-301-1/+1
| | | | | | When testing as installed, we inadvertently do not replace the command-line with dummy in the "apt history-list" command.
* history: Handle transactions without any changesJulian Andres Klode2025-09-261-0/+19
| | | | For some reason I have them in my log file.
* test-history: Do not fully remove the command lineJulian Andres Klode2025-09-261-2/+2
| | | | | This will particularly be useful in the next commit; just strip the path form the commandline.
* History Command and ParsingSimon Johnsson2025-09-261-0/+30
|
* Support kernel images with + in uname in kernel autoremove testDavid Kalnischkies2025-09-021-1/+1
| | | | | | | | | 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.
* Show command in test failure messages if default is overriddenDavid Kalnischkies2025-09-022-19/+33
| | | | | | | | 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).
* solver3: Allow any downloadable version to mark a package as not obsoleteJulian Andres Klode2025-08-261-3/+13
| | | | | | | | | | | | 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
* solver3: Sort dependency targets against current alternativeJulian Andres Klode2025-08-262-10/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix stuck acquire queues on partial server errorsJulian Andres Klode2025-06-241-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* solver3: Filter installed RecommendsJulian Andres Klode2025-06-101-0/+29
| | | | | | When inspecting Recommends of installed packages, filter them to the installed packages only, as we want to avoid switching between alternatives of recommended packages.
* solver3: Ignore Architecture: all for obsoleted-byJulian Andres Klode2025-06-101-2/+21
| | | | | | | | | | | | 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.
* solver3: Only merge dependencies on the same packageJulian Andres Klode2025-05-281-0/+53
| | | | | Avoid or groups and dependencies on different (virtual) packages, to avoid some common pitfalls like the added xorg test case.
* solver3: Merge Depends into RecommendsJulian Andres Klode2025-05-271-0/+13
| | | | | | | | | | | | | | | | | | | | | | | 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.
* solver3: Merge intersecting dependenciesJulian Andres Klode2025-05-272-5/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* solver3: Assume manual packagesJulian Andres Klode2025-05-268-17/+98
| | | | | | | | | | | | | | | | | | | | 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
* 💬 Recommend use of `apt update` over `apt-get update`Max Coplan2025-05-192-3/+3
|
* Introduce apt why, apt why-notJulian Andres Klode2025-05-191-0/+71
| | | | | | | | | | | 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).
* Add 'Include'/'Exclude' options to limit packages used from a repositoryJulian Andres Klode2025-05-191-0/+63
| | | | | | | | | | | | | '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
* test: Do not use host's sequoia configJulian Andres Klode2025-05-062-2/+6
| | | | Make the test suite independent of the host sequoia config.
* test: Fix test-skipped regression in 3.0.1Julian Andres Klode2025-05-061-3/+2
| | | | | There was an accidental exit in the if causing the test to exit early, but the test suite still to pass.
* sqv: Warn about signatures that will be rejected by policy within a yearJulian Andres Klode2025-04-251-0/+10
| | | | | | | | | | | | 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.
* solver3: Consider more upgrades more costly when not upgradingJulian Andres Klode2025-04-041-4/+40
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* pager: Also set SMK in LESS, fix LV=C to be LV=-cJulian Andres Klode2025-03-261-1/+1
| | | | | | | | | | | 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.
* solver3: Correctly deb822-escape error message in evaluation reportJulian Andres Klode2025-03-261-0/+35
| | | | | | The error messages are multi-line now, so need correct escaping. LP: #2104276
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-07-18 06:37:41 +0000