I just tried to update git to fix a security bug and ran into a failure with asciidoc. The build logs are at: https://koji.fedoraproject.org/koji/taskinfo?taskID=1424781 https://koji.fedoraproject.org/koji/getfile?taskID=1424781&name=build.log The errors are: ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11.css ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11-manpage.css ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11-quirks.css I'm not sure, but this looks like the same problem that was fixed in upstream acciidoc commit fa6db1ff4369: http://hg.sharesource.org/asciidoc/rev/fa6db1ff4369 I would guess that's long been in the asciidoc packages we have, but I didn't pull the source to verify that. It is worth noting that /etc/asciidoc/stylesheets is a symlink to /usr/share/asciidoc/stylesheets. The symptoms seem very similar to those reportedly fixed in the above commit. Can you take a look and let me know if this is a git bug or asciidoc bug?
Created attachment 348729 [details] Patch against asciidoc-8.4.5 (for source and spec file) I looked into this a bit and it seems to be caused by the upstream fix mentioned in comment #1. That fix was for a user that had /etc symlinked to /private/etc. So using realpath fixed that problem, but it causes problems for us because we have /etc/asciidoc/stylsheets symlinked to /usr/share/asciidoc/stylesheets. :( The attached patch allows git to build successfully, but it could use some eyes that are more familiar with asciidoc.
Asciidoc author Stuart Rackham replied to my post on the asciidoc list and recommended that we use --unsafe. He suggested that making that the default might be a good idea, as he personally felt the current default was more pain than it was worth. So hopefully a future release of asciidoc will eliminate this problem for us. Stuart's reply: http://groups.google.com/group/asciidoc/msg/aab37c19ea84020e Asciidoc FAQ: http://www.methods.co.nz/asciidoc/faq.html#_the_asciidoc_unsafe_option_is_a_pain_can_it_be_enabled_by_default If anyone else could try the patch I attached in comment #1 and confirm that it does more good than harm, that would be great, as we could apply it as an interim measure so that every asciidoc user isn't annoyed by this bug.
FWIW, I just added --unsafe to the asciidoc calls to fix the guilt build. So I'm good for now ;) -Eric
I regularly build git from git here, and haven't seen any ERROR. I just did a "make clean; make" and saw no problems. What gives?
(In reply to comment #4) > I regularly build git from git here, and haven't seen any ERROR. I just did a > "make clean; make" and saw no problems. What gives? It's the doc building that is broken with asciidoc-8.4.5. A plain 'make' doesn't build the docs AFAIK, you need 'make doc' for that. Testing a few fixes for submission to upstream asciidoc and for our packages is on my agenda for today or tomorrow hopefully. Stuart indicated that defaulting to using the --unsafe option would probably be a good idea.
Created attachment 354530 [details] Various spec file cleanups and patches for asciidoc I spent some time and added a patch to make asciidoc default to using the --unsafe option, sent upstream for consideration¹. While I was at it, I also fixed a number of rpmlint complaints about asciidoc, the most important of which are the executable-marked-as-config-file errors about the filter scripts. To do this I added a DATA_DIR constant similar to the existing CONF_DIR constant and search it when looking for filter scripts. This was also sent upstream². I tested mock builds of libXi, git, and tig and found no problems with any of these changes. If no one sees and glaring problems (and upstream doesn't tell me these are total crap :), I'll apply for commit privileges for asciidoc and build an update for rawhide. ¹ http://groups.google.com/group/asciidoc/msg/fe14ea9467b1f6bd ² http://groups.google.com/group/asciidoc/msg/6c156cff6ed81a09
Looks like the changes are in Rawhide now, so maybe this bug can be closed?
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping