Patches/updates for building with python3 on 12.0+

[dhomeier]

Various packages tested on 12.6.1 and mostly also on 13.1, for backward compatibility on 10.14.

edit to add list of packages in this PR and their status:

• ca-certificates c30ffce
• doxygen doxygen: tries using /usr/bin/python2.7 #980
• glib2-shlibs ad5b783
• gtk-doc a902518
• itstool @dmacks (uses fink-python along with libxml2-py) ee28ebe
• libraqm0-shlibs @nieder 6b58a7b
• libxml2-py @dmacks libxml2-py310 won't build #1077
• qt5-qtwebengine @nieder
• scons 9d64fb9
• zziplib 9568691

[TheSin-]

you should be breaking this up so maintainers can approve their own. There are too many here for me to test, I'll cherry pick the ca-certs change later today.

[dhomeier]

Thanks; not sure how many maintainers have 12.x or 13.1 to test on (in fact most of the other packages have None or the Gnome Team). 8ea266b has the rather straightforward changes.

[dhomeier]

Note that zziplib here uses the upstream update rather than the patch from 9568691.

[nieder]

zziplib decreased compatibility_version when they switched from autotools to cmake. This is a no-go because anything linking it will break if we update zziplib.

gdraheim/zziplib#130

[dmacks]

itstool doesn't just need a defined python interp at runtime, but it also needs to have libxml2-pyXX to match it, so we have to use fink's python interp (as the package already does). No objection to bumping it to use python310 instead of python27, but that seems a separate issue from trying to cope with /usr/bin/python version-changes.

Note that changing a Depends always requires changing %r.

[dhomeier]

itstool doesn't just need a defined python interp at runtime, but it also needs to have libxml2-pyXX to match it, so we have to use fink's python interp (as the package already does). No objection to bumping it to use python310 instead of python27, but that seems a separate issue from trying to cope with /usr/bin/python version-changes.

Note that changing a Depends always requires changing %r.

I agree both that %r should have been updated, and it does not really belong with the systempython updates; I had only included it here as I was unable to build python27 on arm64. As @TheSin- has been successful with that and seems close to open a PR closing #956, we could also just keep it as is for now (although generally I'd vote for using a still supported Python version).

[cooljeanius]

"gnu++99" isn't an actual standard; typo for "gnu++98"?

[cooljeanius]

Suggested change

	SetCXXFLAGS: -std=gnu++99
	SetCXXFLAGS: -std=gnu++98

[dhomeier]

Probably confused with c99/gnu99

[cooljeanius]

Probably confused with c99/gnu99

yeah that's what I was guessing