| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| | |
Seed snapshot servers for well-known hosts
See merge request apt-team/apt!293
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
This runs update before opening the cache and sources.list for
installing/upgrading.
|
|\ \
| |/
|/|
| |
| | |
fix (pkgProblemResolver): Keep "or group" when installing package to satisfy it
See merge request apt-team/apt!292
|
|/ |
|
| |
|
|\
| |
| |
| |
| | |
machine-readable version of COPYING
See merge request apt-team/apt!287
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The concrete copyright holders listed are not really relevant
for anything, as they are woefully incomplete anyhow. Grouping
by licensing allows us to focus on what matters: Parts that have
a different license from the overall project.
|
| |
| |
| |
| |
| | |
Thanks Petter for chasing down the copyright holders and getting
consent.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The debian/copyright (COPYING) file is missing at least two licenses
(Expat, BSD-3-clause) and some copyright statements. A machine-readable
version of COPYING is attached that fixes these.
Closes: #1019273
|
|/
|
|
|
|
|
| |
lintian-brush only fixed the spare-manual-page ones.
Fixes: lintian: mismatched-override
See-also: https://lintian.debian.org/tags/mismatched-override.html
|
|\
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
This test did not work with umask 0002
|
|\ \
| | |
| | |
| | |
| | | |
Do not store trusted=yes Release file unconditionally
See merge request apt-team/apt!289
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
|/ /
| |
| |
| | |
Gbp-Dch: Ignore
|
|\ \
| | |
| | |
| | |
| | | |
Detect trimmed changelogs and pick online instead
See merge request apt-team/apt!288
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
| |
The file is a remnant of the unrelated and closed !145 pull request
which tries to generate "apt-vendor.ent" – but that file exists
in our sources already while the script that would generate it doesn't.
Regression-of: 7e7eb113587230aeb9fe745b2eeac44e634999f5
Gbp-Dch: Ignore
|
|\
| |
| |
| |
| | |
Update ubuntu-codename to lunar
See merge request apt-team/apt!285
|
|/ |
|
|\
| |
| |
| |
| | |
Support transition to new non-free-firmware component
See merge request apt-team/apt!282
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In an ideal world everyone would read release notes, but if the last
sources.list change is any indication a lot of people wont. This is
even more a problem in so far as apt isn't producing errors for
invalid repositories, but instead carries on as normal even through it
will not be able to install upgrades for the moved packages.
This commit implements two scenarios and prints a notice in those cases
pointing to the release notes:
a) User has 'non-free' but not 'non-free-firmware'
b) User has a firmware package which isn't available from anywhere
Both only happen if we are talking about a repository which identifies
itself as one of Debian and is for a release codenamed bookworm (or
sid). Note that as (usually) apt/oldstable is used to upgrade to the
new stable release these suggestions only show for users after they
have upgraded to bookworm on apt command line usage after that.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This changes a lot of lines technically, but its easy enough to unfuzzy
the translations as most of the mentions are examples to be copied
literally in translations (sadly po4a isn't clever enough for this).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Closes: #1031008
|
| | |
|
|\ \
| |/
|/|
| |
| | |
Build with and fix warnings of gcc-13
See merge request apt-team/apt!280
|
| |
| |
| |
| |
| | |
Reported-By: gcc-13 -Wunused-result
Gbp-Dch: Ignore
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
| |
The code isn't using any of the member types this template provides,
so we can just drop it from the code without any practical effect.
Reported-By: gcc -Wdeprecated-declarations
Gbp-Dch: Ignore
|
|
|
|
| |
Closes: #1029280
|
|\
| |
| |
| |
| | |
Document --allow-insecure-repositories
See merge request apt-team/apt!277
|