Re: cpan.org Metadata and modules files not being updated

2026-03-26 Thread Graham Knop

On 2026-03-22 05:10, Ask Bjørn Hansen wrote:

Hi James (and everyone),

Sorry about the head-banging, that was my fault!

The CPAN index files on www.cpan.org were stale for most of today, for users in 
North America and Asia (in Europe it should have been okay).

Yesterday I added two new backends for the Fastly CDN as part of 
decommissioning the old primary cluster (going from two to three origins). The 
CPAN sync into the web server storage wasn't set up on the new clusters, so 
they were serving a static copy from when they were first provisioned. The old 
working backend had fresh data, but requests hitting the new ones got stale 
index files.

We usually catch this with monitoring, but not all the monitoring is in place 
yet for the new clusters. There's been a lot of work getting the new 
infrastructure up and it slipped through.

I've switched the CDN back to only the working backend while I get the sync 
sorted on the new clusters.

If you were seeing "this index file is 39 days old" warnings from the cpan 
shell, or modules not showing updated versions, that was this.



Ask


There still seem to be missing files on some of the backends.

For example, 
https://www.cpan.org/authors/id/R/RJ/RJBS/Getopt-Long-Descriptive-0.117.tar.gz 
works when requested from Europe, but gives a 404 when requested from 
the USA.


https://www.cpan.org/authors/id/W/WA/WATERKIP/AnyEvent-I3X-Workspace-OnDemand-0.010.tar.gz 
has the same issue.




Re: cpan.org Metadata and modules files not being updated

2026-03-22 Thread James E Keenan

On 3/22/26 00:10, Ask Bjørn Hansen wrote:

Hi James (and everyone),

Sorry about the head-banging, that was my fault!

The CPAN index files on www.cpan.org were stale for most of today, for users in 
North America and Asia (in Europe it should have been okay).

Yesterday I added two new backends for the Fastly CDN as part of 
decommissioning the old primary cluster (going from two to three origins). The 
CPAN sync into the web server storage wasn't set up on the new clusters, so 
they were serving a static copy from when they were first provisioned. The old 
working backend had fresh data, but requests hitting the new ones got stale 
index files.

We usually catch this with monitoring, but not all the monitoring is in place 
yet for the new clusters. There's been a lot of work getting the new 
infrastructure up and it slipped through.

I've switched the CDN back to only the working backend while I get the sync 
sorted on the new clusters.

If you were seeing "this index file is 39 days old" warnings from the cpan 
shell, or modules not showing updated versions, that was this.



Ah! So it required deep sysadmin foo to understand!  No wonder I was 
puzzled!


Thanks for your investigation.  At the very least, it got me to align my 
MyConfig.pm on 3 different machines.


Re: cpan.org Metadata and modules files not being updated

2026-03-21 Thread James E Keenan

On 3/21/26 09:31, James E Keenan wrote:
Having a problem which first becomes apparent running the 'cpan' shell, 
but then points toward the cpan.org infrastructure.


Yesterday I installed perl-5.43.9 on by two servers (Linux and FreeBSD). 
  Here I present data from FreeBSD:

```
[perlmonger: perl-5.43.9] $ ls -l bin/perl bin/cpan
-rwxr-xr-x  1 jkeenan jkeenan    8418 Mar 20 14:56 bin/cpan
-rwxr-xr-x  2 jkeenan jkeenan 4080848 Mar 20 14:56 bin/perl
  $ ./bin/perl -v | head -2 | tail -1
This is perl 5, version 43, subversion 9 (v5.43.9) built for amd64- 
freebsd-thread-multi

$ ./bin/cpan -v
./bin/cpan script version 1.678, CPAN.pm version 2.38
```
I then installed Task::CPAN::Reporter against that perl (including a 
trial release of Net-SSLeay-1.95_001) and then proceeded to generate 
CPANtester reports for over 500 distros on each platform.


I subsequently received email indicating that some of the problems I 
reported had already been fixed.  I went back to those new perl 
installations and tried to use the `cpan` shell to install the updated 
distros.

```
$ cd $TESTINGDIR/perl-5.43.9
$ ./bin/cpan

cpan[1]> reload index
Reading '/home/jkeenan/.cpan/Metadata'
   Database was generated on Mon, 09 Feb 2026 15:41:01 GMT
Fetching with HTTP::Tiny:
https://cpan.org/authors/01mailrc.txt.gz
Reading '/home/jkeenan/.cpan/sources/authors/01mailrc.txt.gz'
DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/02packages.details.txt.gz
Reading '/home/jkeenan/.cpan/sources/modules/02packages.details.txt.gz'
   Database was generated on Mon, 09 Feb 2026 15:41:01 GMT
Warning: This index file is 39 days old.
   Please check the host you chose as your CPAN mirror for staleness.
   I'll continue but problems seem likely to happen.
DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/03modlist.data.gz
Reading '/home/jkeenan/.cpan/sources/modules/03modlist.data.gz'
DONE
Writing /home/jkeenan/.cpan/Metadata
```
Note these two lines in the output above:
```
   Database was generated on Mon, 09 Feb 2026 15:41:01 GMT

   Database was generated on Mon, 09 Feb 2026 15:41:01 GMT
Warning: This index file is 39 days old.
   Please check the host you chose as your CPAN mirror for staleness.
   I'll continue but problems seem likely to happen.
```
I get a console beep when that line `Warning: Ths index file is 39 days 
old.` appears.


Today, 21 Mar 2026, is 40 days after 09 Feb 2026.  Now my *local* CPAN 
metadata files are up-to-date:

```
$ ls -l ~/.cpan/Metadata ~/.cpan/sources/modules ~/.cpan/sources/authors
/
-rw-r--r--  1 jkeenan jkeenan 44358810 Mar 21 13:05 /home/jkeenan/.cpan/ 
Metadata


/home/jkeenan/.cpan/sources/authors/:
total 273
-rw-r--r--   1 jkeenan jkeenan 250949 Mar 21 13:05 01mailrc.txt.gz
drwxr-xr-x  28 jkeenan jkeenan 28 May 20  2021 id

/home/jkeenan/.cpan/sources/modules:
total 2549
-rw-r--r--  1 jkeenan jkeenan 2592931 Mar 21 13:05 
02packages.details.txt.gz

-rw-r--r--  1 jkeenan jkeenan 248 Mar 21 13:05 03modlist.data.gz
```
So what it appears is happening is that the files on cpan.org are out- 
of-date:

```
https://cpan.org/authors/01mailrc.txt.gz

https://cpan.org/modules/02packages.details.txt.gz
```
The problem appears to be that **inside** the local 
`02packages.details.txt.gz` file, the `Last-Updated` entry is still 09 
Feb 2026.

```
$ zcat ~/.cpan/sources/modules/02packages.details.txt.gz | head
File: 02packages.details.txt
URL:  http://www.cpan.org/modules/02packages.details.txt
Description:  Package names found in directory $CPAN/authors/id/
Columns:  package name, version, path
Intended-For: Automated fetch routines, namespace documentation.
Written-By:   PAUSE version 1.005
Line-Count:   270470
Last-Updated: Mon, 09 Feb 2026 15:41:01 GMT

A1z::Html  0.04  C/CE/CEEJAY/A1z-Html-0.04.tar.gz
```
So every time I say `reload index` inside the `cpan` shell, I'm getting 
the same 40-day-old data every time.  I note, for instance, that in 
02packages I don't see the latest version of a CPAN distro which I 
uploaded on 03 March.

```
$ zgrep -n 'Business::Tax::US' ~/.cpan/sources/modules/02packages.detail
s.txt.gz
30869:Business::Tax::US::Form_1040::Worksheets 0.07 J/JK/JKEENAN/ 
Business-Tax-US-Form_1040-Worksheets-0.07.tar.gz

```
... whereas metacpan.org correctly has version 0.08 uploaded on March 3.
```
https://metacpan.org/pod/Business::Tax::US::Form_1040::Worksheets
```
Where should this be further reported?




After many hours of head-banging-on-wall, I got the 'cpan' shell on one 
of my two servers to DWIM -- though I don't know why it achieved the 
result I wanted.


I had to compare the ~/.cpan/CPAN/MyConfig.pm file on my laptop -- which 
was already DWIMming -- with that on my Linux server.  I observed 
differences in 2 of the key-value pairs:


KVP   Laptop (Ubuntu 24.04 

Re: cpan.org Metadata and modules files not being updated

2026-03-21 Thread Ask Bjørn Hansen
Hi James (and everyone),

Sorry about the head-banging, that was my fault!

The CPAN index files on www.cpan.org were stale for most of today, for users in 
North America and Asia (in Europe it should have been okay).

Yesterday I added two new backends for the Fastly CDN as part of 
decommissioning the old primary cluster (going from two to three origins). The 
CPAN sync into the web server storage wasn't set up on the new clusters, so 
they were serving a static copy from when they were first provisioned. The old 
working backend had fresh data, but requests hitting the new ones got stale 
index files.

We usually catch this with monitoring, but not all the monitoring is in place 
yet for the new clusters. There's been a lot of work getting the new 
infrastructure up and it slipped through.

I've switched the CDN back to only the working backend while I get the sync 
sorted on the new clusters.

If you were seeing "this index file is 39 days old" warnings from the cpan 
shell, or modules not showing updated versions, that was this.



Ask