1. 04 Jul, 2016 3 commits
  2. 02 Jul, 2016 1 commit
  3. 30 Jun, 2016 3 commits
  4. 29 Jun, 2016 2 commits
  5. 27 Jun, 2016 2 commits
  6. 25 Jun, 2016 2 commits
  7. 16 Jun, 2016 4 commits
  8. 14 Jun, 2016 2 commits
  9. 04 Jun, 2016 2 commits
  10. 31 May, 2016 1 commit
    • Thomas Haller's avatar
      all: merge the stable branch 'nm-1-2' into master · ccd275d2
      Thomas Haller authored
      For the moment, don't maintain a separate stable branch in upstream, until
      'master' bumps the required NetworkManager API to 1.3. Until then, 'master'
      and 'nm-1-2' shall be identical.
      For NetworkManager-core (which provides libnm) and network-manager-applet
      (which provides libnma) we maintain stable branches like 'nm-1-0', 'nm-1-2'.
      This is useful, because those branches have different, backward-compatible
      API that is used by other projects. But what is best for NetworkManager core,
      is not necesarily best for the plugins.
      For the VPN plugins, with the release of 1.2.0 we also branched 'nm-1-2' off
      'master' and since then maintained a stable branch upstream.
      This either means, we eagerly backport from 'master' to 'nm-1.2', in
      which case it's a lot of work with the effect of having two mostly
      identical branches. In this form 'nm-1-2' isn't very useful.
      Or we don't backport eagerly, which may or may not result in 'nm-1-2'
      being more stable. Especially since upstream NetworkManager does releases
      infrequently, it can take a rather long time until we release 1.4.0 and
      improvements on master don't reach users for a long time.
      'master' still doesn't require >= 1.3 API from NetworkManager, libnm or libnma.
      The VPN plugins are rather simple, and there is no strong enough justification
      to maintain two separate branches both based on 1.2 NetworkManager API.
      'master' shall always be in a decent shape. So, it's not clear that the
      outcome of this is actually less stable. And there is no guarantee that any
      branch, stable or not, is perfect. Downstream must be prepared to backport
      necessary patches.
      This merge, resets the version number from 1.3.0 to 1.2.3.
      Also, on master we implemented the GTK plugin split, so the next release
      1.2.4 (or 1.4.0, whichever happens first), will bring that too. This
      will affects packaging due to new files. But I consider this a worthy
      feature to have on 1.2 anyway and without this merge I'd alose like to see
      it backported.
  11. 30 May, 2016 1 commit
  12. 29 May, 2016 2 commits
  13. 28 May, 2016 1 commit
  14. 26 May, 2016 2 commits
  15. 25 May, 2016 2 commits
  16. 24 May, 2016 9 commits
    • Thomas Haller's avatar
      service: fix setting log-level based on debug-mode · 37c71ce0
      Thomas Haller authored
      As our debug message printed by _LOGD() are enabled by
      LOG_INFO level, we must also set the log_level accordingly.
      Fixes: f91c336f
    • Thomas Haller's avatar
      service: don't use logging macros before logging is set up · 26d70220
      Thomas Haller authored
      Before the command line options are successfully parsed,
      the logging macros should not be used.
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      service: cleanup conditional logging macros · f91c336f
      Thomas Haller authored
      Previously, the logging macros _LOGI() and _LOGW() would
      unconditionally log, without considering the logging level.
      Only _LOGD() would consider the logging level.
      Now that we can configure logging levels, that is strange. Why would we
      have a logging macro _LOGI() logging info-messages without <info>
      level enabled?
      Previously, before this branch, logging was like this:
        - some logging statements _LOGW(), _LOGI() were always logged by the
        - some logging statements _LOGd() were only logged when called with
        - nm-openvpn-service-helper would always log messages via g_log().
        - openvpn was called with "--verb 10" in debug mode, otherwise without
          verb options (which equals "--verb 1").
      Especially, NetworkManager would spawn the plugin without --debug
      Now, newer NetworkManager spawns the plugin with NM_VPN_LOG_LEVEL.
      In this case, the logging level set by NetworkManager is authorative
      for all logging statements and the "--verb" option for openvpn directly
      Most notably, NetworkManager quite likely calls the plugin with NM_VPN_LOG_LEVEL=0,
      in which case all _LOGX() macros are disabled, and openvpn is called
      with "--verb 1".
      So, in such a situation, the plugin now logs almost nothing.
      This obviously is a change in behavior, but "logging" doesn't guarantee
      stable behavior. The new behavior makes sense as logging is now fully
      controlled by NetworkManager. If the user wants to enable logging of the
      plugins, he should do
        $ nmcli general logging level KEEP domains VPN_PLUGIN:INFO
    • Thomas Haller's avatar
      service: improve logging for nm-openvpn-service-openvpn-helper · 00b9dcc9
      Thomas Haller authored
      - pass the syslog level to the helper via --debug. This way, the helper
        has more information about the logging verbosity.
      - like for nm-openvpn-service, don't use g_log() and related functions
        for logging. They generate by default a prefix that we don't want,
        and they don't work with levels G_LOG_LEVEL_INFO and lower, unless
        G_MESSAGES_DEBUG is defined.
      - print a different prefix to the logging line. The first part of the
        prefix is equal to what is printed by the nm-openvpn-service. The
        second part, indicates that it's the helper and its PID.
        Note that now with multiple-VPN-support, there might be several helpers
        invoked for different connections. We need to be able to distinguish their
        log-messages, thus they all prefix their messages with the PID of
        their parent nm-openvpn-service process.
    • Thomas Haller's avatar
      service: refactor logging and don't use g_log() · ae519577
      Thomas Haller authored
      g_log() prefixes every logging message with something like:
        (nm-openvpn-service:7563): nm-openvpn-WARNING **:
      We don't want these prefixes, but use our own style.
      Also, G_LOG_LEVEL_INFO and G_LOG_LEVEL_DEBUG are not shown by
      default, unless G_MESSAGES_DEBUG is defined. We already have our
      internal ways to enable/disable logging and don't want g_log()
      interfere with this. Otherwise, we would have to set G_MESSAGES_DEBUG
      Also, we use it for regular loggings. Even a warning, is something that
      can happen under regular conditions. These are not assertions.
      On the other hand, g_warning() dumps core with G_DEBUG=fatal-warnings.
      That is great for libraries and assertions, but not for regular logging.
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      service/trivial: rename logging macro _LOGd() to _LOGD() · 0343d19a
      Thomas Haller authored
      Currently, the _LOGD() is differnt from _LOGI() and _LOGW(),
      in that it logs conditionally based on the debug setting.
      The other two logging macros always log their message.
      Later these macros will be unified, so that also _LOGI and _LOGW
      considers the logging level. So rename them now to make the later
      diff smaller.
      Note that in NetworkManager core project, _LOGt() is a statement
      that can be disabled at compile time. Thus, _LOGd() had a different
      meaning here.
    • Thomas Haller's avatar
      service/trivial: rename logging macros · 1658f0fa
      Thomas Haller authored
      Give them the same names as we use in NetworkManager core.
      Drop unused _LOGD().
  17. 23 May, 2016 1 commit