[R-pkg-devel] What is best practice for handling false negatives on CRAN submission tests?

[Ivan Krylov]

On Sat, 19 Mar 2022 12:14:30 +0000
Daniel Kelley <Dan.Kelley using Dal.Ca> wrote:

> Would I be sensible to wait a couple of weeks for a reply?

I agree with Duncan, I'd wait for days, not weeks.

> I ask because the schedule would have oce being auto-removed from
> CRAN early next month, and I worry a bit about that happening because
> of an email that went missing, or because I was unclear on how to
> communicate with CRAN.

From your description, I think you're doing everything right. I've seen
individual reviewers reject a package after a review by mistake (during
a heroic struggle against a ~100-package long "newbies" queue), but not
the automated system.

The pressure is real, I hope you manage to resolve the problems on time!

> Anyway, the email I got back from CRAN told me that oce-1.7.2 had
> failed initial tests.  However, the email makes it seem that those
> tests had actually been passed.

> package oce_1.7-2.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> Windows:
> <https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_20220317_190259/Windows/00check.log>
> Status: OK

> Debian:
> <https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_20220317_190259/Debian/00check.log>
> Status: OK

This does seem like it shouldn't be have auto-rejected the package,
though if I go take a look at the installation logs, I see compiler
warnings:

https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_20220317_190259/Debian/00install.out

"Variable set but not used" is mostly harmless, but should be easy to
fix, likely by removing said variable.

https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_20220317_190259/Windows/00install.out

"Comparison of integer expressions of different signedness: 'unsigned
int' and 'long int'" could be more serious in corner cases (files
of size > 2G). Typically, the variable being compared to ftell() should
be defined as the same type as the return value of ftell().

Unfortunately, I don't know whether these were the reason for rejection.

> Last released version's CRAN status: OK: 3, NOTE: 6, WARNING: 1,
> ERROR: 3

This is also normal, especially if you explained that you fixed the
previously failing tests in the submission comment.

> Best regards,
> CRAN teams' auto-check service
> Flavor: r-devel-windows-x86_64
> Check: CRAN incoming feasibility, Result: NA
> Maintainer: 'Dan Kelley <Dan.Kelley using Dal.Ca>'

Hmm, where does this come from? The NA result looks ominous.
 
> Flavor: r-devel-windows-x86_64
> Check: Overall checktime, Result: NOTE
> Overall checktime 14 min > 10 min

Is this from the reverse dependency check? Does this mean it needs to
take less time?

-- 
Best regards,
Ivan