[R-pkg-devel] help interpreting a response from CRAN

[Ben Bolker]

  My submission from auto-check, and I'm not sure why because Windows and Debian checks 
both list "OK" and there are no unresolved problems on the CRAN status ...

  My current guess is that the problem is with the too-long check time on Windows (NOTE: 
"Overall checktime 18 min > 10 min")

 I guess I have to get busy setting more tests and examples to skip-on-CRAN 
(kind of a pain as there's no low-hanging fruit - other than the 'testthat' 
tests, none of the individual test files take longer than 15sec, although this 
is doubled because they have to be run on 386 and x64 ...)

 An alternative is that this is a confusingly worded message indicating that 
there are strong rev dependencies so the package needs to be further checked? 
(That seems unlikely as it explicitly asks me to resubmit)

  Can anyone confirm/support those guesses?

  cheers
Ben Bolker
  


=
Dear maintainer,
 
package lme4_1.1-26.tar.gz does not pass the incoming checks automatically, please see the following pre-tests:

Windows:
Status: OK
Debian:
Status: OK
 
Last released version's CRAN status: NOTE: 7, OK: 5

See:
 
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 ***: afex agRee altmeta aods3 arm ARTool bapred bayesammi BayesLN BayesSenMC baystability BBRecapture BClustLonG BFpack blme blmeco BradleyTerry2 brokenstick buildmer cAIC4 car carcass cgam chngpt ciTools clickR climwin CLME clusteredinterference clusterPower CMatching cpr cvms DClusterm dfmeta DHARMa diagmeta difR doremi eda4treeR EdSurvey eefAnalytics effects eirm embed epr ESTER ez faraway faux fence finalfit fishmethods fullfact gamm4 geex GHap glmertree glmmEP GLMMRR glmmsr glmmTMB GLMpack gorica groupedstats gtheory gvcR HelpersMG HeritSeq hmi iccbeta IDmeasurer IMTest inferference influence.ME inti intRvals isni jlctree joineRmeta joineRML JointModel jomo jstable JWileymisc KenSyn latrend lefko3 lmem.qtler LMERConvenienceFunctions lmerTest lmSupport longpower LSAmitR macc MAGNAMWAR manymodelr MargCond marked mbest MDMR mediation MEMSS merDeriv merTools meta metamicrobiomeR metamisc metan metaplus Metatron micemd MiRKAT misty mixAK MixedPsy MixMAP MixRF

 MLID mlma mlmRev mlVAR MMeM multiDimBio multilevelTools MultiRR 
MultisiteMediation mumm mvMISE MXM nanny omics OptimClassifier packDAMipd pamm 
paramhetero PBImisc pbkrtest pcgen pedigreemm Phenotype phyr piecewiseSEM 
Plasmode PLmixed powerbydesign powerlmm predictmeans PrevMap prLogistic 
projpred psfmi ptmixed qape r2mlm raincin rbenvo Rcmdr refund reghelper regplot 
REndo reproducer rewie RLRsim robustBLME robustlmm rockchalk rosetta rpql rptR 
rr2 RRreg rsq rstanarm rstap rties RVAideMemoire RVFam sae semEff siland simr 
sjstats skpr SlaPMEG smicd SoyNAM SPCDAnalyze specr SPreFuGED squid stability 
standardize statgenGxE statgenSTA StroupGLMM structree supernova Surrogate 
surrosurv swissMrP TcGSA themetagenomics tidyBF tidygate tidyMicro tramME 
tukeytrend userfriendlyscience varTestnlme VCA VetResearchLMM warpMix WebPower 
welchADF WeMix
 
Best regards,

CRAN teams' auto-check service


Flavor: r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NA
  Maintainer: 'Ben Bolker'

Flavor: r-devel-windows-ix86+x86_64
Check: Overall checktime, Result: NOTE
  Overall checktime 18 min > 10 min

Flavor: r-devel-linux-x86_64-debian-gcc
Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
  Maintainer: 'Ben Bolker'

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] help interpreting a response from CRAN

[Dirk Eddelbuettel]

On 22 November 2020 at 13:44, Ben Bolker wrote:
|My current guess is that the problem is with the too-long check time on 
Windows (NOTE: "Overall checktime 18 min > 10 min")

Yes.
 
|   I guess I have to get busy setting more tests and examples to skip-on-CRAN 
(kind of a pain as there's no low-hanging fruit - other than the 'testthat' 
tests, none of the individual test files take longer than 15sec, although this 
is doubled because they have to be run on 386 and x64 ...)

It's under your control. You can detect 'are we on Windows' and branch or, as
I do with test runner I use, exit_file("...") based on such conditions.

|   An alternative is that this is a confusingly worded message indicating that 
there are strong rev dependencies so the package needs to be further checked? 
(That seems unlikely as it explicitly asks me to resubmit)

No. If there were any (even false positive ones) they'd be listed there.

Hth, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] help interpreting a response from CRAN

[Uwe Ligges]

Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer 
than 5 min, so the overall check time exceeds 10 min.


So one can follow Dirk's advise.

As a general remark for others who will read this in the future:
tests should test the software, but it is generally not important to 
have real world examples. Small data and few iterations are typically 
sufficient for tests.
It is also possible to run less important tests only conditionally if 
some environment variable is set that you only define on your machine.


Best,
Uwe Ligges







On 22.11.2020 20:36, Dirk Eddelbuettel wrote:


On 22 November 2020 at 13:44, Ben Bolker wrote:
|My current guess is that the problem is with the too-long check time on Windows (NOTE: 
"Overall checktime 18 min > 10 min")

Yes.
  
|   I guess I have to get busy setting more tests and examples to skip-on-CRAN (kind of a pain as there's no low-hanging fruit - other than the 'testthat' tests, none of the individual test files take longer than 15sec, although this is doubled because they have to be run on 386 and x64 ...)


It's under your control. You can detect 'are we on Windows' and branch or, as
I do with test runner I use, exit_file("...") based on such conditions.

|   An alternative is that this is a confusingly worded message indicating that 
there are strong rev dependencies so the package needs to be further checked? 
(That seems unlikely as it explicitly asks me to resubmit)

No. If there were any (even false positive ones) they'd be listed there.

Hth, Dirk



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] 'stringi' package on Windows

[Uwe Ligges]

On 22.11.2020 06:46, Dan Zigmond wrote:

I've run into another issue re-submitting my package to CRAN:

Flavor: r-devel-windows-ix86+x86_64
Check: package dependencies, Result: ERROR
   Package required but not available: 'stringi'

Everything seems to run fine on the other platformd and I used the stringi
package in the previous iteration of the package without issue, but it
seems perhaps there is some issue with stringi under Windows right now?



No, it was being reinstalled while your package got checked. SO we havbe 
to trigger new checks (I hope we did so, but I cannot know as you do not 
mention the package name).


Best,
Uwe Ligges


   Dan


.
--
Dan Zigmond
d...@shmonk.com

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] help interpreting a response from CRAN

[Ben Bolker]

   Thanks all for the help.  The reward (as usual) is another dumb 
question.


If I add up the elapsed times listed in

https://win-builder.r-project.org/incoming_pretest/lme4_1.1-26_20201122_184744/Windows/examples_and_tests/examples_x64/lme4-Ex.timings

  I get 21.43 seconds.  But the output in

https://win-builder.r-project.org/incoming_pretest/lme4_1.1-26_20201122_184744/Windows/00check.log

says

** running examples for arch 'x64' ... [41s] OK

 The values for i386 have a similar discrepancy (20.6 vs 36s).  I can 
appreciate that would be a bit of overhead (and rounding error), but ... 
? (there are a total of 61 examples)


  I wouldn't normally worry about the discrepancy, but I'm doing my 
best to shave seconds where I can ...  can anyone see any obvious thinkos?


  I might as well add (in my partial defense, in response to Uwe's 
point about not needing real-world/big examples for tests); many of 
lme4's tests are regression tests of edge cases that came up in the real 
world with moderately sized data sets.  *In principle* it might be 
possible to find a way to reduce those medium-sized problems to small, 
fast problems that still demonstrated the same numerical problems, but 
it's hard and time-consuming (at least for me) ...


  cheers
Ben Bolker





On 11/22/20 4:06 PM, Uwe Ligges wrote:
Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer 
than 5 min, so the overall check time exceeds 10 min.


So one can follow Dirk's advise.

As a general remark for others who will read this in the future:
tests should test the software, but it is generally not important to 
have real world examples. Small data and few iterations are typically 
sufficient for tests.
It is also possible to run less important tests only conditionally if 
some environment variable is set that you only define on your machine.


Best,
Uwe Ligges







On 22.11.2020 20:36, Dirk Eddelbuettel wrote:


On 22 November 2020 at 13:44, Ben Bolker wrote:
|    My current guess is that the problem is with the too-long check 
time on Windows (NOTE: "Overall checktime 18 min > 10 min")


Yes.
|   I guess I have to get busy setting more tests and examples to 
skip-on-CRAN (kind of a pain as there's no low-hanging fruit - other 
than the 'testthat' tests, none of the individual test files take 
longer than 15sec, although this is doubled because they have to be 
run on 386 and x64 ...)


It's under your control. You can detect 'are we on Windows' and branch 
or, as

I do with test runner I use, exit_file("...") based on such conditions.

|   An alternative is that this is a confusingly worded message 
indicating that there are strong rev dependencies so the package needs 
to be further checked? (That seems unlikely as it explicitly asks me 
to resubmit)


No. If there were any (even false positive ones) they'd be listed there.

Hth, Dirk



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] help interpreting a response from CRAN

[Ben Bolker]

  And one more (last for a while): presumably there is no way to check 
CRAN windows timing without submitting to CRAN ... ?  (I will obviously 
do my best by doing arithmetic on the tests that I set to be skipped, 
but it would be nice to be able to double-check without wasting 
everyone's time ... I guess if I knew that CRAN submissions would 
*always automatically* be rejected with Windows test times>10 min, I 
could use CRAN submission itself as my test ... but maybe that's a bad 
idea?)


On 11/22/20 4:06 PM, Uwe Ligges wrote:
Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer 
than 5 min, so the overall check time exceeds 10 min.


So one can follow Dirk's advise.

As a general remark for others who will read this in the future:
tests should test the software, but it is generally not important to 
have real world examples. Small data and few iterations are typically 
sufficient for tests.
It is also possible to run less important tests only conditionally if 
some environment variable is set that you only define on your machine.


Best,
Uwe Ligges







On 22.11.2020 20:36, Dirk Eddelbuettel wrote:


On 22 November 2020 at 13:44, Ben Bolker wrote:
|    My current guess is that the problem is with the too-long check 
time on Windows (NOTE: "Overall checktime 18 min > 10 min")


Yes.
|   I guess I have to get busy setting more tests and examples to 
skip-on-CRAN (kind of a pain as there's no low-hanging fruit - other 
than the 'testthat' tests, none of the individual test files take 
longer than 15sec, although this is doubled because they have to be 
run on 386 and x64 ...)


It's under your control. You can detect 'are we on Windows' and branch 
or, as

I do with test runner I use, exit_file("...") based on such conditions.

|   An alternative is that this is a confusingly worded message 
indicating that there are strong rev dependencies so the package needs 
to be further checked? (That seems unlikely as it explicitly asks me 
to resubmit)


No. If there were any (even false positive ones) they'd be listed there.

Hth, Dirk



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] help interpreting a response from CRAN

[Roy Mendelssohn - NOAA Federal via R-package-devel]

I have found win-builder timings come close,  but only close.  My experience is 
that the CRAN timings were uniformly slower than those on win-builder.  But I 
also find that I can get quite significant differences between 
win-builder-release and win-builder-devel.  So I also take the slowest that I 
can find as a basis,  and assume the actual times will be slower than that.

HTH,

-Roy

> On Nov 22, 2020, at 5:15 PM, Ben Bolker  wrote:
> 
>  And one more (last for a while): presumably there is no way to check CRAN 
> windows timing without submitting to CRAN ... ?  (I will obviously do my best 
> by doing arithmetic on the tests that I set to be skipped, but it would be 
> nice to be able to double-check without wasting everyone's time ... I guess 
> if I knew that CRAN submissions would *always automatically* be rejected with 
> Windows test times>10 min, I could use CRAN submission itself as my test ... 
> but maybe that's a bad idea?)
> 
> On 11/22/20 4:06 PM, Uwe Ligges wrote:
>> Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer than 5 
>> min, so the overall check time exceeds 10 min.
>> So one can follow Dirk's advise.
>> As a general remark for others who will read this in the future:
>> tests should test the software, but it is generally not important to have 
>> real world examples. Small data and few iterations are typically sufficient 
>> for tests.
>> It is also possible to run less important tests only conditionally if some 
>> environment variable is set that you only define on your machine.
>> Best,
>> Uwe Ligges
>> On 22.11.2020 20:36, Dirk Eddelbuettel wrote:
>>> 
>>> On 22 November 2020 at 13:44, Ben Bolker wrote:
>>> |My current guess is that the problem is with the too-long check time 
>>> on Windows (NOTE: "Overall checktime 18 min > 10 min")
>>> 
>>> Yes.
>>> |   I guess I have to get busy setting more tests and examples to 
>>> skip-on-CRAN (kind of a pain as there's no low-hanging fruit - other than 
>>> the 'testthat' tests, none of the individual test files take longer than 
>>> 15sec, although this is doubled because they have to be run on 386 and x64 
>>> ...)
>>> 
>>> It's under your control. You can detect 'are we on Windows' and branch or, 
>>> as
>>> I do with test runner I use, exit_file("...") based on such conditions.
>>> 
>>> |   An alternative is that this is a confusingly worded message indicating 
>>> that there are strong rev dependencies so the package needs to be further 
>>> checked? (That seems unlikely as it explicitly asks me to resubmit)
>>> 
>>> No. If there were any (even false positive ones) they'd be listed there.
>>> 
>>> Hth, Dirk
>>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] help interpreting a response from CRAN

[Uwe Ligges]

On 23.11.2020 04:13, Roy Mendelssohn - NOAA Federal wrote:

I have found win-builder timings come close,  but only close.  My experience is 
that the CRAN timings were uniformly slower than those on win-builder.  But I 
also find that I can get quite significant differences between 
win-builder-release and win-builder-devel.  So I also take the slowest that I 
can find as a basis,  and assume the actual times will be slower than that.


winbuilder and the WIndows check machione for the regulöar checks are 
actually identical.


Best,
Uwe Ligges





HTH,

-Roy


On Nov 22, 2020, at 5:15 PM, Ben Bolker  wrote:

  And one more (last for a while): presumably there is no way to check CRAN 
windows timing without submitting to CRAN ... ?  (I will obviously do my best by 
doing arithmetic on the tests that I set to be skipped, but it would be nice to be 
able to double-check without wasting everyone's time ... I guess if I knew that 
CRAN submissions would *always automatically* be rejected with Windows test 
times>10 min, I could use CRAN submission itself as my test ... but maybe 
that's a bad idea?)

On 11/22/20 4:06 PM, Uwe Ligges wrote:

Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer than 5 
min, so the overall check time exceeds 10 min.
So one can follow Dirk's advise.
As a general remark for others who will read this in the future:
tests should test the software, but it is generally not important to have real 
world examples. Small data and few iterations are typically sufficient for 
tests.
It is also possible to run less important tests only conditionally if some 
environment variable is set that you only define on your machine.
Best,
Uwe Ligges
On 22.11.2020 20:36, Dirk Eddelbuettel wrote:


On 22 November 2020 at 13:44, Ben Bolker wrote:
|My current guess is that the problem is with the too-long check time on Windows (NOTE: 
"Overall checktime 18 min > 10 min")

Yes.
|   I guess I have to get busy setting more tests and examples to skip-on-CRAN 
(kind of a pain as there's no low-hanging fruit - other than the 'testthat' 
tests, none of the individual test files take longer than 15sec, although this 
is doubled because they have to be run on 386 and x64 ...)

It's under your control. You can detect 'are we on Windows' and branch or, as
I do with test runner I use, exit_file("...") based on such conditions.

|   An alternative is that this is a confusingly worded message indicating that 
there are strong rev dependencies so the package needs to be further checked? 
(That seems unlikely as it explicitly asks me to resubmit)

No. If there were any (even false positive ones) they'd be listed there.

Hth, Dirk



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel