Using Github Actions to distribute releases

[polarathene]

This is something I've seen some projects doing.

Often with a portable (statically linked with musl?) binary when viable (rust, go, or languages with minimal dependencies like Python projects, fail2ban at least does this), along with a .deb / .rpm package.

I'm not sure how much work that is for postsrsd and I personally don't have experience with packaging releases like that. So totally understandable if this request is out of scope 👍

---

Main motivation was that it seems Debian's next release (Bookworm) later this year will remain on postsrsd 1.10, and that also appears to be the same version in their testing + unstable repos presently.

Meanwhile other distros often have at least 1.12, and some (Alpine Edge, OpenSUSE TumbleWeed) are providing 2.x. So it's mostly a Debian issue.

One alternative (since it would be used in a Docker project) would be to build postsrsd ourselves with Docker I guess 😅

[roehling]

I'm not making any promises, but I added some support to build and link PostSRSd with musl. It seems to work okay except for the milter support, because the Sendmail libMilter library is unhappy without some OS-specific headers such as <linux/version.h>.

[polarathene]

No pressure :)

---

I'm not too familiar with the build issue, are the headers only required during the build or does it matter where the binary is run?

In Docker for example the kernel is used from the host, not part of the image, so I imagine software running in the container can't depend on a specific kernel (but a minimum kernel version requirement could be fine).

---

I recall musl can have a few gotchas vs glibc. I also recall the close_range() call that you added for 1.12 wasn't supported by musl around 6 months ago, I'm not sure if it's been added since.

I'm also trying to work with Docker upstream to prevent that problem (their default docker.service config for systemd sets LimitNOFILE=infinity, which raises the default soft limit well above 1024, sometimes up to 2^30).

[oxan]

Main motivation was that it seems Debian's next release (Bookworm) later this year will remain on postsrsd 1.10, and that also appears to be the same version in their testing + unstable repos presently.

Note that it's effectively 1.11, as the only actual code change in 1.11 has been backported to the 1.10 package in Debian. None of the changes in 1.12 should be relevant on Debian either.

But yeah, I haven't gotten around to packaging 2.x for Debian yet. Part of the issue is that I no longer administer any mailservers, so I'd be happy if someone else could take over package maintenance.

[polarathene]

None of the changes in 1.12 should be relevant on Debian either.

It's relevant to Docker containers. 1.12 fixes a bug on hosts where fs.nr_open is a value of 2^30 instead of the default 2^20 (Debian opts-out of this change introduced from systemd v240 due to quirks with how Debian patches PAM IIRC).

On affected hosts, dockerd + containerd set the soft limit to infinity which maps to fs.nr_open, and that causes some software to stall heavily (8 minutes for PostSRSd) when starting up. This is partly an issue with those container packages shipping bad config which makes the issue so much more worse.

---

Unrelated to that, Debian also packages Postfix with some post-install script that doesn't play well when building containers, so we had to work around it by messing with the hostname binary.

---

I haven't gotten around to packaging 2.x for Debian yet. Part of the issue is that I no longer administer any mailservers, so I'd be happy if someone else could take over package maintenance.

No worries, I understand! :)

Thanks for all the effort thus far! 😀

[mtwango]

I've created merge request at Debian repository to package 2.x (https://salsa.debian.org/debian/postsrsd/-/merge_requests/3) and notified maintainers (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017361).

It's still missing some stuff (ie migration path from 1.x) and I'm not confident about init file, but I hope it can set some baseline from which it can be taken forward to packaging 2.x.