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 was argued on list a while ago: http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000391.html
Basically, every use of `%pretrans` is a workaround for some in-place
upgrade problem. But we never do inplace updates, we always assemble
a new tree. Hence, there is no point for us to ever execute these.
Let's stop erroring out on them. If there does turn out to be some problem with
a particular package (e.g. the `openjdk-copy-configs` or whatever), we would
likely end up needing to fix that package's `%post`, not start executing its
`%pretrans`.
Closes: #763
Approved by: jlebon
An updated version of: https://github.com/projectatomic/rpm-ostree/pull/316
using the journal (and structured logging) instead.
I was just curious. And yeah, in some quick testing via deploying an old
FAH `25.67`, there are zero relabels.
We should likely have a test that actually forces a relabel...would require
custom SELinux policy build? Or hm, maybe we could override a file context.
Closes: #760
Approved by: jlebon
When appending the trailing bytes, we were passing (p - s), but p by
definition is always NULL at that point. Chaos ensues.
The really evil part about this is that the len is passed signed and
glib treats negative values to mean it should lookup the length itself,
so this worked *most of the time*. Though I'm guessing if the address at
s is large enough, (p - s) can wrap around and become positive again,
thus causing a massive allocation. Anyway, I didn't actually check this
(esp. since the report was for ARM), but the patch is clearly right.
I think this may be the cause for
https://bugzilla.redhat.com/show_bug.cgi?id=1381357.
Closes: #756
Approved by: cgwalters
I want to use this in livefs, where I'll end up doing some diff
computations on the server and am currently rendering text there.
It might also be a step towards using this in `db diff`.
Closes: #709
Approved by: jlebon
While nothing else besides cleanup right now would call this directly, the code
should live close to the other very similar function:
`rpmostree_syscore_add_deployment()`.
Closes: #709
Approved by: jlebon
This is prep for livefs. We need to tweak the logic from what
core libostree has in `ostree_sysroot_simple_write_deployment()`,
and while we could land improved logic there, I think it makes
sense to carry this here until we're confident enough in the logic
to make it ABI.
This does depend on a [new libostree API](https://github.com/ostreedev/ostree/pull/745)
that allows writing deployments without doing cleanup.
The `bump_mtime()` bit is also prep for livefs, carrying in this patch to avoid
splitting things too much.
Closes: #709
Approved by: jlebon
I was looking at livefs executing scripts, realized I may need to
do some refactoring here, and decided to do some style updates.
Also, we make use of the `g_autoptr()` for ostree types in a few
places.
Closes: #752
Approved by: jlebon
This function wasn't like the others. If an error happened during
directory iteration, we'd still return TRUE, but with an error set.
Noticed while I was going to do some code style porting.
Closes: #752
Approved by: jlebon
I typed `rpm-ostree status` in a container, and today we print:
`error: Could not connect: No such file or directory` which isn't
quite informative enough for me.
Closes: #751
Approved by: jlebon
I honestly didn't really dive into this, but it looks like
this is yet another "hack upgrades in the yum case", which we
should be able to ignore since we always do reassembly.
I at least tested `java -version` works with this.
This is a band-aid for the bigger issue of:
https://github.com/projectatomic/rpm-ostree/issues/749
(Doing this one since an AtomicWS user reported it)
Closes: #750
Approved by: jlebon
`Commit` is useful in cases where one wants to e.g. run `rpm-ostree db diff`.
`StateRoot` however is going to be in the vast majority of cases identical
across deployments.
Closes: #743
Approved by: jlebon
See: https://github.com/ostreedev/ostree/pull/794
I originally tried to do this ~a year ago in:
https://github.com/projectatomic/rpm-ostree/pull/295
But Micah pushed back at the time. I'd still like to do this
though, since I personally find `OSName` *more* confusing
than `StateRoot`.
One specific rationale I have for making this change is that
I rebased a home server from CentOSAH to FAH - and I feel
it's just saner to see `StateRoot: centos-atomic-host` instead
of `OSName: centos-atomic-host` underneath the fedora refspec.
Closes: #743
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
In #728, we started querying enabled repos using get_n_solvables().
However, there are different kinds of enabled repos, and
`dnf_repo_get_enabled()` reflects that through the bitmask it returns:
- DNF_REPO_ENABLED_NONE: repo disabled
- DNF_REPO_ENABLED_PACKAGES: repo enabled for package installs
- DNF_REPO_ENABLED_METADATA: repo enabled for metadata
We were treating it as a boolean, though really, we should only print
data about repos with ENABLED_PACKAGES on, which are the actual repos
libdnf can fetch packages from. Repos with only ENABLED_METADATA on are
not fetched by default, and thus will cause SIGSEGV when trying to
get_n_solvables().
I ran into this while trying to debug #720 on F25 AH, which has this
repo by default:
[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
baseurl=https://codecs.fedoraproject.org/openh264/$releasever/$basearch/
enabled=0
enabled_metadata=1
Closes: #736
Approved by: cgwalters
I'm debugging a depsolve failure right now, and just like for
the treecompose case, it's useful to see the information about
enabled repositories. (We should actually maintain this
better in the daemon, but this is a start)
Closes: #728
Approved by: jlebon
The kver that rpmostree_find_kernel() returned would include the csum
that ostree tacks on. This would then cause dracut to fail to find the
modules for the given kver.
The issue is that rpmostree_find_kernel() can be called for both the
ostree checkout case (pkglayering) and the yumroot case (treecompose).
Rather than using a heuristic to determine whether there is a trailing
csum we should trim, we instead always fetch the kver from the dirname
in /usr/lib/modules, which will work in both cases and is stronger.
This also fixes a few cosmetic issues. Notably the final initramfs and
vmlinuz filenames in /usr/lib/ostree-boot would have *two* chekcsums
tacked on, rather than just one.
Closes: #722
Approved by: cgwalters
Otherwise dracut will just default to the running kernel, which will be
wrong if the pending deployment doesn't have the same kernel. Use --kver
rather than appending to be more explicit.
Closes: #722
Approved by: cgwalters
Add support for --install/--uninstall to upgrade/deploy/rebase by
calling out to UpdateDeployment(). Since it's not released yet, back out
the support for install-local-packages in the options variant for
PkgChange(), and make it instead use UpdateDeployment() as needed.
Closes: #711
Approved by: cgwalters
The new UpdateDeployment() method wraps the full capability of the
deploy transaction handler. Modifiers indicate how one wants to change
the origin, and options indicate extra behaviours.
One interesting note here is that all the options "come together" for
the first time: some of them were user-specified options (reboot,
skip-purge, dry-run), some were internal only (no-pull-base), and some
were both (allow-downgrade).
This means we now have to handle interesting cases, e.g.:
- We check for option conflicts between "no-pull-base" and
"set-refspec"/"set-revision" (similarly for "skip-purge").
- We enable "allow-downgrade" by default if the refspec or revision is
changing.
- Previously, "dry-run" could only be specified through PkgChange().
Rather than making it only valid when pkgs are overlayed (which
itself wasn't that meaningful since the introduction of dormant
package requests), we generalize it so that "dry-run" just means:
stop right before actually deploying the tree.
Closes: #711
Approved by: cgwalters
See https://github.com/ostreedev/ostree/pull/768 - basically
`/proc` is unlabeled, and this gets annoying for livefs work
since it shows up as a diff.
Plus at some point in the future `ostree fsck` might actually learn to verify
deployment directories.
Closes: #714
Approved by: jlebon
If available, using the also-new `OSTREE_CHECK_VERSION`. I dropped the `path`
argument from one of the internal APIs since it made the code simpler, and every
caller except one was passing `.`.
Closes: #712
Approved by: jlebon
All the handlers that eventually create a deploy transaction can share
much more code. This will make it easier to implement pkg
install/uninstall for all of them in one place.
Closes: #710
Approved by: cgwalters
Right now, the `rpm-ostree cleanup` logic calls into a "public static" method of
`RpmOstreeSysrootUpgrader`. That's because today, a lot of the high level "core
server side" logic lived in that class. However, it's only for upgrades (well,
really "generating pending deployments").
As I'm working on "livefs" which is really something different, I find it needs
to interact with some of `SysrootUpgrader`'s logic. Let's introduce a "sysroot
core" which is just a set of static functions taking an `OstreeSysroot*`, and
then all 3 of cleanup, (upgrade|deploy) and livefs can use these.
Closes: #708
Approved by: jlebon
Prep for livefs; there we're storing live update state as xattrs on the
deployment root, and hence we need access to the sysroot to query it.
Closes: #706
Approved by: jlebon
Rework pkg_change() so that the core functionality is implemented by a
helper function. Also convert it to the new style.
I also renamed the "local-packages" to "install-local-packages".
Contrast with the future values: "install-packages" and
"uninstall-packages".
Closes: #704
Approved by: cgwalters
One interesting note here was that I couldn't use glnx_throw in as many
places as I wanted because EXIT_SUCCESS/EXIT_FAILURE are the exact
opposite of that semantic. It was still convenient to use though as a
short-form for g_set_error().
Closes: #704
Approved by: cgwalters
This is the same change that was done for PkgChange(). It will be
required if we want to support specifying local packages through e.g.
--install switches.
Closes: #704
Approved by: cgwalters
Just like `rpm-ostree ex`, for things like `ex livefs` that have DBus
interfaces, we should segregate these off so that people know they're unstable.
And conversely that they can test for the presence of the method on the main
interface for stability.
I initially tried having the same `RpmostreeOS` object implement both
but couldn't work out how to do that; see https://mail.gnome.org/archives/gtk-app-devel-list/2017-March/msg00161.htmlCloses: #701
Approved by: jlebon
This is a small one, but I like the momentum. Also note my use of the `,`
operator here. A little unusual maybe but I think it makes sense.
Closes: #700
Approved by: jlebon
I originally thought there was a bug here, but missed we were skipping
symlinks earlier above. See [previous discussion][1].
Now, I'm not aware right now of something this patch actively fixes, but I think
it makes sense to be consistent in our handling of things here with respect to
symlinks.
1: 29dd1bd801..8158dcfb47 (r95017893)Closes: #689
Approved by: jlebon
This is a follow-up to commit 81c43e8 (#657). That commit extended the
definition of "packages_added" to also support local RPMs. We revert
that here, and instead open the RPM file ourselves and send the fd over
D-Bus. We add support for a "local-packages" option containing the fd
indices to process.
It's just cleaner and safer overall; the daemon and client might not
even be sharing the same view of the filesystem!
Closes: #696
Approved by: cgwalters
Add an annotation so that the generated D-Bus code allows rpm-ostree to
pass fds through messages. Note that this doesn't change the API itself,
only how rpm-ostree uses the GDBus library. Clients should still be able
to invoke PkgChange() as before.
Closes: #696
Approved by: cgwalters
Following up on the previous commit regarding timestamps - the checksum of the
derived commit isn't very useful. It's not going to be the same between any two
people's systems. What we should show instead is the rpm-md repository
timestamps.
In the short term though, I think omitting this even without the rpm-md
timestamps is better. Less visual clutter.
Closes: #697
Approved by: jlebon
Currently we propagate the version field from the base to derived,
but the status UI shows the timestamp from the derived commit.
I found this *extremely* confusing when I was trying to reason about the
up-to-dateness of my system. The version and timestamp should be locked
together so we display them consistently.
When we generated the local commit isn't really useful information; conceptually
we have the base timestamp, plus timestamps for the rpm-md repos. We should
display the latter instead.
(This also adds `base-timestamp` and `base-verison` to the JSON; only
the former is new information, but the latter helps us be consistent)
Closes: #697
Approved by: jlebon
This takes commit c437f90 a bit further. We delete more #ifdef 0 blocks
which can just be revived later on if we need it.
Closes: #695
Approved by: cgwalters
There's no point to shipping these backup files in the base tree. We already had
code to delete them for the package layering case where they caused active harm.
At the point we added that code we really should have *also* changed treecompose
to delete them. Better late than never.
The reason I'm doing this now is because having them in the base tree causes `ex
livefs` to spuriously think that layering a package that *doesn't* change `/etc`
as if it does, because the layering code deletes the backup files.
Closes: #693
Approved by: jlebon
