GitLab

Tracking all windows as application windows makes it possible for the
GtkApplication to terminate at the correct point -- when no windows are
present.

This indicates that a new editor window has been opened, for the
purposes of tracking the windows as GtkApplication windows.

They're offensive.

Brings joy to Thomas while grepping through code.

This communicates that the page has spawned a new editor (e.g. for editing
slave connections). This will allow the GtkApplication to track the editor
windows.

This is not a public API and we aren't using them anywhere.

Doing this for consistency with code where Thomas insists this is a good
idea. Easier than fixing Thomas.

The error argument is never used, don't pretend we handle it and avoid
leaking it. Just dumping the error on the console is still not optimal,
but unconfusing things is a good start.

We use a signal of the same name, and an extra property just messes up
things.

Fixes: 137ec047

None of them actially used.

It's not used anywhere.

!6

The entry never contains a value in such cases. Don't fail the validation.

!9

This is essentially an usability thing that allows system-owned secrets to
be used even when GNOME keyring is not installed.

#3

If getting old secrets fails for whichever reason, get_existing_secrets_cb()
is called with error set and NULL settings (by keyring_find_secrets_cb()).

!4

Handling of nm-connection-editor command line arguments was changed in
f3782da2. Since that commit, most args are handled by `editor_command_line`,
but one (`--keep-above`) is handled by `main`. Unfortunately, if
`--keep-above` appears with other arguments, `main` does not strip it from
argv and parsing in `editor_command_line` fails with "Failed to parse
options".

To handle this, let's just have `editor_command_line` recognize but ignore
`--keep-above` if it encounters it.

#1Signed-off-by: Adam Williamson <awilliam@redhat.com>

"with_appindicator" is the global variable set when parsing command
line arguments. It later results in the initialization of applet's
app-indicator instance. We always should check for INDICATOR_ENABLED(),
not "with_appindicator".

https://bugzilla.gnome.org/show_bug.cgi?id=796258

 We must use premade icons for the indicator VPN case.

 The icons are copies of the original with the padlock pre-composited, because
 indicators can't use pixbufs; we use the suffix -secure.

 This change got introduced with Ubuntu 16.04. Several icon themes have
 upstreamed those -secure icons meanwhile (Numix, MATE Faenza,
 elementaryXubuntu-dark from murrine-themes).

 This patch requires additional icons in nm-applet:

    nm-signal-<xx>.png -> nm-signal-<xx>-secure.png
    nm-device-wired.png -> nm-device-wired-secure.png

 Patch author: Mathieu Trudel-Lapierre <mathieu@canonical.com>

https://bugzilla.gnome.org/show_bug.cgi?id=796258

 Icons were created for Ubuntu and have been obtained from the
 network-manager-applet src:package in Ubuntu. The package maintainer
 applied no specific copyrights to those files. In debian/copyright of
 the Ubuntu package they are covered by this copyright info block:

 Files: *
 Copyright: 2004 - 2015 Red Hat, Inc.
            2005 - 2008 Novell, Inc.
            2001, 2002 Free Software Foundation
 License: GPL-2+

https://bugzilla.gnome.org/show_bug.cgi?id=796258

https://bugs.archlinux.org/task/58767

!2

Fixes: 15ac92e6

!1

The pipeline begins with "build" stage doing a distcheck on Fedora 28
(which is still known to ship libnm-glib) and outputting a tarball
artifact.

The output is then used in the "test" stage.

Some repetition is avoided with YAML map capability, but that's fairly
limited.

Both autotools and meson build/installs are done with both autotools and
meson on latest Fedora (happens to be Fedora 28 too). That seems to be a
reasonable enough for start, given we can't test all possible
combinations.

In future, builds on some older platforms, CentOS and Ubuntu and clang
builds would be nice. Not implemented at this point, but it should be
straightforward enough.

Maybe a build with a Git snapshot of NetworkManager would be useful at
some point, but that's not implemented wither.

g-ir-scanner uses distutils that have an unfortunate misfeature of
inheriting the compiler flags it itself was built with.

This includes the hardening flags that don't work with without
redhat-rpm-build and break with clang every full moon.

A configure check makes it clear about what went wrong in case
introspection is desired, otherwise turns it off.

It's not necessarily present among the packages in a minimal
installation (such as Fedora's docker image). Worse even, libtool just
ends up not linking to some .la libraries.

Don't assume it's there.

It's a not necessarily present among the packages in a minimal
installation (such as Fedora's docker image). Worse even, configure just
ends up passing wrong linker flags on some architectures, without a word
of complain.

Don't assume it's there.

Autoconf installs it on autogen.

https://bugzilla.gnome.org/show_bug.cgi?id=796211