| Age | Commit message (Collapse) | Author |
|---|
|
This filters out errors due to timing issues. Early exits if
enough pulses occured.
|
|
This helps writing test cases. Also adapt the test case that
expected 64-bit.
Nothing changes performance wise, the distribution of the hash
values remains intact.
|
|
Allow an optional colon followed by anything at the end.
|
|
This makes the test suite work on 32 bit-long platforms.
Gbp-Dch: ignore
|
|
Use asprintf() so we have easy error detection and do not depend
on PATH_MAX.
Do not add another separator to the generated path, in both cases
the path inside the chroot is guaranteed to have a leading /
already.
Also pass -Wall to gcc.
|
|
This caused test-bug-717891-abolute-uris-for-proxies to fail
Gbp-Dch: ignore
|
|
This breaks a lot of test cases
Gbp-Dch: ignore
|
|
The allocated buffer was one byte too small. Allocate a buffer
of PATH_MAX instead and use snprintf(), as suggested by Martin
Pitt.
|
|
This reduces the chance that the test fails.
Gbp-Dch: ignore
|
|
Instead of checking for [10%, 100%), check for (0%, 100%),
that is everything < 100% and >0%.
Gbp-Dch: ignore
|
|
This should make the test work on non-amd64 systems
Gbp-Dch: ignore
|
|
Ubuntu's autopkgtest server always prints
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
which is somewhat annoying. Work around that by depending on that
perl stuff for the test suite.
Gbp-Dch: ignore
|
|
Trying to clean up directories which do not exist seems rather silly if
you think about it, so let apt think about it and stop it.
Depends a bit on the caller if this is fixing anything for them as they
might try to acquire a lock or doing other clever things as apt does.
Closes: 807477
|
|
Regression of 1e064088bf7b3e29cd36d30760fb3e4143a1a49a (1.1~exp4) which
moved code around and renamed methods heavily ending up calling the
wrong method matching packagenames only instead of calling the full
array. Most commands work with versions, so this managed to fly under
the radar for quite a while.
Closes: 807870
|
|
If we can't work with the hashes we parsed from the Release file we
display now an error message if the Release file includes only weak
hashes instead of downloading the indexes and failing to verify them
with "Hash Sum mismatch" even through the hashes didn't mismatch (they
were just weak).
If for some (unlikely) reason we have got weak hashes only for
individual targets we will show a warning to this effect (again, befor
downloading and failing the index itself).
Closes: 806459
|
|
The "standard" which (debianutils) has no output whatsoever on stderr,
bash and dash which use this implementation therefore haven't either.
In zsh 'which' is a shell built-in – and has no stderr output either, it
does print an error message on stdout…
So, realistically, a redirection isn't needed at all, but it also can't
hurt (<- I have said that before in this context ->) so why not for
consistency with… well, not with "command -v" as that hasn't an error
message either. Lets say for consistency with my mental image of shell,
as I am still a bit puzzled by zsh's which and now could imagine even
more strange things in other shells.
Closes: 807373
|
|
Closes: 807413
|
|
Korean translation update is attached.
I downloaded the original from https://www.debian.org/international/l10n/po/ko.
Originally, "manually" and "automatically" were translated same,
which was confusing.
Mail-Reference: <CAPrzcnL_YynHQkCSE4xH29eW1O0Q6SPhoSf21KOFTu=Vv6-0Nw@mail.gmail.com>
Mail-Archive: https://lists.debian.org/deity/2015/12/msg00108.html
|
|
Reversing the parsing order ensures that we parse weaker hashes (like
SHA1) before we touch newer/stronger hashes (like SHA256) as the weaker
ones will usually be there for a longer time already with data already
present, which we would discard if we start with the strong one first.
The discarding is visible in the debug logs:
File X wasn't in the list for the first parsed hash! (history)
File X wasn't in the list for the first parsed hash! (patches)
which if file X is part of the patch-path means apt will not find a path and
fallback to acquire the whole file instead needlessly.
If file X isn't part of the patch-path that is no problem, so that
effects only the update-call which updates with patches coming from
before and after the addition of a new hash.
|
|
Reported-By: Manuel A. Fernandez Montecelo <mafm@debian.org>
Git-Dch: Ignore
|
|
|
|
Git-Dch: Ignore
|
|
Yay, newer server
Gbp-Dch: ignore
|
|
Fixes a warning reported by gcc.
Gbp-Dch: ignore
|
|
This fixes a warning reported by gcc.
Gbp-Dch: ignore
|
|
With the package names now normalized to lower case, the caches
of affected systems need to be rebuild. Adjust the minor version
to trigger such a rebuild.
Gbp-Dch: ignore
|
|
dpkg does that when reading package files, so we should do
the same. This only deals with parsing names from binary
package paragraphs, it does not look at source package names
and/or the list of binaries in a dsc file.
Closes: #807012
|
|
Gbp-Dch: ignore
|
|
required and important were swapped, leading to wrong
output.
Closes: #807523
Thanks: Manuel A. Fernandez Montecelo for discovering this
|
|
|
|
Gbp-Dch: ignore
|
|
We need to pass 0llu instead of 0 as the init value, otherwise
std::accumulate will calculate with ints.
Reported-by: Raphaël Hertzog
|
|
In e75e5879 'replace "which" with "command -v" for portability' I missed
that command -v isn't actually required to be available in debian, so
for the 5 files we are using it:
Two (abicheck/run_abi_test & test/integration/framework) are called in
environments were I believe sh is at least dash or 'better' as the first
one is "interactive" for apt developers and the later is sourced by ~200
tests in the same directory run by hand and ci-services – for the later
we have pulled some uglier hacks for worser things already, so if there
should actually end up needing something more compatible we will notice
eventually (and the later actually had a command -v call for some time
already and nobody came running).
debian/rules and debian/apt.cron.daily I switched back to which as that
is more or less debian-specific or at least highly non-critical.
That leaves cmdline/apt-key.in with a bunch of calls where I will
implement that functionality in shell as this is relatively short-lived
as it is used to detect wget (for net-update, which Michael wants to
revive and in that process will properly use apt-helper instead of wget)
and to detect gpg vs. gpg2 systems, where the earlier is supposed to go
away in the longrun (or the later, but by replacing the earlier…).
[and this gpg/gpg2 detection is new in sid, so I have some sympathy for
that being a problem now.]
Thanks: Jakub Wilk for pointing out #747320
|
|
After e75e5879 the reason for an implicit dependency on debianutils
(which is essential for debian, but likely not on other systems) was
just two uses of run-parts, which can be replaced with the a lot more
portable find-piped-into-sort duo.
|
|
which is a debian specific tool packaged in debianutils (essential)
while command is a shell builtin defined by POSIX.
Closes: 807144
Thanks: Mingye Wang for the suggestion.
|
|
Include <stdlib.h> to ensure that atoi(3) is defined to improve
general portability and fix a specific build failure on Android.
Closes: 807031
|
|
This should make it more obvious that CHANGEPATH is a placeholder which
apt will replace with a package specific path rather than a string
constant.
Mail-Reference: <87d1upgvaf.fsf@deep-thought.43-1.org>
Mail-Archive: https://lists.debian.org/debian-dak/2015/12/msg00005.html
|
|
'Regression' of 7d19ee92f2368a40e739cb27d22d6d28f37ebf45, just that it
now works more as expected than previously. Of course, build-essentials
are implicitly also build dependencies, so by definition all packages
have build dependencies, but that isn't what this message wants to say
and it isn't what the user expects.
Git-Dch: Ignore
|
|
Otherwise a user is subject to unexpected content-injection depending on
which directory she happens to start apt in. This also cleans up the code
requiring less implementation details in build-dep which is always good.
Technically, this is an ABI break as we override virtual methods, but
that they weren't overridden was a mistake resulting in pure classes,
which shouldn't be pure, so they were unusable – and as they are new in
1.1 nobody is using them yet (and hopefully ever as they are borderline
implementation details).
Closes: 806693
|
|
There is no need to check configured build-essentials for each package,
doing it once at the start ought to be enough.
Git-Dch: Ignore
|
|
Lets do this non-behaviour change before we modify the source for real
as the reflow and moving would otherwise hide all the interesting changes.
Git-Dch: Ignore
|
|
You could think a0bf789783ea283914d059aea0f4d0f77d6bbaaf would be
enough, but it turns out its only half of the puzzle.
Closes: 806765
Suggested-By: Julian Andres Klode <jak@debian.org>
|
|
With the 1.1.3 release we have seen some re-ordering of the
translation template and the translations. It turns out that
this is because sort sorts differently depending on the locale,
so let's force it to always sort in the C locale.
|
|
Git-dch: ignore
|
|
As we ship some tools in apt-utils which depend on our private library
we have to ensure that apt-utils depends on a proper apt version.
An exact version is probably a bit much, but the simplest way out.
|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
Regression of 14341a7ee1ca3dbcdcdbe10ad19b947ce23d972d.
Reported-By: Julian Andres Klode <jak@debian.org>
|
|
Git-Dch: Ignore
|
|
The relevant testcases are in test/integration/test-apt-get-source.
There is a test for #731853 that is supposed to "ensure that apt will
pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
However, this works by pure chance, as simply reversing the order
of the two insertsource lines makes the test fail.
So #731853 isn't really fixed, yet.
Actually, that's related to the problem I reported, as the underlying
issue for both is the same:
In the FindSrc function apt chooses a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or the version of the package is higher than the last best hit.
Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
in this order.
Looking for the version in stable, apt first selects 1.0, because the
release matches the target release, but then subsequently selects 2.0,
because the version is higher.
Looking for the version in unstable, apt first selects 2.0, because the
release matches the target release, but then subsequently selects 1.5,
because the release also matches the target release.
The correct way would be to choose a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or there is no target release
and the version is higher than the last best hit.
Closes: 746412
Mail-Reference: <565A604B.7090104@googlemail.com>
Mail-Archive: https://lists.debian.org/debian-devel/2015/11/msg00470.html
|
