summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* device: release slaves when an external device is going managedlr/cancel-ip-state-with-activationLubomir Rintel2022-06-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we're deactivating an externally created device that has a master because we're activating a connection on it, actually remove the device from the master. Otherwise unpleasant things happen: active-connection[0x55ed7ba78400]: constructed (NMActRequest, version-id 4, type managed) device[0a458361f9fed8f5] (dummy0): sys-iface-state: external -> managed device[0a458361f9fed8f5] (dummy0): queue activation request waiting for currently active connection to disconnect device (dummy0): disconnecting for new activation request. device (dummy0): state change: activated -> deactivating (reason 'new-activation', sys-iface-state: 'managed') device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (enslaved)(no-config) Note the "no-config" above. We'set priv->master = NULL, but didn't communicate the change to the platform. I believe this is not good. This patch changes that. device (br0): bridge port dummy0 was detached device (dummy0): released from master device br0 active-connection[0x55ed7ba782e0]: set state deactivating (was activated) device (dummy0): ip4: set state none (was done, reason: ip-state-clear) device (dummy0): ip6: set state none (was done, reason: ip-state-clear) device (dummy0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed') platform: (dummy0) emit signal link-changed changed: 102: dummy0 <NOARP,UP,LOWER_UP;broadcast,noarp,up,running,lowerup> mtu 1500 master 101 arp 1 dummy* init addrgenmode none addr EA:8D:DD:DF:1F:B7 brd FF:FF:FF:FF:FF:FF driver dummy rx:0,0 tx:39,4746 Now the platform sent us a new link, the "master" property is still set. device[0a458361f9fed8f5] (dummy0): queued link change for ifindex 102 device[0a458361f9fed8f5] (dummy0): deactivating device (reason 'new-activation') [60] device (dummy0): ip: set (combined) state none (was done, reason: ip-state-clear) config: device-state: write #102 (/run/NetworkManager/devices/102); managed=managed, perm-hw-addr-fake=EA:8D:DD:DF:1F:B7, route-metric-default=0-0 active-connection[0x55ed7ba782e0]: set state deactivated (was deactivating) active-connection[0x55ed7ba782e0]: check-master-ready: already signalled (state deactivated, master 0x55ed7ba781c0 is in state activated) device (dummy0): Activation: starting connection 'dummy1' (ec6fca51-84e6-4a5b-a297-f602252c9f69) device[0a458361f9fed8f5] (dummy0): activation-stage: schedule activate_stage1_device_prepare l3cfg[ae290b5c1f585d6c,ifindex=102]: emit signal (platform-change-on-idle, obj-type-flags=0x2a) device (br0): master: add one slave 0a458361f9fed8f5/dummy0 Amidst the new activation we're processing the netlink message we got. We set priv->master back, effectively nullifying the release above. Sad. device (dummy0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'in-state-change' active-connection[0x55ed7ba78400]: set state activating (was unknown) manager: NetworkManager state is now CONNECTING active-connection[0x55ed7ba78400]: check-master-ready: not signalling (state activating, no master) device[8fff58d61c7686ce] (br0): slave dummy0 state change 30 (disconnected) -> 40 (prepare) device[0a458361f9fed8f5] (dummy0): remove_pending_action (1): 'in-state-change' device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (not enslaved) (force-configure) platform: (dummy0) link: releasing 102 from master 'br0' (101) device (br0): detached bridge port dummy0 Now things go south. The stage1 cleans the device up, removing it from the master and the device itself decides it should deactivate itself because it lots its master regardless of the fact that it should not have one and it's in fact an unwanted carryover from previous activation. I believe this is also wrong. device[0a458361f9fed8f5] (dummy0): Activation: connection 'dummy1' master deactivated device (dummy0): ip4: set state none (was pending, reason: ip-state-clear) device (dummy0): ip6: set state none (was pending, reason: ip-state-clear) device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'queued-state-change-deactivating' device[0a458361f9fed8f5] (dummy0): queue-state[deactivating, reason:connection-assumed, id:298]: queue state change device[0a458361f9fed8f5] (dummy0): activation-stage: synchronously invoke activate_stage2_device_config device (dummy0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Now things are really weird. We synchronously go to config, effectively overriding the queued deactivation. We've really messed up.
* device: only deactivate when the master we've enslaved to goes awayLubomir Rintel2022-06-091-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes weird things happen. Let dummy0 be an externally created device that has a master. We decide to activate a connection that has no master on it: active-connection[0x55ed7ba78400]: constructed (NMActRequest, version-id 4, type managed) device[0a458361f9fed8f5] (dummy0): sys-iface-state: external -> managed device[0a458361f9fed8f5] (dummy0): queue activation request waiting for currently active connection to disconnect device (dummy0): disconnecting for new activation request. device (dummy0): state change: activated -> deactivating (reason 'new-activation', sys-iface-state: 'managed') device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (enslaved)(no-config) Note the "no-config" above. We'set priv->master = NULL, but didn't communicate the change to the platform. I believe this is not good. device (br0): bridge port dummy0 was detached device (dummy0): released from master device br0 active-connection[0x55ed7ba782e0]: set state deactivating (was activated) device (dummy0): ip4: set state none (was done, reason: ip-state-clear) device (dummy0): ip6: set state none (was done, reason: ip-state-clear) device (dummy0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed') platform: (dummy0) emit signal link-changed changed: 102: dummy0 <NOARP,UP,LOWER_UP;broadcast,noarp,up,running,lowerup> mtu 1500 master 101 arp 1 dummy* init addrgenmode none addr EA:8D:DD:DF:1F:B7 brd FF:FF:FF:FF:FF:FF driver dummy rx:0,0 tx:39,4746 Now the platform sent us a new link, the "master" property is still set. device[0a458361f9fed8f5] (dummy0): queued link change for ifindex 102 device[0a458361f9fed8f5] (dummy0): deactivating device (reason 'new-activation') [60] device (dummy0): ip: set (combined) state none (was done, reason: ip-state-clear) config: device-state: write #102 (/run/NetworkManager/devices/102); managed=managed, perm-hw-addr-fake=EA:8D:DD:DF:1F:B7, route-metric-default=0-0 active-connection[0x55ed7ba782e0]: set state deactivated (was deactivating) active-connection[0x55ed7ba782e0]: check-master-ready: already signalled (state deactivated, master 0x55ed7ba781c0 is in state activated) device (dummy0): Activation: starting connection 'dummy1' (ec6fca51-84e6-4a5b-a297-f602252c9f69) device[0a458361f9fed8f5] (dummy0): activation-stage: schedule activate_stage1_device_prepare l3cfg[ae290b5c1f585d6c,ifindex=102]: emit signal (platform-change-on-idle, obj-type-flags=0x2a) device (br0): master: add one slave 0a458361f9fed8f5/dummy0 Amidst the new activation we're processing the netlink message we got. We set priv->master back, effectively nullifying the release above. device (dummy0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'in-state-change' active-connection[0x55ed7ba78400]: set state activating (was unknown) manager: NetworkManager state is now CONNECTING active-connection[0x55ed7ba78400]: check-master-ready: not signalling (state activating, no master) device[8fff58d61c7686ce] (br0): slave dummy0 state change 30 (disconnected) -> 40 (prepare) device[0a458361f9fed8f5] (dummy0): remove_pending_action (1): 'in-state-change' device (br0): master: release one slave 0a458361f9fed8f5/dummy0 (not enslaved) (force-configure) platform: (dummy0) link: releasing 102 from master 'br0' (101) device (br0): detached bridge port dummy0 Now stage1 cleans the device up, removing it from the master. device[0a458361f9fed8f5] (dummy0): Activation: connection 'dummy1' master deactivated device (dummy0): ip4: set state none (was pending, reason: ip-state-clear) device (dummy0): ip6: set state none (was pending, reason: ip-state-clear) device[0a458361f9fed8f5] (dummy0): add_pending_action (2): 'queued-state-change-deactivating' We decide to deal with this by enqueuing a deactivation. That is not great -- we shouldn't even have had this master! This patch takes the deactivation path only if we were willingly enslaved to the master in question.
* device: stop checking the IP configuration state when cancelling activationLubomir Rintel2022-06-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The @bond_mode_8023ad test has been seen failing, with a log like this: <debug> [...3.0484] device[...] (eth1): Activation: connection 'bond0.0' master deactivated <debug> [...3.0484] device[...] (eth1): add_pending_action (2): 'queued-state-change-deactivating' <debug> [...3.0484] device[...] (eth1): queue-state[deactivating, reason:new-activation, id:709]: queue state change What happened is that eth1 has been activating. It was already enslaved to a bond and was in an ip-config state when the bond was removed. A change to "deactivating" state has been enqueued. But then this happened: <trace> [...3.0942] device[...] (eth1): ip4: check-state: state done => done, is_failed=0, is_pending=0, is_started=0 temp_na=0, may-fail-4=1, may-fail-6=1; disabled4; manualip4=done; ignore6 manualip6=done <trace> [...3.0942] device[...] (eth1): ip: check-state: (combined) state pending => done <debug> [...3.0943] device[...] (eth1): ip: set (combined) state done (was pending, reason: check-ip-state) <info> [...3.0943] device (eth1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') <debug> [...3.0943] device[...] (eth1): add_pending_action (3): 'in-state-change' <debug> [...3.0943] device[...] (eth1): queue-state[deactivating, reason:new-activation, id:709]: clear queued state change The IP config succeeded and the queued "deactivating" change was overriden by the IP4 check result, prompting a change to "ip-check". With the master still missing. Not good. Let's terminate the appempts to check the IP state when we cancel the activation, so that it doesn't override the enqueued state change. Fixes-test: @bond_mode_8023ad https://bugzilla.redhat.com/show_bug.cgi?id=2080928 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1245
* dispatcher: log duration of dispatcher callThomas Haller2022-06-091-15/+63
| | | | | | | | | Yes, we anyway log the timestamps for every log message. So one could always calculate the offset. However, when you read a logfile, it can be cumbersome to stop looking at where you currently are to find the start/end of a call. For convenience, log the duration explicitly. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1251
* contrib: enable DHCPv6 in "m-in-container.sh"'s "nm-env-prepare.sh"Thomas Haller2022-06-091-0/+3
|
* std-aux: cleanup NM_CMP_*() macrosThomas Haller2022-06-091-36/+48
| | | | | | | | - add code comments explaining some things. - for NM_CMP_FIELD*() variants have a corresponding NM_CMP_DIRECT*() macro and use it (aside the "memcmp" variants, which don't translate directly).
* device: fix memory leakbg/memBeniamino Galvani2022-06-091-9/+7
| | | | | | | | | | | | | | | | | | l3cd instances must be removed from the old l3cfg before calling _cleanup_ip_pre(). Otherwise, _cleanup_ip_pre() unregisters them from the device, and later _dev_l3_register_l3cds(self, l3cfg_old, FALSE, FALSE) does nothing because the device doesn't have any l3cd. Previously the l3cds would linger in the l3cfg, keeping a reference to it and causing a memory leak; the leak was not detected by valgrind because the l3cfg was still referenced by the NMNetns. Fixes: 58287cbcc0c8 ('core: rework IP configuration in NetworkManager using layer 3 configuration') Fixes-test: @stable_mem_consumption2 https://bugzilla.redhat.com/show_bug.cgi?id=2083453 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1252
* l3cfg: fix comparing "has-dns-priority" flag in nm_l3_config_data_cmp_full()Thomas Haller2022-06-091-1/+4
| | | | Fixes: cb29244552af ('core: support compare flags in nm_l3_config_data_cmp_full()')
* contrib: set git-blame options in "nm-setup-git.sh"Thomas Haller2022-06-081-0/+2
|
* ifcfg: set errno for svGetValueEnum() to detect unset valuesThomas Haller2022-06-071-0/+3
|
* n-dhcp4: re-import git-subtree for 'src/n-dhcp4'Thomas Haller2022-06-070-0/+0
|\ | | | | | | git subtree pull --prefix src/n-dhcp4 git@github.com:nettools/n-dhcp4.git master --squash
| * Squashed 'src/n-dhcp4/' changes from e4af93228e37..7db7dc4bab53Thomas Haller2022-06-073-61/+40
| | | | | | | | | | | | | | | | | | | | 7db7dc4bab53 probe: merge branch 'th/decline-fixes' bb61737788dd probe: fix internal state after declining lease c5d0f38ab7a9 probe: maintain the probe's lease list in "n-dhcp4-c-probe.c" 48bf2788336e probe: return error when calling accept/decline/select in unexpected state git-subtree-dir: src/n-dhcp4 git-subtree-split: 7db7dc4bab5312218135464d8550a86845ca6fdd
* | contrib: don't use :Z for bind mounts in "nm-in-container.sh"Thomas Haller2022-06-031-2/+2
| | | | | | | | | | I am not sure why I added this. I think it's not necessary or useful. Drop it.
* | tools: Fix generate-docs-nm-settings-docs-gir.py on Python 2Igor Ponomarev2022-06-031-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On python2 the following error is raised: `LookupError: unknown encoding: unicode` Seems like `unicode` is a correct encoding in Python 3 but not 2. Fix: 1. Change encoding to `utf-8` 2. Pass output path string instead of opening file and passing opened file object. Python2 and 3 might need different file modes, passing just path lets ElementTree select appropriate file mode. Fixes: f00e90923c8c ('tools: Use ElementTree to write XML in generate-docs-nm-settings-docs-gir.py') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1249
* | gitlab-ci: test build with python2 on Centos7Thomas Haller2022-06-021-0/+9
| | | | | | | | | | | | | | | | | | | | Currently, for all tests we have python3 installed. So effectively, even on CentOS 7, we would test the build with python3 only. The package build on CentOS7/epel7 however uses python2. This happens for example for our copr builds. Also test that configuration in gitlab-ci.
* | build: print python path for autotoolsThomas Haller2022-06-021-0/+1
| |
* | wifi: fix crash in NMDeviceWifi.check_connection_compatible() checking WEP ↵Thomas Haller2022-06-021-2/+3
| | | | | | | | | | | | | | | | capability https://bugzilla.redhat.com/show_bug.cgi?id=2092782 Fixes: feee84aac427 ('wifi: mark WEP connections incompatible if supplicant lacks capability')
* | release: bump version to 1.39.6 (development)1.39.6-devBeniamino Galvani2022-06-012-2/+2
| |
* | dhcp: merge branch 'th/dhcp-acd'Thomas Haller2022-06-0116-436/+1187
|\ \ | | | | | | | | | | | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1713380 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1230
| * | dhcp: implement ACD (address collision detection) for DHCPv4Thomas Haller2022-06-015-118/+616
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was working for internal plugin in the past, but broken by l3cfg rework with 1.36. Re-add it. Not it also works with dhclient. For other plugins, it's not really working, because we can't decline. Now NMDhcpClient does ACD (using NML3Cfg) and abstracts that from the caller (NMDevice). It is complicated. Because there is state involved, meaning, we need to remember the current state for ACD and react on and handle a multitude of events. Getting this right, is non-trivial. What we want is that if ACD fails, we decline the lease (and don't use it). https://bugzilla.redhat.com/show_bug.cgi?id=1713380
| * | dhcp/dhclient: implement accept/decline (ACD) for dhclient pluginThomas Haller2022-05-314-62/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dhclient itself doesn't do ACD. However, it expects the dhclient-script to exit with non-zero status, which causes dhclient to send a DECLINE. `man dhclient-script`: BOUND: Before actually configuring the address, dhclient-script should somehow ARP for it and exit with a nonzero status if it receives a reply. In this case, the client will send a DHCPDECLINE message to the server and acquire a different address. This may also be done in the RENEW, REBIND, or REBOOT states, but is not required, and indeed may not be desirable. See also Fedora's dhclient-script ([1]). https://gitlab.isc.org/isc-projects/dhcp/-/issues/67#note_97226 https://gitlab.isc.org/isc-projects/dhcp/-/blob/33226f2d76b6b7a06df6b76abbb3526100f5ae2d/client/dhclient.c#L1652 [1] https://src.fedoraproject.org/rpms/dhcp/blob/a8f6fd046fe5ff39631ab8da4ebad00f96fd4f15/f/dhclient-script#_878 https://bugzilla.redhat.com/show_bug.cgi?id=1713380
| * | dhcp: minor cleanup of accept/decline functions in "nm-dhcp-client.c"Thomas Haller2022-05-311-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | - assign the result of NM_DHCP_CLIENT_GET_CLASS() to a local variable. It feels nicer to only call the macro once. Of course, the macro expands to plain pointer dereferences, so there is little difference in terms of executed code. - handle the default case with no virtual function first.
| * | dhcp/nettools: pop n-dhcp4 events after select/accept/decline to process ↵Thomas Haller2022-05-311-1/+62
| | | | | | | | | | | | logging events
| * | dhcp/nettools: add helper function dhcp4_event_pop_all_events()Thomas Haller2022-05-311-3/+11
| | | | | | | | | | | | Will be used next.
| * | dhcp/nettools: cleanup logging for dhcp4_event_handle()Thomas Haller2022-05-311-30/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's pretty pointless to log <trace> [1653389116.6288] dhcp4 (br0): client event 7 <debug> [1653389116.6288] dhcp4 (br0): received OFFER of 192.168.121.110 from 192.168.121.1 where the obscure event #7 is only telling you that we are going to log something. Handle logging events first. In general, drop the "client event %d" message and make sure that all code paths log something (useful), so we can see in the log that the event was reached.
| * | dhcp/nettools: better track currently granted leaseThomas Haller2022-05-313-37/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we accept/decline a lease, then that only works if we are in state GRANTED. n-dhcp4 API also requires us, to provide the exact lease, that we were announced earlier. As such, we need to make sure that we don't accept/decline in the wrong state. That means, to keep track of what we are doing more carefully. The functions _dhcp_client_accept()/_dhcp_client_decline() now take a l3cd argument, the one that we announced earlier. And we check that it still matches.
| * | dhcp: move accept/decline function inside "nm-dhcp-client.c"Thomas Haller2022-05-312-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | They are no longer used from outside, NMDhcpClient fully handles this. Make them static and internal. Also, decline is currently unused. It will be used soon, with ACD support.
| * | n-dhcp4: fix internal state after declining leaseThomas Haller2022-05-312-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, during decline we would clear probe->current_lease, however leave the state at GRANTED. That is a wrong state, and can easily lead to a crash later. For example, on the next timeout we will end up at n_dhcp4_client_dispatch_timer(), then current-lease gets accessed unconditionally: case N_DHCP4_CLIENT_PROBE_STATE_GRANTED: if (ns_now >= probe->current_lease->lifetime) { Instead, return to INIT state and schedule a timer. As suggested by RFC 2131, section 3.1, 5) ([1]). [1] https://datatracker.ietf.org/doc/html/rfc2131#section-3.1
| * | n-dhcp4: maintain the probe's lease list in "n-dhcp4-c-probe.c"Thomas Haller2022-05-312-39/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lease list and the probe's state are strongly related. That is evidenced by the fact that sometimes we check the state and then access probe->current_lease without further checking. The code in "n-dhcp4-c-probe.c" (select_lease, accept, decline) already changes and maintains the state, it should also maintain the lease list. Move the code.
| * | n-dhcp4: return error when calling accept/decline/select in unexpected stateThomas Haller2022-05-312-21/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | The caller is supposed to call accept/decline/select with the lease that was just announced. Calling it in the wrong state or with the wrong lease is a user error. Return an error when called in the wrong state, so that the user notices they did something wrong.
| * | dhcp: add and use _NMLOG() macro for "nm-dhcp-manager.c"Thomas Haller2022-05-311-18/+41
| | |
| * | dhcp: improve warning logging for dhcp4_event_handle() failureThomas Haller2022-05-311-1/+1
| | |
| * | dhcp: ensure a valid DHCPv4 lease has an address for dhclientThomas Haller2022-05-311-0/+3
| | | | | | | | | | | | | | | | | | The same check is also for nettools' n-dhcp4 client. It's useful to being able to rely on certain things, like that an DHCPv4 lease always has exactly one address (not equal to 0.0.0.0).
| * | dhcp/trivial: rename connect_l3cfg_notify() to l3_cfg_notify_check_connected()Thomas Haller2022-05-311-6/+6
| | | | | | | | | | | | | | | The function subscribes a callback l3_cfg_notify_cb(). Rename so that related functions have a clearly related name.
| * | dhcp: replace switch in l3_cfg_notify_cb() with if blocksThomas Haller2022-05-311-20/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The l3_cfg_notify_cb() handler is used for different purposes, and different events will be considered. Usually a switch statement is very nice for enums, especially if all enum values should be handled (because the compiler can warn about unhandled cases). In this case, not all events are supposed to be handled. At this point, it seems nicer to just use an if block. It better composes. The compiler should be able to optimize both variants to the same result. In any case, checking some integers for equality is in any case going to be efficient.
| * | dhcp: move addr-family specific data to union in NMDhcpClientPrivateThomas Haller2022-05-312-10/+36
| | |
| * | dhcp/trivial: drop obsolete code commentThomas Haller2022-05-311-9/+0
| | | | | | | | | | | | This is done already.
| * | dhcp: fix logging of event in _nm_dhcp_client_notify()Thomas Haller2022-05-311-1/+1
| | |
| * | core: move NM_ACD_TIMEOUT_MAX_MSEC define to "nm-l3cfg.h" header for reuseThomas Haller2022-05-312-5/+5
| | |
| * | device: initialize full v4/v6 union of NMDhcpClientConfig in ↵Thomas Haller2022-05-311-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | _dev_ipdhcpx_start() I think the previous was technically correct in any case too. Still change it, because I feel with union and struct initialization, we should always explicitly pick one union member that we fully initialize.
| * | glib-aux: add assertions to nm_strvarray_*() helpersThomas Haller2022-05-311-5/+18
| | |
| * | glib-aux: add nm_g_array_index_p() helper and cleanup nm_g_array*() helpersThomas Haller2022-05-311-28/+47
| | |
| * | glib-aux/logging: add LOGD_DHCP_af() helper macroThomas Haller2022-05-311-1/+10
| | |
| * | contrib: install black/clang-format in nm-in-container.shThomas Haller2022-05-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | It's just convenient to have some tools around, not only for testing, but also for (some limited) development. In particular, because we bind-mount .vimrc inside the container, and if I use vim, black/clang-format is just one key binding away.
| * | contrib: add "journal" command to "nm-in-container.sh" for showing logsThomas Haller2022-05-311-8/+32
| | |
| * | contrib: improve bashrc for nm-in-container.shThomas Haller2022-05-311-1/+8
|/ /
* | contrib: add script "nm-setup-git.sh" for setting up NetworkManager git ↵Thomas Haller2022-05-311-0/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | repository You can of course just clone NetworkManager repository and start hacking as you like. However, there are a few things like git-notest which are interesting to setup. Add a script to do this. The script is supposed to be idempotent and do nothing, unless necessary. By default it also only prints what it would do.
* | tools: merge branch 'gfm:generate-docs-nm-settings-docs-gir-preserve-newlines'Thomas Haller2022-05-311-109/+112
|\ \ | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1246
| * | tools: Use ElementTree to write XML in generate-docs-nm-settings-docs-gir.pyIgor Ponomarev2022-05-311-39/+30
| | | | | | | | | | | | | | | | | | | | | | | | Instead of manually writting XML line by line. Quoting is automatic. Makes it much easier to modify. (just add new elements) Generated XML not indented at the moment.
| * | tools: Modernize generate-docs-nm-settings-docs-gir.py to 2022 standardsIgor Ponomarev2022-05-311-101/+113
|/ / | | | | | | | | | | | | | | | | * Create main() function and put its execution under __name__ == '__main__' guard. * Only one module import per line * Use required=True to check if necessary arguments have been passed. * Remove usage() as ArgumentParser handles that already
View Lorry Controller Status