| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Improve locking messaging - pid and name, "do not remove lock file"
See merge request apt-team/apt!68
|
|
Also in old changelogs, but nothing really user visible
like error messages or alike so barely noteworthy.
Reported-By: codespell
Gbp-Dch: Ignore
|
|
Reported-By: cppcheck
|
|
The error messages say only which package it was trying to provide, but
not which package & version tried it which can be misleading as to which
package (version) is the offender.
References: #930256
|
|
Work like applying patches via rred can be performed by many concurrent
rred processes, but we can't just spawn new ones forever: We limit us to
the number of CPUs which can drive them and reuse existing ones if they
have nothing to do at the moment.
The problem arises if we have reached the limit of queues and all of
them are busy which is more likely to happen on "slow" machines with few
CPUs. In this case we opted for random distribution, but that can result
in many big files (e.g. Contents) being added to one queue while the
others get none or only small files.
Ideally we would ask the methods how much they still have to do, but
they only know that for the current item, not for all items in the
queue, so we use the filesize of the expected result.
|
|
Change a pronoun in the readme from `he` to `they`
See merge request apt-team/apt!69
|
|
Using gender neutral language in your documentation is a inclusion win!
Here's some documents describing more context here:
- https://en.wikipedia.org/wiki/Singular_they#Trend_toward_gender-neutral_language
- https://open.buffer.com/inclusive-language-tech
- https://www.grammarly.com/blog/use-the-singular-they/
|
|
We want to tell users which process is holding the lock so they
can easily understand what's going on, and we want to advise
users not to remove the lock file, because ugh, that's bad.
Re-initalize the flock structure, in case it got mangled by
previous fcntl call.
|
|
|
|
|
|
We are converting to std::string anyway by passing to
istringstream, and this removes the need for .c_str()
in callers.
|
|
|
|
Gbp-Dch: ignore
|
|
These functions do not produce any useful results anymore, so
it's pointless to keep them around.
|
|
This mostly turns them private and then overrides the public
version with the switch, as recommended.
|
|
1.6 was 13, so 1.7 has 14 reserved, and 1.8 has 15 reserved, so
let's use 16 for 1.9 for now.
|
|
|
|
|
|
|
|
Gbp-Dch: ignore
|
|
apt-cache: only show solutions if displayed
See merge request apt-team/apt!65
|
|
Currently CONNECT requests use the name of the proxy as Host value, instead of
the origin server's name.
According to RFC 2616 "The Host field value MUST represent the naming authority
of the origin server or gateway given by the original URL."
The current implementation causes problems with some proxy vendors. This
commit fixes this.
[jak: Adding a test case]
See merge request apt-team/apt!66
|
|
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
|
|
LP: #1756595
Fixes Debian/apt#94
|
|
Gbp-Dch: ignore
|
|
|
|
|
|
|
|
apt Debian release 1.8.2
|
|
|
|
We need to unlock in the reverse order of locking in order
to get useful behavior.
LP: #1829860
|
|
When accessing repository protected by TLS mutual auth, apt may receive
a "re-handshake" request from the server, which must be handled
in order for download to proceed.
This situation arises when the server requests a client certificate
based on the resource path provided in the GET request, after the inital
handshake in UnwrapTLS() has already occurred, and a secure connection
has been established.
This issue has been observed with Artifactory-backed Debian repository.
To address the issue, split TLS handshake code out into its own method
in TlsFd, and call it when GNUTLS_E_REHANDSHAKE error is received.
Signed-off-by: Michael Zhivich <mzhivich@akamai.com>
(merged from Debian/apt#93)
LP: #1829861
|
|
Closes: #929290
|
|
Closes: #926614
|
|
Github-Fixes: #89
(cherry picked from commit 46ef1a3e8c8895c53ff1e4787dc96d4f6c5dba27)
|
|
The value as shown in the NEWS file (not in the code) has a typo in
which just a "/" and ":" are swapped.
Closes: #917986
(cherry picked from commit 4c27ca80e2de06ab0fd058349f9813b60824cf04)
|
|
Currently, apt-cache [r]depends always shows all solutions for a
package, if appropriate, even if the package itself wasn’t displayed
(e.g. “--installed” was specified).
Thus, currently, with haskell-platform uninstalled and amd64 and i386
enabled, “apt-cache rdepends alex” shows
alex
Reverse Depends:
haskell-platform
alex:i386
haskell-platform
alex:i386
and “apt-cache rdepends alex --installed” shows
alex
Reverse Depends:
alex:i386
alex:i386
which is rather confusing.
This patch changes the behaviour so that solutions are only displayed
for packages which were themselves displayed;
“apt-cache rdepends alex --installed” then shows
alex
Reverse Depends:
Signed-off-by: Stephen Kitt <skitt@debian.org>
|
|
Went as far as "A test case here is a shell script", this paragraph
is _hard_.
|
|
|
|
For Unit193 and those who value grammar, I suppose.
|
|
The <count> did not appear in the html, render it as code instead
so things work correctly.
Fixes Debian/apt#91
|
|
Using the locale-dependent isspace() function here opens us up
to strange locale-dependent behavior.
|
|
This ensures that we do not accidentally stop overriding a
method because it's signature changed in an API break.
|
|
|
|
This is a bit experimental, and we'll go through a few stages
before reaching libapt-pkg.so.6.0.
|
|
This changes the ABI in the packaging based on the one
in the header.
|
|
This is missing the ones that are still actively used in
cacheset.cc, we need to clean those up too, but they are
obviously more tricky.
|
|
|
|
|
