Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2225760 - doxy2man: FTBFS in Fedora f39: manpage.xsl not found
Summary: doxy2man: FTBFS in Fedora f39: manpage.xsl not found
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: doxy2man
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nikos Mavrogiannopoulos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F39FTBFS
TreeView+ depends on / blocked
 
Reported: 2023-07-25 17:26 UTC by Fedora Release Engineering
Modified: 2023-07-27 10:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-27 10:45:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (deleted)
2023-07-25 17:27 UTC, Fedora Release Engineering
no flags Details
root.log (deleted)
2023-07-25 17:27 UTC, Fedora Release Engineering
no flags Details
state.log (deleted)
2023-07-25 17:27 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2023-07-25 17:26:57 UTC
doxy2man failed to build from source in Fedora rawhide/f39

https://koji.fedoraproject.org/koji/taskinfo?taskID=103568911


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
Please fix doxy2man at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
doxy2man will be orphaned. Before branching of Fedora 40,
doxy2man will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Comment 1 Fedora Release Engineering 2023-07-25 17:27:01 UTC
Created attachment 1977755 [details]
build.log

Comment 2 Fedora Release Engineering 2023-07-25 17:27:05 UTC
Created attachment 1977756 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2023-07-25 17:27:07 UTC
Created attachment 1977757 [details]
state.log

Comment 4 Nikos Mavrogiannopoulos 2023-07-26 13:01:58 UTC
There seem to be changes in the asciidoc package. asciidoc.py is no longer available and after fixing that, I see:
asciidoc: writing: /builddir/build/BUILD/doxy2man-5ce113f4d2a3fc6712f8eb8606a6b0899dc6f8d1/doxy2man.8.xml
warning: failed to load external entity "/usr/share/asciidoc/docbook-xsl/manpage.xsl"
cannot parse /usr/share/asciidoc/docbook-xsl/manpage.xsl

Comment 5 Nikos Mavrogiannopoulos 2023-07-26 13:11:42 UTC
I could not figure out a relevant change to asciidoc. I'm assigning it temporarily to asciidoc to get more information from the maintainer if any. I'd appreciate any help here.

Comment 6 Josef Ridky 2023-07-27 07:00:16 UTC
From asciidoc changelog:

Version 10.0.0 (2021-10-16)
---------------------------
.Breaking Changes
AsciiDoc.py has been rewritten to be a https://pypi.org/project/asciidoc/[proper Python package], installable via pip. Downloading and running asciidoc from the repo is not recommended, but can be done through `python3 -m asciidoc` or `python3 -m asciidoc.a2x`. CLI usage should remain the same where both `asciidoc` and `a2x` CLI commands are available after pip installation. Support for overriding the bundled *.conf files is done through CLI flags, environment variables, etc., and not through directly editing the files within the installation. Importing asciidoc should no longer require the `asciidocapi.py` script, and can be done through regular python import, e.g. `import asciidoc; asciid     oc.execute(...)`.

The APIs of the asciidoc and a2x scripts are now considered "provisional" with no guarantee of BC between releases with the exception of the `asciidoc.execute` method. Please post an issue on our tracker for any method you directly r     ely on and would like to have BC for.


Since this change, there is no /usr/bin/asciidoc.py but just /usr/bin/asciidoc so I would first try to run the build with new call and than it could be investigated more if needed.

Comment 7 Nikos Mavrogiannopoulos 2023-07-27 10:16:58 UTC
Thank you Josef for the investigation. I have already changed the package to use asciidoc instead of asciidoc.py, but the issue is that asciidoc issues the error below:
warning: failed to load external entity "/usr/share/asciidoc/docbook-xsl/manpage.xsl"
cannot parse /usr/share/asciidoc/docbook-xsl/manpage.xsl

The command that fails is: asciidoc -v -d manpage -b docbook doxy2man.8.txt && xsltproc --nonet -o doxy2man.8 /usr/share/asciidoc/docbook-xsl/manpage.xsl doxy2man.8.xml

It is the reason of the failure I cannot understand.

Comment 8 Nikos Mavrogiannopoulos 2023-07-27 10:22:16 UTC
Indeed the f39 asciidoc package has manpage.xsl at /usr/lib/python3.12/site-packages/asciidoc/resources/docbook-xsl/manpage.xsl

How can a package detect the right resource file to use?

Comment 9 Nikos Mavrogiannopoulos 2023-07-27 10:45:01 UTC
I now find that file using rpm --fileprovide.


Note You need to log in before you can comment on or make changes to this bug.