IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
OSTree's code for testing predates the `glib-tap.mk` making its
way into GLib. Let's switch to it, as it provides a number
of advantages.
By far the biggest advantage is that `make check` can start to run
most of the tests *in addition* to having them work installed.
This commit keeps the installed tests working, but `make check` turns
out to be really broken because...our TAP usage has bitrotted to say
the least. Fix that all up.
Do some hacks so that the tests work uninstalled as well - in
particular, `glib-tap.mk` and the bits encoded into
`g_test_build_filename()` assume *recursive* Automake (blah). Work
around that by creating a symlink when installed to loop back.
I noticed in the static deltas tests, there were some tests that
should have been under `-o pipefail` to ensure we properly propagate
errors.
There were a few places where we were referencing undefined variables.
Overall, this is clearly a good idea IMO.
Eliminates the need for constantly passing --sysroot=sysroot, but
also makes ostree place remote configs for sysroot/ostree/repo in
sysroot/etc/ostree/remotes.d where they should have been all along.
If a system administrator happens to type `ostree admin upgrade`
multiple times, currently that will lead to a potentially corrupted
system.
I originally attempted to do locking *internally* in `libostree`, but
that didn't work out because currently a number of the commands
perform multi-step operations that all need to be serialized. All of
the current code in `ostree admin deploy` is an example.
Therefore, allow callers to perform locking, as most of the higher
level logic is presently implemented there.
At some point, we can revisit having internal locking, but it will be
difficult. A more likely approach would be similar to Java's approach
with concurrency on iterators - a "fail fast" method.
