| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
Closes: #853762
|
|
Closes: #853761
|
|
Oh dear, nobody (or rather no tool) saw that yet...
Gbp-Dch: ignore
|
|
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
|
|
Just copied over from common-licenses. Seems we missed to do
that earlier.
Gbp-Dch: ignore
|
|
Committer-Notes:
Complete files pulled from website as patches tend to be hard to work
with in this context. Last-Translator not updated as wished. po-files
refreshed.
Mailingslist-Thread: <20170106014830.f843cd8b89243a8e57c4062c@gmail.com>
|
|
Committer notes:
po file from #852485, patch applied from msg #2, further adapted as the
patch the --fix-broken string is referring to apt instead of apt-get.
Also changing the dot in "&apt-cache. &apt;" to a semicolon to fix the
syntax error and refreshed to drop the outdated fuzzy comments.
Closes: 852460
|
|
Config options are checked in various paths, so making "useless" memory
allocations wastes time and can also cause problems like #852757.
The unneeded malloc was added in ae73a2944a89e0d2406a2aab4a4c082e1e9da3f9.
(We have no explicit malloc here – its std:string doing this internally)
|
|
|
|
This speeds up testing things as root, which is good, because
we usually test as user.
Gbp-Dch: ignore
|
|
This hides errors in the test suite because it will exit
with 0 here. Instead, just do exit 1 in most traps, and
do just the cleanup in the QUIT hook.
This fixes a regression introduced with the caching of the
GPG home directory in 4ce2f35248123ff2366c8c365ad6a94945578d66.
|
|
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
|
|
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
|
|
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
|
|
We don't want to call these on po-files and such and even then they
contain a bunch of false positives which we should better filter out
or looking at the output is too daunting.
Gbp-Dch: Ignore
|
|
While unlikely, it would be embarrising if we would need a freeze
exception for such a change, so lets do the flip now.
|
|
Normal cows moo every time they feel like it and it might be a "moo",
"moo!" or "moo?". This is completely unacceptable behaviour in our super
cow through as as a superior being it has to show its superiority over
the common cows and the meager easter eggs by being fully reproducible!
The second version of Chris' patch is modified to include an array of
tests for this feature – which doubles as explanation for some of the
moo lines by giving more exact dates – and falling back to current time
if the environment is invalid + passing time around instead of having an
invalid environment be an unrecoverable error (aka: Guru Meditation) as
that is more inline with how apt usually behaves: The wisdom of super cow
should be available to everyone, even to the most misfortune users not
capable of having a valid environment variable.
That makes the code slightly more ugly, so instead of requiring a young
follower to produce a third version a high priest of the cult applied the
finishing touches as he is used to the pain by now – and another round
with the slowpoke high priest would have been a serious threat to the
Debian release schedule which the cow would not approve.
Closes: #848721
Signed-off-by: Super Cow
Thanks: Chris Lamb for initial patch and guru meditation
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
This prevents CI failures from happening in 1.3 and 1.2 and
might actually be more complete.
Gbp-Dch: ignore
|
|
We are basically frozen now, but (a) this wildcard thing
is a bit "explosive" to call this RC and (b) you never know
if you might need to add a new tiny feature and freeze can
be long...
|
|
This is very important stuff, especially for the ParseDepends
thingy as otherwise a new python-apt build would always require
the apt it was built against instead of 1.4~beta3.
|
