| Age | Commit message (Collapse) | Author |
|---|
|
Some post-invoke scripts install packages, which fails because
the environment variable is not set. This sets the variable for
all three kinds of scripts {pre,post-}invoke and pre-install-pkgs,
but we will only allow post-invoke at a later time.
Gbp-Dch: full
(cherry picked from commit 6675601c81de85b40dc89772c1d6d17f1811c5ba)
LP: #1796808
|
|
We forgot to set the variable for the selection changes. Let's
set it for that and some other dpkg calls.
Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a
(cherry picked from commit 55489885b51b02b7f74e601a393ecaefd1f71f9c)
|
|
The dpkg frontend lock is a lock dpkg tries to acquire
except if the frontend already acquires it.
This fixes a race condition in the install command where the
dpkg lock is not held for a short period of time between
different dpkg invocations.
For this reason we also define an environment variable
DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows
not to try to acquire the frontend lock because it's held
by a parent process.
We can set DPKG_FRONTEND_LOCKED only if the frontend lock
really is held; that is, if our lock count is greater than 0
- otherwise an apt client not using the LockInner family of
functions would run dpkg without the frontend lock set, but
with DPKG_FRONTEND_LOCKED set. Such a process has a weaker
guarantee: Because dpkg would not lock the frontend lock
either, the process is prone to the existing races, and,
more importantly, so is a new style process.
Closes: #869546
[fixups: fix error messages, add public IsLocked() method, and
make {Un,}LockInner return an error on !debSystem]
(cherry picked from commit c2c8b4787b0882234ba2772ec7513afbf97b563a)
LP: #1781169
|
|
debSystem uses a reference counted lock, so you can acquire it
multiple times in your applications, possibly nested. Nesting
locks causes a fd leak, though, as we only increment the lock
count when we already have locked twice, rather than once, and
hence when we call lock the second time, instead of increasing
the lock count, we open another lock fd.
This fixes the code to check if we have locked at all (> 0).
There is no practical problem here aside from the fd leak, as
closing the new fd releases the lock on the old one due to the
weird semantics of fcntl locks.
(cherry picked from commit 79f012bd09ae99d4c9d63dc0ac960376b5338b32)
|
|
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.
|
|
Allow specifying an alternative path to the InRelease file, so
you can have multiple versions of a repository, for example.
Enabling this option disables fallback to Release and Release.gpg,
so setting it to InRelease can be used to ensure that only that
will be tried.
We add two test cases: One for checking that it works, and another
for checking that the fallback does not happen.
Closes: #886745
|
|
The summary line sounds a bit much: what we end up doing is just adding
two more guards before using results which should always be valid™.
That these values aren't valid is likely a bug in itself somewhere, but
that is no reason for crashing.
|
|
We have quite a bit of metadata available for the files we acquire, but
the methods weren't told about it and got just the URI. That is indeed
fine for most, but to avoid methods trying to parse the metadata out of
the provided URIs (and fail horribly in edgecases) we can just as well
be nice and tell them stuff directly.
|
|
gcc was warning about ignored type qualifiers for all of them due to the
last 'const', so dropping that and converting to static_cast in the
process removes the here harmless warning to avoid hidden real issues in
them later on.
Reported-By: gcc
Gbp-Dch: Ignore
|
|
gcc has problems understanding this construct and additionally thinks it
would produce multiple lines and stuff, so to keep using it isn't really
worth it for the few instances we have: We can just write the long form
there which works better.
Reported-By: gcc
Gbp-Dch: Ignore
|
|
Mostly harmless as it just means that apt thinks that the dpkg
commandline it is building is slightly longer than it actually is and we
have various ways of avoiding generating very long lines nowadays, but
calculating the right value can't hurt.
Reported-By: gcc -Wmultistatement-macros
|
|
Using hardcoded array-indexes in the build-dependency parsing is
efficient, but less discoverable and easier to break. We can avoid
this by making it even more efficient (not that it would be noticeable)
allowing us to do explicitly named comparisons instead.
Gbp-Dch: Ignore
|
|
APT used to parse only wellformed files produced by repository creation
tools which removed empty files as pointless before apt would see them.
Now that apt can be told to parse e.g. debian/control files directly, it
needs to be a little more accepting through: We had this with comments
already, now let it deal with the far more trivial empty fields.
Closes: #875363
|
|
In commit Do not warn about duplicate "legacy" targets, we
we added an if, that changed the .po files...
|
|
If a source has a legacy Contents file, and two lines mention
the same archive but different components, a warning would be
issued that is confusing. So, as the field is named Contents-deb-legacy,
let's just not print warnings for fields containing "legacy".
LP: #1697120
Closes: #839259
|
|
The relevant calling code as well as the implementation for the deb
system was removed 2 years ago with the refactoring of release
information storage (b07aeb1a6e24825e534167a737043441e871de9f).
This commit removes the the unused remains of this change with no
practical effect on anybody (expect codesize) as the methods were
declared as hidden and hence only libapt could have called it.
Gbp-Dch: Ignore
|
|
APT by default logs terminal (term.log) and actions (history.log), but
if either or Dir::Log directly is set to /dev/null it continues to do
so, which isn't too bad – just wasted effort – but term.log is
chmodded to protect it from the general public (as it may contain
otherwise private data the admin entired in the terminal) which
shouldn't happen for /dev/null.
|
|
As a follow up to the last commit, let's replace APT_CONST
with APT_PURE everywhere to clean stuff up.
|
|
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
|
Including cacheiterators.h before pkgcache.h fails because
pkgcache.h depends on cacheiterators.h.
|
|
Commit d7c92411dc1f4c6be098d1425f9c1c075e0c2154 parses the Components
section of (In)Release and attempts to detect the distribution's
supported components. While doing so, it handles component names with
slashes in a special manner, assuming that the actual component is only
the part after the final slash. This is done to handle
security.debian.org, which usually appears in sources.list as follows:
deb http://s.d.o/debian-security stretch/updates main contrib non-free
while the actual release file has:
Codename: stretch
Components: updates/main updates/contrib updates/non-free
While this special handing on APTs part indeed works for
debian-security, it emits spurious warnings on repositories that
actually use slashes in the component names *and* appear so in
sources.list.
We fix this by adding both component versions (whole and final part) to
the SupportedComponents array.
Closes: #868127
|
|
This should fix some issues with dpkg normalizing such
values. Suprisingly enough apt treats the Version: field
the same, even with epoch vs without, but not when searching,
and does not strip the 0: from the output.
|
|
This gives the repository owner a chance to explain why this change was
needed – e.g. explaining the organisational changes or simply detailing
the changes in the new release made. Note that this URI is also shown
if the change is accepted, so it also draws attention to release notes
of minor updates (if users watch apt output closely).
|
|
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.
|
|
The error cases are just as unlikely as the memory leaks to ever cause
real problems, but lets play it safe for correctness.
Reported-By: scan-build & clang
Gbp-Dch: Ignore
|
|
If we couldn't find an entry for a Sources file we would generate an
error while for a Packages file we would silently skip it due to
assuming it is missing because it is empty. We can do better by checking
if the repository declares that it supports a component we want to get
the file from and if not say so and hint at the user making a typo.
An example were this helps is mozilla.debian.net which dropped the
firefox-aurora component (as upstream did) meaning no upgrades until the
user notices manually that the repository doesn't provide packages
anymore. With this commit warnings are raised hopefully causing the user
to investigate what is wrong (sooner).
|
|
If the last alternative(s) of an Or group is ignored, because it does
not match an architecture list, we would end up keeping the or flag,
effectively making the next AND an OR.
For example, when parsing (on amd64):
debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386]
=> debhelper (>= 9), libnacl-dev |
Which can cause python-apt to crash.
Even worse:
debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386], foobar
=> debhelper (>= 9), libnacl-dev [amd64] | foobar
By setting the previous alternatives Or flag to the current Or flag
if the current alternative is ignored, we solve the issue.
LP: #1694697
|
|
In the case of build-dep and other commands where a file can be
passed we must make sure not to normalize the path name as that
can have odd side effects, or well, cause the operation to do
nothing.
Test for build-dep-file is adjusted to perform the vcard check
once as "vcard" and once as "VCard", thus testing that this
solves the reported bug.
We inline the std::transform() and optimize it a bit to not
write anything in the common case (package names are defined
to be lowercase, the whole transformation is just for names
that should not exist...) to counter the performance hit of
the added find() call (it's about 0.15% more instructions
than with the existing transform, but we save about 0.67%
in writes...).
Closes: #854794
|
|
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
|
|
Nothing in user visible strings.
Gbp-Dch: Ignore
Reported-By: codespell
|
|
This is useful for e.g. Britney, where the Build-Depends would have to
be parsed for multiple architectures. With this change, the call can
choose the architecture without having to mess with the config.
Signed-off-by: Niels Thykier <niels@thykier.net>
Closes: #845969
(jak@d.o: made the code compile)
|
|
Interpreting a boolean as an int works just fine – it just hasn't the
intended result – it isn't a serious problem through as the disabling of
the usage of this dpkg calling style is just an "optimization"
|
|
This can happen e.g. for file: repositories. There is no inherent
problem with setting such values internally, but its bad style,
forbidden in the manpage and could be annoying in the future.
Gbp-Dch: Ignore
|
|
Unlikely to have any practical effect, but its more consistent to use
the right methods instead of performing it slightly incorrect by hand.
Gbp-Dch: Ignore
|
|
|
|
We try to configure all packages at the end which need to be configured,
but that also applies to packages which weren't completely installed
(e.g. maintainerscript failed) we end up removing in this interaction
instead.
APT doesn't perform this explicit configure in the end as it is using
"dpkg --configure --pending", but it does confuse the progress report
and potentially also hook scripts.
Regression-Of: 9ffbac99e52c91182ed8ff8678a994626b194e69
|
|
dpkg stumbles over these (#844300) and we haven't dropped 'easier'
removes to be implicit and to be scheduled by dpkg by default so far
so we shouldn't push the decision in such cases to dpkg either.
|
|
Our old idea was to look for the first package which would be "touched"
and take this as the package dpkg is talking about, but that is
incorrect in complicated situations like a package upgraded to/from
multiple M-A:same siblings installed.
As we us the progress report to decide what is still needed we have to
be reasonabily right about the package dpkg is talking about, so we jump
to quite a few loops to get it.
|
|
Given that we use the progress information to skip over actions dpkg has
already done like not purging a package which was already removed and
had no config files or not acting on disappeared packages and such it is
important that apt and dpkg agree on which states the package has to
pass through.
To ensure that we keep tabs on this in the future a warning is added at
the end if apt hasn't seen all the action it was supposed to see. I
can't wait for the first bugreporters to wonder about this…
|
|
If a package is triggered dpkg frequently issues two messages about it
causing us to make a note about it both times which messes up our
planned dpkg actions view. Adding these actions if we have nothing else
planned fixes this and should still be correct as those planned actions
will deal with the triggering just fine and we avoid strange problems
like a package triggered before its removed…
|
|
Our profile says we spend about 5% of the time transforming the
hex digits into the binary format used by HashsumValue, all for
comparing them against the other strings. That makes no sense
at all.
According to callgrind, this reduces the overall instruction
count from 5,3 billion to 5 billion in my example, which
roughly matches the 5%.
|
|
Generating a string for each version we see is somewhat inefficient.
The problem here is that the Description tag names are longer than
15 byte, and thus require an allocation on the heap, which we should
avoid.
It seems reasonable that 20 characters works for all languages codes
used for archive descriptions, but if not, there's a warning, so
we'll catch that.
This should improve performance by about 2%.
|
|
Stop copying stuff, and just parse the bytes one by-one to the
newly created AddCRC16Byte. This improves the instruction count
for an update run from 720,850,121 to 455,801,749 according to
callgrind.
|
|
This one has some obvious collisions for non-alphabetical characters,
like some control characters also hashing to numbers, but we don't
really have those, and these are hash functions which are not
collision free to begin with.
|
|
This basically gets rid of 40-50% of the hash table lookups,
making things a bit faster that way, and the profiles look
far cleaner.
|
|
You can pretty much achieve the same with a local dummy package if you
want to, but libapt has an inbuilt setting for essential: "apt" which
can be overridden with this option as well – it could be helpful in
quick tests and what not so adding this alternative shouldn't really
hurt much.
We aren't going to document them much through as care must be taken in
regards to the binary caches as they aren't invalidated by config
options alone, so the effects of old settings could still be in them,
similar to the other already existing pkgCacheGen option(s).
Closes: 767891
Thanks: Anthony Towns for initial patch
|
|
These new enum values might cause "interesting" behaviour in tools not
expecting them – like an old apt would think a Build-Conflicts-Arch is
some sort of Build-Depends – but that can't reasonably be avoided and
effects only packages using B-D/C-A so if there is any breakage the
tools can easily be adapted.
The APT_PKG_RELEASE number is increased so that libapt users can detect
the availability of these new enum fields via:
#if APT_PKG_ABI > 500 || (APT_PKG_ABI == 500 && APT_PKG_RELEASE >= 1)
Closes: #837395
|
|
If the dependency line does not contain spaces in the repository
but does in the dpkg status file (because dpkg normalized the
dependency list), the dpkg line might be longer than the line
in the repository. If it now happens to be longer than 1024
characters, it would be skipped, causing the hashes to be
out of date.
Note that we have to bump the minor cache version again as
this changes the format slightly, and we might get mismatches
with an older src cache otherwise.
Fixes Debian/apt#23
|
|
If a Binary field contains one or more spaces before a comma, the
code produced a segmentation fault, as it accidentally set a pointer
to 0 instead of the value of the pointer.
If the comma is at the beginning of the field, the code would
create a binStartNext that points one element before the start
of the string, which is undefined behavior.
We also need to check that we do not exit the string during the
replacement of spaces before commas: A string of the form " ,"
would normally exit the boundary of the Buffer:
binStartNext = offset 1 ','
binEnd = offset 0 ' '
isspace_ascii(*binEnd) = true => --binEnd
=> binEnd = - 1
We get rid of the problem by only allowing spaces to be eliminated
if they are not the first character of the buffer:
binStartNext = offset 1 ','
binEnd = offset 0 ' '
binEnd > buffer = false, isspace_ascii(*binEnd) = true
=> exit loop
=> binEnd remains 0
|
|
|
