| Age | Commit message (Collapse) | Author |
|---|
|
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
(cherry picked from commit 6c0c94ed32b8e679b14b0f89b51c1c336dc0ab9c)
|
|
The default buffer size for pkgTagFile is 32kb which should be big
enough for everything… expect for enormous lists of provides,
resulting in:
$ apt show librust-winapi-dev
E: Unable to parse package file /var/lib/apt/lists/ftp.br.debian.org_debian_dists_unstable_main_binary-amd64_Packages (2)
E: Internal Error, Unable to parse a package record
The "apt-cache show" codepath uses instead a max size for all files,
which seems a bit excessive, but works – using the max size for the file
in question seems most appropriate.
The patch is written for the 1.6.y series as a rewrite of the related
code in the 1.7.y series (commit bf53f39c9a0221b670ffff74053ed36fc502d5a0)
removed this problem before it was reported.
Closes: #905527
LP: #1787120
(cherry picked from commit 409ceec9ed30cbebd8ece1ef7ce667ab5a32f9df)
|
|
LP: #1698159
(cherry picked from commit 923ba67464960940a19b24a341e896a9338161fb)
|
|
|
|
(cherry picked from commit 4ba9412d545232794bd7838e0174df8fda4152b8)
LP: #1778551
|
|
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)
(cherry picked from commit 1edcb718293f24ad190703a345f8f868b6e3bcc4)
LP: #1778547
|
|
APT clients always noticed if a method isn't supported and nowadays
generate a message of the form:
E: The method driver …/foobar could not be found.
N: Is the package apt-transport-foobar installed?
This only worked if a single source was using such an unavailable method
through as we were registering the failed config the first round and
the second would try to send requests to the not started method, which
wouldn't work and hang instead (+ hiding the error messages as they would
be shown only at the end of the execution).
Closes: 870675
(cherry picked from commit e250a8d8d8ef2f8f8c5e2041f7645c49fba7aa36)
(cherry picked from commit 281dbc8e481fbaeaf7310e0800468d4d212711b8)
LP: #1762766
|
|
|
|
This is based on 1.4.y, but with the old build system, and
xenial as the base image.
|
|
This reverts commit dd547ebaffd2aceb42e2908f1d5f0ab386af6cb1.
LP: #1751225
|
|
|
|
There's no real point in pulling it in in the timer already,
and it it somewhat saver to do so in the service.
(cherry picked from commit 11417c1058e1b8441ee8f30f948e854b7a6ce89e)
LP: #1716973
(cherry picked from commit 3e639687bbea08acd34f5a66dc99ea62848b7c17)
|
|
A libapt user who hasn't initialized _system likely has a reason, so we
shouldn't greet back with a segfault usually deep down in the callstack
for no reason. If the user had intended to pick up information from the
system, _system wouldn't be uninitialized after all.
LP: #1613184
SRU: 1.4.y
(cherry picked from commit cba5c5a26a9bf00724f8ea647ac61b30e32734ba)
|
|
The main process is guessed by systemd. This prevents killing dpkg
run by unattended-upgrades in the middle of installing packages
and ensures graceful shutdown.
The timeout of 900 seconds after which apt-daily-upgrade.service
is killed is in sync with unattended-upgrades's timer.
LP: #1690980
(cherry picked from commit 78bc10d4702b30b46d802294ac43cffc34d9c431)
|
|
APT considered any response with a Content-Length to have a
body, even if the value of the header was 0. A 0 length body
however, is equal to no body.
(cherry picked from commit d47fb34ae03566feec7fec6dccba80e45fa03e6f)
|
|
When APT was trying multiple addresses, any later error
somewhere else would be reported with ConnectionRefused
or ConnectionTimedOut as the FailReason because that
was set by early connect attempts. This causes APT to
handle the failures differently, leading to some weirdly
breaking test cases (like the changed one).
Add debugging to the previously failing test case so
we can find out when something goes wrong there again.
(cherry picked from commit d3a70c3e5ae68a0e5a3d4667dd1d0fc0887e6263)
|
|
An SRV record includes a portnumber to use with the host given, but apt
was ignoring the portnumber and instead used either the port given by
the user for the initial host or the default port for the service.
In practice the service usually runs on another host on the default
port, so it tends to work as intended and even if not and apt can't get
a connection there it will gracefully fallback to contacting the initial
host with the right port, so its a user invisible bug most of the time.
(cherry picked from commit 9bdc09016f9570389451dd619d7e878bfeaa91df)
|
|
This typo exposes a bug in apt-listchanges that prevents commands like
`apt-listchanges --show-all apt_*.deb' from showing the changelog.
The bug will be fixed in next upload of apt-listchanges, but I think
it would be nice have the typo fixed as well.
Closes: 866358
(cherry picked from commit ec0ebf784d15821786334a4781d0b58b0b163363)
|
|
|
|
Instead of passing -d, which enables a debugging mode; check if
unattended-upgrade supports an option --download-only (which is yet
to be implemented) and use that.
Closes: #863859
Gbp-Dch: Full
(cherry picked from commit 31c81a37ac6dceda0c94ce088b338b6b09afd5a4,
cedf80c55766868eadc7ed59a27537c9a5d91edf)
(cherry picked from commit 80b808940e69d2379d175da1aec97c3301cd0777)
|
|
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
(cherry picked from commit 7ddf958e370d13f93edc6923bee289b2f6444b41)
(cherry picked from commit 423ba4a958b9da02926e586bf59995817cafc32a)
|
|
|
|
Gbp-Dch: ignore
(cherry picked from commit 3819004c2cb3893bfa136f3c44a5783c42cd2a8d)
(cherry picked from commit 7e65cbfe4a073aa4e433681a8f52a3b87b31f63d)
|
|
Error:
pkgs that look like they should be upgraded:
Error in function stop
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 240,
in stop
apt_pkg.size_to_str(self.current_cps))).rstrip("\n"))
File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 51,
in _write
self._file.write("\r")
AttributeError: 'NoneType' object has no attribute 'write'
fetch.run() result: 0
Caused by:
LOCKFD=3
unattended_upgrades $LOCKFD>&-
Unfortunately this code does not work, it is equivalent to
unattended_upgrades 3 >&-
I.e. it left fd 3 open, but closed stdout!
Closes: #862567
(cherry picked from commit 7b4581cbe8fcf6e2bd56a27c5a7a1e6ea33d2973)
(cherry picked from commit 3310f862cba0b997ede8fc4e2d270ab0f6b49e73)
|
|
|
|
Closes: #861846
(cherry picked from commit 6ff527b4f8c88ac406effb1d88fdb3c9ab42967b)
(cherry picked from commit 732325f9d00cb5c32f4ba7a3d5524a467ff037b2)
|
|
The timer doing downloading runs throughout the day, whereas
automatic upgrade and clean actions only happen in the morning.
The upgrade service and timer have After= ordering requirements
on their non-upgrade counterparts to ensure that upgrading at
boot takes place after downloading.
LP: #1686470
(cherry picked from commit 496313fb8e83af2ba71f6ce3d729be687c293dfd)
(cherry picked from commit a234cfe1466066aa1f404cf01e544f16cb517846)
|
|
Use a lock file to make sure only one instance of the
script is running at the same time.
(cherry picked from commit ea49b66372912354143b810e2826301d651a2b37)
(cherry picked from commit 820b469f0648eaa63356a812cd96ca8c4af6ac71)
|
|
We want to download the upgrades first, if unattended-upgrades
is configured. We don't want to use the normal dist-upgrade -d
thing for it, though, as unattended-upgrades only upgrades a
subset.
(cherry picked from commit 01e324a6893164feace153bc17fe6453b6fa97db)
(cherry picked from commit f1f796a3c506400f54f4a39b6f43b0494cfb210c)
|
|
This adds an argument to the script which may be update, install,
or empty. In the update cases, downloads are performed. In the
install case, installs are performed. If empty, both are run.
Gbp-Dch: ignore
(cherry picked from commit 007b22ee6fd33d9b03637577f8401a43c5e7c90c)
(cherry picked from commit d02da9dcaa9daac2a29cf9d9ee3963bf6098fe4e)
|
|
|
|
(cherry picked from commit c832379bb1163800ed24412fbc19c53eea606a66)
(cherry picked from commit 3e26e4e97a6f15bc0fbe16e67aa21165d96a5581)
|
|
The timeout values were so large that the timer could run at any
random time of the day, possibly easily interfering with business
hours, and causing trouble. Reduce them to 30 minutes of random
delay and an accuracy to the default value (1 minute).
Also drop the 18:00 event. People still actively use their device
during that time, and for servers, there might be less attendance
than in the regular 06:00 time slot, so longer time to fix things
if something breaks.
During a boot, the service might be run to catch up with a timer
that would have normally elapsed. Due to no dependencies, it would
have run before the network is online - that's bad. Adding an After
and a Wants fixes that for boots, but still leaves the same issue
for Resume.
LP: #1615482
(cherry picked from commit b4f32b13055287d2ac46a08255db475af195b5f7)
(cherry picked from commit 6267b47f85588fdd00f6e667598abe52887385ae)
|
|
In the intended usecase where this serves as a hack there is no problem
with double/single quotes being present as we write it to a log file
only, but nowadays our calling of apt-key produces a temporary config
file containing this "setting" as well and suddently quoting is
important as the config file syntax is allergic to it.
So the fix is to ignore all quoting whatsoever in the input and just
quote (with singles) the option values with spaces. That gives us 99% of
the time the correct result and the 1% where the quote is an integral
element of the option … doesn't exist – or has bigger problems than a
log file not containing the quote. Same goes for newlines in values.
LP: #1672710
(cherry picked from commit 2ce15bdeac6ee93faefd4b42b57f035bef80c567)
(cherry picked from commit c75620dcfa749f8030e0180df44eec746402885d)
|
|
This gets rid of warnings about .ucf-dist files
Reported-By: Axel Beckert (on IRC)
(cherry picked from commit 5094697fe4b2459ff6f706a22006d3028369f3fa)
(cherry picked from commit 0c42bab8534b4dc95dabdff2a8e08a3574291ec0)
|
|
|
|
-1 is not an allowed value for the file descriptor, the only
allowed non-file-descriptor value is AT_FDCWD. So use that
instead.
AT_SYMLINK_NOFOLLOW has a weird semantic: It checks whether
we have the specified access on the symbolic link. It also
is implemented only by glibc on Linux, so it's inherently
non-portable. We should just drop it.
Thanks: James Clarke for debugging these issues
Reported-by: James Clarke <jrtc27@jrtc27.com>
(cherry picked from commit 25f54c960d7a4ceca7bd3e21f87baf48d6cbc2d3)
(cherry picked from commit 21242490e80dadb167a64c1815c08e1d2258fb61)
|
|
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
(cherry picked from commit 85ee4036c68d8ecd2c973d413a17aca81380900b)
(cherry picked from commit 83e6e1a8fc942668f9a01906cb8349fb70a45b3d)
|
|
Since the introduction of by-hash, two differently named
files might have the same real URL. In our case, the files
icons-64x64.tar.gz and icons-128x128.tar.gz of empty tarballs.
APT would try to merge them and end with weird errors because
it completed the first download and enters the second stage for
decompressing and verifying. After that it would queue a new item
to copy the original file to the location, but that copy item would
be in the wrong stage, causing it to use the hashes for the
decompressed item.
Closes: #838441
(cherry picked from commit 7b78e8bef1fc9de22d826db1db9df25f97d3710c)
(cherry picked from commit d2749c845954fc1ea38133b050ee49d6f6544235)
|
|
Just copied over from common-licenses. Seems we missed to do
that earlier.
Gbp-Dch: ignore
(cherry picked from commit 84285d17bab32a0ceafe31a5b2be61cc4f520b42)
(cherry picked from commit e87c862cbd3aee8200f9752a0023ff53312e6dbd)
|
|
This hopefully cuts down on the test time. Optimally, we'd just have
one build job and parallize, but that requires a tty or something,
probably due to GNU parallel?
Gbp-Dch: ignore
(cherry picked from commit 9b7c71f145e51c2d655ef09fca434d02db08331d)
(cherry picked from commit e12dbcbaf486d176762d82f75307b9f5dfa66752)
|
|
This fixes issues with sourceforge where the redirector includes
such a Content-Range in a 302 redirect. Since we do not really know
what file is meant in a redirect, let's just ignore it for all
responses other than 416 and 206.
Maybe we should also get rid of the other errors, and just ignore
the field in those cases as well?
LP: #1657567
(cherry picked from commit 4759a702081297bde66982efed8b2b7fd39ca27c)
(cherry picked from commit b5d0e1be09fd07e693bae8046848059f578d029f)
|
|
rred can fail for a plentory of reasons, but its failure is usually
recoverable (Ign lines) so it shouldn't leak unrequested debug messages
to an observing user.
Closes: #850759
(cherry picked from commit 2984d7aec37e09b473c7b99f43d20622c25dc99d)
(cherry picked from commit d0a345d4a41802e9129b78d70aabd6239a3c651a)
|
|
If apt renames a file to .FAILED it leaves its namespace and is never
touched again – expect since 1.1~exp4 in which "apt clean" will remove
those files. The usefulness of these files rapidly degrades if you don't
keep the update log itself (together with debug output in the best case)
through and on 99% of all system they will be kept around forever just
to collect dust over time and eat up space.
With this commit an update call will remove all FAILED files of previous
runs, so that the FAILED files you have on disk are always only the ones
related to the last apt run stopping apt from hoarding files.
Closes: 846476
(cherry picked from commit 7ca83492e802967f183babf06ab541b1b51f1703)
(cherry picked from commit c8540403ed35fa36e1610fd90aeae8f66c126fdb)
|
|
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)
(cherry picked from commit 2e5726edcac4fc9228c6b16281365c3ade189b8b)
|
|
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)
(cherry picked from commit b234a610a3818af69952bf85c389588a99b4349f)
|
|
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)
(cherry picked from commit e3f9554224c59e1201d00716ef7d7ec046f79f5d)
|
|
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)
(cherry picked from commit 1d017d04c5fdbf71a35e8f154f01bc94305ad798)
|
|
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)
(cherry picked from commit c0dc26456ba74da449eae11c04c3edb3b5f1e35e)
|
|
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)
(cherry picked from commit fec19de5e786564ed8699b38310f7d1a7c348c01)
|
