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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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.
We got annobin (hardening) warnings in a downstream RPM analysis,
I think this will help ensure that the Rust code is built with
things like `-znow` etc.
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.
I think we should have done this as soon as it was clear that
Rust was sticking and not just an optional thing.
Reasons to make this change now:
- More clear that Rust is going to be the majority of code in the future
- `cargo build` and `cargo test` in a fresh git clone Just Work
- Paves the way for using `cargo` to build C/C++ instead of Automake
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
The `rust-toolset` package does not exist in Fedora, so we cannot
use it for BuildRequires. Change the conditional to exclude ELN
from the %rhel conditional.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
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.
Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.
Closes: #1903
Approved by: jlebon
From Rust v1.37, `cargo vendor` is now baked. Stop building it, and
tweak the vendoring script to adapt to the new UX.
Closes: #1900
Approved by: cgwalters
So this is a somewhat significant change, but I'd like to try having the
canonical spec file upstream. A few reasons for this:
1. We integrate tightly with the distros we're destined for, and so
we're in a pretty good position for knowing how the software should
be packaged.
2. We can atomically change packaging along with the rest of the code.
This has important ramifications, including that it'll be easier to
integrate with continuous build services like Packit, but releases
will also be less fraught with last-minute packaging fixes.
3. I'm playing with Jenkins pipelines and there I'd like to make RPMs
the "artifact" that gets moved down the pipeline into later stages
(e.g. `cosa build`). We could even eventually make it an actual
external artifact so that anyone can easily download RPMs from any
random PR for testing. (And in fact, with a thin yumrepo layer on
top, it could be used to replace Packit/rdgo entirely).
Not that this approach doesn't have issues as well (e.g. on the dist-git
side, we'll need some minimal tooling to merge in the changelog), though
I think it's worth trying out.
Closes: #1900
Approved by: cgwalters
This bumps the requirement on the controlling host to Python 3 only.
It also bumps the requirement on the target host to Python 3 as well
since FCOS doesn't ship Python 2 right now.
Though we'll need to eventually drop all Python usage anyway, but at
least let's get tests passing on FCOS first. (See related previous
patch).
Closes: #1828
Approved by: cgwalters
These are more files that get mangled at `%configure` time. These two
new ones specifically, I tripped on while building on ppc64le for RHEL7.
See https://bugzilla.redhat.com/show_bug.cgi?id=1113618 for more info.
Closes: #1731
Approved by: cgwalters
And `config.guess` and `config.sub`. These files get mangled by the
`%configure` macro when it tries to insert hardening compile flags and
so the checksums no longer match. This is an ugly hack akin to #1554
that requires an incision in the cargo vendor JSON.
Fedora does package a lot of these crate sources now which we
could use to drop these hacks, but not all the crates are packaged (I
counted 4 unpackaged top-level crates), and I'm not sure what their
states are in RHEL7/8 either.
Closes: #1715
Approved by: cgwalters
Nuke systemd source files for the same reasons as libcurl (see #1554).
Also noticed that libz-sys was doing this, though it's not new to this
patch.
For reference, see: https://github.com/projectatomic/rpm-ostree/pull/1554Closes: #1601
Approved by: cgwalters
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.
Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.
For distros that don't ship it (e.g. CentOS) for CI purposes
we build it. For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670
Closes: https://github.com/projectatomic/rpm-ostree/issues/1557Closes: #1573
Approved by: jlebon
The `curl-sys` crate includes with it a bundled copy of libcurl which is
used if `pkgconfig` doesn't find libcurl configuration files. In our
case, we always want to use the system libcurl. So filter it out. This
also drops our *compressed* tarball by 2.5M.
One tricky bit is that cargo crates include a checksum JSON that's read
by `cargo build` later on to validate the crate. So we need to do some
JSON surgery.
What made me look into this was that Koji builds were failing due to the
`%configure` macro including hardening bits that sub out e.g. all
`config.sub` and `ltmain.sh` files which then caused the checksum to
fail validation. This completely sidesteps that issue.
Closes: #1554
Approved by: cgwalters
The script already turned on `-e` later on. Make it conform to the
standard strict mode with the rest of the options right at the
beginning.
Closes: #1554
Approved by: cgwalters
I made a subtle change at the last minute with the previous PR
to use `*` for the glob instead of `.`, because the tmpdir had a `.tmp`
file I didn't want.
But - this caused us to miss the `.cargo` directory which has
the config file. And while I'd been testing builds with no network,
of course cargo was really pulling content from `~/.cargo`.
When I went to do a scratch build in Koji, that failed obviously.
I tested this makes things [work with a SRPM scratch](https://koji.fedoraproject.org/koji/taskinfo?taskID=27490830)
and in my dev container under `bwrap --unshare-net` with `mv ~/.cargo{,.orig}`.
Closes: #1394
Approved by: jlebon
This ends up being different than what landed in librsvg (that
was imported into ostree) because in rpm-ostree we've basically
been using `git archive`-based tarball generation rather than `make dist`
for a long time. And supporting `make dist` looks like it'd get into
handling the `libdnf` bits and walking into `cmake` land so...yeah
let's not do that.
The canonical sources are in git (recursively via submodule),
except for the Rust sources, which cargo can download dynamically,
and with this patch we support glomming all of that together
into a tarball.
(And turn off `make dist` so people understand how we do it)
Tested by `make -f Makefile.dist-packaging dist-snapshot`, then
copying the resulting tarball into a container with `--net=none`
and building there.
Closes: #1391
Approved by: jlebon
This allows non-root users access to the rpm-ostree daemon, which is
a pre-requirement for gnome-software rpm-ostree support.
Closes: #745Closes: #825
Approved by: cgwalters
We'll keep a copy here for now, though the canonical
version should be viewed as the Fedora dist-git.
Updated-by: Colin Walters <walters@verbum.org>
Closes: #667
Approved by: jlebon
Let's try out https://wiki.centos.org/ContainerPipeline
Having maintained Docker images for rpm-ostree seems kind of overdue.
(I didn't actually test the CP bits since I'm not sure how to do that)
Closes: #460
Approved by: jlebon
