Data.table: 1.13.2 release checks

[mattdowle]

• [x] Rerun CRAN revdeps:

  ERROR   :   6 : CornerstoneR eplusr RBMRB spatsoc tstools wyz.code.metaTesting 
  WARNING :   2 : hsrecombi metaMix 
  NOTE    : 315 
  OK      : 595 
  TOTAL   : 918 / 918 

fail.log

• [x] CornerstoneR - passes with 1.13.0 so error is due to 1.13.2. Fixed by #4760.
• [x] eplusr - passes with 1.13.0 so error is due to 1.13.2 https://github.com/hongyuanjia/eplusr/issues/346. Fixed by #4763.
• [x] RBMRB; same unexpected character '<' displays on CRAN. Not due to data.table v1.13.2
• [x] spatsoc; https://github.com/ropensci/spatsoc/issues/32 has been resolved in spatsoc-dev but not yet released to CRAN. revdepsh sets TZ=UTC so when I was comparing R CMD check spatsoc_0.1.14.tar.gz to TZ=UTC R CMD check spatsoc_0.1.14.tar.gz, the former was still running with TZ=UTC. When in a revdepsh bash env, if I unset TZ first, then spatsoc passes. No CRAN machine currently runs tests with TZ=UTC set.
• [x] tstools - passes with 1.13.0 so error is due to 1.13.2. Fixed by #4759.
• [x] wyz.code.metaTesting; same error displays on CRAN. Not due to data.table v1.13.2
• [x] hsrecombi; same attempt to apply non-function displays on CRAN. Not due to data.table v1.13.2
• [x] metaMix; still can't get metaMix past Invalid MIT-MAGIC-COOKIE-1 key locally.
• [x] Pass win-builder R-devel with just URL checking notes about too-many-requests
• [x] CRAN_Release.cmd (e.g. UBSAN, ASAN, rchk, gctorture #4637)
• [x] translation-checks error postponed to 1.13.3: #4764
• [x] CRAN additional issues outstanding: #4639
• [x] News item review, spell check, and tidy format as rendered on github
• [x] Codefreeze
• [x] @renkun-ken go-first run please (successful with 64ea55d25f715e7d7527ffcaa600ea1645d13d76)
• [x] Repeat win-builder 3*OK
• [x] Start final rerun latest revdeps refreshed. CRAN runs revdep impact analysis as well before accepting, and they often find things I don't locally. Hence don't wait for this to complete.
• [x] Submit to CRAN (several opportunities to halt after this, so please shout if something comes up)
• [x] CRAN pre-test success email received and ok
• [x] Bump dev version
• [x] Copy and paste revdep.R::status() output as new comment to this issue
• [x] ~CRAN revdep status impact results email received.~ I didn't receive this email this time. I guess it's not sent when there is no impact at all.
• [x] ~Matt replied to confirm and explain differences to submission note.~ No need this time.
• [x] CRAN email received to confirm accepted
• [x] git tag 1.13.2
• [x] Add publish date to v1.13.2 title in NEWS.md
• [x] Update version and date in Installation wiki heading
• [x] Tweet to #rdatatable https://twitter.com/MattDowle/status/1318406387647512579

[renkun-ken]

Didn't notice the progress is so fast. My go-first run is still running...

[mattdowle]

Rerun of all refreshed revdeps completed and looks good :

CRAN:
 ERROR   :   4 : distr6 lgr spatsoc wyz.code.metaTesting 
 WARNING :   1 : metaMix 
 NOTE    : 317 
 OK      : 599 
 TOTAL   : 921 / 921 

lgr has just started to fail on CRAN too with the same errors, so isn't to do with this data.table update

distr6 is now failing locally for me, but with data.table 1.13.0 too and with the same C stack overflow, so it's not due to this data.table update. For future reference, I managed to fix other similar local fails by reinstalling the dependency chain of such packages in my revdeplib. That can work because I've updated to latest R-devel but I'm using that on the 3,591 packages in my revdeplib that were i) mostly installed with an older version of R-devel, and ii) installed when older version of ubuntu packages where present on my machine which includes scientific libraries that the R revdeps are using that have received updates in the meantime. That didn't work this time. Maybe reinstalling strong dependencies didn't catch the particular library that needs reinstalling. I usually find that a weak dependency chain reaches over 1,000 packages, so at that point I go for a full reinstall of my revdeplib (see .dev/revdep.R) using current R-devel. I'd expect that to fix distr6. That takes a few days, and I do every 6 months or so anyway. I usually use R-release for revdep checking for this reason, but since R-release is currently still in the 4.0.* series, I've been using R-devel this year to test revdeps under 4.1. I tried using Rdevel-strict with ASAN and strict barrier to trace this distr6 problem but I got the ASan runtime does not come first in initial library list; you should either link runtime to your application... error. I'm not sure how to get around that. I guess it's because some packages have been compiled with ASAN (distr6 and data.table in this case) and other packages haven't (everything else in my revdeplib). So then I tested distr6 under Rdevel-strict with ASAN and strict-barrier etc, outside of my revdeplib, and it passed fine.

[mattdowle]

Great, thanks @renkun-ken. For future reference in case someone else is running release procedures in future, I haven't heard from CRAN yet so there would have been time to cancel if Kun had found something. Thanks again, Matt