Package Details: libnm-iwd 1.50.1-1

Git Clone URL: https://aur.archlinux.org/networkmanager-iwd.git (read-only, click to copy)
Package Base: networkmanager-iwd
Description: NetworkManager client library with iwd backend
Upstream URL: https://networkmanager.dev/
Licenses: LGPL-2.1-or-later
Conflicts: libnm
Provides: libnm, libnm.so
Submitter: digitalone
Maintainer: buzo
Last Packager: buzo
Votes: 34
Popularity: 0.22
First Submitted: 2019-08-10 10:04 (UTC)
Last Updated: 2024-12-25 21:02 (UTC)

Required by (52)

Sources (2)

Pinned Comments

digitalone commented on 2019-08-10 10:37 (UTC) (edited on 2019-08-15 09:14 (UTC) by digitalone)

This is a modified package configured to get NetworkManager working exclusively with iwd. Main difference with upstream version is that iwd is required and wpa_supplicant is not needed (so you can uninstall it); iwd seems more reliable on certain wireless cards, so someone could prefer it in place of wpa_supplicant.

It's recommended to enable systemd iwd.service at boot: systemctl enable iwd.service

Tested with Plasma NM system tray applet (plasma-nm), it's working.

Note that wpa_supplicant is still needed to build the package, but you can uninstall it after the building stage.

Latest Comments

1 2 3 4 5 Next › Last »

maksverver commented on 2025-01-04 13:50 (UTC)

@tamarindx: Another thing you can try is taskset 1 makepkg to lock the job to a single CPU core, so ninja won't spawn as many parallel tasks. (taskset is in the util-linux package.) I'd still recommend disabling LTO though, or compilation will take a long time.

By the way this type of discussion is probably better suited for the Arch Linux forums.

tamarindx commented on 2025-01-04 03:58 (UTC)

@makserver: I've added that line and removes those lines, it is defintely change the compiling proccess from 1000+ to 200+, but that compile proccess still took all my memory and freeze.

maksverver commented on 2025-01-04 01:06 (UTC)

@tamarindx: This is probably caused by a combination of the fact that ninja tries to use all available CPU cores and this package uses LTO which is notoriously memory-intensive, so on a system with lots of CPU cores but relatively little memory, you run out of memory.

Try disabling LTO by applying this patch:

--- a/PKGBUILD
+++ b/PKGBUILD
@@ -20,6 +20,7 @@ pkgdesc="Network connection manager and user applications; using iwd backend ins
 url="https://networkmanager.dev/"
 arch=(x86_64)
 license=(LGPL-2.1-or-later)
+options=(!lto)
 makedepends=(
   audit
   bash
@@ -68,9 +69,6 @@ b2sums=('316b1a2e8dfe4d7c0c0fab36f506a8315bf4045f11c5820fb41ea4735dc0a248c04367b

 build() {
   local meson_options=(
-    # build checks this option; injecting just via *FLAGS is broken
-    -D b_lto=true
-
     # platform
     -D dist_version="$pkgver-$pkgrel"
     -D session_tracking_consolekit=false

This will speed up the build process by a factor 100 or more without any noticeable downsides.

IMO its a mistake to enable LTO for AUR packages like this. Some basic math: enabling LTO increases build time by 60 minutes of CPU-core time. If LTO increases performance by 10% you'd need to spend 600 minutes of CPU time on NetworkManager to recover the loss. Since there is a new version released every month or so, that means you need to spend 20 minutes of CPU-core time per day just to break even. NetworkManager doesn't run that much under normal circumstances. So enabling LTO is just a big waste of CPU cycles.

tamarindx commented on 2025-01-03 22:48 (UTC)

Can't even managed to pass the ninja cmake compile proccess... it's eating all my RAM and freeze.

Taijian commented on 2024-10-09 00:00 (UTC)

While looking at some code over on github, I noticed that for the past two years there has been this build option: -D config_wifi_backend_default=iwd. Using this allows building without wpa-supplicant as a build dependency and without installing that override file into /usr/lib/NetworkManager/conf.d/30-wifi-backend.conf

JoeyCorleone commented on 2024-06-22 07:03 (UTC)

Yes, confirmed. As per this comment by heftig:

Thanks to Fabian, as of 2.80.3-1, the development utilities requiring additional dependencies (python, python-packaging, libelf) have been split from glib2 into glib2-devel with proper depends. You may need to add glib2-devel to the makedepends of your packages to get them to build again. At the same time, consider removing python or python-packaging from the makedepends if they were only added to run gdbus-codegen, glib-genmarshal or glib-mkenums.

Taijian commented on 2024-06-21 09:48 (UTC) (edited on 2024-06-21 09:49 (UTC) by Taijian)

Well, in this case glib2-devel should probably be added to makedepends instead of glib2?

dumbnerd commented on 2024-06-21 09:20 (UTC) (edited on 2024-06-21 09:21 (UTC) by dumbnerd)

If anyone else encounters this error during the build:

ERROR: Dependency 'gio-2.0' tool variable 'gdbus_codegen' contains erroneous value: '/usr/bin/gdbus-codegen'

Make sure you have the glib2-devel package installed.

JoeyCorleone commented on 2024-06-19 14:05 (UTC)

Build-time dependency gio-2.0 found: YES 2.80.3
Program /usr/bin/gdbus-codegen found: NO

NetworkManager/introspection/meson.build:66:14: ERROR: Dependency 'gio-2.0' tool variable 'gdbus_codegen' contains erroneous value: '/usr/bin/gdbus-codegen'

This is a distributor issue -- please report it to your gio-2.0 provider.

Anybody else getting this when trying to build?

buzo commented on 2021-12-15 16:24 (UTC)

Thanks Tomodoro for that research, and sorry for the delay. Turns out that the default location for polkit_agent_helper_1 is already the correct one, so I have omitted it completely.

saubakirov: I have no clue what these error messages mean – I hope this update fixes the build for you, too.