multipath keyword links to configuration table are all dead

Bug #1022571 reported by Peter Petrakis
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Server Guide
New
Undecided
Unassigned

Bug Description

All references the the keyword definition table appear to have been cleared.

For example:

https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-config-file.html#attribute-user_friendly_names

Should instead be pointing the corresponding entry.

https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-config-file.html#multipath-config-defaults-table

Instead it goes nowhere, this is true of every keyword that still has a hyperlink, they're dead ends.

This all worked when the docs were originally submitted. I fear that the conversion to PDF might have
compromised these links.
Edit: No, this has nothing to do with PDF. It is related to the "NEW" theme, the "OLD" theme works fine for this issue.

summary: - multipath guide links to main table are all dead
+ multipath keyword links to configuration table are all dead
Revision history for this message
bab188d (bkhosi) wrote : Re: [Bug 1022571] Re: multipath keyword links to configuration table are all dead

UNSUBSCRIBE

2012/7/9, Peter Petrakis <email address hidden>:
> ** Summary changed:
>
> - multipath guide links to main table are all dead
> + multipath keyword links to configuration table are all dead
>
> --
> You received this bug notification because you are subscribed to ubuntu-
> docs in Ubuntu.
> https://bugs.launchpad.net/bugs/1022571
>
> Title:
> multipath keyword links to configuration table are all dead
>
> Status in “ubuntu-docs” package in Ubuntu:
> New
>
> Bug description:
> All references the the keyword definition table appear to have been
> cleared.
>
> For example:
>
> https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-
> config-file.html#attribute-user_friendly_names
>
> Should instead be pointing the corresponding entry.
>
> https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-
> config-file.html#multipath-config-defaults-table
>
> Instead it goes nowhere, this is true of every keyword that still has
> a hyperlink, they're dead ends.
>
> This all worked when the docs were originally submitted. I fear that the
> conversion to PDF might have
> compromised these links.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1022571/+subscriptions
>

Revision history for this message
bab188d (bkhosi) wrote : Re: [Bug 1022571] [NEW] multipath guide links to main table are all dead

UNSUBSCRIBE

2012/7/9, Peter Petrakis <email address hidden>:
> Public bug reported:
>
> All references the the keyword definition table appear to have been
> cleared.
>
> For example:
>
> https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-config-
> file.html#attribute-user_friendly_names
>
> Should instead be pointing the corresponding entry.
>
> https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-config-
> file.html#multipath-config-defaults-table
>
> Instead it goes nowhere, this is true of every keyword that still has a
> hyperlink, they're dead ends.
>
> This all worked when the docs were originally submitted. I fear that the
> conversion to PDF might have
> compromised these links.
>
> ** Affects: ubuntu-docs (Ubuntu)
> Importance: Undecided
> Status: New
>
>
> ** Tags: precise ubuntu-serverguide
>
> --
> You received this bug notification because you are subscribed to ubuntu-
> docs in Ubuntu.
> https://bugs.launchpad.net/bugs/1022571
>
> Title:
> multipath guide links to main table are all dead
>
> Status in “ubuntu-docs” package in Ubuntu:
> New
>
> Bug description:
> All references the the keyword definition table appear to have been
> cleared.
>
> For example:
>
> https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-
> config-file.html#attribute-user_friendly_names
>
> Should instead be pointing the corresponding entry.
>
> https://help.ubuntu.com/12.04/serverguide/multipath-dm-multipath-
> config-file.html#multipath-config-defaults-table
>
> Instead it goes nowhere, this is true of every keyword that still has
> a hyperlink, they're dead ends.
>
> This all worked when the docs were originally submitted. I fear that the
> conversion to PDF might have
> compromised these links.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1022571/+subscriptions
>

Revision history for this message
Peter Matulis (petermatulis) wrote :

I am not certain of what's broken. Assigning this to Doug as he did a lot of work on the PDF version that may have resulted in the purported breakage.

affects: ubuntu-docs (Ubuntu) → serverguide
Changed in serverguide:
assignee: nobody → Doug Smythies (dsmythies)
importance: Undecided → Low
importance: Low → Undecided
Revision history for this message
Doug Smythies (dsmythies) wrote :

First, try to understand what is the problem, as it is not clear to me from the description.

In the source file dm-multipath.xml, find an example of what it might be:

 <para>Each multipath device has a World Wide Identifier (WWID), which is
      guaranteed to be globally unique and unchanging. By default, the name of
      a multipath device is set to its WWID. Alternately, you can set the
      <emphasis role="bold"><link
      linkend="attribute-user_friendly_names">user_friendly_names</link>
      </emphasis>option in the multipath configuration file, which causes
      DM-Multipath to use a node-unique alias of the form <emphasis

So for this link, go to my very first "compile" of the serverguide that included the new dm-multipath path stuff.
(My Reference: doug@s15:~/sguide-1204/serverguide-review-12-3-old01 (2012.03.21))
In the resulting HTML file that link does indeed go to the appropriate line on the Multipath Configuration Defaults table.

Now, go to my last "compile" of the serverguide, which is after the various edits to dm-multipath.
(My reference: doug@s15:~/sguide-1204/serverguide-footnote (2012.04.03))
In the resulting HTML file that link does indeed go to the appropriate line on the Multipath Configuration Defaults table.

Now, go to the current on-line HTML version of the serverguide. And note/recall the massive changes that were made between our work and what was eventually released, not to the source code but in what it compiles into.
O.K. now the link does not work as expected.

I also had a test "compile" of the new method from 2012.04.26. The link did not work for that HTML either. The source files, multipath-config-defaults-table.xml, were identical.

Conclusion: This issue is not related to the actual source code, but rather the new conversion ("compile") process.

other possibly helpful information:

HTML code for the source of the link for all of the examples is O.K.

The difference is in the resulting HTML for the link destination:

The old way, results in:

        <code class="literal">0</code>.</p></td>
                        </tr>
                        <tr>
                          <td align="left"><a id="attribute-user_friendly_names"></a>
          <span class="bold"><strong>user_friendly_names</strong></span>
        </td>

The new way, result in:
Note the missing id= :

<td style="text-align: left;" class="td-colsep td-rowsep">
          <span class="em em-bold emphasis">user_friendly_names</span>
        </td>

Revision history for this message
Doug Smythies (dsmythies) wrote :

By the way those same links work just fine in the resulting PDF document.

Revision history for this message
Doug Smythies (dsmythies) wrote :

I looked at this a bit more. The attachment largely repeats an earlier posting, while I tried to isolate the differences between the old way and the new way to compile the serverguide.

I also edited yelp-build to add the --verbose switch to the xsltproc call. Oh my goodness, it went from no information during the compile to 102 megabytes of crap.
As an aside, there are inefficiencies in the compile, such as creating yelp.js and en.css 114 times, once for each resulting html file. It just makes it hard to follow what is going on is all.

I'll add another attachment in a minute, with a larger extract from the verbose stuff, which I'm not even sure is from the correct area. It appears as though xsltproc does realize that, for example, an entry id for attribute-user_friendly_names is desired. However, it just doesn't create the anchor and the name. The "copy text" part is blank.

In general I find this stuff extremely difficult to follow, and I have no clue how to proceed further. I will probably un-assign myself this bug.

Revision history for this message
Doug Smythies (dsmythies) wrote :

The attachment is my best guess at the problem related area of verbose output from xsltproc

Changed in serverguide:
assignee: Doug Smythies (dsmythies) → nobody
description: updated
Revision history for this message
Peter Petrakis (peter-petrakis) wrote :

That's great work Doug! The theme was switched out at the last minute and no one gave
it a thought that it might cause a regression. The next logical step would be to diff the
themes and engage the theme writers themselves. Who's the resident Docbook XML
genius? We likely have a fundamental problem in the XSL that is being aggravated by
the theme change. If we can bisect the theme change to where everything begins to
break, we can probably xref that to the corresponding XSL which is really causing
the trouble.

Revision history for this message
Doug Smythies (dsmythies) wrote :

I forgot to mention that I already looked at /libs/ubuntu-html-chunk-cust.xsl (the "old" file) and /libs/ubuntu.xsl (the "new" file). They are so completley different that I didn't know how to proceed to isolate the differences with reguard to this problem report.
I would have singled out the "xsltProcessOneNode: no template found for text" line in the excerpt posting above as a key line, except that there are 18037 occurances of that line during a verbose serverguide compile.

I don't know who we need help from, but perhaps Matthew East.

Revision history for this message
Doug Smythies (dsmythies) wrote :

I thought to compare verbose output from compiling the "old" way. However that generated 790 megabytes of crap. The output is very different than the "new" way anyhow.
I think, but am not sure, that we would expect to see these lines in the excerpt from verbose run posted above:

applying xsl:template 'db2html.anchor'
call-template returned: name db2html.anchor
call-template: name db2html.anchor

but it is not there.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.