Bug 2095660

If only rebranching & rebuilding did it…

I went down the list of direct (bravado) and indirect dependencies of fasjson-client manually here on F-36 (so the list could be incomplete if I made a mistake) and these are missing from CS9+EPEL9/next:

root@cs9:~> dnf repolist
repo id                        repo name
appstream                      CentOS Stream 9 - AppStream
baseos                         CentOS Stream 9 - BaseOS
crb                            CentOS Stream 9 - CRB
epel                           Extra Packages for Enterprise Linux 9 - x86_64
epel-next                      Extra Packages for Enterprise Linux 9 - Next - x86_64
extras-common                  CentOS Stream 9 - Extras packages
root@cs9:~> for dep in bravado bravado-core monotonic msgpack python-dateutil pyyaml simplejson six typing-extensions jsonref jsonschema{,'[format]'} pytz simplejson swagger-spec-validator idna jsonpointer rfc3987 strict-rfc3339 webcolors; do [ -z "$(dnf --quiet repoquery --whatprovides "python3dist($dep)")" ] && echo "$dep"; done
bravado
bravado-core
monotonic
jsonref
jsonschema[format]
swagger-spec-validator
rfc3987
strict-rfc3339
webcolors
root@cs9:~>

NB, not sure how it is with Python package extras in EL9, so the jsonschema[format] dep (which is python3-jsonschema+format in Fedora) might be a mute issue.

@carl do you think there's a more efficient way to tick these off than opening bugs against these components individually?

Sadly no, opening individual bugs is the best approach we have.  I found an existing one for python-monotonic [0], and set this bug to depend on it.  The other bugs will need to be created (unless one of us already is a maintainer of the package).

Python extras work the same in RHEL9/EPEL9 as they do in Fedora (examples [1] [2]).  The only potential issue with python3-jsonschema+format is that python3-jsonschema is part of RHEL9, not EPEL9, so it depends on the RHEL maintainers agreeing to do it.  Someone could send the proposed changes as a pull request in GitLab [3].

[0] bug 2056963
[1] https://gitlab.com/redhat/centos-stream/rpms/python-requests/-/blob/c9s/python-requests.spec#L71
[2] https://src.fedoraproject.org/rpms/python-jwt/blob/epel9/f/python-jwt.spec#_37
[3] https://gitlab.com/redhat/centos-stream/rpms/python-jsonschema

Before those bugs are opened, I think the dependencies need to be validated.  I started looking at rfc3987 and realized that fasjson-client doesn't import that anywhere.  The dependencies should be trimmed down to just what is actually needed.

We got some contributors asking about that and so far the only option we can give them at this stage is to use a stream8 container to be able to use it ...

I've been hammering away at this, and I think I got a working solution in copr.  I've already opened many upstream and dist-git pull requests related to getting this to build.  There are a few more to go, and then a few epel9 branch requests, but now that I know it builds it should go smoothly from here on out.  If anyone needs this faster feel free to install it from my copr, just be prepared to distro-sync to switch to the official packages once this bug is closed.

https://copr.fedorainfracloud.org/coprs/carlwgeorge/fasjson-client/

FEDORA-EPEL-2023-ac99251703 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ac99251703

FEDORA-EPEL-2023-ac99251703 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-2023-ac99251703

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2023-ac99251703 has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.