In Debian unstable package libqrencode-dev is version 4.0.2-1, and the
corresponding runtime library is provided by package libqrencode4.
This change fixes the following error when running journalctl:
root@image:~# journalctl
journalctl: error while loading shared libraries: libqrencode.so.4: cannot
open shared object file: No such file or directory
This change also fixes the following boot failures in
systemd-journal-flush.service and systemd-journal-catalog-update.service:
[FAILED] Failed to start Flush Journal to Persistent Storage.
[FAILED] Failed to start Rebuild Journal Catalog.
See also #4949
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
intltool is unnecessary since c81217920e.
But we still need gettext, because we use msgformat to generate .mo files.
(I tried to make meson depend on it, at least in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1545926, but that didn't fly,
and in Debian at least meson also has no dependency on the tools used by
its i18n module, so we need to add our own dependency anyway.)
Closes#8192.
Recent systemd compiled in a build root which had libidn2-devel installed would
not run in the default installation root which had just libidn and did not have
libidn2. Since a8a2a0ed64 libidn2-devel (or equivalent) is installed in
the build root. Normally, since we install systemd in the installation root,
all dependencies that are needed for the compiled systemd to run are present,
but libidn2 is a new dependency, so the distro packages would just pull in
libidn, and not libidn2.
Temporily add libdn2 to explicitly specified Packages. We can remove that once
distro-compiled systemds have moved to libind2.
Yu Watanabe