This is in the same style as GLib's GLIB_CHECK_VERSION [1].
Note that the github.com/HarryMichal/go-version package is a fork of
github.com/mcuadros/go-version. The latter is now marked as read-only
and archived by its owner.
The fork was necessary to fix the documentation of the CompareSimple
function. The function is supposed to conform to the strcmp
convention. ie., return 0 if both versions are equal, 1 if the left
side is bigger, and -1 if the right side is bigger. However, the
documentation had it the other way round.
[1] https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-CHECK-VERSION:CAPShttps://github.com/containers/toolbox/pull/318
These values are generally useful, and reading any of them is a
potentially fallible operation. Since the absence of any of these
values is indicative of a broken environment, it's more convenient to
read them early on during start-up and abort, instead of trying to
handle the error later on.
https://github.com/containers/toolbox/pull/318
All the existing commands and their flags are present; but barring
'help', '--help' and logging, they don't do anything.
The skeleton was bootstrapped with Cobra Generator.
https://github.com/containers/toolbox/pull/318
A subsequent commit will use this to implement the help command.
Just like the existing POSIX shell implementation, the standard error
needs to be redirected to standard output. For details see commit
5e63e9ec9b.
https://github.com/containers/toolbox/pull/318
Meson doesn't support Go [1], so this is implemented by a custom target
that invokes 'go build' to generate the binary.
Unfortunately, when using Go modules, 'go build' insists on being
invoked in the same source directory where the go.mod file lives,
while Meson insists on using a build directory separate from the
corresponding source directory. This is addressed by using a build
script that goes into the source directory and then invokes 'go build'.
Currently, the Go code is only built when a Go implementation is found,
and even then, it's not installed. Non-technical end-users are supposed
to continue using the POSIX shell implementation until the Go version
is blessed as stable.
[1] https://github.com/mesonbuild/meson/issues/123https://github.com/containers/toolbox/pull/318
This fixes the following build failure:
atomic_reactor.util - Package chkconfig available, but not installed.
atomic_reactor.util - No match for argument: chkconfig
atomic_reactor.util - Package dbus-daemon available, but not
installed.
atomic_reactor.util - No match for argument: dbus-daemon
atomic_reactor.util - Package rpm-plugin-systemd-inhibit available,
but not installed.
atomic_reactor.util - No match for argument:
rpm-plugin-systemd-inhibit
...
...
...
atomic_reactor.util - ERROR - {'errorDetail': {'code': 143,
'message': "The command '/bin/sh -c dnf -y reinstall
$(<missing-docs)' returned a non-zero code: 143"}, 'error': "The
command '/bin/sh -c dnf -y reinstall $(<missing-docs)' returned a
non-zero code: 143"}
Current Rawhide is actually version 33. So the appropriate image should
be pre-pulled.
Because of the old version of image being pulled, the tests were
failing.
The tests introduced by commit b5cdc57ae3 have proven to be
rather unstable due to mistakes in their design. The tests were quite
chaotically structured, and because of that images were deleted and
pulled too often, causing several false positives [1, 2].
This changes the structure of the tests in a major way. The tests
(resp. commands) are now run in a manner that better simulates the way
Toolbox is actually used. From a clean state, through creating
containers, using them and in the end deleting them. This should
reduce the strain on the bandwidth and possibly even speed up the
tests themselves.
[1] https://github.com/containers/toolbox/pull/372
[2] https://github.com/containers/toolbox/pull/374https://github.com/containers/toolbox/pull/375
This change adds a pre-run task to pull the fedora-toolbox images from
the registry to reduce the number of false positives caused by
'podman pull' failing to download them during the actual test.
Each section needs a separate playbook because they use different
versions of Fedora, and hence different default images.
https://github.com/containers/toolbox/pull/375
This adds several .yaml files that specify jobs (those in folder
playbooks) and one that serves as the main config (.zuul.yaml).
Tests and builds are currently executed on every change in PRs (ie.,
check and gating) and periodically (according to the documentation
this pipeline should be run at least once a day).
There are 4 tests in total:
1. 'ninja test' - does the same thing that Travis did
2. Fedora 30 - runs the system tests with current Podman and Toolbox
in Fedora 30
3. Fedora 31 - the same but for Fedora 31
4. Fedora Rawhide - the same but for Fedora Rawhide
https://github.com/containers/toolbox/issues/68
These tests are written using BATS (Bash Automated Testing System). I
used a very helpful helpers.bash script from the libpod project (Thank
you!) that I tweaked slightly.
https://github.com/containers/toolbox/issues/68
/usr/share/profile.d is the default location where toolbox.sh is
installed, even though, in practice, most (all?) distributions use
/etc/profile.d. It's reasonable to at least make the code work with the
default build values.
https://github.com/containers/toolbox/pull/362
/sys/fs/selinux is only present when SELinux is 'enforcing' or
'permissive'. When it's disabled, /sys/fs/selinux doesn't exist and
sysfs doesn't let you create it either. Therefore, the attempt to wipe
out the toolbox container's /sys/fs/selinux by bind mounting
/usr/share/empty over it fails, and in turn prevents the container from
starting up.
Fallout from f9cca5719dhttps://github.com/containers/toolbox/issues/344
On Silverblue, /mnt is a symbolic link to /var/mnt. Matching the
presence of /var/mnt on the host inside the toolbox container would
make things less confusing for users.
https://github.com/containers/toolbox/issues/92
A subsequent commit will give access to /var/mnt from the host, if its
present, by bind mounting /run/host/var/mnt at runtime. However, it
turns out that an attempt to non-recursively bind it will error out, if
the host's /var/mnt already contains a mount point.
On the host:
$ sudo mkdir --parents /var/mnt/tmp
$ sudo mount -t tmpfs none /var/mnt/tmp
Inside the container:
$ sudo mkdir --parents /var/mnt
$ sudo mount --bind -o rslave /run/host/var/mnt /var/mnt
mount: /var/mnt: wrong fs type, bad option, bad superblock on
/run/host/var/mnt, missing codepage or helper, or other error.
https://github.com/containers/toolbox/issues/92
