1. 14 Sep, 2018 5 commits
    • 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)
      5f1912f5
    • 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)
      d29f6e03
    • Thomas Haller's avatar
      build: fix error message in configure script about gtk-doc · 629dbf66
      Thomas Haller authored
      (cherry picked from commit 815834ae)
      629dbf66
    • 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
  2. 13 Sep, 2018 28 commits
  3. 12 Sep, 2018 7 commits