On Sat, 19 Mar 2022 12:14:30 +0000 Daniel Kelley <dan.kel...@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.kel...@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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel