1. 01 Jun, 2018 1 commit
  2. 31 May, 2018 2 commits
    • Thomas Haller's avatar
      build/meson: fix meson build for shared files · f445128a
      Thomas Haller authored
      The files in shared/nm-utils are not compiled as one static library,
      instead each subproject that needs (parts of) them, re-compiles the
      files individually.
      The major reason for that is, because we might have different compile
      flags, depending on whether we build libnm-core or
      libnm-util/libnm-glib. Actually, I think that is not really the case,
      and maybe this should be refactored, to indeed build them all as a
      static library first.
      Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
      different set of shared files that they should compile. Refactor
      "shared/meson.build" to account for that and handle it like autotools
      Another change is, that "shared_c_siphash_dep" no longer advertises
      "include_directories: include_directories('c-siphash/src')". We don't
      put c-siphash.h into the include search path. Users who need it, should
      include it via "#include <c-siphash/src/c-siphash.h>". The only exception
      is when building shared_n_acd library, which is not under our control.
    • Thomas Haller's avatar
  3. 28 May, 2018 5 commits
    • Thomas Haller's avatar
      clients/tests: run nmcli commands in parallel · baaab522
      Thomas Haller authored
      Most nmcli calls from clients/tests don't change the server's state.
      Hence, they can easily run in parallel.
      Run tests in parallel. No longer handle one nmcli invocation after the other.
      Instead, spawn groups of processes in parallel, and track the pending jobs.
      Only at certain synchronization points we call self.async_wait() to
      wait for all previous jobs to complete.
      This reduces the test time on my machine from 7 to 3 seconds. Arguably,
      that matters less during a full `make check -j 8`, because the entire
      set of tests anyway takes longer than 7 seconds. So when running the
      entire test suite, the machine is kept busy anyway. It matters however
      for manual invocations.
    • Thomas Haller's avatar
      all: add stable-id specifier "${DEVICE}" · eb821ead
      Thomas Haller authored
      Add new stable-id specifier "${DEVICE}" to explicitly declare that the
      connection's identity differs per-device.
      Note that for settings like "ipv6.addr-gen-mode=stable" we already hash
      the interface's name. So, in combination with addr-gen-mode, using this
      specifier has no real use. But for example, we don't do that for
      Point being, in various context we possibly already include a per-device
      token into the generation algorithm. But that is not the case for all
      contexts and uses.
      Especially the DHCPv4 client identifier is supposed to differ between interfaces
      (according to RFC). We don't do that by default with "ipv4.dhcp-client-id=stable",
      but with "${DEVICE}" can can now be configured by the user.
      Note that the fact that the client-id is the same accross interfaces, is not a
      common problem, because profiles are usually restricted to one device via
    • Thomas Haller's avatar
      device: hash a per-host key for ipv4.dhcp-client-id=stable · d1a94a85
      Thomas Haller authored
      Otherwise, the generated client-id depends purely on the profile's
      stable-id. It means, the same profile (that is, either the same UUID
      or same stable-id) on different hosts will result in identical client-ids.
      That is clearly not desired. Hash a per-host secret-key as well.
      Note, that we don't hash the interface name. So, activating the
      profile on different interfaces, will still yield the same client-id.
      But also note, that commonly a profile is restricted to one device,
      via "connection.interface-name".
      Note that this is a change in behavior. However, "ipv4.dhcp-client-id=stable"
      was only added recently and not yet released.
      Fixes: 62a78639
    • Beniamino Galvani's avatar
      cli: fix property matching · 1f7780cb
      Beniamino Galvani authored
      @ret was not initialized when there was only one partial match.
      Also, refactor the code to return all matching values.
      Fixes: 3fd9bf9d
    • Thomas Haller's avatar
      clients/tests: refactor by moving replace-text helper function · 78e877ee
      Thomas Haller authored
      Have less logic in TestNmcli.
  4. 27 May, 2018 1 commit
    • Thomas Haller's avatar
      clients/tests: generate Makefile.am for expected files · ee85151a
      Thomas Haller authored
      The developer can re-generate .expected files with
       $ NM_TEST_REGENERATE=1 ./clients/tests/test-client.py
      Note that these files are also dist-ed, so that the tests also work
      from a source-tarball. For that, we need to add them to EXTRA_DIST.
      Previously, this was done manually in the base Makefile.am file. This
      was cumbersome, because when adding a new test, the developer would need
      to manually add the files.
      Now, let the test (with NM_TEST_REGENERATE=1) also generate a makefile
  5. 25 May, 2018 2 commits
  6. 24 May, 2018 8 commits
  7. 14 May, 2018 14 commits
  8. 11 May, 2018 1 commit
    • Thomas Haller's avatar
      clients/tests: add python test script for nmcli tests · d4093a3a
      Thomas Haller authored
      Add a test which runs nmcli against our stub NetworkManager
      service and compares the output.
      The output formats of nmcli are complicated and not easily understood.
      For example how --mode tabular|multiline interacts with selecting
      output-fields (--fields) and output modes ([default]|--terse|--pretty).
      Also, there are things like `nmcli connection show --order $FIELD_SPEC`.
      We need unit tests to ensure that we don't change the output
  9. 10 May, 2018 6 commits
    • Lubomir Rintel's avatar
      cli: allow setting the colors with terminal-colors.d(5) · bcc9e58b
      Lubomir Rintel authored
      The present version of the specification is somewhat unclear at times,
      Unclear points were discussed with the maintainers [1] and probably
      some new version will address those.
      Until then here's how the implementation copes with ambiguities
      (after the discussion with util-linux maintainers):
      1.) It is unclear whether multiple .schem files should override each
          other or be merged. We use the overriding behavior -- take the
          highest priority one and ignore the rest.
      2.) We assume "name.schem" is more specific than "@term.schem".
      3.) We assume the "Color name" are to be used as aliases for the color
          sequences and translate them to ANSI escape sequences.
      4.) The "Escape sequences" are of no use since the specification
          pretty much assumes an ANSI terminal and none of the sequences make
          any sense in ANSI color codes. We don't support them.
          accept that.
      5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
          what should it do.
    • Lubomir Rintel's avatar
      cli: use a palette to implement coloring · 31aa2cfe
      Lubomir Rintel authored
      This basically replaces the (NMMetaTermColor, NMMetaTermFormat) combo
      with NMMetaColor that describes the colored element semantically as
      opposed to storing the raw attributes.
      A (currently static) paletted is used to translate the semantic color
      code to the actual ANSI controle sequence. This matches what
      terminal-colors.d(5) schemes use, making it convenient to implement
      customizable palettes.
    • Lubomir Rintel's avatar
      cli: rework enabling and disabling colors · 9dfe8258
      Lubomir Rintel authored
      This actually makes very little difference at the moment, but will make
      things more confortable later on, when the logic of enabling/disabling
      coloring will involve terminal-colors.d(5).
      Instead of deciding whether to use colors lazily with use_colors(), it's
      done very early on nmcli initialization and a boolean use_colors field
      is stored in the NmcConfig instance instead of the raw tristate option
      of NmcColorOption type (which is now confined to nmcli.c).
      Wherever the NmcColorOption was used previously, the whole NmcConfig
      instance is passed around. That might seem pointless (since only the
      use_colors boolean is actually used at the moment), but will be utilized
      to pass around the actual color palette in future.
    • Lubomir Rintel's avatar
      cli: drop --prompt-color · 56a5b273
      Lubomir Rintel authored
      It's undocumented, useless, somewhat expensive in volume of code and
      probably just downright stupid. We'll get a more general way to set
      Hacking in some code to keep this working wouldn't be too difficult, but
      it seems entirely pointless.
    • Lubomir Rintel's avatar
      cli: use static initializer for NmCli · 30d67c99
      Lubomir Rintel authored
      It's perhaps but a small improvement here, but will make things a lot
      more convenient when the color palette will be added.
    • Lubomir Rintel's avatar
      cli: drop a useless comment · f70abef5
      Lubomir Rintel authored
      Thomas doesn't like it and who am I to argue with him.