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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Particularly in places like the lockfile code where we were iterating
on a list of packages, validating UTF-8 and `memcpy()`ing strings
from C is...well, unnecessary.
I don't think there's any actual real performance concerns right
now but let's use this as a best practice because the patterns
we establish *will* be copy+pasted or at least used as inspiration
for other places where performance might matter.
I happened to scroll past this code while doing something
else and noticed what we were doing here was silly - no need
to re-validate UTF-8 etc when serde can hand us a `String` directly.
Clippy reports this as an error; I think in practice Linux
doesn't return short writes for regular files, but it's still
a good idea to do the right thing here.
This command allows users to cheaply inject configuration files in the
initramfs stage without having to regenerate the whole initramfs (or
even a new OSTree commit). This will be useful for configuring services
involved in bringing up the root block device.
```
$ echo 'hello world' > /etc/foobar
$ rpm-ostree ex initramfs-etc --track /etc/foobar
Staging deployment... done
Run "systemctl reboot" to start a reboot
$ rpm-ostree status
State: idle
Deployments:
ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
InitramfsEtc: /etc/foobar
● ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z)
Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b
GPGSignature: (unsigned)
$ reboot
(boot into rd.break)
sh-5.0# cat /etc/foobar
hello world
```
See the libostree side of this at:
https://github.com/ostreedev/ostree/pull/2155
Lots more discussions in:
https://github.com/coreos/fedora-coreos-tracker/issues/94Closes: #1930
Let's just use the GLib translation bits rather than rolling our own;
this applies primarily to `ffi_new_string()`.
However, I think in most cases performance here doesn't
matter enough to have an even more special case that avoids duplicating
the string. Let's remove the `ffi_view_str()` optimization too
in favor of consistently using GLib translation.
In the future perhaps we should argue for adding a `from_glib_str_unchecked()`
to the upstream GLib bindings.
This avoids us leaking all of the Rust symbols as public
into our shared library.
Came up in team chat since one person tried to copy just `/usr/bin/rpm-ostree`
from the dev container into a target and got a linker crash; but
really we want to avoid all the duplicated symbols entirely.
(And we should investigate cross-language LTO because that's the
only way to get full savings)
This starts bridging parts of the daemon syscore logic to Rust
plumbing, moving the livefs detection logic over there as a first
consumer. That was the simplest logic available for wiring, and
mostly meant as a sanity check.
It's tempting to flip the default, but let's encourage
people to adapt to the `modules` version now.
Plus infrastructure to add deprecation warnings here
will come in handy in the future.
We're seeing some CI failures that I think are a bug in rojig.
In the bigger picture...we never actually started using this,
and I think longer term shipping os updates via containers
probably makes more sense.
I put a *lot* of effort into this code and it's pretty cool
so it's hard to just delete it. And *maybe* someone out there
is using it (but I doubt it). So rather than just deleting
it entirely let's make it a build-time option.
I verified that it builds at least.
Until Dependabot learns to batch PRs
(https://github.com/dependabot/dependabot-core/issues/1190), let's
reduce the churn here by limiting to 3 PRs at a time. Otherwise, it's a
massive pain to get them all in and taxes our CI heavily.
I suspect that having two DBus connections involved
is part of potential races in
https://bugzilla.redhat.com/show_bug.cgi?id=1865839https://github.com/coreos/rpm-ostree/pull/2255
Right now the client calls Reload when done - by
having the daemon defer it to an idle, we help ensure
that any other pending events (fd close,
transaction completions) are processed before
we even start the reload.
Today we unlock in the finalize path, which means that
the unlock can be delayed if something is referencing
the gobject for the transaction, even after it's done.
Worse, we do `g_clear_object (&priv->sysroot)` in the dispose
handler which means that if something calls dispose before
the last unref, we will never unlock!
Fix all this by unlocking when the transaction is done
executing. At that point we aren't going to do any
further modifications, so there's no reason to hold the lock.
This should be much more reliable.
While we're here also track the locked state via an explicit
boolean rather than keying off whether we happen to have
a sysroot object.
Part of looking at
https://bugzilla.redhat.com/show_bug.cgi?id=1865839https://github.com/coreos/rpm-ostree/pull/2255/
Basically the transaction can be lifecycle bound to the
DBus connection. We hold that connection open even
after we get a success response and then call back into the
daemon again to do a reload.
Rework the client code here so that all of the txn
stuff is in a method itself, and move the reload outside
of it. That way the bus connection will have been closed
reliably by autocleanups before we reload.
In f32, ping is no longer privileged since it ships with the sysctl for
`ping_group_range` which allows unpriv pings. Check the file caps of
arping instead, which does still use them.
Now that we've bumped to the latest FCOS commit for compose tests, one
thing that came up was that our compose tests never actually included
FCOS overlays in the compose the way cosa does.
This then cause compose failures because one of the postprocess scripts
expects those files there.
Let's just nuke all postprocess scripts here to work around this. I
initially wanted to import the overlay logic from cosa, but overlays
only work in unified core mode, and sadly we still want some coverage in
non-unified mode until that's fully dropped.
And anyway, we also already do a proper `cosa build` in the vmcheck
branch of CI so it's not like we're losing that coverage.
Down the line though, I think this is a good argument for folding the
overlay dirs into rpm-ostree more natively as discussed here:
https://github.com/coreos/coreos-assembler/pull/639#issuecomment-534713737
