[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22543: 404 in Manualpage
From: |
Nils Gillmann |
Subject: |
bug#22543: 404 in Manualpage |
Date: |
Tue, 16 Feb 2016 10:56:05 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Leo Famulari <address@hidden> writes:
> On Wed, Feb 03, 2016 at 02:41:04PM +0100, Nils Gillmann wrote:
>> The manual page
>> https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements
>>
>> contains a link to
>>
>> https://www.gnu.org/software/guix/manual/gnutls-guile/Guile-Preparations.html#Guile-Preparations
>>
>> which give a 404. I am not familiar with what's supposed to be there, a
>> quick search for "gnutls-guile/Guile-Preparations.html" in duckduckgo gives
>> me
>> http://www.gnutls.org/manual/gnutls-guile/Guile-Preparations.html as one
>> of 2 results.
>>
>> Should I fix the link to this one and send in a patch?
>
> Yes, please!
So you think I should (and can?) fix it, while alex replies:
>> I don't think you can send a patch for this. According to
>> <https://www.gnu.org/software/guix/manual/>:
>>
>> (This page generated by the gendocs.sh¹ script.)
>> This "gendocs.sh" uses "texi2html" to convert our texinfo documentation
>> (see "doc/guix.texi" in the guix git repo) to the html page. In
>> "guix.texi" the link you are talking about is a usual link to the
>> "gnutls-guile" manual. I didn't look at "texi2html" but I believe by
>> default it just assumes that all the manuals are placed at
>> "www.gnu.org/software/<package>/manual/", so for "external" manuals the
>> generated links are false. For example, there are also wrong links to
>> Geiser and Magit-Popup manuals.
>>
>> So I think it's a general thing for all generated manuals that are
>> placed on "gnu.org".
>>
>> ¹ http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/gendocs.sh
>>
>> --
>> Alex
Okay, so I guess it's related to #22651 and it#s not fixable the
way I want to (edit the source), or at least what I would want to
do is not optimal and it should be fixed in some other way.
Didn't look into it yet, but should we follow #22651 for the 404s?
--
ng