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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Previously we were running clang-format across multiple operating
system versions and hence clang versions, and it turns out
clang has changed the preferred formatting multiple times.
We could *probably* dig in and try to pin things more strongly
but eh...for now let's arbitrarily just use whatever's in
the default GH Action ubuntu-latest runner as that should
be equally painful for everyone.
Signed-off-by: Colin Walters <walters@verbum.org>
For some reason we're not picking this up in the Prow build,
which breaks things because now rpm-ostree hard requires it.
Let's make this a fatal build time error for more clear
debugging.
There's no additional dependencies, and it's a small amount
of new code.
The riskiest thing is the changes to ostree-prepare-root, but
I believe that things are in a good state now there.
Again, this just enables it at *build time* - it's still
off at runtime by default.
As of lately it emits a ton of errors from `grep` about having `*`
at the start of a line, but more generally it's only generally
found papercut-style issues that aren't worth carrying a distinct
checking system for.
Our `install` target doesn't depend on `all` unlike the
rpm-ostree version; not doing so is arguably better, so let's
explicitly build before installing.
I want to gain testing over the composefs path; but without
yet changing the main Jenkins build. Because we have duplicate/overlapping
CI systems, we can take advantage of this by testing the composefs
flow via Prow.
Sync the Prow build scripts with what's in coreos/rpm-ostree
right now.
Then let's test the composefs flow a bit more e2e there.
Having `-Werror` on in CI only by default has generally worked OK,
but I don't think it's worth trying to immediately scramble to port
when they deprecate APIs.
Motivated in this case by
```
src/libostree/ostree-fetcher-curl.c: In function 'initiate_next_curl_request':
src/libostree/ostree-fetcher-curl.c:876:3: error: 'CURLOPT_PROTOCOLS' is deprecated: since 7.85.0. Use CURLOPT_PROTOCOLS_STR [-Werror=deprecated-declarations]
876 | rc = curl_easy_setopt (req->easy, CURLOPT_PROTOCOLS, (long)(CURLPROTO_HTTP | CURLPROTO_HTTPS | CURLPROTO_FILE));
| ^~
```
There's a pile of new warnings in GCC 12 from F36, I dug into
them but most of them seem inscrutable - I am not seeing the bugs.
For now to unblock further work, stop using this flag.
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).
