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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Unfortunately, strverscmp() from libc or str_verscmp() do not correctly
handle pre-release version, e.g. 247 vs 247~rc1.
This implement a new comparison function, which is based on the RPM's
rpmvercmp().
sd-boot has a copy of a subset of codes from libbasic. This makes
sd-boot share the code with libbasic, and dedup the code.
Note, startswith_no_case() is dropped from sd-boot, as
- it is not used,
- the previous implementation is not correct,
- gnu-efi does not have StrniCmp() or so.
Previously, even when writing e.g. /etc/hostname fails, the static
hostname in Context is not restored. So, the subsequent call of the same
method succeeds:
```
$ sudo chattr +i /etc/hostname
$ sudo hostnamectl --static set-hostname aaa
Could not set static hostname: Access denied
$ echo $?
1
$ sudo hostnamectl --static set-hostname aaa
$ echo $?
0
```
This makes when updating file is failed, the saved stat is cleared. So,
the static hostname or machine information in the context are always
consistent to the corresponding files.
If no target (--pretty, --static, or --transient) is specified, then
let's try to set transient hostname even if setting static or pretty
hostname failed. This may be useful for read-only filesystem.
e.g.:
./src/shared/dissect-image.c:2218:39: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"/usr/lib/os-release\0",
^
../src/shared/dissect-image.c:2217:39: note: place parentheses around the string literal to silence warning
[META_OS_RELEASE] = "/etc/os-release\0"
^
1 error generated.
See: https://reviews.llvm.org/D85545
As far as I can see, at some point the parser function for MountAPIVFS
was changed from the generic bool parser to a custom implementation, to
allow the context to keep track of whether MountAPIVFS had been set
explicitly. If not, exec_context_get_effective_mount_apivfs would fall
back to a default value. However, the corresponding entry in the big
parser table wasn't updated, meaning that the old bool parser was still
used, meaning that context->mount_apivfs_set remained at its default
value of false, meaning that the default value was always used and the
config option was effectively ignored.
Fix for 5e98086d16.
The last release of Upstart was July 2014 [1], and there have been no new
commits to the repo. We should move on too.
[1] https://lists.ubuntu.com/archives/upstart-devel/2014-July/003313.html
The only real support was in the code that looked for $PREVLEVEL.
https://codesearch.debian.net/search?q=PREVLEVEL&literal=1&perpkg=1 shows this
string in our own code (or the copy in elogind), our own man pages, and init
scripts for two packages (brltty, salt), which shouldn't be used with systemd.
(And both *check* for PREVLEVEL, and don't set it. So most likely nothing at
all sets it.)
When executed in test mode, "OUTDATED" is appropriate. But when executed
to actually update the text, after the tool executes, those pages are the
opposite, not outdated.
It happens too often that what people ask for already is implemented.
Let's help cut the noise a bit, and make people check things first
hopefully, and at least make it either for us to detect such cases.
If we don't have ifindex info, don't set the field for it.
We already do that for parsed IP address replies, let's do it for all
cases: it's a bit nicer to suppress the ifindex prop if it doesn't apply
than to pass it invalid.
This is the other side of #18482, i.e. fixes things so that the parser
doesn't get tripped up by this.
(This too makes a problem go away we should track down properly, i.e.
figure out how the ifindex got lost in
https://github.com/systemd/systemd/pull/17823#issuecomment-742439422 )
Since the test suite overhaul, the test units are now under
/usr/lib/systemd/tests/testdata/tetsuite-06.units with
system_u:object_r:lib_t context. This causes an AVC denial, since the
systemd unit files are expected to have the
system_u:object_r:systemd_unit_file_t context. Let's fix this by using a
custom file context definition.
Aaargh. See the comment in the code.
Apparently the range is like that:
$ sudo bash -c 'echo "default 1001" >/sys/fs/cgroup/user.slice/io.bfq.weight'
bash: line 0: echo: write error: Numerical result out of range
$ uname -r
5.11.0-0.rc4.129.fc34.x86_64
Instead of using a short fixed string, let's use a huge blob for
testing, with randomized size and contents, that definitely is above the
16K buffer size conservative_renameat() uses internally.
The "XDG standardization for applications" specification states that
services should be in the form:
app[-<launcher>]-<ApplicationID>[@<RANDOM>].service or
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
In this case "autostart" takes the place of [RANDOM] to provide a unique
identifier if the same app is launched elsewhere. As it is a service
that means it should be set as a template not using a hyphen delimiter.
To add secure-boot enrolling support, we need to be able to specify
the EFI_VARIABLE_APPEND_WRITE flag so let's make the efivar_set()
methods more generic so we can set that flag.
