Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #66499 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#953569: linux: please cherry-pick wireguard patches from 5.6 Daniel Kahn Gillmor <dkg@fifthhorseman.net> - 2020-03-10 19:10 +0100
    Processed: linux: please cherry-pick wireguard patches from 5.6 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-03-10 19:10 +0100
    Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-11 00:20 +0100
      Bug#953569:  Ben Hutchings <ben@decadent.org.uk> - 2020-03-11 04:00 +0100
        Bug#953569:  Daniel Kahn Gillmor <dkg@debian.org> - 2020-03-11 04:40 +0100
          Bug#953569:  Ben Hutchings <ben@decadent.org.uk> - 2020-03-11 05:00 +0100
            Bug#953569:  Daniel Kahn Gillmor <dkg@debian.org> - 2020-03-11 06:10 +0100
              Provides: wireguard-modules and transition plan Ben Hutchings <ben@decadent.org.uk> - 2020-04-13 17:10 +0200
                Re: Provides: wireguard-modules and transition plan "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-04-13 21:40 +0200
        Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-11 05:30 +0100
          Bug#953569:  Daniel Kahn Gillmor <dkg@fifthhorseman.net> - 2020-03-11 06:10 +0100
          Bug#953569:  Ben Hutchings <ben@decadent.org.uk> - 2020-03-21 04:30 +0100
            Bug#953569:  Ben Hutchings <ben@decadent.org.uk> - 2020-03-21 05:30 +0100
              Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-21 05:40 +0100
                Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-21 07:10 +0100
                  Bug#953569:  Ben Hutchings <ben@decadent.org.uk> - 2020-03-28 06:20 +0100
                    Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-28 10:40 +0100
        Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-12 02:10 +0100
          Bug#953569:  Ben Hutchings <ben@decadent.org.uk> - 2020-03-12 02:40 +0100
        Bug#953569:  "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-03-21 04:10 +0100
    Bug#953569: marked as done (linux: please cherry-pick wireguard  patches from 5.6) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-03-30 10:20 +0200

Page 1 of 2  [1] 2  Next page →

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#66500 — Processed: linux: please cherry-pick wireguard patches from 5.6

Processing control commands:

> affects -1 src:wireguard-linux-compat src:wireguard
Bug #953569 [src:linux] linux: please cherry-pick wireguard patches from 5.6
Added indication that 953569 affects src:wireguard-linux-compat and src:wireguard

-- 
953569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953569
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#66506 — Bug#953569:

Please coordinate with me for doing this. Actually, if this sounds
interesting to you, I'll backport it myself, along with the missing
crypto/ bits, and send you a git bundle of patches for 5.5.

In other words, just say "yes please", and I'll supply the rest. Then
you can apply this to your tree and add the Provides as dkg asked.

[toc] | [prev] | [next] | [standalone]

#66507 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> Please coordinate with me for doing this. Actually, if this sounds
> interesting to you, I'll backport it myself, along with the missing
> crypto/ bits, and send you a git bundle of patches for 5.5.
> 
> In other words, just say "yes please", and I'll supply the rest.

Either a git bundle or quilt patch series is fine.

> Then you can apply this to your tree and add the Provides as dkg
> asked.

We definitely can't add a Provides on "real" kernel packages, because
this breaks auto-removal of old packages.  We could possibly add it to
the meta-packages, but there would have to be a plan for how we can
drop it later (and have the Wireguard user-space just assume the kernel
supports it).  We definitely shouldn't accumulate Provides for every
component that was previously packaged out-of-tree.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.

[toc] | [prev] | [next] | [standalone]

#66508 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

Thanks to Ben and Jason for following up here.

On Wed 2020-03-11 02:52:43 +0000, Ben Hutchings wrote:
> We definitely can't add a Provides on "real" kernel packages, because
> this breaks auto-removal of old packages.

I'm not sure i understand this.  by "real" kernel packages i think you
mean something like linux-image-5.4.0-4-amd64.

If linux-image-5.5.0-1-amd64 were installed, with such a Provides:, and
then linux-image-5.5.0-2-amd64 were installed, also with such a
Provides:, then why wouldn't autoremoval of linux-image-5.5.0-1-amd64
still work?  The system would still have the Provides: satisfied.

Feel free to point me at some piece of Apt or dpkg documentation if i'm
missing something obvious.

> We could possibly add it to the meta-packages, but there would have to
> be a plan for how we can drop it later (and have the Wireguard
> user-space just assume the kernel supports it).

When we can just assume that the kernel supports it, we might just drop
the "wireguard" package entirely, and supply only the "wireguard-tools"
package (maybe at that point, we make "wireguard-tools" itself Provide:
wireguard).  At that point, we certainly wouldn't need the Provides: on
the kernel.

> We definitely shouldn't accumulate Provides for every component that
> was previously packaged out-of-tree.

I can see how that would be problematic :)

  --dkg

[toc] | [prev] | [next] | [standalone]

#66509 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2020-03-10 at 23:31 -0400, Daniel Kahn Gillmor wrote:
> Thanks to Ben and Jason for following up here.
> 
> On Wed 2020-03-11 02:52:43 +0000, Ben Hutchings wrote:
> > We definitely can't add a Provides on "real" kernel packages, because
> > this breaks auto-removal of old packages.
> 
> I'm not sure i understand this.  by "real" kernel packages i think you
> mean something like linux-image-5.4.0-4-amd64.
> 
> If linux-image-5.5.0-1-amd64 were installed, with such a Provides:, and
> then linux-image-5.5.0-2-amd64 were installed, also with such a
> Provides:, then why wouldn't autoremoval of linux-image-5.5.0-1-amd64
> still work?  The system would still have the Provides: satisfied.
> 
> Feel free to point me at some piece of Apt or dpkg documentation if i'm
> missing something obvious.

I don't know where/if it's explicitly documented, but it would be with
apt if anywhere.

If some of the packages providing a virtual package are explicitly
installed, and some auto-installed, it could reasonably auto-remove the
latter group (though I don't think it does).  But if all of them are
auto-installed, which will be the case for kernel packages, it can't
tell which should be kept and which removed.

> > We could possibly add it to the meta-packages, but there would have to
> > be a plan for how we can drop it later (and have the Wireguard
> > user-space just assume the kernel supports it).
> 
> When we can just assume that the kernel supports it, we might just drop
> the "wireguard" package entirely, and supply only the "wireguard-tools"
> package (maybe at that point, we make "wireguard-tools" itself Provide:
> wireguard).

But nothing will auto-remove the wireguard package.  So you would have
to keep it as a transitional package for one release cycle, even when
it depends on just wireguard-tools.

Yes, this is annoyingly complicated.  That's why I need there to be a
plan.

Ben.

> At that point, we certainly wouldn't need the Provides: on
> the kernel.
> 
> > We definitely shouldn't accumulate Provides for every component that
> > was previously packaged out-of-tree.
> 
> I can see how that would be problematic :)
> 
>   --dkg
-- 
Ben Hutchings
Humour is the best antidote to reality.

[toc] | [prev] | [next] | [standalone]

#66512 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Wed 2020-03-11 03:50:00 +0000, Ben Hutchings wrote:
> If some of the packages providing a virtual package are explicitly
> installed, and some auto-installed, it could reasonably auto-remove the
> latter group (though I don't think it does).  But if all of them are
> auto-installed, which will be the case for kernel packages, it can't
> tell which should be kept and which removed.

hm, right, i can see how that would be a problem.  thanks for the
explanation.

> But nothing will auto-remove the wireguard package.  So you would have
> to keep it as a transitional package for one release cycle, even when
> it depends on just wireguard-tools.

I don't think it would be a problem to have a transitional package for
one release cycle.  do you?

> Yes, this is annoyingly complicated.  That's why I need there to be a
> plan.

I'm open to any suggestions that you think would work better than what
we've talked about so far.  Let me know what you prefer.

      --dkg

[toc] | [prev] | [next] | [standalone]

#66747 — Provides: wireguard-modules and transition plan

[Multipart message — attachments visible in raw view] — view raw

On Wed, 11 Mar 2020 01:05:49 -0400 Daniel Kahn Gillmor <dkg@debian.org> wrote:
> On Wed 2020-03-11 03:50:00 +0000, Ben Hutchings wrote:
> > If some of the packages providing a virtual package are explicitly
> > installed, and some auto-installed, it could reasonably auto-remove the
> > latter group (though I don't think it does).  But if all of them are
> > auto-installed, which will be the case for kernel packages, it can't
> > tell which should be kept and which removed.
> 
> hm, right, i can see how that would be a problem.  thanks for the
> explanation.
> 
> > But nothing will auto-remove the wireguard package.  So you would have
> > to keep it as a transitional package for one release cycle, even when
> > it depends on just wireguard-tools.
> 
> I don't think it would be a problem to have a transitional package for
> one release cycle.  do you?

No, that's not a problem.

> > Yes, this is annoyingly complicated.  That's why I need there to be a
> > plan.
> 
> I'm open to any suggestions that you think would work better than what
> we've talked about so far.  Let me know what you prefer.

I would have preferred you to do the work, but OK.  I think this plan
works:

1. We add "Provides: wireguard-modules" to the kernel meta-packages
   (MR 232).
2. You make the wireguard meta-package depend on wireguard-modules |
   wireguard-dkms (or the other way around).
3. Wait for bullseye release.  Now you can assume the kernel has been
   upgraded.
4. You turn the wireguard meta-package into a transitional package
   depending only on wireguard-tools.
5. Wait for bookworm release.  Now we can assume the meta-package has
   been upgraded.
6. We drop "Provides: wireguard-modules".

(We could also replace the Provides with a versioned Breaks after step
4, but that doesn't allow us to get to the end state any earlier.)

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

[toc] | [prev] | [next] | [standalone]

#66748 — Re: Provides: wireguard-modules and transition plan

On Mon, Apr 13, 2020 at 8:59 AM Ben Hutchings <ben@decadent.org.uk> wrote:
> I would have preferred you to do the work, but OK.

I don't quite know how to Debian, but I'm happy to pitch in where it
makes sense (i.e. that MR).

> I think this plan
> works:
>
> 1. We add "Provides: wireguard-modules" to the kernel meta-packages
>    (MR 232).

This is now done (pending you pressing the merge button).

> 2. You make the wireguard meta-package depend on wireguard-modules |
>    wireguard-dkms (or the other way around).

This is already done.

> 3. Wait for bullseye release.  Now you can assume the kernel has been
>    upgraded.
> 4. You turn the wireguard meta-package into a transitional package
>    depending only on wireguard-tools.

Sounds reasonable.

> 5. Wait for bookworm release.  Now we can assume the meta-package has
>    been upgraded.
> 6. We drop "Provides: wireguard-modules".

Ack.

Jason

[toc] | [prev] | [next] | [standalone]

#66510 — Bug#953569:

On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> > Please coordinate with me for doing this. Actually, if this sounds
> > interesting to you, I'll backport it myself, along with the missing
> > crypto/ bits, and send you a git bundle of patches for 5.5.
> >
> > In other words, just say "yes please", and I'll supply the rest.
>
> Either a git bundle or quilt patch series is fine.

Voila:

https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip

That will apply on top of 5.5.8. Let me know if you have any problems,
and please poke me after this is done so I can test it out.

>
> > Then you can apply this to your tree and add the Provides as dkg
> > asked.
>
> We definitely can't add a Provides on "real" kernel packages, because
> this breaks auto-removal of old packages.  We could possibly add it to
> the meta-packages, but there would have to be a plan for how we can
> drop it later (and have the Wireguard user-space just assume the kernel
> supports it).  We definitely shouldn't accumulate Provides for every
> component that was previously packaged out-of-tree.

There are tricky Debian concerns here I don't totally grok, but what
I'd like to happen is:

- A user is on stock Debian and runs `apt install wireguard`: only
wireguard-tools is pulled in.
- A user is on weird Debian (say, some AWS kernel) and runs `apt
install wireguard`: wireguard-tools and wireguard-dkms are pulled in.

I was under the impression that the "Provides" mechanism does a good
job at that. But perhaps there's another good way you have in mind.

[toc] | [prev] | [next] | [standalone]

#66511 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Tue 2020-03-10 22:23:18 -0600, Jason A. Donenfeld wrote:
> https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip

Thanks, Jason!

> - A user is on stock Debian and runs `apt install wireguard`: only
> wireguard-tools is pulled in.
> - A user is on weird Debian (say, some AWS kernel) and runs `apt
> install wireguard`: wireguard-tools and wireguard-dkms are pulled in.

Are you thinking about kernel 5.5 or kernel 5.6 or later?

if wg is mainlined in 5.6 and the user is on a 5.6 or later kernel, then
i don't think we want wireguard-dkms at all, right?

> I was under the impression that the "Provides" mechanism does a good
> job at that. But perhaps there's another good way you have in mind.

The automatic uninstallation of packages with legacy kernel ABIs is what
Ben has identified as a sticking point for putting a Provides: on the
"real" kernel package.  But it doesn't sound like that's a problem for
the kernel metapackages.

    --dkg

[toc] | [prev] | [next] | [standalone]

#66571 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2020-03-10 at 22:23 -0600, Jason A. Donenfeld wrote:
> On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings <ben@decadent.org.uk> wrote:
> > On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> > > Please coordinate with me for doing this. Actually, if this sounds
> > > interesting to you, I'll backport it myself, along with the missing
> > > crypto/ bits, and send you a git bundle of patches for 5.5.
> > > 
> > > In other words, just say "yes please", and I'll supply the rest.
> > 
> > Either a git bundle or quilt patch series is fine.
> 
> Voila:
> 
> https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip
> 
> That will apply on top of 5.5.8. Let me know if you have any problems,
> and please poke me after this is done so I can test it out.
[...]

I'm looking through this now, and it seems like you've squashed commits
together, e.g. patch #1 combines commits d0e7a2b6d069 and a8e41f6033a0.

We generally prefer to have one patch per upstream commit, with a
reference to that, so that when we rebase on a new upstream it's easy
to see if a patch can be dropped because it's upstream.  (Though in
this case we know we can drop all those patches when moving to 5.6, and
not before.)

But that would also have made it easier to review any backporting
adjustments you've made.  Anyway, I'll continue to look.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

[toc] | [prev] | [next] | [standalone]

#66572 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2020-03-21 at 03:21 +0000, Ben Hutchings wrote:
> On Tue, 2020-03-10 at 22:23 -0600, Jason A. Donenfeld wrote:
> > On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings <ben@decadent.org.uk> wrote:
> > > On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> > > > Please coordinate with me for doing this. Actually, if this sounds
> > > > interesting to you, I'll backport it myself, along with the missing
> > > > crypto/ bits, and send you a git bundle of patches for 5.5.
> > > > 
> > > > In other words, just say "yes please", and I'll supply the rest.
> > > 
> > > Either a git bundle or quilt patch series is fine.
> > 
> > Voila:
> > 
> > https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip
> > 
> > That will apply on top of 5.5.8. Let me know if you have any problems,
> > and please poke me after this is done so I can test it out.
> [...]
> 
> I'm looking through this now, and it seems like you've squashed commits
> together, e.g. patch #1 combines commits d0e7a2b6d069 and a8e41f6033a0.
> 
> We generally prefer to have one patch per upstream commit, with a
> reference to that, so that when we rebase on a new upstream it's easy
> to see if a patch can be dropped because it's upstream.  (Though in
> this case we know we can drop all those patches when moving to 5.6, and
> not before.)
> 
> But that would also have made it easier to review any backporting
> adjustments you've made.  Anyway, I'll continue to look.

I've added patches #1-9, but not #10 "crypto: x86/curve25519 - replace
with formally verified implementation" as it is not in mainlne and
doesn't seem to be in any subsystem tree yet.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

[toc] | [prev] | [next] | [standalone]

#66573 — Bug#953569:

On Fri, Mar 20, 2020 at 10:18 PM Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Sat, 2020-03-21 at 03:21 +0000, Ben Hutchings wrote:
> > On Tue, 2020-03-10 at 22:23 -0600, Jason A. Donenfeld wrote:
> > > On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings <ben@decadent.org.uk> wrote:
> > > > On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> > > > > Please coordinate with me for doing this. Actually, if this sounds
> > > > > interesting to you, I'll backport it myself, along with the missing
> > > > > crypto/ bits, and send you a git bundle of patches for 5.5.
> > > > >
> > > > > In other words, just say "yes please", and I'll supply the rest.
> > > >
> > > > Either a git bundle or quilt patch series is fine.
> > >
> > > Voila:
> > >
> > > https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip
> > >
> > > That will apply on top of 5.5.8. Let me know if you have any problems,
> > > and please poke me after this is done so I can test it out.
> > [...]
> >
> > I'm looking through this now, and it seems like you've squashed commits
> > together, e.g. patch #1 combines commits d0e7a2b6d069 and a8e41f6033a0.
> >
> > We generally prefer to have one patch per upstream commit, with a
> > reference to that, so that when we rebase on a new upstream it's easy
> > to see if a patch can be dropped because it's upstream.  (Though in
> > this case we know we can drop all those patches when moving to 5.6, and
> > not before.)
> >
> > But that would also have made it easier to review any backporting
> > adjustments you've made.  Anyway, I'll continue to look.
>
> I've added patches #1-9, but not #10 "crypto: x86/curve25519 - replace
> with formally verified implementation" as it is not in mainlne and
> doesn't seem to be in any subsystem tree yet.

No, it's in Herbert's cryptodev-2.6.git tree.

https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=07b586fe06625b0b610dc3d3a969c51913d143d4
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=dc7fc3a53ae158263196b1892b672aedf67796c5

[toc] | [prev] | [next] | [standalone]

#66575 — Bug#953569:

Hi again,

It looks like you didn't actually take these patches from the updated
tree I sent you, but rather used the outdated .zip I had posted prior.
Please try again using the tree I linked earlier:

https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y

Thanks,
Jason

[toc] | [prev] | [next] | [standalone]

#66614 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2020-03-21 at 00:01 -0600, Jason A. Donenfeld wrote:
> Hi again,
> 
> It looks like you didn't actually take these patches from the updated
> tree I sent you, but rather used the outdated .zip I had posted prior.
> Please try again using the tree I linked earlier:
> 
> https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y

I've applied all the changes from there.  I should be uploading an
updated Debian package over the weekend.  Thanks for your patience.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

[toc] | [prev] | [next] | [standalone]

#66615 — Bug#953569:

Thanks! Looks good to me. I appreciate that you were able to
reconstruct the original upstream commits for each of these.

(WireGuard has a capital G btw.)

[toc] | [prev] | [next] | [standalone]

#66515 — Bug#953569:

By the way, do you want a patch series for 5.4 too? I can provide that as well.

[toc] | [prev] | [next] | [standalone]

#66516 — Bug#953569:

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2020-03-11 at 19:04 -0600, Jason A. Donenfeld wrote:
> By the way, do you want a patch series for 5.4 too? I can provide
> that as well.

Thanks, but I don't anticipate there being any further 5.4-based kernel
packages in Debian.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

[toc] | [prev] | [next] | [standalone]

#66570 — Bug#953569:

Hi Ben,

I continue to maintain and keep up to date the 5.5.y backport for
WireGuard for you. I don't know when you intend on merging this --
after 5.6 drops, I assume -- but I've updated the patches and I'm now
holding them in the wireguard-linux repo:

https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y

So, whenever you're ready, you can just grab whatever is the latest in
that branch.

Jason

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web