This bug is part of the non-responsive maintainer procedure for dmlb2000, 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 pdsh.
I am not dmlb2000, but I'm still kicking pdsh forward.
This was opened as I was hoping to get an EPEL8 build of pdsh: https://bugzilla.redhat.com/show_bug.cgi?id=1960006 - I never got a response there or when I reached out to the maintainers/owners lists for pdsh. I would be happy to become a co-maintainer if it would help get an EPEL8 build going. I am a co-maintainer of genders which is one of the dependencies for pdsh.
Ah, I see. I believe spstarr is the EPEL maintainer. I did see the bug and email, but assumed he would take care of it. Does it need any code changes or just a branch and build?
Needs code changes to not build Torque plugin RPM unless someone gets Torque builds into EPEL8. The Torque RPMs in EPEL7 are ancient and Torque and the company behind it are not long for this world, or so it seems based on our experience with the product. I kind of imagined if the Torque plugin RPMs are useful to keep in Fedora but okay to drop in EPEL the spec could be updated to just not do anything related to Torque for RHEL builds but continue for Fedora builds. I see you are the maintainer for Torque RPMs so I guess it really up to you if you want to also put Torque into EPEL8 to make it work just like EPEL7.
I have no interest in maintaining torque in epel8. I only kick it along in Fedora so as to keep expectations on par with what was available before. I have requested an EPEL8 branch for pdsh. If you tell me your FAS account name, I will give you access to pdsh, then you can make changes and build. :)
My FAS account name is treydock. Does the idea of something like this in spec sound reasonable for pdsh to avoid Torque on EPEL8? %if 0%{?rhel} < 8 && 0%{?fedora} >= 0 <do torque things> %endif Or would it be better to just drop Torque support entirely from pdsh and propagate that out to Fedora builds as well?
I think that conditionalization is the cleanest way. If/when torque goes extinct, we can revisit removal. You now have admin perms. Remember, with great power comes great responsibility, but do what you think is best on the epel8 branch.
Oh, and && 0{?fedora} is sufficient, no need to compare against anything there.
After some thought I think the condition has to be this: %if %{?rhel} < 8 | 0{?fedora} <build with torque> %else <build without torque> %endif Is there a way to setup Koji builds to do either "--without torque" or "--define '_without_torque ...'" so that the existing --with/--without logic in pdsh spec can be used or is doing conditional logic on OS version the only possible way to vary build behavior between branches? Also scratch builds are failing because libnodeupdown-devel is missing. I'm not having much luck even finding that package in Koji or in Fedora package sources website. I can easily extend condition to that as well just not sure why I can't find that RPM anywhere.
Correction, I had typo in my condition: %if %{?rhel} < 8 || 0{?fedora} <build with torque> %else <build without torque> %endif
I think this is the correct conditional: %if 0%{?rhel} < 8 If %{rhel} is defined and less than 8, use torque. If %{rhel} is undefined, the conditional simplifies to: %if 0 < 8 Which is true (and happens in Fedora).
FEDORA-EPEL-2021-6635a8ea5e has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6635a8ea5e
Thanks for the tip, I made the adjustments to epel8 branch and pushed to bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6635a8ea5e I think unresponsive maintainer that prompted this bug is same person who maintains whatsup which provides libnodeupdown-devel, I just marked RHEL8 builds to not use that dependency also.
FEDORA-EPEL-2021-6635a8ea5e has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6635a8ea5e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I don't have an EPEL8 environment, plus I don't use pdsh anymore, haven't in a long time...
FEDORA-EPEL-2021-0efa487610 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0efa487610
FEDORA-EPEL-2021-0efa487610 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0efa487610 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-0efa487610 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.