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 were missing a bunch of flags as part of the property GType. I was
getting a warning that's become fatal because we set
`G_DEBUG=fatal-warnings` for `make vmsync`, which is how I was testing
this:
```
rpm-ostree[1813]: value "((RpmOstreeSysrootUpgraderFlags) 48)" of type 'RpmOstreeSysrootUpgraderFlags' is invalid or out of range for property 'flags' of type 'RpmOstreeSysrootUpgraderFlags'
kernel: traps: pool[1816] trap int3 ip:7f47f4b4b6d5 sp:7f47e989d1f0 error:0 in libglib-2.0.so.0.5600.1[7f47f4af9000+115000]
```
I'm not quite sure why this is happening now though, since I use
`make vmsync` a lot. My guess would be something to do with how we
changed flag passing in d568e54d from "all of them" to "only those we
need", but I didn't verify that.
Closes: #1398
Approved by: cgwalters
When I initially added support for local RPM layering (#657), I was
operating under the assumption that there is no reliable way to parse a
NEVRA back to its constituent elements. So we worked around this by
doing lookups in the pkgcache and comparing against branches converted
back to their NEVRAs, which was pretty hacky.
Later on, I learned that you *can* reliably parse a NEVRA back to its
elements because RPM forbids all fields from having a colon `:` and all
fields other than the package name to have a dash `-`. In fact, there is
a helper from `libdnf` to do exactly this.
This patch swaps out the old way of decomposing NEVRAs and converting
NEVRAs to their cache branch notation with a simpler more direct
approach using the helper function from `libdnf`.
Closes: #1395
Approved by: cgwalters
Prep for later commit.
I hesitated between `rpmostree-util.c` and `rpmostree-rpm-util.c`. In
the end, I decided on the latter since some of the functions require
rpmlib headers, which aren't currently included in `rpmostree-util.c`.
Closes: #1395
Approved by: cgwalters
I made a subtle change at the last minute with the previous PR
to use `*` for the glob instead of `.`, because the tmpdir had a `.tmp`
file I didn't want.
But - this caused us to miss the `.cargo` directory which has
the config file. And while I'd been testing builds with no network,
of course cargo was really pulling content from `~/.cargo`.
When I went to do a scratch build in Koji, that failed obviously.
I tested this makes things [work with a SRPM scratch](https://koji.fedoraproject.org/koji/taskinfo?taskID=27490830)
and in my dev container under `bwrap --unshare-net` with `mv ~/.cargo{,.orig}`.
Closes: #1394
Approved by: jlebon
We're seeing a case where the change detection apparently isn't
working; let's log the hash we got so it's easier to debug.
Closes: #1393
Approved by: jlebon
This ends up being different than what landed in librsvg (that
was imported into ostree) because in rpm-ostree we've basically
been using `git archive`-based tarball generation rather than `make dist`
for a long time. And supporting `make dist` looks like it'd get into
handling the `libdnf` bits and walking into `cmake` land so...yeah
let's not do that.
The canonical sources are in git (recursively via submodule),
except for the Rust sources, which cargo can download dynamically,
and with this patch we support glomming all of that together
into a tarball.
(And turn off `make dist` so people understand how we do it)
Tested by `make -f Makefile.dist-packaging dist-snapshot`, then
copying the resulting tarball into a container with `--net=none`
and building there.
Closes: #1391
Approved by: jlebon
Automake was warning about duplicate `clean-local` definitions, let's
do the nonrecursive automake dance.
And while I'm here, let's add some Rust unit tests that actually run
on `make check` too, since the whole unit testing bits of Rust are
awesome.
(I also tweaked the propagate bits to use the nicer `is_null()` method)
Closes: #1389
Approved by: jlebon
For now all this switch does is turn off the scary warning. We also
tweak the warning to make it clear that this will be required in a
future release.
Closes: #1378
Approved by: cgwalters
Follow-up to previous commit. Rather than allocating and destroying
RefSacks multiple times, hoist it out of those blocks so it can be
re-used.
Closes: #1378
Approved by: cgwalters
This has been a huge point of confusion for users with the new
declarative way of specifying package requests (see #1216, #1287).
Essentially, doing `rpm-ostree install glibc` will work, but it's not
very useful because we don't really expect glibc to ever go away. As a
heuristic, let's work towards forbidding package requests that would
immediately become inactive. For now, we just print a warning.
Note that this still leaves the door open for layered pkgs that e.g.
become inactive during a rebase to a tree which has it baked in, and
then active again when rebasing back; supporting this was the major
advantage of switching to a declarative approach.
Closes: #1378
Approved by: cgwalters
This breaks builds on platforms that don't have `gdbus-codegen`
installed at that path. This reverts #1153, which was needed at the
time, but things appear to be fixed now.
Closes: #1383
Approved by: cgwalters
This adds some additional help to the man page and the RTD page around
using local packages with the install/uninstall commands.
Closes: #1388
Approved by: cgwalters
Let's modernize and start supporting YAML treefiles. I'll dare make the
sweeping generalization that most people would prefer reading and
writing YAML over JSON.
This takes bits from coreos-assembler[1] that know how to serialize a
YAML file and spit it back out as a JSON and makes it into a shared lib
that we can link against. We could use this eventually for JSON inputs
as well to force a validation check before composing.
If we go this route, we could then turn on `--enable-rust` in FAHC for
now and drop the duplicate code in coreos-assembler.
[1] https://github.com/cgwalters/coreos-assemblerCloses: #1377
Approved by: cgwalters
I was honestly surprised to see this test was running all this time for
CentOS. As cool as it is, this test is really more meant for Fedora.
Closes: #1382
Approved by: jlebon
In the middle of adding yet another parameter to
`rpmostree_get_options_variant`, it dawned upon me that we weren't
gaining much from making it its own function. Just generating the
GVariant inline seems much cleaner since (1) we only actually have to
insert keys for values we want to specify, rather than always specifying
default `FALSE` values, and (2) the fact that the key name is right
there makes it self-documenting and thus doesn't require a bunch of
comments on the side.
Closes: #1382
Approved by: jlebon
We were trying to test that doing `override remove` on a layered package
errored out. But the test was bogus since `foo` is a base package here.
Let's just use a brand new package that will actually be layered.
Closes: #1382
Approved by: jlebon
Just part of the continuing breakdown of our testsuites into smaller
pieces for more efficient allocation.
Will add a test case to the `layering-basic-2.sh` in a follow-up commit.
Closes: #1382
Approved by: jlebon
Seeing a 404 in the CentOS build for some reason...something like
older versions of git not following redirects maybe?
Update submodule: libglnx
Closes: #1374
Approved by: jlebon
With the new support for pinning deployments, we need to also update
rpm-ostree to clean up the transient state as is now done in the ostree
sysroot upgrader.
This addresses that issue as well as tries to be a little cleaner in how
we clean up other transient state. Notably, we add a new helper function
to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In
other cases, we do want this transient information since it allows us to
describe the deployment.
Closes: https://github.com/ostreedev/ostree/issues/1595Closes: #1372
Approved by: cgwalters
This makes the logs a bit more useful, but the ultimate goal
here is to write the originating client `id` to the cached update
data, so users know that e.g. `gnome-software` triggered it.
Closes: #1368
Approved by: jlebon
The high level goal is to render in a better way what caused an
update: https://github.com/projectatomic/rpm-ostree/issues/247#issuecomment-386615707
This gets us for Cockpit:
`Initiated txn DownloadUpdateRpmDiff for client(dbus:1.28 unit:session-6.scope uid:0): /org/projectatomic/rpmostree1/fedora_atomic`
which isn't as good as I'd hoped; I was thinking we'd get `cockpit.service`
but actually Cockpit does invocations as a real login for good reason.
We get a similar result from the CLI.
Closes: #1368
Approved by: jlebon
This started out as an experiment to see how useful it'd be in
rpm-ostree. Again, the goal wasn't to leverage the rpm-ostree-specific
tests of a-h-t here, but rather running the *other* tests to ensure that
we weren't inadvertedly impacting userspace. In the end, as far as I
remember, it hasn't brought up anything since adding it here, so let's
bring the experiment to an end.
It might still be worth doing this same experiment in the ostree CI
instead, though I don't want to add more load there until we fully
switch over to the new CI infra.
Closes: #1369
Approved by: cgwalters
Following up to https://github.com/projectatomic/rpm-ostree/pull/1352
AKA 506910d930
which added an experimental flag to globally enable deployment
staging, let's add an `ex-stage` automatic update policy.
I chose to create a new `test-autoupdate-stage.sh` and rename
the previous one to `test-autoupdate-check.sh` in going with
the previous theme of smaller test files; it's
way faster to iterate on new tests when it's a new file. And adding
staging at the top would have been weird.
This was all quite straightforward, just plumbing through lots
of layers.
Closes: #1321
Approved by: jlebon
We are hitting issues with a-h-t on CAHC right now failing due to an
`atomic scan` issue and preventing promotion of continuous content to
the smoketested branch. This is then blocking our CI which needs a newer
tree with the latest glib2 baked in. Let's unblock our CI for now by
rebasing on the continuous branch. We'll drop that hack once the a-h-t
issues are ironed out.
Closes: #1365
Approved by: cgwalters
The common case is having layered packages and no overrides; seeing
`Applying 8 overlays` then `Building filesystem [0/8]` is redundant.
Tweak the progress to avoid the double message. Also change the terminology
to clarify that each item is a package.
Also update libglnx to pull in progress bar newline fix.
Update submodule: libglnx
Closes: #1363
Approved by: jlebon
The `status --verbose` output is getting quite long now that we print
repo information and diffs. Let's add a switch for only making
advisories more verbose so that it's easy to get more information
without having to use `-v` and scroll up if the diff is massive.
Closes: #1350
Approved by: cgwalters
Follow-up from #1344.
In the case where a cached update is created from an `upgrade` operation
(and soon, "stage" auto-update policy runs), we can just print the diff
and advisory info together with the pending deployment. This makes the
output look much more natural.
Closes: #1350
Approved by: cgwalters
In #1344, we changed `upgrade` to always write the cached update. One
thing I hadn't noticed was that with pkglayering, loading the sack twice
meant we printed all that gory repo info twice.
Really, the much nicer thing to do is just to make an effort to try to
*keep* the original sack that the core used so that we skip all that
overhead completely.
Closes: #1357
Approved by: cgwalters
It just makes the sack more useful for other purposes this way. Callers
can just use `download_metadata` directly if they'd like to override
this. Prep for a follow-up patch.
Closes: #1357
Approved by: cgwalters
Prep for printing this info as part of the deployments. I also snuck in
a small fix so that we don't print the `Diff:` line if there's no diff
(e.g. it's a no-op update).
Closes: #1357
Approved by: cgwalters
In https://github.com/cockpit-project/cockpit/pull/9090#issuecomment-386564044
we're seeing:
`Txn DownloadUpdateRpmDiff ... failed: open(O_TMPFILE): No such file or directory`
Looking at the error paths in the rpmdb diff code, there's not really
any error prefixing. Let's add some so this is easier to debug.
Closes: #1356
Approved by: jlebon
This now works after https://github.com/ostreedev/ostree/pull/1570
However, I was hitting an issue with the temp httpd running the
tests serially, let's split them up.
Really the only sane thing is to run each of these tests in a fresh
VM; we'll do the VM-in-container pattern here hopefully soon.
Closes: #1355
Approved by: jlebon
I was hitting an error during sysroot loading while playing
with deployment staging, and it wasn't initially
clear which phase was causing it (a client-initated reload versus
one we do before or after deploying). Add some error prefixing.
Closes: #1355
Approved by: jlebon
Now that infrastructure for this has landed in libostree,
let's make it easy for people to opt-in to testing it. This is a distinct first
step for adding it as an update policy.
Closes: #1352
Approved by: jlebon
Since we unified the pkgcache repo in 7056e6b726
there's no longer a reason to perform two repository prunes.
Change things so that the first phase is regenerating all of the
refs (in a single libostree txn), then perform a single prune.
This is preparation for reworking how we do prunes, which is
going to be useful for staged deployments.
Closes: #1351
Approved by: jlebon
Right now, cached updates generated during "check" policy runs are
completely decoupled from upgrade operations. This can lead
to the surprising situation where the "Available update" is *older* than
a freshly deployed pending tree with `rpm-ostree upgrade`.
We should just generate a cached update after upgrade operations. This
is also prep for staged deployments, where we'll want to do this as
well.
Note that we write out the cached update here even if automatic updates
are turned off since it's essentially free. I've been thinking about
always displaying that information after an `rpm-ostree upgrade` in
`status`. Though not sure if we should keep it in a separate "Available
update" section, or somehow morph it as part of the pending deployment
output.
Closes: #1344
Approved by: cgwalters
