| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
GCC defaults to C++17 currently, but our library users could be on other
(newer/older) standard still e.g. by explicit request, so to avoid
accidentally breaking them the pkg-config-test is adapted to include
all of our public headers as a smoke test for if you can build an
application against our library in a certain C++ standard.
The test script is also adapted to be runnable outside of autopkgtest
like in our CI or manually.
|
| |
|
|
|
|
|
|
| |
gdb-minimal will soon be dropped from the archive; it doesn't offer
any advantages over the gdb binary package. Just depend on gdb
directly.
Signed-off-by: Sergio Durigan Junior <sergiodj@debian.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our goal is for each platform to have one blessed OpenPGP verification
system: Platforms that support sqv get sqv, platforms that don't get
gpgv. To do so we hardcode the architecture list at build time.
At build time we check if /usr/bin/sqv exists, which is the condition
that apt uses to see if it should build with sqv support.
We use a slight hack here to build with sqv on the official Debian
buildds but use gpgv on Ubuntu by abusing the fact that Ubuntu
resolves alternative build dependencies, and gpgv is installed
in the buildd image.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the test case for MD5 and expired signatures, as we can't
create them (can't set signing digest, and can't set signature
expiry).
Tests for them have been added to test-method-gpgv instead.
We override sq in a function with cert-store and key-store
set to none.
This supports both sq 0.40 and sq 1.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Automatically show the output of `show`, `policy`, `list`,
`search`, `showsrc` in a pager.
The pager setup is inspired by git's pager setup. Notably,
the pager is found using APT_PAGER and PAGER variables.
We wait for the pager to be setup somewhat correctly by
using a notify pipe to figure out whether execvp() was
succesful - then the pipe will read EOF as the other end
got closed by CLOEXEC during exec - or not, then the pipe
will contain an errno.
We set up the correct handlers for signals and exit to close
the fds and wait for the pager. Notably inside the signal
handler we cannot flush our streams, only close them, so
there is some duplication.
We call the InitOutputPager() function from inside the
various Do...() functions rather than setting it up
generally in InitOutput(). Doing so allows us to first
render the progress without a pager, and then setup
the pager for the content only which improves user
experience.
When we setup a pager we also take care to disable
standard input, as we should not be prompting users
while a pager is running (the pager will be reading
from the tty directly). We do this by dup2-ing() a
/dev/null over it; if we just close()d the fd, another
open() might reuse the fd number and problems could
occur.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
JSON: Pass options to hooks in hello message
See merge request apt-team/apt!389
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This also ensures that our JSON is actually correct
JSON.
echo may fail now with EPIPE, given that it is multiline, so
wrap it in 2>/dev/null
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
Building the library just so we can build the helpers against it is not
only wasteful but as we are supposed to test the system we can use that
as an additional simple smoke test before the real testing starts.
|
| |
|
|
|
|
|
|
|
| |
autopkgtest says:
Tests may not modify the source tree (and may not have write access to it).
We don't really modify the source of course, but we created our build/
directory in the tree, which seems to work just fine (for now), but lets
be nice.
|
| |
|
|
|
|
| |
Reorganising the control file allows this simple test to run first and
be marked as superficial which makes no practical difference, but is
more correct.
|
| |
|
|
|
|
|
|
| |
If the system tells us that a core dump was created we should try to
display the contained info as that system might not be easily available
when we see the error (like C-I or autopkgtest).
Gbp-Dch: Ignore
|
| |
|
|
|
|
| |
We use a Breaks for the binary package instead of adding
a versioned depends, as Breaks will cause apt solver to upgrade dpkg,
while depends would make apt try to remove apt as first choice.
|
| |
|
|
|
|
| |
Unfortunately for us, apt update with Acquire::Queue-Mode=access
does not always crash on a real system, so run the whole thing
in valgrind.
|
| | |
|
| |
|
|
| |
Closes: #439121
|
| |
|
|
|
|
|
|
| |
This is an optional dependency for the test, but the skipping of the
test is very noisy and checking that an unchanged aptitude isn't
downright exploding with our libapt isn't a bad idea either.
Gbp-Dch: Ignore
|
| |
|
|
|
|
| |
We do want to get our autopkgtests triggered by dpkg uploads
in Ubuntu, but this does not happen because we don't have
an explicit dependency on it. Add one.
|
| |
|
|
|
|
|
|
|
| |
We can't cleanup the environment like e.g. sudo would do as you usually
want the environment to "leak" into these helpers, but some variables
like HOME should really not have still the value of the root user – it
could confuse the helpers (USER) and HOME isn't accessible anyhow.
Closes: 842877
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 problemresolver will set the candidate version for pkg P back
to the current version if it encounters an impossible to satisfy
critical dependency on P. However it did not set the State of
the package back as well which lead to a situation where P is
neither in Keep,Install,Upgrade,Delete state.
Note that this can not be tested via the traditional sh based
framework. I added a python-apt based test for this.
LP: #1550741
[jak@debian.org: Make the test not fail if apt_pkg cannot be
imported]
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Git-Dch: Ignore
|
| |
|
|
|
|
| |
This allows running tests in parallel.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
| |
dpkg and dak know various field names and order them in their output,
while we have yet another order and have to play catch up with them as
we are sitting between chairs here and neither order is ideal for us,
too.
A little testcase is from now on supposed to help ensureing that we do
not derivate to far away from which fields dpkg knows and orders.
|
| |
|
|
|
|
|
| |
By convention, if I run a tool with --help or --version I expect it to
exit successfully with the usage, while if I do call it wrong (like
without any parameters) I expect the usage message shown with a non-zero
exit.
|
| |
|
|
|
|
|
| |
apt can work with both, so it has an or-dependency on them,
but the tests want to play with both of them.
Git-Dch: Ignore
|
| |
|
|
| |
Closes: #759655
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Mostly ensures that we use the build methods and not the system
provided methods in the tests (if we don't want it that way).
Git-Dch: Ignore
|
| |
|
|
| |
Git-Dch: Ignore
|
| | |
|
| |
|
|
|
|
|
|
| |
debian/tests/control: Add missing build-essential, fakeroot, and wget test
dependencies.
debian/tests/run-tests: Pin locale to C to avoid test failures in other
locales.
|
| | |
|
| |
|
|
| |
debian/tests/run-tests
|
| | |
|
| |
|
