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 <rpufky@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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmfdk90ACgkQ05SBrh55 rPfBthAAsQIkC8/JVob39r+0dExfwF+R/oWBsuJ5UhiptHDk59TX/W9ISrtqwEqa z/rytawUI23HQrBSaBKQuMQDxh6nrGMgKLqrHAt7AMDYgc1TsgdniXo4GoUOwGrP H+MWMvQCxucdXRbhT3qP4+EP3N3TX9ydMeBSc6mIpCmYwt1becO/t54wAXCWslsV nD8VR3uYYWO+YMEtKASzisJXkdaEFlN2EUsVfrEXNWYrOnmHaazxfaosk8STkVaU 3KUbVjBXZjKxAjl/hmd2i8IiPbvaP/YU7znn+UV5yU4jZ7Qx7w6/HNC0nUjXA3OH 9KR/N4Uvf+0Ym6JC61pavihd00NMPGG7Sb0AxtmJtRNVQLPDlwKcfaiW6OT7pHCb g6sA4M+ex2oJBs5GXIyDK5JOTQ60OnBK4do4CdLW9zDRRL1ERNgGJs1UPZnLuR8d yTHM6q87uL1cth1C/7P3qBdAbtZ3HTJiC0tSrxJl1bwypZKppTMgqhicHJSPb5td 7bFt8jJMMrAdDIQ0GdThGkEbWANcAwamQXmqppdfMoWAw1U3Yhwbp1rT9LiiUd7V gpfrKIRT3glgjxTGfaF9k713M9xmvBDlU/1Jy9pohgnf4IbPLBTLmhup51j5bDjD Gkcj36sXrhpzOzeJh8mKVUfPP6gb9dVJ3r8dONCneUVN4XoUjJs=
=RHT3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)