| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Add AllowRange option to disable HTTP Range usage
See merge request apt-team/apt!188
|
| |
| |
| |
| |
| |
| |
| |
| | |
apt makes heavy usage of HTTP1.1 features including Range and If-Range.
Sadly it is not obvious if the involved server(s) (and proxies) actually
support them all. The Acquire::http::AllowRange option defaults to true
as before, but now a user can disable Range usage if it is known that
the involved server is not dealing with such requests correctly.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APT is not the place this information should be stored at, but it is a
good place to experiment and see what will be (not) needed in the future
for a proper implementation higher up the stack.
This is why "BarbarianArchitectures" is chosen instead of a more neutral
and/or sensible "VeryForeign" and isn't readily exported in the API to
other clients for this PoC as a to be drawn up standard will likely
require potentially incompatible changes. Having a then outdated and
slightly different implementation block a "good" name would be bad.
The functionality itself mostly exists (ignoring bugs) since the
introduction of MultiArch as we always had the risk of encountering
packages of architectures not known to dpkg (forced onto the system,
potentially before MultiArch) we had to deal with somehow and other
edge cases.
All this commit really does is allowing what could previously only be
achieved with editing sources.list and some conf options via a single
config option: -o APT::BarbarianArchitectures=foo,bar
|
|
|
|
|
|
| |
This is very basic support on the testing side, we just test
the debug output but not how long it actually took. Would be
nice to check time really.
|
|
|
|
|
|
|
| |
Add a new Item field called FetchAfter, which determines the earliest
time the item should be fetched at. Adjust insertion into queue to
take it into account alongside priority, and only fill pipelines
with items that are ready.
|
|
|
|
| |
It defaults to false, like the other options there do.
|
|
|
|
|
|
|
|
|
| |
Repositories without Size information for packages are not
proper and need fixing. This ensures people see an error in
CI, and get notifications and hence the ability to fix it.
It can be turned off by setting Acquire::AllowUnsizedPackages
to true.
|
|
|
|
|
|
|
|
|
|
|
| |
People have been asking for a feature to error out on transient network
errors for a while, this gives them one while keeping the door open for
other modes we need, such as --error-on=no-success which we need to
determine when to retry the daily update job.
Closes: #594813
(and a whole bunch of duplicates...)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for Phased-Update-Percentage by pinning
upgrades that are not to be installed down to 1.
The output of policy has been changed to add the level of
phasing, and documentation has been improved to document
how phased updates work.
The patch detects if it is running in a chroot, and if so, always
includes phased updates, restoring classic apt behavior to avoid
behavioral changes on buildd chroots.
Various options are added to control this all:
* APT::Get::{Always,Never}-Include-Phased-Updates and their legacy
update-manager equivalents to always or never include phased updates
* APT::Machine-ID can be set to a UUID string to have all machines in a
fleet phase the same
* Dir::Etc::Machine-ID is weird in that it's default is sort of like
../machine-id, but not really, as ../machine-id would look up
$PWD/../machine-id and not relative to Dir::Etc; but it allows you to
override the path to machine-id (as opposed to the value)
* Dir::Bin::ischroot is the path to the ischroot(1) binary which is used
to detect whether we are running in a chroot.
|
|
|
|
|
| |
Kernels clutter /boot and /boot is small size, so we need to take
extra care to remove kernels when possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our kernel autoremoval helper script protects the currently booted
kernel, but it only runs whenever we install or remove a kernel,
causing it to protect the kernel that was booted at that point in time,
which is not necessarily the same kernel as the one that is running
right now.
Reimplement the logic in C++ such that we can calculate it at run-time:
Provide a function to produce a regular expression that matches all
kernels that need protecting, and by changing the default root set
function in the DepCache to make use of that expression.
Note that the code groups the kernels by versions as before, and then
marks all kernel packages with the same version.
This optimized version inserts a virtual package $kernel into the cache
when building it to avoid having to iterate over all packages in the
cache to find the installed ones, significantly improving performance at
a minor cost when building the cache.
LP: #1615381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do not deal a lot with URIs which need encoding, but then we do it is
a pain that we store it decoded in the acquire system as it means we
have to decode and reencode URIs eventually which is potentially giving
us slightly different URIs.
We see that in our own testing framework while setting up redirects as
the config options are effectively double-encoded and decoded to pass
them around successfully as otherwise %2f and / in an URI are treated
the same.
This commit adds the infrastructure for methods to opt into getting URIs
send in encoded form (and returning them to us in encoded form, too) so
that we eventually do not have to touch the URIs which is how it should
be. This means though that we have to deal with methods who do not
support this yet (aka: all at the moment) for which we decode and encode
while communicating with them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Merging patches is a bit of non-trivial code we have for client-side
work, but as we support also server-side merging we can export this
functionality so that server software can reuse it.
Note that this just cleans up and makes rred behave a bit more like all
our other binaries by supporting setting configuration at runtime and
supporting --help and --version. If you can make due without this, the
now advertised functionality is provided already in earlier versions.
|
|\
| |
| |
| |
| | |
Support marking all newly installed packages as automatically installed
See merge request apt-team/apt!110
|
| |
| |
| |
| |
| |
| |
| | |
Add option '--mark-auto' to 'apt install' that marks all newly installed
packages as automatically installed.
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
|
|/
|
|
| |
This will be mapped to Important for the time being.
|
|
|
|
|
|
|
|
| |
Especially if a lot packages have to be removed due to not to explicitly
expressed conflicts the problem resolver can take a few turns to remove
them all. Allowing it to try a little longer if needed seems beneficial
as the worst which can happen is that we now take two times as long to
present an error message to the user.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include that apt is being run from a service in the user
agent, so traffic can be analysed for interactive vs
non-interactive use, and prioritised accordingly.
It looks like this now:
User-Agent: Debian APT-HTTP/1.3 (2.0.1) non-interactive
A previous version included the full service names, but this
raised some privacy concerns.
LP: #1825000
|
|
|
|
|
|
|
|
|
|
|
| |
This caused unbound error list growth, because each time
we dumped an error, the calls to _config->FindB() inside
operator << would add 3 new errors of the form:
W: Using unknown config option »apt::color« of type BOOL
Hence we are dumping an infinite list of errors, and eventually
that list will exceed available memory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Showing a percentage for a timeout is pretty non-standard. Rework the
progress class so it can show an absolute progress (currently hardcoded
to use seconds as a unit). If there is a timeout (aka if it's not the
maximum long long unsigned -1llu), then show the timeout, otherwise
just count up seconds, e.g.
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1/120s
or
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1s
Also improve the error message to use "Waiting for cache lock: %s" instead of "... (%s)", as having
multiple sentences inside parenthesis is super weird, as is having two closing parens.
We pass the information via _config, as that's reasonably easy and avoids
ABI hackage. It also provides an interesting debugging tool for other
kinds of progress.
|
|
|
|
|
|
| |
This is a rework of !6 with additional stuff for the frontend
lock, so we can lock the frontend lock and then keep looping
over dpkg lock.
|
|
|
|
|
| |
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow to satisfy dependency strings supplied on
the command line, optionally prefixed with
"Conflicts:" to satisfy them like Conflicts.
Build profiles and architecture restriction lists,
as used in build dependencies, are supported as
well.
Compared to build-dep, build-essential is not
installed automatically, and installing of recommended
packages follows the global default, which defaults
to yes.
Closes: #275379
See merge request apt-team/apt!63
|
|
|
|
|
|
|
| |
As long as we are running dpkg, keep an inhibitor that
blocks us from shutting down.
LP: #1820886
|
|\
| |
| |
| |
| | |
Set PATH=/usr/sbin:/usr/bin:/sbin:/bin when running dpkg
See merge request apt-team/apt!38
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids a lot of problems from local installations of
scripting languages and other stuff in /usr/local for which
maintainer scripts are not prepared.
[v3: Inherit PATH during tests, check overrides work]
[v2: Add testing]
|
|/
|
|
|
|
|
|
|
| |
This allows us to install matching auth files for sources.list.d
files, for example; very useful.
This converts aptmethod's authfd from one FileFd to a vector of
pointers to FileFd, as FileFd cannot be copied, and move operators
are hard.
|
|
|
|
|
|
| |
Not needed for common interactions, but for some download-file
interactions it could be useful to set a specific referer as some
servers do not serve requested files otherwise.
|
|
|
|
| |
Closes: #910941
|
|
|
|
|
| |
120s is an insanely high default time out, lower it to 30s
to make things a bit nicer.
|
|
|
|
| |
Prompted-by: Jakub Wilk <jwilk@debian.org>
|
|
|
|
|
|
|
| |
zstd is a compression algorithm developed by facebook. At level 19,
it is about 6% worse in size than xz -6, but decompression is multiple
times faster, saving about 40% install time, especially with eatmydata
on cloud instances.
|
|\
| |
| |
| |
| | |
Check that Date of Release file is not in the future
See merge request apt-team/apt!3
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By restricting the Date field to be in the past, an attacker cannot
just create a repository from the future that would be accepted as
a valid update for a repository.
This check can be disabled by Acquire::Check-Date set to false. This
will also disable Check-Valid-Until and any future date related checking,
if any - the option means: "my computers date cannot be trusted."
Modify the tests to allow repositories to be up to 10 hours in the
future, so we can keep using hours there to simulate time changes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The interesting takeaway here is perhaps that 'chmod +w' is effected by
the umask – obvious in hindsight of course. The usual setup helps with
hiding that applying that recursively on all directories (and files)
isn't correct. Ensuring files will not be stored with the wrong
permissions even if in strange umask contexts is trivial in comparison.
Fixing the test also highlighted that it wasn't bulletproof as apt will
automatically fix the permissions of the directories it works with, so
for this test we actually need to introduce a shortcut in the code.
Reported-By: Ubuntu autopkgtest CI
|
|/ |
|
|
|
|
|
|
| |
Same reasoning as with the previous commit for http with the added
benefit of moving the hard to discover and untranslated example config
into a manpage which could be translated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try establishing connections in alternating address families in
rapid intervals of 250 ms, adding more connections to the wait
list until one succeeds (RFC 8305, happy eyeballs 2).
It is important that WaitAndCheckErrors() waits until it has
a successful connection, a time out, or all connections failed
- otherwise the timing between tries might be wrong, and the
final long wait might exit early because one connection failed
without trying the others. Timing wise, this only works correctly
on Linux, as select() counts down there. But we rely on that in
some other places too, so this is not the time to fix that.
Timeouts are only reported in the final long wait - the short
inner waits are expected to time out more often, and multiple
times, we do not want to report them.
Closes: #668948
LP: #1308200
Gbp-Dch: paragraph
|
|
|
|
|
|
| |
This should help debugging crashes. The signal handler is a C++11
lambda, yay! Special care has been taken to only use signal handler
-safe functions inside there.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces the number of syscalls to about 140 from about
350 or so, significantly reducing security risks.
Also change prepare-release to ignore the architecture lists
in the build dependencies when generating the build-depends
package for travis.
We might want to clean up things a bit more and/or move it
somewhere else.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We detect the effected sources by matching Release info – that has
potential by-catch of repositories which have incorrect field values,
but those are better fixed now anyhow. The bigger incorrectness is that
this message will not only be printed for the Debian services itself but
also for all mirrors not under Debian control but serving Debian like more
local/private mirrors which will not (directly) shutdown. It is likely
through that many of them will follow suite with less visible
announcements or break downright if their upstream source disappears, so
having false-positives here seems benefitial for the user in the end.
|
|
|
|
| |
/org has been obsoleted by /srv for many years on debian.org hosts.
|
|
|
|
|
| |
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
|
|
|
|
|
| |
If we have a user sitting around we can let 'apt' ask the user for a
confirmation rather than print errors at the end and require the user to
figure out which commandline flags are needed to confirm the changes
non-interactively.
|
|
|
|
|
|
|
|
|
|
|
| |
The value of Origin, Label, Codename and co can be used in user
configuration from apts own pinning to unattended upgrades.
A repository changing this values can therefore have serious effects on
the behaviour of apt and other tools using these values.
In a first step we will generate error messages for these changes now
explaining the need for explicit confirmation and provide config options
and commandline flags to accept them.
|
|
|
|
|
|
| |
As requested by Henrique de Moraes Holschuh, here comes
an option to disable TLS support. If the option is set
to false, the internal TLS layer is disabled.
|
|
|
|
|
|
|
|
|
| |
Changes nothing on the program front and as the datatypes are
sufficently comparable fixes no bug either, but problems later on if we
ever change the types of those and prevent us using types which are too
large for the values we want to store waste (a tiny bit of) resources.
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
| |
Most of them in (old) code comments. The two instances of user visible
string changes the po files of the manpages are fixed up as well.
Gbp-Dch: Ignore
Reported-By: spellintian
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our implementation of wildcards was rudimentary. It worked for some
common ones, but it was also broken: For example, armel matched any-armel,
but should match any-arm.
With this commit, we load the correct tables from dpkg. Supported are
both triplets and quadruplet tables (the latter introduced in dpkg 1.18.11).
There are some odd things we have to deal with in the cache filter for
historical and API reasons:
* The character "*" must be accepted as an alternative to any - in fact
it may appear anywhere in the wildcard as we also allow fnmatch() style
wildcard matching on the commandline.
* The code might get passed an arch with a minus at the end, for example
the cmdline "install apt:any-arm-" will first try to check if any-arm-
is a valid architecture. We deal with this by rejecting any wildcard
ending in a minus.
* Triplets are actually implemented by extending them to faux quadruplets
- by prepending a "base" component for the architecture tuple, and "any"
if there is a wildcard component.
Once we have constructed a wildcard, it is transformed into an fnmatch()
expression for historical reasons. In the future, we should really get a
tuple class and implement matching in a better, more explicit way.
This does for now though - it passes all the test cases and accepts all
things it should accept.
Closes: #748936
Thanks: James Clarke <jrtc27@jrtc27.com> for the initial patch
|