libnm-util/crypto_gnutls.c: In function crypto_encrypt:
  libnm-util/crypto_gnutls.c:245:8: error: variable salt_len set but not used [-Werror=unused-but-set-variable]
    gsize salt_len;
          ^~~~~~~~

See-also: 312c72f7617d974abd9de4218f1e9b920a6a999c

Coccinelle:

  @@
  expression a, b;
  @@
  -a ? a : b
  +a ?: b

Applied with:

  spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .

With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.

Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.

Normalize coding style by removing consecutive empty lines from C
sources and headers.

https://github.com/NetworkManager/NetworkManager/pull/108

There are multiple tests with the same in different directories; add a
unique prefix to test names so that it is clear from the output which
one is running.

Like autotools, use the wrapper script 'run-nm-test.sh' that starts a
separate D-Bus session when needed.

The code was passing the gpointer alias of the GValue, rather than the
GValue* itself. This doesn’t matter normally, but broke an experimental
patch in GLib to remove a cast from G_VALUE_TYPE.

We’ve reverted the patch in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=793186), but this should be
fixed in NetworkManager anyway.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

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

We commonly only allow tabs at the beginning of a line, not
afterwards. The reason for this style is so that the code
looks formated right with tabstop=4 and tabstop=8.

NM_API_VERSION is a better name. It's not the current stable
version, but the version number of the API which the current
NM_VERSION provides. In practice, NM_API_VERSION is either identical
to NM_VERSION (in case of a release) or NM_VERSION is a development
version leading up the the upcoming NM_API_VERSION.

For example, with the new name the check

  #if NM_VERSION != NM_API_VERSION
  # warning this is an development version
  #endif

makes more sense.

We don't need to have two version defines "CUR" and "NEXT".

The main purpose of these macros (if not their only), is to
make NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros work.

1) At the precise commit of a release, "CUR" and "NEXT" must be identical,
because whenever the user configures NM_VERSION_MIN_REQUIRED and
NM_VERSION_MAX_ALLOWED, then they both compare against the current
version, at which point "CUR" == "NEXT".

2) Every other commit aside the release, is a development version that leads
up the the next coming release. But as far as versioning is concerned, such
a development version should be treated like that future release. It's unstable
API and it may or may not be close to later API of the release. But
we shall treat it as that version. Hence, also in this case, we want to
set both "NM_VERSION_CUR_STABLE" and again NEXT to the future version.

This makes NM_VERSION_NEXT_STABLE redundant.

Previously, the separation between current and next version would for
example allow that NM_VERSION_CUR_STABLE is the previously release
stable API, and NM_VERSION_NEXT_STABLE is the version of the next upcoming
stable API. So, we could allow "examples" to make use of development
API, but other(?) internal code still restrict to unstable API. But it's
unclear which other code would want to avoid current development.

Also, the points 1) and 2) were badly understood. Note that for our
previousy releases, we usually didn't bump the macros at the stable
release (and if we did, we didn't set them to be the same). While using
two macros might be more powerful, it is hard to grok and easy to
forget to bump the macros a the right time. One macro shall suffice.

All this also means, that *immediately* after making a new release, we shall
bump the version number in `configure.ac` and "NM_VERSION_CUR_STABLE".

RHEL 7.1 and Ubuntu 14.04 LTS both have this.

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