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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
