| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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.
|
| | |
|
| |\
| |
| |
| |
| | |
Allow apt to run if no dpkg/status file exists
See merge request apt-team/apt!257
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Not having a dpkg/status file used to be a hard error which from a
boostrap perspective is suspect as in the beginning, there is no
status so you would need to touch it into existence.
We make a difference between factual non-existence and inaccessibility
to catch mistakes in which the file is not readable for some reason,
the testcase test-bug-254770-segfault-if-cache-not-buildable is an
example of this.
Note that apt has already figured out at this point that this is a
Debian-like system which should have a dpkg/status file. This change
does not effect the auto-detection and is not supposed to.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Failing to properly create the status file class should be reported back
to the caller so it can proceed accordingly instead of proceeding into
more failures.
This gives us:
E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory)
E: The package lists or status file could not be parsed or opened.
instead of:
E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory)
E: Could not open file - open (2: No such file or directory)
E: Problem opening
E: The package lists or status file could not be parsed or opened.
and valgrind reporting actions on uninitialised values.
|
| |\ \
| | |
| | |
| | |
| | | |
phased update improvements
See merge request apt-team/apt!262
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
By marking them at the end, we might make other decisions that
depend on the new phased updates, confusing the solver. Run the
marking at the start too.
The EDSP test file from Jeremy was modified to include Machine-ID
and Phased-Update-Percentage fields and then filtered to mostly
exclude packages irrelevant to the test case by running
grep-dctrl \( -FRequest "EDSP 0.5" -o -FInstalled yes \
-oFPhased-Update-Percentage 10 \) \
-a --not -FArchitecture i386
LP: #1990586
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When iterating over I's dependencies (which are called Pkg), we
accidentally checked if I was Protected() instead of Pkg when deciding
whether Pkg can be kept back.
LP: #1990684
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add Machine-ID to the first stanza, and copy Phased-Update-Percentage
to package stanzas.
This will be tested at a later state by the EDSP test case for
bug 1990586.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
apt-pkg/contrib/fileutl.h Explicitly include sys/stat.h
See merge request apt-team/apt!255
|
| | | |/
| |/|
| | |
| | | |
This fixes compatibility with musl C library.
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
This fixes build on some architectures like mips
progress.cc:125:31: error: non-constant-expression cannot be narrowed from type 'std::chrono::duration<long long>::rep' (aka 'long long') to '__time_t' (aka 'long') in initializer list [-Wc++11-narrowing]
struct timeval NowTime = { Now_sec.count(), Now_usec.count() };
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
A temporary filename is used as a workaround for bugs/missing features
in other software dealing with /dev/stdin, but nobody said I have to use
the exact same filename….
However in-tree builds are not generally recommended.
References:
https://salsa.debian.org/debian/sbuild/-/commit/aa4a4326d09969e809f336e1b75cbd7342a77529
https://salsa.debian.org/ci-team/autopkgtest/-/commit/fb0561efc41a117963fa3e31802db6b2664c7aa5
Regression-Of: 701a501fb1c84296d2003c0092e4308742079591
Reported-By: Lance Fredrickson <lancethepants@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
| |
First mark them for upgrade without autoInst, so we don't call
their "mark other binaries loop"; then call them again with it.
Without this change, each binary package would upgrade the next
one in the list, recursively.
|
| |
|
|
|
|
|
|
|
| |
Schedule all other binaries in the source package for upgrade if
the candidate version belongs to the same source version as the
package we are upgrading.
This will significantly reduce the risk of partial upgrades and
should make life a lot easier.
|
| |\
| |
| |
| |
| | |
Mark broken reverse depends for upgrade
See merge request apt-team/apt!248
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the solver handles cases where a Breaks b (<< 1) and
if we install that a, upgrades b. However, where b Depends a (= 1),
b was removed again.
This addresses the problem by iterating over installed reverse
dependencies of upgrades and upgrading them so that both cases
work roughly similarly.
LP: #1974196
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With apt 2.5.1 python-apt fails to build with:
```
...
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.10 -c python/acquire-item.cc -o build/temp.linux-x86_64-3.10/python/acquire-item.o -std=c++11 -Wno-write-strings -DAPT_8_CLEANER_HEADERS -DAPT_9_CLEANER_HEADERS -DAPT_10_CLEANER_HEADERS -DPY_SSIZE_T_CLEAN
In file included from python/python-apt.h:30,
from python/apt_pkgmodule.h:211,
from python/acquire-item.cc:25:
/usr/include/apt-pkg/deblistparser.h:48:65: error: ‘pkgTagSection::Key’ has not been declared
48 | bool ParseDepends(pkgCache::VerIterator &Ver, pkgTagSection::Key Key,
| ^~~
```
This commit adds a small fix by (re)exporting `pkgTagSection::Key`.
|
| |\
| |
| |
| |
| | |
Rewrite phased updates using a keep-back approach
See merge request apt-team/apt!245
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a package is already pinned to a negative value, we should not
override this with a positive 1. This causes packages to be installable
that were pinned to -1, which is not intended.
For this, implement phasing as a ceiling of 1 for the pin instead
of a fixed 1 value. An alternative would have been to fix it to
NEVER_PIN, but that would mean entirely NEW packages would not be
installable while phasing which is not the intention either.
LP: #1978125
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a lot closer to the original implementation in update-manager,
but still has a couple of differences that might cause bugs:
- When checking whether a version is a security update, we only
check versions in between and not any later version. This happens
mostly because we do not know the suite, so we just check if there
is any version between the installed version and our target that
is a security update
- We only keep already installed packages, as we run before the
resolver. update-manager first runs the resolver, and then marks
for keep all packages that were upgraded or newly installed that
are phasing (afaict).
This approach has a significant caveat that if you have version 1
installed from a release pocket, version 2 is in security, and version
3 is phasing in updates, that it installs version 3 rather than 2
from security as the policy based implementation does.
It also means that apt install does not respect phasing and would
always install version 3 in such a scenario.
LP: #1979244
|
| |/
|
|
|
|
|
|
|
|
|
| |
Before this patch, the expression `Res - File.length()` that was
used as the length underflowed. It was very unlikely to cause any
problem given the saturating behavior of the std::string
constructor that's used.
Replacing `Res - File.length()` with `File.length() - Res` would
have worked, but omitting the last argument altogether invokes an
std::string constructor which does the right thing.
|
| |
|
|
|
|
|
|
| |
/dev might not be populated for example in unshare chroots, so just
using a temporary file it is until triehash supports non-file input.
Regression-Of: f6438ea9e726a1c13ce8d90ac78cc272346ab0f8
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
| |
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
|
| |
|
|
|
|
|
|
| |
Our public interface doesn't use zlib for quite a while now so lets drop
the last remnants as hopefully nobody depends on us bringing it in…
Unlike our own private lib for transitive provision of unistd.h.
References: 680b916ce7203a40ebd0a3882b9a71ca77278a67
|
| |\
| |
| |
| |
| | |
Consistently dealing with fields via pkgTagSection::Key
See merge request apt-team/apt!233
|
| | |
| |
| |
| |
| |
| |
| | |
We abstract hashes a fair bit to be able to add new ones eventually,
which lead us to building the field names on the fly. We can do better
through by keeping a central place for these names, too, which even
helps in reducing code as we don't need the MD5 → Files dance anymore.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The speed critical paths were converted earlier, but the remaining
could benefit a tiny bit from this as well especially as we have the
facility now available and can therefore brush up the code in various
places in the process as well.
Also takes the time to add the hidden Exists method advertised in
the headers, but previously not implemented.
|
| | |
| |
| |
| |
| |
| | |
FindS has a APT::StringView based API nowadays, so we can avoid these
explicit calls also allowing us to avoid the std::string in input or
output entirely or at least move it a few branches down.
|
| | |
| |
| |
| |
| |
| |
| | |
It was introduced in the first commit for EDSP, but beside this
reference, never appears in documentation and code. Seems like an
earlier name of what APT-ID ended up to be and as such should be
more than safely being able to retire now.
|