Error: Connection activation failed: no valid VPN secrets.
Hint: use 'journalctl -xe NM_CONNECTION=0dd048e5-e84b-4e96-9142-61b3e73f1c69 + NM_DEVICE=eth0' to get more details.
Autocompletion doesn't work in some cases because we present a prompt
ending with ":", but compare it with the string without ":" in the
autocomplete function. Fix this.
While at it, also add missing colon after prompt where needed.
The array returned by the completion function follows a special
convention. If the first element is set, it is used as the
completion. Otherwise, the remaining entries are the possible
completions.
_meta_abstract_complete() just returned an array of matching words and
so the first element was always used as completion. Instead, we must
use rl_completion_matches() to generate the array passing a generator
function.
https://bugzilla.redhat.com/show_bug.cgi?id=1588952
Add a new 'match' setting containing properties to match a connection
to devices. At the moment only the interface-name property is present
and, contrary to connection.interface-name, it allows the use of
wildcards.
Historically, nmcli printed all fields during operations like
`nmcli connection show "$PROFILE"`. As we supported more and
more options, this resulted in a verbose output, of most properties
just being the default values.
To counter that, we added the '-overview' option. When given,
it would hide options that are set at their default. This option
was not the default, to preserve established behavior.
However, for new options, we can afford to hide them. Add a mechanism,
that property getters can mark their value to be hidden. At the moment,
there is no way to show these properties. However, we could add a
'-verbose' option, with the opposite meaning of '-overview'. Anyway,
that does not seem necessary at the moment.
Hiding properties from output is only acceptable for new properties
(otherwise we badly change behavior), and if the properties are set
at their default values (otherwise, we hide important information).
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
Not all properties that we want to handle in nmcli are actual GObject
properties. For the moment that was the case, but that's about to change.
This is a change in behavior with respect of the order in which
properties are reported. For example, print_setting_description()
now prints the property descriptions in a different order. However,
one might argue that this order makes more sense because:
- it's the same order as properties are listed in
"nm-meta-setting-desc.c". At that place, we have explict
control over the order and set it intentionally to suite
our needs best. The order of the GObject properties is
much less well defined.
- the order from "nm-meta-setting-desc.c" is used at several other
places. So, it makes sense to use the same order everywhere.
The virtual function NMMetaType.get_nested() has only one caller:
nm_meta_abstract_info_get_nested(). That caller makes sure to
always pass in an @out_to_free argument, and that it is initialized
to NULL.
The local variable was just a copy of the (unchanging)
configuration nmc_config->multiline_output.
It is complicated enough to understand how nmc_config->print_output
and nmc_config->multiline_output affects nmc_print(). Don't use an
alias when referencing to nmc_config->multiline_output because it
hides where the value is used and where it causes a difference.
PrintDataCol contains a reference to the parent structure, for which
it was created. Previously, that was expressed via the "parent_idx"
field, which is an index into the list of all PrintDataCol entries.
That is inconvenient. Resolve the index to the actual pointer.
Note that during _output_selection_append() we still need to use
the index instead of resolving the pointer right away. That is because
_output_selection_append() grows the GArray into which the parent_idx
pointers to. So, obtaining the real pointer at that point would result
in using a dangling pointer later on.
Introduce a new step _output_selection_complete() which converts the
index into the actual pointer.
The print-output knows three modes: NORMAL, PRETTY, TERSE.
Never compare whether a mode is != a particular mode.
Instead, always explicitly check for the modes for which we enable a
particular behavior.
The effect is, that we always do something when the mode is set to a
particular value. We don't ever do something, if the mode is not set to
a particular value. Consistently opt-in is easier to understand.
The print-output knows three modes: NORMAL, PRETTY, TERSE.
Instead of using local variables "pretty" and "terse",
check for the output mode directly.
Note how we have tree modes, so mapping them to two boolean
variables is confusing. Especially at one place where we did:
pretty = (nmc_config->print_output != NMC_PRINT_TERSE);
while at other places:
pretty = (nmc_config->print_output == NMC_PRINT_PRETTY);
The header-cell is the header for a column with possibly many
rows.
We must not set:
header_cell->skip = nmc_config->overview && is_default;
for a particular cell, because it does not take into accound
the neighbouring rows. It is only correct, if there is only
one row.
Invert the logical meaning and rename "strip" to "to_print".
Each cell then can opt-in, whether it needs to be printed.
Only if no cell opts-in, it will be skipped.
Fixes: 9a19bbcb2f
1) the command line gets shorter. I frequently run `make V=1` to see
the command line arguments for the compiler, and there is a lot
of noise.
2) define each of these variables at one place. This makes it easy
to verify that for all compilation units, a particular
define has the same value. Previously that was not obvious or
even not the case (see commit e5d1a71396
and commit d63cf1ef2f).
The point is to avoid redundancy.
3) not all compilation units need all defines. In fact, most modules
would only need a few of these defines. We aimed to pass the necessary
minium of defines to each compilation unit, but that was non-obvious
to get right and often we set a define that wasn't used. See for example
"src_settings_plugins_ibft_cppflags" which needlessly had "-DSYSCONFDIR".
This question is now entirely avoided by just defining all variables in
a header. We don't care to find the minimum, because every component
gets anyway all defines from the header.
4) this also avoids the situation, where a module that previously did
not use a particular define gets modified to require it. Previously,
that would have required to identify the missing define, and add
it to the CFLAGS of the complation unit. Since every compilation
now includes "config-extra.h", all defines are available everywhere.
5) the fact that each define is now available in all compilation units
could be perceived as a downside. But it isn't, because these defines
should have a unique name and one specific value. Defining the same
name with different values, or refer to the same value by different
names is a bug, not a desirable feature. Since these defines should
be unique accross the entire tree, there is no problem in providing
them to every compilation unit.
6) the reason why we generate "config-extra.h" this way, instead of using
AC_DEFINE() in configure.ac, is due to the particular handling of
autoconf for directory variables. See [1].
With meson, it would be trivial to put them into "config.h.meson".
While that is not easy with autoconf, the "config-extra.h" workaround
seems still preferable to me.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Installation-Directory-Variables.html
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[@]}"
The function nmc_print() receives a list of "targets". These are essentially
the rows that should be printed (while the "fields" list represents the columns).
When filling the cells with values, it calles repeatedly get_fcn() on the
column descriptors (fields), by passing each row (target).
The caller must be well aware that the fields and targets are
compatible. For example, in some cases the targets are NMDevice
instances and the target type must correspond to what get_fcn()
expects.
Add another user-data pointer that is passed on along with the
targets. That is useful, if we have a list of targets/rows, but
pass in additional data that applies to all rows alike.
It is still unused.
With --color=auto, coloring is enabled based on the .enable/.disable
termcolors files.
Likewise, when we enable coloring, we parse the color palette from the
.schem termcolors files.
The termcolors files are searched by finding the best match depending
on the terminal and application name. Note, that if we find a matching
file like "nmcli@xterm.enable" we still allow loading the palette from
a less specific file like "nmcli.schem" and vice versa. That was already
done before.
Previously, the search was done by calling several layers of functions, and having
in/out arguments "color_option" and "p_palette_buffer". in/out paramters
here seems confusing to me, as they are state that gets modified and carried
along.
Instead, rework the functions to clearly separate between input
and output arguments.
Also, in the auto-case, check_colors() now first determines whether
coloring is enabled, before even starting loading the palette.
This avoids loading the palette until we are sure that we need it.
The NmCli variables is essentially a global variable of *everything*.
The set_color() function and its helpers only need a particular
part of it. Instead, of passing the entire global state to them,
only pass what they need.
It makes it clearer which parts are actually relevant. Turns out,
it only actually touches a resonable small part of the global state.
Now that nmcli initiates a scan before displaying Wi-Fi networks,
the stub service must properly support that as well.
For the moment, the stub service chooses "now" as LastScan timestamp.
This causes nmcli not to trigger a new scan, because nmcli gives
unstable output if multiple nmcli processes in parallel race to
trigger a Wi-Fi scan. That should be fixed.
