1. 19 Mar, 2019 1 commit
    • Lubomir Rintel's avatar
      all: goodbye libnm-glib · 1de8383a
      Lubomir Rintel authored
      This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
      The it has been replaced with libnm since NetworkManager 1.0, disabled
      by default since 1.12 and no up-to-date distributions ship it for years
      now.
      
      Removing the libraries allows us to:
      
      * Remove the horrible hacks that were in place to deal with accidental use
        of both the new and old library in a single process.
      * Relief the translators of maintenance burden of similar yet different
        strings.
      * Get rid of known bad code without chances of ever getting fixed
        (libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
      * Generally lower the footprint of the releases and our workspace
      
      If there are some really really legacy users; they can just build
      libnm-glib and friends from the NetworkManager-1.16 distribution. The
      D-Bus API is stable and old libnm-glib will keep working forever.
      
      https://github.com/NetworkManager/NetworkManager/pull/308
      1de8383a
  2. 07 Mar, 2019 16 commits
  3. 08 Feb, 2019 1 commit
  4. 07 Feb, 2019 1 commit
    • Thomas Haller's avatar
      contrib/rpm: quote snapshot/git_sha variables in spec-file · a0b976ac
      Thomas Haller authored
      Otherwise the following fails:
      
          $ ./contrib/fedora/rpm/build_clean.sh -g -s x.1
          ...
          error: parse error in expression
          error: /data/src/_NetworkManager/contrib/fedora/rpm/NetworkManager.20190207-165257.XOkW4i/SPECS/NetworkManager.spec:35: bad %if condition
          ERROR: rpmbuild FAILED
      
      Even with the fix, not all characters are allowed:
      
          $ ./contrib/fedora/rpm/build_clean.sh -g -s x-1
          ...
          error: line 112: Illegal char '-' (0x2d) in: Release: 22165.x-1.25b13e2053.fc29
          ERROR: rpmbuild FAILED
      a0b976ac
  5. 04 Feb, 2019 1 commit
  6. 07 Jan, 2019 1 commit
  7. 20 Dec, 2018 1 commit
    • Inigo Martínez's avatar
      build: meson: Remove polkit_dir option · 4b32bbc8
      Inigo Martínez authored
      meson is able to get variables defined in pkg-config files such as
      directory paths. PolicyKit defines in its pkg-config file the path to
      the directory where `policy` files are present.
      
      This removes the `polkit_dir` option to ease the move to start using
      those variables. The `polkit` variable has also been converted to
      boolean.
      
      Fedora spec script has also been updated accordingly.
      4b32bbc8
  8. 09 Nov, 2018 1 commit
    • Beniamino Galvani's avatar
      rpm: disable ebpf support on RHEL · 570c41aa
      Beniamino Galvani authored
      The ebpf syscall doesn't work on RHEL even if the linux/bpf.h header
      is available: let's explicitly disable it.
      
      On Fedora explicitly enable eBPF instead of autodetecting it.
      570c41aa
  9. 07 Nov, 2018 1 commit
  10. 01 Nov, 2018 1 commit
    • Thomas Haller's avatar
      contrib/rpm: add "00-server-dhcp-client-id.conf" · 7a46ccff
      Thomas Haller authored
      While this is packaged in "NetworkManager-config-server.rpm"
      sub-package, it's not in "00-server.conf" file. The reason
      is that a convenient way to disable configuration from
      "/usr/lib/NetworkManager/conf.d", is by putting a (possibly empty)
      file into /etc directory with the same name. If the sub-package
      only provides one large "00-server.conf" file, this is no longer
      possible at a granular level.
      7a46ccff
  11. 22 Oct, 2018 1 commit
  12. 12 Oct, 2018 1 commit
    • Michael Biebl's avatar
      systemd: don't make NetworkManager D-Bus activatable · 90f71c0f
      Michael Biebl authored
      If the NetworkManager daemon has been stopped manually we don't want it
      to be autostarted by a client request.
      
      [lkundrak@v3.sk: The auto-activation is probably more surprising than useful.
      Services that need NetworkManager API should depend on NetworkManager service
      directly.
      
      I have no idea what purpose does the D-Bus service file serve nowadays,
      but it looks rather hacky (really, activating /bin/false) and the comment
      in it suggests that the autoactivating behavior was not intended anyway.
      Debian has been shipping this for quite some time and no complains have been
      heard.]
      
      https://github.com/NetworkManager/NetworkManager/pull/230
      90f71c0f
  13. 28 Sep, 2018 2 commits
    • Beniamino Galvani's avatar
      contrib/rpm: support building with meson · 295b9d5b
      Beniamino Galvani authored
      Add support for building with meson, enabled by '--with meson' so that
      we can regularly test the whole build+test+install procedure with
      meson. I compared the RPM contents of NM, NM-libnm, NM-libnm-devel
      packages and they match the autotools ones. It's also faster:
      
        $ time contrib/fedora/rpm/build_clean.sh -g -Q -f
      
        real    3m54.239s
        user    11m15.000s
        sys     1m28.456s
      
        $ time contrib/fedora/rpm/build_clean.sh -g -Q -f -w meson
      
        real    3m9.938s
        user    9m5.225s
        sys     1m4.392s
      295b9d5b
    • Beniamino Galvani's avatar
      contrib/rpm: remove duplicate documentation · 1f187834
      Beniamino Galvani authored
      In NetworkManager-libnm-devel we ship the same documentation in two
      different places:
      
       /usr/share/doc/NetworkManager-libnm-devel
       /usr/share/gtk-doc/html/NetworkManager
      
      Remove the former, which was added in commit e01c1752.
      
      Also, remove the same documentation from NetworkManager-glib-devel
      since it's already present in NetworkManager-libnm-devel.
      1f187834
  14. 18 Sep, 2018 2 commits
  15. 14 Sep, 2018 7 commits
    • 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
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1626517
      (cherry picked from commit d8a972c5)
      63639f33
    • 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
      flags).
      
      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.
      
      Now:
      
      - 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)
      fd2e8179
    • 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)
      7e6824f4
    • Thomas Haller's avatar
      contrib/rpm: disable tests by default and use fatal-warnings with tests · ad850c4f
      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
      flags).
      
      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.
      
      Now:
      
      - 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".
      ad850c4f
    • Thomas Haller's avatar
      contrib/rpm: always run tests and enable more compiler warnings in package build · 58b030f3
      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.
      58b030f3
    • 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)
      5023e089
    • Thomas Haller's avatar
      contrib/rpm: disable --with-more-asserts for devel-builds · b4e2f834
      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).
      b4e2f834
  16. 13 Sep, 2018 1 commit
    • Beniamino Galvani's avatar
      contrib/rpm: fix mode of ghost ifup/ifdown files · d8a972c5
      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
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1626517
      d8a972c5
  17. 04 Sep, 2018 1 commit