| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
It's interesting to the user to see the progress when it happens,
but arguably once it's done it is just visual clutter, so let's
not write newlines, and when we are done, instead of appending
"Done", let's just empty the line.
This requires some effort to keep apt-cdrom happy which just writes
lines to stdout itself. Bad apt-cdrom. Maybe there is a better fix
for it, but this gets us going.
|
| |
|
|
| |
This reverts commit 9bb953fddae0246a4dcedddb769d75d3521e1f2f.
|
| |
|
|
|
|
|
| |
The TagFile parser will have already parsed further and can't go
back so it needs to reopen the file if compressed.
Closes: #1067440
|
| |
|
|
|
|
|
|
|
| |
If we get called twice with the same offset, our d->Start and d->iOffset
will already point at the offset for the next section. But since we have
the start of the last parsed section still in the buffer, just make sure
to always go back to the start first.
Closes: #1067440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libapt has a NotEquals relation for version constraints in
dependencies, which is used internally e.g. in the MultiArch
implementation, but this relation is not supported by Debian
policy and as such can not be used in packages.
Our parser here is extremely accepting, even unknown relations are
parsed as Equals relation – but the version that must match will be a
rather strange one…
For our own testcases and e.g. on the command line with 'satisfy' it
can make sense to have != available… and what strange things apt does
parsing unsupported relations is not really much of a concern. Real
packages will not have such relations anyhow as we are (mostly) just
a consumer, not a producer of packages and index files.
|
| |
|
|
|
|
|
|
|
|
| |
While the code claims to handle it by just continuing the loop, the
looping condition will actually cause a break from the loop failing the
interrupted writing. The non-static FileFd::Write (and ::Read) deal with
this by setting acceptable values for the loop condition as well – but
for more simplicity and consistency we can instead remove this extra loop
condition and perform the continue/break due to error handling more
explicitly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
This adds a bit more code but avoids any surprises later on by
having both the shadowed and non-shadowed meta index in the
list.
Gbp-Dch: ignore
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This was automated with sed and git-clang-format, and then I had to
fix up the top of policy.cc by hand as git-clang-format accidentally
indented it by two spaces.
|
| |\
| |
| |
| |
| | |
Prevent infinite loop in `ReadConfigFile`
See merge request apt-team/apt!314
|
| | |
| |
| |
| |
| | |
Break the loop on failure. Without this, the function
goes into an infinite loop if `FName` is a directory.
|
| |\ \
| | |
| | |
| | |
| | | |
Configure the amount of kernels to keep
See merge request apt-team/apt!324
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit introduces the following configuration for keeping a
configurable amount of kernels: APT::NeverAutoRemove::KernelCount
The logic dictates that the running kernel and the latest kernel are not
autoremoved. In case the running kernel is the latest kernel, the
previous kernel is kept. Any count lower than two is therefore
disregarded. This is in line with the previous behavior.
The default is therefore similar to:
APT::NeverAutoRemove::KernelCount 2;
This will be ignored and we will still keep two:
APT::NeverAutoRemove::KernelCount 1;
This will keep 3 kernels (including the runnig, and most recent)
APT::NeverAutoRemove::KernelCount 3;
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
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.
|
| |/ / |
|