Some distributions (Debian and Ubuntu in particular) will soon use systemd's
logind, but not its init part. Check for a recent enough "libsystemd-login"
version instead of "systemd", as suspend/resume and inhibitors are all in
logind.
https://bugzilla.gnome.org/show_bug.cgi?id=698947
DocBook is not my favorite thing in the world, but it's
<lots-of-emphasis>far</lots-of-emphasis> saner than troff. Some style
parts cribbed from systemd.
This is preparatory work for actually improving the content of the
man pages.
get_virtual_iface_name() returns an allocated interface name which
we must free; that wasn't being done when attempting to find the
interface for which a virtual interface needs to be created. Also
throw in a cleanup for the given-device-doesn't-exist case just to
make it clearer when the interface name is freed.
When 'connection' and 'new_connection' arguments are the same object make the
function no-op and simply return true. Otherwise 'connection's settings are
removed, making it invalid.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
If a SOURCES variable changes, we need to recheck the generated files,
since a file may have been removed from SOURCES, but still be
referenced in a previously-generated -enum-types.c file, etc. So make
these generated files depend on Makefile.
Also, update spacing of silent rules to match current automake.
The various need_secrets() implementation do allocate a fresh GPtrArray, but
add static strings to them without dup'ing. Thus callers must _not_ free the
array elements, only the array itself. Adjust documentation and annotations
accordingly.
Also adjust the corresponding comment in the goi-list-connections.py example.
https://bugzilla.gnome.org/show_bug.cgi?id=698175
Use the correct annotation for vfuncs, so that NMClient.SecretAgent becomes
introspectable.
Use "self" as the first argument of the vfuncs in their declarations, to match
the actual name in nm-secret-agent.c. This avoids warnings from g-ir-scanner.
https://bugzilla.gnome.org/show_bug.cgi?id=698184
Convenience function to replace settings in one conneciton with settings
from another, without having to go through the nm_connection_to_hash()
steps, which are just inefficient and kinda pointless.
Agents are expected to save any new/updated secrets returned to
NetworkManager from a GetSecrets call, as it would be silly to return
those same secrets right back to the agent via SaveSecrets when the
agent is perfectly capable of saving the secrets itself without
round-tripping to NetworkManager and back.
We want to free the element data, then remove the element from the
list. Instead the code freed the element data, then treated the
element data pointer as a GSList link, which is completely wrong.
Settings with all-default values are not written to reduce
complexity of the keyfile (and be more human-readable friendly)
and that includes VLAN settings with a VLAN ID of zero. So
when reading this file back, if there is no 'base type' setting
(eg, the setting specified by the connection::type property)
then just add that setting. nm_connection_verify() will catch
cases where an empty 'base type' setting is invalid.
The code to check if an ethernet device had a matching connection was
not taking NMSettingConnection:interface-name into account, meaning it
might think a device had a matching connection when that connection
actually only matched a different device.
Fix this by calling nm_setting_connection_get_interface_name() rather
than nm_connection_get_virtual_iface_name() (which would always be
NULL for ethernet connections anyway).
Also, simplify the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=696722
Add these aliases for the setting names '802-3-ethernet',
'802-11-wireless', and '802-11-wireless-security' and write them by
default. It's much friendlier for administrators to type, and a lot
less ugly.
Also works for:
[connection]
type=ethernet
The TRUE return got missed in the original commit of the AvailableConnections
code. _try_add_available_connection() returns TRUE if the connection was
added and FALSE if it wasn't, to allow the caller to optionally emit the
PropertiesChanged signal. Only TRUE was never returned...
