| 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.
|
|
This gets rid of the special casing of etc/apt, various
example file installations handled by the upstream build
system, and of course the directory creation for all dirs
created by the upstream build system.
|
|
Hardcoding gpgv1 and gnupg1 breaks Ubuntu, because on Ubuntu,
these packages do not exist yet. Instead allow gnupg (<< 2)
for gnupg1 and gnupg2 for gnupg (>= 2), so we cover all
potential combinations.
|
|
On Ubuntu, cmake installs are vendor-specific apt.conf.d
snippet, causing the build to fail.
|
|
|
|
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.
|
|
Having the completions installed only by the packaging was
an oversight.
Gbp-Dch: ignore
|
|
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.
|
|
ctest as run by cmake by default does not show the output of the tests
even if the tests failed. In terms of our tests it could be handy to set
it always, but unfortunately it seems like cmake doesn't allow it if the
internet is to be believed, so lets enable it at least while building
packages and on travis.
Gbp-Dch: Ignore
|
|
This is much better than removing them in debian/rules.
Gbp-Dch: ignore
|
|
This was only needed temporarily
Thanks: Axel Beckert for reporting
|
|
This commit looks heavy. Most of that comes from the fact that the
ordering of files in the translations changed with the switch to
CMake. I could have gone the extra mile to figure out the original
ordering and replicate it, but I have chosen to re-order everything
by file and line number, as that's easier.
|
|
This can now build all documentation. It should also be fairly
reusable for other projects, as long as they follow the same
naming scheme for the po4a output files and set the PACKAGE_*
variables used here.
We could have done all translations in a single call to po4a
like the makefile based buildsystem does. While that would
have made the output slightly nicer, this solution offers a
huge performance gain because it can translate the documents
in parallel, which also means that the xsltproc stage does not
have to wait for all translations to be done first.
You might think that the add_custom_command() should list the
actual output files as BYPRODUCTS. This is not true however:
Because the files are not always generated, Ninja will think
missing byproducts mean that the target is out of date - which
is not what we want.
Finally, also add the missing doxygen support. Note that the
packaging script cleans up some md5 and map files created by
doxygen, otherwise it is fairly boring.
|
|
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
|
|
|
|
Yes, we might still add new features to 1.3 or break some more
stuff. Stay tuned!
|
|
Escape "+" in kernel package names when generating APT::NeverAutoRemove
list so it is not treated as a regular expression meta-character.
[Changed by David Kalnischkies: let test actually test the change]
Closes: #830159
|
|
|
|
Julian noticed on IRC that I fall victim to a lovely false friend by
calling referring to a 'planer' all the time even through these are
machines to e.g. remove splinters from woodwork ("make stuff plane").
The term I meant is written in german in this way (= with a single n)
but in english there are two, aka: 'planner'.
As that is unreleased code switching all instances without any
transitional provisions. Also the reason why its skipped in changelog.
Thanks: Julian Andres Klode
Gbp-Dch: Ignore
|
|
Testing the current implementation can benefit from being able to be
feed an EIPP request and produce a fully compliant response. It is also
a great test for EIPP in general.
|
|
The very first step in introducing the "external installation planer
protocol" (short: EIPP) as part of my GSoC2016 project.
The description reads: APT-based tools like apt-get, aptitude, synaptic,
… work with the user to figure out how their system should look like
after they are done installing/removing packages and their dependencies.
The actual installation/removal of packages is done by dpkg with the
constrain that dependencies must be fulfilled at any point in time (e.g.
to run maintainer scripts).
Historically APT has a super micro-management approach to this task
which hasn't aged that well over the years mostly ignoring changes in
dpkg and growing into an unmaintainable mess hardly anyone can debug and
everyone fears to touch – especially as more and more requirements are
tacked onto it like handling cycles and triggers, dealing with
"important" packages first, package sources on removable media, touch
minimal groups to be able to interrupt the process if needed (e.g.
unattended-upgrades) which not only sky-rocket complexity but also can
be mutually exclusive as you e.g. can't have minimal groups and minimal
trigger executions at the same time.
|
|
|
|
debian/apt.apt-compat.cron.daily is using on_ac_power utility
|
|
.. instead of hardcoding the functionnality in the apt.systemd.daily
script.
Also make the compatibility cron job provide the same functionnality
for systems that do not use systemd.
Closes: #827930
|
|
Quite a huge churn of new strings.
|
|
|
|
|
|
EDSP had a WriteSolution method to write out the entire solution based
on the inspection of a given pkgDepCache, but that is rather inflexible
both for EDSP itself and for other EDSP like-protocols. It seems better
to use a smaller scope in printing just a single stanza based on a given
version as there is more reuse potential.
|
|
This reduces the number of symbols by about 10%. Unfortunately,
it does not seem to cover all the weird std::vector and friend
template expansions.
ABI should not brake due to that change: It was never specified
before whether an inline symbol was exported or not; so no library
could rely on its presence. Instead, the symbols were exported in
each library/program needing it and and then merged into a common
one by the dynamic linker.
Also update the symbol files to account for the removed symbols.
|
|
David added some more when he changed the output format for
numbers.
Gbp-Dch: ignore
|
|
Git-Dch: Ignore
|
|
The debian/rules file tries to guess in which directory it is supposed
to be building, but that guess is always ./build – if it wasn't it
would fail later as not all rules take alternatives into acount.
So, as this is clearly not used lets remove this complexity instead of
fixing it up.
Git-Dch: Ignore
|
|
The embedding is done completely automatic by doxygen and documented to
be that way for reasons: /usr/share/doc/doxygen/README.jquery
As we can't do anything about it, it is pointless to keep the warning.
|
|
Reported-By: lintian: vcs-field-uses-insecure-uri
Git-Dch: Ignore
|
|
Reported-By: lintian: spelling-error-in-doc-base-abstract-field
Git-Dch: Ignore
|
|
We don't have no menu file.
|
|
|
|
The rest is also on the same line, so let's go consistent here
now that we have a bug report about it.
LP: #1581985
|
|
|
|
A frontend like apt-file is only interested in a specific set of files
and selects those easily via "Created-By". If it supports two locations
for those files through it would need to select both and a user would
need to know that implementation detail for sources.list configuration.
The "Identifier" field is hence introduced which by default has the same
value as "Created-By", but can be freely configured – especially it can
be used to give two indexes the same identifier.
|
|
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).
|
|
Closes: 820861
|
|
|
