The problem is that you cannot be sure which patches
were applied on top of a source tree, so the __nm_git_sha
value is unreliable.
Also, after running autoreconf during the package build,
NM_GIT_SHA is reset as well.
- when user provided a $SOURCE argument, do call abs_path on
it. abs_path allows the user to provide relative paths in
the original directory.
- don't call abs_path on "$GITDIR/NetworkManager-$VERSION".tar.xz
abs_path is there to verify user input and it will abort the script
if the file doesn't exist.
- when creating a temporary tarball via git-archive, put it
into the output directory and not overwriting files in
$GITDIR.
- fix abs_path to return an error code and let callers abort
the script
- add a new parameter $SOURCE_FROM_GIT so that you can control
whether git-archive is used. You can now specify either $SOURCE
or $SOURCE_FROM_GIT. In case of absence of both, it tries to
detect a tar file in the $GITDIR directory.
Fixes: 9e9ec1a3da
The link_stats structure grew between 4.5 and 4.6 and this would cause
the messages to me ignored when compiling with 4.6 headers and running
on 4.5.
https://bugzilla.gnome.org/show_bug.cgi?id=764332
Make sure there's always the device and connection as well as the reason
when a slave activation fails. The slave connection could in fact be
chosen automatically on "nmcli d connect" and the user might not be
aware activation of which connection was attempted:
$ nmcli d connect enp0s25
Error: Device activation failed: Master connection not found or invalid
GVariantBuilder doesn't care if you give it multiple dict entries with
the same key. But that causes duplicate dict entries in the legacy
D-Bus PropertiesChanged signals that NM emits. So instead go back to
a hash table to ensure that any previous value is dropped in favor of
the new one.
When porting to GDBus property change notifications were converted from a
hash table to a GVariantBuilder. GVariantBuilder doesn't care about
duplicated properties in the dict so each g_object_notify() will add
an additional item with possibly different values:
signal time=1458571005.592811 sender=:1.10 -> destination=(null destination) serial=64451 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged
array [
dict entry(
string "ActiveConnections"
variant array [
object path "/org/freedesktop/NetworkManager/ActiveConnection/19"
object path "/org/freedesktop/NetworkManager/ActiveConnection/18"
object path "/org/freedesktop/NetworkManager/ActiveConnection/15"
object path "/org/freedesktop/NetworkManager/ActiveConnection/0"
]
)
dict entry(
string "ActiveConnections"
variant array [
object path "/org/freedesktop/NetworkManager/ActiveConnection/24"
object path "/org/freedesktop/NetworkManager/ActiveConnection/19"
object path "/org/freedesktop/NetworkManager/ActiveConnection/18"
object path "/org/freedesktop/NetworkManager/ActiveConnection/15"
object path "/org/freedesktop/NetworkManager/ActiveConnection/0"
]
)
]
Fix that by not emitting notify events for the manager's ActiveConnections
property until the property has actually been updated in active_connection_add().
The unexport also isn't required for VPN connections since it will get
unexported when it's disposed after _internal_activation_failed() gets called.
We cannot simply compare the single values of option hashes to match
connections because some keys are equivalent to others and also
because keys having a default value should be ignored.
Add the compare_property method to implement custom comparison logic.
When a value of a TYPE_BOTH option is read back from kernel it
contains both string and numeric values ("balance-rr 0"), so we must
chop off the number before adding the option to the setting. Also
change the default values of options to the string form so that the
option matching logic works.
The bond 'arp_ip_target' option contains a list of comma-separated IP
addresses; but comma is also used to separate options and so at the
moment it is not possible to specify multiple IPs as the command
$ nmcli c m b1 bond.options \
mode=0,arp_interval=1,arp_ip_target=1.1.1.1,2.2.2.2
interprets 2.2.2.2 as the next option.
Allows spaces to be used as separators for the IPs of the
'arp_ip_target':
$ nmcli c m b1 bond.options \
"mode=0,arp_interval=1,arp_ip_target=1.1.1.1 2.2.2.2"
This can regularly happen when a virtual device depends on a parent/master
that is not yet created. We will retry later when the parent is ready, so
logging a warning about it is wrong and confusing.
The name_owner_chagned() unregisters the agent if NetworkManager goes away and
nmc_cleanup() also tries to unregister an agent, resulting in an assertion
failure:
# nmcli c up conn666
<daemon terminates>
Error: Connection activation failed: Message recipient disconnected from message bus without replying
(process:8746): libnm-CRITICAL **: nm_secret_agent_old_unregister: assertion 'priv->registered == TRUE' failed
_internal_unregister() already contains a priv->registered check and raising an
error on duplicate unregister attempt from a daemon after a restart is not a
problem either, since nmc_cleanup() doesn't care about the error returned
on teardown anyway.
We actually don't want to understand these options unless the legacy
*-slave types are used. The properties should be used directly instead.
https://bugzilla.gnome.org/show_bug.cgi?id=748302
This basically undoes most of what has been done in commit 00e0fffea2.
If we want to ensure that we create only one single instance of
NMPolicy, just don't create multiple instances. The nm_policy_new()
method should not be restriced and behave like other *new() functions
and create a new object as requested.
Add internal functions _nm_connection_replace_settings() and
_nm_connection_new_from_hash() that cannot fail.
Altough they are not public API, we have to expose them via
libnm-util.ver so that they can be used from libnm-glib.
Warnings aren't great, especially if they can realistically be triggered
by a newer NetworkManager version. Just accept what we can and ignore
the rest silently.
There is no excuse for clients to send connections to NetworkManager
that have invalid/unknown fields. Just reject them.
This is a dangerous change, because we might now reject connections
that we were accepting previously. Who know what clients were sending
and it used to work.
AddAndActivateConnection is allowed to provide an incomplete connection
that will be completed by NetworkManager. That is, a connection that
does not verify.
But we still want to catch invalid properties or unknown setting types.
Thus, we want to reject invalid partial connections.
This possibly rejects invalid requests from clients that were accepted
before. Thus this change has the potential to break misbehaving clients.
