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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Now that we have `CUtf8`, let's just store the serialized JSON
as a string, owned by the Rust side. This way we can drop the
`serialized_treefile` buffer we were passing around and simplify
various bits of code. Most notably, we only serialize the JSON
once (via Serde) rather than also doing it again in the C side.
Closes: #1600
Approved by: jlebon
In preparation for running in default Docker permissions where
we can `chroot()` and `makedev()` but not e.g. create bind mounts,
move `/usr/etc` to `/etc` when running scripts.
The script processing is also entangled with our passwd/group
file handling, so change those functions called from the core too.
It's tempting to basically maintain `/usr/etc` as `/etc` all
the way from immediately after checkout to just before commit.
We can't change how we do imports now; perhaps importing
RPMs into ostree as `usr/etc` was just a mistake in retrospect,
but oh well.
Closes: #1592
Approved by: jlebon
Split out of supporting "pure rojig" work. We also want
to support this for doing "oscontainers" as is planned for
Red Hat CoreOS. The user experience in both cases is oriented
around versioning of the external wrapper, not the inner ref/commit.
Note for users/builders who want to make use of this feature:
You probably want to mirror the changes in our test suite here to
use the compose JSON and parse the resulting `ostree-commit` out of that.
Closes: #1603
Approved by: jlebon
This follows up to https://github.com/projectatomic/rpm-ostree/pull/1576
AKA commit 2e567840ca - we now process
treefile inheritance in Rust code. Previously for elements which
reference external files (`postprocess-script` and `add-files`)
we'd hardcoded things to only look in the first context dir.
Now we open file descriptors in the Rust side for these "externals"
as we're parsing, and load them C side. Hence we'll correctly handle
a `postprocess-script` from an included config.
Other advantages are that the include handling was ugly un-typesafe C code
with no unit tests, now it's memory safe Rust with unit tests.
The downside here is I ended up spelling out the list of fields
again - there's probably a way to unify this via macros but
for now I think this is OK.
Closes: #1574
Approved by: jlebon
It still takes a noticeable amount of time to stage a deployment, so
just give some feedback so we don't just hang there.
Closes: #1594
Approved by: cgwalters
Noticed these while perusing the codebase. We don't do anything in those
handlers, and they're optional, so just nix them.
Closes: #1594
Approved by: cgwalters
Make sure we can open and query the rpmdb when creating new deployments.
This should help filter out cases where somehow librpm failed to
actually write the rpmdb but didn't error out.
This requires splitting the sanity checking in two so that we still get
that nice error first on scripts that do `rm -rf`.
See: #1566Closes: #1584
Approved by: cgwalters
We want to use the host repos not just for downloading the packages
we'll compose trees with, but also for the rpm-ostree build itself
leading up to the tests.
Closes: #1585
Approved by: jlebon
I often am editing just the Rust code, and want the fast iteration
feedback of a `cargo test` - don't want to pay the cost of full
optimization (particularly LTO) for the release build, and I
*just* want to run the Rust tests.
Basically if you're editing our Rust code a lot, this target is
your friend.
Closes: #1585
Approved by: jlebon
Following on to the previous change which added an explicit bind
mount API and also removed the API to append bwrap arguments, let's
also change the constructor to disallow the latter.
There was just one non-bind-mount argument being used
for "ro /var + tmpfs /var/tmp" - change that to an explicit new
API.
Looking at all of this, perhaps what we really want is to move
the "mutability" for `/var` underneath our API too, but let's
do this smaller incremental step first.
Closes: #1593
Approved by: jlebon
This is prep for adding a "backend" to this that uses just plain
`chroot` - we want things to avoid talking to bwrap's commandline
directly.
Closes: #1590
Approved by: jlebon
While debugging test failures in #1584, I was perplexed to find that the
ex-container tests didn't work on current git master. It turns out we
were only checking for one of the two possible error codes in the case
where we rename to a non-empty dir. So why is CI getting `EEXIST` while
locally I get `ENOTEMPTY`? Doing some diving kernel-side revealed it's
due to xfs vs tmpfs.
Closes: #1589
Approved by: cgwalters
The advantage of this over CStr is that Rust knows it's UTF-8
too. I also tweaked our path code to use String, and only
view it as a `Path`. This avoids having to `unwrap()` later
back to a `str`.
Closes: #1588
Approved by: jlebon
Today I was trying to use gdb and noticed my libdnf build didn't
have debuginfo. Now, I thought that's what `-DCMAKE_BUILD_TYPE=RelWithDebugInfo`
was doing but...I have no idea right now where I got that.
I looked at RPM builds, and the way this works is it exports CXXFLAGS.
Now for our C code, our defaults actually come from Autoconf. Let's
do the beautiful hack of telling Autoconf we're going to use C++ so
it sets `CXXFLAGS` for us.
Closes: #1586
Approved by: jlebon
It's really an array of pairs. Tripped over this while working
on the pure-Rust treefile parsing on the `misc-tweaks` compose test.
Closes: #1581
Approved by: jlebon
This is analogous to commit c62058e548
which propagated `V=1` into `cmake`. Except if the build *isn't*
verbose (for local development), let's not force `--verbose` on
for Rust.
Closes: #1583
Approved by: jlebon
Prep for moving more of our parsing into Rust. The main
thing here is that for JSON, we need to continue to ignore
unknown fields. It took me a little while but I eventually
figured out that using `#[serde(flatten)]` works for this.
Seriously: serde is freaking amazingly awesome.
Closes: #1580
Approved by: jlebon
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
Drop the `rpmostree.rpmdb.pkglist` keys from the deployment metadata
since users shouldn't need it and it greatly increases the size of the
output.
Closes: #1577
Approved by: cgwalters
In `--unified-core` mode, we would segfault if `selinux: true`
but no policy was found.
I hit this while hacking up the manifest for some Red Hat CoreOS
work.
Closes: #1578
Approved by: jlebon
The core bug here is that previously if we had multiple YAML files
in include, we ended up overwriting self->treefile_rs for the
last one. Handling inheritance worked, but it broke rojig since
we generate the specfile Rust side.
Let's have first-one-wins semantics for now. I have a bigger
fix incoming in https://github.com/projectatomic/rpm-ostree/pull/1574Closes: #1576
Approved by: jlebon
Currently `compose tree` supports writing to both an OSTree
repository and optionally simultaneously generating a rojig
RPM or rojig set.
We are instead going to split off a separate `compose rojig` verb,
since we want to support a "pure rojig" mode, and having all
3 options would make this code far too complex.
For now anyone who wants *both* formats can use `compose tree` then
follow up with `ex commit2rojig`.
This is also inline with the new coreos-assembler push, where
we'll treat `rpm-ostree compose` as more of a "low level" API,
and wrap it in a more opinionated model there.
Closes: #1570
Approved by: jlebon
In coreos-assembler I want to sort our builds by timestamp,
and having the ostree timestamp in the metadata is convenient.
Closes: #1569
Approved by: jlebon
Often, after rebooting from an upgrade, I want to check what was just
updated. This patch makes `db diff` do the right thing in those cases.
Specifically, before `db diff` without arguments would default to
diff'ing the pending deployment with the booted deployment and error out
otherwise. This patch extends the logic so that if there's a rollback
deployment, we default to diff'ing against that.
Closes: #1565
Approved by: cgwalters
Factor out a function for reading checksums from deployments and
printing their diffs. Also slightly rework the error-handling logic.
Prep for next commit.
Closes: #1565
Approved by: cgwalters
By the way `ostree_sysroot_query_deployments_for()` is defined, the
pending deployment is never the same as the booted deployment, so drop
that redundant check.
Closes: #1565
Approved by: cgwalters
Prep for adding a new toplevel rojig command. It's also just
cleaner to avoid cluttering up the main compose logic with
distractions like the `_legacy_prep_dev()` bits.
Closes: #1564
Approved by: jlebon
This completes the removal of externally-provided rojig spec files.
In the current flow then `compose tree --ex-rojig-output-*` will
end up parsing the manifest twice. But this is prep for defaulting
rojig to "pure" mode without a separate ostree repo. Then
anyone who wants to do both can run `commit2rojig` after.
Closes: #1561
Approved by: jlebon
This is prep for fully dropping the separate spec file, which
is now just used by `commit2rojig`.
A compose test can now specify it wants YAML instead of JSON.
Closes: #1561
Approved by: jlebon
Our trick of using layered commits as base commit updates doesn't jive
well with the new opportunistic reuse of the base rpmdb. The issue is
that a layered commit includes the rpmdb of *its* base commit at the
`/usr/lib/sysimage` location. So to convert it into a proper base commit
means that the layered rpmdb should move there.
Closes: #1502
Approved by: cgwalters
Check if we can reuse the base rpmdb from the pending deployment if it
matches the base rev we're targeting. This allows us to avoid checking
out the tree early only to later on discard it. Such cases include
layering existing packages and inactive requests.
Closes: #1502
Approved by: cgwalters
Apparently I was just totally confused into thinking `OsStr`
was `NUL` terminated. I don't know where I got that idea
but a quick inspection of the Rust source code makes this
clear. I may submit a PR to the docs.
So we have two choices: allocate, or internally use a `NUL`-terminated
type. Let's just use `Box<CStr>` internally. Note I chose that
over `CString` as the latter is theoretically mutable, and when
passing data back over to C we don't have ownership/mutability
guarantees.
Closes: #1563
Approved by: jlebon
For local development, I want to be able to e.g. update `Cargo.toml`
or switch branches and not have to `rm -rf target`.
Let's tweak the logic here so we only pass `--frozen` if the ownership
of the dir is different.
Probably an even better fix would be to just error out, but
this is a conservative tweak.
Closes: #1563
Approved by: jlebon
Prep for another patch. Some callers will need to know whether some
layers contain certain fixes before proceeding. We already have that
information handy so just expose it.
We should probably do something about that massive argument list... will
return to that at some point. But at least with the new base layer
accessor from the previous patch, there aren't many callers affected by
the added argument.
Closes: #1560
Approved by: cgwalters
In the majority of cases, we just want to know if a deployment is
layered and what the base commit is. Make a simpler accessor for this.
We can further simplify the logic on the client side here by relying on
the fact that there is only a base layer iif we're layered, so we don't
need two output variables.
I find it also makes things much easier to grok in some places, e.g. in
`rpmostreed-deployment-utils.c`, we now have:
const char *current_base_checksum = current_base_checksum_owned ?: current_checksum;
which better crystallizes what we want to get at.
Or e.g. in the sysroot upgrader, we can drop a comment which states
something that is now completely obvious.
Closes: #1560
Approved by: cgwalters
We only want to copy our own rpmdb to the base rpmdb location in the
server-side paths. OTOH, when creating layered commits client-side, we
want to make sure that we *don't* touch the base rpmdb location.
Accordingly, move the logic that does the hardlinking into
`postprocess_final`.
This can cause issues if we want to make use of the base rpmdb (as in a
forthcoming patch) of commits that were not created by a recent enough
rpm-ostree which inject the base rpmdb. When layering on such base
commits, we would unwittingly copy the new rpmdb (with the layered
packages) into the base rpmdb location. This then of course throws off
any logic that assumes the rpmdb at that location is from the base
layer.
There's a slight compatibility issue here: there are still older layered
commits out there where we did this and which might throw off new logic
that relies on this. We bump the clientlayer version so that we can just
check for that version to know whether it's safe to use the base rpmdb.
Closes: #1560
Approved by: cgwalters
I'm going to add a new user soon. This should probably
be a best practice.
Ideally...cbindgen would have a way to add some wrapper bits
around any types it defines or something?
Closes: #1559
Approved by: jlebon
