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 initially wanted to include all of `epoch`, `version`, and `release`
separately in the rpmdb.pkglist metadata in case we needed them
separately. Thinking more on this, I can't think of a really good reason
to have them, so since we're not public yet, let's just encode the `evr`
as a single string.
The reason I'm revisiting this is because it took me a while to hunt
down issues when handling epoch, which turned out to be the fact that we
weren't consistently committing as big endian (i.e. we did so in the
`compose tree` case, but not the layering case), and neither were we
consistently converting back from big endian. It's doable of course, but
the added gymnastics doesn't feel justified for the gains here.
This also nicely cleans up the `RpmOstreePackage` implementation to be
leaner and faster.
Closes: #1190
Approved by: cgwalters
- Actually use separate `${test_tmpdir}` for test setup (closes a race)
- Merge stdout/stderr (more readable)
- Ensure logs are renamed to `.txt` even on failure
- Use `--progress` for some feedback
- Use `-j +1` so that even on unicore machines we get at least 2
jobs (and in general NCPUS+1)
Closes: #1188
Approved by: jlebon
I initially started this since I wanted to have the client-side
commands first, but ended up splitting them into a separate section.
Various other things:
- Update the intro
- Add jlebon to authors
Closes: #1189
Approved by: jlebon
Basically the `rpmostree_context_relabel()` call we had in the treecompose path
for unified core didn't actually have any effect as the core code did a relabel
and unset the array.
I think this may actually be a regression from: https://github.com/projectatomic/rpm-ostree/pull/1137
though I didn't verify.
Anyways looking at this, the code is a lot simpler if we change the API so that
the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we
change the public relabel API to be "force relabel" which we use in the unified
core 🌐 treecompose path.
This shrinks the jigdoRPM for FAH from 90MB to 68MB.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1172Closes: #1173
Approved by: jlebon
Compose is a slow test right now. Down the line what I'd
like to do is: https://github.com/projectatomic/papr/pull/70
Since this job can be scheduled as a container, not a VM. There's
no reason to grab a whole 8GB of RAM for it, but we *do* want multiple
CPUs. Containers do that by default.
Closes: #1187
Approved by: jlebon
This fixes a large swath of compatibility issues, for the same reasons as
overlayfs makes a lot of things Just Work. The ugly part of course is
doing hidden copyups inside the filesystem.
We've gone quite a long time with the "pure rofiles" mode, and have made changes
to various bits of userspace to be compatible with it. But what finally made me
give up on that is glibc's locale-archive; there's a patch for it that
is stalled, but even if it was applied we would still need to work with
older glibc.
This issue comes to the fore in unified core 🌐 mode, as without this
we won't get a correct locale archive.
Closes: #1171
Approved by: jlebon
Over a year later, the "opening the host rpmdb" bug is fixed,
so we can do composes in parallel ∥, hooray!
I'm dusting this off since we were running into CI (PAPR) timeouts
when I was adding more to the compose tests.
Closes: #545
Approved by: jlebon
Minor, but it was annoying me perhaps somewhat unreasonably. There's
no "overlay" going on in `ex container` runs, so let's just use the
term "installing".
Closes: #1186
Approved by: jlebon
Will be used for `compose tree --ex-output-jigdo-set`. Also probably more things
could use this. I first tried just doing another query in the higher level code
but that fails for this case as `sort_packages() reimplements
`dnf_transaction_ensure_repo_list()` which we need to get the `DnfRepo` (which
itself feels like a hack, we should be maintaining that dynamically or have a
hash accessor).
Closes: #1184
Approved by: jlebon
Ideally we'd be fixing upstream libdnf but that's a bit blocked
right now. I need these at a higher level to implement
`rpm-ostree compose tree --ex-output-jigdo-set` which needs to
link/copy the input RPMs.
Closes: #1184
Approved by: jlebon
We've had many bugs from internal helpers using `return EXIT_FAILURE` rather
than `return FALSE`. The reason we need exit codes is to handle the
`RPM_OSTREE_EXIT_UNCHANGED` case. I realized recently that we had the handy
`RpmOstreeCommandInvocation` which we can use to signal back this special case.
Then all of our functions otherwise are just normal `GError`.
One minor wart here is the two cases of "usage error" versus "command
invocation" in `main.c`, but IMO the general cleanup is well worth that.
Closes: #1169
Approved by: jlebon
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
The old branch examples use Fedora 26 which is almost EOL. The new
Fedora 27 examples show off the various `testing` and `updates`
branches, as well as the support for different arches.
Closes: #1175
Approved by: cgwalters
This is the first step towards unifying how we introspect packages from
a specific commit. We currently do this in three ways: libdnf, librpm,
and now `rpmostree.rpmdb.pkglist`. I'd like to get to a point where we
only have `rpmostree.rpmdb.pkglist` and libdnf, the latter only when
more complex queries are required.
This patch teaches the `db diff` command to make use of the new db diff
API so that it can work even on metadata-only commits. This is relevant
for use cases mentioned in #558.
I didn't get rid of the `rpmhdrs_diff` functions right now because of
the `--changelogs` option: libdnf currently does not expose this, so we
fall back to the previous API in that case. OTOH, I wonder how much it's
actually used in the wild; maybe we could just nix it?
Closes: #1162
Approved by: cgwalters
Add a function that can smartly perform diff operations on sorted
RpmOstreePackage arrays and make the db API use that. This allows us to
immediately take advantage of the benefits in a few places where diffs
are performed, including post-deployment tree diffs, and the legacy db
diff variant API. The upcoming `CachedUpdate` rework will also make use
of this (but with the notable difference of setting `allow_noent` to
`TRUE`).
Note this introduces a new `rpm_ostree_db_diff_ext` public API which has
the same interface as `rpm_ostree_db_diff` but also takes flags.
Closes: #1162
Approved by: cgwalters
In order to make use the new pkglist metadata more consummable, let's
add a function to create RpmOstreePackage arrays from it. Since some
APIs need to keep working as before, we use a `allow_noent` parameter to
distinguish between the two cases.
This is prep trying our best to make use of this metadata when possible
rather than checking out the rpmdb and initializing a `DnfSack`.
Closes: #1162
Approved by: cgwalters
Rather than letting the terminal wrap our line and go unindented on the
next line, let's do the wrapping ourselves to tidy up the output.
Closes: #1159
Approved by: cgwalters
Prep for `compose tree --ex-jigdo`; basically we want to generate the jigdoRPM
and only then set the ref to help bind the two things together. The main
thing to achieve is that if generating the jigdoRPM fails, the ref isn't
updated.
Closes: #1161
Approved by: jlebon
This is used in critical paths like pungi, so let's be sure it works;
the semantics are a bit subtle as it overrides setting the ref.
Closes: #1161
Approved by: jlebon
Basically reduce these functions to no-frills `DnfSack` utility
functions with the same implied warranty as
`rpmostree_get_matching_packages` and `rpmostree_sack_get_by_pkgname`,
which also operate directly on the sack.
These functions will be used from more places in the upcoming
auto-update patches.
Closes: #1158
Approved by: cgwalters
To make the new pkglist metadata even more usable, let's insert it
sorted. This ensures that we can bsearch the GVariant on the
client-side.
Enhance the bsearch utility function we have to deal with duplicate key
names. Although this is not the case today in rpm-ostree-managed streams
I know, some packages are allowed to have multiple versions installed,
so let's make sure we handle that deterministically by always returning
the first (earliest) version of the package.
Closes: #1158
Approved by: cgwalters
This function returned both an RpmOstreeRefsack and a pkglist bound to
the refsack. Interestingly, there were only two users of it, and one of
them didn't even make use of the pkglist functionality. Since the
lifetime semantics of this function are tricky, let's drop it and
introduce a dedicated function just for returning package lists.
I also dropped the `GCancellable` argument, since it isn't/can't easily
be used by those code paths.
Closes: #1158
Approved by: cgwalters
The new `rpmdb.pkglist` metadata is a cheap way of retrieving the set of
packages in a commit. I'd like to make use of it as much as possible vs.
checking out the rpmdb and setting up a DnfSack.
Of course, in the case of layered commits, it doesn't matter *as* much,
because a layered commit being present in the repo should mean that a
deployment is currently using it, and we should learn to reuse the rpmdb
checkout of that deployment. Though keeping it consistent across both
server and client commits makes implementing `OstreeDeployment`-agnostic
things like `db diff` more efficient too. I also plan to use this in the
upcoming auto-update code.
Closes: #1158
Approved by: cgwalters
It makes it harder to keep track of ownership except in the trivial
`_new ()` case for which they were designed (i.e. shoving straight into
another glib GVariant function that takes ownership of it right away).
Closes: #1160
Approved by: cgwalters
In the case of a rebase to a fresh remote, we want to make sure our
`OstreeRepo` picks up the new remote before we try to parse its
deployment. Otherwise, we'll error out when trying to fetch configs for
it.
This was picked up after turning on strict errors in the GPG
verification process.
Closes: #1160
Approved by: cgwalters
Prep for more work.
We actually pass a `GError` to the gpg results function and fail for any
other failures than gpg signature verification. (In that case, we want
to make sure that information gets to the D-Bus API level, so killing
the daemon would be the wrong choice).
I also factored out all the logic in
`rpmostreed_commit_generate_cached_details_variant` into a separate
function. This is prep for reusing it elsewhere.
Closes: #1160
Approved by: cgwalters
This is minor, though the list of methods we support is getting long and
will get longer. Let's just add some order to it to make it easier for
humans to parse.
Closes: #1160
Approved by: cgwalters
Prep for more work.
This also involved changing the functions from pointer return values to
`gboolean`.
I also made functions that didn't really need to be public become
private and fixed some indentation.
Closes: #1160
Approved by: cgwalters
This allows our bwrap API to really be more of a wrapper around
`GSubprocessLauncher` rather than having to hold data like the
environment itself.
Closes: #1157
Approved by: jlebon
More prep for `-Werror=undef`. Ideally we'd actually have these be defined but
that seems painful with autotools; for a later date.
Closes: #1156
Approved by: jlebon
This matches reality; I picked what's in CentOS 7 mainline today. More
importantly this also fixes a build error with `-Werror=undef` because we had a
trailing underscore `_` at the end and never noticed.
Closes: #1156
Approved by: jlebon
Minor follow-up to previous commit. It seems a bit confusing to allow
specifying `download-only` and `dry-run`. The former already includes
all the steps in the latter but goes further, as documented. Let's check
for this combination.
Closes: #1155
Approved by: cgwalters
Minor regression that crept in during the `--download-only` work. We
would download and import packages even when `--dry-run` was given.
Make sure we stop right after printing the transaction.
Related: #1128Closes: #1155
Approved by: cgwalters
We were calling the wrong completer function for `SetInitramfsState()`.
Not that it mattered much in compiled form since both ways ended up
calling the same internal gdbus function with the same arguments.
Closes: #1155
Approved by: cgwalters
This is highly dependent of the outcome of [1], though until that's
settled there, let's at least update the description to something a
little more apt. It feels more appropriate to consider rpm-ostree as a
"system manager" than just a "package manager" (which it certainly is
too of course). Also use Title Case convention which seems more popular
overall and looks nicer.
[1] https://github.com/projectatomic/rpm-ostree/issues/405Closes: #1155
Approved by: cgwalters
Minor polish item; `output_message` already prints a newline at the end.
Looks nicer without the double empty lines when refreshing metadata, and
no lines when cached.
Closes: #1155
Approved by: cgwalters
