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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
rdgo is choking on this right now because, even though we added
`/usr/share/bash-completion` to the list of dirs to check in the spec
file[1], we don't have `bash-completion` installed in the buildroot, so
the `completionsdir` pkgconfig var isn't defined and we end up
defaulting to `/etc/bash_completion.d`.
el7's bash (not that it matters much now after #1785) is indeed new
enough to know that location. See also
https://github.com/ostreedev/ostree/pull/1083.
[1] https://src.fedoraproject.org/rpms/rpm-ostree/pull-request/30Closes: #1786
Approved by: rfairley
Let's stop actively testing on CentOS 7 from this point on. The latest
stable version v2019.2 will be the last fully supported release on this
platform. We may backport patches there if needed.
This will allow us to shed a lot of legacy and dual-paths code that
rendered the code more complex. It'll also reduce friction on new
initiatives like unified core by default and sysusers.
Closes: #1785
Approved by: cgwalters
Don't go back and forth between adding packages to the sack and marking
them for install. Do the former upfront, and then do the latter.
This allows us to work around:
https://github.com/rpm-software-management/libdnf/issues/700Closes: #1783
Approved by: cgwalters
We weren't freeing the `DnfPackage` that `dnf_sack_add_cmdline_package`
returned. But really, once it's marked for install, we don't need it.
Closes: #1783
Approved by: cgwalters
Otherwise, glib will complain if the array is empty since it can't infer
the type of the item.
While we're here, just `git grep` all instances of
`G_VARIANT_TYPE_ARRAY` and make sure they use a fully-specified format.
I added a test to sanity check that glib is happy to synthesize empty
`GVariant` arrays from `g_variant_builder()` if the format string is
specified.
Closes: #1783
Approved by: cgwalters
Not that it matters much since that function can't fail right now
(though it does have a precondition check). But this just matches what
we do elsewhere and prepares us in the event the function becomes
fallible.
Closes: #1783
Approved by: cgwalters
And this (for now at least) completes the epic journey of the
"where's the kernel"? With this it's found solely in
`/usr/lib/modules/$kver`.
There are a few reasons to do this; most prominent is that
it avoids duplicating the content as the locations may have
different SELinux labels.
Closes: #1773
Approved by: jlebon
I'd like to add a new `boot-location: modules`. In prep
for that, let's remove the legacy `both` which drops into
`/boot`.
The libostree support for handling `/usr/lib/ostree-boot` has
existed for over 4 years:
```
commit 37a059925f6b96d30190b65bee6bdde0ae1c6915
Commit: Colin Walters <walters@verbum.org>
CommitDate: Sun Nov 30 23:14:05 2014 -0500
deploy: Ensure that we can deploy using only /usr/lib/ostree-boot
```
I think we assume now that no one is now making *new* treecomposes and needs
a newer rpm-ostree and that they expect people to be able to use as an
upgrade target from a libostree that predates that.
Closes: #1773
Approved by: jlebon
The recent dep bump caused rand to jump to v0.6.5, which pulled in
`fuchsia-cprng`. Sadly, the cargo version we're frozen on chokes on it
because its manifest makes use of the `edition` keyword, which wasn't
stabilized yet.
Let's just freeze the problematic crate for now. We should be able to
bump our Rust toolchain soon-ish.
(Note this commit also does some other minor crate bumps as a result of
regenerating the lockfile to prune away `fuchsia-cprng`.)
Closes: #1777Closes: #1778
Approved by: cgwalters
Now that we support YAML, it's a gotcha/eyesore that some of our options
use underscores rather than dashes. Let's be nice and switch those few
options over, while of course still supporting the previous name.
Co-authored-by: Colin Walters <walters@verbum.org>
Closes: #1749
Approved by: cgwalters
Instead of the `Strict` and `Permissive` variants of
`TreeComposeConfig`, just collapse all the excess fields in a new
`extra` member and check for any keys there in the strict YAML path.
This will also allow us to drop the hardcoded list of architectures in
the next patch.
Closes: #1749
Approved by: cgwalters
This stand-alone file doesn't impact any part of the build process and
is designed to be a convenience for end-users.
Closes: #1499
Approved by: jlebon
Notably, the latest indicatif compiles fine again. This is now the
latest of everything, except the glib stack:
```
$ cargo outdated -R
Name Project Compat Latest Kind Platform
---- ------- ------ ------ ---- --------
gio-sys 0.7.0 --- 0.8.0 Normal ---
glib 0.6.1 --- 0.7.1 Normal ---
glib-sys 0.7.0 --- 0.8.0 Normal ---
```
because it requires a newer rustc than we're currently locked at.
Closes: #1770
Approved by: cgwalters
Minor regression from #1755. Noticed this after seeing the following in
the journal:
```
Mar 01 02:41:03 f29-ros rpm-ostree[3931]: Failed to GetConnectionUnixUser for client /org/projectatomic/rpmostree1/fedora_atomic: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name '/org/projectatomic/rpmostree1/fedora_atomic': no such name
Mar 01 02:41:03 f29-ros rpm-ostree[3931]: Failed to GetConnectionUnixProcessID for client /org/projectatomic/rpmostree1/fedora_atomic: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name '/org/projectatomic/rpmostree1/fedora_atomic': no such name
```
Closes: #1769
Approved by: cgwalters
Add a `basearch` key to the manifest. This can be used at compose time
to assert the architecture the compose is running on. Though my
motivation is for the common case where it gets omitted from the input
manifest and gets automatically added by rpm-ostree into
`/usr/share/rpm-ostree/treefile.json` for introspection on the client.
(The crucial part here is that the treefile created by rpm-ostree
remains deserializable into a `TreeComposeConfig`).
Closes: https://github.com/coreos/fedora-coreos-tracker/issues/154Closes: #1766
Approved by: cgwalters
We're really using this variable to substitute `${basearch}` and find
basearch-specific packages. Let's rename the variable to make that more
obvious.
Closes: #1766
Approved by: cgwalters
A lot of history here. Long before the YAML treefiles, I was
dissatisfied with the JSON treefile syntax, and also wanted
to create a format that could be used by the (still experimental)
`container` builtin, and chose to use GKeyFile.
I don't think that really worked out; the Rust YAML is just way
better.
In the future we probably want to more cleanly split off the
"compose only" aspects of the treefile. But for now, it's rather
tedious to pass down flags from the treefile into the keyfile/gvariant.
Let's just give direct access to the treefile to the core.
Prep for sysusers.
Closes: #1764
Approved by: jlebon
We should only be calling into GIO once we've set our preparatory
environment variables etc. Not fixing anything today that I know
of, just noticed while looking at the code.
Closes: #1763
Approved by: jlebon
This removes the "transaction monitor". Originally the idea
here was things would queue, but we never really made that
work. Since transactions started grabbing the
libostree sysroot lock in particular.
Rip out the transaction monitor code with the queue and have
a singleton txn ref in the sysroot object. This should ensure
that if a txn is active, one always gets an error message about
which one.
Next, add a 30s timeout for connections to the transaction DBus
sockets after they're complete.
This should address https://github.com/projectatomic/rpm-ostree/issues/1692
which is a case where gnome-software was leaking the txn DBus
connection and keeping it alive.
Closes: #1755
Approved by: cgwalters
There's no reason to keep this around, we aren't going to use it.
Motivation here is the lifetime of transactions is currently
entangled with the bus connections from clients, and we don't
want to hold them open unnecessarily.
Also, we were adding a notify on the wrong object. I think it
was just working before because something else ran the mainloop
and we got the property notification anyways.
Closes: #1759
Approved by: jlebon
Manually patch `file_contexts.subs_dist` so that `/home` is equivalent
to `/var/home`. This is required now that the generated homedirs rules
use `/var/home`. Otherwise, `matchpathcon` for example will return wrong
results.
This patch also includes the *removal* of `/var/home -> /home` so that
we're not dependent on this selinux-policy patch making it at the same
time as downstream:
https://src.fedoraproject.org/rpms/selinux-policy/pull-request/14
(See the conversation there for more information.)
Closes: #1754
Approved by: cgwalters
It's possible for some postprocessing scripts to affect the final
SELinux policy. This is the case for the new `/etc/default/useradd` edit
we now do (#1726), but it could've been the case beforehand too with
user scripts modifying e.g. booleans (though ideally all these
modifications would be part of RPMs).
Do a final `semodule -nB` during postprocessing so that the final policy
we commit is "up to date". Otherwise, users may only see changes take
effect if they layer packages that trigger a rebuild.
The motivation for this is specifically for `/etc/default/useradd`.
There is magic in `selinux-policy` that parses the file and generates
templated rules from the value of `HOME`.
For more info, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1669982https://src.fedoraproject.org/rpms/selinux-policy/pull-request/14Closes: #1754
Approved by: cgwalters
RPM-OSTree has been pretty good so far at consuming the exact same RPMs
used for traditional OSes without modifications. This is important,
because shielding RPMs from the OSTree abstraction means we remain
compatible with a large portion of the ecosystem.
However, there are some apps that definitely require rethinking their
approach. The example right now is akmods, which has a patch proposed to
build kmods at `%post` time on OSTree systems instead of from the
daemon.[1]
In such situations, scriptlets need something to key off of for the
OSTree-specific approach. The `/run/ostree-booted` file is the de facto
API to determine if we're running on an OSTree system or not. This patch
simply extends this API so that scriptlets can naturally make use of
them.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1667014Closes: #1750
Approved by: cgwalters
There's lots of gyrations here for unified-core vs not; it's
been broken in the case of `--unified-core` for a while I think.
In that case our workdir is tmpdir, so rename that directory.
Closes: #1743
Approved by: jlebon
Teach rpm-ostree to interpret rebases where the remote component is a
path to a local repo, e.g.:
rpm-ostree rebase /mnt/ostree/repo:my/target/ref
Essentially, the local remote in this case is considered "ephemeral".
It's kind of the equivalent of, on traditional systems:
dnf install --repofrompath repo,/path/to/repodata ...
The use case for this is in OpenShift v4, in which upgrades are done
from containers containing the OSTree commit. There, we want to point
RPM-OSTree directly at the repo in the mounted container and rebase to
the checksum.
For now, the option is marked experimental. One major reason for this is
that the way we pass the repo differs on RHEL7 vs other platforms. (See
comment block in `rpmostree-dbus-helpers.c` for details).
Related: https://github.com/openshift/machine-config-operator/issues/314
Co-authored-by: Colin Walters <walters@verbum.org>
Closes: #1732
Approved by: cgwalters
I've become quite fond of the `--changelogs` switch lately on my
Silverblue. I find it useful as a first step when nailing down a
regression, or just to peruse the churn of changes after an update.
One annoyance is that the same changelog gets printed multiple times for
each RPM that shares the same SRPM. This patch does a naive lookahead to
dedupe them. Example output:
```
NetworkManager 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-adsl 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-bluetooth 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-config-connectivity-fedora 1:1.12.6-4.fc29.noarch -> 1:1.12.6-5.fc29.noarch
NetworkManager-libnm 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-ppp 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-wifi 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-wwan 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
* Mon Jan 14 2019 Beniamino Galvani <bgalvani@redhat.com> - 1:1.12.6-5
- improve Wi-Fi PMF support (rh #1665694)
```
I say "naive" because this doesn't catch the case where a binary RPM is
named differently enough that they're not consecutive. Anyway, this
simple heuristic cleans up the output nicely.
Closes: #1738
Approved by: cgwalters
This uses the `Context` feature of the failure crate to make error
messages more useful when we fail to open a file. The difference with
`map_err` is that one can still obtain the underlying error from the
context if need be. Though surprisingly, the normal `Display` for a
`Context` doesn't include the original error, so we essentially have to
do a prefix here (see [1]).
Before:
```
error: Failed to load YAML treefile: No such file or directory (os error 2)
```
After:
```
error: Failed to load YAML treefile: Can't open file "treecompose-post.sh": No such file or directory (os error 2)
```
[1] https://github.com/rust-lang-nursery/failure/issues/182Closes: #1735
Approved by: cgwalters
These are more files that get mangled at `%configure` time. These two
new ones specifically, I tripped on while building on ppc64le for RHEL7.
See https://bugzilla.redhat.com/show_bug.cgi?id=1113618 for more info.
Closes: #1731
Approved by: cgwalters