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 a follow-up to commit 77acf62. There, we added support for
rebasing from a local branch to another local branch. But in testing,
it's also really useful to be able to rebase from a remote-based refspec
to a local branch. We allow this here by slightly expanding the syntax
of allowed refspecs.
Now, we can use rpm-ostree all the time rather than fallback to `ostree
admin deploy`, which isn't pkg-aware.
Closes: #764
Approved by: cgwalters
Conceptually: we're going to move rpm-ostree and ostree at the same
cadence most of the time; for both releases *and* for git master.
The problem so far has been the latter part. Reusing FAHC
for the build gets us half of the problem.
The other trick I realized we can do - just pull ostree out from the build
container. This avoids fetching it from the internet, and makes my workflow for
hacking on both nicer - I just `sudo make install` in my build container for
ostree.
It's tempting to make the whole thing symmetric and require `sudo make install`
for rpm-ostree and not do the insttree thing but...perhaps after.
Closes: #758
Approved by: jlebon
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
The Dockerfile is problematic since we can't update it atomically. I also really
dislike reliance on the Hub. Further, I think rather than caching our build deps
as built containers, we should be caching RPMs in CI. And we should be using
rpm-ostree at some point to assemble filesystem trees faster.
Also, consolidate the clang to be serial with gcc, since while we lose a tiny
bit of parallelism, it's not really worth its own context right now.
Closes: #759
Approved by: jlebon
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
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
This has bitten me many times already; switching libdnf submodule (or just
editing the code directly in the submodule dir to add debug prints) didn't
rebuild libdnf.
Recursing the build: cheap ¢. Not spending a half hour figuring out
the code you're debugging isn't what you typed: priceless 💸.
Closes: #733
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
I want to be able to debug a test by sshing in with the same setup;
right now the suite resets and reboots by default.
This also required fixing how we deal with `/etc/yum.repos.d`, since at the
start of the test it could be either pristine or not.
Closes: #578
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
