Please do a new release for Python 3.11 compat

[MartinHusemann]

Python 3.11 is becoming the standard version in various package systems and no released version of mod_python works with it (while the issues seem to be already fixed).

Can you please do a new release?

[grisha]

@MartinHusemann for the past 10 years our official policy has been that there are no more releases as such, what is on master basically is the latest release.

[gdt]

As a packager, I ask that you reconsider. From a packaging system viewpoint, no releases looks like "upstream is not functional", and this conclusion was indeed offered as an opinion on a pkgsrc list. Likely primarily because of no releases, pkgsrc still has 3.5.0. Please have a look at

https://repology.org/project/apmod:python/versions

which shows that most GNU/Linux distributions and other packaging systems are out of date relative to git master. Debian until recently had 3.5.0 and how has git from 2021, but that seems to be the best case.

It doesn't need to be a release; a tag is fine. That is simply a statement that upstream thinks that particular commit is stable. Release/tags like 3.6.20230815 are fine, to unwind semantics from them other than "this commit is ok and it's the most recent one that has been blessed".

Also, the README does not explain the lack of releases, so someone looking at github is lead to incorrect conclusions.

[grisha]

@gdt this sounds reasonable - let me think on it for a couple of days

[grisha]

I created a 3.5.0.1 tag and adjusted the README and NEWS. LMK if more needs to be done?

[gdt]

That looks good. I will try to get pkgsrc updated to the new version over the next with any luck less than a week, and if all goes as smoothly as I expect, Martin or I will ask you to close the ticket. Thank you very much for doing this.

It will also be interesting to see repology pick this up and I suspect it will cause a lot of packaging systems and distributions to update.

[gdt]

pkgsrc updated. The only wrinkle was that the body of the release has version at 3.5.0, and thus the egg name is 3.5.0, not the usual $VERSION. But that was easy to deal with.

We are carrying two patches, both longstanding and off topic here:

• add in -R in addition to -L in configure.ac (generally an issue in the python world)
• don't run git at build time to compute a version (it's not a declared dependency and we want the same result always)

We have this marked as not safe for -j builds and I just confirmed that this broke when I tried it. Docs say to run make without -j, quietly by omission, so only sort of a bug :-)

Happy to file bugs if useful, and I totally understand if these are below the line of what you want to deal with. Surely everybody who cares has dealt by now.

[grisha]

@gdt thank you for your efforts! Might you have a link to the aforementioned patches?

[gdt]

Only if you promise not to laugh about CVS.

• http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/www/ap2-python/?only_with_tag=MAIN
• http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/ap2-python/patches/patch-configure.in?rev=1.1&content-type=text/plain&only_with_tag=MAIN
• http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/ap2-python/patches/patch-dist_version.sh?rev=1.2&content-type=text/plain&only_with_tag=MAIN

The configure patch is really hacky, modifying flags in a way that is only safe because they were just set to one thing. The basic issue is that you need -R (or -Wl,-R or -Wl,-rpath) to link the module so it can find python. This is probably avoided on most GNU/Linux because everything is --prefix=/usr, but in general it doesn't work. The situation is compounded by python's config script not dealing with -R like it should.

[grisha]

Lol, for the life of me cannot remember whether mod_python was in CVS at some point... It must have 'cause mp predates SVN?

Okay, closing this for now. Thank you all!