I suppose AppStream is an appropriate target here for RHEL 9, considering that it is also in RHEL 8 AppStream. If this is not supposed to be shipped, please consider allowing us to ship this package in EPEL 9 at least (currently, the component is blocked against Fedora EPEL distro).
python-sqlalchemy is not part of the RHEL 9 content set and is not built for RHEL 9. You are free to request adding it to EPEL 9.
I wanted to fill this against python-sqlalchemy originally, but it can not be done :-/ Then I realized this is ex-RHEL (modular) package. That's why I ended up here. Thank you for the quick response! Perhaps the component is just blocked for EPEL 9, somewhere? In BZ? Anyway, moving against Fedora product, so the bug at least finds the actual SQAlchemy Fedora maintainers.
I've naively requested the `epel9` branch to be created. Let's see how far we get.
Cool, thank you!
Creating the branch worked, but building the package failed. The reason is because python3-greenlet and python3-pytest-xdist are missing from EL9. The latter is kinda optional (the package could be built without, but tests wouldn't be executed in parallel and the test suite is looong), but greenlets are needed for the asyncio extension which I don't want to build without: #2046450
python3-greenlet should be in crb...
Ah, I didn't pay attention to the exact output, sorry. It requires "python3-greenlet >= 1.0" and we only seem to have 0.4.7 in EL9, whom can we contact to get this upgraded? Version 1.0 has been available since Jan 2021.
maybe that part can be adjusted because SQLAlchemy itself works with all versions of greenlet, with the exception of the specific greenlet version 0.4.17. works with older ones like 0.4.7 too.
With minor modifications, 1.3.24 from the f34 branch builds successfully for epel9. Would that version be acceptable?
(In reply to Michael Bayer from comment #8) > maybe that part can be adjusted because SQLAlchemy itself works with all > versions of greenlet, with the exception of the specific greenlet version > 0.4.17. works with older ones like 0.4.7 too. Heh, I wonder why I put in >= 1.0 as a BR then when going from 1.3 to 1.4. (In reply to Carl George 🤠 from comment #9) > With minor modifications, 1.3.24 from the f34 branch builds successfully for > epel9. Would that version be acceptable? Hmm, version 1.3.x hasn't received any updates in a long while, which I'd rather not. Per Mike's comment, SQLAlchemy should work with the version of greenlet in EL9, so going back to the previous version shouldn't be necessary.
Ugh, looks like I typoed above and EL9 has the exact offending version of python3-greenlet, 0.4.17. :( Which brings me back to my previous question, i.e. whom to contact to get it bumped to a current version. I imagine there's probably something wrong with it otherwise SQLAlchemy would work with it, right? @
/cc Kevin, can you help me out here? I.e. whom to contact about the version of python-greenlet in EL9.
File a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%209 on python-greenlet and choose CentOS-Stream as the version? Alternately/in addition, you could create a MR to update it at https://gitlab.com/redhat/centos-stream/rpms/python-greenlet I looked upstream and I couldn't really tell why that version was avoided. ;(
Same here, I git-blamed setup.cfg (where the greenlet != 0.4.17 is encoded) and didn't find anything to shed light on what problems that specific version of greenlet has.
0.4.17 "works" in every way except for the way they manage Python contextvars, so an application that uses the contextvars feature of Python std lib might have problems, the discussion is here: https://github.com/python-greenlet/greenlet/issues/196 . I think there's a test in the SQLAlchemy suite that tests the issue here also (at least im sort of assuming there is as the folks were very involved with this when it came out)
Thanks for the info!
We discussed python-greenlet yesterday. We are likely to remove this from CentOS Stream 9 and RHEL 9 entirely, which would allow someone to package/rebase it to a newer version in EPEL.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
sqlalchemy-1.3.24 is pretty old at this point and I've been targeting 1.4.x for my applications.
Yeah, I plan to bring the current 1.4 version into EPEL9.
FEDORA-EPEL-2022-dab04ba712 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-dab04ba712
FEDORA-EPEL-2022-dab04ba712 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-dab04ba712 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-dab04ba712 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.