gi now emits a warning when not loading a specific library
version [1]:
./generate-setting-docs.py:21: 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.
from gi.repository import NM, GObject
Seems require_version() is reasonably old to just always use it without
breaking on older versions [2].
[1] Related: https://bugzilla.gnome.org/show_bug.cgi?id=727379
[2] https://git.gnome.org/browse/pygobject/commit/?id=76758efb6579752237a0dc4d56cf9518de6c6e55
(cherry picked from commit 8d1233e67e)
We now (since 3272ff6 libnm/libnm-glib: don't quit in the middle of asking for
secrets) always hook on the quit timer when NM asks the plugin if it needs
secrets. The timer is 20 seconds, which seems too short.
Let's make it three minutes. Don't bother adding another timer or using a
distinct timeout: it does no harm for the plugin to remain unused for three
minutes on a bus.
Another option would be to completely unhook it; however the plugin wouldn't
learn if the user cancelled the NM's secrets request and would remain unused
on the bus forever.
(cherry picked from commit b1512221bc)
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
(cherry picked from commit 7bf10a75db)
Add functions nm_utils_enum_to_str() and nm_utils_enum_from_str()
which can be used to perform conversions between enum values and
strings, passing the GType automatically generated for every enum by
glib-mkenums.
(cherry picked from commit 8be9814793)
Python is just too slow on some machines. Needed around twice the previous
limit on BCM2835 with Pidora 20, let's add some safety margin too.
(cherry picked from commit 81cc4d27b1)
This introduces a global metered property which makes easier for
clients to obtain the metered status of the current primary
connection.
(cherry picked from commit 04d5804dd5)
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
(cherry picked from commit 6f647fe689)
If the VPN plugin terminated and the user started it again, then the
quit timer will still be running and it sometimes happens that the
VPN plugin will quit while the UI is asking the user for secrets.
That's not very nice, so don't do that.
Reproducer: while connect to the VPN, suspend your laptop. Then
resume it, and immediately re-start the VPN connection. Watch the
secrets dialog disappear within a very short time.
https://bugzilla.gnome.org/show_bug.cgi?id=752237
This is done to silence coverity. In the dispatcher the existence of the
key is checked before and we're fine with leaving the value untouched
in the vpn-plugin-old.
(cherry picked from commit a9996c4f1d)
On master, we added new symbols
nm_setting_connection_autoconnect_slaves_get_type()
nm_setting_connection_get_autoconnect_slaves()
in the libnm_1_2_0 section.
It is wrong to extend the linker section of a stable
release. When backporting the patch we must create a
new linker section.
Move the symbols to the libnm_1_0_4 section. Note that
master (1.1) also defines the symbol there, so that the
upgrade path works.
https://bugzilla.gnome.org/show_bug.cgi?id=751535
Fixes: 408b631673
The property is used for controlling whether slaves should be brought up with
a master connection. If 0, activating the master will not activate slaves.
But if set to 1, activating the master will bring up slaves as well.
The property can have the third state (-1), meaning that the value is default.
That is either a value set in the configuration file for the property, or 0.
(cherry picked from commit 6caafab258)
Add a function to get a concise representation of the
device type.
libnm already has nm_device_get_type_description() for that
and it is shown by
nmcli -f GENERAL.TYPE device show
Reimplement that function for nm-core. Just take care that the
two implementations don't diverge.
(cherry picked from commit e9e9d44468)
Even if we're running the tests as root we still want to use the mock
service instead of whatever version of daemon runs on the test host.
(cherry picked from commit 02e3d6c286)
The previous patch 9ffcecf86a was
completely wrong.
It tried to fix callers that provided a floating GVariant reference.
We require the caller to unref @secrets, so the correct fix it to
ensure that the reference is not floating.
Fixes: 6793a32a8c
(cherry picked from commit 9ffcecf86a)
(cherry picked from commit 2071e4794f)
(process:6888): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GDBusProxy'
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x0000003148e50c70 in g_logv (log_domain=0x3149a3b224 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffda70) at gmessages.c:1046
#1 0x0000003148e50eaf in g_log (log_domain=log_domain@entry=0x3149a3b224 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x3149a42690 "invalid unclassed pointer in cast to '%s'") at gmessages.c:1079
#2 0x0000003149a34171 in g_type_check_instance_cast (type_instance=type_instance@entry=0x6fc530, iface_type=<optimized out>) at gtype.c:4030
#3 0x00007ffff7d6b016 in nmdbus_settings_connection_call_get_settings_finish (proxy=0x6fc530, out_settings=out_settings@entry=0x7fffffffdbb8, res=res@entry=0x6fe150, error=error@entry=0x0)
at nmdbus-settings-connection.c:1303
#4 0x00007ffff7ce8813 in updated_get_settings_cb (proxy=<optimized out>, result=0x6fe150, user_data=user_data@entry=0x6fc650) at nm-remote-connection.c:588
#5 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe150 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#6 0x000000314a2df47c in reply_cb (connection=<optimized out>, res=0x6fe0e0, user_data=user_data@entry=0x6fe150) at gdbusproxy.c:2623
#7 0x000000314a27640d in g_simple_async_result_complete (simple=0x6fe0e0 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#8 0x000000314a2d48cc in g_dbus_connection_call_done (source=<optimized out>, result=<optimized out>, user_data=user_data@entry=0x7fffec01a320) at gdbusconnection.c:5502
#9 0x000000314a27640d in g_simple_async_result_complete (simple=0x6e5f40 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#10 0x000000314a27647c in complete_in_idle_cb (data=0x6e5f40) at gsimpleasyncresult.c:775
#11 0x0000003148e49b6b in g_main_context_dispatch (context=0x687970) at gmain.c:3064
#12 0x0000003148e49b6b in g_main_context_dispatch (context=context@entry=0x687970) at gmain.c:3663
#13 0x0000003148e49f08 in g_main_context_iterate (context=0x687970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3734
#14 0x0000003148e4a232 in g_main_loop_run (loop=0x687a80) at gmain.c:3928
#15 0x00000000004136a1 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:632
(gdb)
(cherry picked from commit 9d3b31e1ae)
When a new connection is activated and presently active connection goes away,
the active-connection-removed signal is not emitted for the old connection.
This is what happens:
1.) Initially, nm-manager::active-connections = [ActiveConnection/old]
2.) First PropertyChange is signalled for the new connection addition:
nm-manager::active-connections = [ActiveConnection/old,ActiveConnection/new]
This triggers load of ActiveConnection/new object.
3.) Another PropertyChange is signalled for the old connection removal:
nm-manager::active-connections = [ActiveConnection/new]
This removes the ActiveConnection/old object from
nm-manager::active-connections and enqueues active-connection-removed
signal. The signal is not emmitted as there's a reload from 2.) in progress.
4.) ActiveConnection/new reload finished
object_property_complete() compares
[ActiveConnection/old,ActiveConnection/new] from its odata to current
nm-manager::active-connections and incorrectly concludes that
ActiveConnection/old was just added and removes the enqueued
active-connection-removed signal.
This patch fixes the issue by remembering the original
nm-manager::active-connections property value at 2.).
[thaller@redhat.com: fixed an integer overflow and odata->array unreffing]
https://bugzilla.redhat.com/show_bug.cgi?id=1079353
(cherry picked from commit dba4e8ece8)
Otherwise the compiler complains that they could be left uninitialized in case
the function returns too early.
Fixes: 76745817c3
(cherry picked from commit 2981839bde)
Otherwise it does not register the "options" property and an assertion fails
when the user prints connection that has DHCPv6 options:
$ LIBNM_GLIB_DEBUG=properties-changed nmcli c show yolo
...
libnm-Message: Property 'options' unhandled.
...
(process:13522): libnm-CRITICAL **: nm_dhcp_config_get_options: assertion 'NM_IS_DHCP_CONFIG (config)' failed
(cherry picked from commit 4615d74de0)
Error: INFINITE_LOOP (CWE-835): [#def17]
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:93: loop_top: Top of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:94: loop_bottom: Bottom of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:93: loop_condition: If "notified" is initially true then it will remain true.
Error: INFINITE_LOOP (CWE-835): [#def18]
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_top: Top of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:192: loop_bottom: Bottom of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_condition: If "result & NOTIFY_MASK" is initially true then it will remain true.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_condition: If "result & SIGNAL_MASK" is initially true then it will remain true.
(cherry picked from commit ce6323d4df)
I had argued for putting the local symbols in their own section, since
it doesn't make sense to have local symbols introduced in 1.2 in the
libnm_1_0_0 section... but apparently even if the section has no
exported symbols, rpm's find-provides still picks it up if it's there,
creating an ugly additional "provides" for libnm. So get rid of that.
(cherry picked from commit 8d96273870)
VPN connections always return true for nm_connection_need_secrets(), but the
documented behavior of GetSecrets() is just to return any secrets we have
(otherwise nmcli c --show-secrets would not be useful for VPN connections).
We now also use a similar function in VPN plugins. It makes
sense to provide a generic implementation in libnm.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=740783
In general, we shouldn't end up with an unencrypted copy of a
certificate key anyway, so this function ought to be unnecessary (or
at least, not broadly useful enough to be in the public API).
nm-applet's GConf migration tool needs it, but that will eventually go
away, and until then it can just use libnm-util.
