Hide Forgot
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.
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.
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...
Anyway - moving back - this is not the issue of docbook stylesheets.
Hmm, I use xsltproc instead of xmlto. Tentatively reassigning to xsltproc then.
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
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...
RHEL-6 package NVR is docbook-style-xsl-1.75.2-6.el6 ...
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...
Should be fixed by docbook-style-xsl-1.76.1-3.fc17 ... closing RAWHIDE.
Ah okay, I was afraid of a possible brokeness in the EXSLT extensions, thanks for chasing the issue :-) Daniel
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.
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.
(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 :(
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
(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.
Ok, thanks, closing RAWHIDE again...