Stale external URL in doc?

On 9 Jul 2020, at 09:12, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:

Hello.

I see the following description in the doc.

https://www.postgresql.org/docs/13/ssl-tcp.html

Intermediate certificates that chain up to existing root certificates
can also appear in the ssl_ca_file file if you wish to avoid storing
them on clients (assuming the root and intermediate certificates were
created with v3_ca extensions). Certificate Revocation List (CRL)
entries are also checked if the parameter ssl_crl_file is set. (See
http://h41379.www4.hpe.com/doc/83final/ba554_90007/ch04s02.html for
diagrams showing SSL certificate usage.)

I follwed the URL above and saw the "Support and other resources" page
of the document "OpeNVMS Systems Documemtation Index page".

Right, it's redirecting there now. The same goes for a link to hpe.com on
https://www.postgresql.org/docs/13/libpq-ssl.html which too is redirected
to a larger documentation set.

FWIW the folloing URL shows "HP Open Source Security for OpenVMS
Volume 2: HP SSL for Open VMS", which seems to be the originally
intended document..

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04622320

The intended document is a page which is more concise and to the point, the
full OpenVMS SSL documentation set doesn't really fit the purpose for this
link.

As a short term fix we should either a) remove these links completely or b)
link to archived copies of the pages on archive.org; or c) find a more
appropriate pages to link to. A quick search didn't turn up anything I would
prefer for (c), and I'm not sure what he legality of linking to a cached copy
is, so I would advocate for (a).

Longer term we should try to incorporate (some of) these diagrams and content
into our own documentation now that we have proper capability for inline
images.

cheers ./daniel

Daniel Gustafsson <daniel@yesql.se> writes:

As a short term fix we should either a) remove these links completely or b)
link to archived copies of the pages on archive.org; or c) find a more
appropriate pages to link to. A quick search didn't turn up anything I would
prefer for (c), and I'm not sure what he legality of linking to a cached copy
is, so I would advocate for (a).

+1. It should have been obvious just from the spelling of this URL that
it wasn't intended to be a long term stable location. Digging in the
git history shows we've already updated it twice, and I wonder how many
changes there were that we didn't notice.

Just reverting bbd3bdba3 seems appropriate to me.

regards, tom lane

On Thu, Jul 9, 2020 at 3:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

As a short term fix we should either a) remove these links completely or

b)

link to archived copies of the pages on archive.org; or c) find a more
appropriate pages to link to. A quick search didn't turn up anything I

would

prefer for (c), and I'm not sure what he legality of linking to a cached

copy

is, so I would advocate for (a).

+1. It should have been obvious just from the spelling of this URL that
it wasn't intended to be a long term stable location. Digging in the
git history shows we've already updated it twice, and I wonder how many
changes there were that we didn't notice.

Just reverting bbd3bdba3 seems appropriate to me.

+1.

If we want to keep a set of such links, probably the wiki is a better place
as more people can easily fix them there.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

On 2020-Jul-09, Magnus Hagander wrote:

If we want to keep a set of such links, probably the wiki is a better place
as more people can easily fix them there.

Or, since our docs have diagram capabilities now, we can make our own
diagram.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Jul 9, 2020 at 6:36 PM Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

On 2020-Jul-09, Magnus Hagander wrote:

If we want to keep a set of such links, probably the wiki is a better

place

as more people can easily fix them there.

Or, since our docs have diagram capabilities now, we can make our own
diagram.

Absolutely. I meant more as a general thing if we want to refer to websites
outside of our control for other things.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

On 9 Jul 2020, at 17:54, Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Jul 9, 2020 at 3:52 PM Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> writes:

As a short term fix we should either a) remove these links completely or b)
link to archived copies of the pages on archive.org <http://archive.org/&gt;; or c) find a more
appropriate pages to link to. A quick search didn't turn up anything I would
prefer for (c), and I'm not sure what he legality of linking to a cached copy
is, so I would advocate for (a).

+1. It should have been obvious just from the spelling of this URL that
it wasn't intended to be a long term stable location. Digging in the
git history shows we've already updated it twice, and I wonder how many
changes there were that we didn't notice.

Just reverting bbd3bdba3 seems appropriate to me.

+1.

If we want to keep a set of such links, probably the wiki is a better place as more people can easily fix them there.

Taking a look at other links to external resources, most links seemed to
resolve still (but I didn't test all of them). I did find another one on the
GEQO page which is now dead without the content available elsewhere, as well as
a larger problem with the AIX references.

We have a list of links to the AIX 6.1 documentation which no longer works as
IBM only provides docset PDFs for 6.1. Looking that 7.x documentation they
have reorganized enough to make the older links not directly translatable. I
do wonder if updating this list is worth the effort, or if it will only lead to
us revisiting this once IBM does another site change.

The attached suggestion removes the reported SSL links, the FAQ linked to on
GEQO and all the IBM links, fully realizing that it might be controversial to
some extent.

cheers ./daniel

Daniel Gustafsson <daniel@yesql.se> writes:

Taking a look at other links to external resources, most links seemed to
resolve still (but I didn't test all of them). I did find another one on the
GEQO page which is now dead without the content available elsewhere, as well as
a larger problem with the AIX references.

We have a list of links to the AIX 6.1 documentation which no longer works as
IBM only provides docset PDFs for 6.1. Looking that 7.x documentation they
have reorganized enough to make the older links not directly translatable. I
do wonder if updating this list is worth the effort, or if it will only lead to
us revisiting this once IBM does another site change.

The attached suggestion removes the reported SSL links, the FAQ linked to on
GEQO and all the IBM links, fully realizing that it might be controversial to
some extent.

+1 for just deleting all of it. I don't think we need to be telling users
of obsolete AIX versions how to run their systems. The comp.ai.genetic
FAQ link might be more of a loss, but on the other hand I'd be willing to
bet it wasn't very up to date anymore. Netnews has been moribund for a
long time :-(

regards, tom lane

On 2020-Jul-10, Daniel Gustafsson wrote:

Taking a look at other links to external resources, most links seemed to
resolve still (but I didn't test all of them). I did find another one on the
GEQO page which is now dead without the content available elsewhere, as well as
a larger problem with the AIX references.

Um, the comp.ai.genetic FAQ can still be found, eg.
http://www.faqs.org/faqs/ai-faq/genetic/part1/

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2020-Jul-10, Daniel Gustafsson wrote:

Taking a look at other links to external resources, most links seemed to
resolve still (but I didn't test all of them). I did find another one on the
GEQO page which is now dead without the content available elsewhere, as well as
a larger problem with the AIX references.

Um, the comp.ai.genetic FAQ can still be found, eg.
http://www.faqs.org/faqs/ai-faq/genetic/part1/

So it is, although that also shows it hasn't been updated since 2001.

OTOH, that vintage of info is probably just fine for understanding GEQO.

I'll go update that pointer and remove the other links per Daniel's
patch.

regards, tom lane

On 10 Jul 2020, at 18:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Um, the comp.ai.genetic FAQ can still be found, eg.
http://www.faqs.org/faqs/ai-faq/genetic/part1/

So it is, although that also shows it hasn't been updated since 2001.

Ah, I missed the alternative source.

I'll go update that pointer and remove the other links per Daniel's
patch.

Thanks for the fixup.

cheers ./daniel

On Fri, Jul 10, 2020 at 10:07 AM Daniel Gustafsson <daniel@yesql.se> wrote:

(but I didn't test all of them)

Cave-person shell script time:

for url in ` git grep 'url="http' | sed 's/.*url="//;s/".*//' | sort | uniq `
do
if ! curl --output /dev/null --silent --head --fail "$url"
then
echo "bad URL: $url"
fi
done

bad URL: https://mingw-w64.org/
bad URL: https://msdn.microsoft.com/en-us/library/aa380493%28VS.85%29.aspx
bad URL: https://ssl.icu-project.org/icu-bin/locexp
bad URL: https://www.ismn-international.org/ranges.html

The Microsoft one is OK, it's a redirect, but the redirect target
looks like a more permanent URL to me so maybe we should change it.
The others required minor manual sleuthing to correct; I hope I found
the correct ISN ranges page. Please see attached.

Looking at the ICU URL, I found a couple like that in our source tree,
and fixed those too, including one used by
src/backend/utils/mb/Unicode/Makefile to fetch source data which has
moved (http://site.icu-project.org/repository says "Announcement
07/16/2018: The ICU source code repository has been migrated from
Subversion to Git, and is now hosted on GitHub.").

Thomas Munro <thomas.munro@gmail.com> writes:

The Microsoft one is OK, it's a redirect, but the redirect target
looks like a more permanent URL to me so maybe we should change it.

+1

The others required minor manual sleuthing to correct; I hope I found
the correct ISN ranges page. Please see attached.

I didn't actually check any of these, but they look like sane changes.

regards, tom lane

On 10 Jul 2020, at 23:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:

The others required minor manual sleuthing to correct; I hope I found
the correct ISN ranges page. Please see attached.

I didn't actually check any of these, but they look like sane changes.

+1, looks good, thanks!

cheers ./daniel

On Sat, Jul 11, 2020 at 9:56 AM Daniel Gustafsson <daniel@yesql.se> wrote:

On 10 Jul 2020, at 23:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:

The others required minor manual sleuthing to correct; I hope I found
the correct ISN ranges page. Please see attached.

I didn't actually check any of these, but they look like sane changes.

+1, looks good, thanks!

Is it OK that I see the following warning many times when running
"make" under src/backend/utils/mb/Unicode? It looks like this code is
from commit 1de9cc0d. Horiguchi-san, do you think something changed
(input data format, etc) since you wrote it, or maybe some later
changes just made our perl scripts more picky about warnings?

Use of uninitialized value $val in printf at convutils.pm line 612.

On 11 Jul 2020, at 05:25, Thomas Munro <thomas.munro@gmail.com> wrote:

Is it OK that I see the following warning many times when running
"make" under src/backend/utils/mb/Unicode? It looks like this code is
from commit 1de9cc0d. Horiguchi-san, do you think something changed
(input data format, etc) since you wrote it, or maybe some later
changes just made our perl scripts more picky about warnings?

Use of uninitialized value $val in printf at convutils.pm line 612.

Confirmed here as well, combined with the below ones for a few of the files:

Use of uninitialized value in hash element at convutils.pm line 448.
Use of uninitialized value $b1root in printf at convutils.pm line 558.
Use of uninitialized value $b1_lower in printf at convutils.pm line 560.
Use of uninitialized value $b1_upper in printf at convutils.pm line 561.
Use of uninitialized value $b3root in printf at convutils.pm line 570.
Use of uninitialized value $b3_1_lower in printf at convutils.pm line 572.
Use of uninitialized value $b3_1_upper in printf at convutils.pm line 573.
Use of uninitialized value $b3_2_lower in printf at convutils.pm line 574.
Use of uninitialized value $b3_2_upper in printf at convutils.pm line 575.
Use of uninitialized value $b3_3_lower in printf at convutils.pm line 576.
Use of uninitialized value $b3_3_upper in printf at convutils.pm line 577.
Use of uninitialized value $val in printf at convutils.pm line 612.

cheers ./daniel

At Mon, 13 Jul 2020 11:36:17 +0200, Daniel Gustafsson <daniel@yesql.se> wrote in

On 11 Jul 2020, at 05:25, Thomas Munro <thomas.munro@gmail.com> wrote:

Is it OK that I see the following warning many times when running
"make" under src/backend/utils/mb/Unicode? It looks like this code is
from commit 1de9cc0d. Horiguchi-san, do you think something changed
(input data format, etc) since you wrote it, or maybe some later
changes just made our perl scripts more picky about warnings?

Use of uninitialized value $val in printf at convutils.pm line 612.

Confirmed here as well, combined with the below ones for a few of the files:

Use of uninitialized value in hash element at convutils.pm line 448.
Use of uninitialized value $b1root in printf at convutils.pm line 558.
Use of uninitialized value $b1_lower in printf at convutils.pm line 560.

Mmm. I see the same, too. I'm looking into that.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

It is found to be a time capsule full of worms..

At Tue, 14 Jul 2020 09:00:11 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in

Use of uninitialized value $b1_lower in printf at convutils.pm line 560.

Mmm. I see the same, too. I'm looking into that.

There are three easy-to-fix issues:

1. The script set utilized undef as zeros, so most of them are fixed
by using zero for undefs.

2. Some Japanese-related converter scripts seem to be affected by a
change of regexp greediness and easily fixed.

3. I got a certificate error for ssl.icu-project.org and found that
the name is changed to icu-project.org.

And one issue that I'm not sure how we shold treat this:

A. I didn't find the files gb-18030-2000.xml and windows-949-2000.xml
in the ICU site. We have our own copy in our repository so it's not
a serious problem but I'm not sure what we should do for this.

I found CP949.TXT for windows-949-2000.xml but the former is missing
mappings for certaion code ranges (c9xx and fexx).

The attached is the fix for 1 to 3 above. It doesn't contain changes
in .map files.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Tue, Jul 14, 2020 at 3:27 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:

A. I didn't find the files gb-18030-2000.xml and windows-949-2000.xml
in the ICU site. We have our own copy in our repository so it's not
a serious problem but I'm not sure what we should do for this.

The patch I posted earlier fixes that problem (their source repository moved).

At Tue, 14 Jul 2020 15:40:41 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in

On Tue, Jul 14, 2020 at 3:27 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:

A. I didn't find the files gb-18030-2000.xml and windows-949-2000.xml
in the ICU site. We have our own copy in our repository so it's not
a serious problem but I'm not sure what we should do for this.

The patch I posted earlier fixes that problem (their source repository moved).

- $(DOWNLOAD) https://ssl.icu-project.org/repos/icu/data/trunk/charset/data/xml/$(@F)
+ $(DOWNLOAD) https://raw.githubusercontent.com/unicode-org/icu-data/master/charset/data/xml/$(@F)

Wow. The URL works and makes no difference in related map files.

Thanks!

--
Kyotaro Horiguchi
NTT Open Source Software Center