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.
