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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This way we're sure it will build in e.g. Koji. Right now
it's annoying to test that locally; one needs to explicitly
create a no-network container to do so strictly. But
cargo has a convenient `--offline` flag, and nothing else
in our build stack should touch the network.
This adds support for e.g.:
```
$ rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2020-2908628031
```
This will find the Koji builds from the listed update, download
all the RPMs (that aren't debuginfo) and pass them for overrides
in the same way we support `override replace http://somewebserver/foo.rpm`
now.
We also support directly linking a Koji build:
```
$ rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=1625029
```
Bodhi has a modern HTTP+JSON API, and the lack of a Koji equivalent
drove me to create https://github.com/cgwalters/koji-sane-json-api
and we currently depend on an instance set up in the OpenShift CI
cluster.
I hope it shouldn't take long to deploy this in Fedora Infra,
but I don't want to block on it.
Also notably this still downloads *all* the other RPMs even
ones that aren't installed. Handling that truly correctly
would require moving this logic to the daemon and core.
All of this functionality is keyed off a `cfg(feature = "fedora-integration")`
that is detected by a Rust `build.rs` which parses the build environment's
`/etc/os-release` for now.
This is cleaner if we move the "catch and print errors" into
the Rust side. We lose the "print errors as red" part but
eh we can readd that later Rust side.
Apparently small rpmdb changes can cause the size to stay the
same due to preallocation, and rsync defaults to skipping files
based on (name, size, mtime). It's really ostree's mtime canonicalization
that's unfortunate here.
Anyways, we obviously don't care about performance here so use
`-I` to disable that rsync check.
(Also remove the `mkdir -p` since it's not necessary since a long time)
Closes: https://github.com/coreos/rpm-ostree/issues/2435
This makes the C++ side a bit uglier because the "variable mapping"
is more Rust-native but we only use it Rust side anyways.
(We can't yet move the basearch bits to rust because it depends on
libdnf, which requires buildsystem unification)
But all the unsafe FFI conversion drops out, as do the duplicated
C unit tests.
Prep for the [fedora-integration PR](https://github.com/coreos/rpm-ostree/pull/2420).
This also generalizes the "fetch URL to tempfile" code into
supporting multiple at once - it's much more efficient to do
it that way because we can reuse a TCP connection to servers,
parsed certificates etc.
Now that the whole core codebase is "compile in C++ mode",
remove the ifdef and move the C++-specific `#include <>`s
up so it's more obviously supported to add new
C++ code (if necessary).
We previously severed the dependency between the shared library
and our internal code, but the library still included internal
headers even though they weren't used.
This broke my attempt to natively use C++ in some headers.
Drop the unused headers and clean up the `#include`s.
(I'm going to start calling it `live-apply` instead of "livefs")
On one hand, this drops the unsafe bindgen glue. On the other
hand it demonstrates a notable current ergonomic shortfall of
cxx-rs in that it doesn't support `Option<T>`, so we represent
optional strings by converting them to empty strings.
(Relatedly I discovered in C++ there is `std::optional<>` but it's in C++17.
I assume we can depend on that but let's for now match libdnf's
usage of `-std=c++14` because we know that works everywhere)
cxx-rs has support for bridging types, but it's more awkward
for us because those types are defined in other crates, so
we need to do a newtype dance. Further cxx-rs doesn't currently
support automatically generating wrappers, so add a custom
`gobj_wrap()` for now.
I started writing a comment about why we run autotools twice,
then decided that was *much* uglier than extracting the binding
rules to a separate `Makefile`. But I forgot to go back
and remove the first part, so do that now and fix up the comment.
We've had a problem for a long time that e.g. `rpmostree-rust.h`
didn't have dependencies on the relevant Rust sources, so changing
it required `rm -f rpmostree-rust && make` which is very confusing.
Improve things here for both it and cxx.rs so that we use
content-based change detection (this is a default in more modern
build systems). This way e.g. `touch Cargo.toml && make` won't
implicitly result in rebuilding all of the C/C++ side.
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.
AFAICT, we just need `cxxbridge` to be in the `PATH` of the building
user. Let's avoid targeting privileged paths so devs can just run this
script directly without `sudo`.
The way gresources work using a constructor function started
failing when I was refactoring the build system, and I couldn't
figure it out. It's just easier to use Rust for this which
has nice toolchain-integrated functionality for this.
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 need to cleanly split off "test dependencies" that we
install inside the cosa pod from builds (where we won't
have `cargo`) from the build time where we use the cosa
buildroot image.
Prep for using https://cxx.rs
In the previous buildsytem rework we disabled the unit tests because
of linking problems. Now I realized that a simple solution is
to continue to build one big object, just make it an internal
static library and have a tiny "stub main" that delegates to an entrypoint.
That's basically what the C unit tests are - an alternative `main()`
with some extra code.
The cool thing about this is it emphasizes how "integrated" apply-live
is versus the uncontrolled `rpm-ostree usroverlay`. We're still
tracking the state of things reliably and can print it.
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`.
