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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Just skip them in place, instead of setting separator=true. We only do
that in a single place (while finding a separator outside of quote or
backslash states) so we don't really need a separate state for it.
Tested that no regressions were introduced in test-extract-word. Ran a
full `make check` and also installed the binaries on a test system and
did not see any issues related to parsing unit files or starting units
after a reboot.
Use inner loops to keep processing the same state, except when there is
a state change, then break back to the outer loop so that the correct
branch can be selected again.
Tested that no regressions were introduced in test-extract-word.
This will make it easier to use inner loops to keep looping in the same
state, by just updating p and c in the same way in the inner loops.
Tested that no regressions were created in test-extract-word.
Using `goto` might be appropriate for the "finish" cases but it was
really not necessary at this point of the code... Just use if/else
blocks to accomplish the same.
Confirmed that the test cases in test-extract-word keep working as
expected.
This block runs once before all the other handling, so move it outside
the main loop and put it in its own loop until it's finished doing its
job.
Tested by confirming `make check` (and particularly test-extract-word)
still passes and by booting a system with binaries including this
commit.
Use the "return log_error_errno(...)" idiom to have fewer curly braces.
The last hunk also fixes the return value of setup_journal(), but the
fix has no practical effect.
Don't simply continue after sleeping, it potentially puts us in a state
of spinning doing nothing slowly, if the ratelimit_test() keeps
detecting the need for limiting.
Observed in vms after the host had been suspended for a while, on resume
systemd entered a loop of making zero progress spamming the console
with:
[431942.850090] systemd[1]: Looping too fast. Throttling execution a
little.
I see no reason to have a continue here, the intention should be to
throttle execution, not circumvent it altogether.
The basic setup for the well-known system and session buses is
now done in read-only files in ${datadir} (normally /usr/share).
See the NEWS entry for 1.9.18 for details.
http://cgit.freedesktop.org/dbus/dbus/tree/NEWS
Some guests (ARM, AArch64, x86-RHEL) have 'KVM' in the product name.
Look for that first in order to more precisely report "kvm" when
detecting a QEMU/KVM guest. Without this patch we report "qemu",
even if KVM acceleration is in use on ARM/AArch64 guests.
I've only tested a backported version of this and the previous
patch on an AArch64 guest (which worked). Of course it would be
nice to get regression testing on all guest types that depend on
dmi done.
ARM/AArch64 guests now have SMBIOS tables populated (when boot
with a late enough QEMU and a late enough AAVMF is used as the
bootloader). Furthermore, when booting ARM/AArch64 guests with
ACPI, the DT detection obviously no longer works, so we need
dmi detection.
afaict, this will fix a regression caused by commit 75f86906c5.
Where we used to report "kvm" before that patch, without this patch,
we would only report "qemu". The reason is because cpuid detection
must come before dmi detection. Also, both can safely come before
other xen heuristics. Untested.
'set-property' was missing from the list of known command.
Also a list of unit names will be proposed as next argument.
However no support on property names is provided since it would
require a hard coded list of them.
We already filter out 0, and as -1 is usually special (meaning infinity,
as in USEC_INFINITY) we should better not accept it either. Better safe
than sorry...
It is really unclear if we want to / have the resources to support this fully, so drop it
for now. It can easily be brought back if a killer usecase emerges.
Note that this code was never hooked up, so this does not remove any features.
