| Age | Commit message (Collapse) | Author |
|---|
|
The mode wasn't working at all if not used together with --fix-missing
which while likely to come in pairs its legal to use standalone.
Regression-in: eb1f04dda07c2b69549ad9fd793cca0e91841b3e
(cherry picked from commit 3313eaf97c83177433478505c05815ab02f9782b)
|
|
Keeping the Fd of the cache file we have validated around to later load
it into the mmap ensures not only that we load the same file (which
wouldn't really be a problem in practice), but that this file also still
exists and wasn't deleted e.g. by a 'apt clean' call run in parallel.
(cherry picked from commit 06606f073210fe3902fe92d5ff77fa1ab621b972)
|
|
The update command acquires a lock on lists/, but at the end it will
also require the dpkg/lock while building the binary caches. That seems
rather pointless as we are only reading those files, not causing writing
in them. This can also cause problems if a package installation is
running and a background process (like cron) starts an update: If you
are "lucky" enough the update process will pick the dpkg lock in between
apt calls causing the installation process to fail.
(cherry picked from commit 0d9081598afa051409b03dbdbe5025cd7ce59ba4)
|
|
We get the archives/lock for clean – that is enough to ensure that other
apt instances aren't interfering (or are being interfered with). We
don't need to block actions involving dpkg.
(cherry picked from commit 22acd327ac39ffe3bb14b3e1f2d1f21761de13ca)
|
|
Unlikely that anyone is actually running into this, but if we asked to
not generate a cache and avoid it in the first step we shouldn't create
one implicitly anyway by displaying the statistics.
(cherry picked from commit 33f982b90a4f77be18cb82daf8c79e9c5513761c)
|
|
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"
(cherry picked from commit 4e18c2cee6da39982cc463cafbf27eab5561099f)
|
|
Again no practical difference, but for consistency a boolean option
should really be accessed via a boolean method rather than an int
especially if you happen to try setting the option to "true" …
Gbp-Dch: Ignore
(cherry picked from commit c15ba854b6736696f164e4d2c243a944e2d4006e)
|
|
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
(cherry picked from commit 44ecb8c3579e5ae8828f83530e4151a0ff84d5d6)
|
|
The crude way of preparing a message to be a multiline value failed at
generation valid deb822 in case the error message ended with a new line
like the resolving errors from apt do. apt itself can parse these, but
other tools like grep-dctrl choke on it, so be nice and print valid.
Reported-By: Johannes 'josch' Schauer on IRC
(cherry picked from commit 0161280405fe5aa256dc9df6a56106dd3a1a6f38)
|
|
That was the case already for tar-only and diff-only, but in a more
confusing way and without a message while dsc "worked" before resulting
in a dpkg-source error shortly after as tar/diff files aren't available…
(cherry picked from commit 58ebb3017baf46e33a9bb2c1779d6daede27d108)
|
|
(cherry picked from commit 49b91f6903804183dbe1abb12ce1f9803a3dee5f)
|
|
Previouosly apt's bash completion was such that, given
$ mkdir xyzzz
$ touch xyzzy.deb xyzzx.two.deb
you'd get
$ apt install xyzz<tab>
xyzzx.two.deb xyzzz/
$ apt install /tmp/foo/xyzz<tab>
xyzzx.two.deb xyzzz/
this is inconsistent (xyzzx.two.deb is listed but not xyzzy.deb), but
worse than that it offered things that apt would not actually
recognise as candidates for install:
$ sudo apt install xyzzx.two.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package xyzzx.two.deb
E: Couldn't find any package by glob 'xyzzx.two.deb'
E: Couldn't find any package by regex 'xyzzx.two.deb'
With this small (trival, really) change, apt's bash completion will
only offer things apt understands, and won't recquire an aditional
period in the filename to offer it:
$ apt install xyzz<tab>^C
$ # (no completions!)
$ apt install ./xyzz<tab>
xyzzx.two.deb xyzzy.deb xyzzz/
$ apt install /tmp/foo/xyzz
xyzzx.two.deb xyzzy.deb xyzzz/
fixes #28
LP: #1645815
(cherry picked from commit 6761dae5d0c372d132b0df91753120b59e30fd0e)
|
|
The documentation of APT::Periodic::Verbose doesn't match the code,
specifically level 2 should apply some things differently to level 1
but does not because it uses `-le 2` instead of `-lt 2` or `-le 1`.
Closes: 845599
(cherry picked from commit 250687865e2d27dc949b810e59b07161a4c8f762)
|
|
In ad9416611ab83f7799f2dcb4bf7f3ef30e9fe6f8 we fall back to asking the
original mirror (e.g. a redirector) if we do not get the expected
result. This works for the indexes, but patches are a different beast
and much simpler. Adding this fallback code here seems like overkill as
they are usually right along their Index file, so actually forward the
relevant settings to the patch items which fixes pdiff support combined
with a redirector and partial mirrors as in such a situation the pdiff
patches would be 404 and the complete index would be downloaded.
(cherry picked from commit 5832913a49d4f7c75527264a935cc0ce00627f1d)
|
|
(cherry picked from commit 8e7a99564dd57b0dcb7df47b43e71ccefc8e0ebe)
|
|
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
(cherry picked from commit bb9c5972524ac5c078fa0f0bc5674c7a0fe01fb4)
|
|
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.
(cherry picked from commit 53f3fc59f4eb37eea57bbde53fb75f2e15af0378)
|
|
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.
(cherry picked from commit 4b10240cca0dc0a4e82e42959545d2ae7e622d29)
|
|
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…
(cherry picked from commit dabe9e2482180ada77d2adda2b3c03db22059fb8)
|
|
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…
(cherry picked from commit 066d4a5bab628ef8220971bb5763ff8f3a13de07)
|
|
[Comment from commiter:] I have the feeling that the issue itself is
fixed for a while already as nowadays we have testcases involving a
webserver closing the connection on error (look for "closeOnError") and
no even remotely recent reports about it, but moving the content
clearance above the failure report is a valid change and shouldn't hurt.
Closes: #465572
(cherry picked from commit 324bb34d77a43d1be411c402b2e11f588194439a)
|
|
apt tools do not really support these other variables, but tools apt
calls might, so lets play save and clean those up as needed.
Reported-By: Paul Wise (pabs) on IRC
(cherry picked from commit e2c8c825a5470e33c25d00e07de188d0e03922c8)
|
|
We can't cleanup the environment like e.g. sudo would do as you usually
want the environment to "leak" into these helpers, but some variables
like HOME should really not have still the value of the root user – it
could confuse the helpers (USER) and HOME isn't accessible anyhow.
Closes: 842877
(cherry picked from commit 34b491e735ad47c4805e63f3b83a659b8d10262b)
|
|
A user relying on the deprecated behaviour of apt-get to accept a source
with an unknown pubkey to install a package containing the key expects
that the following 'apt-get update' causes the source to be considered
as trusted, but in case the source hadn't changed in the meantime this
wasn't happening: The source kept being untrusted until the Release file
was changed.
This only effects sources not using InRelease and only apt-get, the apt
binary downright refuses this course of actions, but it is a common way
of adding external sources.
Closes: 838779
(cherry picked from commit 84eec207be35b8c117c430296d4c212b079c00c1)
LP: #1657440
|
|
In effect this is an extension of the 6 years old commit
a8dfff90aa740889eb99d00fde5d70908d9fd88a which uses the autoremover to
remove packages again from the solution which are no longer needed to be
there. Commonly these are dependencies of packages we end up not
installed due to problem resolver decisions. Slightly less common is
the situation we deal with here: a package which we wanted to upgrade
sporting a new dependency, but ended up holding back.
The problem is that all versions of an installed reverse dependencies can
bring back a "garbage" package – we need to do this as there is
nothing inherently wrong in having garbage packages installed or upgrade
them, which itself would have garbage dependencies, so just blindly
killing all new garbage packages would prevent the upgrade (and actually
generate errors). What we should be doing is looking only at the version
we will have on the system, disregarding all old/new reverse dependencies.
Reported-By: Stuart Prescott (themill) on IRC
(cherry picked from commit 952171787a0b865c17d5c9476e272106383ae93a)
|
|
|
|
This prevents CI failures from happening in 1.3 and 1.2 and
might actually be more complete.
Gbp-Dch: ignore
(cherry picked from commit 803dabde5a4345ce83b3d2ffbd475786db9769d9)
|
|
Curl requires URLs to be urlencoded. We are however giving it
undecoded URLs. This causes it go completely nuts if there is
a space in the URI, producing requests like:
GET /a file HTTP/1.1
which the servers then interpret as a GET request for "/a" with
HTTP version "file" or some other non-sense.
This works around the issue by encoding the path component of
the URL. I'm not sure if we should encode other parts of the URL
as well, this one seems to do the trick for the actual issue at
hand.
A more correct fix is to avoid the dequoting and (re-)quoting
of URLs when a redirect occurs / a new request is sent. That's
been on the radar for probably a year or two now, but nobody
bothered implementing that yet.
LP: #1651923
(cherry picked from commit 994515e689dcc5f963f5fed58284831750a5da03)
|
|
|
|
This unit runs unattended-upgrades. If apt itself is part of the
upgrade a restart of the unit will kill unattended-upgrades. This
will lead to an inconsistent dpkg status.
Closes: #841763
Thanks: Alexandre Detiste
(cherry picked from commit e133bb5e81b10bf059b3abeab2d9e41f7206e446)
LP: #1649959
|
|
|
|
This is a follow up to the previous issue where we did not check
if getline() returned -1 due to an end of file or due to an error
like memory allocation, treating both as end of file.
Here we ensure that we also handle buffered writes correctly by
flushing the files before checking for any errors in our error
stack.
Buffered writes themselves were introduced in 1.1.9, but the
function was never called with a buffered file from inside
apt until commit 46c4043d741cb2c1d54e7f5bfaa234f1b7580f6c
which was first released with apt 1.2.10. The function is
public, though, so fixing this is a good idea anyway.
Affected: >= 1.1.9
(cherry picked from commit 6212ee84a517ed68217429022bd45c108ecf9f85)
|
|
This fixes a security issue where signatures of the
InRelease files could be circumvented in a man-in-the-middle
attack, giving attackers the ability to serve any packages
they want to a system, in turn giving them root access.
It turns out that getline() may not only return EINVAL
as stated in the documentation - it might also return
in case of an error when allocating memory.
This fix not only adds a check that reading worked
correctly, it also implicitly checks that all writes
worked by reporting any other error that occurred inside
the loop and was logged by apt.
Affected: >= 0.9.8
Reported-By: Jann Horn <jannh@google.com>
Thanks: Jann Horn, Google Project Zero for reporting the issue
LP: #1647467
(cherry picked from commit 51be550c5c38a2e1ddfc2af50a9fab73ccf78026)
|
|
|
|
Gbp-Dch: ignore
|
|
|
|
We always want to run codecov test, even if there are spurious
failures. We should really work around those failures more, though,
it is starting to annoy me.
|
|
Closes: #838731
|
|
|
|
This fixes a regression introduced in
commit 8f858d560e3b7b475c623c4e242d1edce246025a
don't leak FD in AutoProxyDetect command return parsing
which accidentally made the proxy autodetection code also read
the scripts output on stderr, not only on stdout when it switched
the code from popen() to Popen().
Reported-By: Tim Small <tim@seoss.co.uk>
|
|
|
|
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
|
|
This allows fully automated code coverage testing, which is
basically awesome. To allow the methods and solvers and stuff
which run as _apt to write to our build directory, we need to
adjust the permissions a bit, but otherwise it's OK.
Gbp-Dch: ignore
|
|
We need to ignore messages from gcov. All those messages
start with profiling: and are printed using vfprintf(), so
the only thing we can do is add a library overriding those
functions and linking apt-pkg to it.
|
|
This allows us to easily test coverage
|
|
This cleans up the output a bit, it should also improve performance,
but unfortunately, this does not really seem to be the case.
Gbp-Dch: ignore
|
|
Even if we only configure a single architecture, install dpkg, so
dpkg can assert multi arch correctly. This also has the nice side
effect of making single architecture and multiple architecture
test cases more uniform.
This fixes a regression from f878d3a862128bc1385616751ae1d78246b1bd01
("test: Assert multi-arch in the chroot").
|
|
If we copied one of the existing status files, we might not have
a trailing newline, so let's add one.
Gbp-Dch: ignore
|
|
Commit b60c8a89c281f2bb945d426d2215cbf8f5760738 improved the situation,
but due to inconsistency mostly for planners, not for solvers. As the
idea of hiding errors if we show another error is a bit scary (as the
extern error might be a followup of our intern error, rather than the
reason for our intern error as it is at the moment) we don't discard the
errors, but if we got an extern error we show them directly removing
them from the error list at the end of the run – that list will contain
the extern error which hopefully gives us the best of both worlds.
The problem itself is the same as before: The externals exiting before
apt is done talking to them.
Reported-By: Johannes 'josch' Schauer on IRC
|
|
Commit 3af3ac2f5ec007badeded46a94be2bd06b9917a2 (released in 1.3~pre1)
implements proper fallback for SRV, but that works actually too good
as the RFC defines that such an SRV record should indicate that the
server doesn't provide this service and apt should respect this.
The solution is hence to fail again as requested even if that isn't what
the user (and perhaps even the server admins) wanted. At least we will
print a message now explicitly mentioning SRV to point people in the
right direction.
Reported-In: https://bugs.kali.org/view.php?id=3525
Reported-By: Raphaël Hertzog
|
