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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
On traditional rpm systems this can hang because the outer
process may have an rpmdb lock, and the inner one wants
to acquire a lock. Here we're sandboxing the `%post` script
and it's targeting a separate temporary filesystem compared to
the booted one (so there's no double locking). Plus we don't
create the rpmdb in the target until all scripts have run.
Inspired by https://twitter.com/_msw_/status/1335981558717587473
I've been meaning to hook up `ex history` to a pager a-la-journalctl,
though it's not high-priority, and it'd be nice to do it in Rust instead
(I think this command would be a good candidate for more oxidation if we
move the CLI entrypoint to Rust.)
For now at least, let's not spam the full history by default. Instead,
limit it to 3, and add `--limit` and `--all` options to tweak that if
wanted (I thought about making `--limit -1` just mean all entries,
though I think I'd still want an explicit `--all` anyway.)
We've been neglecting this for a long time and it's been omitted
from dependabot. Everything still seems to work.
Prep for converting to a workspace so we only have a single
`Cargo.lock`.
I was looking at the output of `ostree admin config-diff`
on a base FCOS boot. It'd be really nice to trim that down
as much as possible, so we can cleanly capture the difference
between user config and system config.
Let's use static enablement rather than presets.
I still think we should do this at some point, but
the experiment with using `GKeyfile` for configuration
is IMO a failure and the variety of data formats
(treefile JSON vs YAML vs origin keyfiles vs container keyfiles)
causes a lot of confusion.
Prep for https://github.com/coreos/rpm-ostree/issues/2326
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 is technically an API break, but that method has never really been
very useful and I doubt it was ever seriously used. There is no wrapper
for it in the CLI client. Let's just delete it and pretend it never
existed.
In the end, I don't think the ability of supporting multiple separate
stateroots is widely used in practice.
Closes: #551
The `Journal::open` API has been deprecated in favour of the new
`OpenOptions` builder pattern.
We could dedupe this a bit more, though the mock journal in the history
code makes it trickier and there's little value in mocking the builder
pattern too.
Those got moved to GitHub from readthedocs.io, meaning links pointing
to specific pages return a 404, so this fixes that along with
skipping the redirect for the links that just point to the main page.
We have no business accessing `/var/roothome` or `/var/home`. In general
the ostree design clearly avoids touching those, but since systemd offers
us easy tools to toggle on protection, let's use them. In the future
it'd be nice to do something like using `DynamicUser=yes` for the main service,
and have a system `rpm-ostreed-transaction.service` that runs privileged
but as a subprocess.
Now always based on an overlayfs:
f2773c1b55
This fixes a whole swath of problems with the previous design,
including the danger in replacing `/usr/lib/ostree-boot` which
broke booting for some people.
Further, we don't need to push a rollback deployment; the livefs
changes are always transient. So now we store livefs state
in `/run` instead of in the origin file.
Since we're doing a rewrite, it's now in Rust for much more safety.
We also always work in terms of incremental diffs between commits;
the previous huge hammer of swapping `/usr` was way too dangerous.
The libdnf plugins are not really relevant for us (the only in-tree one
is for RHSM). Let's tell libdnf to not even bother trying to load them
in.
Prompted by the fact that libdnf tries to load the plugins from the
bundled path which doesn't exist:
```
libdnf-WARNING **: 13:49:33.207: Can't read plugin directory
"/usr/libexec/rpm-ostree/lib64/libdnf/plugins/": No such file or
directory
```
In test contexts, this warning causes a `SIGABRT`.
This effectively reverts commit: c8113bde32
We never ended up using it; instead the `rdcore` bits from
`coreos-installer` have the rootfs reprovisioning logic.
This allows us to fix RHCOS builds with coreos-assembler
after e76b270198
That broke change detection.
We need to explicitly provide the previous commit. This is
very similar to `--parent`, and arguably we should
have made `--parent` have change detection semantics too
at the time.
