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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The firmware spec doesn't really say whether FilePath of the LoadedImage
protocol may be NULL or not. So far we assumed it to be non-NULL, but
apparently the FreeBSD UEFI chainloader sets it to NULL. Handle this
gracefully.
(Noticed and tracked down by Alexander Schreiber)
Fixes: #18733
THe previous code wasn't wrong, but it's certainly nicer to avoid a
partially uninitialized array here, hence Coverity has a point
complaining about this.
Coverity 1446731
This reverts commit 5ffa2eaa541b718122a3422e911ef95f4c9981d7.
It seems that if install_dir is not specified, meson decides install path
based on file type, and non-executable binary files are installed under
/usr/share.
kernel-install is a script. So, we need to set install_dir argument
explicitly.
Fixes#18754.
The argument only exists to be used to override/fill in the RRSIG record
of the answer item. Hence actually use it instead of ignore it.
(Not sure how this got lost earlier.)
Fixes: #18714
Before, we only allowed conditionalizing on controllers, not the hierarchy.
This commit extends this to allow a simple check for v1 (i.e. classic or hybrid),
and v2 (full unified).
An alternative approach would be to add a separate Condition for this, but I'm
not too keen on that, considering that v1 is already being deprecrecated
(c.f. 82f3063218).
I left the stuff related to [NextHop] out. There are still
patches outstanding, and we can add a comprehensive entry once
things reached the final form.
There's no "answer_auxiliary" object anymore, it's all one "answer"
object, and we have per-item flags that tell us which section things are
from, i.e. from the main answer section, or the additional or
authoritative ones.
CNAME following was broken by 775ae35403f8f3c01b7ac13387fe8aac1759993f
where we'd not properly collect RRs along the CNAME path. Good thing
though is that we don't have to anymore: since we nowadays propagate all
sections of the upstream replies into the cache and back to stub clients
all the information should already be available anyway, and there's no
need for us to collect it.
Fixes: #18690
This follows the addition of DEFAULT_HOSTNAME= in os-release.
The distinction between the value from os-release or the env var and
the compile-time setting is not made in the api: HostnameSource is
"default" is all cases. I think that this level of detail is not needed,
because the users of this mostly care whether the hostname was set by
user configuration or not.
This provides a fairly comprehensible fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1893417.
This adds yet-another level of configuration:
- /etc/hostname
- transient hostname
- $SYSTEMD_DEFAULT_HOSTNAME
- DEFAULT_HOSTNAME is os-release
- -Dfallback-hostname=
- "linux"
It's a lot of layers, but each has it's own justification.
See https://bugzilla.redhat.com/show_bug.cgi?id=1893417 for the back story:
the fallback hostname matters a lot in certain environments. Right now the only
way to configure the fallback hostname is by recompiling systemd, which is
obviously problematic in case when the fallback hostname shall differ between
different editions of the same distro that share a single compiled rpm.
By making this overridable through an envvar, we're providing an escape hatch
without making this a top-level api. Later on a way to set this through
os-release is added, but I think the approach with the variable is still
useful. It it very convenient for testing, or to override settings only in a
particular service, etc.
