Bug 727251

Summary: systemd documentation references cause man to complain
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: docbook-style-xslAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: harald, johannbg, kay, kdudka, lpoetter, metherid, mschmidt, notting, ovasik, plautrba, sgallagh, veillard
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-06 17:59:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Michal Jaegermann 2011-08-01 16:42:15 UTC
Description of problem:

The following series of commands has the following effects:

$ man -w init
man: can't open /usr/share/man/systemd.1: No such file or directory
/usr/share/man/man1/systemd.1.gz
$ man -w sd_is_socket
man: can't open /usr/share/man/sd_is_fifo.3: No such file or directory
/usr/share/man/man3/sd_is_fifo.3.gz
$ man -w sd_is_socket_inet
man: can't open /usr/share/man/sd_is_fifo.3: No such file or directory
/usr/share/man/man3/sd_is_fifo.3.gz
$ man -w sd_is_socket_unix
man: can't open /usr/share/man/sd_is_fifo.3: No such file or directory
/usr/share/man/man3/sd_is_fifo.3.gz
$ man -w sd_notifyf
man: can't open /usr/share/man/sd_notify.3: No such file or directory
/usr/share/man/man3/sd_notify.3.gz
$ man -w poweroff
man: can't open /usr/share/man/halt.8: No such file or directory
/usr/share/man/man8/halt.8.gz
$ man -w reboot
man: can't open /usr/share/man/halt.8: No such file or directory
/usr/share/man/man8/halt.8.gz

The issue is that there is '.so systemd.1' in /usr/share/man/man1/init.1.gz while '.so man1/systemd.1' is really expected and similar in other cases.

It looks that the current 'man' is "smart" enough to recover from that but this is causing, at least, some indigestion in 'mandb' as well (of "bad symlink or ROFF `.so' request" kind).  One needs to run mandb without '--quiet' and usually force caches regeneration to see complaints.

Version-Release number of selected component (if applicable):
systemd-30-1.fc16

Additional info:
Yes, 'mandb' has complaints about some other manpages too.

Comment 1 Lennart Poettering 2011-08-02 00:16:07 UTC
Hmm, these are the docbook xslt stylesheets producing this output. We just  If this is not correct, then this should be fixed there.

We simply use <refname>....</refname> to create these alias files, and if the generated files are invalid, then the stylesheets should be fixed.

Comment 2 Ondrej Vasik 2011-08-25 15:48:03 UTC
Well... I don't think the issue is in docbook stylesheets ...

I checked out your sources and tried to rebuild the manpage manually with properly set docbook...

[Reset@dhcp-24-196 man]$ cat sd_is_socket.3 
.so sd_is_fifo.3
[Reset@dhcp-24-196 man]$ xmlto man sd_is_fifo.xml 
Note: Writing sd_is_fifo.3
Note: Writing sd_is_socket.3 (soelim stub)
Note: Writing sd_is_socket_inet.3 (soelim stub)
Note: Writing sd_is_socket_unix.3 (soelim stub)
Note: Writing sd_is_mq.3 (soelim stub)
[Reset@dhcp-24-196 man]$ cat sd_is_socket.3 
.so man3/sd_is_fifo.3

Lennart, what are you using for generating these manpage links? Probably just wrong tools use...

Comment 3 Ondrej Vasik 2011-08-25 19:37:25 UTC
Anyway - moving back - this is not the issue of docbook stylesheets.

Comment 4 Lennart Poettering 2011-08-29 12:17:10 UTC
Hmm, I use xsltproc instead of xmlto. Tentatively reassigning to xsltproc then.

Comment 5 Daniel Veillard 2011-08-29 12:57:55 UTC
Hard to tell without debugging the docbook stylesheets and how they
interact with the various extensions to XSLT-1.0 specification.
Ondrej if you have the setup could you look at the difference in behaviour.
Note that xmlto used to call xsltproc too (depending what was asked),
so it's really unclear what is going on just from the bug report.

Daniel

Comment 6 Ondrej Vasik 2011-08-29 13:38:20 UTC
Ok, I checked that one more time and it works ok on RHEL-6 (docbook-style-xsl), but seems to be broken in docbook-style-xsl-1.76.1 in Fedora Rawhide...

Moving back to stylesheets, sorry for the noise...

Comment 8 Ondrej Vasik 2011-08-29 13:39:48 UTC
RHEL-6 package NVR is docbook-style-xsl-1.75.2-6.el6 ...

Comment 9 Ondrej Vasik 2011-08-29 13:51:24 UTC
Hmmms, upstream change - http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/xsl/manpages/other.xsl?r1=8841&r2=8865 ... man.output.in.separate.dir in manpages/param.xsl has to be changed by default to 1 to restore previous default behaviour...

Comment 10 Ondrej Vasik 2011-08-29 14:22:39 UTC
Should be fixed by docbook-style-xsl-1.76.1-3.fc17 ... closing RAWHIDE.

Comment 11 Daniel Veillard 2011-08-31 07:47:55 UTC
Ah okay, I was afraid of a possible brokeness in the EXSLT extensions,
thanks for chasing the issue :-)

Daniel

Comment 12 Stephen Gallagher 2011-09-02 19:13:02 UTC
Reopening this bug. This change is completely unacceptable. It breaks generation of manpages (it changes where the output goes).

To use SSSD as an example (whose nightly builds just started breaking because of this change):

With docbook-style-xsl-1.76.1-2.fc15:
/usr/bin/xsltproc -o uk/sss_usermod.8  --catalogs --xinclude --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl uk/sss_usermod.8.xml
produces the file ./uk/sss_usermod.8 (as expected).

With docbook-style-xsl-1.76.1-3.fc15 (trivially rebuilt from docbook-style-xsl.noarch 0:1.76.1-3.fc17 for local testing):
/usr/bin/xsltproc -o uk/sss_usermod.8  --catalogs --xinclude --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl uk/sss_usermod.8.xml
produces the file ./uk/man/man8/sss_usermod.8

This is nowhere near where it belongs. If xsltproc is handed a -o option specifying where the output goes, that needs to remain the same.

Comment 13 Ondrej Vasik 2011-09-03 15:12:15 UTC
Damned ... you are right, Stephen...
If the change of the default parameter is affecting other builds, I have to revert it...
Any idea how to solve it better way? I think the longer "workaround" in the original upstream report ( http://sourceforge.net/tracker/?func=detail&aid=2831602&group_id=21935&atid=373747 ) and reverting the param change should work in both cases.

Comment 14 Stephen Gallagher 2011-09-06 12:05:34 UTC
(In reply to comment #13)
> Damned ... you are right, Stephen...
> If the change of the default parameter is affecting other builds, I have to
> revert it...
> Any idea how to solve it better way? I think the longer "workaround" in the
> original upstream report (
> http://sourceforge.net/tracker/?func=detail&aid=2831602&group_id=21935&atid=373747
> ) and reverting the param change should work in both cases.

Sorry, I don't actually have any insight into this problem. I only know this change broke my build :(

Comment 15 Ondrej Vasik 2011-09-06 15:45:06 UTC
Ok, I tried that on my machine and this should work for both cases correctly - please try docbook-style-xsl-1.76.1-4.fc17 from  http://koji.fedoraproject.org/koji/taskinfo?taskID=3327584

Comment 16 Stephen Gallagher 2011-09-06 15:55:06 UTC
(In reply to comment #15)
> Ok, I tried that on my machine and this should work for both cases correctly -
> please try docbook-style-xsl-1.76.1-4.fc17 from 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3327584

That's working for me.

Comment 17 Ondrej Vasik 2011-09-06 17:59:39 UTC
Ok, thanks, closing RAWHIDE again...