[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#953569: linux: please cherry-pick wireguard patches from 5.6



Package: src:linux
Severity: wishlist
Control: affects -1 src:wireguard-linux-compat src:wireguard

Hi Debian kernel folks--

Please cherry-pick the wireguard patches from Linux's 5.6 development
branch into future debian builds of 5.5 (and 5.4?) builds of the Linux
kernel.

The Wireguard VPN mechanism is due to be released in upstream kernel
5.6.  Debian unstable and testing currently have all the tooling needed
to configure and control wireguard interfaces as long as the kernel
module is available.  In particular, systemd-networkd is capable of
configuring wireguard interfaces in some standard configurations, and
the "wireguard-tools" source package offers fine-grained control via
/usr/bin/wg and a "wg-quick@" systemd unit template.

The kernel module itself has been available for a few years now for
people with machines that can afford to compile source code via
wireguard-dkms, but the dkms fooptprint and failure modes make it more
heavyweight than just having the module available directly.

I was looking into how to simplify this, and part of it involved
packaging a kernel module, but i've been dissuaded by folks on the
#debian-kernel IRC channel from trying to keep such a thing in debian.

bwh suggested cherry-picking the wireguard patches into src:linux 5.5,
which would be great.

the wireguard metapackage currently has:

    Depends: wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 0.0.20191219)

so it would be nice if you could add the following metadata to any
generated binary packages:

    Provides: wireguard-modules (= 0.0.20200121-2)

(you can replace the version number with whatever version info is
present in the upstream series that you cherry-pick, of course)

I understand from some folks on #debian-kernel that they don't think
this sort of dependency resolution mechanism is good to do, but it
doesn't appear to hurt anything, and it should smooth out the default
use case, so it seems like a win to me.

Thanks for considering this,

      --dkg

Attachment: signature.asc
Description: PGP signature


Reply to: