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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Right now there's an issue in Fedora with `g-ir-scanner` picking up
`-fstack-clash-protection` from the `sysconfig` Python module and
passing it to `clang`, which doesn't understand this flag yet.
Just work around this by (1) not even building GIR bindings for our
bundled libdnf since there's no need, and (2) overridding the compiler
used by `g-ir-scanner` so it's always `gcc`.
See: https://github.com/projectatomic/rpm-ostree/pull/1787#issuecomment-473971585Closes: #1787
Approved by: cgwalters
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
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
Let's make use of the GitHub release feature to make it more prominent
on the "Releases" tab, but more importantly so that we can attach
vendored tarballs for downstreams. E.g. this will allow us to have a
correct `Source0` field in the Fedora spec file.
Related: #1683Closes: #1684
Approved by: rfairley
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
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
This removes the logic around supporting opting out of the staging
feature. We don't want to support multiple configurations here, and at
this point, staging should be considered stable.
Closes: #1546
Approved by: cgwalters
https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
broke our build, since Rust doesn't yet have a way to express
the fact that the static library has dynamic dependencies.
(AIUI this is actually something libtool can handle with `.la` but eh)
Closes: #1522
Approved by: cgwalters
It seems like `4.14.2-rc1` orders later than `4.14.2`, which is causing
issues in f28 builds.
Also print the version of librpm at configure time.
Closes: #1515
Approved by: cgwalters
This teaches the client to fetch packages from URLs directly so that one
doesn't have to `curl` first and then install. Supported anywhere
package filenames are allowed (notably: `install` and
`override replace`).
One neat things about this is that we download the file into an
`O_TMPFILE` and then pass on ownership of that fd directly to the
daemon. So at no point are the packages actually laying visible on the
system. (Assuming the filesystem supports `O_TMPFILE` that is).
This adds direct linking to libcurl and openssl, two libraries which we
were already pulling in indirectly.
Closes: #1508
Approved by: cgwalters
When building in `debug` mode, `RUST_DEBUG` was still turned off because
`rust_debug_release` was set to `yes`, not `debug`.
Fix this by tweaking how `--enable-rust-debug` works: when it's *not*
provided, we default to the `$CFLAGS` detection logic. Otherwise, it
overrides it.
Closes: #1514
Approved by: cgwalters
As something that manages your base operating system, we care
about reliability, predictability, as well as performance and
low-level access to native operating system facilities. The
C programming language is great for the latter two, but fails
at providing a truly memory-safe environment. Rust is fairly
unique in providing a language that doesn't carry a runtime,
so we can gradually "oxidize" and convert our C code without
imposing additional overhead. It's also got a lot of modern
design niceties, like not having a null pointer.
Let's pull the trigger here and hard require Rust. It's the
programming language I personally want to be primarily writing in for
years to come.
This is also in line with a recent trend of reducing our
experimental/optional matrix.
Closes: #1509
Approved by: jlebon
We've put a lot of work into staged deployments, it's time
to pull the trigger and turn them on by default. This is
a key step for enabling `stage` mode automatic updates by
default in e.g. Fedora CoreOS/Silverblue.
We add a new `--disable-staged` build-time option to flip
things back.
Closes: #1430
Approved by: jlebon
Newer librpm defaults to doing a full payload checksum, which we can't
do at this point (writing the db) because we imported the RPMs into
ostree commits, saving just the header in metadata - we don't have the
exact original content to provide again.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1607223Closes: #1469
Approved by: jlebon
This entirely drops out Sphinx as well as python-devel from our
builds, makes builds faster, and silences a lot of warnings too.
Update submodule: libdnf
Closes: #1480
Approved by: jlebon
Skip building man pages and HTML docs for our embedded libdnf to speed
up builds.
This bump also pulls in a fix to ensure we never try to install src
packages from `dnf_context_install()`.
See: https://github.com/projectatomic/libdnf/pull/3
Update submodule: libdnf
Closes: #1463
Approved by: jlebon
Probably at some point libdnf will drop py2 support, but the
main reason I'm doing this is avoids a python2 dependency
for rpm-ostree for distributions that don't want that.
Note of course rpm-ostree itself doesn't use python, libdnf does.
And only for the python bindings, which we don't use either. So
this is mostly just to DTRT automatically for the libdnf bits; down
the line we could probably add a patch to make the python fully
conditional.
Closes: #1460
Approved by: jlebon
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 prefer to use `-Og` rather than `-O0` in debug mode. Notably, it shuts
up `_FORTIFY_SOURCE` warnings which require *some* optimizations turned
on.
Closes: #1284
Approved by: cgwalters
Bugfix release to fix minor performance regression from auto-updates
work. Plus a low-risk enhancement to `status` to print only the booted
deployment with `--booted`.
Also minor refresh of release workflow documentation.
Closes: #1262
Approved by: cgwalters
We have lots of goodies in the bag worthy of a release. More rojig
improvements, initial auto-updates support, and many fixes.
Closes: #1258
Approved by: cgwalters
Amazingly things seemed to stumble on from here, but this
started actively breaking when I was trying to change the code below.
It took me a while to realize it wasn't my changes introducing
the error message 😭.
Also indent so it's clearer where the conditional ends.
Closes: #1213
Approved by: jlebon
We previously added a projectatomic/libdnf fork. I just pushed an
`rpmostree-branch` to there with one PR on top. This is an unfortunate turn but
the C++ thing still needs to be worked out.
Obviously we don't want a permanent fork, but I find it hard to justify spending
a whole lot of time pitching in to help with the libdnf C++ conversion versus
all the other work I could be doing.
Update submodule: libdnf
Closes: #1114
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
Now that we have the jigdoset in `Requires`, let's make a hard
switch to using it and drop the jigdoset from the jigdoRPM data.
One lingering concern here is that the `Requires` are not quite
as strict as what we had before; for example one apparently can't
add a `Requires:` that refers to an architecture (x86_64 vs noarch).
And a lot more strongly than that we had the repodata checksums
in the old format. I'm still thinking of a way to use those.
But moving on, this allows us to rework the client side to do a lot more
up-front calculation before downloading the jigdoRPM. In the spirit of that, at
the same time let's add a `Provides: rpmostree-jigdo-commit(e7bdb7443d8...)` so
that we can determine ahead of time whether or not we have the actual commit.
A major change we could now take would be to download the jigdoRPM
in parallel with the jigdo set, but doing that would require
driving a lot more of the jigdo logic into the core; it'd need
to know to specially handle the jigdoRPM download.
Closes: #1140
Approved by: jlebon
There's a lot more details in the libostree PR:
https://github.com/ostreedev/ostree/pull/1357
Basically loading the xattrs is slow; let's only do it if we need to, and "need
to" is defined by "SELinux policy changed". On my test F27AH VM, the difference
between a stat() + hash table lookup versus the full xattr load on my test case
of rpm-ostree install ./tree-1.7.0-10.fc27.x86_64.rpm is absolutely dramatic;
consistently on the order of 10s without this support, and <1s with (800ms).
Closes: #1123
Approved by: jlebon
Now that there's a new libostree out, let's cut one here too, since we have a
fair bit accumulated, and I think it'd be good to have the oustanding kargs PR
to soak in master for a bit after landing.
Closes: #1080
Approved by: jlebon
File triggers are a post-RHEL7 thing; more information at
http://rpm.org/user_doc/file_triggers.html
There are two notable users I've been testing this with;
`glib2` and `vagrant`. The `vagrant` one is more immediately urgent,
since it makes `vagrant-libvirt` work, which I currently rely on
for my workstation dev.
I've tested things successfully with `vagrant`, and I did verify that we run the
`glib2` ones when doing `rpm-ostree ex container`.
Long term, more transaction file triggers are likely to live in
"base" packages like `glib2`. We don't implement those yet, but
extending this to do that shouldn't be too hard.
There was *significant* what I'd call reverse engineering of the
implementation in librpm. The file triggers code there is spread out
and abstracted in a few different places in the code. I found
trying to understand what header values were involved to be quite
tricky.
There are some corner cases like multiple patterns that I *think*
this does correctly, but could use more validation. The main
question I had was - is it required that the patterns for e.g.
`%transfiletriggerin` and `%transfiletriggerun` be identical?
Closes: https://github.com/projectatomic/rpm-ostree/issues/648Closes: #869
Approved by: jlebon
The version checking function in particular is really useful for people doing
`from gi.repository import RpmOstree`, which we'd like at least some things like
Anaconda and Pungi to do.
Closes: #891
Approved by: jlebon
For https://pagure.io/atomic-wg/issue/299 we need to make it
more convenient to substitute the architecture in an installation
context. I plan to use this API inside `rpmostreepayload` in Anaconda,
so we can substitute the same value of `${basearch}` we use in treefiles
since https://github.com/projectatomic/rpm-ostree/pull/305
Now, you might wonder - why do we need an API wrapping libdnf? It's because
libdnf is not API stable yet. We're just exposing a tiny subset. In theory we
could use the Python dnf bindings in Anaconda, but things get slightly weird if
rpmostreepayload depends on dnf. Perhaps we'll do that down the road, but for
now this a small API surface to maintain (forever).
This change reworks the internal `varsubst` bits to take a pure `DnfContext`,
since we don't want to spin up a whole `RpmOstreeContext` just to do some
string substitutions.
Closes: #877
Approved by: jlebon
