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

[Daniel Kelley]

A followup: I heard back from CRAN yesterday, and got the impression that the time was, indeed, an issue.  However, the oce package was sent along to the next step, as a CRAN maintainer noted that much of the 14 minutes was taken up by things that are difficult to trim.

PS. I think I can trim the time by about a minute, and have done so for the development version. But even removing all the documentation examples is unlikely to get oce under the 10 minute limit.  The package is fairly big, it takes a while for those R quality-control procedures to be completed.

> On Mar 19, 2022, at 1:29 PM, dbosak01 using gmail.com wrote:
> 
> CAUTION: The Sender of this email is not from within Dalhousie.
> 
> ** Check: Overall checktime, Result: NOTE Overall checktime 14 min > 10 **
> 
> This message is pretty clear that the package check time needs to be reduced.  They want it to run in less than 10 minutes.
> 
> I've hit this issue several times before. One way to resolve it is to skip some tests for the CRAN submission.  Or speed up the tests.  You are currently 4 minutes over the limit, so you'll have to reduce quite a lot.
> 
> 
> -----Original Message-----
> From: R-package-devel <r-package-devel-bounces using r-project.org> On Behalf Of Daniel Kelley
> Sent: Saturday, March 19, 2022 9:52 AM
> To: Ivan Krylov <krylov.r00t using gmail.com>
> Cc: Daniel Kelley <Dan.Kelley using Dal.Ca>; R package devel <r-package-devel using r-project.org>
> Subject: Re: [R-pkg-devel] What is best practice for handling false negatives on CRAN submission tests?
> 
> Ah, maybe the problem is in the C++ warnings.
> 
> I'll fix those up in my own version, and then wait a week or two to see if this was the cause.
> 
> Thanks, Ivan and Duncan, for your quick and very helpful replies, on a weekend.
> 
>> On Mar 19, 2022, at 10:26 AM, Ivan Krylov <krylov.r00t using gmail.com> wrote:
>> 
>> CAUTION: The Sender of this email is not from within Dalhousie.
>> 
>> 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_2022031
>>> 7_190259/Windows/00check.log>
>>> Status: OK
>> 
>>> Debian:
>>> <https://win-builder.r-project.org/incoming_pretest/oce_1.7-2_2022031
>>> 7_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
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
>