Previously, the ppp version was only detected (and used) at one place,
in "nm-pppd-compat.c", after including the ppp headers. That was nice
and easy.
However, with that way, we could only detect it after including ppp
headers, and given the ugliness of ppp headers, we only want to include
them in "nm-pppd-compat.c" (and nowhere else).
In particular, 'nm-pppd-compat.c" uses symbols from the ppp daemon, it
thus can only be linked into a ppp plugin, not in NetworkManager core
itself. But at some places we will need to know the ppp version, outside
of the ppp plugin and "nm-pppd-compat.c".
Additionally, detect it at configure time and place it in "config.h".
There is a static assert that we are in agreement with the two ways of
detection.
(cherry picked from commit 3e66c0bde1)
(cherry picked from commit 65756dca7f)
Using the ppp code is rather ugly.
Historically, the pppd headers don't follow a good naming convention,
and define things that cause conflicts with our headers:
/usr/include/pppd/patchlevel.h:#define VERSION "2.4.9"
/usr/include/pppd/pppd.h:typedef unsigned char bool;
Hence we had to include the pppd headers in certain order, and be
careful.
ppp 2.5 changes API and cleans that up. But since we need to support
also old versions, it does not immediately simplify anything.
Only include "pppd" headers in "nm-pppd-compat.c" and expose a wrapper
API from "nm-pppd-compat.h". The purpose is that "nm-pppd-compat.h"
exposes clean names, while all the handling of ppp is in the source
file.
(cherry picked from commit afe80171b2)
(cherry picked from commit facd2ae916)
This change does the following
* Adding in nm-pppd-compat.h to mask details regarding different
versions of pppd.
* Fix the nm-pppd-plugin.c regarding differences in API between
2.4.9 (current) and latet pppd 2.5.0 in master branch
* Additional fixes to the configure.ac to appropriately set defines used
for compilation
(cherry picked from commit 8469c09a50)
(cherry picked from commit 521f936567)
Ppp 2.5 adds a pkg-config file, so we can detect the version.
Use it.
[thaller@redhat.com: split out patch]
(cherry picked from commit 0324098afa)
(cherry picked from commit 89bde5c9ca)
"-Difcfg_rh=false" did not work, we would always fallback to
autodetection. That is wrong, an explicit "false" should be honored.
It's also not what autotools does. Fix this.
While at it, drop "distro" variable. It's not a clear concept
that can be reused and it's unused otherwise.
Also, no longer let the autodetection be based on cross compilation.
When cross-compiling, it seems not entirely unreasonable that you cross
compile to a comparable distro, so let the autodetection be based on
what we detect on the host. In any case, a user can and is encouraged
to explicitly enable/disable the plugins via "-Difcfg_rh=" or
"-Difupdown=".
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1310
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.]
Otherwise, we will try to install "src/nm-dispatcher/nm-dispatcher.conf"
to "/usr/share/dbus-1/system.d", which is not correct, when we want a separate
prefix.
On Debian 10, `apt-get install meson` gives meson-0.49.2-1.
That version doesn't like certain ternary expressions (while some
that we have are OK), which leads to a crash of meson.
Avoid that.
Fixes: bddffb1731 ('build/meson: honor prefix for udev_dir and don't use pkg-config')
We do the same with autotools.
Well, almost the same. Of course, meson's define_variable only
accepts a list of two strings, to define one variable. So we cannot
also redefine "prefix", unlike configure.ac.
When building with `mesond -Dprefix=/tmp/nm`, then we would expect
that udev files are installed there (wouldn't we?).
The user can already explicitly set "-Dudev_dir=", or even disable
installing the files with "-Dudev_dir=no".
Note that meson be default pre-populates `get_option("prefix")`, so there
is always something set. So we cannot just act on whether the user set a
prefix. It seems to default to /usr/local.
Note that package builds from Fedora spec file pass "-Dprefix=/usr".
I think we should honor the prefix. However, then it seems wrong to also
honor pkg-config at the same time.
In particular, because `pkg-config --variable=udevdir udev` gives /usr/lib/udev.
That means, if we would just prepend the default prefix "/usr" or "/usr/local"
to "/usr/lib/udev" we get the wrong result.
Note that we already to the same for autotools.
The "unbound" DNS plugin was very rudimentary and is deprecated since
commit 4a2fe09853 ('man: mark [main].dns=unbound as deprecated') (Jun
2021).
It is part of dnssec-trigger tool, but the dnssec-trigger tool doesn't
actually use it. Instead it installs a dispatcher script
"/usr/lib/NetworkManager/dispatcher.d/01-dnssec-trigger".
Especially, since the plugin requires "/usr/libexec/dnssec-trigger-script",
which is provided by "dnssec-trigger" package on Fedora. At the same
time, the package provides the dispatcher script. So I don't this works
or anybody is using this.
https://mail.gnome.org/archives/networkmanager-list/2022-April/msg00002.html
