| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This will avoid people from thinking that they have to do nothing
when they change the set of files.
Gbp-Dch: ignore
|
|
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
|
|
This is somewhat more portable than just hardcoding perl or in the
triehash case /usr/bin/perl in the shebang.
Thanks: Guillem Jover for the hint
Gbp-Dch: ignore
|
|
Our implementation of wildcards was rudimentary. It worked for some
common ones, but it was also broken: For example, armel matched any-armel,
but should match any-arm.
With this commit, we load the correct tables from dpkg. Supported are
both triplets and quadruplet tables (the latter introduced in dpkg 1.18.11).
There are some odd things we have to deal with in the cache filter for
historical and API reasons:
* The character "*" must be accepted as an alternative to any - in fact
it may appear anywhere in the wildcard as we also allow fnmatch() style
wildcard matching on the commandline.
* The code might get passed an arch with a minus at the end, for example
the cmdline "install apt:any-arm-" will first try to check if any-arm-
is a valid architecture. We deal with this by rejecting any wildcard
ending in a minus.
* Triplets are actually implemented by extending them to faux quadruplets
- by prepending a "base" component for the architecture tuple, and "any"
if there is a wildcard component.
Once we have constructed a wildcard, it is transformed into an fnmatch()
expression for historical reasons. In the future, we should really get a
tuple class and implement matching in a better, more explicit way.
This does for now though - it passes all the test cases and accepts all
things it should accept.
Closes: #748936
Thanks: James Clarke <jrtc27@jrtc27.com> for the initial patch
|
|
Thanks: James Clarke <jrtc27@jrtc27.com> for the implementation
Gbp-Dch: ignore
|
|
|
|
Run the test for kfreebsd-i386 and amd64 and pass "amd64" as
an additional argument to the function. This tests that the
argument is used and thus ParseDepends returns the amd64
results even on a different architecture like i386.
|
|
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)
|
|
The idea is simple: Each¹ Find*( call starts with a call check if the
given option (with the requested type) exists in the whitelist. The
whitelist is specified via our configure-index file so that we have
a better chance at keeping it current. the whitelist is loaded via a
special (undocumented for now) configuration stanza and if none is
loaded the empty whitelist will make it so that no warnings are shown.
Much needs to be done still, but that is as good a time as any to take a
snapshot of the current state and release it into the wild given that it
found some bugs already and has no practical effect on users.
¹ not all in this iteration, but many
|
|
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"
|
|
On Travis and co the default gpg implementation is gpg1 which for some
reason fails if a secret key which was already imported is imported
again. We would prefer it to be a NOP like gpg2 handles it so we crudely
check the error message. apt-key usually doesn't deal with secret keys –
it only learned to do it for manual testing and the integration
framework usage, so no public interface is effected.
Triggered-By: 4ce2f35248123ff2366c8c365ad6a94945578d66
Gbp-Dch: Ignore
|
|
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
|
|
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
|
