| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| | |
Only revoke weak RSA keys now, add 'next' and 'future' levels
See merge request apt-team/apt!365
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Algorithms not in the next level give a warning, algorithms
in not in the future level introduce an audit message for
the --audit flag.
next: >=rsa2048,ed25519,ed448,nistp256,nistp384,nistp512
future: >=rsa3072,ed25519,ed448
LP: #2073126
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The option is supported by the command (as this is done by a bit more
low level code), but the command line parsing did not expect them to
be used for the apt show & list command, so that it would report error.
As such, a workaround for this issue is to use:
-o APT::Snapshot=BANANA
instead of e.g.
-S BANANA
Closes: #1075819
|
| |/
|
|
|
| |
Showing a package version which was never installed in removals is
confusing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the various Install requests into a single one and move
some stuff around, this should be a bit easier to maintain and
we don't repeat ourselves all the time.
This accidentally uncovered some bugs in the code, that get fixed
by this:
- The UpgradeManual and InstallManual groups did not work correctly,
Essential packages were Install and others were Upgrade.
- Automatically installed packages falsely got promoted to the
manual groups as they got promoted into the manual code path,
whenever we ran without allowing their removal.
- The combination of --mark-auto --auto-remove now works correctly
We previously skipped the installation of automatically installed
packages when we did autoremoval, but we did not consider if the
action was protected, that is specified on the command-line.
Now we do not autoremove protected actions, and have added a test
case for it.
- The AllowRemoveManual option no longer is applied if removals are
generally denied.
Closes: #1071519
|
| |
|
|
|
|
|
|
|
|
| |
As part of the refactoring, we allowed the code to work on unimportant
dependencies as we needed to promote Suggests to Depends if they are
currently satisfied.
However, Replaces and Enhances were not considered properly and both
are not negative dependencies so they were accidentally promoted to
Depends too if they were currently satisfied.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has two aspects:
1. For a dependency A | B | C we order the obsolete packages last,
that is, if A is obsolete, this gets reordered to B | C | A,
such that we try to pick non-obsolete packages first to ease
upgrade calculation.
2. When comparing two dependencies, we order dependencies into three
groups: First we satisfy dependencies mentioning only non-installed
(NEW) packages, then we satisfy "normal" dependencies, and finally
we satisfy any dependencies mentioning obsolete packages.
This means for example if you have obsolete libfoo1 and a new
libfoo1t64, that we will see Depends: libfoo1t64 before any
Depends: libfoo1 (which may expand to libfoo1 | libfoo1t64),
so we effectively will have selected "replacement" packages
this way already before getting to older packages where we
would have to choose between the obsolete package and its
replacement.
|
| |
|
|
|
|
|
|
|
| |
When a test-* file is created but not executable, we'd ignore
the argument and then our subprocess would run the entire
test suite itself, sequentially. Silly.
Let's just see if the file exists instead, then the test will
fail.
|
| |
|
|
|
|
| |
These got broken by the recent solver3 changes by accident,
and we did not notice as I also broke the test suite detection
with the new statistics feature, hooray.
|
| |
|
|
|
|
|
|
|
| |
We also need to issue a MarkDelete() if the package is marked for
installation currently but should not be, not only if it did not
have a previous version.
This fixes the final test in test-multiarch-barbarian, the others
only needed adjustments to mark all packages as automatic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When restoring previously solved items, we try to restore items
that have become unsolved again by skipping items that have a
solved solution.
Well at least we thought we did, but we accidentally had a "not"
in there that inverted the meaning, hence we lost work items on
backtracking.
This mostly did not seem to have caused any issues, I stumbled
over it while trying to add `autoremove` listings to `upgrade`,
but fixing it also fixes:
test-ubuntu-bug-1130419-prefer-installed-ma-same-siblings
This used to say "E: Broken packages", meaning the solver lost
a non-optional install request and the 2nd stage solver caught
an incomplete solution.
Also test-bug-735967-lib32-to-i386-unavailable restores the legacy
solver behavior, so win win?
|
| |
|
|
|
|
|
| |
This somewhat improves reliability of not breaking Recommends, e.g.
if the Recommends gets tightened. One test case enabled by this now
is the test-resolver-provider-exchange, which with a simple change
to allow removal of automatically installed packages works now.
|
| |
|
|
|
|
| |
As per the test-suggests-promoted-to-recommends test. This is still
a bit messy as we ignore alternative choices and only check the last
one, but um seems useful?
|
| |
|
|
|
| |
The previous commit basically fixes this, it just requires some
minor small adjustments
|
| |
|
|
|
|
|
|
|
|
| |
This fixes --no-strict-pinning attempting to upgrade all the versions
on the system. Adjust the upgrade test case accordingly:
1) no-strict-pinning pulls in systemd despite it being pinned down due
to a dependenc (this was true before this fix)
2) no-strict-pinning does not pull in the upgrade-simple because nothing
depends on it (this is what the test fixes)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Highlights:
- test-bug-618848-always-respect-user-requests: (Do not) Support 3.0 solver
A manually installed package is never removed just because we request
the removal of its dependency in solver3.
- test-bug-657695-resolver-breaks-on-virtuals: Support 3.0 solver
For manually installed packages, solver 3.0 would require some
new xserver-xorg-video-driver to Conflict+Replace+Provides the
old one (once the logic is implemented), but that does seem
reasonable.
- test-bug-720597-build-dep-purge: Support 3.0 solver
This needs a simple aptmark auto because pkga is removed by the
build-dep. But further adjustments are necessary because it weirdly
tested for no autoremovable packages before installing pkgc.
- test-bug-960705-*: Support 3.0 solver
Bit awkward to deal with; notably the protect to conflict doesn't
actually work anymore and that is a feature these days.
|
| |
|
|
|
|
|
|
| |
This makes things a bit nicer. We also include a list of passed
tests here, to use with --only to validate solver3 changes, as
well as the list of skipped tests.
But too lazy to implement these for the non-parallel case.
|
| |
|
|
|
| |
We do not show them yet, so let's ignore them so we can focus
on getting the rest of the tests to work.
|
| |
|
|
|
| |
Implement --solver, --only, -skip flags for the test suite, and
run the test suite with the broken tests skipped against solver3.
|
| |
|
|
|
|
| |
This is mostly going to be useful for the test suite for now,
implement a function there to set it up so we can use it to
improve test suite correctness.
|
| |
|
|
|
| |
Ignore the Solving dependencies... line in the testing framework
for compatibility with the existing test cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Companion of the previous commit that uses the same reasoning, but from
the other side of the logic (as we start from reverse deps here) so that
we are dropping the useless NEW from the solution.
Ideally this code would not live in -private, but in -pkg, but there is
not really a pre-existent good central place for this currently as a
sort-of fixup for our default resolver given this is the result of
resolver decision to not do something which had ripple effects that
aren't reverted along with it.
It is a bit unlikely that this is fixing all instances that this bug
has given we have dealt with a few instances of it already as they are
relatively obscure situations to clean up after and the cost of being
wrong (= autoremover generating breaks) is much higher than being
correct (= no pointless install – that is likely installed later anyhow
after the temporary automatic hold is lifted). And by virtue of being
the result of mostly temporary situations its also unlikely to be
debugable in hindsight months later; so if there is another situation,
its better to deal with it in a new bugreport.
Closes: #839546
|
| |
|
|
|
|
|
|
|
|
|
| |
The test is actually documenting another bug hidden a bit by this one as
we do not need to install a NEW package in this situation as the upgrade
needing it was kept back, but it was protected from considering it to
be autoremoveable as all providers tend to be considered protected, but
by limiting us to installed providers if we have some we can drag those
new packages out of hiding.
Now, we "just" have to get right of the NEW package in a next step.
|
| |
|
|
|
|
|
|
|
|
| |
Removing every line with at least three characters at the end makes
comparisons for output differences rather easy to pass. The intend
was to match for '\.\.\.' but given we have to adapt the strings to
include autoremove remarks we can also include the string that appeared
now that state information is provided (in the form of autobits).
Regession-Of: 734eb9ac3f65e38ac3ba7f2d50ea206743a6f611
|
| |
|
|
|
|
| |
It relies on removing packages, so we must allow it to. To see
if it does the right thing, mark all packages automatically
installed.
|
| | |
|
| |\
| |
| |
| |
| | |
showsrc, source, build-dep: Support src:name
See merge request apt-team/apt!346
|
| | |
| |
| |
| | |
This has the same behavior as --only-source name.
|
| | |
| |
| |
| | |
This has the same meaning as --only-source name
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If dpkg-gencontrol was involved in the creation of a package we will not
usually encounter empty or otherwise useless fields, but apparently not
everyone is using it.
It isn't recommended to have these empty lines, but it isn't too hard to
ignore for Provides as we did for dependencies already and apt-ftparchive
can be convinced to produce empty files (if you feed it such a package)
as well, so lets be nice and provide users with a more accepting parser.
Closes: #1069874
|
| | |
| |
| |
| |
| | |
Our code does the right thing currently, so lets add a test to ensure
this keeps being the case in the future.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our autoremoval-advertisment is modified by SUDO_USER as if the current
apt call was made with sudo it seems a good idea to show the ad with
sudo as well. That is annoying for our tests through as normally the
tests are run locally or by autopkgtest without sudo, but in Gitlab CI
we use it (to run our tests as user… as we are already root) and so
individual tests had to deal with this.
That is annoying and really not needed as we can have our autoremove
test check that this ad gets displayed the right way and ignore it the
rest of the time.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We schedule reverse dependencies for an upgrade, but we shouldn't do it
if we have ear-marked this package for removal later on. Usually the
solver will end up doing the right thing like it already did in the
included testcase in the end, but given that before it reaches the right
end it explored a bad path which can lead to more installs and removals
influencing later decisions or are just too hard for the resolver to
undo later on, we can just not explore this path to begin with.
References: e077370ffcb3669a50a600e80356c2002e6b176d
|
| |/
|
|
|
|
|
|
|
| |
We remove new garbage packages from the solution if we can as installing
a new package which is at the same time considered garbage looks silly,
but it could also be a new dependency of another garbage package, so we
have a second round trying to save such packages. In this round we
weren't considering versioned constraints on dependency relations through
so even an unsatisfied old recommends could save which it shouldn't.
|
| |
|
|
|
|
| |
This makes things more useful in combination with the upgrade
command, but introduces a subtle change seen in the test suite
when you use the install command to upgrade packages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key talking points here are:
1. Instead of long sentences, we use short concise messages,
e.g. "The following NEW packages will be installed" becomes
"Installing".
2. Dependencies are only listed once. We removed the
"The following additional packages will be installed" section
in favor of splitting up the "Installing" section into
"Installing" and "Installing dependencies" (like dnf)
3. The order of the output is different:
1. Packages to be installed manually
2. Packages to be installed automatically
4. Weak dependencies of new packages not installed
3. Packages to be upgraded
4. Packages to be downgraded
5. Packages that have been kept back / are on hold
6. Removals
7. Essential removals
i.e. we logically show you the action that is being
done, followed by lists related to the action.
4. As requested by popey, we have colorful UI, with green for
packages being installed and red for packages being removed.
Caveats:
- The list of recommends and suggests has not been updated yet,
it should move to after the packages being installed (as they
are what triggers them)
This also introduces output format versioning, configured by the
APT::Output-Format option. The default value is 0, except for the
apt(8) binary where it is 30 - which enables the new style.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes it a bit easier to quickly grasp the changes
about to be performed by apt.
It displays package lists in a columnar format by default,
similar to what `ls` produces for files.
A new long option `--no-list-columns` and an associated
`APT::Get::List-Columns` config setting control the behavior.
Usage example, with 60 column wide terminal:
```
$ sudo apt upgrade |
Reading package lists... Done |
Building dependency tree... Done |
Reading state information... Done |
Calculating upgrade... Done |
The following packages were automatically installed and are |
no longer required: |
libappindicator1 libindicator7 |
libdbusmenu-gtk4 linux-image-5.14.0-4-amd64 |
Use 'sudo apt autoremove' to remove them. |
The following packages have been kept back: |
criu linux-headers-amd64 nvidia-settings |
libxnvctrl0 nvidia-modprobe xwayland |
0 upgraded, 0 newly installed, 0 to remove and 6 not upgrade|
d. |
```
The effect becomes more pronounced with more packages (e.g. when
doing a dist-upgrade).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We temporarily downgraded the errors to warnings to give the
launchpad PPAs time to be fixed, but warnings are not safe:
Untrusted keys could be hiding on your system, but just not
used at the moment. Hence revert this so we get the errors we
want.
This reverts commit 66998ed3d299bede651ad40368bdb270f5f5b0f9.
LP: #2060721
Gbp-Dch: full
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't store .diff_Index files anymore and so libapt cares even less
about these purposefully leftover files from the testcases than it did
previously. On a successful apt run they would just be deleted, but as
we are testing a failed run they are not touched at all.
Testing the file access bits then means we check with whatever umask
they were created which might very well be different to what apt decides
these files to have if it had touched them, so for this test we just
delete them. For the other case we set it completely wrong just in case,
but they will (hopefully) be non-existent anyhow as tested first.
References: afcdbcf895284efd76903b2b3ba5cc849059ce50
|
| |
|
|
|
|
| |
We remove the working directory from the found file names as these paths
could contain a lot of funny characters confusing the for loop like
spaces… we just readd it later in the actual calls to be safe.
|
| |
|
|
|
| |
This will only issue warnings instead of errors while we continue
cleaning up our repositories.
|
| |
|
|
| |
This allows us to render public key algorithms as weak as well.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The assertion can be overriden using apt::key::assert-pubkey-algo,
the default is the most opinionated one.
This will inform the user during apt-cdrom add as we do not
pass --quiet to user, so adjust test case.
Add a simple test case for it to test-method-gpgv.
LP: #2055193
|
| | |
|
| |
|
|
|
|
| |
1. repository not supporting snapshots, implicit Enabled
2. repository not supporting snapshots, Enabled: yes
3. URL-based lookup, implicit Enabled
|
| |
|
|
|
|
| |
This was accidentally using testfailure instead of
testfailureequal, hence trying to run the output string
as a command :(
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert sources.list Snapshot option from opt-in to automatic. If
we can find a snapshot server, Snapshot: yes is assumed if a snapshot
is specified.
On the implementation side, we record automatic snapshot enablement
by adding a '?' suffix to the snapshot timestamp, if any is specified,
this avoids introducing bugs into the code where we could end up with
an empty snapshot.
This has an annoying internal implementation caveat: Since we call
GetDebReleaseIndexBy() with the SHADOWED option emplaced, if we do
not find a server, we need to remove the SHADOWED option again, but
we already have inserted a shadowed release index into the list.
This will simply insert the release index a second time without the
SHADOWED option which in preliminary testing works fine, but it would
arguably be more correct to also remove the release index again if
we have created it.
FIXME: This only has one test case: A source with supported snapshot
server is auto-discovered. We should also add a test case where we
cannot detect a server and then don't fail in automatic mode.
|
| |\
| |
| |
| |
| | |
Typos in integration tests
See merge request apt-team/apt!313
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Corrected 'und' -> 'and' in the fake package's description.
As a result, the MD5 checksum of this string is changed from
36ef2ec58c83bc4fdbe9fe958dd9c107 to 5022766cbc9bf07d1abea2c41a72646f
which in turn reduced the size of the resulting Packages.gz by one.
Therefore the accepted answer in the test case is updated too.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces a new line:
The following upgrades have been deferred due to phasing
This is any kept back package that is also phasing. This may
not be 100% accurate as we have kept it back due to other reasons
in an install command, for example, but we don't track for which
packages we applied phasing in reality.
If additional packages are kept back that are not phasing, show
a a notice
"N: Some packages may have been kept back due to phasing."
LP: #1988819
|
