As build-requirement, we either require
- python2 with python-gobject-base
- python3 with python3-gobject-base
Previously, we would require that a plain `python` gives the desired
interpreter version.
If somebody's "/usr/bin/env python" however points to a different
python version, there was no easy way to change it -- aside
resetting the $PATH variable to some desired "python" binary.
Now, you can specify it during configure:
./configure PYTHON=python3 ...
This especially matters, if you only have python3-gobject-base
installed, you /usr/bin/python is a symlink to python2.
https://bugzilla.gnome.org/show_bug.cgi?id=775768
Similar to systemd's PROTECT_ERRNO. The difference it, that it doesn't
treat the auto-variable as internal, so it is allowed to use it. E.g.
if (!(fd = open (...)) {
NM_AUTO_PROTECT_ERRNO (errno_saved);
printf ("error: %s", g_strerror (errno_saved));
return FALSE;
}
We already have gs_fd_close, which however doesn't preserve
errno and only checks for fd != -1. Add our own define.
Downside is, we have to include stdio.h and errno.h,
which effectively ends up to be included *everywhere*.
We usually don't build NM with g_assert() disabled (G_DISABLE_ASSERT).
But even if we would, there is no assertion macro that always evaluates
the condition for possible side effects.
I think that is a useful thing to have.
It was a macro to pass on the non-const-ness of the argument, but
that just doesn't make sense.
That is a signature
char *nm_str_not_empty (char *)
does not make sense, because you cannot transfer ownership
conditionally without additional checks to avoid a leak. Which makes
this form is pointless. For example:
char *
foo (void)
{
char *s;
s = _create_value ();
return nm_str_not_empty (s); /* leaks "" */
}
g_assert() uses G_LIKELY(), which in turn uses _G_BOOLEAN_EXPR().
As glib's version of _G_BOOLEAN_EXPR() uses a local variable
_g_boolean_var_, we cannot nest a G_LIKELY() inside a G_LIKELY(),
or inside a g_assert(), or a g_assert() inside a g_assert().
Workaround that, by redefining the macro.
I already encountered this problem before, when having a nm_assert()
inside a ({...}) block, inside a g_assert(). Then I just avoided that
combination, but this situation is quite easy to encounter.
When a VPN plugin logs to syslog(), it should not use the syslog
levels that were passed in by NetworkManager directly. Instead,
it must map LOG_NOTICE to LOG_INFO and LOG_INFO to LOG_DEBUG.
Add a utility function does gets that right.
- reorder entries in src/Makefile.am so that general names
are all at the beginning (AM_CPPFLAGS, sbin_PROGRAMS)
and the names for a certain library/binary are grouped
together
- have libNetworkManager.la reuse libNetworkManagerBase.la.
- let all components in src/Makefile.am use the same AM_CPPFLAGS,
except libsystem-nm.la.
- move callouts/nm-dispatcher-api.h to shared/ directory. It
is obviously not internal API to callouts, and callouts is
not a library. Thus, the right place is shared/.
Soon we will add proxy support where VPN plugins set a property
NM_VPN_PLUGIN_CONFIG_PROXY_PAC.
All a VPN plugin needs to make use of this new setting is the
NM_VPN_PLUGIN_CONFIG_PROXY_PAC define.
We don't want that older plugins (still compatible with libnm 1.2 API)
require a new API only for this define. Define it instead in
"shared/nm-utils/nm-vpn-plugin-macros.h" as fallback.
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00154.html
When using g_return_val_if_reached(), the default macro would include
the function name. This name is increasing the binary size. Replace
it in non-debug builds.
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
We use statement expressions all over the place without explicitly
marking them. If that would be a problem, we'd have to change a
*lot* of code. We simply require that as a mandatory feature from
our compiler.
"nm-glib.h" is the most basic header, the one we cannot do without.
("nm-default.h", is already more generic, the one which every common
source file in NetworkManager repository should include).
Let "gsystem-local-alloc.h" be included by "nm-glib.h" and nowhere
else.
This file is only used by plugins and copied between them.
It's purpose is to contain general utility functions that are
only relevant for implementing NetworkManager's VPN plugins.
In principle the utility functions could be part of libnm, however,
there are a few problems with that:
- if they are part of libnm, adding and using a new utility function
requires the plugin to bump the required libnm version. Since you
usally can work around/reimplement utility functions, this results
in not using the API from libnm, not adding the API to libnm,
and reimplementing it over and over in the plugin.
- plugins compile both against libnm and libnm-glib. Thus, either
the utility function would also be needed in libnm-glib, or again,
it is not usable by the plugin.
We must avoid that the utility functions diverge and no local
modifications to these files should be made in the plugin.
Instead, one special location of the utility functions shall be
extended and re-imported (copied) to the plugin as needed.
Add the files to NetworkManager's repository. Although they are not
needed for NetworkManager itself, they are a different API provided
by NetworkManager. An API that is reused and shared by copying the files
around.
