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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We want to be able to enable more repos than those in the treefile when
downloading extensions. In RHCOS for example, the `kernel-rt` packages
come from a separate repo.
But also, once we support "development" extensions, we want to support
the case where devel packages come from another repo.
In the core context, this is redundant with `sort_packages` because it
won't put local packages in the `pkgs_to_download` array anyway, but we
want this check even if we call `rpmostree_download_packages` directly
and pass some packages which may be local.
When automatic updates are driven by an external driver like Zincati,
display e.g. `AutomaticUpdatesDriver: Zincati` instead of
`AutomaticUpdates: driven by Zincati`, since the latter might suggest it
is rpm-ostree's own built-in support for automatic updates.
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive. This of course would
have been caught by Rust...
```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
#0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
#1 0x7f92089da902 (/lib64/libglib-2.0.so.0+0x9f902)
#2 0x7f92089de20f (/lib64/libglib-2.0.so.0+0xa320f)
#3 0x7f92089de52e (/lib64/libglib-2.0.so.0+0xa352e)
#4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
#5 0x7f9208b7445f (/lib64/libgio-2.0.so.0+0xab45f)
#6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
#7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
#8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
#9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
#10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
#11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
#12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
#13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
#14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
#15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
#16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
#17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
#18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
#19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
#20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
#21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
#22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
#23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
#24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
#25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
#26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
#27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
#28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
#29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
#30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
#31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)
Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
#0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
We now have bidirectional calling between Rust and C++,
but we are generating two static libraries that we then
link together with a tiny C++ `main.cxx`.
Let's make another huge leap towards oxdiation by
having Rust be the entrypoint. This way cargo natively
takes care of linking the internal Rust library, and
our C++ internals become the library.
In other words, we've now fully inverted from
"C app with internal Rust library"
to "Rust binary with internal C++ library".
In order to make this work though we have to finally
kill the C unit tests. But mostly everything covered
there is either being converted to Rust, or covered
elsewhere anyways.
Now as the doc comments in `main.rs` say...this is
a bit awkward because all the CLI code is still in C++.
Porting stuff to use e.g. `structopt` natively would
be a bit of a slog. For now, we basically rely on
the fact that the Rust-native CLIs are all hidden
commands.
Update submodule: libdnf
The way this tries to replace the system Rust is hacky and
actually I realized belatedly I may have broken it recently; basically
`installdeps.sh` re-adds the system one, and it's hard to be sure
with our current buildsystem we're using the newer one from `$PATH`.
What we really want to do here is use a CentOS8 buildroot,
which will automatically enforce this in a better way along
with solving other problems. But right now we've broken
that because libdnf requires a too-new libmodulemd.
So let's just rely on the Fedora rust for now.
Let's do a build with clang as a cleanly separate context
instead of serially; and also do it unconditionally. This
is prep for turning on more `-Werror` flow in both cases,
and also using clang `scan-build` in CI.
Nothing is using this; our unit tests don't change uids and
most of our testing is in VMs.
Dropping this makes it easier to run the scripts outside of CI.
See https://github.com/rpm-software-management/libdnf/pull/1127
Basically IMO the "return if fail" pattern is a carry-over
from C GTK+ apps where the idea is it's better to try to stumble
forward than have the app crash for the user.
In our case though, IMO we absolutely should just crash
if our assertions trip, because we're maintaining the user's
root filesystem.
Notably this includes [std::optional](https://en.cppreference.com/w/cpp/utility/optional)
which I'd like to use.
The dnf-5-devel branch uses this too, and C++-17 is now well
supported in current GCC, which is available in RHEL8 DTS too.
This demonstrates well the strength of the cxx-rs approach;
we can keep an API in C++ but add unit tests in Rust which
just works much more nicely.
Prep for https://github.com/coreos/rpm-ostree/pull/2502
which wants to drop the C++ unit tests.
The correct place for this would be...something like ostree-releng-tools
or coreos-assembler. Or perhaps in the future a Rust ostree-ext-tools repository.
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.
Registration through `RegisterClient` is not mandatory today; for
example, Zincati does not register itself currently.
Look up systemd unit of caller if it is not already registered.
The previous build was GC'd; unfortunately it's very nontrivial
to make this test truly robust over time because FCOS changes;
we might sometimes have an outstanding update, other times might
not etc.
Let's just sanity check the commands; ultimately they're
thin wrappers around just downloading packages so we don't need
deep checks.
Let's include the final extensions file in JSON format as part of the
output directory. A key difference from the input file (apart from YAML
vs JSON) is that this is post-filtering, so any extensions which were
removed because the architecture does not match are not present.
This JSON file will be used by cosa and the MCO. See discussions in:
https://github.com/openshift/os/issues/409
Prep for reworking our binary entrypoint to be Rust and not C++.
We need to split up main into sub-pieces; but before we do
that let's avoid `goto out` and rework into declare-and-initialize
style which cleans things up here.
Until now with cxx-rs we'd been using it effectively as a better
cbindgen - we're exposing Rust code to C++ safely. This is
the first case of having Rust calling back into C++ using cxx-rs.
This allows us to fully use cxx-rs with `extern "C++"`. Now
we do call back into the C/C++ today, but it only works outside
of cargo/Rust's knowledge. Most notably, it means we can't
use our C code in `cargo test`. And that's a problem
for moving some C/C++ code to Rust, because we want to port
the unit tests too.
For now, re-declare our dependencies and part of the build
system inside the Cargo build. However, this is also
an important step towards using Cargo as our *sole* build
system.
We don't add build dependencies too often, so the short
term duplication should be OK.
However, a major unfortunate side effect of this is that
we now need to serialize the build process; almost all the
C/C++ comes first (`librpmostreeinternals.la`) and then
the Rust build, then we finally generate the executable
with both.
The only way out of this really is to move more of the
C/C++ build into Cargo, and we probably want to refactor
into internal crates.
I think we did this at some point, but then stopped.
Prep for https://github.com/coreos/rpm-ostree/pull/2413
because we'll need a full build of the C++ side too in order
to `cargo test`.
It is sometimes useful to only register an update driver without
actually deploying anything. If the argument for `deploy` is an
empty string, only register driver and then no-op.
We temporarily set the rpmdb path to be an absolute path pointing under
the tmprootfs when writing the rpmdb. This throws off libsolv 0.7.17,
which learned to give the `_dbpath` macro precedence on where the rpmdb
is located:
04d4d036b2
So then the rpmdb sanity-check we do when exiting
`rpmostree_context_assemble()` breaks because it can't find the expected
packages.
Because RPM macros are in global state, there's no elegant way of
setting it just for the rpmdb write operation (short of forking), so
just fix this by setting `_dbpath` back to the correct value after we're
done writing the rpmdb.
Closes: https://github.com/coreos/fedora-coreos-tracker/issues/723
Mostly straightforward stuff. It taught me about the `matches!` macro,
which looks really useful.
Wanted to turn this on in CI, but there's still a bunch of clippy
warnings coming from the `cxx.rs` stuff and some of our unsafe blocks.
For example, it wants the `files` arg in `initramfs_overlay_generate` to
be `&[String]` instead of `&Vec<String>` but that would break cxx.rs (it
looks like cxx.rs does support slices, but it would require creating one
from the vector we have to create anyway).
