[Rd] R-devel tarball at ETH is zero

[Martin Maechler]

>>>>> peter dalgaard 
>>>>>     on Tue, 3 May 2022 14:11:14 +0200 writes:

    > FWIW, the tarballs in 
    > https://cran.r-project.org/src/base-prerelease/

    > seem ok at this point.

    > (We usually prefer that you use one of the two tarball sources over svn/git because "make dist" issues otherwise can go unnoticed.)

    > -pd 

    >> On 3 May 2022, at 13:54 , Dirk Eddelbuettel <edd using debian.org> wrote:
    >> 
    >> 
    >> Dear Martin as our trusted ETH point person,
    >> 
    >> I have some automated builders fall over as the tarball of R-devel is
    >> currently empty:
    >> 
    >> 
    >> edd using rob:/tmp$ wget https://stat.ethz.ch/R/daily/R-devel.tar.bz2
    >> --2022-05-03 06:52:20--  https://stat.ethz.ch/R/daily/R-devel.tar.bz2
    >> Resolving stat.ethz.ch (stat.ethz.ch)... 129.132.119.195
    >> Connecting to stat.ethz.ch (stat.ethz.ch)|129.132.119.195|:443... connected.
    >> HTTP request sent, awaiting response... 200 OK
    >> Length: 0 [application/x-bzip2]
    >> Saving to: ‘R-devel.tar.bz2’
    >> 
    >> R-devel.tar.bz2         [ <=>                ]       0  --.-KB/s    in 0s      
    >> 
    >> 2022-05-03 06:52:21 (0.00 B/s) - ‘R-devel.tar.bz2’ saved [0/0]
    >> 
    >> edd using rob:/tmp$ ls -l R-devel.tar.bz2 
    >> -rw-rw-r-- 1 edd edd 0 May  2 19:07 R-devel.tar.bz2

I'm really sorry for this experience.

We are also a CRAN mirror, and this came after release of R
4.2.0 with its new 'binary' (sub)directories for Windows and 2
versions of macOS:  The necessary disk space  increased again
*AND*  for some reason the "supervisor" process which alerts
about "disk quota soon to be reached"  had stopped working  ---
for reasons yet unknown which our IT staff is investigating,
hence disk quota had been badly violated .. and even moving away
less important stuff (me, last evening, spending an hour in vain)
would not help to get below the limit..

When the disk quota was finally raised early this morning, I subsequently
manually started the process creating the tar balls etc (which
otherwise runs in 2 different versions 3x/day via cron
daemon)... and so tar balls should be back to normal for ca. 3
hours now.

Best regards,
Martin