Fedora Account System
Red Hat Associate
Red Hat Customer
Hello,I am having an issue with beets which is resolved in the new release 2.3.1. When I build, I receive: nothing provides python3.13dist(lap) >= 0.5.12 needed by beets-2.3.1-1.fc42.noarch I was thinking that possibly that the code scipy provided: Provides: bundled(LAPJVsp) would be sufficient, but it isn't. I've created python3-lap and will place in COPR, but that won't help getting beets-2.3.1 upgraded because of the outstanding lap dependency. What do you believe would be the best way to handle this? Thank you. Reproducible: Always
If you have a dependency on python3dist(lap), from 'lap = ">=0.5.12"' in pyproject.toml, that means you need https://pypi.org/project/lap, which would normally be packaged as python-lap. It will have to be submitted as a new package and reviewed via https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/.
(In reply to Ben Beasley from comment #1) > If you have a dependency on python3dist(lap), from 'lap = ">=0.5.12"' in > pyproject.toml, that means you need https://pypi.org/project/lap, which > would normally be packaged as python-lap. It will have to be submitted as a > new package and reviewed via > https://docs.fedoraproject.org/en-US/package-maintainers/ > Package_Review_Process/. Thanks for the quick reply. I can certainly go through the process, I have done it before - I just thought that the Python SIG might want to be aware and possible coordinate this since it was another python module. I've got a working package (along with the upgraded beets) here: https://copr.fedorainfracloud.org/coprs/gbcox/dogfood/packages/
The Python SIG is a loose collection of packagers who have an interest in keeping Fedora’s Python ecosystem healthy. Many SIG members will end up helping out with a lot of Python packages, but in the end the SIG is just an assortment of people, mostly contributing as volunteers. The SIG isn’t a “packaging service:” there is a lot of help and mentoring available, but if you need a new package as a dependency, then you are probably the one who should be the primary maintainer. That said, once you have imported the package, you can choose to add python-packagers-sig as a group co-maintainer if you want Python SIG members to be able to fix issues in the package without needing to use PR’s or provenpackager privilege. I have occasionally packaged things to support other people’s projects when I had some time and found the subject interesting or useful, but this is the exception rather than the rule. While I have other priorities right now than packaging python-lap just for fun, both music and abstruse optimization algorithms are relevant to my personal interests, and I’ll be happy to help with any issues you encounter, and perhaps do the package review.
Thanks for the quick reply Ben. I'm going to close this as a duplicate of the package request I am creating, and then I'll xref the beets upgrade bug. I got involved in all this because I created a package call beetbrainz which is a listenbrainz scrobbler, then went down the rabbit hole of finding that the beet package on Fedora needed and upgrade, and then that python3-lap is required for the new release of beets. I'll put a request out on discussion requesting reviews.
*** This bug has been marked as a duplicate of bug 2373806 ***