2) Is there a quick tutorial on pulling in new releases from upstream? One complication is, my upstream (on GitHub) had it’s history re-written to change my email address. Is that possible on salsa? Not recommended?
Ugh. This might be problematic. Not sure. You’ll see? :)
Sounds ominous, ok. :)
3) I’d like to build with the standard Go compiler instead of gccgo. I currently have this in Build-Depends in the control file:
Build-Depends: debhelper (>= 11),
dh-golang,
golang-any,
…
Should I just replace golang-any with golang-go, or is it preferred that we actually support gccgo?
What’s your motivation to do so? Definitely leave a comment if you go that route. Also, note that this will mean that your package will be available on fewer architectures (some are supported by gccgo, but not by gc).
The irtt server that’s compiled with gccgo (amd64) can exit for no reason, and it doesn’t leave a log message, but there's no code path by which that should even be possible. It's easier to switch to a compiler I know than try to track it down. It can take a few days to reproduce. :)
Gotcha. Just put that into a comment and go with gc for the time being, then.
4) Last question, do you have an opinion on if to enable the irtt server by default at installation? There is no known security risk to doing so. The server has a three-way handshake to prevent reflection/amplification attacks, and some reasonable default restrictions. netperf, for example, enables netserver by default at startup. I guess I would prefer it...
If there are separate client/server packages, I think it’s reasonable to enable the server when the user installed the server package. If no, I’d default to being careful.
I’m not sure if Debian has converged on a clear policy on this, but I do know that it has been discussed at length, repeatedly, over many years.
By the way, just had a look at what irtt is, and it seems pretty cool! Will give it a shot when I get a chance.