This is probably a good idea to do to signal there's significant changes in
dependencies to the distro package maintainers with libnm port and associated
changes.
libgnomeui is long deprecated.
There's one functional difference: the choice to save the passwords is gone.
The password flags and saved password should be set in the preferences dialog,
but this commit does not fix that.
It was only possible to set the password from the authentication dialog,
which is not ideal; as it requires a connection attempt.
This adds an input entry along with a primary icon from libnma/libnm-gtk
which allows selecting the backend and flags for the password (system, session
agent, always ask or empty).
They're both the same now. We'll port the new one to libnm in follow-up commits.
NetworkManager 1.2 (which is currently versioned as 1.1.0) is going to bring
some new ABI while still supporting the old one. There's new VPN service and
UI plugin APIs in libnm.
There's one difficulty though -- the connection editor 1.2 will be linked
against libnm and a new libnma library it will provide (as opposed to
libnm-glib and libnm-gtk), thus will be incapable of loading of property
plugins that are linked with the old libraries (due to glib type system
limitations).
However, we must not break support for other connection editors (GNOME control
center, older versions of nm-connection-editor, etc.) therefore we need
to build two versions of the property plugin. NetworkManager 1.2's libnm will
provide a shim that makes it easy.
It's the preferred location for system-provided plugins.
A compatible file in /etc is still kept. Also, the compatibility /etc
file needs to use a full path due to a bug in GNOME Shell.
The full path to a arch-dependent file in a supposedly arch-independent
file is a sin and a multilib violation in some distributions. However.
some pre-release versions of NetworkManager-1.2 as shipped by
distributions require a full path. Let's keep a configure-time option
for that.
It does more than intended; apart from denying messages to that
particular interface it also denies all messages non-qualified with an
interface globally. This blocks messages completely unrelated to
strongSwan's VPN plugin, such as NetworkManager communication with the
VPN plugins.
From the dbus-daemon manual:
Be careful with send_interface/receive_interface, because the
interface field in messages is optional. In particular, do NOT
specify <deny send_interface="org.foo.Bar"/>! This will cause
no-interface messages to be blocked for all services, which is
almost certainly not what you intended. Always use rules of the form:
<deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
We can just safely remove those rules, since we're sufficiently
protected by the send_destination matches and method calls are
disallowed by default anyway.
Closesstrongswan/strongswan#42.
This will ensure the strongSwan NetworkManager plugin will be easily
installable from the app stores such as GNOME Software.
Closesstrongswan/strongswan#41.
The run is aborted after the current scenario. Depending on which
command was interrupted it might be necessary to press CTRL-C multiple
times (e.g. if a later command depends on the interrupted one).
This should fix HTML files and get us some proper console output after
the run.
This avoids having to copy testresults, makes results of cancelled runs
browsable (runs may actually be followed live) and preserves old results
when rebuilding guest images (e.g. when using the build-strongswan script).
The number of consecutive test runs without any intermittent rebuild of the
guest images is also not limited by the image size anymore.
With AC_SEARCH_LIBS() we don't succeed if the searched function is a
built-in as the check uses the wrong signature so the built-in will not
be applied (the warning issued by GCC is "conflicting types for built-in
function '...'"). So even if not required, libatomic will be linked if
it is found, which could be problematic if compiling on a separate host
and the target host does not have libatomic installed.
Also, some tests showed that it's more likely that __atomic_and_fetch()
requires linking libatomic than __atomic_load_n() does.
References #1533.
These seem to indicate the major and minor version of the protocol, like
e.g. for the DPD vendor ID. Some implementations seem to send versions
other than 1.0 so we just ignore these for now when checking for known
vendor IDs.
Fixes#2088.
Tobias Brunner