Also, don't add the CFLAGS for libjansson to dflt_cppflags_libnm_core.
dflt_cppflags_libnm_core is used also by core and libnm. But those
components do not (directly) link against libjansson. The cannot use
these flags.
I don't think we should do this.
- renamining/dropping configure options is still an annoyance,
because it requires to different ./configure options depending
on the version. The rename from --enable-teamctl to --enable-team
might be theoretically nice, but more annoying then helpful.
- There is no strict dependency between --enable-team and
--enable-json-validation. At most, one could argue that
when enabling the team plugin (--enable-teamctl), then
libnm must also be build with --enable-json-validation.
But in fact, the team plugin will happily work with a
libnm that doesn't link against libjansson.
That is --enable-teamctl --disable-json-validation will work
in practice just fine.
On the other hand, libnm is a client library to create connection
profiles, fully supporting team profiles also makes sense if the
actual plugin is not installed (or build). Thus, --disable-teamctl
--enable-json-validation certainly makes sense.
At this point, one might ask whether libnm is even still complete without
libjansson. Maybe libnm should *require* --enable-json-validation.
But that is not what the patch was doing, and it would also need
some careful consideration before doing so.
This reverts commit 9d5cd7eae8.
Rename the team functionality enablement from 'teamdctl' to 'team'.
Force jansson lib requirement for team functionality: NetworkManager
requires the teamd daemon to manage team. As teamd depends upon jansson
lib, adding jansson requirement for teaming support in NetworkManager
seems reasonable.
Remove the jansson_validation flag, as the only generic json function in
nmcli (not related to team) was the one to check if a string was in json
format. Anyway, that function is used for team checks only. So, move
also json validation functions under the WITH_TEAM flag.
Currently there are multiple features that require Jansson support,
but WITH_JANSSON=1 is set only when configuring with
--enable-json-validation. Therefore a build with
"--disable-json-validation --enable-ovs" fails.
The availability of Jansson (WITH_JANSSON) should only be used:
- to check if dependent features can be enabled
- to determine compiler and linker flags in the Makefile
- in nm-jansson.h to define compatibility functions if needed
Everything else must be controlled by a configure switch.
https://bugzilla.gnome.org/show_bug.cgi?id=790233
After 1.10.0 is released, merge it back into master so that
1.10.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.10.0 and 1.10-rc*.
Also bump the micro version to 1.11.1-dev to indicate that this is
after 1.10.0 is out.
There is still a fallback detection in "shared/nm-utils/nm-macros-internal.h",
so that VPN-plugins and applet don't need to bother about adding these
configure checks.
Register empty "NMClient" and "NetworkManager" GIR modules as soon as libnm is
loaded witch gnome-introspection. This prevents the real modules from being
loaded because they would in turn load libnm-glib and abort() and crash.
In particular this prevents the GNOME shell from crashing with
libnm-glib abort and allows gracefully disabling the extensions which
use the obsolete library.
Test:
$ cat test.js
const NM = imports.gi.NM;
print (NM.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
const NMClient = imports.gi.NMClient;
print (NMClient.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
Before:
$ gjs test.js
1
(gjs:16253): libnm-util-ERROR **: libnm symbols detected; Mixing libnm with libnm-util/libnm-glib is not supported
Trace/breakpoint trap (core dumped)
$
After:
$ gjs test.js
1
Gjs-Message: JS WARNING: [test.js 5]: reference to undefined property "SecretAgentGetSecretsFlags"
(gjs:16228): Gjs-WARNING **: JS ERROR: TypeError: NMClient.SecretAgentGetSecretsFlags is undefined
@test.js:5:1
JS_EvaluateScript() failed
When building with -flto, we need to use linker plugins.
In case of binutils' nm, it means to prefer gcc-nm if
available.
Like for ranlib and ar, prefer gcc-nm.
- replace AC_PATH_TOOL() by AC_CHECK_TOOLS(). That is consistent
with what we do for ar,ranlib and suggested on bgo#783311.
- instead of using the variable $BINUTILS_NM, replace it by
$NM, which is more common according to bgo#783311.
- Keep recognizing $BINUTILS_NM environment, which was introduced
by commit 8bc88bcc7c. This is purely to keep previous build
scripts working. Originally I named it "$BINUTILS_NM" because
using $NM in NetworkManager seemed confusing. But well...
https://bugs.gentoo.org/show_bug.cgi?id=620052https://bugzilla.gnome.org/show_bug.cgi?id=782525https://bugzilla.gnome.org/show_bug.cgi?id=783311
After 1.8.0 is released, merge it back into master so that
1.8.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.8.0 and 1.8-rc*.
Also bump the micro version to 1.9.1-dev to indicate that this is
after 1.8.0 is out.
connectivity check functionality should be explicitly set as disabled if
not wanted: this prevents building NM without connectivity check support
without any evident warning on systems where libcurl is not installed.
(cherry picked from commit 4e6967e33d)
Recently we removed libsoup dependency in favor of libcurl.
Connectivity checking functionality was enabled by defaut when libsoup
was detected: do the same now when detecting libcurl.
(cherry picked from commit ad35fbf3a3)
connectivity check functionality should be explicitly set as disabled if
not wanted: this prevents building NM without connectivity check support
without any evident warning on systems where libcurl is not installed.
Recently we removed libsoup dependency in favor of libcurl.
Connectivity checking functionality was enabled by defaut when libsoup
was detected: do the same now when detecting libcurl.
There are very few places where we actually use floating point
or #include <math.h>.
Drop that library, although we very likely still get it as indirect
dependency (e.g. on my system it is still dragged in by libsystemd.so,
libudev.so and libnl-3.so).
With --enable-introspection we generate various targets that either
require perl or xsltproc. Error out when building with introspection
enabled but the programs are not found.
The only reliable way of setting a MAC address for the team is through
the "hwaddr" property in the configuration passed to teamd. In order
to rewrite the configuration we need Jansson support; since it is
already a requirement for teamd, let the team plugin depend on it.
If configure is called without --enable-json-validation or
--disable-json-validation, let's automatically choose a value
depending on the availability of the library.
Otherwise, substitions are not properly expanded.
For example
- "AC_SUBST(nmrundir, '${runstatedir}'/$PACKAGE, [NetworkManager runtime state directory])"
gives ${runstatedir}/NetworkManager/resolv.conf
- "AC_SUBST(nmrundir, "${runstatedir}/$PACKAGE", [NetworkManager runtime state directory])"
gives ${prefix}/var/run/NetworkManager/resolv.conf
The purpose of "rc-manager=symlink" is so that the administrator can point
the "/etc/resolv.conf" as a symlink to a certain file, and thus indicating
that a certain component is responsible to manage resolv.conf, while others
should stay away from it.
For example, systemd-resolved never touches "/etc/resolv.conf", but
expects the admin to setup the symlink appropriately. It also recognizes
whether the symlink points to it's own resolv.conf in /run or to another
component.
Previously, "rc-manager=symlink" would always replace a regular file
with a symlink to "/var/run/NetworkManager/resolv.conf". Only if
"/etc/resolv.conf" is already a symlink somewhere else, NM would not
touch it. This with the exception that if "/etc/resolv.conf" points to
"/var/run/NetworkManager/resolv.conf", it would replace the symlink
with the same link to raise inotify events.
Change behavior so if "/etc/resolv.conf" is already a regular file, keep
it as file.
This means, if you have multiple components that don't care, everybody
can write the "/etc/resolv.conf" (as file) and there is no clear
expressed responsibility.
It was wrong that NetworkManager would convert the file to a symlink,
this should be reserved to the admin. Instead, NetworkManager should
accept that the intent is unspecified and preserve the regular file.
It's up to the admin to replace the symlink to somewhere else (to keep
NM off), or to point it to "/var/run/NetworkManager/resolv.conf", to show
the explicit intent.
The wrong behavior causes dangling symlinks when somebody disables
NetworkManager for good.
https://bugzilla.redhat.com/show_bug.cgi?id=1367551
Building the man pages via xsltproc requires "docbook.xsl"
which is part of docbook.
Previously, we would build the man pages solely based on
"--enable-introspection", which checks for the presence of
xsltproc, but not docbook. This can lead to build failure
when docbook is not available, but "--enable-introspection"
is given.
Instead of adding yet another configure option to fine-tune
and say "--with-docbook --disable-gtk-doc", just simplify it.
Now, documentation (both man pages and setting docs) will be generated
with "--enable-gtk-doc" and "--enable-introspection".
If the documentation is not about to be generated, pre-generated docs
will be installed if they are available. That is commonly the case
with a source tarball, but not with a git checkout.
Finally, if documentation is nither generated nor pre-generated,
no documentation will be installed *duh*.
This removes the possibility to treat man pages separate from settings
docs. Now you either generate both, install both pre-generated, or don't
get any of them.
https://bugzilla.gnome.org/show_bug.cgi?id=778551
`nm` is used by "tools/create-exports-NetworkManager.sh" script.
Alloc configuring an explicit path during configure.
BINUTILS_NM=/usr/bin/nm ./configure
