Simon McVittie [Mon, 30 Jul 2018 15:51:01 +0000 (16:51 +0100)]
Skip test-pull-repeated during CI
This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.
It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.
Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch
Jonathan Lebon [Wed, 25 Sep 2019 13:37:48 +0000 (09:37 -0400)]
Release 2019.4
Tiny release. Just want to get out the important bugfixes instead of
backporting patches (notably the gpg-agent stuff and
`ostree-finalize-staged.service` ordering).
Jonathan Lebon [Tue, 24 Sep 2019 21:08:54 +0000 (17:08 -0400)]
boot/finalize-staged: Run after systemd-journal-flush.service
In Fedora 31, `systemd-journal-flush.service` uses a new
`--smart-relinquish-var` switch which fixes the
`umount: /var: target is busy` bug by telling journald to stop logging
to `/var` and back to `/run` again during shutdown.
This interacted with `ostree-finalize-staged.service` in a tricky way:
since we weren't strongly ordered against it, when we happened to
finalize after `/var` is relinquished, we never persisted the output
from that service to disk. This then threw off `rpm-ostree status` when
trying to find the completion message to know that finalization went
well.
Just fix this by adding an explicit `After=` on that unit. That way we
shut down *before* `systemd-journal-flush.service` (the `/var`
relinquish bit happens in its `ExecStop=`).
Simon McVittie [Mon, 30 Jul 2018 15:51:01 +0000 (16:51 +0100)]
Skip test-pull-repeated during CI
This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.
It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.
Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch
Benjamin Gilbert [Fri, 13 Sep 2019 06:37:01 +0000 (02:37 -0400)]
prepare-root: remember to remove /sysroot.tmp
Without this, rerunning ostree-prepare-root will fail in mkdir()
because /sysroot.tmp already exists, which complicates debugging from
the dracut emergency shell.
Jason Wessel [Wed, 10 Jul 2019 18:42:27 +0000 (14:42 -0400)]
fsck: Add test for --delete corruption, fix repair, and partial commit checks
The ostree fsck test is aimed to check that it will still fail an fsck
if the repository has been repaired by fsck. It also checks that a
pull operation corrects the error and ostree fsck will exit with zero.
Jason Wessel [Wed, 10 Jul 2019 18:47:27 +0000 (14:47 -0400)]
fsck: Implement a partial commit reason bitmask
After the corruption has been fixed with "ostree fsck -a --delete", a
second run of the "ostree fsck" command will print X partial commits
not verified and exit with a zero.
The zero exit code makes it hard to detect if a repair operation needs
to be run. When ever fsck creates a partial commit it should add a
reason for the partial commit to the state file found in
state/<hash>.commitpartial. This will allow a future execution of the
fsck to still return an error indicating that the repository is still
in the damaged state, awaiting repair.
Additional reason codes could be added in the future for why a partial
commit exists.
Text from: https://github.com/ostreedev/ostree/pull/1880
====
cgwalters commented:
To restate, the core issue is that it's valid to have partial commits
for reasons other than fsck pruned bad objects, and libostree doesn't
have a way to distinguish.
Another option perhaps is to write e.g. fsck-partial into the
statefile state/<hash>.commitpartial which would mean "partial, and
expected to exist but was pruned by fsck" and fsck would continue to
error out until the commit was re-pulled. Right now the partial stamp
file is empty, so it'd be fully compatible to write a rationale into
it.
====
Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Closes: #1910
Approved by: cgwalters
Dan Nicholson [Fri, 6 Sep 2019 22:52:15 +0000 (16:52 -0600)]
lib/gpg: Use g_spawn_sync to kill gpg-agent
For reasons I don't understand, GSubprocess doesn't play nice with KDE's
plasmashell. I assume this has something to do with the GSubprocess
using the glib worker thread while plasmashell uses the glib main
loop. Instead, just use g_spawn_sync to fork and wait in the current
thread.
Dan Nicholson [Thu, 5 Sep 2019 18:20:04 +0000 (12:20 -0600)]
lib/gpg: Don't kill gpg-agent on newer gnupg
GnuPG 2.1.17 contains a bug fix so that `gpg-agent` is killed when the
entire GPG home directory is deleted[1]. If the host's GnuPG is new
enough, then we don't need to bother calling `gpg-connect-agent` to kill
the agent since it will be cleaned up on its own.
Get the GnuPG version from the GPGME OpenPGP engine info and parse it to
see if it matches this criteria.
Dan Nicholson [Fri, 16 Aug 2019 04:24:54 +0000 (22:24 -0600)]
lib/gpg: Only show gpg-connect-agent stderr on failures
When listing GPG keys, the temporary GPG homedir will be constructed by
simply copying the remote's trusted keys to the pubring.gpg file. In
that case, no GPG operations spawning gpg-agent will be run. When
gpg-connect-agent is run to cleanup the homedir, it will helpfully print
on stderr that it's starting gpg-agent like so:
gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
Send gpg-connect-agent's stderr to a pipe and only send it to the
application's stderr if an error was encountered.
But bootloaders could expect the title field to be unique for BLS files.
For example, the zipl bootloader used in the s390x architecture uses the
field to name the boot sections that are created from the BLS snippets.
So two BLS snippets having the same title would lead to zipl failing to
create the IPL boot sections because they would have duplicated names:
$ zipl
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/ostree-3-testos.conf'
Using BLS config file '/boot/loader/entries/ostree-2-testos.conf'
Using BLS config file '/boot/loader/entries/ostree-1-testos.conf'
Error: Config file '/etc/zipl.conf': Line 0: section name 'TestOS 42 20190902.0 (ostree)' already specified
Avoid this by always including the deployment index along with the commit
version in the title field, so this will be unique even if there are BLS
files for deployments that use the same commit version:
lib/bootconfig-parser: Write BLS fragment fields in a deterministic order
Currently the BLS fragments fields write is non-determinisitc. The order
of the fields will depend on how the iterator of the options GHashTable
iterates over the key/value pairs.
But some bootloaders expect the fields to be written in a certain order.
For example the zipl bootloader (used in the s390x architecture) fails to
parse BLS files if the first field is not the 'title' field, since that's
used to name the zipl boot sections that are created from the BLS files.
Write the fields in a deterministic order, following what is used in the
example file of the BootLoaderspec document:
lib/bootconfig-parser: Remove support to preserve comments in BLS files
OSTree has some logic to preserve comment lines in the BLS fragments, but
the BLS fragments are always created on new deployments so the comments
are never carried.
Also, OSTree never writes BLS fragments with comments so these will only
be present in BLS files that were modified outside of OSTree. Something
that should be avoided in general.
Finally, there is a bug in the logic that causes BLS files to have lines
with only a newline character.
The ostree_bootconfig_parser_parse_at() function reads the bootconfig file
using glnx_fd_readall_utf8() but this function NUL terminates the returned
string with the file contents.
So when the string is later split using '\n' as delimiter, the last token
is set to '\0' and a wrong GVariant will be added to the lines GPtrArray
in the OstreeBootconfigParser struct.
This will lead to bootconfig files that contains lines with only a newline
character, since the key in the GVariant would be set to NUL and won't be
present in the options GHashTable of the OstreeBootconfigParser struct.
So let's just remove that logic since is never used and makes BLS files to
have wrong empty lines.
Colin Walters [Wed, 28 Aug 2019 18:59:10 +0000 (18:59 +0000)]
ci: Add prow/ subdirectory with Dockerfile
I'd like to add OpenShift's prow to this repository. Let's start
by adding a Dockerfile - it doesn't really do anything besides build.
However...I've lately been thinking about e.g. shipping the ostree tests
as an image, and then e.g. we could test FCOS by running that container
(which would orchestrate the *host's* ostree).
Anyways, not doing that right now but this is a start.
Also this cherry picks the fix from rpm-ostree CI for the sad
Fedora release package brokenness.
Colin Walters [Mon, 26 Aug 2019 17:43:26 +0000 (17:43 +0000)]
sysroot: Add a clearer error if /boot/loader isn't found
I've seen people confused by this error in the case where
`/boot` isn't mounted or the BLS fragments were deleted, etc.
If you understand ostree deeply it's clear but, let's do
better here and a direct error message for the case where
we can't find `/boot/loader` which is the majority of these.
The other case could happen if e.g. just the BLS fragment
for the booted deployment was deleted; let's reword that
one a bit too.
Simon McVittie [Mon, 30 Jul 2018 15:51:01 +0000 (16:51 +0100)]
Skip test-pull-repeated during CI
This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.
It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.
Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch
Simon McVittie [Fri, 23 Aug 2019 10:26:49 +0000 (11:26 +0100)]
Skip `gpg-connect-agent` when cleaning up temporary GPG home directories
It appears this is sometimes done when it wasn't needed, causing
gpg-connect-agent to wait for an agent to start so that it can tell it
to stop, which results in a lot of noise on stderr when running `flatpak
update`. Debian 10 has GPG 2.2, and according to the commit message of
the commit I'm reverting here, this cleanup should be unnecessary with
GPG >= 2.2.
Jonathan Lebon [Tue, 13 Aug 2019 19:05:09 +0000 (15:05 -0400)]
bin: Better handle --
We would stop passing through `--` and args after it to the underlying
command in `ostree_run`. This made it impossible to use `--` to tell the
parser that following args starting with `-` really are positional.
AFAICT, that logic for `--` here came from a time when we parse options
manually in a big loop, in which case breaking out made sense (see 97558276e4f855442337be01abc8f90cf0dd1810).
There's an extra step here, which is that glib by default leaves the
`--` in the list of args, so we need to take care to remove it from the
list after parsing.
Colin Walters [Tue, 6 Aug 2019 01:59:38 +0000 (01:59 +0000)]
admin/init-fs: Add a --modern switch
This skips creating the default stuff in the physical sysroot.
I don't recall why I did that to be honest; it originated with
the first commit of this file. It might not have ever been
necessary.
In any case, it's not necessary now with Fedora CoreOS, so
prune it and let's have a clean `/`.
Keep the old behavior by default though to avoid breaking anyone.
Add dummy stubs for GPG public functions to be compiled instead of
original code in case if support of GPG is disabled.
Need that to keep API backward compatibility.
Based on original code from file `ostree-gpg-verify-result.c`.
Denis Pynkin [Mon, 20 May 2019 22:35:25 +0000 (01:35 +0300)]
gpg: conditionally build GPG-related code for sign/verification
Do not build the code related to GPG sign and verification if
GPGME support is disabled.
Public functions return error 'G_IO_ERROR_NOT_SUPPORTED' in case if
gpg-related check is rquested.
Dan Nicholson [Fri, 26 Jul 2019 20:28:47 +0000 (14:28 -0600)]
ci/rpmostree: Bump to 2019.3
The test-ucontainer.sh test in rpmostree 2019.1 is failing for
non-ostree reasons. This is fixed in [1], which is part of 2019.3. I
believe this is still a relevant test of f29 since that's what's shipped
in f29-updates.
Dan Nicholson [Fri, 26 Jul 2019 16:42:42 +0000 (10:42 -0600)]
lib/kargs: Don't expose OstreeKernelArgs autoptr cleanup on old glib
Move the OstreeKernelArgs autoptr cleanup definition to
ostree-autocleanups.h, which will only expose the definitions when
building ostree or if glib is new enough. The include of
ostree-kernel-args.h needs to be moved before ostree-autocleanups.h in
ostree.h so that the OstreeKernelArgs type is declared when the autoptr
cleanup is defined. All the places it's used already pull in libglnx.h
first so that the compat macros are picked up if glib it too old during
the ostree build.
Dan Nicholson [Fri, 26 Jul 2019 16:11:00 +0000 (10:11 -0600)]
tests/gpg: Skip tests when subkeys can't be expired
The ability to expire subkeys using gpg's --quick-set-expire is only
available on gnupg 2.1.22. If expiring a subkey fails, assume this is
why and skip the tests that require it but run the actions that the
subsequent tests depend on. This was failing on the Debian Stretch CI
tests since stretch has gnupg 2.1.18.
Dan Nicholson [Mon, 8 Jul 2019 21:08:07 +0000 (15:08 -0600)]
tests/sizes.js: Fix byte array unpacking
Recent GJS changed how byte arrays are unpacked with some assumptions
that they are likely strings. Manually use get_child_value() and
get_byte() to ensure the correct value is parsed when checking the
`ostree.sizes` metadata.
The upstream test is currently passing fine with GJS 1.56.2, but at
Endless we (unfortunately) have a downstream change that adds the object
type as an additional byte in the array. This is parsed incorrectly by
`deep_unpack()`. We can carry this patch downstream, but this change
makes the test more robust regardless.
Simon McVittie [Mon, 30 Jul 2018 15:51:01 +0000 (16:51 +0100)]
Skip test-pull-repeated during CI
This test is expected to fail a small proportion of the time. During
the build of ostree 2018.7-1 in Debian, it seems we were unlucky on
s390x. Non-deterministic tests are also problematic for autopkgtest,
where they can gate migration of our dependencies like GLib, so skip
this test unless the caller has opted-in to non-deterministic tests.
It would be appropriate to enable this test in environments where
failures can easily be retried and are not disruptive to other
packages.
Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-pull-repeated-during-CI.patch
Simon McVittie [Tue, 9 Jul 2019 19:13:57 +0000 (20:13 +0100)]
ostree (2019.2-2) unstable; urgency=medium
* Upload to unstable
* d/gbp.conf: Return to debian/master branch
* d/salsa-ci.yml: Request standard CI on salsa.debian.org
- Disable build-time tests with DEB_BUILD_OPTIONS=nocheck for now.
They don't currently work in the salsa-ci infrastructure, but I
can't reproduce and debug the failure in a local Docker container.
- Similarly, disable the autopkgtest for now.
* Standards-Version: 4.4.0 (no changes required)
* Use debhelper-compat 12
- Override dh_installsystemd instead of dh_systemd_start
- Stop overriding libexecdir
Robert Fairley [Wed, 19 Jun 2019 17:32:00 +0000 (13:32 -0400)]
Makefile-libostree.am: Work around clang issues with g-ir-scanner
Work around an issue with clang-7 in Fedora 29 where the
`-fstack-clash-protection` flag is not recognized. Force
the compiler used by `g-ir-scanner` to `gcc`, so that the flag
is recognized.
Since `clang-4.0` is no longer being used, it should be safe to remove
use of this diagnostic for clang. This enables using `gcc` as a workaround
for `g-ir-scanner`, as `unused-command-line-argument` is not recognized by
`gcc`.
Robert Fairley [Tue, 11 Jun 2019 20:38:16 +0000 (16:38 -0400)]
ci: Use Fedora 29 artifacts
Use Fedora 29 artifacts instead of Fedora 28, since 28 is now
end-of-life.
Also rename `ci/fah28-insttests.sh` -> `ci/fah29-insttests.sh`
and use the https://getfedora.org/atomic_qcow2_latest redirect
URL for the latest Fedora Atomic Host 29 image.
Dan Nicholson [Thu, 13 Jun 2019 21:26:47 +0000 (16:26 -0500)]
tests: Always cleanup gpg-agent when exiting
Add `libtest_cleanup_gpg()` to the array of commands to run when
exiting. This provides 2 improvements:
1. You don't need to worry about whether the test will spawn a gpg-agent
and therefore require adding a call to `libtest_cleanup_gpg()`.
2. All the existing users were calling `libtest_cleanup_gpg()` at the
end of the script. If there was a failure and the script exited
early, then it wouldn't cleanup and there may be a stray gpg-agent
hanging around.
Dan Nicholson [Thu, 13 Jun 2019 20:57:17 +0000 (15:57 -0500)]
tests/libtest: Allow appending actions to be run on EXIT
Currently if a test script adds a trap on `EXIT` to run some cleanup, it
will stomp on the existing trap to run `save_core()`. Allow for scripts
to append actions that will run on exit by introducing an array that
will be iterated over by a single exit runner.
Dan Nicholson [Thu, 10 Jan 2019 20:00:42 +0000 (14:00 -0600)]
lib: Kill GPG agent when cleaning up tmp homedirs
When a temporary directory is used for GPG operations, it's pretty clear
that the running agent will be useless after the directory is deleted.
Call the new `ot_gpgme_kill_agent ()` helper to kill gpg-agent rather
than leaving them it hanging around forever.
As it turns out, gnupg does have code to make gpg-agent automatically
exit when the homedir is removed (https://dev.gnupg.org/T2756), but
that's only available on gnupg 2.2 or newer. Possibly this code can be
dropped later when that's more widely deployed or users/distros have
been advised to backport the necessary changes.
Dan Nicholson [Thu, 10 Jan 2019 19:49:17 +0000 (13:49 -0600)]
lib/gpg: Add helper to kill GPG agent
With GnuPG 2, any time you do basically any operation, a gpg-agent will
be spawned for the GPG home directory in use. The classic way to kill a
gpg-agent is to use `gpg-connect-agent` and send the `killagent` command
as is done in libtest.sh.