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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add a --enable-man-html configure option to build HTML man pages using a
different stylesheet. The HTML pages aren't installed as I don't know
what purpose they'd serve on an actual installation.
This is failing for me as of recently but only when I build
without optimization. I don't think we've ever written any
code that returned a large structure by value.
Let's just drop this one.
In fixing https://github.com/coreos/rpm-ostree/pull/3323
I felt that it was a bit ugly we're installing `/usr/bin/ostree-container`.
It's kind of an implementation detail. We want users to use
`ostree container`.
Let's support values outside of $PATH too.
For example, this also ensures that TAB completion for `ost` expands
to `ostree ` with a space.
This adds build-time configuration logic to automatically detect
and switch between libfuse 2.x and 3.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Luca BRUNO <luca.bruno@coreos.com>
We struggled for a long time with enablement of our "internal units",
trying to follow the philosophy that units should only be enabled
by explicit preset.
See https://bugzilla.redhat.com/show_bug.cgi?id=1451458
and https://github.com/coreos/rpm-ostree/pull/1482
etc.
And I just saw chat (RH internal on a proprietary system sadly) where
someone hit `ostree-remount.service` not being enabled in CentOS8.
Thinking about this more, I realized we've shipped a systemd generator
for a long time and while its only role until now was to generate `var.mount`,
but by using it to force on our internal units, we don't require
people to deal with presets anymore.
Basically we're inverting things so that "if ostree= is on the kernel
cmdline, then enable our units" and not "enable our units, but have
them use ConditionKernelCmdline=ostree to skip".
Drop the weird gyrations we were doing around `ostree-finalize-staged.path`
too; forking `systemctl start` is just asking for bugs.
So after this, hopefully we won't ever again have to think about
distribution presets and our units.
It was added for the collections bits, but we made that stable.
It's now just cruft and we're very unlikely to reuse the infrastructure
again.
Motivated by a unit test failure when running from a tarball:
https://github.com/ostreedev/ostree/issues/2313
This was my first experiment with using Rust in this way; I gained
a lot of knowledge from it. But, we don't really gain
anything from the code as it is today - while it is "bit fiddling"
code, the C code is well tested.
We have a lot of compile-time options, and trimming them will be
helpful.
We've also gotten pushback on hard requiring Rust client side.
Instead, what I'd like to do is hopefully soon create an `ostree-system`
crate that uses the existing `ostree` library and can contain
code drained from the rpm-ostree Rust and used by other projects perhaps.
So the goal here is really more Rust, but we need to focus our
efforts on where it's most valuable.
GRUB starting with version 2.02 permits the use of the linux and
initrd commands for both EFI boot in *-efi installations, as
well as 32-bit BIOS boot in i386-pc installations.
This makes the use of the -16 and -efi suffixes for BIOS and EFI
boot obsolete on systems with a modern GRUB installation.
The --with-modern-grub configure flag makes ostree use the
unsuffixed linux/initrd commands when generating a GRUB
configuration, while defaulting to the previous behaviour for
users not wanted this option.
It's cleaner if this is an build option rather than being
kludged into the CI layer.
Notably we can't use `LD_PRELOAD` anymore with ASAN, so update
our tests to check for `ASAN_OPTIONS`.
Use option `--with-ed25519-libsodium` instead of
`--with-libsodium` to enable ed25519 signature engine.
This allows to use later different implementations of ed25519
signing/verification. For instance, based on openssl.
Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>
`libsodium` is an implementation detail. In particular, I'd like
to consider using OpenSSL for ed25519 (if libsodium isn't configured
and openssl is).
So switch the name of the exposed feature and adjust the tests.
