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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
This allows non-root users access to the rpm-ostree daemon, which is
a pre-requirement for gnome-software rpm-ostree support.
Closes: #745Closes: #825
Approved by: cgwalters
Starting from v4.12, rpmteFI has been deprecated in favour of
rpmteFiles. Make use of it if we can, otherwise fall back to the older
API.
Closes: #824
Approved by: cgwalters
A very minor release, but better than backporting more patches. This rolls in
the `RegisterClient` fix as non-root, plus the arm32 crasher.
The syscore refactoring is the only risky part, but I'm pretty confident in it.
Closes: #757
Approved by: jlebon
This is preparatory for future changes which will make use the newer sysroot
writing API. But in this change, we can drop all of our version ifdef'd code.
Closes: #740
Approved by: jlebon
The equivalent of https://github.com/ostreedev/ostree/pull/718
but for this codebase.
I just picked one example at random, there's plenty of others, but I don't want
to do any kind of tree-wide conversion since we have lots of outstanding
patches.
Closes: #664
Approved by: jlebon
This release includes a fix for [CVE-2017-2623](https://bugzilla.redhat.com/show_bug.cgi?id=1422157).
There are a few new features, such as `systemctl reload rpm-ostreed` now being
supported. Some bugfixes such as memory leak fixes. Besides that, there's a lot
of internal refactoring going on in preparation for work on local RPM
installation.
Closes: #663
Approved by: jlebon
This notably fixes the spam of transaction warnings. Due to a libdnf
build system improvement, we no longer need to manually propagate
`CFLAGS`.
Closes: #499
Approved by: jlebon
See https://github.com/projectatomic/rpm-ostree/issues/405
This patch adds an (off by default) `--enable-new-name` build option
which currently defaults to `nts`. This is purely additive, and
the intention is that we'll support the rpm-ostree name in
perpetuity most likely.
At the moment, we add a new name for:
- /usr/bin/$name
- The systemd unit file
But we notably *don't* attempt to add a new name to the DBus API,
as it'd be a lot more invasive of a patch, and less payoff (it's
mostly just programs/scripts that interact with the DBus).
Closes: #497
Approved by: jlebon
So that it's easier to build bubblewrap as `Source1` in an RPM
embedded (flatpak is using a git submodule, but for this I think
`Source1` is better).
Closes: #384
Approved by: jlebon
So I was trying to hack on my host's copy of rpm-ostree inside a pet
docker container, but ran into a conflict with libhif since dnf uses
it. I think we basically need to *always* build the bundled path,
rather than what I'm doing with CAHC and FADC where it's built as a
regular RPM.
It's not really sustainable right now for us to have both bundled and
not-bundled build paths - and we need to support co-installation with
dnf.
Another major issue is that we want to version lock with libhif -
right now our CI and both CAHC/FADC track libhif master, but that
means everything breaks if libhif breaks and we don't immediately
port.
git submodules solve all of these problems - the same as we're doing
with libglnx.
libglnx is *designed* for use as a git submodule, where as libhif
needs to support being both bundled and not-bundled. So we end up
with some hacks on our side, but I think it's all not too bad. I've
marked build rules with `# bundled libhif` so we know where to find
them later when libhif is stable.
Closes: #357
Approved by: jlebon
In order to make many things work, we need to run scripts. Short version:
For now, we:
- Run `%posttrans`
- Treat most `%post` as the same as `%posttrans`
- Ignore `%preun` and such since we never uninstall
Most importantly though, we start to build up an "override" list
for script handling. Currently it's just a blacklist of scripts
we don't need.
Significant work here would be needed to run Lua scripts, so far I've
been able to just skip them.
Closes: #338
Approved by: jlebon
This follows the pattern used by e.g. glib. If people (commonly
embedded systems) don't want docs, we should support that.
Pull request: #235
Approved by: jlebon
This is in preparation for `rpm-ostree container`, which handles
unpacking RPMs as non-root.
At the moment, I'm copying code in from both ostree's libarchive bits
(fixable...may need to export some utility functions) and some
functions from libhif (harder, see:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-January/000297.html )
There's lots more cleanup to do here, but I don't want to block on the
resolution of the libhif changes.
For some reason my CD builder didn't trigger this, but we do actually
need `-larchive` (and we want to have the dependency metadata so
packagers know to BuildDepends on it).
During autoreconf, automake would emit many warnings regarding the
option 'subdir-objects' being disabled. We squash those warnings by
enabling the option.
We also fix Makefile.am so that it includes the patched libglnx Makefile
rather than the original one, which would cause libglnx output to be
placed in the literal dir './$(libglnx_srcpath)'.
We noticed that tree composes failed with a missing `atomic` package,
when really what happend is Fedora 22 was released and the repo
metadata moved from `development/` to `released/`.
See https://github.com/hughsie/libhif/pull/47
This will help build release engineering and other types of tools;
for example, rather than parsing the output of `db diff`, one
should be able to call an API.
Initially, this adds the generic infrastructure for a public shared
library, with a new function call to do the equivalent of `rpm -qa` on
a particular OSTree commit.
Closes: https://github.com/projectatomic/rpm-ostree/issues/117
Closes: https://github.com/projectatomic/rpm-ostree/pull/124
There are a lot of advantages to this. See the linked issue
for more details, but briefly:
- Lays the groundwork for package layering
- Better caching (exit compose after depsolve if no changes)
- Better error handling
- Potential for unprivileged package downloads
- Potential to better containerize installs
TODO:
- langs handling
- progress output
Closes: https://github.com/projectatomic/rpm-ostree/issues/53
This matches recent work in OSTree to use *at() - it's faster and less
prone to error. In the case of directories which are mutable by
processes in different security domains, it's more secure too. (That's
not the case here though).
These files were taken from json-glib, around the era of this commit:
https://git.gnome.org/browse/json-glib/tree/build/autotools?id=2779d537492f1902d71cf648631238110b62b311
Unfortunately, this involved hacking it up a bit:
- I couldn't easily use `nobase` for the data, so I deleted that.
Test data goes in the installed-tests dir.
- Delete duplicated predeclared variables; we're using nonrecursive
make.
- Ensure we run each test in its own tmpdir
Remove redundant function _rpmostree_pull_progress().
Bumped ostree requirement to 2014.13, but this isn't quite right because
we actually need (unreleased) 2014.14. Post-release version bumps would
be useful here.
I was looking again at using hawkey/librepo, and realized just how
much I'd have to fight all of these libraries to avoid affecting
the running system.
What we really want to do with librepo/hawkey is run them effectively
unprivileged, and to hide the system's RPM database from them. This
is a baby step towards that, by confining our existing yum.
- /usr, /etc, and /var/lib/rpm are mounted read-only
- yum is now run under CLONE_NEWPID, to avoid stray %post scripts
affecting system processes
"atomic rebase" is mostly a copy of "ostree admin switch", so let's
also pick up the changes in ostree admin switch for the new
unconfigured state flag.
This allows a user to "atomic rebase" on an unconfigured system.
Related: #31
Some downstreams want the ability to separate the compose tooling from
the client, for e.g. support reasons.
This approach supports generating a tarball without the source for the
compose command, and requires specifying a config option to disable
it.
We use the new unified OSTree API (OstreeSePolicy) to perform
labeling, rather than having our own here.
Also create a new rpm-ostree-relabeling-helper that is run to label
any leftover files such as /etc/fstab that we create offline, and also
to relabel the entire disk.
This is somewhat similar to what we've been doing with Continuous; we
take the manifest.json, and turn it into a "snapshot". Except here
there is a notion of inheritance.
This gets stored into the tree as /usr/share/rpm-ostree/treefile.json.
Additionally, it goes into the autobuilder directory in
products-built.json. Though really we should split up that file,
since it will be kind of...large.
There are two major reasons:
1) I want to do things like process SELinux labels here, and that
type of thing is best done in C.
2) There are presently 3 languages in this code, and this takes us
down to just two.
