libnm-core/nm-setting-bond.c:502:1: error: ‘static’ is not at beginning of declaration [-Werror=old-style-declaration]
const static struct {
^~~~~
In file included from clients/cli/common.c:32:0:
./clients/common/nm-vpn-helpers.h:27:1: error: ‘typedef’ is not at beginning of declaration [-Werror=old-style-declaration]
} typedef VpnPasswordName;
^
./src/nm-config-data.h:163:1: error: 'const' type qualifier on return type has no effect [-Werror,-Wignored-qualifiers]
const guint nm_config_data_get_connectivity_interval (const NMConfigData *config_data);
^~~~~~
Fix it by converting the macro to an inline function. It's anyway
nicer.
$ make src/src_libNetworkManagerBase_la-main-utils.lo
CC src/src_libNetworkManagerBase_la-main-utils.lo
In file included from ./shared/nm-utils/nm-macros-internal.h:29:0,
from ./shared/nm-default.h:178,
from src/main-utils.c:22:
src/main-utils.c: In function ‘nm_main_utils_setup_signals’:
./shared/nm-utils/nm-glib.h:144:36: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
&& glib_micro_version >= (micro))))
^
src/main-utils.c:82:6: note: in expansion of macro ‘nm_glib_check_version’
if (nm_glib_check_version (2, 36, 0)) {
^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Makefile:12312: recipe for target 'src/src_libNetworkManagerBase_la-main-utils.lo' failed
priv->path_cost and priv->priority can only be set as GObject properties,
which already does the same range check. Hence, the checks are never reached.
This also avoids a compiler warning:
libnm-core/nm-setting-bridge-port.c: In function ‘verify’:
libnm-core/nm-setting-bridge-port.c:132:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
if (priv->path_cost > BR_MAX_PATH_COST) {
^
The warning seems questionable and overly strict.
For now, just disable it to allow building with gcc7.
src/systemd/src/basic/time-util.c: In function ‘format_timespan’:
src/systemd/src/basic/time-util.c:509:46: error: ‘%0*lu’ directive output between 1 and 2147483648 bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-truncation=]
"%s"USEC_FMT".%0*"PRI_USEC"%s",
^~~~
src/systemd/src/basic/time-util.c:509:60: note: format string is defined here
"%s"USEC_FMT".%0*"PRI_USEC"%s",
src/systemd/src/basic/time-util.c:509:46: note: directive argument in the range [0, 18446744073709551614]
"%s"USEC_FMT".%0*"PRI_USEC"%s",
^~~~
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00001.html
The -Wimplicit-fallthrough=3 warning is quite flexible of accepting
a fall-through warning.
Some comments were missing or not detected correctly.
Thereby, also change all other comments to follow the exact
same pattern.
It's not used anymore. Which is a good thing, because if it was used
we'd have to get rid of the uses.
It did accept a whitespace separated string for an argument, which is
never useful for us; it indicated error either on g_spawn_sync()
failure or an error status code of the program spawned, but only set the
error in the former case which had let to errors.
The would would be a bit nicer place without it.
(But not much)
nm_spawn_process() only sets error if the g_spawn_sync() itself fails,
not when the program ran returns a non-zero code.
<debug> [148 059915.1567] dns-mgr: update-dns: updating resolv.conf
<info> [148 059915.1568] dns-mgr: Removing DNS information from /usr/bin/resolvconf
No resolv.conf for interface NetworkManager
Thread 1 "NetworkManager" received signal SIGSEGV, Segmentation fault.
0x0000555555 7c325 in nm_dns_manager_end_updates
1532 _LOGW ("could not commit DNS changes: %s", error->message);
(gdb) bt full
#0 0x0000555555 7c325 in nm_dns_manager_end_updates
error = 0x0
When using nm-online -t N, the countdown shows "0s" during the last second.
The countdown value should be rounded up so that "0s" is only shown when the
timeout is actually elapsed.
https://bugzilla.gnome.org/show_bug.cgi?id=778093
The function is used, among others, in the get_property() of many
objects to return a boxed strv from a list. The default value for a
boxed strv property is NULL, but _nm_utils_slist_to_strv() returns a
pointer to an array with zero elements when the list is empty.
Change the function to return NULL if the input list is empty.
Moving nm-online to async init introduced various issues:
- with a timeout of zero, nm-online would terminate with failure
before initializing the NMClient instance.
- add a timeout for safeguarding the async creation of NMClient
- fix adding trailing newline for the progress bar.
While at it, refactor:
- use defines for the exit codes
- don't use exit(), but instead always properly quit the mainloop
and cleanup all resources.
- in non-quiet mode, print the result [online] or [offline] at
the end.
Fixes: c5f17a97eahttps://bugzilla.gnome.org/show_bug.cgi?id=777914
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
c5f17a97ea changed nm-online to determine
the status asynchronously, however this introduced a regression with
"nm-online -x -q" when there is connectivity.
if ( state == NM_STATE_CONNECTED_LOCAL
|| state == NM_STATE_CONNECTED_SITE
|| state == NM_STATE_CONNECTED_GLOBAL) {
data->retval = 0;
g_main_loop_quit (data->loop);
}
}
if (data->exit_no_nm && (state != NM_STATE_CONNECTING)) {
data->retval = 1;
g_main_loop_quit (data->loop);
}
After setting data->retval = 0 in the "state is connected" branch, the
function falls through to the "exit_no_nm and !connecting" branch,
overwriting data->retval. This causes "nm-online -x -q" to incorrectly
report an offline state.
Adding an explicit "return;" after any state where data->retval is set
ensures that the value isn't overwritten before main() uses it.
Fixes: c5f17a97eahttps://mail.gnome.org/archives/networkmanager-list/2017-January/msg00058.html
If the connection spontaneously disappears (perhaps along with the whole
daemon on crash) while we're deleting it, then the removal callback
would free up the context structure the delete operation is using.
Let's cancel the in-flight delete operations so that they won't touch
the structure after it's gone.
After 1.6.0 is released, merge it back into master so that
1.6.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.6.0 and 1.6-rc*.
Also bump the micro version to 1.7.1-dev to indicate that this is
after 1.6.0 is out.
The public property NM_DEVICE_ACTIVATION_REQUEST exposes the exported
D-Bus path. So, it's not sufficient to emit property changed signals
when changing the priv->act_request pointer, we must also react on
exporting/unexporting.
It's not clear whether this fixes an actual bug. Maybe, we never
export/unexport priv->act_request while the device tracks it.
But the code is pretty hard to follow and it's hard to verify
whether this is the case.
By hooking up to "notify::path", we can easily verify that such
a situtation cannot arise.
(cherry picked from commit 9ae5e6a54d)
If a slave device activates, we should keep the master up even though it
was taken over before.
This fixes an issue, where a single slave to a master would be
reactivated after a daemon restart. The daemon restart would cause the
master to be treated externally created (would go unmanaged when all the
slaves are gone) while the reactivation would leave the master without
slaves for a while.
(cherry picked from commit b605fb2712)
