| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
ABI BREAK: Implement pinning by source package
See merge request apt-team/apt!96
|
|
|
|
The current man-page has "(work in progress") for `apt list`.
I feel after more than >5y we can remove this.
|
|
|
|
Missed that in pu/short-patterns.
|
|
|
|
|
|
|
|
Also make pattern detector in cacheset and private's list accept
such patterns. We probably should just try to parse and see if it
is a (start of a) pattern.
|
|
|
|
|
|
This implements the src: syntax inside policy, allowing you to
pin by source package. This by default only pins the native
architecuture, use src:pkg:any to pin for all architectures
in your cache.
Closes: #166032
|
|
|
|
|
|
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
|
|
|
|
Fix a mistake in man french translation
See merge request apt-team/apt!83
|
|
Pu/patterns phase2
See merge request apt-team/apt!85
|
|
This avoids downgrade attacks where an attacker could inject
Location: http://private.example/
and then (having access to raw data to private.example, for example,
by opening a port there, or sniffing network traffic) read the credentials
for the private repository.
Closes: #945911
|
|
|
|
|
|
|
|
|
|
This is pure syntactic sugar - ?narrow does not exist in the
abstract syntax.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This matches any package that does not have versions.
|
|
The ?exact-name pattern matches the name exactly, there is
no substring matching going on, or any regular expression
or fnmatch magic.
|
|
This matches all packages where at least one of the versions
is marked essential; or well, whenver apt considers a package
essential.
|
|
This matches all packages that have broken dependencies in the
installed version or the version selected for install.
|
|
These two are mutually exclusive states of installed-ness. And
?installed package is fully unpacked and configured; a ?config-files
package only has config files left.
|
|
These match packages that have no version in a repository, or
where an upgrade is available. Notably,
?and(?obsolete,?upgradable) == ?false
because an upgradable package is by definition not obsolete.
|
|
These patterns allow you to identify automatically installed
packages, as well as automatically installed packages that are
no longer reachable from the manually installed ones.
|
|
This implements the basic logic patterns:
?and ?false ?not ?or ?true
and the basic package patterns:
?architecture ?name ?x-name-fnmatch
|
|
This does not describe much yet, as there's not much to talk
about.
|
|
|
|
|
|
|
