We have generated headers, and non-generated.
We have public headers and internal headers.
We have headers/sources for libnm-glib and libnm-glib-vpn.
We want that non-generated files depend on generated files.
Thus, reorder it all and assign the groups to different variables.
Source files like libnm/nm-client.c include introspection files like
nmdbus-manager.h. These files are part of BUILT_SOURCES, which is
a pre-requisite to "all" target.
However, that is not sufficient for
./autogen --enable-gtk-doc && make dist
Generating the docs, requires man/nm-settings.xml. That is only present
when
- ./configure --enable-gtk-doc --with-introspecton
- in a dist-tarball, contrary to a git-tree
Only create docs, when we also regenerate the manuals (BUILD_SETTING_DOCS).
That is, you can no longer generate docs, by relying on the pre-generated
manual pages.
If you want to generate docs, you have to regenerate the manual pages
as well.
Previously, doing the following in a git-tree failed:
$ git clean -fdx
$ ./autogen.sh --enable-gtk-doc --enable-introspection=no && make
...
make[2]: Entering directory './NetworkManager/docs/api'
DOC Preparing build
DOC Scanning header files
DOC Introspecting gobjects
DOC Building XML
DOC Building XML
make[2]: *** No rule to make target '../../man/nm-settings.xml', needed by 'html-build.stamp'. Stop.
make[2]: Leaving directory './NetworkManager/docs/api'
With systemd < 219, restarting the journald service closes the stdout
and stderr streams associated with services.
The NM process has SIGPIPE ignored, but g_spawn_sync()/g_spawn_async()
re-enable it and so any child executed with those functions will
terminate by default if it tries to log anything to stdout/stderr.
The teamd instance launched by NM is affected by this problem since it
writes debug messages before actually ignoring SIGPIPE.
To fix this, use the @child_setup callback of g_spawn() to ignore
again SIGPIPE in the child process.
https://bugzilla.redhat.com/show_bug.cgi?id=1393853
Apparently, the client is used by the services we depend on (firewalld),
and an attempt to start the service would deadlock them.
This was an accidental change anyway.
Related firewalld change: https://github.com/t-woerner/firewalld/pull/171
Otherwise its path remains visible on D-Bus despite the object is gone,
making libnm sad and grumpy:
libnm-WARNING **: no object known for /org/freedesktop/NetworkManager/AccessPoint/666
Otherwise there is a warning:
from gi.repository import GLib, NM
__main__:1: PyGIWarning: NM was imported without specifying a version first. Use gi.require_version(NM, 1.0) before import to ensure that the right version gets loaded.
The GDBusObjectManagerClient's control proxy seems to leak some bits. Not sure
why; but certainly not our fault since it's a private object and the
manager object itself gets finalized.
Before switching to the ObjectManager, the D-Bus property was used to
decide the actual type of the device and the property set manually by
each subclass in its _init() function. Now we determine objects type
based on their D-Bus interface and therefore we can handle the
property like all others, ensuring that we return a known value in
get_property() to avoid warnings in GLib.
This fixes the missing initialization of the property which causes
regressions on clients as nm-applet.
Fixes: 1f5b48a59e
nm_utils_hexstr2bin() is quite similar to hwaddr_aton(), and
nm_utils_bin2hexstr() is similar to _bin2str_buf().
Move them close to each other. Maybe one day they should be
consolidated. But their API is slightly different, so the
consolidation would require some effort.
For now, just move them close to each other, so that it's
clearer that two similar (but distinct) functions exists.
On some architectures, it seems we don't properly expose
the symbol of these static variables from NetworkManager
binary.
Just avoid that and don't instead use a static array
inside the device plugin itself.
While at it, make the arrays all const, which possibly allows
the linker to put those symbols in the read-only section.
They indicate a server bug (a dangling path of an object that does not
exist). The best we can do probably is to just ignore them and warn.
Based-on-patch-by: Dan Williams <dcbw@redhat.com>
It could be that the client is just newer and it's just too harsh to
fail the whole request. Leave the unknown permission in unknown and
possibly proceed filling in the rest.
The GetPermissions call is very expensive (~400ms here, an extra
NM->polkit call for every known permission while polkit being really
slow to answer) yet seldom needed.
There's no methods to access the permissions -- they're only
communicated via signals.
Unfortunately, we don't know when a signal is hooked, so we still need
to kick of the call. Nevertheless, we don't need to wait for it to
finish.
When the device has an IP interface different from the main one, we
previously took the MTU saved in priv->mtu (which is the MTU initially
set on the underlying interface) and applied it to the IP interface.
This is wrong as it forces the two MTUs to be equal and breaks
connectivity for devices with encapsulation (as PPP). Instead, track
the two MTUs in different variables.
https://bugzilla.redhat.com/show_bug.cgi?id=1385198
- a key
FOO=''
would still allocate a temporary GString and return the allocated
empty string. Don't do that. This saves the g_free() in
svGetValueString() for this common case. We should return
an allocated string only if it is necessary. It is not necessary
for the "" case, and it is inconsistent.
- when returning an empty string, always return the static string "".
No need to seek to the end of value, and return a pointer to that
string.
This happens for example in the case
FOO= # empty value, but trailing stuff
FOO=""
FOO=$'\Uxhallo'
