Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
These are just general purpose D-Bus utils, based on glib and GDBus.
They fit perfectly to libnm-glib-aux. Move the code.
Also, there is already the file "src/core/nm-dbus-utils.c", having two
files with the same name on our source tree is just confusing.
Instead, hack gettext's Makefile.
gettext has an issue with parallel make. See [1] and [2].
Reproduce with:
git reset --hard &&
git clean -fdx &&
NOCONFIGURE=yes ./autogen.sh &&
./configure --enable-gtk-doc --enable-introspection &&
make -j distcheck V=1
We worked around this by setting "DIST_DEPENDS_ON_UPDATE_PO = yes",
however that (obviously) results in regenerating source files during
dist. "Source files" in the sense that the po files are commited to git
and get distributed in the release. Doing this is very ugly.
In particular it's ugly, because `make -C po update-po` is not reproducible
and the output depends on the current time (*had one job*).
Otherwise, we could just regenerate the files before doing a release.
This means, running "release.sh" script ends up with a dirty tree
afterwards. Also, the distributed po files are not the ones from the source
tree when we did the release. Also, since "release.sh rc1" does two distributions
(once for the rc1 and once for the next devel snapshot), the commit for the
second distribution will have a large diff for the po files.
This reverts commit 978d8eb699 ('po: make dist depend on update-po')
and hacks around the problem.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1094#note_1435313
[2] https://lists.gnu.org/archive/html/bug-gettext/2022-06/msg00022.htmlhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1405
Recent gettext version can extract and merge back strings from and to
various file formats, no need for intltool anymore.
https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigrationhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/133https://github.com/NetworkManager/NetworkManager/pull/303https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/96
Clarification about the use of AM_GNU_GETTEXT_REQUIRE_VERSION:
In configure.ac, specify the minimum gettext version we require, rather
than the exact one. This fixes a situation where the autoconf macros
used for gettext will be the latest available on the system (for
example, 0.20); but the copied-in Makefile.in.in will be for the exact
version specified in configure.ac (in this case, 0.19).
In that situation, the gettext build rules will error out at `make` time
with the message:
*** error: gettext infrastructure mismatch: using a Makefile.in.in
from gettext version 0.19 but the autoconf macros are from gettext
version 0.20
Avoid that by specifying a minimum version dependency rather than an
exact one. This should not cause problems as we haven’t committed any
generated or external gettext files into git, so each developer will end
up regenerating the build system for their system’s version of gettext,
as expected.
See the subsection of
https://www.gnu.org/software/gettext/manual/html_node/Version-Control-Issues.html
for more information.
Note that autoreconf currently doesn’t recognise
AM_GNU_GETTEXT_REQUIRE_VERSION, so we must continue also using
AM_GNU_GETTEXT_VERSION. autopoint will ignore the latter if the former
is present. See
https://lists.gnu.org/archive/html/autoconf-patches/2015-10/msg00000.html.
[lkundrak@v3.sk: Fixed the meson build, adjusted autogen.sh:
droped "|| exit 1", dropped call to aclocal,
dropped --copy from gtkdocize.]
libnm-core currently has a dependency on crypto libraries (either
"gnutls", "nss" or "null"). We need this huge dependency for few cases.
Move the crypto code to a separate static library"src/libnm-crypto/libnm-crypto.la".
The reasoning is that it becomes clearer where we have this dependency,
to use it more consciously, and to be better see how it's used.
We clearly need the crypto functionality in libnm. But do we also need
it in the daemon? Could we ever link the daemon without crypto libraries?
The goal of splitting the crypto part out, to better understand the
crypto dependency.
`msgfmt -vc` warns:
po/be@latin.po:2: warning: header field 'Language' still has the initial default value
Check all files and update the Language manually.
The documentation ([1]) says that either "ll", "ll_CC" or "ll_CC@variant"
is valid. Update accordingly.
[1] https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html
`msgfmt -vc` warns:
po/as.po:9: warning: header field 'Project-Id-Version' still has the initial default value
Update them all:
$ git grep -l Project-Id-Version | xargs sed 's/^"Project-Id-Version: \(.*\)\\n"$/"Project-Id-Version: NetworkManager\\n"/' -i
The documentation ([1]) says:
Project-Id-Version
This is the name and version of the package. Fill it in if it has not already
been filled in by xgettext.
but don't add the "version". We have these files in git on the devel branch,
so whenever we branch a new release, the version would change. Just say
"NetworkManager".
[1] https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html
Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3
manager for the IP configuration of an interface. Use NML3ConfigData as
pieces of configuration that the various components collect and
configure. NMDevice is managing most of the IP configuration at a higher
level, that is, it starts DHCP and other IP methods. Rework the state
handling there.
This is a huge rework of how NetworkManager daemon handles IP
configuration. Some fallout is to be expected.
It appears the patch deletes many lines of code. That is not accurate, because
you also have to count the files `src/core/nm-l3*`, which were unused previously.
Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
