| Age | Commit message (Collapse) | Author |
|---|
|
This visits dependencies of all manually installed metapackages,
as determined by APT::Never-MarkAuto-Sections, and marks them as
automatically installed. It can be used to clean up autoflags after
a d-i install, for example.
|
|
Closes: #916358
|
|
Closes: #915952
|
|
|
|
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.
|
|
|
|
|
|
|
|
Reviewed-By: Helge Kreutzmann <debian@helgefjell.de>
|
|
Closes: #912022
|
|
Support subkeys and multiple keyrings in Signed-By options
See merge request apt-team/apt!27
|
|
apt-get.8: mention --only-source in 'source' and 'build-dep' description
See merge request apt-team/apt!24
|
|
Closes: #910941
|
|
|
|
Including a block-element like informalexample in a para is legal, but
the documentation of the para tag hints that some processing systems may
have difficulties handling this – so lets just move it out of the block
and be happy as it is (again?) displayed.
Closes: #909712
|
|
|
|
|
|
do not suggest that 'source' and 'build-dep' arguments are binary
package names only
|
|
A user can specify multiple fingerprints for a while now, so its seems
counter-intuitive to support only one keyring, especially if this isn't
really checked or enforced and while unlikely mixtures of both should
work properly, too, instead of a kinda random behaviour.
|
|
|
|
|
|
|
|
|
|
Closes: #900602
|
|
120s is an insanely high default time out, lower it to 30s
to make things a bit nicer.
|
|
This shouldn't make a practical difference for most people, but for edge
cases it avoids DNS lookups and additionally prevents us from perfoming
unneeded SRV requests, too.
|
|
The boilerplate stems from automatic processing of these files as
most (with the exception of po/nl.po) are one-off (partial)
translations from years past.
Gbp-Dch: Ignore
|
|
Prompted-by: Jakub Wilk <jwilk@debian.org>
|
|
The formatting is very basic and more should probably be done, but we at
least get the files out of the root directory which in case of the
various READMEs was confusing salsa which one display as (central) README.
|
|
Reported-By: codespell & spellintian
Gbp-Dch: Ignore
|
|
|
|
Closes: 679580
|
|
|
|
[jak: Fix invalid empty line]
Closes: #895117
|
|
This reverts commit 57a00c50b14a49ed91816e3f4467e0f2e57ee772.
|
|
pu/zstd
See merge request apt-team/apt!8
|
|
Reported-By: Mattia Rizzolo on IRC
|
|
Closes: 679580
|
|
Reported-By: lintian spelling-error-in-manpage
|
|
We just enabled https on changelogs.ubuntu.com, let's use it.
|
|
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
|
|
|
