New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openconnect: fix paths to systemd tools in vpnc-script #121917
Conversation
Result of 124 packages marked as broken and skipped:
441 packages skipped due to time constraints:
12 packages built successfully:
Result of 130 packages marked as broken and skipped:
513 packages skipped due to time constraints:
12 packages built successfully:
1 suggestion:
|
The license headers in OpenConnect sources have some occurrences of “or later version” but most of them do not contain that text. So, I am assuming the stricter interpretation applies.
Your approach looks good, but if you feel adventurous this looks like a perfect use case for resholve, see pkgs/development/misc/resholve/README.md |
I attempted to use resholve but this is as far as I got.
Does the command look right? Seems to me like the keep directive |
hum I don't know, cc @abathur maybe? |
@symphorien @liff This is abathur/resholve#23. I'll be brief since I'm working on the fix at the moment, but the TL;DR:
|
@tricktron #106465 looks good, though it wouldn’t work for me with systemd-resolved. I’ll continue on that one. |
Motivation for this change
The vpnc-script looks for a bunch of tools in fixed FHS paths. Since it won’t find them it’ll use the fallback mechanism to update DNS information, which means it’ll just change
/etc/resolv.conf
. This doesn’t work too well with systemd.There’s also #105020, which this should fix.
Things done
vpnc-scripts
to the latest version from Git.vpnc-scripts
build to just installvpnc-script
and fix the paths in it.lgpl21Only
per Robot Robert’s suggestion.The license headers in OpenConnect sources have some occurrences of “or later version” but most of them do not contain that text. So, I am assuming the stricter(?) interpretation applies.
Didn’t run
nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
since that would build a rather sizable portion of the desktop (GNOME/KDE) world.sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)