Description of problem: Can python-tabulate in EPEL7 be updated to version 0.8.9 (or newer) Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Version 0.8.9 introduces latex_longtable support that I'd like to utilize. Additional info:
Currently, the EPEL7 package builds for Python 2.7, 3.4, and 3.6 (python2, python3_other, and python3). Upstream version 0.8.6 stops supporting Python 3.4. (Version 0.9 stops supporting Python 2.7 and 3.6.) So I think we can safely update to version 0.8.5, or to version 0.8.10 but at the cost of dropping (and Obsoleting) the python34-other subpackage. Opinions on what to do from the submitter and from python-tabulate maintainers (and other neuro-sig/python-sig members) would be appreciated.
For now, I’ve cleaned up the packaging a bit and updated to 0.8.5. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-bf8baddd5b
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Hrm, not sure what happened here---I don't maintain the EL branches. Maybe Ralph orphaned the package on the branch? We don't maintain packages for EL in the neuro-sig, and I don't do them personally either (since I don't use EL at all). Ben, what should we do here? Orphan the package on EL? Cheers,
You may set me as the EPEL bug assignee for this package. I’m happy to take care of any EPEL work it might need. (In reply to Ben Beasley from comment #1) > Currently, the EPEL7 package builds for Python 2.7, 3.4, and 3.6 (python2, > python3_other, and python3). Upstream version 0.8.6 stops supporting Python > 3.4. (Version 0.9 stops supporting Python 2.7 and 3.6.) > > So I think we can safely update to version 0.8.5, or to version 0.8.10 but > at the cost of dropping (and Obsoleting) the python34-other subpackage. > > Opinions on what to do from the submitter and from python-tabulate > maintainers (and other neuro-sig/python-sig members) would be appreciated. Since there wasn’t any feedback on dropping the python34-tabulate subpackage, I’m not planning to do it, and I’m going to close this as WONTFIX. If there’s demand for updating to 0.8.10 at the cost of dropping the python34-tabulate subpackage, the issue (and discussion) can be reopened.
(In reply to Ben Beasley from comment #5) > You may set me as the EPEL bug assignee for this package. I’m happy to take > care of any EPEL work it might need. Sure thing---I added you as a collaborator to the repo for epel* branches. Does that do it, or is there anything else we need to tweak?
(In reply to Ankur Sinha (FranciscoD) from comment #6) > (In reply to Ben Beasley from comment #5) > > You may set me as the EPEL bug assignee for this package. I’m happy to take > > care of any EPEL work it might need. > > Sure thing---I added you as a collaborator to the repo for epel* branches. > Does that do it, or is there anything else we need to tweak? I’m already able to maintain EPEL branches for this package via my neuro-sig group membership, although it doesn’t hurt to make responsibility explicit this way. If you want EPEL bugs to be assigned to me instead of you by default, you can go to https://src.fedoraproject.org/rpms/python-tabulate and click the Edit button under Bugzilla Assignee, and set the EPEL assignee to me (music). Admin permissions on the package should really be sufficient to adjust bugzilla assignees, but unfortunately only the main admin can do it.