| 29 Jun 2025 |
 emily | hm no, module looks benign too | 15:18:59 |
 K900 | And iwd doesn't want to deal with external secret providers | 15:19:00 |
 hexa | we're in the +38 MB range and modemmanager is another 13 MB (just the package output) | 15:19:12 |
| emily | so I don't know what's making modemmanager look huge but I can't corroborate it | 15:19:13 |
| hexa | * we're in the +38 MB range and modemmanager is another 13 MB (just the package output) we could save | 15:19:26 |
| K900 | And neither side wants to actually sort this out | 15:19:35 |
| emily | so, again openconnect is by far the hugest part of this | 15:19:40 |
| hexa | so I'm not feeling strongly about removing it, but I don't think the use case is that great to begin with | 15:19:45 |
| emily | it adds 249.55 MiB to the networkmanager closure | 15:19:49 |
| hexa | doubt | 15:19:53 |
| hexa | well, not doubt | 15:19:57 |
| emily | out of 520.45 MiB | 15:19:59 |
| emily | nix-tree nixpkgs#networkmanager, look yourself | 15:20:08 |
| hexa | why do I get such a small closure size increase then? | 15:20:10 |
| hexa | did we have that in there before? | 15:20:20 |
| emily | you aren't eliminating openconnect from networkmanager the package | 15:20:24 |
| emily | just the plugin, which is a separate thing that also pulls it in | 15:20:30 |
| emily | get rid of the fix-paths.patch in NM and it should get a lot smaller | 15:20:38 |
| emily | we have to actually… fix that, of course | 15:20:46 |
| hexa | right, but why does the ISO only become 38 MB larger I don't understand | 15:21:03 |
| emily | I don't fully understand the results you're getting but it might just be compression | 15:21:08 |
| hexa | possibly | 15:21:15 |
| emily | but like, openconnect is pulling in GTK 3 | 15:21:23 |
| emily | if we had GTK 3 on the minimal ISO already that's uh… | 15:21:27 |
| hexa | bad | 15:21:45 |
| emily | (I guess we probably do now that I say that…) | 15:21:45 |
| emily | it pulls in GTK via… https://github.com/stoken-dev/stoken | 15:22:02 |
| hexa | diff --git a/src/libnmc-base/nm-vpn-helpers.c b/src/libnmc-base/nm-vpn-helpers.c
index cbe76f5f1c..0c9185e8ff 100644
--- a/src/libnmc-base/nm-vpn-helpers.c
+++ b/src/libnmc-base/nm-vpn-helpers.c
@@ -311,13 +311,8 @@ nm_vpn_openconnect_authenticate_helper(NMSettingVpn *s_vpn, GPtrArray *secrets,
port = extract_url_port(gw);
- path = nm_utils_file_search_in_paths("openconnect",
- "/usr/sbin/openconnect",
- DEFAULT_PATHS,
- G_FILE_TEST_IS_EXECUTABLE,
- NULL,
- NULL,
- error);
+ path = g_find_program_in_path("openconnect");
+
if (!path)
return FALSE;
| 15:39:41 |
| hexa | https://docs.gtk.org/glib/func.find_program_in_path.html | 15:39:56 |
| emily | probably works, but no idea if we reliably get openconnect into the path when the plugin is enabled | 15:45:05 |
