NetworkManager merge requestshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests2019-05-07T14:43:21Zhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/134[th/cache-state-keyfiles]2019-05-07T14:43:21ZThomas Haller[th/cache-state-keyfiles]no longer read the state keyfiles `/var/lib/NetworkManager/timestamps` and `/var/lib/NetworkManager/seen-bssids` over and over.
Instead, keep them in memory.no longer read the state keyfiles `/var/lib/NetworkManager/timestamps` and `/var/lib/NetworkManager/seen-bssids` over and over.
Instead, keep them in memory.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/133[th/ethtool-retry]2019-05-07T07:46:19ZThomas Haller[th/ethtool-retry]ethtool/mii API is prone to races of renaming interfaces.
Try to do better by retrying the ioctl request if we determine that a race might have happend.ethtool/mii API is prone to races of renaming interfaces.
Try to do better by retrying the ioctl request if we determine that a race might have happend.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/132[th/authchain-cleanup]2019-05-13T07:27:02ZThomas Haller[th/authchain-cleanup]https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/130Update es.po. Changing "Token" translation to "testigo"2019-05-01T12:00:29ZRodrigo LledóUpdate es.po. Changing "Token" translation to "testigo"Update es.po. Changing "Token" translation from "identificador" to "testigo" as discussed in the GNOME Spanish Translation Team's mailing list. Special thanks to Daniel Mustieles our coordinator.Update es.po. Changing "Token" translation from "identificador" to "testigo" as discussed in the GNOME Spanish Translation Team's mailing list. Special thanks to Daniel Mustieles our coordinator.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/129ipv6: add 'disabled' method2019-06-11T14:33:11ZBeniamino Galvaniipv6: add 'disabled' methodAdd a new ipv6.method value 'disabled' that completely disables IPv6
for the interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1643841Add a new ipv6.method value 'disabled' that completely disables IPv6
for the interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1643841https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/128Update Ukrainian translation2019-05-01T11:57:42ZYuri ChornoivanUpdate Ukrainian translationVerified with msgfmt -vc for validity. Thanks in advance for merging.Verified with msgfmt -vc for validity. Thanks in advance for merging.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/127device: fix reapply of MTU2019-05-06T08:24:42ZBeniamino Galvanidevice: fix reapply of MTUWhen we set the MTU on the link we remember its previous source
(ip-config, parent-device or connection profile) and don't change it
again afterwards to avoid interfering with user's manual changes. The
only exceptions when we change ...When we set the MTU on the link we remember its previous source
(ip-config, parent-device or connection profile) and don't change it
again afterwards to avoid interfering with user's manual changes. The
only exceptions when we change it again are (1) if the parent device
MTU changes and (2) if the new MTU has higher priority than the one
previously set.
To allow a live reapply of the MTU property we also need to clear the
saved source, or the checks described above will prevent setting the
new value.
Fixes: 2f8917237fdf ('device: rework mtu priority handling')
https://bugzilla.redhat.com/show_bug.cgi?id=1702657https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/126[th/libnm-setting-cleanup]2019-05-01T11:47:36ZThomas Haller[th/libnm-setting-cleanup]Another small stab at unifying property handling in libnm.
We have property meta data (`NMSettInfoProperty`) for how to handle properties. On top of that, we have virtual functions in `NMSettingClass`. Also, keyfile has its own vtables....Another small stab at unifying property handling in libnm.
We have property meta data (`NMSettInfoProperty`) for how to handle properties. On top of that, we have virtual functions in `NMSettingClass`. Also, keyfile has its own vtables.
How a property is handled is spread out to various places. Also, the function pointers in `NMSettInfoProperty` have non-obvious interactions. They got called at multiple times, and the caller had to take care about to call the right function. Try to improve that a bit.
Also, save the unnecessary calls for `variant_type_for_gtype()` all the time. We can cache the result.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/125[th/test-randomize-random-seed] Revert "build: do not randomize tests by defa...2019-05-17T11:48:32ZThomas Haller[th/test-randomize-random-seed] Revert "build: do not randomize tests by default"Tests that use nmtst_*rand*() randomize test inputs and code paths.
The purpose is to cover more test cases (on average).
These may be test cases that we didn't even think about, or where
testing all combinations (every time) is not fea...Tests that use nmtst_*rand*() randomize test inputs and code paths.
The purpose is to cover more test cases (on average).
These may be test cases that we didn't even think about, or where
testing all combinations (every time) is not feasable.
The idea is that if you run the tests often enough, you will hit those
cases eventually. Optimally, we already perform these randomized tests
in a loop and would hit always all error cases. In practice, that is not
possible because we don't have time to extensivley loop and we don't
explicitly know all interesting cases we'd have to test. We we would
have a well-known, small set of interesting cases, we wouldn't need to
randomize in the first place.
So, "random" failures due to nmtst_*rand*() are not something to be
afraid of. You hunt them down by:
1) first run the test in a loop with randomization enabled.
2) once you get the failure, note the NMTST_SEED_RAND and reproduce
the failure reliably.
Note that we want that failures are reliably reproducable (2) for a
given seed. For that, all randomization must happen for internal reasons.
Meaning: the randomization in a unit tests must not depend on external factors
like the run time of a test step. If a randomized test cannot reliably
reproduce the failure after setting NMTST_SEED_RAND, then the test has a
bug that needs fixing.
Regardless of that, note that fixing NMTST_SEED_RAND to reproduce the failure
is only guaranteed to work if you run the test in the exact same configuration.
That means on the same machine, during the same boot, with the same
library versions, with the same compiler options, same environment variables,
and same command line ("-p TEST"). If you vary any of these, the failure may
not be reliably reproducable. But that's not a problem: just run the test in a
loop so that you find the offending NMTST_SEED_RAND that reproduce the issue for
*your* current configuration.
So: fixing the NMTST_SEED_RAND to 0 by default is harmful:
a) it's not guaranteed that NMTST_SEED_RAND=0 will yield the same
results in different configurations anyway. What does it help when the
test "reliably" fails in gitlab-ci but you still cannot reproduce
it on your system by using the same seed. Instead: you have to
find a seed that reproduces the issue in your environment.
b) despite a), by fixing the seed we wrongly limit the search space of
inputs and code paths that are tested. It defeats the purpose of
randomization. As explained, it is a given that one fixed seed is not
sufficient to find all possible failures. We must find all possible
failures by running often and with different seeds.
This reverts commit 9c6ff7fe1800ecbb6181a80c39e940d1bcc2da82.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/124cli: don't wait for connection change on update failure2019-06-14T15:33:27ZBeniamino Galvanicli: don't wait for connection change on update failureWhen saving a connection, we wait the connection-changed signal before
proceeding to ensure that the remote connection is up to date.
However, no signal is emitted if the update fails and so we shouldn't
wait for it.
Fixes: a370faeb59a9...When saving a connection, we wait the connection-changed signal before
proceeding to ensure that the remote connection is up to date.
However, no signal is emitted if the update fails and so we shouldn't
wait for it.
Fixes: a370faeb59a9 ('cli: wait for changed signal after updating a connection'):
https://bugzilla.redhat.com/show_bug.cgi?id=1702203https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/123manager: clear unmanaged-sleeping flag on software devices on resume2019-05-07T07:54:14ZBeniamino Galvanimanager: clear unmanaged-sleeping flag on software devices on resumehttps://bugzilla.redhat.com/show_bug.cgi?id=1701585https://bugzilla.redhat.com/show_bug.cgi?id=1701585https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/122Fix printing blob certificates2019-05-06T08:51:25ZBeniamino GalvaniFix printing blob certificateshttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/121[th/cli-team-cleanup]2019-04-25T09:50:45ZThomas Haller[th/cli-team-cleanup]https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/120PO: updated Panjabi Translation (pa.po)2019-04-20T16:07:49ZAman Alam5987-aalam1@users.noreply.gitlab.freedesktop.orgPO: updated Panjabi Translation (pa.po)Please merge Panjabi (pa.po) Translation.Please merge Panjabi (pa.po) Translation.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/119[th/gitlab-ci-build-more] gitlab-ci: test on Ubuntu 16.04, 18.04, Debian Stre...2019-04-19T06:23:15ZThomas Haller[th/gitlab-ci-build-more] gitlab-ci: test on Ubuntu 16.04, 18.04, Debian Stretch (9), Testing and Sidhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/118platform/tests: fix assertion for nmp_object2019-04-18T08:23:23ZHW-ljplatform/tests: fix assertion for nmp_objectHere we should assert nmp_object_is_visible is NULL, just as what master branch do. Otherwise we will meet
> ERROR: src/platform/tests/test-nmp-object - Bail out! test:ERROR:src/platform/tests/test-nmp-object.c:390:test_cache_link: ass...Here we should assert nmp_object_is_visible is NULL, just as what master branch do. Otherwise we will meet
> ERROR: src/platform/tests/test-nmp-object - Bail out! test:ERROR:src/platform/tests/test-nmp-object.c:390:test_cache_link: assertion failed: (nmp_object_is_visible (obj_new))https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/117[th/strsplit-pt4]2019-04-18T16:54:32ZThomas Haller[th/strsplit-pt4]https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/116Update es.po2019-04-17T15:43:18ZRodrigo LledóUpdate es.poHello,
I managed to copy all the good strings and fix the wrong ones.Hello,
I managed to copy all the good strings and fix the wrong ones.https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/115[th/platform-routing-rules-compare]2019-04-18T09:25:10ZThomas Haller[th/platform-routing-rules-compare]When running against older kernels (e.g. rhel-7), then kernel might not support several routing rule attributes.
Note that `NMPRulesManager` checks whether a rule exists before adding it ([[1]](https://gitlab.freedesktop.org/NetworkMana...When running against older kernels (e.g. rhel-7), then kernel might not support several routing rule attributes.
Note that `NMPRulesManager` checks whether a rule exists before adding it ([[1]](https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/832adf323eaa958bf5d0b0cb6305448c194be561/src/platform/nmp-rules-manager.c#L574)). That means, NetworkManager must use the same notion of what equality means as the current kernel we run against.
Preferably, we detect that at runtime, but kernel does not make that easy so have a compile-time default as fallback that depends on the kernel headers we built against.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1652653https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/114WIP: all: support bridge vlan ranges2019-04-18T07:57:13ZBeniamino GalvaniWIP: all: support bridge vlan rangesIn some cases it is convenient to specify ranges of bridge vlans, as
already supported by iproute2 and natively by kernel. With this commit
it becomes possible to add a range in this way:
`nmcli connection modify eth0-slave +bridge-po...In some cases it is convenient to specify ranges of bridge vlans, as
already supported by iproute2 and natively by kernel. With this commit
it becomes possible to add a range in this way:
`nmcli connection modify eth0-slave +bridge-port.vlans "100-200 untagged"`
vlan ranges can't be PVIDs because only one PVID vlan can exist.
https://bugzilla.redhat.com/show_bug.cgi?id=1652910