We build them in "make" and clean them in "make clean", so there
doesn't seem much point in shipping them pre-generated in the tarball.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #1013
Approved by: cgwalters
They are built at "make" time and cleaned up by "make clean", so there
is no need to distribute them.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #665
Approved by: cgwalters
Debian's Lintian packaging consistency check complains that it isn't
executable but has a #! line. In fact it's reasonable to run this
script directly, so make it executable, and put it in a _scripts
variable so it will be installed executable.
Closes: #652
Approved by: cgwalters
They are installed non-executable, which makes Debian's Lintian
packaging consistency check complain that #! is only useful
in executable scripts. But in fact they are not useful to execute
directly (they rely on setup being done in the script that sources
them), so just chmod them -x.
Closes: #652
Approved by: cgwalters
In its initial commit, Alexander Larsson wrote
This works standalone, but unfortunately it breaks in
gnome-desktop-testing-runner as /tmp doesn't support
xattrs, so it is not installed atm.
but we now (a) use /var/tmp, and (b) explicitly skip the test if
xattr support is unavailable. So it should be OK to run now.
Closes: #652
Approved by: cgwalters
While using the Automake parallel test harness, if a test hangs for
long enough for an external watchdog to kill the entire build process
(as happens in Debian sbuild after 150 minutes with no activity on
stdout/stderr), the logs will not be shown. If we make an individual
test time out sooner, logs are more likely to be shown.
We use SIGABRT so that the process(es) under test will dump core,
allowing the point at which ostree is blocking to be analyzed.
After 1 minute, if any have not died, we kill them again with SIGKILL.
To support slow platforms and slow debugging tools, if
TEST_TIMEOUT_FACTOR is set, multiply the 10 minute timeout by that.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #607
Approved by: cgwalters
If we're using LD_LIBRARY_PATH for some locally-built library, we want
to search those after OSTree's own libraries.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #606
Approved by: cgwalters
Found by valgrind memcheck. g_variant_new_from_bytes takes a ref to the
bytes, so we need to release the original ref.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #556
Approved by: cgwalters
ostree_repo_pull_with_options() and ostree_repo_remote_change() don't
sink floating GVariant arguments, and doing so now would be an
ABI change; so don't rely on them to do so.
Leak found with valgrind memcheck.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #556
Approved by: cgwalters
g_variant_get_strv is (transfer container): the caller is expected to
free the array, but not the individual strings.
Leak found with valgrind memcheck.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #556
Approved by: cgwalters
It appears the result of assign_bootserials() is never actually used,
but I haven't changed it to return void right now.
Leak found with valgrind memcheck.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #556
Approved by: cgwalters
The cleanup attribute doesn't clean up before calling a noreturn
function like exit(). Explicitly clean up the pointer variables
(but don't assume that a simple g_object_unref() would be OK either,
in case the behaviour of the cleanup attribute changes).
This isn't a real leak since we're about to exit anyway, but if we
don't fix it then valgrind memcheck will make the tests fail.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #559
Approved by: cgwalters
We are relying on the GPtrArray to free its contents, but we only
give it a free-function on one code path.
Found by valgrind memcheck.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #559
Approved by: cgwalters
If !existed, then we add arg to kargs->order, where it will be freed
by that array's free-function. However, if the kernel argument did
already exist, we have to either free arg ourselves (and make sure
the old key is what appears in the hash table), or do a linear search
on kargs->order to replace the old key with the new.
Leak found by valgrind memcheck.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #559
Approved by: cgwalters
This fixes a "make dist" tarball produced on a minimal system and run on a
non-minimal system. Automake knows that files that are only conditionally
included in dist_whatever_WHATEVER are to be distributed, but it does not
do the same for files that are only conditionally included in EXTRA_DIST,
which is how glib-tap.mk's various variables like dist_test_scripts work.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #557
Approved by: cgwalters
Otherwise several tests fail, for example in this build done in a French
locale by Debian's reproducible builds initiative, to check whether
the resulting binaries are identical to what was produced in an
English locale:
<https://tests.reproducible-builds.org/debian/logs/unstable/amd64/ostree_2016.11-1.build2.log.gz>
(test-basic)
# error: Cannot write to repository: Permission non accordée
...
File 'error-message' doesn't match regexp 'Permission denied'
(test-help)
# Utilisation :
# ostree [OPTION...] COMMAND
...
File 'out' doesn't match regexp '[Uu]sage'
(test-pull-metalink)
# error: Erreur à la ligne 1, caractère 1 : Le document doit commencer avec un élément (par ex. <book>)
...
File 'err.txt' doesn't match regexp 'Document must begin with an element'
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #558
Approved by: cgwalters
.travis.yml is obviously still Travis-specific, but tests/ci-* are
designed to be shareable with other CI environments if there is interest
in doing so.
At the moment I'm only testing on Debian and Ubuntu. In principle we
could try a non-Debian-derived Docker container such as Fedora or CentOS
inside travis-ci's Ubuntu environment, similar to what I'm doing
for Debian, but I don't know the correct setup commands to use there.
Closes: #438
Approved by: cgwalters
ostree's naming convention for whiteouts is similar to what is
done in aufs, which means we can't compose the trees to test this
feature under Docker with the aufs storage driver, as used on
travis-ci.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #437
Approved by: cgwalters
libtoolize creates a version of libtool for the right architecture
in $(top_builddir), which is guaranteed to be present, and is
guaranteed to match what we are compiling (even during
cross-compilation).
Packaging systems sometimes separate /usr/bin/libtool, which is
specific to one architecture, from the libtool development files
such as libtoolize and ltmain.sh, which are architecture-independent.
For example, in Debian, libtool_*_all.deb contains the files necessary
to libtoolize a package and is depended on by the dh-autoreconf package,
but libtool-bin_*_amd64.deb (or whatever architecture) contains
/usr/bin/libtool and is not normally necessary to depend on.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #367
Approved by: cgwalters
The filename of the real ostree executable could be either .libs/ostree
or .libs/lt-ostree.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #337
Approved by: cgwalters
Otherwise, during "make distcheck" it will be read-only (because it
is a copy of the read-only ${srcdir} with permissions preserved), and
deletion will fail during cleanup.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #337
Approved by: cgwalters
This avoids hard-coding the autogen-time ${srcdir} into our build
system, and might fix "make distcheck".
We don't need to specify ${srcdir} explicitly in the various variables,
because Automake always uses make's VPATH feature to look in both
${builddir} and ${srcdir} at build time.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #337
Approved by: cgwalters
It uses dlsym(). There's no point in being extra-portable here
because OSTree only targets Linux anyway.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #336
Approved by: cgwalters
As with the C tests in commit 08580118, this makes sure the test
fails as soon as something goes wrong.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #335
Approved by: giuseppe
I've seen an intermittent test failure in an autobuilder (sbuild)
environment where logs from failed builds cannot be retrieved,
but I can no longer reproduce it. Put the contents of the offending
file in the test's failing output so that if the failure comes back,
it can be debugged.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #264
Approved by: cgwalters
test-sysroot.js runs libtestExec() twice, one of which is after
creating non-hidden directories in $(pwd), so this check needs to be
skipped the second time.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #234
Approved by: cgwalters
If we touch test-xattrs before sourcing libtest.sh, we get:
test tmpdir=/tmp/test-tmp-ostree_test-xattrs.sh.test-HSEXEY is not
empty; run this test via `make check TESTS=`, not directly
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #234
Approved by: cgwalters
This fixes the bug that in installed-tests that run testlib.sh under
"bash -c" (i.e. the C and JS tests), $(dirname $0) is "." and we can't do
the LD_PRELOAD correctly:
ERROR: ld.so: object './libreaddir-rand.so' from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
Similarly, those tests can't copy gpghome correctly.
This also removes the confusing situation that SRCDIR in libtest.sh
(which is ${top_srcdir}/tests) does not mean the same thing as SRCDIR
in test-abi.sh (which is just ${top_srcdir}).
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #234
Approved by: cgwalters
moreutils parallel isn't compatible with the command-line syntax
used here. Because it doesn't implement GNU-style --help and exits 1
when that option is given, this test was correctly skipped when
using moreutils parallel, but only by mistake.
moreutils parallel might conceivably gain --help and --version in
future, but hopefully nothing incompatible with GNU parallel is going
to gain a --gnu option.
Also use the --gnu option to force the new command-line semantics;
some versions optionally supported an incompatible command-line syntax
taken from moreutils parallel.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #232
Approved by: cgwalters
If installed-tests are disabled, it would normally be a static
(convenience) library, which isn't something we can LD_PRELOAD.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #232
Approved by: cgwalters
The "function foo()" syntax is bash-specific, and Colin indicated in
PR #226 that he prefers to require bash rather than trying to support
every POSIX shell.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #232
Approved by: cgwalters
Previously, the build-time tests would only pass if the g-i bindings to
OSTree were already installed, with a reasonably similar version.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #232
Approved by: cgwalters
The script created ./.testtmp but looked for ./.test, which isn't
going to work.
This means the various "ostree trivial-httpd --autoexit" processes
actually exit, because their web roots are cleaned up now.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #232
Approved by: cgwalters
Some autobuilder environments place the entire build chroot on tmpfs, so
even /var/tmp might not have this.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #232
Approved by: cgwalters
On Debian and its derivatives, /bin/sh is a lightweight POSIX shell
(currently dash) which does not support the bash {foo,bar} syntax.
Signed-off-by: Simon McVittie <smcv@debian.org>
Closes: #226
Approved by: cgwalters
The test tries to get a filesystem that supports xattrs by writing
to /var/tmp, but in some automated build environments the entire
build chroot is on a tmpfs.
Signed-off-by: Simon McVittie <smcv@debian.org>
Simon McVittie