apt/test/integration/framework, branch mainDebians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=main2026-04-07T09:40:15ZDrop warning about unstable CLI interface2026-04-07T09:40:15ZJulian Andres Klodejak@debian.org2026-02-24T18:25:21Zurn:sha1:f0c71b95ca00bae2b364c4b4858c51d84b002387
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
Implement architecture variants2025-10-25T18:42:14ZJulian Andres Klodejulian.klode@canonical.com2025-01-07T16:39:32Zurn:sha1:9d62eef571ffd1fd2df8b97884d3689fced27fb1
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";
Show command in test failure messages if default is overridden2025-09-02T18:50:04ZDavid Kalnischkiesdavid@kalnischkies.de2025-09-02T16:48:49Zurn:sha1:4f162c2f63796411467b816ccd80a20b2c248e72
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).
test: Do not use host's sequoia config2025-05-06T10:12:31ZJulian Andres Klodejulian.klode@canonical.com2025-04-25T22:26:05Zurn:sha1:7994d1b3bdaaef1351872f13054d1ed9d645f65a
Make the test suite independent of the host sequoia config.
Print --solver 3.0 explanation if both internal and it failed2025-03-09T12:55:23ZJulian Andres Klodejulian.klode@canonical.com2025-03-09T12:55:23Zurn:sha1:6c112f9860c1730237029f4e23d40bf658d73704
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.
test: Grep continuation lines in error messages2025-03-04T20:41:41ZJulian Andres Klodejulian.klode@canonical.com2025-03-04T20:41:41Zurn:sha1:1b959f0129460f2267e66bc77ca9464c28c915c5
This is important for upcoming multi-line solver error message
work.
test: Improve output cleaning for solver progress2025-02-18T14:48:49ZJulian Andres Klodejulian.klode@canonical.com2025-02-18T14:46:04Zurn:sha1:815d5b01bf9be1d476b110050b20ae980c76d4a8
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.
Warn about missing Signed-By in .list format2025-01-21T11:16:34ZJulian Andres Klodejulian.klode@canonical.com2025-01-20T10:57:33Zurn:sha1:c4e57e200ae40db5e9ada6ec0933b53d249e4a97
Warn about the missing field there and suggest the transition
to deb822 .sources files if we found any non-deb822 source
without signed-by.
Resolve autopkgtest failures caused by dpkg >= 1.22.122025-01-05T21:46:03ZDavid Kalnischkiesdavid@kalnischkies.de2025-01-05T21:46:03Zurn:sha1:eb1adc417b0f3c626c545d195e900d1369c751f0
Streamlining the rules around the Section field and especially what
happens if its isn't present are a good idea in general, but for testing
proposes we want a package without a section ~ something dpkg and co do
not want us to have for good reasons (outside of tests).
While a real nosection package would interact with more of our code, for
this test we don't really need a real one and so we can adopt to the new
reality of encountering such packages only if they are already
installed instead of trying to build a sectionless package by hand.
The other failure is a simple and trivial string change around the
formatting of the version number in dpkg error message about file
overrides, which we can resolve by just not looking at the version to
sidestep dealing with the formatting difference.
References: https://lists.debian.org/debian-dpkg/2024/12/msg00010.html
Closes: #1092090
Use sq in the test suite, remove apt-key2024-12-19T22:41:01ZJulian Andres Klodejulian.klode@canonical.com2024-12-19T21:11:04Zurn:sha1:a00fbbdb28cc31e78882301c2efe7218583ab4cb
Remove the test case for MD5 and expired signatures, as we can't
create them (can't set signing digest, and can't set signature
expiry).
Tests for them have been added to test-method-gpgv instead.
We override sq in a function with cert-store and key-store
set to none.
This supports both sq 0.40 and sq 1.0.