I would suggest using C.UTF-8 here.

Makes sense, I've added en_US there because of proposed default in https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html

rebased

Requires: python2-cheetah

This breaks on rhel6/7. Does python2-cheetah in Fedora provide python-cheetah? If so, we could leave the req alone here, if not, we'll need more %if lines.

%package -n python2-%{name}-web

I'm slightly concerned about renaming the -web subpackage without providing the old name.

Is there a reason we can't just build the hub only as Python 3 when it's possible?

new commit should solve both issues

Why are we building both?! We should just have non-API components build one way or the other.

Good point, but don't we force users (e.g. in older Fedora) to have py3 mod_wsgi even if they've other apps which requires py2? mod_wsgi_python3 can't run in save httpd as mod_wsgi.

Good point, but don't we force users (e.g. in older Fedora) to have py3 mod_wsgi even if they've other apps which require py2? mod_wsgi_python3 can't run in save httpd as mod_wsgi.

My suggestion is to just switch to Python 3 for Fedora 29+. There's an ongoing mass removal for Python 2 packages anyway.

Rebased and retested, still works correctly.

I'm concerned about the upgrade path here. The koji-web rpm is renamed to python2-koji-web. The macro seems to automatically provide python-koji-web, but not koji-web. Nothing tells rpm that this package should replace the old koji-web.

Is there a reason we should provide both in this case? It's a web interface application. It'd probably be better to just change it to use Python 3 for fedora, and keep Python 2 for RHEL 6/7.

The code changes themselves generally look ok

Is there a reason we should provide both in this case? It's a web interface application. It'd probably be better to just change it to use Python 3 for fedora, and keep Python 2 for RHEL 6/7.

An interesting point. You could almost make the same argument for the hub.

Part of the concern is simple caution. Providing both allows a fallback option, and more flexibility for instances to time their transition.

Is there a reason we should provide both in this case? It's a web interface application. It'd probably be better to just change it to use Python 3 for fedora, and keep Python 2 for RHEL 6/7.

An interesting point. You could almost make the same argument for the hub.
Part of the concern is simple caution. Providing both allows a fallback option, and more flexibility for instances to time their transition.

I don't think the concern is warranted. Moreover, we're not going to have much choice soon for Fedora and Mageia (and RHEL 8) anyway. The extra complexity is just not worth it, and to some extent, making it a switch that's activated for everything except RHEL < 8 will help force us make the Python 3 support better.

Similar to #921, the spec changes aren't quite where I want them, but I'll create a follow up to address that.

Merging this with a manual rebase (a few spec adjustments to account for the changes in 921)

Commit d54063d6 fixes this pull-request