Dear EPEL maintainers,

Any plan to bring uwsgi back for RHEL/CentOS 8?

I had a go at building this as we have a use for uwsgi in CentOS 8. It needed gloox which also isn't in epel 8 yet, though fortunately the fc31 package srpm rebuilt cleanly. After trying several --with --without and --define build options I did get to build starting from the fc31 srpm with a single edit to the spec file due to the different versioning on python36-devel and python3-greenlet-devel, so it shouldn't be too difficult to do given suitable epel8 settings. Note however that I haven't tested any of the packages I built yet.

So python-greenlet is part of RHEL 8 in CodeReady Builder and CentOS 8 in PowerTools, so no backport of that is needed.

gloox, on the other hand, is needed in EPEL 8, but should be trivial to build.

(In reply to Neal Gompa from comment #3)
> So python-greenlet is part of RHEL 8 in CodeReady Builder and CentOS 8 in
> PowerTools, so no backport of that is needed.
> 
> gloox, on the other hand, is needed in EPEL 8, but should be trivial to
> build.

Yes, gloox built cleanly for me from the Fedora 31 source rpm. My cleaned up final build sequence was
mock --rebuild gloox-1.0.14-10.fc31.src.rpm -r epel-8-x86_64
mock --rebuild /tmp/uwsgi-2.0.18-1.fc31.src.rpm -r uwsgitemp --without tcp_wrappers --define="with_python3 1" --define="with_mod_proxy_uwsgi 1"  --define="with_systemd 1" --define="__python2 /usr/bin/python3"
where the uwsgitemp mock configuration file added a local repository containing the gloox packages to the standard epel 8 configuration.

Please build for EPEL 8, or is there an alternative to uwsgi/nginx for Django apps on RHEL/CentOS 8.

thanks.

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

This seems to building for F32 and F33, any update on building for EPEL8?

https://src.fedoraproject.org/rpms/uwsgi

I have requested an epel8 branch and started work on this (finally!)

I don't think the current package is suitable for EPEL-8

Various plugins for language stacks have to use modules.

If you build with current builder configuration (which is IMHO totally broken), you will use the default stream, so only this one will work

Ex, for PHP, you have 7.2 (since 8.0, default for now), 7.3 (since 8.1), and probably soon 7.4, 8.0, ...

Sorry, but I don't see any easy way to manage this

1/ create a "uwsgi" module

with buildtime and runtime dependency on the other modules

but this will create a big build matrix (number of each module stream, 2 php * 2 perl ...)

2/ split the package

one package for each plugin

Then each plugin can be built in a module extending the official one

Ex: for PHP there is a plan to have a "php-extras" module with additionnal packages to extend the "php" module



but nothing is supported by EPEL infrastructure for now
See
https://pagure.io/epel/issue/75
https://pagure.io/fedora-infrastructure/issue/8690


But perhaps nobody really cares (>1 year and still nothing happen), and having a single version supported is enough :s



P.S. splitted plugins is the solution used in some 3rd party repository to provides the plugin for alternative language versions,
ex, here is the spec file I use to build the php plugin
https://git.remirepo.net/cgit/rpms/uwsgi/uwsgi-plugin-php.git/plain/uwsgi-plugin-php.spec

Just for comparison, Debian/Ubuntu seem to split the packages out:

https://packages.debian.org/search?keywords=uwsgi-plugin

I may have misunderstood, but it appears there is already a split-up build of uwsgi for el8 as part of OpenStack:

https://cbs.centos.org/koji/buildinfo?buildID=28261

Debian/Ubuntu do split some packages (they didn't back when I originally packaged for fedora and looked at previous art) but this isn't going to be pretty here. I think having a single supported version is "OK" or at least the least worst outcome. The source code is shipped so in theory people can build their plugins with whatever versions they have available.
A coupld of new releases came out in rapid succession, I am working on getting to the latest and hit epel8 there as well.

> it appears there is already a split-up build of uwsgi for el8 as part of OpenStack

Alas, no uwsgi-plugin-python3 there, and uwsgi-plugin-python needs python 2... :(

It seems GetPageSpeed has viable RPMs for RHEL/CentOS 8 (https://centos.pkgs.org/8/getpagespeed-x86_64/uwsgi-2.0.17.1-2.el8.x86_64.rpm.html), and the changelog has a good number of @rehat.com adresses ... Not having uWSGI for deploying Django applications is not a total showstopper but a good incentive to stay at 7.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Closing as the package was retired.