Like all other keys that can have a default value, substitute the
default only when needed. In this way, we can tell later if the
value comes from configuration file or if it's the default value.
Also, rename CONFIG_PLUGINS_DEFAULT to NM_CONFIG_PLUGINS_DEFAULT.
The DHCP plugins are linked statically and don't have a plugin mechanism
to be loaded from a shared library. Change the _nm_dhcp_client_register()
mechanism to something more static.
Also, only link the plugins into the binary if they are actually
enabled. Previously, they would always be linked in (and always
register themself). However, nm_dhcp_dh*_get_path() would return NULL
which made the plugin unusable.
The autoconf code to detect the DHCP plugins is still not stellar, but
seems to work well enough for now. At least, we log the result of the
detection at the end of the configure-script, so a user can at least
notice what happend.
We want to embed the current commit-id in the ./configure script.
That way the generated ./configure file in the source tarball
references the commit-id from which the tarball was created.
Then, in a second step, a script can check ./configure to find
the parent commit. This is for example done by the 'makerepo.sh'
script.
This is generally useful, and also done by network-manager-applet
and libnl3 projects. Move the function to a separate m4 macro
to reuse it. It should also be re-used in NetworkManager's VPN plugins.
After 1.4.0 is released, merge it back into master so that
1.4.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.4.0 and 1.4.0-rc1.
Also, the closest branch parent of master and nm-1-4 branch
becomes 1.4.0 tag.
Also bump the micro version to 1.5.1-dev to indicate that this is
after 1.4.0 is out, otherwise `git describe` uses the 1.4.0 tag.
Now we have a single file for all suspend APIs and the selection is
done through the preprocessor: remove stale AM_CONDITIONALs and define
SUSPEND_RESUME_UPOWER when needed.
Fixes: c76eb3e8f7
At least, there are assertions that fail and must be fixed.
Still, let's merge the (incomplete) ofono patches early
to have something that can be incrementally improved.
However, for now mark it as experimental and disable it by
default.
This adds two new options to the configure scripts to compile NM,
clients and libraries with the address and undefined-behavior
sanitizers available in recent GCC versions. Clang is not supported at
moment.
We break the aliasing rules in the code, and thus the flag should
always be enabled to prevent wrong optimizations, even without
--enable-more-warnings.
Downstream might want to choose a different default value for
main.rc-manager setting (and it can does so, by compiling with
explicit resolvconf or netconfig support).
Make the default configurable at build-time and also embed it into
the manual page of "NetworkManager.conf".
https://bugzilla.redhat.com/show_bug.cgi?id=1337222
GCC can place each symbols into separate sections making it possible for
ld to discard unneeded sections (and thus symbols afterwards). This achieves
almost the same size benefits as LTO without the huge performance
penalty (and the undefined behavior with -g).
The cost of more section headers in .o files seems to be negligible.
Before:
359.73user 71.94system 1:29.67elapsed 481%CPU (0avgtext+0avgdata 137948maxresident)k
text data bss dec hex filename
2772228 74848 9272 2856348 2b959c src/NetworkManager
With LTO:
740.37user 94.89system 4:13.83elapsed 329%CPU (0avgtext+0avgdata 118316maxresident)k
text data bss dec hex filename
2435437 74224 8704 2518365 266d5d src/NetworkManager
With --gc-sections:
365.63user 72.34system 1:30.12elapsed 485%CPU (0avgtext+0avgdata 138016maxresident)k
text data bss dec hex filename
2498498 74040 8408 2580946 2761d2 src/NetworkManager
This way it's consistently used across all manual page without a need
for XSL templating.
Also, the entities file could in future possibly be used to template the
build-time configurables such as filesystem paths or bug tracker URL.
It should really be in /usr/lib, not /lib. Not a real issue, since the two are
usually links, but the latter is supposably for compatibility only. This also
installs into correct place when configured with a different --prefix.
Choose a new logging format.
- the logging format must not be configurable and it must be the
same for all backends. It is neat that journal supports additional
fields, but an average user still posts the output of plain
journalctl, without "--output verbose" (which would also be hard
to read).
Also, we get used to a certain logging format, so having different
formats is confusing. If one format is better then another, it should
be used for all backends: syslog, journal and debug.
The only question is, what is the best format.
- the timestamp: I find it useful to see how much time between two
events passed. The timestamp printed by syslog doesn't have sufficient
granularity, and the internal journal fields are not readily available.
We used to print the timestamps for <error>, <debug> and <trace>,
but ommited them for <info> and <warn> levels. We now print them for
all levels, which has a uniform alignment.
- the location: the "[file:line] func():" part is mostly redundant
and results in wide lines. It also causes a misalignment of the
logging lines, or -- as I recently added alignment of the location --
it results in awkward whitespace and truncation.
But the location is really just necessary because our logging messages
are bad:
"<debug> [1456397604.038226] (9) 11-dhclient succeeded"
The solution to this is not
"<debug> [1456397604.038226] [nm-dispatcher.c:358] dispatcher_results_process(): (9) 11-dhclient succeeded"
but a properly worded message:
"<debug> [1456397604.038226] dispatcher: request #9, script 11-dhclient succeeded"
- logging-message: we need to write better logging messages.
I like some form of "tags" that are easy to grep:
"platform: signal: link changed: 4: ..."
Downside is, that this is not nice to read as a full sentence.
So, especially for <info> and <warn> logging, more human readable
messages are better.
We should find a compromise, where the log message explains what
happens, but is still concise and contains patterns that are easy
to grep and identify visually.
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00077.html
Sorry, it was not Debian's fault. It is only libnss-devel package on
Ubuntu 12.04/Precise [1].
Revert the workaround and avoid the failure by dropping the version check altogether.
NSS 3.11 is from 2006, it's unlikely a user tries to build current NetworkManager
against such an old version of the library.
[1] https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1547147
This reverts commit d48790cbec.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
These initscripts weren't modified for a long time. Are they just
unused or flawless? It seems they are no longer best-practice
(e.g. NetworkManager supports reloading configuration via SIGHUP,
which none of these scripts implement).
Nowadays some distributions moved to systemd and quite possible
nobody uses these scripts. Also, any potential downstream user
probably has an adjusted copy of them in their repositories.
Just remove them.
https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00003.html
