| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This release is made for Niels Thykier and apt-file.
|
|
|
|
|
|
|
|
Allow an optional colon followed by anything at the end.
|
|
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
|
|
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
|
|
|
|
|
|
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
|
|
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.
|
|
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>
|
|
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.
|
|
Passing function pointers around while working on this was very icky,
but if weak symbols are too much to ask for…
Reverts "do not use "-Wl,-Bsymbolic-functions" during the build to avoid
breakage" aka a5fc9be36211a290a7abc3ca2a8bf98943bc1f57.
|
|
|
|
|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
|
|
Git-Dch: Ignore
|
|
Git-Dch: ignore
|
|
|
|
Unfortunately it seems like git-buildpackage does not have a
pre-export hook so the hook is disabled for now.
Git-Dch: ignore
|
|
|
|
The manpages were fixed by Justin B Rye, lets deal with the rest now.
Git-Dch: Ignore
|
|
|
|
Reported-By: codespell
Git-Dch: Ignore
|
|
If the config.{sub,guess} files we linked in were newer than our
configure script we ended up recreating configure and then rerun it
without all the configuration options which were (potentially) present
for a previous run.
We avoid this by changing to the same ruleset as in the debian/rules
file which compares the config.* files against a stamp file rather than
the configure script itself as its the configuration itself which
depends on all scripts, not configure on the config scripts.
While at it, we also drop the 'make -s dirs' call as we don't need to do
it explicitly here as proper dependencies will take care of it.
Thanks: Helmut Grohne for the detailed bugreport.
Closes: 804923
|
|
|
|
|
|
Commit 653ef26c70dc9c0e2cbfdd4e79117876bb63e87d broke the camels back in
sofar that everything works in terms of our internal use of copy:/, but
external use is completely destroyed. This is kinda the reverse of what
happened in "parallel" in the sid branch, where external use was mostly
fine, internal and external exploded on the GzipIndexes option.
We fix this now by rewriting our internal use by letting copy:/ only do
what the name suggests it does: Copy files and not uncompress them
on-the-fly. Then we teach copy and the uncompressors how to deal with
/dev/null and use it as destination file in case we don't want to store
the uncompressed files on disk.
Closes: 799158
|
|
Gbp-Dch: ignore
|
|
Gbp-Dch: ignore
|
|
|
|
|
|
This allows running tests in parallel.
Git-Dch: Ignore
|
|
Not all tests work yet, most notable the cdrom tests, but those require
changes in libapt itself to have a proper fix and what we have fixed so
far is good enough progress for now.
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
Figuring out after the fact what went wrong in the kernel hook is kinda
hart, also as the bugreports are usually very lacking on the details
front. Collecting the internal variables in the debug output we attach
to the generated file might help shine some light on the matter.
It's at least not going to hurt…
|
|
This is basically a rewrite of the script with the general idea of
finding the Debian version of the installed kernels – as multiple
flavours will have the same Debian version – select the two newest of
them and translate them back to versions found in package names.
This way we avoid e.g. kernel and kernel-rt to use up the protected
slots even through they are basically the same kernel (just a different
flavour) so it is likely that if kernel doesn't work for some reason,
kernel-rt will not either.
This also deals with foreign kernel packages, kernels on hold and partly
installed kernels (in case multiple kernels are installed in the same
apt run) in a hopefully sensible way.
Closes: 787827
|
|
|
|
Closes: #783337
Thanks: Christian for all the l10n, code & social contributions!
|
|
|
|
It was not nice to use 2 * number of cores in all cases.
Thanks: Jakub Wilk for the suggestion
|
|
Reported-By: codespell
|
|
Git-Dch: Ignore
|
|
For many usecases like the acquire system libapt-pkg actually needs
tools and config found in the apt package. apt tends to be installed
everywhere libapt-pkg appears usually anyhow, but just in case to nudge
users (and tools) in the right direction.
Note that this isn't and shouldn't be a hard depends as there are
usecases working perfectly without 'apt' and as this is such an esoteric
problem incurring the costs arising from a Depends-Breaks-loop isn't
deemd as worth it.
|
