| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
I also unfuzzied the translation strings for the 23.10->24.04
apt-key deprecation change.
|
| |
|
|\
| |
| |
| |
| | |
Automatically enable snapshots where supported
See merge request apt-team/apt!328
|
| |
| |
| |
| |
| |
| | |
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 :(
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
| |
Closes: #1054137
|
|\
| |
| |
| |
| | |
Modernize standard library includes
See merge request apt-team/apt!329
|
|/
|
|
|
|
| |
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.
|
|
|
|
|
| |
While it was initially on the road map for 24.04 it got replaced
with the disable 1024R keys feature.
|
|\
| |
| |
| |
| | |
apt.8: summarise remaining verbs (Closes: #827785)
See merge request apt-team/apt!315
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following were undocumented
// package stuff
{"auto-remove", &DoInstall, nullptr},
{"autopurge",&DoInstall, nullptr},
// system wide stuff
// misc
{"moo", &DoMoo, nullptr},
// for compat with muscle memory
{"dist-upgrade", &DoDistUpgrade, nullptr},
{"showsrc",&ShowSrcPackage, nullptr},
{"depends",&Depends, nullptr},
{"rdepends",&RDepends, nullptr},
{"policy",&Policy, nullptr},
{"build-dep", &DoBuildDep,nullptr},
{"clean", &DoClean, nullptr},
{"distclean", &DoDistClean, nullptr},
{"dist-clean", &DoDistClean, nullptr},
{"autoclean", &DoAutoClean, nullptr},
{"auto-clean", &DoAutoClean, nullptr},
{"source", &DoSource, nullptr},
{"download", &DoDownload, nullptr},
{"changelog", &DoChangelog, nullptr},
{"info", &ShowPackage, nullptr},
And there's good reason for some of it, but I unironically didn't know
where apt changelog lived. It's unsearchable.
So the following are now simple links with no paragraphs:
// query
// package stuff
// system wide stuff
// misc
// for compat with muscle memory
{"showsrc",&ShowSrcPackage, nullptr},
{"depends",&Depends, nullptr},
{"rdepends",&RDepends, nullptr},
{"policy",&Policy, nullptr},
{"build-dep", &DoBuildDep,nullptr},
{"clean", &DoClean, nullptr},
{"distclean", &DoDistClean, nullptr},
{"autoclean", &DoAutoClean, nullptr},
{"source", &DoSource, nullptr},
{"download", &DoDownload, nullptr},
{"changelog", &DoChangelog, nullptr},
|
|\ \
| | |
| | |
| | |
| | | |
Document 'dist-clean'
See merge request apt-team/apt!317
|
| | |
| | |
| | |
| | | |
cf. https://salsa.debian.org/apt-team/apt/-/merge_requests/312#note_453588
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
apt-key: remove carriage returns from armored keyrings before dearmoring
See merge request apt-team/apt!309
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Without this, the awk script returns nothing if the armored keyring
uses Windows/DOS-style CRLF line endings (since awk is designed for
processing Unix text files). This would result in a NO_PUBKEY error
during the signature verification part of an apt-get update.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix bug where ./git-clang-format.sh errors incorrectly
See merge request apt-team/apt!325
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When running the following command twice:
./git-clang-format.sh $(git merge-base HEAD @{u})
The tool previously errored with the following message: patch: **** Only
garbage was found in the patch input.
This is because on a second run there is nothing to patch. Fix that
small issue by excluding the line 'clang-format did not modify any
files' and the line 'no modified files to format'
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Configure the amount of kernels to keep
See merge request apt-team/apt!324
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This commit adds documentation for: APT::Protect-Kernels,
APT::NeverAutoRemove::*, APT::VersionedKernelPackages.
This is to inform users about the newly introduced
NeverAutoRemove::KernelCount feature.
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add public phased update API and separate message list
See merge request apt-team/apt!327
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It is documented and the code supports it, but the command line parsing
actually refuses -a/--host-architecture=arch … probably a sign how much
"apt-get source -b" is (not) used in practice.
Setting via -o APT::Get::Host-Architecture=arch (which -a is just a
shorthand for) works as it did before and can be used if backward
compatibility is important.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The -a flag exists for apt-cache (--all-versions) and -a=arch is
actually an (also documented) option to set host architecture – as the
apt-get manpage documents further below setting a host arch makes sense
only for those commands that actually need one set like source and
build-dep, so other commands keep refusing the option as unsupported as
they should be.
So this commit does indeed just remove a single character from
documentation with no other practical effect.
See: #1061148
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The APT team is very concerned about the encroachement of its
namespace and the impact on security of its file verification
process. We have expressed those concerns in the ITP bug, but
the package was nonetheless uploaded and accepted, so we have
to take this extraordinary step to protect our users.
Gbp-Dch: full
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
pkgcachegen: Use placement new to construct header
See merge request apt-team/apt!320
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reading the contents of a directory is not deterministic, so if we
wanted a fixed order we would need to sort the reported errors, but
as we don't need any specific order lets just accept both possibilities.
Regression-of: 7b41275b9da31d6c87bbaa0c9115e224e47b15e1
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This reverts commit 86e6eace1d50527b5a2396290acd1db819b13e26, reversing
changes made to 6e43eef9ca8250eb561f2c9af2f4890d674f3911.
|
| | |
| | |
| | |
| | | |
Closes: #1059352
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Document and test 'distclean'
See merge request apt-team/apt!312
|
| | | | |
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
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.
|