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

The libnm API fir checkpoints was only introduced with 1.11. It
is not yet stable, so there is still time to adjust it. Note that
this changes API/ABI of the development branch.

Changes:

- we only add async variants of the checkpoint functions. I believe
  that synchronous D-Bus methods are fundamentally flawed, because
  they mess up the ordering of events.
  Rename the async functions by removing the "_async" suffix. This
  matches glib style, for which the async form is also not specially
  marked.

- for function that refere to a particular checkpoint (rollback and
  destroy), accept the D-Bus path as string, instead of an NMCheckpoint
  instance. This form is more flexible, because it allows to use
  the function without having a NMCheckpoint instance at hand. On the
  other hand, if one has a NMCheckpoint instance, he can trivially
  obtain the path to make the call.

- make python2 and python3 compatible
- support Checkpoint create flags (requires recent libnm for GI
  of flags)
- support adjust-rollback-timeout command
- print elapsed time in show output

We need common operations from the python scripts.
For example, to print the boot-time.

Move such utils to a separate nmex.py file ("ex" for
example). This file should contain helper functions that
are pure python (or, if the have requirements, load them
only on demand, so that examples that need those have
additional dependencies). It should also be simple to extract
individual helpers from nmex, so that the user can take an
example, merge parts of nmex.py in, and modify it to his needs.

Note that this changes API for checkpoint_create_async() in Python
via GIR. Previously it would require an integer argument, now a flags
argument. But this API is still unstable, it will be introduced with
1.12.

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.

It already defaults to the right value. We only need to define
NM_VERSION_MIN_REQUIRED, so that parts of our internal build
can make use of deprecated API.

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".