[GF-Users] postfix-tlspol: Upstream updated to 1.11.0

Mon Jul 13 22:32:35 MST 2026

Peter. Thanks for looking into this. I responded below, but I trust whichever way you want to go. Mike

-----Original Message-----
From: users-bounces at lists.ghettoforge.net <users-bounces at lists.ghettoforge.net> On Behalf Of Peter
Sent: Monday, July 13, 2026 10:07 PM
To: users at lists.ghettoforge.net
Subject: Re: [GF-Users] postfix-tlspol: Upstream updated to 1.11.0

On 13/07/2026 20:57, Michael Webb wrote:
> Hi Peter
> 
> postfix-tlspol 1.11.0 is now available for building when convenient.

Thanks I'll try to get to that soon.

> I have modified some of the macros from the spec file extracted from 
> the previous GF release.
> 
>   * Compiler reported that patch syntax has changed. %Patch1 needs to be
>     replaced with %Patch -P 1

Right, the patch syntax is deprecated for future versions of EL.  EL10 continues to support the old syntax with a warning.  I believe that EL8 (and possibly 9) do not support the newer syntax, so at the moment it's easiest to continue to use the old syntax until EL11 drops, when that happens I'll need to put in some version-specific branching to support both old and new syntax on appropriate releases. ******** Understood - Good points, or we can just make release conditional macro so that we are ready for the change ******

>   * I really think going forward we should be compiling with the same
>     version of GO used/specified by the upstream so need to change to
>     “export GOTOOLCHAIN=auto” otherwise package is compiled with the GO
>     version shipped with the linux distro.

As previously discussed, this puts a dependency on a downloadable toolchain that can change at a moments notice.  It violates the principle of reproducible builds and Fedora specifically changes the default for this to local because of this.  If there's a compelling reason to change it to auto (such as actual breakage that occurs with the local toolchain) then I'll revisit this.

***************************************************************************************************************************************************
I do understand and can accept. To clarify the upstream stipulates a specific Go release embedded in their build script. They do not specify "latest", so I think the builds may still qualify as being reproducible.

My feeling is that it could go the other way when one day the upstream depends on a feature that is only available in a later revision. I thought that a big part of GF value is to shorten the cycle of trustworthy packages to end-users. In this case we are talking about a dependency (GO) that has a sponsor that is picky on quality and has enormous resources to test before release that has a higher chance of having security flaws that need patching (that we are proposing to allow to lag 1 year behind), compared to the package that depends on it that is arguably less rigorously tested and has few vulnerabilities (that only lags by 1-2 weeks). To me it is better to opportunistically build with upstream specified until we can't.
***************************************************************************************************************************************************

>   * My mistake from early attempts – apparently not good practice to
>     include wildcards in %files and have removed them

I've used wildcards in %files before, but I agree it's better to name files explicitly.  The advantages of naming explicit files is your build breaks when the files change and you get a chance to review it and understand the differences and what effect it has on your package instead of just slurping in the changes without review.  The downsides is that sometimes the file list can grow quite long and create a significant amount of work to maintain.  At the end of the day I dont' 
really have a huge preference and I might change my approach on a case-by-case basis.

> Please also use the updated .patch and README.gf files in my folders below.
> 
> The new README.gf fixes a stale reference to non-existent “GUIDE.gf”,

Updated, thanks.

> The new patch adds a clarification to help users how to read upstream 
> md file format.

I'm thinking it might be better to compile the markdown to a standard text file, then no special reader will be necessary.  I'll do that and update the patch accordingly.

**********************************************************************************************************************************************************
I did spend a few hours on this to convert md, but it started to look and feel terrible - when really, all a user has to do is visit the upstream website to get the same information in a more presentable format and when glow already works very well in putty.

I tried running pandoc with only limited success, and finished using the regexp with philosophy below which worked very well: 

First copy SourcePath/README.md to BuildPath/README.md.orig, then
cat SourcePath/README.md | \
  sed -E '/\!\[/d; /<img/d; /<br/d; /<details>/d; /<\/details>/d; /<summary>/d; /<\/summary>/d' | \
  sed -E 's/\[([^]]+)\]\(([^)]+)\)/\1 (\2)/g; s/<[^>]*>//g; s/\\_/_/g; s/`//g; s/^#+[[:space:]]*//g' \
  > "BuildPath/README.md"
********************************************************************************************************************************************************

Peter

> No problems to report compiling EL8,9,10 for both x86_64 and aarch on 
> Rocky 10 using viniciusferrao/qemu-user-static for aarch.
> 
> The rpms are running correctly on EL9 and 10 production servers.
> 
> My source and result files are at the link below (hit browser refresh 
> if you get an error)
> 
> https://www.integrilog.com/adhj5jkuuk2sfsf0/postfix-tlspol/
> Custom%201.11.0/0/ 
> <https://www.integrilog.com/adhj5jkuuk2sfsf0/postfix-
> tlspol/Custom%201.11.0/0/>
> 
> Upstream source
> 
> https://github.com/Zuplu/postfix-tlspol/releases <https://github.com/ 
> Zuplu/postfix-tlspol/releases>
> 
> Mike
> 
> 
> _______________________________________________
> users mailing list
> users at lists.ghettoforge.net
> http://lists.ghettoforge.net/mailman/listinfo/users

_______________________________________________
users mailing list
users at lists.ghettoforge.net
http://lists.ghettoforge.net/mailman/listinfo/users