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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Prep for "Rust-as-main", where I want to build libdnf statically.
And this really completes the "library thinout" story because
now we avoid dragging our *private* `libdnf.so` into the caller's
address space, which can cause potential conflicts if they're
also linking the system one. (Which could easily occur with
something like gnome-software)
All we were using libdnf for (indirectly via libsolv) is comparing
version strings but librpm can already do that for us.
cxx.rs (aka cxxbridge) and cbindgen are
both generating source code. Since the last release
we've introduced the former, and we need to ensure
that the generated cxx.rs source ends up in release tarballs
the same way as the cbindgen code.
Rationalize and clean up the binding infrastructure.
Drop support for the vendored cbindgen which we
weren't actually using:
Closes: https://github.com/coreos/rpm-ostree/issues/2392
Move the cxx-rs and cbindgen bits into the same place,
and update our CoreOS CI build to use a separate `Makefile.bindings`
that just generates the code, so our CI still "works like"
a main Koji RPM build.
Rust has a nice crate for doing perfect hashing. Move that
code into Rust and drop the dependency on `gperf`. This also
helps move away from Autotools.
This is much better than bindgen because it's fully safe. It's
much more ergonomic too:
- Invoke Rust methods-on-structs just like C++ methods-on-structs
- Rust `Result<>` is translated automatically to exceptions
See https://cxx.rs/context.html for more.
We set it to the same value in both cases. There's no reason
to require it at build time anyways.
Part of thinning out the Autotools side in prep for using Cargo.
We aren't going to be shipping major new versions to RHEL7
ever again, so drop this compat definition.
Drop this as part of thinning out our Autotools build system
in preparation for moving to `build.rs`.
This was only needed for RHEL7; RHEL8 and above ships bwrap with
the OS.
Drop this as part of thinning out our Autotools build system
in preparation for moving to `build.rs`.
There won't be any support for writing to the bdb backend in f34, so
e.g. pkglayering won't work (and obviously even composes wouldn't work
once the buildroot moves to f34).
Instead of requiring the whole world to add an `rpmdb` key in their
manifests, let's just add a compile flag for it, and tweak the spec file
to use this flag on f34.
First, we now need the `vendor/` directory at the toplevel because
that's where `Cargo.toml` is.
Now this triggers another bug introduced in the build system
with how we're handling the `rpmostree-rust.h` header.
We ended up vendoring a pre-generated one in the tarball
mainly because RHEL doesn't include cbindgen.
Now probably in the future I'd like to fix that.
But let's clean this up - the tarball generation process copies
the file into `rpmostree-rust-prebuilt.h`, and build machinery
detects that and entirely skips looking for or trying to build
our internal cbindgen.
This is part of investigating using https://cxx.rs/
In order to make this really work, we need to convert some of our C
code to C++ so we can include cxx.rs-generated code.
This starts by converting just two files as a starting point.
I did the minimal porting; I didn't try to actually rewrite them
to resemble modern C++, just "C in C++ mode".
This command allows users to cheaply inject configuration files in the
initramfs stage without having to regenerate the whole initramfs (or
even a new OSTree commit). This will be useful for configuring services
involved in bringing up the root block device.
```
$ echo 'hello world' > /etc/foobar
$ rpm-ostree ex initramfs-etc --track /etc/foobar
Staging deployment... done
Run "systemctl reboot" to start a reboot
$ rpm-ostree status
State: idle
Deployments:
ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
InitramfsEtc: /etc/foobar
● ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
$ reboot
(boot into rd.break)
sh-5.0# cat /etc/foobar
hello world
```
See the libostree side of this at:
https://github.com/ostreedev/ostree/pull/2155
Lots more discussions in:
https://github.com/coreos/fedora-coreos-tracker/issues/94Closes: #1930
This avoids us leaking all of the Rust symbols as public
into our shared library.
Came up in team chat since one person tried to copy just `/usr/bin/rpm-ostree`
from the dev container into a target and got a linker crash; but
really we want to avoid all the duplicated symbols entirely.
(And we should investigate cross-language LTO because that's the
only way to get full savings)
We're seeing some CI failures that I think are a bug in rojig.
In the bigger picture...we never actually started using this,
and I think longer term shipping os updates via containers
probably makes more sense.
I put a *lot* of effort into this code and it's pretty cool
so it's hard to just delete it. And *maybe* someone out there
is using it (but I doubt it). So rather than just deleting
it entirely let's make it a build-time option.
I verified that it builds at least.
The instructions for doing a release were outdated. Take the opportunity
to just move it to a dedicated markdown file and breaking it out to make
it easier to follow.
This is one step short of using a release checklist like some of the
other CoreOS projects do. This is a good base to eventually do that if
we want.
Going to update rpm-ostree for RHEL 8.3, we did a huge bump
in libdnf which now defaults to enabling zchunk in its build
system. We added the infrastructure before to detect things,
so propagate that to libdnf.
The current `rpm-ostree-2020.1-1.fc31.x86_64` in Fedora
was [built with a truly ancient libostree](https://kojipkgs.fedoraproject.org//packages/rpm-ostree/2020.1/1.fc31/data/logs/x86_64/root.log)
because Fedora's build system is weird and only adds packages
released after "gold" into the buildroot via an override
that times out.
This actively breaks things because rpm-ostree isn't
detecting the read-only sysroot.
Let's bump our hard requirement.
We don't *actually* use this ourself, but librepo does, and libdnf gets confused
if librepo doesn't support it. This is the case in RHEL8 currently.
Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata)
on RHEL CoreOS. And we have a test in kola that does this today.
I think we're in a good position now for FCOS enablement, and there are
a bunch of fixes we should get out, such as the zstd one.
Closes: #1875
Approved by: cgwalters
Right now there's an issue in Fedora with `g-ir-scanner` picking up
`-fstack-clash-protection` from the `sysconfig` Python module and
passing it to `clang`, which doesn't understand this flag yet.
Just work around this by (1) not even building GIR bindings for our
bundled libdnf since there's no need, and (2) overridding the compiler
used by `g-ir-scanner` so it's always `gcc`.
See: https://github.com/projectatomic/rpm-ostree/pull/1787#issuecomment-473971585Closes: #1787
Approved by: cgwalters
rdgo is choking on this right now because, even though we added
`/usr/share/bash-completion` to the list of dirs to check in the spec
file[1], we don't have `bash-completion` installed in the buildroot, so
the `completionsdir` pkgconfig var isn't defined and we end up
defaulting to `/etc/bash_completion.d`.
el7's bash (not that it matters much now after #1785) is indeed new
enough to know that location. See also
https://github.com/ostreedev/ostree/pull/1083.
[1] https://src.fedoraproject.org/rpms/rpm-ostree/pull-request/30Closes: #1786
Approved by: rfairley
Teach rpm-ostree to interpret rebases where the remote component is a
path to a local repo, e.g.:
rpm-ostree rebase /mnt/ostree/repo:my/target/ref
Essentially, the local remote in this case is considered "ephemeral".
It's kind of the equivalent of, on traditional systems:
dnf install --repofrompath repo,/path/to/repodata ...
The use case for this is in OpenShift v4, in which upgrades are done
from containers containing the OSTree commit. There, we want to point
RPM-OSTree directly at the repo in the mounted container and rebase to
the checksum.
For now, the option is marked experimental. One major reason for this is
that the way we pass the repo differs on RHEL7 vs other platforms. (See
comment block in `rpmostree-dbus-helpers.c` for details).
Related: https://github.com/openshift/machine-config-operator/issues/314
Co-authored-by: Colin Walters <walters@verbum.org>
Closes: #1732
Approved by: cgwalters
Let's make use of the GitHub release feature to make it more prominent
on the "Releases" tab, but more importantly so that we can attach
vendored tarballs for downstreams. E.g. this will allow us to have a
correct `Source0` field in the Fedora spec file.
Related: #1683Closes: #1684
Approved by: rfairley
