countdown to CRAN release 1.4-0

[dankelley]

Below is a checklist for CRAN submission of oce version 1.4-0. I will alter this list as I go through the process. All steps should pass without problem before proceeding to the next step.

• [x] tarball size is under 5,000,000 bytes (yes, it is 4,824,790 bytes)
• [x] devtools::spell_check()
• [x] R-CMD-check ok on all platforms, i.e. windows-latest (release), macOS-latest (release), ubuntu-20.04 (release), and ubuntu-20.04 (devel).
• [x] update other packages with update.packages() in R
• [x] local 'build' in RStudio
• [x] local devtools::check(args = c('--run-donttest','--as-cran')) in RStudio
• [x] local project-diagnostics in RStudio
• [x] local R CMD check --as-cran of tarball, from commandline
• [x] devtools:::check_win_release()
• [x] devtools:::check_win_oldrelease()
• [x] devtools:::check_win_devel()
• [x] rhub::check_for_cran() all OK, except for builds with unrelated PREPERRORS.
• [x] revdepcheck::revdep_check()
• [x] update cran-comments.md
• ~[ ] rebuild website in docs/~ this is done with the pkgdown action, and there is an error with with that (see https://github.com/dankelley/oce/runs/2194709168?check_suite_focus=true) that seems unrelated to oce, and so I am not going to let this block CRAN submission. We have seen problems with actions before, and they tend to go away because a lot of packages are using them, and I think it's just a matter of time until the action's author notices it and devises a solution. There is also a typical delay of several days, as (I think) changes have to propagate through the OSes of the action-handling machines. We have been asked to update oce or have it rejected, and so it makes no sense to hold up a resubmission (which often involves a week of to-and-fro) just to wait for an autogenerated webpage that has nothing to do with CRAN.
• [x] check https://lockedata.github.io/cransays/articles/dashboard.html to that the queue does not have an earlier submission with the same version number
• [x] upload to CRAN with devtools::release().
• [x] answer the email from CRAN asking if I had uploaded.

[dankelley]

I just did devtools::release() to submit oce to CRAN. Now we wait and see. Normally it's about a day or two to start hearing back ... it depends on how many other packages are in the pipeline, I think.

[dankelley]

I got an email that the upload worked.

[dankelley]

FYI, it is still in "pretest". You can see the status at https://lockedata.github.io/cransays/articles/dashboard.html and you'll notice that lots of things in "pretest" have been there for several days. Therefore, I imagine we'll know more by early next week.

[dankelley]

It fails Pretest. I'll investigate more today.

Email I got from CRAN describing failure

CAUTION: The Sender of this email is not from within Dalhousie. Dear maintainer, package oce_1.4-0.tar.gz does not pass the incoming checks automatically, please see the following pre-tests: Windows: Status: 1 NOTE Debian: Status: 1 NOTE Last released version's CRAN status: NOTE: 7, OK: 6 See: Last released version's additional issues: donttest CRAN Web: Please fix all problems and resubmit a fixed version via the webform. If you are not sure how to fix the problems shown, please ask for help on the R-package-devel mailing list: If you are fairly certain the rejection is a false positive, please reply-all to this message and explain. More details are given in the directory: The files will be removed after roughly 7 days. *** Strong rev. depends ***: dendroTools morphomap seacarb soundecology SWMPr vprr Best regards, CRAN teams' auto-check service Flavor: r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility, Result: NA Maintainer: 'Dan Kelley ' Size of tarball: 5155967 bytes Flavor: r-devel-windows-ix86+x86_64 Check: Overall checktime, Result: NOTE Overall checktime 14 min > 10 min Flavor: r-devel-linux-x86_64-debian-gcc Check: CRAN incoming feasibility, Result: NOTE Maintainer: 'Dan Kelley ' Size of tarball: 5155967 bytes

[dankelley]

The only things I can see as problems are

1. the filesize 5155967 bytes, which might be causing a problem by being in excess of 5000000 bytes. I can see if there's a 155000 byte trimming I can do in a dataset, but some are basically untrimmable (like a world-topo dataset, a coastline dataset). Also, we got through in 1.3.0 with I think the same size. Besides, I thought the limit was 5MB, which is 5*2^20 = 5242880 and we are under that limit. (Measured in "MB" with ls -l on my machine, the tarball is 4.9M)
2. a cross-reference to the marmap package, which seems to come up in just one platform. (Maybe that test platform cannot install marmap). This one is easy:in commit cd034881be22bd47775e18abc15500a706afa010 I just changed the link to a non-link.

I am confused, though. The first seems to have been true before. And the second seems pretty trivial (but who am I to say). I wonder if I'm missing something.

[dankelley]

As for trimming, tar -vtf oce_1.4-0.tar.gz| reveals a possibility: Reducing the resolution or size of some demo PNG files in the docs. Reducing these by 20% each (which would not make them terrible) would save 171901 bytes, getting the total under what seems to be the flagged cutoff of 5000000 bytes. I don't see too much harm in trying so I'll do that later this morning.

-rw-r--r--  0 kelley staff  167435 25 Mar 12:54 oce/man/figures/oce-demo-1.png
-rw-r--r--  0 kelley staff  124723 25 Mar 12:54 oce/man/figures/oce-demo-2.png
-rw-r--r--  0 kelley staff  237887 25 Mar 12:54 oce/man/figures/oce-demo-3.png
-rw-r--r--  0 kelley staff   95196 25 Mar 12:54 oce/man/figures/oce-demo-4.png
-rw-r--r--  0 kelley staff  185154 25 Mar 12:54 oce/man/figures/oce-demo-5.png
-rw-r--r--  0 kelley staff   49166 25 Mar 12:54 oce/man/figures/oce-demo-6.png

[dankelley]

I've trimmed the oce-demo-*.png files by 25% linearly (without too much perceptible change) and dropped the vignette diagrams by 12.5% linearly, and this gets the tarball from 5155967 to 4824261. That means that oce will get past this part of the automated testing at CRAN.

Next, I'll have a look at why the pkgdown action is not working lately. (Thanks, @paleolimbot, for the hint on that, and also the reminder that we must be under 5e6 bytes, not 5Mb!)

[richardsc]

I have to say that if the issue is that the tarball is too big, they really don't make it clear that is what is causing the NOTE.

[dankelley]

I rebuilt the pkgdown docs locally, and found a syntax error in one example, which I've fixed. (That check took 3.5 hours on an otherwise unloaded machine, whew.)

Screen snapshot of the failed action step

[dankelley]

Resubmission of 1.4-0 complete. If things proceed as the last time, it will take a day or two to see if there are problems.

[dankelley]

Still fails a pretest, because docs/reference/download.topo.html had a link to marmap. I guess I must have fixed that in a Roxygen line during the 3.5 hours it took pkgdown to rebuild that file. I am not going to wait another 3.5 hours, since it is so simple to hand-edit that file.

[dankelley]

It took 3 or 4 submissions, but finally version 1.4-0 is on its way to CRAN (see details below). I will keep this issue active until this version has been tested on all CRAN machines (see checklist), which usually takes about a week.

• [x] r-devel-linux-x86_64-debian-clang
• [x] r-devel-linux-x86_64-debian-gcc
• [x] r-devel-linux-x86_64-fedora-clang
• [x] r-devel-linux-x86_64-fedora-gcc
• [x] r-devel-windows-ix86+x86_64
• [x] r-devel-windows-x86_64-gcc10-UCRT -- THIS TEST FAILS
• [x] r-patched-linux-x86_64
• [x] r-patched-solaris-x86
• [x] r-release-linux-x86_6
• [x] r-release-macos-x86_64
• [x] r-release-windows-ix86+x86_64
• [x] r-oldrel-macos-x86_64
• [x] r-oldrel-windows-ix86+x86_64

Dear maintainer, thanks, package oce_1.4-0.tar.gz is on its way to CRAN. Best regards, CRAN teams' auto-check service Package check result: OK No changes to worse in reverse depends.

[dankelley]

I see a FAIL for the r-devel-windows-x86_64-gcc10-UCRT system, something to do with the rebuilding of vignette outputs.

The link provided on https://cran.r-project.org/web/checks/check_results_oce.html doesn't tell much (anything, really) about the problem.

I suspect the only way to learn more would be to find someone with that kind of system who is willing to do some tricky work installing a custom toolchain. Whether it's worth the effort (and risk of messing up a machine) is not clear to me. This system seems to be quite experimental, and I think it would make sense to learn more about the percentage of packages that have similar failures, before potentially throwing days at this problem (weeks, maybe, if a system has to be walked back to a previous state).

[paleolimbot]

The only thing I know about the UCRT system is that it's running Windows with UTF-8 as the system encoding (I'm sure you've read this already). I imagine it's likely not your fault and that some non-ASCII character in the vignette is causing problems...I've successfully waited out a UCRT failure when I released a new version of wk a few weeks ago. If you do have to fix it, you could also just move the vignettes to pkgdown articles to keep them out of the CMD check.

[dankelley]

Thanks, Dewey. That's an excellent point. It often happens that I drag/drop a citation from Zotero into the .Rmd, and as a result we get a UTF-8 type quotation mark or hyphen. I usually try to catch those, but sometimes I might miss them.

[dankelley]

As a further check, the following suggests that the vignette sources and also the built-up vignettes consist entirely of ASCII characters.

setwd("~/git/oce")
for (f in list.files("docs/articles", "html$", full.names=TRUE))
    cat(f, if(length(tools::showNonASCII(f))) " has non-ASCII chars\n" else " consists only of ASCII chars\n")
#> docs/articles/adp.html  consists only of ASCII chars
#> docs/articles/ctd.html  consists only of ASCII chars
#> docs/articles/flags.html  consists only of ASCII chars
#> docs/articles/index.html  consists only of ASCII chars
#> docs/articles/map_projections.html  consists only of ASCII chars
#> docs/articles/oce.html  consists only of ASCII chars
#> docs/articles/subclassing.html  consists only of ASCII chars
for (f in list.files("vignettes", "Rmd$", full.names=TRUE))
    cat(f, if(length(tools::showNonASCII(f))) " has non-ASCII chars\n" else " consists only of ASCII chars\n")
#> vignettes/adp.Rmd  consists only of ASCII chars
#> vignettes/ctd.Rmd  consists only of ASCII chars
#> vignettes/flags.Rmd  consists only of ASCII chars
#> vignettes/map_projections.Rmd  consists only of ASCII chars
#> vignettes/oce.Rmd  consists only of ASCII chars
#> vignettes/subclassing.Rmd  consists only of ASCII chars

^{Created on 2021-03-31 by the reprex package (v1.0.0)}

[dankelley]

It has been build on all CRAN machines, so I am closing this. I'll keep that ASCII issue in my mind, but since I don't know if it's a problem with oce or the CRAN test machines, I do not consider that a reason for keeping this issue open.

I thank those who have helped me with this, particularly @paleolimbot.