Please support an EL 8 branch as it is needed for document generation.
I tried a COPR build and note the following unmet dependencies: DEBUG util.py:621: No matching package to install: 'rubygem(coderay)' DEBUG util.py:621: No matching package to install: 'rubygem(erubis)' DEBUG util.py:621: No matching package to install: 'rubygem(haml)' DEBUG util.py:621: No matching package to install: 'rubygem(nokogiri)' DEBUG util.py:621: No matching package to install: 'rubygem(rouge)' DEBUG util.py:621: No matching package to install: 'rubygem(slim)' DEBUG util.py:621: No matching package to install: 'rubygem(tilt)'
It would definitely be nice to get this into el8, but as you note, there are a number of deps which need to make it there first. I'm hoping that the maintainers of those deps (or others who really want to see asciidoctor in el8) will find the time to get them into el8 eventually. I don't feel particularly competent to branch and maintain those (nor motivated to be a good caretaker of them), even if there were enough hours in the day. :)
*** Bug 1849446 has been marked as a duplicate of this bug. ***
It appears that the conditionals added to the rawhide branch by Neal a few weeks ago conditionalize the missing dependencies, and the rawhide branch of this package now builds successfully against EPEL 8: https://koji.fedoraproject.org/koji/taskinfo?taskID=82823899
Hi Dan, is there anything I can do to help move this along? If maintenance and/or testing is a concern, please consider adding me (cottsay) as an EPEL-only co-maintainer of this package.
Since there's no one else named Dan on this thread, I'm going to assume you're referring to me. If not, please disregard. I don't maintain this package for EL, so there's nothing I can do to move it along one way or another. However, if you have any question about Asciidoctor itself or how to work with the code, please don't hesitate to contact me. I'm always happy to answer such questions.
Scott, thanks for the offer! I've added you as a committer. I think that should give you the ability to make an epel8 branch request and push an update. I didn't restrict that to only the epel8 branch, since the branches are generally merged down from rawhide, so if changes are needed for epel8 (or in most any other branch, we should start them in rawhide and let them percolate down). Let me know if you don't want that much access. :) AFAIK, the package has "built" for epel8 for some time, since 1f2c7cb (Do not run tests for any %{rhel} distros., 2021-01-21). It's a shame to not be able to run the tests, but if we keep the spec file shared across fedora and epel branches, I guess that provides some level of testing and confidence -- with "some" being the operative word. Many of the tests _should_ be able to run on epel9 (and perhaps epel8), but that does require some additional conditionals or treating each branch separately, as Vít noted in https://src.fedoraproject.org/rpms/rubygem-asciidoctor/pull-request/6#comment-77418. Personally, I tend to prefer a few conditionals in an otherwise shared spec file than managing each branch separately at this time and for this package. It's not that git's branching isn't wonderful (it is!); it's that it doesn't fit well with how spec files are maintained. Some of that will improve as the release and changelog can be migrated out of the spec file, but that's not suitable for all of the epel branches AFAIK. But if there are more active maintainers who want to keep asciidoctor fed and watered and do so with each branch separate, I'm happy to not consume it for the git build process. ;) The epel-packagers-sig group is a collaborator on the package. I think that's how it was branched for epel9. It might be nice if they handled epel8 as well. Dan is listed as the bugzilla assignee on both Fedora and EPEL branches in Pagure. It seems like we ought to change that for EPEL, as Dan indicated above "I don't maintain this package for EL." Lastly, I suspect many of us are interested in asciidocter by way of another package (git, for me). That can keep it from getting the care it needs as so long as it works to build the docs we need, it's out of sight and out of mind. So the more help, the better. I will say that upstream is awesome and very responsive to the few issues I've had; Dan in particular, as well the other folks in the Ascidoctor project as well.
Thanks Dan and Todd. > ... if changes are needed for epel8 ... we should start them in rawhide and let them percolate down Noted, thanks. > I tend to prefer a few conditionals in an otherwise shared spec file than managing each branch separately at this time and for this package. I have similar preferences! > I will say that upstream is awesome and very responsive to the few issues I've had Great to hear, thank you.
*** Bug 2065935 has been marked as a duplicate of this bug. ***
rubygem-asciidoctor is needed to build Wireshark as of version 3.6.
FEDORA-EPEL-2022-660ef2e31c has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-660ef2e31c
FEDORA-EPEL-2022-660ef2e31c 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-2022-660ef2e31c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-660ef2e31c has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.