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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Whenever the user has SELinux enabled and has any local
modules/modifications installed, it is necessary to rebuild the policy
in the final deployment, otherwise ostree will leave the binary policy
files unchanged from last deployment as it detects difference against
the base content (in rpm-ostree case this is the RPM content).
To avoid the situation where the policy binaries go stale once any local
customization of the policy is made, try to rebuild the policy as part
of sysroot_finalize_deployment(). Use the special
--rebuild-if-modules-changed switch, which detects if the input module
files have changed relative to last time the policy was built and skips
the most time-consuming part of the rebuild process if modules are
unchanged (thus making this a relatively cheap operation if the user
hasn't made any modifications to the shipped policy).
As suggested by Jonathan Lebon, this uses bubblewrap (via
g_spawn_sync()) to perform the rebuild inside the deployment's
filesystem tree, which also means that ostree will have a runtime
dependency on bubblewrap.
Partially addresses: https://github.com/coreos/fedora-coreos-tracker/issues/701
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
`dnf` is present in all the platforms we care about now, and the CentOS
bit is out of date. We can re-add it if we add e.g. C[89]S support with
the updated list of packages.
Motivated by noticing that the `yum` symlink isn't always present.
This adds build-time configuration logic to automatically detect
and switch between libfuse 2.x and 3.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Luca BRUNO <luca.bruno@coreos.com>
Followup to https://github.com/ostreedev/ostree/pull/2463
One thing I noticed here is we lost usage of `build-check.sh`
which also invokes `clang`, which doesn't speak `-fanalyzer`
and would be broken by this if we try to enable `build-check.sh`
again. But that can come later.
Some distributions set this during build in order to have reproducible
builds from the same source code: for example, Debian uses the date
from debian/changelog.
However, some of our tests assume that `ostree commit` will result in
a commit with the current date/time, and SOURCE_DATE_EPOCH breaks that
assumption. Unset it for our build-time tests.
Resolves: https://github.com/ostreedev/ostree/issues/2405
Signed-off-by: Simon McVittie <smcv@collabora.com>
This fixes the ci-release-build.sh script to directly source
and evaluate 'package_version' from its m4 definition, without
requiring a fully configured source tree.
This refreshes the build dependencies installed for the GitHub Tests
workflow based on the Build-Depends in the upstream packaging. The
handling is now more explicit about any deviations and any release
differences.
travis-ci.org stopped running builds on June 15, 2021. Since this
organization is very unlikely to switch to travis-ci.com, just drop the
setup. The new GitHub Actions tests completely replace it.
This runs the test suite in various distros. The intention is to use
this to replace the Travis CI setup since it often has rate limit
failures.
Each configuration in the matrix runs in a Docker container, installs
system dependencies and then builds and tests ostree. The scripts are
basically copy and paste of the travis ones with some of the lesser used
features pruned out.
Some differences from the travis setup:
* OS details are gathered from `/etc/os-release` instead of being passed
in as environment variables.
* The scripts always assume the user is root and don't try to use
`sudo`.
* The `installcheck` test has been removed since ostree doesn't actually
use that. It could be added to run the installed tests or
`gnome-desktop-testing-runner` could just be called directly.
There should be enough flexibility to run other distros like Fedora,
Arch or Alpine. Another option would be to use the other build scripts
in ci/.
Currently the Ubuntu builds are stuck waiting for an answer on what
timezone to use. That could be fixed, but generally the way to do these
types of installs is to set the DEBIAN_FRONTEND environment variable to
`noninteractive` so that debconf just chooses a default. This is what
debootstrap does, for instance. I tested installing tzdata on a local
focal container this way and it just chooses `Etc/UTC` as the timezone.
It's cleaner if this is an build option rather than being
kludged into the CI layer.
Notably we can't use `LD_PRELOAD` anymore with ASAN, so update
our tests to check for `ASAN_OPTIONS`.
The default `_NPROCESSORS_ONLN` heuristic we have isn't cgroups aware.
So it thinks it has e.g. 40 CPUs when running in a k8s pod. This can
then blow through our allocated resource limits.
Declare some modest amount of RAM and CPU resources and override `make`
parallelism.
This matches what rpm-ostree now does in
https://github.com/coreos/rpm-ostree/pull/2155.
And move everything that was in it directly in `ci/`. There's a bunch
more cleanups here that we need to do (and more changes to upstream from
the rpm-ostree copies of this).
As far as I can tell we're not gating on this right now. From
a quick glance, it looks like Debian stable has `libsodium-dev`
but only Ubuntu eoan does which we're not testing right now.
Some of the flatpak tests assert on GPG error strings that come from
OSTree. Those are being changed here, so patch the cloned flatpak 1.4.1
to accommodate the new error strings. When this work lands, I'll send a
patch upstream to flatpak that will eventually trickle back here in a
tagged build.
The vmcheck tests in 2019.3 fail because of an SSH control socket issue
on overlayfs. This is fixed in 2019.4[1]. That has some other changes
such as using Python 3 in tests. The package dependencies have been
synced from the rpm-ostree CI for that.
Unfortunately, this is no longer a totally representative test of f29
since it has 2019.3 in updates. But that's the price you pay for
exercising someone else's CI from your own CI.
1. c89f81c138Fixes: #1994
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.
Closes: #1906
Approved by: cgwalters
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.
1. 45b6186be0Closes: #1892
Approved by: jlebon
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`.
See: https://github.com/ostreedev/ostree/pull/1871#issuecomment-503765624Closes: #1871
Approved by: jlebon
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.
Closes: #1871
Approved by: jlebon
2018.7 started failing `test-ucontainer.sh`. I don't have the cycles to
look more deeply into what was going on there, but bumping to 2018.8
fixes it at least. (And of course, it's passing in rpm-ostree too.)
Closes: #1728
Approved by: cgwalters
