lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] file://localhost/usr/share/doc/packages/lynx/lynx_help/ly


From: Krzysztof Żelechowski
Subject: Re: [Lynx-dev] file://localhost/usr/share/doc/packages/lynx/lynx_help/lynx-dev.html
Date: Sun, 27 Nov 2011 18:22:02 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Firefox/7.0.1 SeaMonkey/2.4.1

Użytkownik Thomas Dickey napisał:
On Sat, Nov 26, 2011 at 01:40:38AM +0100, Krzysztof ??elechowski wrote:
U??ytkownik Thomas Dickey napisa??:
However, you may be specifically referring to the part of the url that
has the version number (because that corresponds to a directory name).
I suppose if you're attempting to review old configuration details, it
can be a nuisance trying to use the "release" url.  I added a symbolic
link to smooth that out.
Actually, a "Moved permanently" redirect would be more appropriate, but
otherwise works as prescribed, thanks a lot.
ok.

The issue with ".bz2" also depends on whether support for
bzip2 is compiled in, or configured with an external program - or neither.
For instance, it works "here".

Chris

___
[1]<URL: file:///usr/share/doc/packages/lynx/lynx_help/lynx_help_main.html>
2.8.6 is the previous release (October 2006).

[2]<URL: http://lynx.isc.org/release/lynx2-8-6/lynx_help/cattoc.html>
2.8.7 is current (July 2009).
This url works:

    [2]<URL: http://lynx.isc.org/release/lynx2-8-7/lynx_help/cattoc.html>
But the problem is, the URL with 8-6 is installed in the local
documentation for v2.8.7. The documentation on line has a relative URL
there so it does not matter.
That was in the initial tarball, but I see that I fixed it later
(in the rel.2 patch).  Patches are in
        http://lynx.isc.org/release/patches/

The current tarballs in
        http://lynx.isc.org/release

have the rel.2 patch.  Did I overlook something on lynx.isc.org, or are
you using the initial tarball?

You tell me. The tarball name is the same and the build service does not offer MD5. I cannot open a bug saying "Hey you have got the wrong tarball" because I have no way to prove it. Since a workaround has been implemented on server and a fix has been (sneakily) deployed upstream, I do not think the problem is worth fixing.

Thanks,
Chris

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.xiV4ai
+ umask 022
+ cd /usr/src/packages/BUILD
+ cd /usr/src/packages/BUILD
+ rm -rf lynx2-8-7
+ /usr/bin/bzip2 -dc /usr/src/packages/SOURCES/lynx2.8.7.tar.bz2
+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd lynx2-8-7
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #100 (lynx-2.8.5.dif):'
Patch #100 (lynx-2.8.5.dif):
+ /bin/cat /usr/src/packages/SOURCES/lynx-2.8.5.dif
+ /usr/bin/patch -s -p1 --fuzz=0
+ echo 'Patch #101 (lynx-2.8.5-charset.patch):'
Patch #101 (lynx-2.8.5-charset.patch):
+ /bin/cat /usr/src/packages/SOURCES/lynx-2.8.5-charset.patch
+ /usr/bin/patch -s -p0 --fuzz=0
+ echo 'Patch #102 (lynx-2.8.7-enable_xli.patch):'
Patch #102 (lynx-2.8.7-enable_xli.patch):
+ /bin/cat /usr/src/packages/SOURCES/lynx-2.8.7-enable_xli.patch
+ /usr/bin/patch -s -p1 --fuzz=0
+ echo 'Patch #103 (lynx-no-build-date.patch):'
Patch #103 (lynx-no-build-date.patch):
+ /bin/cat /usr/src/packages/SOURCES/lynx-no-build-date.patch
+ /usr/bin/patch -s -p0 --fuzz=0
+ exit 0




reply via email to

[Prev in Thread] Current Thread [Next in Thread]