Bug 485161
Summary: | git man page not displayed correctly | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Robin Green <greenrd> |
Component: | git | Assignee: | Todd Zullinger <tmz> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | bkearney, chrisw, jwboyer, mjg, ovasik, tmz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-06-28 23:47:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Robin Green
2009-02-11 23:32:31 UTC
rpm -V git gives no output, indicating that the man file has not been corrupted on my system. This is a known problem. I reported it upstream¹, but no one seems to know the cause. It seems to have started with F10, where xmlto is newer than on F9. Any help or ideas would be appreciated. Maybe the xmlto maintainers can help? ¹ http://article.gmane.org/gmane.comp.version-control.git/105589 Strange, could build that manpage without problems (and with expected look) on my machine with latest xmlto (in fact 0.0.22 RC :) - but it seems to work with 0.0.21 as well), I have latest docbook-style-xsl, older groff (groff-1.18.1.1-11.1). Which version of docbook-style-xsl was used for build? Ondrej, thanks for taking a look. docbook-style-xsl-1.74.0-6.fc11 is what was pulled in to the build root. The mock logs for this build are at: http://kojipkgs.fedoraproject.org/packages/git/1.6.1.3/1.fc11/data/logs/i386/ This has happened since sometime during the F10 rawhide cycle. I thought when I looked at it then that the only package which differed was xmlto. But I could easily be wrong about that. I surely don't have a great understanding of the doc tool chain. :) So are you saying that you can perform a mock build and not get these odd characters? Or is it perhaps due to some difference between your system and what's in the F10/F11 repos? No, not mock build - just local build on my machine (based on FC-6. many things from rawhide) - so too many differences from mock/koji build. Will try to check what's wrong ... Sorry for few weeks delay... Issue seems to be caused by DOCBOOK_XSL_172=YesPlease ... without that variable defined, xmlto builds git-reset manpage without troubles. Otherwise Callout multibyte replacement in manpage-1.72.xsl (which is used instead of callouts.xsl in the case that DOCBOOK_XSL_172 is defined. Could you please which minor manpage issues were fixed by defining that DOCBOOK_XSL_172 variable when we have 1.74.3 now ? IMHO those issues should be fixed other way. Thanks for looking at this Ondrej. The issue fixed by using the DOCBOOK_XSL_172 definition is described at http://article.gmane.org/gmane.comp.version-control.git/105589. The summary: For example, in git-diff.1, without DOCBOOK_XSL_172, I see: .ft C $ git diff (1) $ git diff --cached (2) $ git diff HEAD (3) .ft With DOCBOOK_XSL_172, I get this: $ git diff ▓fB(3)▓fR $ git diff --cached ▓fB(2)▓fR $ git diff HEAD ▓fB(3)▓fR This just came up on the git list again today, with Chris Johnsen sending a patch series which aims to fix things up a bit. Perhaps that thread and patch series will make more sense to you than it does to me? :) http://thread.gmane.org/gmane.comp.version-control.git/114417 If you have a chance to look at that and see if it might help fix these issues, it would be most appreciated. Thanks again for taking a look. Let me know if I can help dig up any other pointers to help you out. I guess there was already discussion about those .ft in manpage upstream - see http://thread.gmane.org/gmane.comp.version-control.git/56147/focus=56153 or http://kerneltrap.org/mailarchive/git/2007/7/19/252065/thread Generally - with docbook-style-xsl >= 1.72 you'll get \&.ft instead of having just .ft ... Something like sed -i s/\&\.ft/\.ft/g <manpage> for every manpage after build should workaround the .ft problem better way than defining DOCBOOK_XSL_172 . I know it's silly, but it's quickest ;) Thanks again Ondrej. I added a simple sed to workaround the .ft issue and dropped the DOCBOOK_XSL_172 usage until a better solution is found. I've yet to look at the patch series that Chris Johnsen worked on. It's possible that may help eventually. I've built git-1.6.2.2-1.fc11 for rawhide. If anyone notices these man page issues still or if undefining DOCBOOK_XSL_172 has caused other problems please speak up. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I believe this is reasonably fixed in git-1.6.2.2-1.fc11, with an even cleaner upstream fix enabled in the rawhide 1.6.3.x packages. Feel free to re-open this is problems persist. |