Please branch and build python-matplotlib in epel10. If you do not wish to maintain python-matplotlib in epel10, or do not think you will be able to do this in a timely manner, the EPEL Packagers SIG would be happy to be a co-maintainer of the package; please add the epel-packagers-sig group through https://src.fedoraproject.org/rpms/python-matplotlib/addgroup and grant it commit access, or collaborator access on epel* branches. I would also be happy to be a co-maintainer (FAS: kkeithle); please add me through https://src.fedoraproject.org/rpms/python-matplotlib/adduser
Added both.
branched, not built. this is only needed for %test in python-sortedcontainers. I (temporarily) disabled %test in python-sortedcontainers, at least until all of python-matplotlib's BRs are resolved, as IMO python-sortedcontainers does not need %test for ceph->python-hypothesis->python-sortedcontainers.
This is needed to for blosc-bench, which has already been published to epel10 and is currently uninstallable.
*** Bug 2319787 has been marked as a duplicate of this bug. ***
Hi, matplotlib is a dependency of python-pygraphviz apparently: #2320859 Cheers, Romain
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
see https://bugzilla.redhat.com/show_bug.cgi?id=2308780#c2
Kaleb, I'm confused. > I would also be happy to be a co-maintainer (FAS: kkeithle); Elliott added you as a collaborator, and set you as the default bugzilla assignee. Then you closed the bug because you were able to work around your immediate need by disabling the tests in python-sortedcontainers. Other packages still depend on this, and the bug was re-opened. You then re-assigned the bug to Elliott. That is in direct contradiction to your original comment, and not fair to Elliott. It's also not appropriate to reassign the bug to extras-orphan. That is used for orphan packages, and this package is not orphaned. This bug needs to stay assigned to you per your original request, and you can work on it as your time allows so you can eventually re-enable the python-sortedcontainers test suite. If you're willing to do this, please change the status of the bug to ASSIGNED. If you are not willing to do this, please ask Elliott to remove you from the package and remove you as the default EPEL bugzilla assignee. Then the bug can be unassigned until another maintainer steps up.
It's a pretty big leap to go from "willing to do the build for EPEL10" to being the default bugzilla assignee for all EPEL bugs, IMO, and then having every EPEL bug get assigned to me. Apparently using the '--fas ...` option on ebranch is/was a mistake. So yes (or no) I don't wish to take on responsibility for all the EPEL builds of matplotlib. Please remove me as comaintainer and remove me as the default EPEL bugzilla assignee. Thanks
Right, maybe there’s some way to make it more clear, but “be a co-maintainer” is generally understood to mean taking care of a package on some kind of a long-term basis.
(In reply to Ben Beasley from comment #10) > Right, maybe there’s some way to make it more clear, but “be a > co-maintainer” is generally understood to mean taking care of a package on > some kind of a long-term basis. I was, I am willing—— For EPEL10. I was not expecting to take on responsibility for 'fails-to-install for epel8' or 'build a python38-matplotlib for epel8' bugs. I presumed that adding '--fas ...' to ebranch was a way of saying "if you don't want to give it to the whole epel-pkg-sig, you can just give it to me if you want.'
That makes sense! In any case, thanks for following up.
> It's a pretty big leap to go from "willing to do the build for EPEL10" to being the default bugzilla assignee for all EPEL bugs, IMO, and then having every EPEL bug get assigned to me. The only granularity we have for default bugzilla assignees is Fedora or EPEL, and each one has to be set to someone. If none of the other maintainers have expressed interest in EPEL, it makes perfect sense for the the one maintainer who has to be set as the default EPEL bugzilla assignee. > I was, I am willing—— For EPEL10. We gave up the concept of per-branch maintainers a long time ago, when we moved from pkgdb to pagure. Maintainers are expected to collaborate on all branches. > I was not expecting to take on responsibility for 'fails-to-install for epel8' or 'build a python38-matplotlib for epel8' bugs. Bug 2303479 ('fails-to-install for epel8') was caused by someone forgetting to enable CRB. Bug 2139778 ('build a python38-matplotlib for epel8') is a request for a new package that shouldn't have been filed under the python-matplotlib component. Both of these were trivial to look into and close, so I took care of them even though I'm not a maintainer of this package. If you are going to volunteer to be a co-maintainer, you should be willing to at least share in the overall responsibility of maintaining the package, not just for the branch that is your priority. No one is saying you have to personally fix every bug, but you should at least try to be helpful where you can. Being a maintainer is not about creating only the builds you need as dependencies to unblock other packages.
FEDORA-EPEL-2024-42a0bb4c15 (python-matplotlib-3.9.1-0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-42a0bb4c15
FEDORA-EPEL-2024-f7a0bf0fb4 (fonttools-4.55.3-2.el10_0 and python-matplotlib-3.9.1-6.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f7a0bf0fb4
FEDORA-EPEL-2024-f7a0bf0fb4 has been pushed to the Fedora EPEL 10.0 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f7a0bf0fb4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-f7a0bf0fb4 (fonttools-4.55.3-2.el10_0 and python-matplotlib-3.9.1-6.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.