1. 14 Sep, 2018 21 commits
    • Thomas Haller's avatar
      release: bump version to 1.14.0 · 2979c891
      Thomas Haller authored
    • Thomas Haller's avatar
      release: update NEWS · 93727f13
      Thomas Haller authored
    • Thomas Haller's avatar
      libnm/trivial: whitespace · ff8777cd
      Thomas Haller authored
      (cherry picked from commit 3b5912f0)
    • Beniamino Galvani's avatar
      clients: fix memory leak when parsing routes · 6a9d2740
      Beniamino Galvani authored
      The new hash table should destroy elements stolen from the hash table
      returned by nm_utils_parse_variant_attributes().
      Fixes: d0949141
      (cherry picked from commit 31bda1b8)
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm: add missing NM_AVAILABLE_IN_1_14 macro to new API · 749ea949
      Thomas Haller authored
      Fixes: df30651b
      (cherry picked from commit bbc93a2e)
    • Thomas Haller's avatar
      autoptr: add missing autoptr cleanup functions · 070e4e39
      Thomas Haller authored
      (cherry picked from commit c1b647d5)
    • Thomas Haller's avatar
      libnm: drop API nm_connection_get_setting_{6lowpan,sriov,wpan}() · fe866fbe
      Thomas Haller authored
      Note that NMSettingEthtool and NMSettingMatch don't have such
      functions either.
      We have API
        nm_connection_get_setting (NMConnection *, GType)
        nm_connection_get_setting_by_name (NMConnection *, const char *)
      which can be used generically, meaning: the requested setting type
      is an argument to the function. That is generally more useful and
      Don't add API which duplicates existing functionality and is (arguably)
      inferiour. Drop it now. This is an ABI/API break for the current development
      cycle where the 1.14.0 API is still unstable. Indeed it's already after
      1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
      this API/ABI and is badly impacted by this change.
      Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
      are slightly inconvenient in C still, because they usually require a cast.
      We should fix that by changing the return type to "void *". Such
      a change may be possibly any time without breaking API/ABI (almost, it'd
      be an API change when taking a function pointer without casting).
      (cherry picked from commit a10156f5)
    • Thomas Haller's avatar
      vpn: disconnect signal handlers from proxy in NMVpnConnection::dispose() · f71f9b54
      Thomas Haller authored
      We cannot be sure who holds a reference to the proxy, and
      who is gonna call us back after the VPN connection instance
      is destroyed.
      (cherry picked from commit 6ebb9091)
    • Thomas Haller's avatar
      vpn: fix assertion during "SecretsRequired" in unexpected state · 011dd919
      Thomas Haller authored
      Got this assertion:
          NetworkManager[12939]: <debug> [1536917977.4868] active-connection[0x563d8fd34540]: set state deactivated (was deactivating)
          NetworkManager[12939]: nm-openvpn[1106] <info>  openvpn[1132]: send SIGTERM
          NetworkManager[12939]: nm-openvpn[1106] <info>  wait for 1 openvpn processes to terminate...
          NetworkManager[12939]: nm-openvpn[1106] <warn>  openvpn[1132] exited with error code 1
          NetworkManager[12939]: <info>  [1536917977.5035] vpn-connection[0x563d8fd34540,2fdeaea3-975f-4325-8305-83ebca5eaa26,"my-openvpn-Red-Hat",0]: VPN plugin: requested secrets; state disconnected (9)
          NetworkManager[12939]: plugin_interactive_secrets_required: assertion 'priv->vpn_state == STATE_CONNECT || priv->vpn_state == STATE_NEED_AUTH' failed
      Meaning. We should either ensure that secrets_required_cb() signal callback
      is disconnected from proxy's signal, or we gracefully handle callbacks at
      unexpected moments. Do the latter.
      (cherry picked from commit 92344dd0)
    • Thomas Haller's avatar
      cli: fix reading "vpn.secrets.*" from passwd-file · 6bfab679
      Thomas Haller authored
      Due to a bug, we required VPN secrets to be prefixed with
      "vpn.secret." instead of "vpn.secrets.". This was a change
      in behavior with 1.12.0 release.
      Fix it, to restore the old behavior. For backward compatibility
      to the broken behavior, adjust parse_passwords() to treat accept
      that as well.
      Fixes: 0601b5d7
      (cherry picked from commit 5815ae8c)
    • Beniamino Galvani's avatar
      contrib/rpm: fix mode of ghost ifup/ifdown files · 63639f33
      Beniamino Galvani authored
      Set the execution bit on /usr/sbin/{ifup,ifdown} ghost files to match
      the mode of same files installed by initscripts.
      Otherwise, they will appear as changed according to rpm verify:
       .M.......  g /usr/sbin/ifdown
       .M.......  g /usr/sbin/ifup
      when the alternatives mechanism is not in place.
       # ll /usr/sbin/if{up,down}
       -rwxr-xr-x. 1 root root 1651 Aug 24 06:23 /usr/sbin/ifdown
       -rwxr-xr-x. 1 root root 5010 Aug 24 06:23 /usr/sbin/ifup
      (cherry picked from commit d8a972c5)
    • Thomas Haller's avatar
      contrib/rpm: fix handling of --with test default · d1fecaa2
      Thomas Haller authored
      Seems rpmbuild does not honor the latest occurance with
        --with test --without test
      to disable tests. Work around that.
      Fixes: ad850c4f
      (cherry picked from commit cc8c2071)
    • Thomas Haller's avatar
      contrib/rpm: disable tests by default and use fatal-warnings with tests · fd2e8179
      Thomas Haller authored
      In general, when we build a package, we want no compiler warnings
      and all unit tests to pass.
      That is in particular true when building a package for the distribution
      in koji. When builing in koji, we (rightly) cannot pass rpmbuild options, so
      the default whether tests/compiler-warnings are fatal matter very much.
      One could argue: let's have the tests/compiler-warnings fatal and fail the build.
      During a build in koji for a Fedora release, we want them all pass. And if somebody
      does a manual build, the person can patch the spec file (or use rpmbuild
      However, note how commit "f7b5e48c contrib/rpm: don't force fatal warnings
      with tests" already disabled fatal compiler warnings. Why? It seems
      compiler warnings should be even more stable than our unit tests, as long
      as you target a particular Fedora release and compiler version. So this
      was done to support rebuilding an SRPM for a different Fedora release,
      or to be more graceful during early development phase of a Fedora
      release, where things are not as stable yet.
      The exactly same reasoning applies to treating unit-tests failures as fatal.
      For example, a recent iproute2 issue broke unit tests. That meant, with
      that iproute2 release in build root, the NetworkManager RPM could not be built.
      Very annoying.
      - if "test" is enabled, that means both `make check` and compiler warnings
        are treated fatal. If "test" is disabled, `make check` and compiler
        warnings are still done, just not fatal.
      - "test" is now disabled by default via the spec file. They are not fatal
        when building in koji or when rebuilding the package manually.
      - tests can be enabled optionally. Note that the "build_clean.sh"
        script enables them by default. So, a user using this script would
        need to explicitly "--without test".
      (cherry picked from commit ad850c4f)
    • Thomas Haller's avatar
      contrib/rpm: always run tests and enable more compiler warnings in package build · 7e6824f4
      Thomas Haller authored
      - always enable more compiler warnings. They are not marked as breaking
        the build anyway.
      - also, always build with '--with-tests=yes'. Note that our autotools is
        actually very nice. Even if you build '--with-tests=no', you still can
        run `make check` and the tests are build on demand. The only
        difference here is whether the tests are build during `make` or during
        `make check`. While little difference, build everything during the
        `make` step.
      - when running tests, use `make -k check`. Even if they fail, we want to
        run the entire test suite.
      - also running tests are disabled, still run them. But don't let them
        fail the build.
      (cherry picked from commit 58b030f3)
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      contrib/rpm: add --release option to build_clean.sh script · 5f1912f5
      Thomas Haller authored
      The correct way to create a tarball for release is
        ./contrib/fedora/rpm/build_clean.sh -r
      Just ensure to issue this from a clean shell environment.
      (cherry picked from commit 5894da67)
    • Thomas Haller's avatar
      docs/test: add check that gtk-doc contains patch to generate proper documentation · d29f6e03
      Thomas Haller authored
      In libnm, we prefer opaque typedefs. gtk-doc needs to be patched to properly
      generate documentation. Add a check for that.
      Add a test. By default, this does not fail but just prints a warning. The test
      can be made failing by setting NMTST_CHECK_GTK_DOC=1.
      See-also: https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/2
      (cherry picked from commit 02464c05)
    • Thomas Haller's avatar
      build: fix error message in configure script about gtk-doc · 629dbf66
      Thomas Haller authored
      (cherry picked from commit 815834ae)
    • Thomas Haller's avatar
      contrib/rpm: disable --with-more-asserts for devel-builds · 5023e089
      Thomas Haller authored
      The NetworkManager spec file used to determine devel builds as those that
      have an odd minor version number. In that case, the built package would
      enable more-asserts.
      -- By the way, why is '1.13.3-dev' considered a delopment version worthy of more
      asserts, but a build from the development phase of the next minor release on
      'nm-1-12' branch not?
      Note that during the development phase of Fedora (and sometimes even afterwards),
      we commonly package development versions from 'master'. For example '1.12.0-0.1',
      which is some snapshot with version number '1.11.x-dev' (or '1.12-rc1' in this case),
      but before the actual '1.12.0' release.
      It's problematic that for part of the devel phase we compile the
      package for the distribution with more assertions. This package is
      significanly different and rpmdiff and coverity give different results
      for them.
      For example, the binary size of debug packages is larger, so first
      rpmdiff will complain that the binary sized increased (compare to the
      previous version) and then later it decreases again.
      Likewise, coverity finds significantly different issues on a debug
      build. For example, it sees assertions against NULL and takes that
      as a hint as to whether the parameter can/shall be NULL. Keeping
      coverity warnings low is already high effort to sort out false
      positives. We should not invest time in checking debug builds with
      coverity, at least not as long as there are more important issues.
      But more importantly, the --with-more-asserts configure option governs whether
      nm_assert() is enabled. The only point of existance of nm_assert() -- compared to
      g_assert(), g_return_*() and assert() -- is that this variant is disabled by default.
      It's only used for checks that are really really not supposed to fail and/or
      which may be expensive to do. This is useful for developing and CI,
      but it's not right to put into the distribution. It really enables
      assertions that you don't want in such a scenario. Enabling them even
      for distribution builds defeats their purpose. If you care about an
      assertion to be usually/always enabled, you should use g_assert() or
      g_return_*() instead.
      What this changes, that "devel" builds in koji/brew do not have more-asserts
      enabled. When manually building the SRPM one still can enable it,
      for example via
        $ ./contrib/fedora/rpm/build_clean.sh -w debug
      Also our CI has an option to build packages with or without more-asserts
      (defaulting to more asserts already).
      (cherry picked from commit b4e2f834)
  2. 13 Sep, 2018 19 commits