Bugzilla Bug 145739

Okay, no one shoot the bug reporter just yet. If this is assigned to the wrong
component, fine, reassign once you get some more info. :)

I was just alerted by a user who says that none of the 2006.1 docs are viewable
in lynx. Bottom line, it's viewable and navigable in links, firefox, etc., but
not in lynx. It looks like something may have been touched in the xsl or other
backend for gentoo.org, because browsing to *any* handbook-${arch}.xml (the
table of contents), whether networked or networkless, any release, won't let
you browse further. Select a chapter in lynx, and it takes you up to the
"select arch handbook" page *one level up*.

Note that using 

This is confirmed by me; very strange. What's weirder is that
gentoo.org/blah/foo/bar/?chap=2&line=44 *fails* but specifying
g.org/blah/blah/blah.xml?chap=2&line=44 (note the .xml) works fine.

So, what do we have? website backend problem (infra)? obscure docs-team issue
(works in all other browsers, nothing altered for more than 13 hours)? or lynx
parsing bug (exg)?

Needs to be fixed pronto, as all the users who try to browse the new 2006.1
release are going WTF?!? :)

Steps to reproduce:
1. Use lynx (this only has issues with lynx; maybe it can't understand 4.01
transitional?)
2. navigate by browsing or jumping directly to gentoo.org/doc/en/handbook/
3. Choose networked/networkless flavor
4. choose architecture
5. choose viewing style - print, 1 page per, all in 1 page
6. at the table of contents, go down and select a link.
7. hit it and be amazed as you're returned to the page a level up about
selecting arch & viewing style.

It seems that lynx2.8.6dev.18 behaves correctly while lynx2.8.5 does not.
Thomas, do you have any clue on what might be the reason so I can backport the
patch?

A quick check shows me it is one of the bugs fixed in 2.8.6dev.7,
and looking at the changelog

* correct parsing of embedded URLs which have parameters but no path, e.g.,
  base
    http://wj55.org/Minutes.php
  and embedded
    ?date_meeting=2004-08-31
  (Debian #274619, report/analysis by Liam K Morland) -TD

Looking at the patch, I think that the change is limited to the 50-line
diff in WWW/Implementation/Library/HTParse.c - see

http://lynx.isc.org/current/2.8.6dev.7.patch.gz

The XSL changed recently (2006-08-13 19:10:39) to issue links that start with
?... without the file name because using @link (from link="foo.xml" in main
file) is simply unreliable. Write it wrong, or move the files as it happened
when drafting the new books, and navigation & TOC do not work at all.
Sorry it caused you some trouble.

FYI, all handbooks have had plenty of '?part=X&chap=Y' links in their content
for a long time and those have never worked in lynx. No one has ever complained
about that.

FYI

The XSL changed recently (2006-08-13 19:10:39) to issue links that start with
?... without the file name because using @link (from link="foo.xml" in main
file) is simply unreliable. Write it wrong, or move the files as it happened
when drafting the new books, and navigation & TOC do not work at all.
Sorry it caused you some trouble.

FYI, all handbooks have had plenty of '?part=X&chap=Y' links in their content
for a long time and those have never worked in lynx. No one has ever complained
about that.

FYI², upgrading all www nodes to >=gorg-0.6 would give us a reliable file name
passed as a $link param, but we've been waiting for that to happen for a very
long time already.

Solutions (in random order):
1. Use ~ARCH lynx
2. Use another browser
3. Wait until patch is backported to ARCH lynx
4. Wait until lynx-2.8.6 loses its ~
5. Read full handbook

(In reply to comment #0)
> Needs to be fixed pronto, as all the users who try to browse the new 2006.1
> release are going WTF?!? :)

Not 2006.1-specific and you probably meant all users of <lynx-2.8.6. I have no
exact number, but it's somewhere between insignificant and extremely few.

I've backported the fix in lynx-2.8.5-r4.

Xavier -- is the emerge to >=gorg-0.6 a fairly painless one?  If so, I'll take
care of that today/tomorrow.

(In reply to comment #5)
> Xavier -- is the emerge to >=gorg-0.6 a fairly painless one?  If so, I'll take
> care of that today/tomorrow.

I'd like gorg to be bumped to 0.6.2 (bug #137258) to have the same version all
over.
Not required, can be done later, just FYI.
It fixes a minor bug and I know how not to trigger it on www.g.o

I can (and shall) upgrade wren/kiwi/loon as long as gorg's config is not
overwritten by cfengine.

The real problem is bluejay.
As long as one node uses axkit, upgrading gorg on other nodes is pointless.
Bluejay needs to be removed from the rotation and either upgraded to apache2
w/gorg or recycled and replaced by loon.
Once taken out, I don't mind spending some time on bluejay to upgrade it if you
want to keep using it as a www node.

at the risk of hijacking this bug...

how about if I take bluejay out of the rotation, but we leave it as the master
www node.  the stuff that does that doesn't require/depend on apache at all --
it's all cvs, cfengine and rsync.  As long as we don't touch that stuff, we
should be able to remove axkit, upgrade apache, etc.

If that sounds OK to you, I'll yank it from the rotation and, if you don't mind
taking care of the apache/gorg part, we can get this taken care of.

(In reply to comment #7)
> If that sounds OK to you, I'll yank it from the rotation and, if you don't mind
> taking care of the apache/gorg part, we can get this taken care of.

Fine with me.

ok it's pulled.  fire away.

Can I close this bug?

(In reply to comment #10)
> Can I close this bug?

I'll take it. You've done your part in current versions of lynx, now it's my
turn to make it work reliably for old versions. Be patient, it'll take me some
time :)

Web nodes have been upgraded, xsl has been changed to prepend '?...' links with
filename.

Thanks for reporting, and for your patience.