Please branch and build perl-XML-TreePP in epel9.
Are you going to be able to build perl-XML-TreePP in epel9?
We are trying to install glpi-agent (https://github.com/glpi-project/glpi-agent) on CentOS 9 Stream, which has perl-XML-TreePP as a requirement. Any news on an ETA? Thanks.
xmltv also need it
Not good news , Marianne not have any activity since Fev 2022 (expect in a tag_package_owners entry!?!? ) Last login in FAS: jehane 2021-02-18 Last action on koji: Fri, 09 Sep 2022 tag_package_owners entry created by humaton [still active] Last package update on bodhi: 2021-02-01 13:54:59 on package perl-POE-Component-Client-Ping-1.176-1.fc33 Last actions performed according to fedmsg: - org.fedoraproject.prod.bugzilla.bug.update on 2022-01-15 01:23:48 - org.fedoraproject.prod.bugzilla.bug.update on 2022-01-15 01:23:48 - org.fedoraproject.prod.bugzilla.bug.update on 2022-01-04 15:03:10 - org.fedoraproject.prod.bugzilla.bug.update on 2022-01-04 15:03:09 - org.fedoraproject.prod.bugzilla.bug.update on 2021-12-13 16:34:31 - org.fedoraproject.prod.bugzilla.bug.new on 2021-12-13 16:34:31 - org.fedoraproject.prod.bugzilla.bug.update on 2021-12-12 02:40:57 - org.fedoraproject.prod.bugzilla.bug.new on 2021-12-12 02:40:57
(In reply to Sergio Basto from comment #4) > Not good news , Marianne not have any activity since Fev 2022 (expect in a > tag_package_owners entry!?!? ) I *think* the various tag_package_owner values are artifacts of other workflows, and not directly related to activity (I have seen such values for others that I believe are no longer active). I will not be surprised if Marianne will be identified in the list to come out shortly (now that F37 has been released) of inactive packagers and cleanups. And that will end up orphaning perl-XML-TreePP. If no one else picks it up first if orphaned I will likely choose to do so (when I looked some time ago perl-XML-TreePP seemed to not be especially onerous to maintain), and will then branch for epel9.
(In reply to Gary Buhrmaster from comment #5) > (In reply to Sergio Basto from comment #4) > > Not good news , Marianne not have any activity since Fev 2022 (expect in a > > tag_package_owners entry!?!? ) > > I *think* the various tag_package_owner values are artifacts of other > workflows, and not directly related to activity (I have seen such values for > others that I believe are no longer active). > > I will not be surprised if Marianne will be identified in the list to come > out shortly (now that F37 has been released) of inactive packagers and > cleanups. And that will end up orphaning perl-XML-TreePP. > > If no one else picks it up first if orphaned I will likely choose to do so > (when I looked some time ago perl-XML-TreePP seemed to not be especially > onerous to maintain), and will then branch for epel9. Can you open an unresponsive maintainer request please , I think is the best solution Thank you
This bug is part of the non-responsive maintainer procedure for cottsay, following https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/. Please respond if you are still active in Fedora and want to maintain perl-XML-TreePP Thank you
I have taken ownership of the packaged after it was orphaned as part of the packager cleanup. Branch requested: https://pagure.io/releng/fedora-scm-requests/issue/49373
FEDORA-EPEL-2022-69649340de has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-69649340de
FEDORA-EPEL-2022-69649340de 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-2022-69649340de See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-69649340de has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days