Just run xsltproc verbose autobuild sstem and normal system ... the logs differs:

@@ -108077,10 +107772,9 @@
 Handling xsl:with-param content
 Building variable content
 Evaluating variable 'content'
-xsltValueOf: select concat('.so man', $section, '/')
-Lookup variable 'section'
-xsltCopyTextString: copy text .so man8/
-xsltValueOf: result '.so man8/'
+xsltValueOf: select '.so '
+xsltCopyTextString: copy text .so 
+xsltValueOf: result '.so '
 call-template: name make.adjusted.man.filename
 Handling xsl:with-param name
         select $first.refname
[...]
@@ -108268,7 +107965,7 @@
 Lookup variable 'content'
 Object is an XSLT value tree :
 1  TEXT
-    content=.so man8/systemd-vconsole-setup.service....
+    content=.so systemd-vconsole-setup.service.8 
 applying xsl:template 'write.chunk'
 xsltIf: test $quiet = 0
 Lookup variable 'quiet'
[...]
@ -108317,9 +108014,9 @@
 xsltCopyOf: select $content
 Lookup variable 'content'
 xsltCopyOf: result is a result tree fragment
-xsltCopyTextString: copy text .so man8/systemd-vconsole-setup.service.8
+xsltCopyTextString: copy text .so systemd-vconsole-setup.service.8
 
-Wrote 42 bytes to man/systemd-vconsole-setup.8
+Wrote 37 bytes to man/systemd-vconsole-setup.8
 freeing dictionary from stylesheet
 call-template returned: name write.chunk
 call-template returned: name write.text.chunk

...

systemd/systemd-207> zgrep SRC/all /work/SRC/INDEX.spec.gz | xargs grep -E 'BuildRequires:[[:blank:]]*libxslt-tools'
/work/SRC/all/tig/tig.spec:BuildRequires:  libxslt-tools
/work/SRC/all/gimp/gimp.spec:BuildRequires:  libxslt-tools
/work/SRC/all/kmod/kmod.spec:BuildRequires:  libxslt-tools
/work/SRC/all/po4a/po4a.spec:BuildRequires:  libxslt-tools
/work/SRC/all/sssd/sssd.spec:BuildRequires:  libxslt-tools
/work/SRC/all/boost/boost.spec:BuildRequires:  libxslt-tools
/work/SRC/all/crmsh/crmsh.spec:BuildRequires:  libxslt-tools
/work/SRC/all/fvwm2/fvwm2.spec:BuildRequires:  libxslt-tools
/work/SRC/all/java-1_7_0-openjdk/java-1_7_0-openjdk.spec:BuildRequires:  libxslt-tools
/work/SRC/all/ninja/ninja.spec:BuildRequires:  libxslt-tools
/work/SRC/all/samba/samba.spec:BuildRequires:  libxslt-tools
/work/SRC/all/xmlto/xmlto.spec:BuildRequires:  libxslt-tools
/work/SRC/all/libxslt/libxslt-python.spec:BuildRequires:  libxslt-tools
/work/SRC/all/systemd/systemd.spec:BuildRequires:  libxslt-tools
/work/SRC/all/systemd/systemd-mini.spec:BuildRequires:  libxslt-tools
/work/SRC/all/liblqr/liblqr.spec:BuildRequires:  libxslt-tools
/work/SRC/all/twilio-utils/twilio-utils.spec:BuildRequires:  libxslt-tools
/work/SRC/all/DELETED/libcmis/libcmis.spec:BuildRequires:  libxslt-tools

...

Pam is also affected by broken ROFF links ... I'm not sure if xsltproc was used to produce the manual pages

noether:/ # zcat /usr/share/man/man8/pam.8.gz
.so PAM.8
noether:/ # zcat /usr/share/man/man5/pam.d.5.gz 
.so pam.conf.5

I doubt this is libxslt issue. Looking on the stylesheet, the make.adjusted.man.filename does except param section, which is evaluated to empty file. This is defined in manpages/docbook.xsl as 

<xsl:with-param name="section" select="$refentry.metadata/section"/>

but no element section does exists in systemd-vconsole-setup.service.xml, so it is evaluated as empty. However as per comment#1, the section is evaluated well in "normal" system.

@werner, can you share details about your system? Versions of libxslt-tools, docbook and docbook-xsl-stylesheets and the output of 

/usr/bin/xsltproc --verbose -o man/systemd-vconsole-setup.service.8 --nonet --stringparam man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam man.authors.section.enabled 0 --stringparam man.copyright.section.enabled 0 --stringparam systemd.version 207 --path './man:./man'  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl  man/systemd-vconsole-setup.service.xml

on a system, where output is correct would be useful.

(In reply to comment #4)

I'm talking about openSUSE:Factory as well as about openSUSE:13.1 and also on openSUSE:12.3 (just seen) .... the check for the correct ROFF link was done on an old openSUSE:12.1.

Created attachment 561468 [details]
log.12.1

Here the log on 12.1 done with

 systemd/systemd-207> /usr/bin/xsltproc --verbose -o man/systemd-vconsole-setup.service.8 --nonet --stringparam man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam man.authors.section.enabled 0 --stringparam man.copyright.section.enabled 0 --stringparam systemd.version 207 --path './man:./man' http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl man/systemd-vconsole-setup.service.xml > log 2>&1

On the 12.1 there is only docbook-xsl-stylesheets with

 systemd/systemd-207> rpm -q libxslt-tools docbook docbook-xsl-stylesheets
 package libxslt-tools is not installed
 package docbook is not installed
 docbook-xsl-stylesheets-1.76.2.1.75.2-9.3.1.noarch
 systemd/systemd-207> rpm -qf /usr/bin/xsltproc
 libxslt1-1.1.26-15.8.1.x86_64

... quite old but working.  I'm only wondering that the original source includes the correct ROFF link and I guess that Lennart is also using libxslt but on a Fedora based system using a modern version of xsltproc, docbook, libxslt-tools and docbook-xsl-stylesheets.

It works fine on my 13.1 Beta1 machine when I use docbook-xsl-stylesheets package from 12.1 (1.76.2.1.75.2-9.3.1.noarch)

So I assume the problem lies within that package.
Reassigning to docbook-xsl-stylesheets maintainer.

Have you tried the parameter $man.output.in.separate.dir? If you set it to 1 I'll get the following:

$ /usr/bin/xsltproc -o Foo/systemd-vconsole-setup.service.8 --nonet --param man.output.in.separate.dir 1 --stringparam funcsynopsis.style ansi --stringparam man.authors.section.enabled 0 --stringparam man.copyright.section.enabled 0 --stringparam systemd.version 207 --path './man:./man' $DB/manpages/docbook.xsl   man/systemd-vconsole-setup.service.xml

$ cat Foo/man/man8/systemd-vconsole-setup.8
.so man/man8/systemd-vconsole-setup.service.8


If you don't like the additional "man/" directory before "man8/", suppress it with the parameter $man.output.base.dir setting it to an empty string:

$ /usr/bin/xsltproc -o Foo2/systemd-vconsole-setup.service.8 --nonet --stringparam man.output.base.dir "" --param man.output.in.separate.dir 1 --stringparam funcsynopsis.style ansi --stringparam man.authors.section.enabled 0 --stringparam man.copyright.section.enabled 0 --stringparam systemd.version 207 --path './man:./man' $DB/manpages/docbook.xsl   man/systemd-vconsole-setup.service.xml

$ cat Foo2/man8/systemd-vconsole-setup.8 
.so man8/systemd-vconsole-setup.service.8

The following link contains the description of the above parameters:
http://docbook.sourceforge.net/release/xsl/current/doc/manpages/output.html


Is this what you want?

(In reply to comment #9)

I've added the patch

 | xsltproc use wrong ROFF links due broken defaults of docbook!
 | --- systemd-208/man/custom-man.xsl
 | +++ systemd-208/man/custom-man.xsl      2013-10-21 08:47:21.094236027 +0000
 | @@ -61,4 +61,9 @@
 |    <xsl:text>"</xsl:text>
 |  </xsl:template>
 |  
 | +<xsl:param name="man.output.in.separate.dir" select="1">
 | +</xsl:param>
 | +<xsl:param name="man.output.base.dir">
 | +</xsl:param>
 | +
 |  </xsl:stylesheet>

and it works.  Nevertheless, why is this not the default?  Why I've to patch systemd sources?  And why this has not been checked out before we run into release candidate for a final product?

I insist on making the settings used in the patch to become the default for all
SUSE/openSUSE packages.

It seems that newlines may cause error messages

  [  124s]   XSLT     man/telinit.8
  [  124s] compilation error: file ./man/custom-man.xsl line 64 element param
  [  124s] XSLT-param: The content should be empty since the attribute 'select' 

changed the code to

  <xsl:param name="man.output.in.separate.dir" select="1"></xsl:param>
  <xsl:param name="man.output.base.dir"></xsl:param>

...

This is an autogenerated message for OBS integration:
This bug (842844) was mentioned in
https://build.opensuse.org/request/show/204107 Factory / systemd

(In reply to comment #10)
>
> Nevertheless, why is this not the default? 

I don't know. Ask the developer of the manpage stylesheets. Perhaps they thought it would be a good default. 


> Why I've to patch systemd sources?  

You never ever have to patch the systemd XML files! You just add an additional parameter or use xsl:param in your customization layer, that's all.


> I insist on making the settings used in the patch to become the default for all SUSE/openSUSE packages.

Do you mean really to patch the original DocBook stylesheet package? In that case I have to disagree for the following reasons:

1. It's a bad idea to change the default behaviour of the DocBook stylesheets. People expect(!) that the stylesheets behave exactly like this.
2. If you don't like the default, it is really easy to change it through parameters or a customization layer (which you have already). This is just a small and easy change in your xsltproc call.
3. If you still disagree, discuss your idea on the docbook-apps mailinglist.




(In reply to comment #11)
> It seems that newlines may cause error messages
> 
>   [  124s]   XSLT     man/telinit.8
>   [  124s] compilation error: file ./man/custom-man.xsl line 64 element param
>   [  124s] XSLT-param: The content should be empty since the attribute 'select' 
> 
> changed the code to
> 
>   <xsl:param name="man.output.in.separate.dir" select="1"></xsl:param>
>   <xsl:param name="man.output.base.dir"></xsl:param>
> 
> ...

Right. Newlines are just text. It is also possible to write 

  <xsl:param name="man.output.base.dir"/>

or

  <xsl:param name="man.output.base.dir" select="''"/>

It's all the same (meaning an empty string).


As a patch is generated, I'm setting this bug to resolved/fixed.

(In reply to comment #13)

> > Why I've to patch systemd sources?  
> 
> You never ever have to patch the systemd XML files! You just add an additional
> parameter or use xsl:param in your customization layer, that's all.

I'd like to patch/change exactly one location.  And I prefere to avoid patching.
Beside this: what does `customization layer' mean and why I have to use it?

Please do not close this bug as fixed as it is *not* fixed (IMHO) ... the patch is a workaround!  IMHO the package DocBook stylesheet package has to fixed or enhanced to fit the requirements of the openSUSE/SUSE policy.  Otherwise every package maintainer has to change/work around the upstream defaults of the DocBook stylesheet package.

Just to remember; systemd is not the only package affected by the upstream defaults of the DocBook stylesheet package, I'm aware of at least pam ... and maybe there are also others which are currently not reported.

If you really do not want to add a distribution customization layer then please add a rpmlint check to avoid broken manual pages.

(In reply to comment #14)
> (In reply to comment #13)
> 
> > > Why I've to patch systemd sources?  
> > 
> > You never ever have to patch the systemd XML files! You just add an additional
> > parameter or use xsl:param in your customization layer, that's all.
> 
> I'd like to patch/change exactly one location.  And I prefere to avoid
> patching.
> Beside this: what does `customization layer' mean and why I have to use it?

Oh sorry, I better should explain this:
Basically, a "customization layer" is just another XSLT file. It imports the original DocBook stylesheets and contains parameters and template. These parameters and templates overwrite the original ones.

After the debugging session with Werner (thanks!) we've found the following hints:

1. The openSUSE releases contained the following versions:
   openSUSE 11.3: docbook-xsl-1.75.2
   openSUSE 12.1: docbook-xsl-1.76.1
   openSUSE 12.2: docbook-xsl-1.77.1
   openSUSE 12.3: docbook-xsl-1.77.1
   openSUSE 13.1: docbook-xsl-1.78.1

2. Between 1.75.2 and 1.76.1, there was the following upstream change added:

--- /tmp/docbook-xsl-1.75.2/manpages/other.xsl  2009-02-19 19:26:36.000000000 +0100
+++ /tmp/docbook-xsl-1.76.1/manpages/other.xsl  2013-10-21 09:53:07.719215407 +0200
@@ -595,10 +606,11 @@
           <xsl:with-param name="message-prolog">Note: </xsl:with-param>
           <xsl:with-param name="message-epilog"> (soelim stub)</xsl:with-param>
           <xsl:with-param name="content">
-            <xsl:value-of select="concat('.so man', $section, '/')"/>
+            <xsl:value-of select="'.so '"/>


The "manX" directory part is hard-coded in 1.75.1. This has been changed in 1.76.1, but is now "hided" under the $man.output.in.separate.dir parameter.

3. RedHat contains a patch which just alters the ROFF links, see here
http://pkgs.fedoraproject.org/cgit/docbook-style-xsl.git/tree/docbook-xsl-mandir.patch

4. Toms will write a mail to the docbook-apps mailinglist, suggesting to incorporate the patch from point 3.

JFYI:
I've found a similar/related bug in the DocBook bug tracker:

#1313 soelim stubs broken due to containing full path
https://sourceforge.net/p/docbook/bugs/1313/

(In reply to comment #16)
> [...] 
> 4. Toms will write a mail to the docbook-apps mailinglist, suggesting to
> incorporate the patch from point 3.

https://lists.oasis-open.org/archives/docbook-apps/201310/msg00074.html

Just a quick note:
Revision #9847 of the DocBook SVN repository fixed the above problem.

TODO: Add the above patch into our package.

References:
http://sourceforge.net/p/docbook/code/9847
http://sourceforge.net/p/docbook/bugs/1313/

This is an autogenerated message for OBS integration:
This bug (842844) was mentioned in
https://build.opensuse.org/request/show/221574 Factory / docbook-xsl-stylesheets

@Werner:
Would you be so kind to test the new package so we can close this bug?

Thanks!

@Thomas: after rebuilding systemd for Factory without applying Werner's patch, I'm still getting the ROFF link without the 'man8/' prefix (but I'm not sure the link is really incorrect in this case, maybe the default man search path wasn't configured to automatically search in man[1-8]/ dirs  ?)

However on opensuse 13.2, with:

docbook-xsl-stylesheets-1.78.1+svn9743-3.7.1.noarch
man-2.6.6-3.1.7.x86_64

everything seems to work fine even if I'm using the "wrong" ROFF link:

$ cd /usr/share/man/man8
$ zcat systemd-vconsole-setup.8.gz
.so man8/systemd-vconsole-setup.service.8
$ rm systemd-vconsole-setup.8.gz
$ man systemd-vconsole-setup
No manual entry for systemd-vconsole-setup
$ cat >systemd-vconsole-setup.8
.so systemd-vconsole-setup.service.8
$ cd ~
$ man systemd-vconsole-setup
< works as expected >

(this still fails on 13.1)

So the initial issue is gone on 13.2 even if the ROFF links weren't fixed. But I'm not sure if that's due to your patch or some others changes...
                                         
If anyone could clarify, that would be great.

Thanks

(In reply to Franck Bui from comment #23)

Normally `man' uses /usr/share/man or /usr/share/man/<locale>/ to search for files.  That is that a `.so' link should always include the man section subdirectory.  Or you have a special MANPATH environment variable set and/or some changes in /etc/manpath.config.

(In reply to Dr. Werner Fink from comment #24)
> 
> Normally `man' uses /usr/share/man or /usr/share/man/<locale>/ to search for
> files.  That is that a `.so' link should always include the man section
> subdirectory.  Or you have a special MANPATH environment variable set and/or
> some changes in /etc/manpath.config.

I'm using the default configuration file (/etc/manpath.config) without any modifications of my own. Default value of MANPATH:

$ echo $MANPATH
/usr/local/man:/usr/share/man

I'm pretty sure I haven't done any customisation in this area, at least intentionally.

IMHO this bug has become an optical issue ... and yes it can be closed

(In reply to Dr. Werner Fink from comment #26)
> 
>   * man-db 2.6.0 arranged to search the full manpath when expanding
>     .so directives in manual pages (so that ".so name.1" works as well
>     as ".so man1/name.1"), but this incorrectly did not take effect
>     for manual pages that consist only of a .so directive.  This is
>     now fixed.
> 
> ... this is *new* as former the man had never done this ;)

Indeed, but the changelog seems to say that this change is a fix rather than an improvement.

If so, maybe we should backport it (when needed).

As a side effect, it should be safe to drop the workaround you did for systemd, at least for 13.2 and factory, now. Specially since it makes the build failing from a clean repo (with no generated files).

Also I still don't see the effect of the patch that Thomas included in docbook-xsl-stylesheets.

(In reply to Dr. Werner Fink from comment #27)

Hmm ... it was common[1] to use the .so links as

  .so man<section>/<page>

no idea why a common and a well known behaviour has become a ``bug'' now which had to be ``fixed'' in the viewer instead in the manual page its self.  Interesting this new behaviour seems to be caused by the GNOME people.

[1] I know this fact more than 20 years ;)

(In reply to Dr. Werner Fink from comment #29)
> 
> Hmm ... it was common[1] to use the .so links as
> 
>   .so man<section>/<page>
> 
> no idea why a common and a well known behaviour has become a ``bug'' now
> which had to be ``fixed'' in the viewer instead in the manual page its self.

Hmm I don't think the fix made '.so man<section>/<page>' a bug. It has always worked and is still supported by the viewer.

I think the fix was for man pages which consists of a *single* .so directive '.so <page>' in which case the path wasn't expanded correctly by the viewer.

This is an autogenerated message for OBS integration:
This bug (842844) was mentioned in
https://build.opensuse.org/request/show/328764 Factory / systemd

This is an autogenerated message for OBS integration:
This bug (842844) was mentioned in
https://build.opensuse.org/request/show/329511 Factory / systemd

This is an autogenerated message for OBS integration:
This bug (842844) was mentioned in
https://build.opensuse.org/request/show/333777 Factory / systemd