Bug 1757157 - uwsgi in epel 8
Summary: uwsgi in epel 8
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: uwsgi
Version: epel8
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jorge Gallegos
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-09-30 17:25 UTC by Jonathan D.
Modified: 2020-11-20 08:07 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Jonathan D. 2019-09-30 17:25:53 UTC
Hi - hoping we could get uwsgi packaged for epel 8.  Please let me know if you need more information, if nobody is slated to maintain this in epel 8, or if I could contribute somehow.  


Comment 1 Zhang Huangbin 2019-10-27 10:52:06 UTC
Dear EPEL maintainers,

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

Comment 2 Michael Young 2020-01-22 00:43:58 UTC
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.

Comment 3 Neal Gompa 2020-02-23 16:26:14 UTC
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.

Comment 4 Michael Young 2020-02-23 16:52:42 UTC
(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.

Comment 5 Thomas Stephen Lee 2020-04-01 05:42:24 UTC
Please build for EPEL 8, or is there an alternative to uwsgi/nginx for Django apps on RHEL/CentOS 8.


Comment 6 Fedora Admin XMLRPC Client 2020-04-06 19:34:12 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 7 Marcus Furlong 2020-05-06 17:28:57 UTC
This seems to building for F32 and F33, any update on building for EPEL8?


Comment 8 Jorge Gallegos 2020-05-14 15:30:50 UTC
I have requested an epel8 branch and started work on this (finally!)

Comment 9 Remi Collet 2020-05-15 07:44:37 UTC
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

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

Comment 10 Marcus Furlong 2020-05-15 13:49:17 UTC
Just for comparison, Debian/Ubuntu seem to split the packages out:


Comment 11 Rufo Al 2020-06-14 22:46:14 UTC
I may have misunderstood, but it appears there is already a split-up build of uwsgi for el8 as part of OpenStack:


Comment 12 Jorge Gallegos 2020-06-17 15:51:29 UTC
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.

Comment 13 Richard Hughes 2020-06-23 19:50:35 UTC
> 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... :(

Comment 14 Victoriano Giralt 2020-10-18 23:21:45 UTC
It seems GetPageSpeed has viable RPMs for RHEL/CentOS 8 (https://centos.pkgs.org/8/getpagespeed-x86_64/uwsgi-, 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.

Note You need to log in before you can comment on or make changes to this bug.