| Age | Commit message (Collapse) | Author |
|---|
|
Git-Dch: Ignore
|
|
We setup a "horrible" environment in the apt-key testcase to check all
kinds of things, but we really should be making also at least a simple
apt update call, as that in turn will call apt-key which is how apt-key
is used in the non-testcase world, so that calling should be able to
deal with such environments as well.
Gbp-Dch: Ignore
|
|
Gbp-Dch: Ignore
|
|
Showing messages related to downloading in a mode which can't download
is pretty pointless, so instead of trying harder to make it so that
these messages do not trigger just skip them entirely.
That the message triggered here is an artifact of the implementation in
which the download items are finished, while the code expects them to be
still pending – even the in a previous run completely downloaded files.
Closes: 863635
|
|
Changes nothing on the program front and as the datatypes are
sufficently comparable fixes no bug either, but problems later on if we
ever change the types of those and prevent us using types which are too
large for the values we want to store waste (a tiny bit of) resources.
Gbp-Dch: Ignore
|
|
In complex situations in which we want to unpack a package which has a
conflict/breaks on another package which must be removed due this
conflict apt can decide to perform this remove earlier than initially
planned.
Problem: For three years apt wouldn't remove that package, but the
package which has the conflict… The situation isn't very common and
easily hidden as the package which is removed is unpacked a few actions
later – it becomes visible for packages which protect themselves from
removal through like systemd as the running init resulting in upgrade
failures (#854041).
Note that the package isn't purged, so data shouldn't be lost even if a
user runs into a "hidden" case of it as long as the package sticks to
the policy of removing data only on purge.
Reaching this situation artificially is hard, which is why no testcase
is included, as the situation is highly state dependent. Testing with
"real" systems indicate that slight modifications in the installed
packages set can make the bug not trigger.
Regression-Of: 0eb4af9d3d0c524c7afdc684238aa263ac287449
Thanks: Michael Biebl for helping find this with countless tests
|
|
We want to kill the agent if its home directory exists at that location,
not if it isn't there (leaving an army of processes around).
Gbp-Dch: Ignore
|
|
|
|
0ca66b761 Redefine ambiguous to be much more simple
3d9adfb3f Add more comments
2896e78c2 Render C code to match longest prefix
21e620cf0 fix various typos reported by spellintian
git-subtree-dir: triehash
git-subtree-split: 0ca66b761aa56d42d35c4cc254f455424764895a
|
|
We need to be able to update 1.4.y in different ways than later
apt versions, and thus need to bump the major version so there
is no collision in the minor version at some point.
|
|
|
|
Using dry-run as in the previous commit is not really correct, as
it logs dpkg debugging output too. So, let's assume unattended-upgrade
gets a --download-only option and use that if it is available.
This lets us add the downloading part to unattended-upgrades later
on, without requiring versioned dependencies between the two.
Closes: #863859
|
|
We want to download stuff:
--dry-run Simulation, download but do not install
not debug:
-d, --debug print debug messages
Confusion everywhere!
Closes: #863859
|
|
|
|
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
|
|
|
|
Gbp-Dch: ignore
|
|
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
|
|
|
|
Closes: #861943
|
|
dh_systemd_start inserted postinst commands in all packages,
rather than just the package containing the timers.
This also gets rid of postinst scripts for all other
packages, yay.
Closes: #862001
|
|
|
|
|
|
Closes: #861846
|
|
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
|
|
Use a lock file to make sure only one instance of the
script is running at the same time.
|
|
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.
|
|
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
|
|
|
|
|
|
Regression from commit f5e9be1da89725f9bf1915bdf86fdc4a77edf917
|
|
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
|
|
|
|
Reported-By: Niels Thykier on IRC
Gbp-Dch: ignore
|
|
We are in a dilemma here: The regression of sorts was introduced in 2013
with commit d8a8f9d7f0 allowing pkg modifiers for the upgrade commands.
That calls the autoremover as a sideeffect through and with it comes the
option to remove the garbage packages in these commands (similar to aptitude).
Having the option on the commandline is no problem – people aren't going
to request what they don't want (or so I hope), but the documentation
explicitly states that this option only effects install/remove and
mentions a config knob users might use and expect to not suddenly apply
(especially without documentation) to more commands.
Just reverting the commit is out of question, completely ignoring the
option breaks the workflow of every user who happened to use
--autoremove on the commandline for upgrade and expects that to work
given that it was accepted and worked in a stable release. Changing the
documentation to reflect reality while perhaps the simplest and cleanest
option contradicts freeze and is a surprising change we tend to avoid
like the plague while just leaving it be confuses all users who end up
believing the documentation even if was different in the last 3 years.
So what we do is a tricky compromise: The configuration option if read
from a file does apply only for install/remove as documented, while if
the option is encountered on the commandline it is accepted and applies
to the upgrade which should make 99% of the users happy. The rest has to
wait for us to figure out for buster how to get that documented and
implemented in a saner way.
Closes: #855891
|
|
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
|
|
Closes: #856723
|
|
It says SRCNAME_SRCVER, but the example just gives
the SRCVER part.
Reported-By: Nishanth Aravamudan (nacc) in #ubuntu-devel
|
|
If one is attempting to create a reproducible ISO image we do not want to
include the build system's kernel version, not only due to it breaking
reproducibility, but it could be somewhat misleading and/or the
wrong thing to put in this file anyway.
Closes: #857632
|
|
This gets rid of warnings about .ucf-dist files
Reported-By: Axel Beckert (on IRC)
|
|
|
|
Ubuntu servers / Launchpad rejects uploads where debian/copyright
is a symbolic link, and lintian warns about them. I think that's
crazy, but I'm tired of having to work around this in SRUs, so
let's just solve it by copying the file during clean: This way,
it won't be in git, but it will be generated during the export
by git-buildpackage.
|
|
We are including sys/statvfs.h, not statvfs.h, so make sure our
dummy in the correct spot.
|
|
-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>
|
|
|
|
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
|
|
$ uname -m
i686
$ date -d '0-12-25'
date: invalid date '0-12-25'
Test-Regression-In: 25a14d4ccfceb2698edce01092bc6a1dbe9fb217
|
|
Added in dpkg commit 6c8203440bf443d3031ee2ab8485b16c1b6da3b6
|
|
|
|
Gbp-Dch: ignore
|
