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.
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.
This completes the task of unifying the build of all of our C/C++
into a single unit, which avoids code duplication and will allow
us to more easily use LTO in the future.
Prep for reworking `core.rs` to use cxx-rs
(Notable in this is the dropping of `goto out` by writing
a small struct with a destructor to handle the cleanup `unlinkat()` for us)
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".
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.
Tried a `--unified-core` build of Silverblue and it blew up on this.
Just copy-pasting the comment in the code:
34927af202
From a read of that script, none of it is necessary for rpm-ostree. It's about working around
bugs from a traditional RPM in-place update, but rpm-ostree always starts from a clean
filesystem checkout.
Closes: #1869
Approved by: jlebon
This brings us back in sync with the latest libdnf git master. This
required a bunch of work both on the libdnf and rpm-ostree side to get
working. See e.g.
https://github.com/rpm-software-management/libdnf/issues/645.
A few things to adapt to:
- soname bump to `libdnf.so.2`
- `DnfAdvisory` is no longer a `GObject` (annoyingly it's not replaced
by something we can keep a ref on, so this requires some hacks to
steal from the `GPtrArray` -- could enhance libdnf for this later)
- disable SWDB history writing
- use new reldep public API
- update for latest `hy_subject_get_best_selector()` API
This now unlocks the possibility to add support for modules. (One can
see hints of this in the diff by the fact that `libdnf` links to
`libmodulemd1`.)
Update submodule: libdnf
Closes: #1404
Approved by: cgwalters
This was caught by the abicheck in Fedora; since we were building with default
visibility for `librpmostreepriv.la` which was linked statically into the public
library, we'd end up with lots of internals as public ABI.
Fix this by using `-fvisibility=private` for the libpriv build and for good
measure elsewhere so we remember to use it by default.
Closes: #1320
Approved by: jlebon
This renames the remaining C files, tests, etc. There are only
a few hits for `jigdo` left; changing them would be a format break,
so let's wait to do that until we need to.
Closes: #1279
Approved by: jlebon
src/libpriv/rpmostree-cleanup.h was removed in commit f14d1a3536 and its presence in Makefile causes "make tags" to fail.
Closes: #1270
Approved by: jlebon
There are types that we want to share between the daemon and the client
for deduplication. Those are, as expected, related to D-Bus things like
formats and enums. Let's create a new file for it rather than shove it
in `rpmostree-util.h`. As mentioned in the file, some of these probably
belong better directly in the public API.
Closes: #1147
Approved by: cgwalters
This patch introduces a new `AutomaticUpdatePolicy` configuration. This
was a long time coming for rpm-ostree, given that its update model makes
it extremely apt for such a feature.
The config supports a `check` mode, which should be very useful to
Atomic Workstation users, as well as a `reboot` mode, which could be
used in its present form in simple single node Atomic Host situations.
There is still a lot of work to be done, including integrating
advisories, and supporting a `deploy` mode. This feature hopefully will
be leveraged as well by higher-level projects like GNOME Software and
Cockpit.
Closes: #1147
Approved by: cgwalters
Introduce a new `rpmostree_context_execute_jigdo()` that fills the same role as
`ostree_repo_pull_with_options()`. This will be used by the sysroot upgrader.
I didn't change the jigdo client code much yet; as a TODO says there's a lot
more we can do to improve things. Some of the public APIs we added to the core
no longer need to be public, such as `rpmostree_context_set_packages()`. But
let's try to do things incrementally.
I did at least change the `g_print()`s to `rpmostree_output_message()`. I
dropped the `commit_and_print()`; at some point will come back and clean things
up so we consistently journal/print stats.
Closes: #1168
Approved by: jlebon
Prep for doing the "single object, multiple .c files" pattern like is done in
e.g. libostree with OstreeRepo and `ostree-repo-{refs,commit.c}` etc. For jigdo
we'll need to split things up (see what I did there?).
Closes: #1168
Approved by: jlebon
Prep for adding `compose tree --ex-jigdo` to do both at the same time.
Changes other than code motion were minimized; the main thing was tweaks around
the initial option processing to call the API.
Closes: #1146
Approved by: jlebon
Rather than entirely symlinking `systemctl` → `/bin/true`, in order
to e.g. have NetworkManager be enabled, we need to process presets.
This is one of the things that's breaking FAHC where I did a
`--ex-unified-core` deployment.
(Actually it's a bit tempting to run a mass preset pass at the end,
but for now let's do this)
Implementation note: this is our first use of GResources, which
is a handy way to embed data into our final binary.
Closes: https://github.com/projectatomic/rpm-ostree/issues/550Closes: #1148
Approved by: jlebon
Tracking issue: https://github.com/projectatomic/rpm-ostree/issues/1081
To briefly recap: Let's experiment with doing ostree-in-RPM, basically the
"compose" process injects additional data (SELinux labels for example) in an
"ostree image" RPM, like `fedora-atomic-host-27.8-1.x86_64.rpm`. That "ostree
image" RPM will contain the OSTree commit+metadata, and tell us what RPMs we
need need to download. For updates, like `yum update` we only download changed
RPMs, plus the new "oirpm". But SELinux labeling, depsolving, etc. are still
done server side, and we still have a reliable OSTree commit checksum.
This is a lot like [Jigdo](http://atterer.org/jigdo/)
Here we fully demonstrate the concept working end-to-end; we use the
"traditional" `compose tree` to commit a bunch of RPMs to an OSTree repo, which
has a checksum, version etc. Then the new `ex commit2jigdo` generates the
"oirpm". This is the "server side" operation. Next simulating the client side,
`jigdo2commit` takes the OIRPM and uses it and downloads the "jigdo set" RPMs,
fully regenerating *bit for bit* the final OSTree commit.
If you want to play with this, I'd take a look at the `test-jigdo.sh`; from
there you can find other useful bits like the example `fedora-atomic-host.spec`
file (though the canonical copy of this will likely land in the
[fedora-atomic](http://pagure.io/fedora-atomic) manifest git repo.
Closes: #1103
Approved by: jlebon
Add editor option for kernel arguments. The logic
was taken from the ostree-commit editor.
The user now can edit the kernel arguments from an editor.
The synchronization related issue is resolved by reloading the
sysroot and see if the sysroot has been changed since the call
of the editor prompt.
Closes: #1097
Approved by: jlebon
In the jigdo path we don't actually want to import the OIRPM literally
into ostree. I considered adding jigdo logic into `rpmostree-unpacker.c`
but it'd be a mess as the functionality is quite logically separate
from importing.
So split off an `unpacker-core.c` file which has the bare libarchive+RPM
helpers, and rename `RpmOstreeUnpacker` to `RpmOstreeImporter`.
Closes: #1110
Approved by: jlebon
API functions from ostree-kernel-args.c
are copied to libpriv. The append functionality
reuses _ostree_kernel_args_append_argv() for
collecting added kernel arguments.
Also added handlation in rpm-ostree upgrader
to allow deployments happen with kernel arguments.
Now, the user is able to add kernel arguments via
'rpm-ostree ex kargs --append key=value'
or 'rpm-ostree ex kargs --append key' if they
want to have an empty value with key.
The user is also able to display the current
kernel arguments via 'rpm-ostree ex kargs'
In addition, this functionality will create a pending deployment,
and will update the conf file in /boot/loader/entries/ostree-$osname-0.conf upon success.
Closes: #1013
Approved by: cgwalters
I want to use this in livefs, where I'll end up doing some diff
computations on the server and am currently rendering text there.
It might also be a step towards using this in `db diff`.
Closes: #709
Approved by: jlebon
In prep for adding "regenerates initramfs" to "is locally assembled",
we need more abstraction. I previously introduced a helper function, but
I'd still need to touch every call site when changing that.
Rather than having each caller re-parse the origin, let's parse it once into a
structure, and then have error-free accessors for it (that also don't malloc).
This way when adding a new flag, I don't need to touch every call site.
Notes:
- Some places in the code (like the deployments -> variant bits) tried to
handle deployments without an origin gracefully. That's no
longer true. I'm not sure how much we care - do we?
- There are a few places where I changed `packagelist.len() > 0` to
`is_locally_assembled()`. I think this is right, but we'll need
to be sure the "no packages to overlay, just initramfs" case
works when that lands.
Closes: #566
Approved by: jlebon
Since the dracut run is now separated from the rest of postprocess, we change it
to use the bwrap API diretly, and this lets use the new _IMMUTABLE bwrap type.
This will make it easier to reuse for client-side initramfs regeneration.
Splitting this off makes it also easier to simplify the remaining mutable
usage in postprocess.c.
Closes: #560
Approved by: jlebon
The treecompose code will learn how to use bwrap instead of
libcontainer in libglnx, since the latter is a buggy copy of a subset
of the former.
Closes: #429
Approved by: jlebon
So I was trying to hack on my host's copy of rpm-ostree inside a pet
docker container, but ran into a conflict with libhif since dnf uses
it. I think we basically need to *always* build the bundled path,
rather than what I'm doing with CAHC and FADC where it's built as a
regular RPM.
It's not really sustainable right now for us to have both bundled and
not-bundled build paths - and we need to support co-installation with
dnf.
Another major issue is that we want to version lock with libhif -
right now our CI and both CAHC/FADC track libhif master, but that
means everything breaks if libhif breaks and we don't immediately
port.
git submodules solve all of these problems - the same as we're doing
with libglnx.
libglnx is *designed* for use as a git submodule, where as libhif
needs to support being both bundled and not-bundled. So we end up
with some hacks on our side, but I think it's all not too bad. I've
marked build rules with `# bundled libhif` so we know where to find
them later when libhif is stable.
Closes: #357
Approved by: jlebon
In order to make many things work, we need to run scripts. Short version:
For now, we:
- Run `%posttrans`
- Treat most `%post` as the same as `%posttrans`
- Ignore `%preun` and such since we never uninstall
Most importantly though, we start to build up an "override" list
for script handling. Currently it's just a blacklist of scripts
we don't need.
Significant work here would be needed to run Lua scripts, so far I've
been able to just skip them.
Closes: #338
Approved by: jlebon
