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

[dbos@k01 m@iii@g oii gm@ii@com]

** 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