Fedora Account System
Red Hat Associate
Red Hat Customer
Blocker bug for Cinnamon and dependencies in EPEL9.
Please branch and build the following packages in epel9: caribou cinnamon cinnamon-control-center cinnamon-desktop cinnamon-menus cinnamon-screensaver cinnamon-session cinnamon-settings-daemon cinnamon-translations cjs mintlocale mint-themes mint-x-icons mint-y-icons muffin nemo nemo-extensions python-xapp tint2 xapps xed xreader If you do not wish to maintain these packages in epel9, 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/<package>/addgroup and grant it commit access, or collaborator access on epel* branches.
Access granted I have zero interest in supporting rhel based distros, please leave rawhide branch alone, no epel packaging changes.
Regretfully I've not got the time to get this into EPEL. Passing back to Yaakov Selkowitz as access is granted for EPEL.
FEDORA-EPEL-2023-bfed058207 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-bfed058207
FEDORA-EPEL-2023-bfed058207 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-2023-bfed058207 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-bfed058207 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
If you plan to keep this in EPEL 9 long term, you may want to get the group/comps.xml bits into the EPEL repo.
Leigh (the main admin for most of the packages in question) retired xreader from EPEL 9 last month, and now nemo-preview fails to install (bug 2499305). https://src.fedoraproject.org/rpms/xreader/c/567d502b059fe588ff7230a488634363cdcf677d?branch=epel9 In the commit message he complains that epel-packagers-sig doesn't answer bugs. I guess he didn't get the memo that SIG was deprecated last year and had all members removed from the corresponding group. https://discussion.fedoraproject.org/t/deprecating-the-epel-packagers-sig/137923 What is the future of cinnamon in EPEL 9? If it is to remain than an individual maintainer (not a group) needs to be added, and they'll need to re-add xreader to epel9 to fix nemo-preview. If no one is going to step up then the epel9 branch should probably be retired on most or even all of these packages, not just one.
@leigh123linux When you retired xreader, why didn't you follow the EPEL retirement process? https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire That would have give @yselkowi or anyone else an opportunity to take over the maintenance of the epel9 branch and avoided breaking nemo-preview. This is an official policy, and following it is not optional.
(In reply to Carl George 🤠 from comment #8) > Leigh (the main admin for most of the packages in question) retired xreader > from EPEL 9 last month, and now nemo-preview fails to install (bug 2499305). I will retire all the epel packages if I continue receiving spam from them. > > https://src.fedoraproject.org/rpms/xreader/c/ > 567d502b059fe588ff7230a488634363cdcf677d?branch=epel9 > > In the commit message he complains that epel-packagers-sig doesn't answer > bugs. I guess he didn't get the memo that SIG was deprecated last year and > had all members removed from the corresponding group. That isn't my job to monitor, the epel-packagers-sig should be responsible for that! > > https://discussion.fedoraproject.org/t/deprecating-the-epel-packagers-sig/ > 137923 > > What is the future of cinnamon in EPEL 9? If it is to remain than an > individual maintainer (not a group) needs to be added, and they'll need to > re-add xreader to epel9 to fix nemo-preview. If no one is going to step up > then the epel9 branch should probably be retired on most or even all of > these packages, not just one. If anyone steps up they can manage their own spec files, I don't want any rhel cruff in master and will revert the change a remove their perms.
(In reply to Carl George 🤠 from comment #9) > @leigh123linux When you retired xreader, why didn't you follow the > EPEL retirement process? > > https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ > #process_no_time_or_desire > > That would have give @yselkowi or anyone else an opportunity to > take over the maintenance of the epel9 branch and avoided breaking > nemo-preview. This is an official policy, and following it is not optional. I don't accept any responsibility for the epel packages, the blame for this should be leveled at the epel sig not me!
Someone has change the assignee for the epel packages back to me, I have changed them to orphan and anything reassigned to me will be closed as 'Wont fix'
(In reply to Carl George 🤠 from comment #9) > @leigh123linux When you retired xreader, why didn't you follow the > EPEL retirement process? That is the epel maintainers job to do, not mine!, so stop trying to assign blame to me!
@leigh123linux please make me (FAS: yselkowitz) the epel maintainer for all these packages.
(In reply to Yaakov Selkowitz from comment #14) > @leigh123linux please make me (FAS: yselkowitz) the epel > maintainer for all these packages. Done.
> I will retire all the epel packages if I continue receiving spam from them. Bug reports are not spam. Please read the FESCo policy document on package maintainer responsibilities. https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ > That isn't my job to monitor, the epel-packagers-sig should be responsible for that! As I already explained, that group no longer exists. > If anyone steps up they can manage their own spec files, I don't want any rhel cruff in master and will revert the change a remove their perms. RHEL/EPEL conditionals are explicitly allowed by the packaging guidelines. You have no authority to disallow them. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_legibility > I don't accept any responsibility for the epel packages, the blame for this should be leveled at the epel sig not me! Again, that group no longer exists. While no one can force you to volunteer your time to work on EPEL, you acted irresponsibly and recklessly by retiring a random package that other packages depending on, and you ignored policy about retirement procedures. In the future, please follow Fedora and EPEL policy so other contributors can effectively collaborate with you.
(In reply to Carl George 🤠 from comment #16) > > I will retire all the epel packages if I continue receiving spam from them. > > Bug reports are not spam. Please read the FESCo policy document on package > maintainer responsibilities. > > https://docs.fedoraproject.org/en-US/fesco/ > Package_maintainer_responsibilities/ > > > That isn't my job to monitor, the epel-packagers-sig should be responsible for that! > > As I already explained, that group no longer exists. > > > If anyone steps up they can manage their own spec files, I don't want any rhel cruff in master and will revert the change a remove their perms. > > RHEL/EPEL conditionals are explicitly allowed by the packaging guidelines. > You have no authority to disallow them. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_legibility > > > I don't accept any responsibility for the epel packages, the blame for this should be leveled at the epel sig not me! > > Again, that group no longer exists. While no one can force you to volunteer > your time to work on EPEL, you acted irresponsibly and recklessly by > retiring a random package that other packages depending on, and you ignored > policy about retirement procedures. In the future, please follow Fedora and > EPEL policy so other contributors can effectively collaborate with you. Don't ever try to talk to me again, in fact welcome to my spam filter.