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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Mostly because when building with CLang, I get a spam of warnings
like:
```
/home/walters/src/github/projectatomic/rpm-ostree/libdnf/libdnf/dnf-transaction.h:37:27: warning: redefinition of typedef 'DnfTransaction' is a C11 feature [-Wtypedef-redefinition]
G_DECLARE_DERIVABLE_TYPE (DnfTransaction, dnf_transaction, DNF, TRANSACTION, GObject)
```
Closes: #501
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
A funky behaviour of `rpm-ostree deploy` was that specifying a csum
directly allowed you to jump to any commit, regardless of whether that
commit exists on the current branch or not. We tighten that up here so
that we check that the checksum does exist on the current branch.
The previous behaviour can be useful of course, but we might want to
change how users access it so that we don't get inconsistencies such as
rpm-ostree status saying that we're sitting on a specific branch with a
specific commit which doesn't actually belong to that branch.
Closes: #495
Approved by: cgwalters
I'm trying to rebase my workstation across a major version, but
hit the issue that we were pointing libdnf at the current root,
and hence it inherited the major of 24, when my target base ref
was 25. In trivial cases this may work, but I have various things
like Emacs layered that caused dependency resolution failure.
The obvious fix here is to point libdnf at the target base ref.
However, until now we'd been checking out a minimal copy of the tree
*before* doing package upgrade resolution. I considered trying
to add `/usr/lib/os-release` to that set, but it doesn't seem
sustainable.
Particularly since I think the original rationale for this was that
the checkout was slow, but that was when we had `fsync()` on, which we
don't now.
Closes: https://github.com/projectatomic/rpm-ostree/issues/486Closes: #496
Approved by: jlebon
This is basically a re-implementation of
85c9dd5c07
for the same reasons: it makes things work for rpm-ostree running
inside NixOS. But there are other cases where if e.g. an unprivileged
user runs rpm-ostree and may not have `/usr/sbin` in PATH, we still
want the container to pick it up, etc.
While changing things I nuked the hacky `RPMOSTREE_DEBUG_SCRIPT` env
var, we can re-add it later in a better way if needed.
Closes: #490
Approved by: jlebon
We have two different codepaths for creating a cache branch header
string, one from libdnf, and one from librpm. It turns out if
an RPM package explicitly specifies an `Epoch: 0` like various Fedora
perl subpackages do, these are different.
Explicitly convert `0:` to the empty string to make them match, and
hence installation will work.
Closes: https://github.com/projectatomic/rpm-ostree/issues/349Closes: #482
Approved by: jlebon
Nothing in the file seems to use it. Doing this quickly via GitHub UI under assumption that the magic @walters bot will take care of running the full test suite, but otherwise I'll test it later when I get back to a machine I can use for that.
Closes: #481
Approved by: cgwalters
This makes the design fully coherent now - we don't try to store
multiple commits, we no longer reference them, and the cleanup does a
depth=0 pruning.
Closes: #475
Approved by: jlebon
My desktop system was aborting on upgrade with a missing metadata
object, which turned out to be the fact that my previous changes to
the package layering code pruned with depth=0, but the commit it was
looking for had a parent commit that had been pruned.
Closes: #475
Approved by: jlebon
I hit a pile of:
```
Oct 04 12:44:15 icarus.verbum.local rpm-ostreed[26257]: ostree_repo_resolve_partial_checksum: assertion 'error == NULL || *error == NULL' failed
```
Which turned out to be a missing metadata object (for some reason),
but this function's incorrect use of `ret = TRUE` caused the GError
to have already been set.
Fix this, and we change to "direct return" style which is more
readable.
Closes: #474
Approved by: jlebon
Per OSTree design, /var can start out empty. However, our warning
spam here is annoying. Let's first delete some known files -
obviously this won't be exhaustive, but it's way faster than trying to
fix all of this in the packages right now.
The major one is the SELinux policy, which resulted in a lot of spam.
Closes: #473
Approved by: jlebon
The API for json_generator_to_stream() says:
Return value: %TRUE if the write operation was successful, and
%FALSE on failure. In case of error, the #GError will be filled
accordingly
When in fact, because it just gives back what g_output_stream_write(),
1. it doesn't strictly return TRUE/FALSE, but a full-range uint, and
2. it will return -1 (which is as good as anything > 0 for success
checks) when an error occurs.
Although a simple <= 0 would fix it, let's just be extra strict and also
check for an error.
Closes: #468Closes: #469
Approved by: miabbott
Let's try out https://wiki.centos.org/ContainerPipeline
Having maintained Docker images for rpm-ostree seems kind of overdue.
(I didn't actually test the CP bits since I'm not sure how to do that)
Closes: #460
Approved by: jlebon
These were added to shadow-utils in recent times (Fedora 25 e.g.) and
like the other passwd files, shadow-utils opens them with `O_TRUNC`.
(At some point we should patch it to do create-new-then-replace internally)
Closes: https://github.com/projectatomic/rpm-ostree/issues/458Closes: #459
Approved by: jlebon
Commit 334cec56a0 had a fatal
logic error - I changed it to write a temporary ref for the final
commit, not the base.
I noticed this by getting `missing metadata object $base.commit` on my
desktop system. Hooray for dogfooding git master.
Closes: #452
Approved by: jlebon
I think these are suitable for wider consumption now, and we should
be able to support existing installs.
Rename the verb to just `install` since it's what every other package
manager uses.
Closes: #450
Approved by: jlebon
It turns out it was buggy (for some reason `PS1` wasn't propagating),
and furthermore, things mostly work if one enables `--new-chroot` i.e.
`systemd-nspawn`, which is what Fedora is going to do, and everyone
else in the world uses Docker.
While we're here, tweak the error message to use `<>` around the URL
which makes it more easily clickable from terminals.
Closes: #449
Approved by: jlebon
It needs to be under `[Unit]`. I noticed the systemd warning
in my logs; not sure how this worked when I was testing it locally.
Closes: #446
Approved by: jlebon
Right now the daemon assumes the system is using ostree, but
for various reasons people can try to start it on non-ostree systems.
This is a simple fix to avoid crashing. A better fix would
need to rework a lot of the code to return dummy/stub values but
that would be painful. Maybe later.
https://bugzilla.redhat.com/show_bug.cgi?id=1372194Closes: #445
Approved by: jlebon
Communicating information is a hard problem, but basically there
are two things here. First, the changelogs make the diff visual
spaghetti. (If we were rendering to HTML with expanders or something,
it could work).
Second, I think RPM changelogs are legacy - tooling should pull from
git.
So far when doing release announcements I've been manually stripping
out the changelogs, embarassingly enough. Time to fix that.
Anyways, we preserve the changelog-emitting code, it's just not the
default now.
Closes: #439
Approved by: jlebon
We need to manage our baselayer refs independently of the deployment
being written by libostree, so suppress the default clean; we'll do
it in rpm-ostree.
I noticed the `Freed objects:` message twice and always wondered why
until today.
Closes: #437
Approved by: jlebon
Until now, we weren't pruning the pkgcache repo at all. I ran out of
space in the root partition in my CAHC vagrant test box, so it's time
to fix this.
The basic algorithm is to walk over the full rpmdb contents of each
root, generate a set of "currently referenced" cached refs, then delete
any refs in the pkgcache repo which aren't included. Then, do a prune
of the pkgcache repo.
While we're here, factor out a `sysroot_upgrader_cleanup()` function
which does all of the cleanup. The idea is at some point we need to
introduce an `rpm-ostree cleanup` command or so which calls this, to
handle the case where the system is interrupted post-deploy but
pre-clean.
Closes: https://github.com/projectatomic/rpm-ostree/issues/428Closes: #437
Approved by: jlebon
In preparation for future changes here, rework things so
that we only walk the set of deployments once after the new
deployment has been generated.
To avoid a race where if we're interrupted after the deployment write
but before the regeneration, create a special `rpmostree/base/tmp` ref
that we delete after all the bases are regenerated.
Closes: #437
Approved by: jlebon
Currently, we do the final commit into the pkgcache repo, then
pull it to the base. The problem with this is that, combined
with the fact that we're not presently pruning the pkgcache repo,
we leak space.
In preparation for a cleaner fix for this, rework things so that the
core infra can know about *both* a base repo and a pkgcache repo. If
they're separate (as is the case for rpm-ostree-on-host), whenever we
are doing layering, explicitly pull just the `.file` objects that are
referenced into the parent repo. We do the final commit in the base
repo.
Closes: #437
Approved by: jlebon
Thought it'd be fun to write a test for verifying proper handling of
scriptlets during package layering. There's obviously a lot more that
could go in here (patches welcome!), but it's a start.
Closes: #434
Approved by: cgwalters
