1. 24 May, 2020 2 commits
  2. 18 May, 2020 1 commit
  3. 17 May, 2020 1 commit
  4. 14 May, 2020 1 commit
  5. 07 May, 2020 2 commits
  6. 27 Apr, 2020 1 commit
  7. 25 Apr, 2020 1 commit
  8. 24 Apr, 2020 1 commit
  9. 23 Apr, 2020 1 commit
  10. 22 Apr, 2020 4 commits
  11. 18 Apr, 2020 1 commit
  12. 13 Apr, 2020 1 commit
  13. 06 Apr, 2020 7 commits
  14. 29 Mar, 2020 1 commit
  15. 17 Mar, 2020 1 commit
  16. 07 Mar, 2020 5 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      release: bump version to 1.16.0 · daded73d
      Thomas Haller authored
    • Thomas Haller's avatar
      release: update NEWS · 9d8be2d9
      Thomas Haller authored
    • Thomas Haller's avatar
      build: require libnma 1.8.28 · 91337dd4
      Thomas Haller authored
      Applet requires libnma-1.8.28 because "org.gnome.nm-applet.gschema.xml"
      moved to libnma.
      Now libnma 1.8.28 got released. Explicitly encode the dependency.
      Note that it is still inconvenient at this point to bootstrap
      and build applet as such.
      It is inconvenient if you are on current Fedora 31 with
      gnome-control-center. Then, gnome-control-center will require
      nm-connection-editor (1.8.24) which will require libnma-1.8.24.
      That means, even if you rebuild libnma-1.8.28 RPM, you cannot
      install it (because you have no suitable nm-connection-editor
      which gnome-control-center requires).
      As workaround, build nm-connection-editor first in a build root
      without Gnome, only libnma-1.8.28 present.
      Still bump the dependency because it's right to do before release
      and we will applet 1.16.0 shortly. While inconvenient to boot strap,
      it's doable to have libnma-1.8.28 present for building applet.
    • Thomas Haller's avatar
      gitlab-ci: move logic from gitlab-ci.yml to script and install external libnma-1.8.28 · 240da3ea
      Thomas Haller authored
      I think a plain shell script makes it easier to implement the build
      steps. It's easier to read and to extend.
      Also, the gitlab-ci script tried to install libnma from rawhide.
      However, while the libnma-1.8.26 package is currently built in koji,
      it is still (for some reasons) not available for installation. The
      build step would still install libnma-1.8.24 (which was still bundled
      with applet). Aside that, there are currently other issues in rawhide
      that prevent this from working.
      This only worked accidentally, because the network-manager-applet build
      does not yet explicitly require a new libnma package. However, in practice
      it does already, because when building against libnma-2.8.24, the
      "org.gnome.nm-applet.gschema.xml" is missing. Next we are going to explicitly
      require libnma-1.8.28, so this wouldn't work anymore.
      Instead I did a scratch build of libnma-1.8.28 in koji. Adjust the
      build steps and install the package. This is a temporary solution,
      that helps to boot strap the update to an unbundled libnma-1.8.28.
  17. 06 Mar, 2020 4 commits
  18. 05 Mar, 2020 5 commits
    • Thomas Haller's avatar
      build: temporarily allow building against libnma 1.22 · 02f24fa5
      Thomas Haller authored
      With the split of libnma to a new repository, we also moved the
      "org.gnome.nm-applet.gschema.xml" file. For that (and maybe other
      reasons), we really need to build master of applet against latest
      libnma (1.8.28).
      However, libnma is not yet widely packaged, so for development and testing
      this is rather inconvenient. Relax the requirement to allow building against
      older libnma.
      This patch should eventually be reverted.
    • Thomas Haller's avatar
      build/meson: fix NMA_VERSION_MIN_REQUIRED/NMA_VERSION_MAX_ALLOWED macros · c00fb791
      Thomas Haller authored
      Fixes: 9674424f ('build: use NMA_VERSION_MIN_REQUIRED/NMA_VERSION_MAX_ALLOWED macros')
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      version: bump version to 1.15.0 (in anticipation of 1.16.0 release) · c107a22f
      Thomas Haller authored
      For applet, we (usually) don't maintain stable branches upstream. Nor
      did the versioning scheme so far (with 3 numbers) give space for
      Up to now, the first two numbers (1.8) indicate the minimum required
      libnm version API. There is no particular good reason to do (or not
      to do) that. It worked reasonably well.
      However, let's change our versioning scheme. For one, we only seldom
      bump the required libnm version, so expressing it in the version
      number of applet is not spectacular. Also, we have other important
      libraries too (gtk3/gtk4, libnma-1.8.27). It's not clear that libnm's
      version number is more relevant than the one of other libraries,
      or why applet's version number should follow libnm's version number.
      Start a new versioning scheme with the next release. The next release
      will be 1.16.0 (still to reflect that we now require libnm 1.16.0).
      Also, future (major) releases will bump the second version number. Basically,
      we will adopt the same versioning scheme as NetworkManager, and their
      versions will move independently.
      Note that we are still in a development, pre-release version for 1.16.0.
      Hence, bump the version to 1.15.0.
    • Thomas Haller's avatar
      build: add dependency for libnm >= 1.16.0 · 43c2a9d4
      Thomas Haller authored
      NetworkManager 1.16.0 was released in March 2019. It introduces WireGuard
      support, and as we soon will use that API, require it.