Re: Provides: wireguard-modules and transition plan
On Mon, Apr 13, 2020 at 8:59 AM Ben Hutchings 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
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.)
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
Bug#953569:
On Fri, Mar 20, 2020 at 10:18 PM Ben Hutchings wrote: > > On Sat, 2020-03-21 at 03:21 +, 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 > > > 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
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
Bug#953569:
By the way, do you want a patch series for 5.4 too? I can provide that as well.
Bug#953569:
On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings 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.
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.
