| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
This release is dedicated to Linus Tech Tips.
|
| | |
|
| |\
| |
| |
| |
| | |
Do not remove Essential/Protected due to dependencies
See merge request apt-team/apt!198
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Suggesting the removal of Essential and Protected packages as a
solution leads to situations where YouTubers end up removing their
desktop.
Let's not remove such packages ourselves.
|
| |\ \
| | |
| | |
| | |
| | | |
Require argument to remove essential packages, do not prompt
See merge request apt-team/apt!199
|
| | |/
| |
| |
| | |
Let's make this one step harder.
|
| |\ \
| | |
| | |
| | |
| | | |
bash completion: use `grep -E` instead of `egrep`
See merge request apt-team/apt!197
|
| |/ /
| |
| |
| |
| |
| | |
`egrep` has been deprecated in GNU grep since 2007, and in current post
3.7 Git it has been made to emit obsolescence warnings:
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a9515624709865d480e3142fd959bccd1c9372d1
|
| | |
| |
| |
| | |
Closes: #998830
|
| |\ \
| | |
| | |
| | |
| | | |
Don't print every inline PGP key in Signed-By
See merge request apt-team/apt!195
|
| |/ /
| |
| |
| | |
It looks like a debug line was left in accidentally.
|
| |\ \
| |/
|/|
| |
| | |
Use `command -v` instead of `which`
See merge request apt-team/apt!193
|
| |/
|
|
|
|
|
|
|
|
| |
`which` has been deprecated in debianutils 5.0+. The recommended
replacement, `command -v`, is mandated by Debian policy these days, in
addition to being required by POSIX and its predecessor specs at least
since 1994.
Not found commands cause no output from `command -v` per POSIX, so
remove the redundant 2>&1's while at it.
|
| | |
|
| |
|
|
|
|
|
|
| |
Fix a regression in python-apt where switching the architectures
in the config between cache invocations regressed.
Regression-Of: 8ff4e226af55a9feb168477a2b1a99f9c5152e54
Gbp-Dch: full
|
| |\
| |
| |
| |
| | |
Allow =version and /release selectors on virtual packages
See merge request apt-team/apt!121
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already have code for figuring out if a virtual package is only
provided by a single provider (and otherwise show a list) we can
auto-select for the user, so we can adapt that to work with versioned
provides as well and while at it also release selectors.
The code tries to keep ABI backward compatible and hence turns
relatively ugly as we need a parameter (the selector) to be passed
around without adding a parameter or new virtual methods.
|
| | |
| |
| |
| |
| | |
Edgecase of an edgecase at best, but it works just fine as a dependency,
so it should really work on the commandline as well.
|
| | |
| |
| |
| |
| | |
When color has not been turned on explictly in the configuration
file or options, only turn it on if NO_COLOR is not set.
|
| |\ \
| | |
| | |
| | |
| | | |
apt-pkg/deb/dpkgpm.cc: make DPkg::Chroot-Directory work under fakechroot
See merge request apt-team/apt!189
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Add support for embedding PGP keys into Signed-By in deb822 sources
See merge request apt-team/apt!176
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Rename the argument to Introducer and generalize it to anything
that introduces new keys into the trusted vector, like file names
and full keys.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Extend the Signed-By field to handle embedded public key blocks,
this allows shipping self-contained .sources files, making it
substantially easier to provide third party repositories.
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
This currently has no effect, as there are no quotable characters
inside it, but it will allow us to send embedded keys through to
the method.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
basehttp: Turn HaveContent into a TriState
See merge request apt-team/apt!179
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Set haveContent to HaveContent::FALSE when Content-Length is 0,
and change remaining code to only set it to TRUE if it has not
been set so far.
Closes: #990281
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We need to be able to set HaveContent to false if the Content-Length
is 0, and not have that overriden just because a later header is
Content-Type.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Add AllowRange option to disable HTTP Range usage
See merge request apt-team/apt!188
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
RFC7233 3.2 If-Range specifies the comparison to be an exact match,
not a less or equal, which makes no sense in this context anyhow.
Our server exists only to write our tests against it so this isn't much
of a practical issue. I did confirm with a crashing server that no test
(silently) depends on this or exhibits a different behaviour not
explicitly checked for.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Debian buster (oldstable) ships 6.1 while bullseye (stable) ships 6.5
and so the later is 'fixed'. Upstream declares 6.0 still as supported.
It might be still a while we encounter "bad" versions in the wild, so
if we can detect and work around the issue at runtime automatically we
can save some users from running into "persistent" partial files.
References: https://varnish-cache.org/docs/6.4/whats-new/changes-6.4.html#changes-in-behavior
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Fix file:/// vs file:/ hang & https-proxy for http
See merge request apt-team/apt!187
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The settings used for unwrapping TLS connections depend on the access
and hostname we connect to more than what we eventually unwrap. The
bugreport mentions CaInfo, but all other https-settings should also
apply (regardless of generic or hostname specific) to an https proxy,
even if the connection we proxy through it is http-only.
Closes: #990555
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We allow file (and other file-based methods) URIs to either be given
as file:///path or as file:/path, but in various places of the acquire
system we perform string comparisons on URIs which do not handle this
expecting the canonical representation produced by our URI code.
That used to be hidden by us quoting and dequoting the URIs in the
system, but as we don't do this anymore we have to be a bit more careful
on input.
Ideally we would do less of these comparisons, but for now lets be
content with inserting a canonicalisation early on to prevent hangs in
the acquire system.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
add pattern to select packages by priority (closes: #989558)
See merge request apt-team/apt!185
|
| | | | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
Streamline access to barbarian architecture functionality
See merge request apt-team/apt!184
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
What does a M-A:allowed package from non-native/non-foreign architecture
provide? If we look at M-A:foreign, such a package satisfies
dependencies within its own architecture, but not in other
architectures, so the same should apply to :any dependencies on
M-A:allowed packages, but we have a problem: While unqualified package
names are architecture-specific, the virtual package name qualified with
:any is not (see 3addaba1ff).
We could of course make it architecture-specific now, but that would
introduce many virtual packages for this relatively minor usecase and
would reintroduce a need for special display handling.
So, we pull a trick here: Barbarian M-A:allowed packages do not provide
the architecture-independent :any package anymore, but only a specific
one and every :any dependency from a barbarian package is rewritten to
an or-group of the specific and the independent :any package.
References: 3addaba1ff
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As we don't know which architectures we will deal with and to avoid
creating many "unneeded" packages (and provides) the cache
generation uses a scheme of on-demand creation (see ecc138f858).
This assumed a particular handling of :any which got changed later
(3addaba1ff) making this code path not only no longer needed for
M-A:allowed, but actually wrong as it would go on and create provides
for the explicit Provides of a package as if the package would be
M-A:foreign.
The result was that a package A:amd64 providing B tagged as M-A:allowed
would satisfy a "C:armel depends on B". Note that this bug does NOT
effect "C:armel depends on A" which is (correctly) not satisfied as
before.
References: ecc138f858, 3addaba1ff
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Back than M-A was added to build-dependencies (#558104) only the
qualifiers :native and :any were considered at first which for the
native case behave the same, so stripping was a good idea.
Nowadays we could encounter arch-qualified dependencies, too, through –
or slightly more likely conflicts perhaps – at least in theory as in
practice native build-dep operations in Debian and elsewhere wouldn't
have other architectures available anyhow.
Still, we have full support for all this for the crossbuilding case
which makes active use of this (at least is far more likely to do so),
so it seems better to converge on one edgecase rather than keeping
two in active use and so produce potentially different results for not
specifying -a and -a $native.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This just moves code around without actually changing anything.
Gbp-Dch: Ignore
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
APTs ad hoc testing framework for integration tests is not intending to
be a general propose framework, but it is relatively easy to abuse it
for other projects anyhow with some refactoring even if that is neither
recommend nor officially supported.
Gbp-Dch: Ignore
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Gbp-Dch: Ignore
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Back in 2015 the code inside libapt who was using this field was dropped
as even if we are on a system which is not configured for MultiArch,
there are still edge cases in which the cache can include very foreign
packages, so any assumption you could make thinking only a single
architecture will be in the cache is probably wrong.
Maintaining two different codepaths for Multi- and SingleArch is likely
not very beneficial for code and users alike and is surprisingly hard to
answer correctly and becoming even harder still, so always assuming the
"worst case" seems like the far better option.
References: 6c9937da76b9155d166092b9dda22d06200510c1
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When an item has been delayed and the queue is cycled to start
it, we did not properly report an error from the cycling, and
we would then fail in the assert(), causing all errors to be
lost.
Propagate the error instead and make the assert a warning.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Fix infinite recursions in MarkPackage and improve recursions in general
See merge request apt-team/apt!183
|