| Age | Commit message (Collapse) | Author |
|---|
|
debhelper 10 is much nicer with the installation part from
a dirty tree, so you can just fix some stuff breaking the
install step and then continue building with debuild -b -nc
until you have fixed all your stuff.
It also has some other advantages, of course, like some
bug fixes in shell escaping for maintscript, or systemd
helper changes.
|
|
We need to support partial upgrades anyhow, so we have to deal with the
different versions and your tests try to ensure that we do, so we
shouldn't make any explicit higher requirements.
|
|
This also fixes Debian/apt#20, but is slightly more complete. I
think /git also looks better than /cgit, so let's switch the Vcs
entry in control over too.
|
|
The SOURCE_DIR property is used for the translation building and
was introduced in cmake 3.4
|
|
|
|
This new packaging is much easier to read, although the duplication
in the install files is a bit annoying. We should probably also get
rid of the movefiles for solvers, planners, and https method; but
then we have to keep track of which methods exist in the apt package.
Another disadvantage is that building only the documentation packages
also requires building the code, as there's no way to turn off code
building in the project.
|
|
This simplifies the design a bit, as we do not need to read the
major ABI version number from some file / command.
Gbp-Dch: ignore
|
|
|
|
debian/apt.apt-compat.cron.daily is using on_ac_power utility
|
|
|
|
Reported-By: lintian: vcs-field-uses-insecure-uri
Git-Dch: Ignore
|
|
We don't have no menu file.
|
|
apt doesn't need gnupg in its main execution paths to function,
especially the Release file verification is done with gpgv only.
It is only used by apt-key for advanced key management functionality
most user will never use nor need.
The intend is to demote it eventually to Suggests, but we opt here for a
staged downgrade as there are still third-party repositories out there
which require apt-key functionality without depending on gnupg (or apt
for that matter).
|
|
The rational is that we need to spread the load on the mirrors
that apt update and unattended-upgrades cause. To do so, we
leverage the RandomizeDelay feature of systemd. The other advantage
is that the timer is not run at a fixed daily.daily time but
instead every 24h. This also fixes the problem that the randomized
deplay in the current apt.cron.daily causes other cron jobs to
be deplayed.
A compatibility cron job is also provided for systems that do not
use systemd.
Note that the time is fired two times a day, but the logic inside
of apt.systemd.daily will ensure (via stamp files) that the
servers are hit at most every 24h. Firing two times a day helps
with the worst case update time and it also helps with systems
that are not always on.
LP: #246381, #727685
Closes: #600262, #709675, #663290
|
|
We do not follow the recommendation with regards to placement
of documentation in apt-doc, as we install in apt-doc, but
it's only a recommendation and I don't want think we should
move them.
|
|
It's not cross-satisfiable.
Reported-by: Helmut Grohne
|
|
We need r126 of lz4, as this introduces the lz4frame.h
header.
|
|
This is not really needed anymore, as those are in stable,
but as they are versioned already, let's just do it.
Gbp-Dch: ignore
|
|
There's no point in breaking all older apt-file versions just
because one old experimental upload was broken.
|
|
Gbp-Dch: ignore
|
|
This ensures that a compatible version of appstream is
installed, that is, one that disables lz4 compression
for its data.
|
|
Implement native support for LZ4 compression, using the official
lz4 library.
|
|
I'd like to avoid pulling libgtest-dev into the bootstrap set.
Fortunately, libgtest-dev is only used for testing apt and apt
correctly implements DEB_BUILD_OPTIONS=nocheck now. So this
bug is about getting rid of the Build-Depends.
Simply removing it (by adding a build profile) is not sufficient
however as configure fails hard, so an additional bit is necessary
to cover for that.
Closes: #809726
|
|
The apt bash-completion support was submited to the bash-completion
package as a patch in May 2014. It is still not included to this
date and because it is an important feature for many users it is
now part of apt until the bash-completion package is mantained
more actively again.
Note that the "Relaces" line is only required for Ubuntu it will
have no effect on Debian.
Closes: #747094
|
|
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>
|
|
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.
|
|
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
|
|
Git-Dch: Ignore
|
|
Closes: #783337
Thanks: Christian for all the l10n, code & social contributions!
|
|
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.
|
|
This makes tests work again!
Gbp-Dch: ignore
|
|
Thanks: Lintian
|
|
Thanks: Lintian
|
|
Thanks: Lintian
|
|
|
|
|
|
The library(s) make an API break anyhow, so lets ensure we use gcc5 for
this break and enable c++11 as standard as gcc6 will use it as default
and should provide some API parts for c++11 – beside that it can't hurt
to use c++11 itself. We just have to keep our headers c++03 compatible
to not enforce a standrd bump in our reverse dependencies.
|
|
If all keyrings are simple keyrings we can merge the keyrings with cat
rather than doing a detour over gpg --export | --import (see #790665),
which means 'apt-key verify' can do without gpg and just use gpgv as
before the merging change.
We declare this gpgv usage explicit now in the dependencies. This isn't
a new dependency as gnupg as well as debian-archive-keyring depend on
and we used it before unconditionally, just that we didn't declare it.
The handling of the merged keyring needs to be slightly different as our
merged keyring can end up containing the same key multiple times, but at
least currently gpg does remove only the first occurrence with
--delete-keys, so we move the handling to a if one is gone, all are gone
rather than an (implicit) quid pro quo or even no effect.
Thanks: Daniel Kahn Gillmor for the suggestion
|
|
The rational is that https downloads fail with cryptic error messages
if the certificates are missing.
|
|
|
|
|
|
|
|
Closes: #763004
Thanks: Russ Allbery
|
|
gnupg/gnupg2 can do verify just fine of course, so we don't need to use
gpgv here, but it is what we always used in the past, so there might be
scripts expecting a certain output and more importantly the output of
apt-cdrom contains messages from gpg and even with all the settings we
activate to prevent it, it still shows (in some versions) a quiet scary:
"gpg: WARNING: Using untrusted key!" message. Keeping the use of gpgv is
the simplest way to prevent it.
We are increasing also the "Breaks: apt" version from libapt as it
requires a newer apt-key than might be installed in partial upgrades.
|
|
If both are available APT will still prefer gpg over gpg2 as it is a bit
more lightweight, but it shouldn't be a problem to use one or the other
(at least at the moment, who knows what will happen in the future).
|
|
|
|
Conflicts:
apt-pkg/deb/deblistparser.cc
doc/po/apt-doc.pot
doc/po/de.po
doc/po/es.po
doc/po/fr.po
doc/po/it.po
doc/po/ja.po
doc/po/pl.po
doc/po/pt.po
doc/po/pt_BR.po
po/da.po
po/mr.po
po/vi.po
|
|
|
|
|
|
Conflicts:
apt-pkg/cachefilter.h
apt-pkg/contrib/fileutl.cc
apt-pkg/contrib/netrc.h
apt-pkg/deb/debsrcrecords.cc
apt-pkg/init.h
apt-pkg/pkgcache.cc
debian/apt.install.in
debian/changelog
|
