1. 09 Jul, 2021 1 commit
  2. 30 Jun, 2021 1 commit
  3. 28 Jun, 2021 3 commits
  4. 04 May, 2021 1 commit
  5. 18 Feb, 2021 1 commit
    • Thomas Haller's avatar
      build: move "libnm-core/" to "src/" and split it · fdf9614b
      Thomas Haller authored
      "libnm-core/" is rather complicated. It provides a static library that
      is linked into libnm.so and NetworkManager. It also contains public
      headers (like "nm-setting.h") which are part of public libnm API.
      
      Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
      only rely on public API of libnm-core, but are themself static
      libraries that can be used by anybody who uses libnm-core. And
      "libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
      
      Move "libnm-core/" to "src/". But also split it in different
      directories so that they have a clearer purpose.
      
      The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
      directories correspond to the different modules (static libraries and set
      of headers that we have). We have different kinds of such modules because
      of how we combine various code together. The directory layout now reflects
      this.
      fdf9614b
  6. 09 Feb, 2021 1 commit
  7. 08 Feb, 2021 1 commit
  8. 04 Feb, 2021 1 commit
    • Thomas Haller's avatar
      all: move "src/" directory to "src/core/" · ac1a9e03
      Thomas Haller authored
      Currently "src/" mostly contains the source code of the daemon.
      I say mostly, because that is not true, there are also the device,
      settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
      helper, and probably more.
      
      Also we have source code under libnm-core/, libnm/, clients/, and
      shared/ directories. That is all confusing.
      
      We should have one "src" directory, that contains subdirectories. Those
      subdirectories should contain individual parts (libraries or
      applications), that possibly have dependencies on other subdirectories.
      There should be a flat hierarchy of directories under src/, which
      contains individual modules.
      
      As the name "src/" is already taken, that prevents any sensible
      restructuring of the code.
      
      As a first step, move "src/" to "src/core/". This gives space to
      reorganize the code better by moving individual components into "src/".
      
      For inspiration, look at systemd's "src/" directory.
      
      https://gitlab.freedesktop.org/NetworkManager/NetworkM...
      ac1a9e03
  9. 05 Jan, 2021 1 commit
    • Thomas Haller's avatar
      all: update deprecated SPDX license identifiers · 977ea352
      Thomas Haller authored
      These SPDX license identifiers are deprecated ([1]). Update them.
      
      [1] https://spdx.org/licenses/
      
        sed \
           -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \
           -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \
           -i \
           $(git grep -l SPDX-License-Identifier -- \
               ':(exclude)shared/c-*/' \
               ':(exclude)shared/n-*/' \
               ':(exclude)shared/systemd/src' \
               ':(exclude)src/systemd/src')
      977ea352
  10. 29 Sep, 2020 1 commit
    • Thomas Haller's avatar
      all: unify comment style for SPDX-License-Identifier tag · 88071abb
      Thomas Haller authored
      Our coding style recommends C style comments (/* */) instead of C++
      (//). Also, systemd (which we partly fork) uses C style comments for
      the SPDX-License-Identifier.
      
      Unify the style.
      
        $ sed -i '1 s#// SPDX-License-Identifier: \([^ ]\+\)$#/* SPDX-License-Identifier: \1 */#' -- $(git ls-files -- '*.[hc]' '*.[hc]pp')
      88071abb
  11. 28 Sep, 2020 2 commits
  12. 17 Aug, 2020 1 commit
  13. 02 Oct, 2019 1 commit
    • Thomas Haller's avatar
      all: unify format of our Copyright source code comments · 3b69f021
      Thomas Haller authored
      ```bash
      
      readarray -d '' FILES < <(
        git ls-files -z \
          ':(exclude)po' \
          ':(exclude)shared/c-rbtree' \
          ':(exclude)shared/c-list' \
          ':(exclude)shared/c-siphash' \
          ':(exclude)shared/c-stdaux' \
          ':(exclude)shared/n-acd' \
          ':(exclude)shared/n-dhcp4' \
          ':(exclude)src/systemd/src' \
          ':(exclude)shared/systemd/src' \
          ':(exclude)m4' \
          ':(exclude)COPYING*'
        )
      
      sed \
        -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \
        -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \
        -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \
        -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \
        -i \
        "${FILES[@]}"
      
      echo ">>> untouched Copyright lines"
      git grep Copyright "${FILES[@]}"
      
      echo ">>> Copyright lines with unusual extra"
      git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved
      
      sed \
        -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \
        -i \
        "${FILES[@]}"
      
      ```
      
      !298
      3b69f021
  14. 01 Oct, 2019 1 commit
  15. 10 Sep, 2019 1 commit
  16. 11 Jun, 2019 1 commit
    • Thomas Haller's avatar
      all: drop emacs file variables from source files · c0e075c9
      Thomas Haller authored
      We no longer add these. If you use Emacs, configure it yourself.
      
      Also, due to our "smart-tab" usage the editor anyway does a subpar
      job handling our tabs. However, on the upside every user can choose
      whatever tab-width he/she prefers. If "smart-tabs" are used properly
      (like we do), every tab-width will work.
      
      No manual changes, just ran commands:
      
          F=($(git grep -l -e '-\*-'))
          sed '1 { /\/\* *-\*-  *[mM]ode.*\*\/$/d }'     -i "${F[@]}"
          sed '1,4 { /^\(#\|--\|dnl\) *-\*- [mM]ode/d }' -i "${F[@]}"
      
      Check remaining lines with:
      
          git grep -e '-\*-'
      
      The ultimate purpose of this is to cleanup our files and eventually use
      SPDX license identifiers. For that, first get rid of the boilerplate lines.
      c0e075c9
  17. 19 May, 2019 1 commit
  18. 18 Apr, 2019 2 commits
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · 284ac92e
      Thomas Haller authored
      "libnm-core" implements common functionality for "NetworkManager" and
      "libnm".
      
      Note that clients like "nmcli" cannot access the internal API provided
      by "libnm-core". So, if nmcli wants to do something that is also done by
      "libnm-core", , "libnm", or "NetworkManager", the code would have to be
      duplicated.
      
      Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
      Note that:
      
        0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
           On the other hand, "libnm-libnm-core-aux.la" is not used by
           libnm-core, but provides utilities on top of it.
      
        1) they both extend "libnm-core" with utlities that are not public
           API of libnm itself. Maybe part of the code should one day become
           public API of libnm. On the other hand, this is code for which
           we may not want to commit to a stable interface or which we
           don't want to provide as part of the API.
      
        2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
           and thus directly available to "libnm" and "NetworkManager".
           On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
           and "NetworkManager".
           Both libraries may be statically linked by libnm clients (like
           nmcli).
      
        3) it must only use glib, libnm-glib-aux.la, and the public API
           of libnm-core.
           This is important: it must not use "libnm-core/nm-core-internal.h"
           nor "libnm-core/nm-utils-private.h" so the static library is usable
           by nmcli which couldn't access these.
      
      Note that "shared/nm-meta-setting.c" is an entirely different case,
      because it behaves differently depending on whether linking against
      "libnm-core" or the client programs. As such, this file must be compiled
      twice.
      
      (cherry picked from commit af07ed01)
      284ac92e
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · af07ed01
      Thomas Haller authored
      "libnm-core" implements common functionality for "NetworkManager" and
      "libnm".
      
      Note that clients like "nmcli" cannot access the internal API provided
      by "libnm-core". So, if nmcli wants to do something that is also done by
      "libnm-core", , "libnm", or "NetworkManager", the code would have to be
      duplicated.
      
      Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
      Note that:
      
        0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
           On the other hand, "libnm-libnm-core-aux.la" is not used by
           libnm-core, but provides utilities on top of it.
      
        1) they both extend "libnm-core" with utlities that are not public
           API of libnm itself. Maybe part of the code should one day become
           public API of libnm. On the other hand, this is code for which
           we may not want to commit to a stable interface or which we
           don't want to provide as part of the API.
      
        2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
           and thus directly available to "libnm" and "NetworkManager".
           On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
           and "NetworkManager".
           Both libraries may be statically linked by libnm clients (like
           nmcli).
      
        3) it must only use glib, libnm-glib-aux.la, and the public API
           of libnm-core.
           This is important: it must not use "libnm-core/nm-core-internal.h"
           nor "libnm-core/nm-utils-private.h" so the static library is usable
           by nmcli which couldn't access these.
      
      Note that "shared/nm-meta-setting.c" is an entirely different case,
      because it behaves differently depending on whether linking against
      "libnm-core" or the client programs. As such, this file must be compiled
      twice.
      af07ed01
  19. 12 Feb, 2019 1 commit
  20. 17 Jul, 2018 1 commit
  21. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
      
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          587
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          21114
      
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
      
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      
      A simple style guide is instead: don't use these typedefs.
      
      No manual actions, I only ran the bash script:
      
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
            "${FILES[@]}"
      e1c7a2b5
  22. 27 Jun, 2017 2 commits
  23. 12 May, 2017 2 commits
    • Thomas Haller's avatar
      hostname: cache hostname-manager's hostname property · 54f5407a
      Thomas Haller authored
      A property preferably only emits a notify-changed signal when
      the value actually changes and it caches the value (so that
      between property-changed signals the value is guaranteed not to change).
      
      NMSettings and NMManager both already cache the hostname, because
      NMHostnameManager didn't guarantee this basic concept.
      
      Implement it and rely on it from NMSettings and NMPolicy.
      And remove the copy of the property from NMManager.
      
      Move the call for nm_dispatcher_call_hostname() from NMHostnameManager
      to NMManager. Note that NMPolicy also has a call to the dispatcher
      when set-transient-hostname returns. This should be cleaned up later.
      54f5407a
    • Thomas Haller's avatar
      hostname: split out hostname management from NMSettings · 5bfb7c3c
      Thomas Haller authored
      Hostname management is complicated. At least, how it is implemented currently.
      For example, NMPolicy also sets the hostname (NMPolicy calls
      nm_settings_set_transient_hostname() to have hostnamed set the hostname,
      but then falls back to sethostname() in settings_set_hostname_cb()).
      Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and
      NMPolicy listens to changes from there -- instead of changes from
      NMSettings.
      
      Eventually, NMHostnameManager should contain the hostname parts from NMSettings
      and NMPolicy.
      5bfb7c3c