| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
This selects all packages that are being kept back due to phasing
on your system.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the functions of the PhasedUpgrader class into
various other classes so they can be publicly exposed.
This introduces three new functions:
pkgDepCache::PhasingApplied() tells you whether phasing should
be applied to the package.
pkgProblemResolver::KeepPhasedUpdates() keeps back updates that
have phasing applied.
pkgCache::VerIterator::IsSecurityUpdate() determines whether this
version contains security fixes.
|
| |
|
|
|
|
|
|
|
| |
previous ones
We only considered an update a security update if a previous update
is a security update but not the update in question itself.
LP: #2051181
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid copying the header from a stack allocated object as this
will copy uninitialized padding bytes into the cache, triggering
valgrind errors which people then use as a strawman for unrelated
errors on armhf.
In an optimal world we should annotate the allocator however such
that valgrind actually does treat those bytes as uninitialized and
then supress warnings in the harmless places, such that when you
then go and try to access it in a place that matters, you do get
an error for uninitialized memory.
Currently any access within the pool will be considered initialized
which is clearly suboptimal. But this is very much a TBD topic and
involves annotating the allocator everywhere.
|
| |\
| |
| |
| |
| | |
Do not store .diff_Index files in update
See merge request apt-team/apt!316
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Nowadays we only download the index file if we have a non-current file
on disk which we want to patch. If that is the case, any index file for
patches we could have stored is by definition outdated, so storing those
files just takes up disk space.
At least, that is the case if we have a Release file – if we don't this
commit introduces a needless redownload for such repositories but such
repositories are an error by default and if they can't be bothered to
provide a Release file its very unlikely they actually ship diffs, so
adding detection code for this seems pointless at best.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The implementation as-is as various smaller/esoteric bugs and
inconsistencies like apt-get not supporting them, the option -s
being supported in code but not accepted on the command line,
the regex not escaping the dot before the file extension and
exposing more implementation details to public headers than we
actually need.
Also comes with a small test case to ensure it actually works.
References: bd7c126e3fb1b94e76e0e632c657cea854586844
|
| |/
|
|
|
|
| |
Files with reserved extensions like .list, .sources, .conf,
and .pref should receive notices in their respective directories
even if they are directories.
|
| |\
| |
| |
| |
| | |
Add 'dist-clean' command to remove packages and list files
See merge request apt-team/apt!290
|
| | |
| |
| |
| |
| |
| |
| | |
We assume all files in the 'listsdir' are candidates. Keep only files
ending with Release, Release.gpg, and InRelease.
Closes: #959093
|
| |\ \
| | |
| | |
| | |
| | | |
Have Grp.FindPreferredPkg return very foreign pkgs as last resort
See merge request apt-team/apt!310
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Usually this method will return the package in the most preferred
architecture (e.g. native) as that is usually what the user talks about
and also information wise for our internal usage the most dense.
Early on in parsing Packages files through it can happen that we
encounter stanzas about packages in architectures we are not even
configured to know about – we have to collect them anyhow as we might be
requested to show info about them or they could be in the status file
and we can't ignore stanzas in the status file… trouble is that this
method used to not return anything if only such an architecture was
present if we later discover other architectures which causes Provides
and Conflicts which are added lazily on discovery of an architecture
to not be added correctly.
The result is like in the testcase that apt could be instructed to
install a package without respecting its negative dependencies, which is
bad even if its discovered by dpkg and refused. It does only happen with
unknown architectures through which mostly happens if you are unlucky
(amd64 users tend to be very lucky as that sorts early) and use
flat-style repositories containing multiple architectures.
Reported-By: Tianyu Chen (billchenchina) on IRC
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
apt-pkg/cacheset.cc: set ShowErrors to true when no version matched
See merge request apt-team/apt!308
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Enforce helper.canNotGetVersion to show error if no version matched.
Regression-of: 572810e9f321237873d1536c88991d7825c6f1db
Closes: #1053887
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Fix incorrect time unit comment for PulseInterval
See merge request apt-team/apt!304
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This reverts commit 668451def296afeb0c358a7d80ff39dc546defab.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This avoids the rabbit hole of md5 on FIPS systems, and repositories
have moved to including the value as well.
Also stop validating the field, this can be an arbitrary string
as far as we are concerned.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One warning will be issued before the Y/n prompt, the other will
be issued at the end after package installs have been attempted
or if there were other failures, such that the last line you see
is warnings about unmerged-usr
I do not anticipate this to be the final version either, but
there we go.
Closes: #1052058
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As of bookworm, merged-usr is mandatory, and people got caught
in the crosshairs of the dpkg fsys-unmessusr debacle and inadvertently
reverted back to an unmerged configuration and continue to remain
on an unsupported system unknowingly.
Help them by erroring out when they are installing packages on /,
they are not in a chroot, and a usrmerge package is available.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we know both SHA256, and they're different, the packages are. This
approach stores the SHA256 only at runtime, avoiding the overhead of
storing it on-disk, because when we update repositories we update all
of them anyhow.
Note that pkgCacheGenerator is hidden, so we can just modify its
ABI, hooray.
Closes: #931175
LP: #2029268
|
| | |
| |
| |
| |
| | |
We did not handle multiple components properly, add a contrib
component to the test case.
|
| |\ \
| | |
| | |
| | |
| | | |
Do not fail on systems running in FIPSmode.
See merge request apt-team/apt!295
|
| | | |
| | |
| | |
| | |
| | | |
Initialize using gcrypt's GCRYCTL_NO_FIPS_MODE, available since
gcrypt version 1.10.0, otherwise apt aborts on FIPS enabled systems.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
dist-upgrade: Revert phased updates using keeps only
See merge request apt-team/apt!299
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes an issue where phased updates gain new dependencies
and cause them to be installed despite themselves not being
installed.
In the cause of investigation, it turned out that we also need
to evaluate the candidate version at those early stage rather
than the install version (which is only valid *after* MarkInstall).
This does not fully resolve the problem: If an update pulls in
a phased update, depends are still being installed. Resolving
this while ensuring that phased updates cannot uninstall packages
requires us to do a minimization of changes by trying to keep
back each new install removal and then seeing if any dependency
is being broken by it. This is more complex and will happen
later.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the bug, mutter was kept back due to phasing and the new gnome-shell
depended on that, and was therefore kept back as well, however,
gnome-shell-common was not broken, and apt decided to continue upgrading
it by removing gnome-shell and the ubuntu desktop meta packages.
This is potentially a regression of LP#1990586 where we added keep
back calls to the start of the dist-upgrade to ensure that we do not
mark stuff for upgrade in the first place that depends on phasing
updates, however it was generally allowed by the resolver to also
do those removals.
To fix this, we need to resolve the update normally and then use
ResolveByKeepInternal to keep back any changes broken by held back
packages.
However, doing so breaks test-bug-591882-conkeror because ResolveByKeep
keeps back packages for broken Recommends as well, which is not
something we generally want to do in a dist-upgrade after we already
decided to upgrade it.
To circumvent that issue, extend the pkgProblemResolver to allow
a package to be policy broken, and mark all packages that already
were already going to be policy broken to be allowed to be that,
such that we don't try to undo their installs.
LP: #2025462
|
| |/ /
| |
| |
| |
| |
| |
| | |
We want to gently steer users towards having Signed-By for each
source such that we can retire a shared keyring across sources
which improves resilience against configuration issues and
incompetent malicious actors.
|
| | |
| |
| |
| |
| |
| | |
Separate the determination of the next level domain into its
own function and split out the "we found a result" into its
own break for improved readability.
|
| | | |
|
| | |
| |
| |
| |
| | |
This will attempt to fallback to a per-server setting if we could
not determine a value from the release file.
|
| |\ \
| | |
| | |
| | |
| | | |
Add --snapshot and --update support
See merge request apt-team/apt!291
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Provide snapshot support for offical Debian and Ubuntu archives.
There are two ways to enable snapshots for sources:
1. Add Snapshot: yes to your sources file ([snapshot=yes]). This
will allow you to specify a snapshot to use when updating or
installing using the --snapshot,-S option.
2. Add Snapshot: ID to your sources files to request a specific
snapshot for this source.
Snapshots are discovered using Label and Origin fields in the Release
file of the main source, hence you need to have updated the source at
least once before you can use snapshots.
The Release file may also declare a snapshots server to use, similar
to Changelogs, it can contain a Snapshots field with the values:
1. `Snapshots: https://example.com/@SNAPSHOTID@` where `@SNAPSHOTID@`
is a placeholder that is replaced with the requested snapshot id
2. `Snapshots: no` to disable snapshot support for this source.
Requesting snapshots for this source will result in a failure
to load the source.
The implementation adds a SHADOWED option to deb source entries,
and marks the main entry as SHADOWED when a snapshot has been
requested, which will cause it to be updated, but not included
in the generated cache.
The concern here was that we need to keep generating the shadowed
entries because the cleanup in `apt update` deletes any files not
queued for download, so we gotta keep downloading the main source.
This design is not entirely optimal, but avoids the pitfalls of
having to reimplement list cleanup.
Gaps:
- Ubuntu Pro repositories and PPAs are not yet supported.
|
| |/ / |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Fix permissions && change section matching in config files to be more gitignore style rightmost match
See merge request apt-team/apt!286
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use a rightmost match for / so that if we end up with a Section: a/b/c,
a 'c' matcher still matches.
If the section does not contain any /, it can be matched using /pattern,
e.g. /c only matches Section: c, but not Section: a/b/c.
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A source marked with trusted=yes can still fail verification of the
Release file, mostly for Date related issues, like being too new or too
old, which have other options to force them in.
The update code was not using the Release file (which was a InRelease
file but failed verification – which was overridden by trusted=yes) as
intended, but it marked it for storage, so that this "bad" Release file
would end up being moved into lists/, which is bad as the indexes it
refers to aren't updated while the next update run assumes that the
indexes are in the state the Release file claims them to be in.
Fixed simply by making the storage conditional on the usage as intended,
which also resolves a second issue: The verification can also detect that
a Release file we got is older than what we already have to avoid down-
grade attacks. The more likely explanation is a slightly outdated mirror
in a rotation/CDN through, so this gets the silent treatment to avoid
scaring users by handling it as if we had got the same Release file we
already have stored locally, removing the freshly received older file
in the process alongside setting some variables. Those variables were
already modified in the trusted=yes case though resulting in the stored
Release file being removed instead. Not modifying the variables too early
resolves this problem as well.
Both seem to exist since at least 2015 as traces are visible in 448c38bdcd
already, which shuffled lots of code around including the bad ones, but
as we are in trusted=yes land, security is of no concern here, this
"just" leads to failed pinning, hashsum mismatches and other strange
problems in follow-up calls depending on how out of sync the Release
file (if its still present) is with the rest of the trusted data.
Reported-By: Dima Kogan <dkogan@debian.org> on IRC
Tested-By: Dima Kogan <dkogan@debian.org>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only check the start of these lines to avoid hard coding the exact
command and we pick 150 as maximum line length as the longest package
name on my system is apparently 75 characters long. We could choose
longer or shorter without much issue as over-length just means we
mishandle the rest of the line as a new line and it should be really
unlikely that a) lines are that long in this file and b) that such long
lines contain one of our trigger sequences – but even if, all we do is
start a download of an online file. Could be worse.
This auto-detection can be avoided by setting
Acquire::Changelogs::AlwaysOnline (or Origin specific sub options)
to "true" if you always want the changelog from an online source.
The reverse – setting it to "false" in the hope it would not get the
changelog from an online source – was not and is still not possible.
Closes: #1024457
|
| |\
| |
| |
| |
| | |
Support transition to new non-free-firmware component
See merge request apt-team/apt!282
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Hard coding each and every component is not only boring but given that
everyone is free to add or use more we end up in situations in which apt
behaves differently for the same binary package just because metadata
said it is in different components (e.g. non-free vs. non-free-firmware).
It is also probably not what the casual user would expect.
So we instead treat a value without a component as if it applies for all
of them. The previous behaviour can be restored by prefixing the value
with "<undefined>/" as in the component is not defined.
In an ideal world we would probably use "*/foo" for the new default
instead of changing the behaviour for "foo", but it seems rather
unlikely that the old behaviour is actually desired. All existing values
were duplicated for all (previously) known components in Debian and
Ubuntu.
|
| | |
| |
| |
| | |
Closes: #1029751
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The matchers are usually called via its base class, but if we would call
them via the derivate class we would not be able to call the not
explicitly "imported" overloads, which would be strange.
Reported-By: gcc-13 -Woverloaded-virtual
Gbp-Dch: Ignore
|
| | |
| |
| |
| |
| | |
Reported-By: clang-tidy [cppcoreguidelines-explicit-virtual-functions]
Gbp-Dch: Ignore
|
| | |
| |
| |
| |
| |
| |
| | |
In gcc-13 internal includes were reduced exposing our laziness.
Reported-By: gcc-13
Gbp-Dch: Ignore
|
| | |
| |
| |
| |
| | |
Reported-By: gcc -Wsign-compare
Gbp-Dch: Ignore
|
| |/
|
|
|
| |
Reported-By: gcc -Wunused-parameter
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
This is the correct behavior, but it was overlooked when aptitude
patterns where ported. I remember wondering about this, but I checked
the aptitude code and saw a check that CurrentVer != 0 or something
and then apparently did not notice another implementation for version
matching.
|