Hi Alexander, Thanks for working on this. Packaging comments below.
On Wed, Mar 19, 2025 at 09:01:08PM +0100, Alexander Sulfrian wrote: > * Package name : wireguard-initramfs > Version : 2025.03.02-1 > Upstream contact : Robert Pufky <rpu...@gmail.com> > * URL : https://github.com/r-pufky/wireguard-initramfs > * License : unlicense > * Vcs : https://salsa.debian.org/animux/wireguard-initramfs If contributors.d.o isn't lying to me you're new to Debian. Are you familiar with the whole team vs. individual maintainer question? By setting yourself (as opposed to a team ML) as Maintainer *and* putting the repo outside of a team namespace you're asking everyone to keep their hands off the package without going through you (or following the NMU or ITS processess). That may not be your intent. I'd prefer to place this in debian/ for collaborative maintainance. If you agree I can move the repo. See https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group d/gbp.conf: [DEFAULT] pristine-tar = True upstream-branch = upstream master-branch = master You're re-stating the upstream-branch default, please remove that line. Also the `master-branch=` key doesn't exist AFAIK. You're probably thinking of `debian-branch=`. The recommended git layout these days is https://dep-team.pages.debian.net/deps/dep14/ unless there's an overriding reason not to follow it. In this case that would mean `debian-branch=debian/latest`. About the the DATETIME_URL=google.com default. I would guess there's a reason upstream has this. Wireguard doesn't work at all if the system time is off by a lot, so on systems without a reliable RTC clock (like RPi) it's just not going to work. The classical solution to that is to use an NTP client of which we have several in Debian: ntpsec, chrony, ntp-rs, (classic) ntp and systemd-timesyncd. Could you see if any of those can operate in an initrd context or be made to in order to support our use-case here. What we'd want is a one-shot client we can run and then be sure time is at least correct-ish. Ofc. the question the becomes, is it a good thing that we get time from an untrusted source? As a mitigation we could only trigger time sync when boot time is off by a lot compared to the system's last valid time. I'm not yet sure where to get the latter from but there's a number of options we could look at. Using a HTTP service, while a very modern thing to do, isn't the right solution here IMO. Why do you set SALSA_CI_DISABLE_AUTOPKGTEST=1 in d/salsa-ci.yml when there are no autopkgtests in debian/test? I think it would actually be great to have some testing here since pre-boot is such a tricky environment. I've never had to test this with autopkgtest but I do believe it supports it by rebooting see "Reboot during a test" https://people.debian.org/~eriberto/README.package-tests.html. Setting up a "remote" wireguard peer is going to be the biggest challange, but even that can be done relatively easily with ip-netns and perhaps unshare -u to control the time of the other peer if we want to test time sync. --Daniel
signature.asc
Description: PGP signature
