Description of problem: The version of musicbrainzngs packaged in Fedora is very old. Version 0.6 was released in 2016, but Fedora only packages version 0.5. Version 0.5 mistakenly enables Python deprecation warnings, which causes any Python program that imports musicbrainzngs to start outputting deprecation warnings. This issue was fixed in 2014: <https://github.com/alastair/python-musicbrainzngs/pull/159> and the fix is present in version 0.6 of the library. Version-Release number of selected component (if applicable): 0.5-12.fc29 How reproducible: always Steps to Reproduce: 1. dnf install python3-pysocks python3-jinja2 2. python3 -c 'import musicbrainzngs; import socks' Actual results: /usr/lib/python3.7/site-packages/socks.py:58: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working from collections import Callable /usr/lib/python3.7/site-packages/jinja2/utils.py:485: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working from collections import MutableMapping /usr/lib64/python3.7/site-packages/markupsafe/__init__.py:13: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working from collections import Mapping Expected results: No deprecation warnings (unless the user or administrator has explicitly enabled them.)
Slight correction: you get the results I posted above if you run: python3 -c 'import musicbrainzngs; import socks; import jinja2'
Thanks Sam, I've not been using the Beets music manager packaged in Fedora for the reason of those warnings. Un update to musicbrainzngs will be very welcome.
This issue should be easily fixable. Any reaction from the package maintainer, please? I would step up as a co-maintainer for this package if you would like to share the maintenance work.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Pull request: https://src.fedoraproject.org/rpms/python-musicbrainzngs/pull-request/1
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Issue still present. This package seems to be unmaintained. Would it be possible to get any feedback from the package maintainers? Or how about merging my pull request?
@fedora Actually this package is not only old and completely outdated, it creates a complete mess on dependent packages, too. E.g Quodlibet and ExFalso are dependent on this package, but in the real world Quodlibet even needs >= 6.0 to work correctly. Fedora has the most recent Quodlibet version in repos, but has a dependency on this package which is essentially way too old. As this is installed as a dependency it creates all sort of other problems in the system, e.g. if you install via pip and a package needs musicbrainzngs it pulss the system dependency if you oversee that somehow, and than certain software does not even work anymore. This version is 8 years old, so this is literally somehow insane why no one does anything about that. Can this please be fixed? The packages who depend on newer musicbrainzngs versions are essentially broken, even if they don't look like it at first sight. Thanks.
I think it might be best to start the non-responsive maintainer process on this package, in order to add at least one co-maintainer to the package. In the short-run it might be the easiest to alert a proven-packager and ask him to merge the pull request. The maintainer seems to still be active in fedora, but just not for this package. Last login in FAS: amluto 2019-08-22 Last action on koji: Sat, 27 Nov 2021 tag_package_owners entry created by bodhi [still active] Last package update on bodhi: 2020-04-25 18:24:52 on package nvme-cli-1.11.1-1.fc33 Last actions performed according to fedmsg: - accts commented on RHBZ#1685216 'Upgrade to musicbrainzngs 0.7.1' on 2021-12-08 20:52:38 - accts updated 'flag.needinfo' on RHBZ#1685216 'Upgrade to musicbrainzngs 0.7.1' on 2021-12-08 20:52:38 - accts updated 'cc' and 'flag.needinfo' on RHBZ#1685216 'Upgrade to musicbrainzngs 0.7.1' on 2021-12-08 20:52:38 - fedora updated 'flag.needinfo' and 'version' on RHBZ#1685216 'Upgrade to musicbrainzngs 0.7.1' on 2021-11-05 09:33:20 - fedora commented on RHBZ#1685216 'Upgrade to musicbrainzngs 0.7.1' on 2021-11-05 09:33:20 - bcotton commented on RHBZ#1685216 'Upgrade to musicbrainzngs 0.7.1' on 2021-11-04 18:23:21 - klember commented on RHBZ#1908874 'File chooser subfolder search is complet...' on 2021-10-02 22:45:23 - luto commented on RHBZ#1908874 'File chooser subfolder search is complet...' on 2021-10-02 21:19:37 - updates commented on RHBZ#1908874 'File chooser subfolder search is complet...' on 2021-10-01 04:20:10 - updates commented on RHBZ#1908874 'File chooser subfolder search is complet...' on 2021-09-30 16:26:43
*** Bug 2030467 has been marked as a duplicate of this bug. ***
I've sent out a message to fedora-devel. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PQL3RKP3RXT2RH6K5OUQJKA4VUOPDXJN/
(In reply to Tom G from comment #9) > @fedora Actually this package is not only old and completely > outdated, it creates a complete mess on dependent packages, too. E.g > Quodlibet and ExFalso are dependent on this package, but in the real world > Quodlibet even needs >= 6.0 to work correctly. Fedora has the most recent > Quodlibet version in repos, but has a dependency on this package which is > essentially way too old. > […] Hi Tom, is there anything I can provide info on? I don't understand what to do from your comment. Or did you @needinfo me by accident? @hannes: Thanks for taking the initiative!
(In reply to Christian Stadelmann from comment #13) > (In reply to Tom G from comment #9) > > @fedora Actually this package is not only old and completely > > outdated, it creates a complete mess on dependent packages, too. E.g > > Quodlibet and ExFalso are dependent on this package, but in the real world > > Quodlibet even needs >= 6.0 to work correctly. Fedora has the most recent > > Quodlibet version in repos, but has a dependency on this package which is > > essentially way too old. > > […] > > Hi Tom, is there anything I can provide info on? I don't understand what to > do from your comment. Or did you @needinfo me by accident? > > @hannes: Thanks for taking the initiative! That was on accident, sorry Christian. I hope this situation will be cleared soon.
I orphaned it. Feel free to take over.
As the package is now orphaned will you take it over Johannes? Or how will there be a new maintainer for it? If there is no maintainer it would be cleaner somehow to strip it at least from the dependency list from QuodLibet/ExFalso, as it does not meet the minimum upstream requirement anymore. There are other reqs like pyinotify for QL which are not in the Requires at all, so they are missing anyways (not needed for core app though, but this also applies to musicbrainzngs). The other package that is really affected from this will be beets as mentioned above, which is also a pretty dated version in Fedora (1.4.9, upstream is at 1.6.0 currently, with a lot of improvements). If one installs the actual beets via pip and python3-musibrainzngs is installed via dnf it will end in error when even just called, as the old version is pulled from the system install. For all that know how to circumvent it would be rather easy, for and end-user of Workstation it might not be that clear though.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
FEDORA-2021-00788b023c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-00788b023c
FEDORA-2021-c88255f6e9 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c88255f6e9
I've taken it for now. @fedora please feel free to become a co-maintainer. I've also added the version requirement in quodlibet, but I won't add a lot more dependencies, only for the plugins. Please keep in mind that most of us are doing all of the fedora related work in our free time.
@johannes.lips Thanks for taking this over for now. Just to clarify. I did not mean to offend you, nor to press you in any way to fulfill every optional dependency in QL/EF. I just meant, if the package would have stayed orphaned for longer or even retired, that it would be better to remove it at all from the dependency list, as it is optional anyways, like others too that are not installed. From an infrastructural standpoint that would have been cleaner than pulling a package that does not work in the end.
FEDORA-2021-00788b023c has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-00788b023c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-00788b023c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-c88255f6e9 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c88255f6e9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c88255f6e9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-00788b023c has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-c88255f6e9 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.