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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
While looking at the inline help for `install`, I thought we could do
better by specifically stating that the `--uninstall` switch only
operates on layered packages. This might prevent any users from
trying to use the `--uninstall` switch on a package that is part of
the base deployment.
Closes: #1421
Approved by: jlebon
Kernel arguments added from `rpm-ostree ex kargs` can be lost
after doing multiple deploy related operations (e.g upgrade, install etc).
The root cause of that is because when doing the deployment
(ostree_sysroot_deploy_tree), the kernel arguments from the
pending deployment were never passed in.
This commit adds logic to pass in kernel arguments from pending deployment
to fix the above mentioned problem
Closes: https://github.com/projectatomic/rpm-ostree/issues/1392Closes: #1420
Approved by: cgwalters
A bunch of commands had descriptions for `--reboot` that were copied
from the `upgrade` description. Let's just make them all the same to
keep it consistent.
Closes: #1418
Approved by: cgwalters
Minor tweaks to try to clarify that the `install` and `uninstall`
commands are for managing an overlay. This should hopefully make it less
likely that someone tries `uninstall` when really they want
`override remove`.
Also drop the paragraph about having to specify NEVRAs for removing
local RPMs since that's no longer necessary.
Closes: #1418
Approved by: cgwalters
Fewer variables and avoid extra strdupv calls. I also fixed
handling of refspec canonicalization that I broke with a previous
change (we weren't actually setting `self->refspec` to the canonicalized
version).
Closes: #1414
Approved by: jlebon
I was surprised when I fired up GDB and found out that my
`etc-group-members` modifications weren't being obeyed. It turns out
serde was looking for the wrong field name. I did a quick sanity check
and found a few others.
Closes: #1417
Approved by: cgwalters
I think this is what's showing up in a PR test:
21b68a68ff.2.1529072619059542132/artifacts/vmcheck/livefs.log
```
(rpm-ostree status:17017): Json-CRITICAL **: json_gvariant_serialize: assertion 'variant != NULL' failed
```
It shouldn't be happening; let's add an assertion which will give us a core
dump reliably instead of the "stumble on" `g_warning()` default.
Closes: #1416
Approved by: jlebon
It's just all-around simpler if we only parse the vardict
and avoid exploding everything into enums/parameters. Previously
we were converting the variant into parameters and flags, and
then in most cases converting the flags back into booleans!
This should make it easier to add new parameters.
Closes: #1412
Approved by: jlebon
We are having exact same function call between rpmostree_check_groups
and rpmostree_check_passwd, which means we are ignoring all the logic
for group checking.
This commit changes the option `passwd` to FALSE to also check for groups
during compose process.
Closes: #1413
Approved by: cgwalters
Minor regression from #1382. Since we no longer always include all the
option keys, we actually need to initialize the default values now.
Closes: #1410Closes: #1411
Approved by: cgwalters
This is one part of #1387 and is prep for a single higher level command
that makes it easier to remove all customizations (layering *and*
overrides).
Closes: #1408
Approved by: cgwalters
We were also counting the `NULL` element we added at the end of the
array when appending how many local installs we were doing. Fix this by
just reading the array length before adding the `NULL` terminator.
Closes: #1407
Approved by: cgwalters
We were previously relying on `!self->revision` to determine what
message to print in the no-op case. This made `override reset --all`
also print `No upgrade available.`.
Fix this by using the stronger `is_upgrade` instead.
Closes: #1407
Approved by: cgwalters
We were labeling pure `uninstall` transactions as `install`. Tease out
that distinction. (Though if a `--install` switch is passed, then we
still just label it as `install` -- there's no difference between that
and `install --uninstall` anyway).
Closes: #1407
Approved by: cgwalters
Doing `override reset --all` may be a no-op if there are no overrides
currently applied. But we were trying to always print the tree diff
under the assumption that all override invocations have to result in a
new deployment.
Fix this by using the same default deployment check that `upgrade` does
before printing.
Closes: #1407
Approved by: cgwalters
Follow to previous change; this should make it easier to add
a new parameter. It also just makes more sense to centralize
the parsing here.
Closes: #1403
Approved by: jlebon
Subsequent patches will move it down farther; the high level
goal is to avoid touching many functions to add a parameter.
Closes: #1403
Approved by: jlebon
This fixes a painful UX issue where one must use the full NEVRA when
uninstalling a locally layered RPM. Now, one can specify either the
NEVRA or the package name only. Though we still try to interpret the
request first as a NEVRA or a capability.
Closes: #1386Closes: #1400
Approved by: cgwalters
There are a few scenarios today where one might deliver content
to a machine via an external transport. For example, take the
scenario of a single server updated via USB drive. While we
can provide a refspec...what should the remote be? (This gets
into ostree collections). There's nothing really that can
happen when typing `rpm-ostree upgrade` unless the USB stick
is plugged in. That type of scenario should be emphasized
by pinning the commit - the machine is updated via an external
script.
Another case: we're experimenting embedding OSTree commits inside OCI
containers. Here again since rpm-ostree can't understand how to
pull content from containers, it's saner to drop the refspec
bits, and pin to a commit.
Further enhancements will follow to make the admin experience more
obvious.
Closes: #1396
Approved by: jlebon
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
