Dear all,
I recently made some minor updates to the joineRML R package to squash some CRAN CMD check NOTEs that have emerged over the past couple of years. After resubmitting to CRAN, a new NOTE appeared on the Debian platform only: > package joineRML_0.4.7.tar.gz does not pass the incoming checks automatically, please see the following pre-tests (additional issue checks): > Windows: < https://win-builder.r-project.org/incoming_pretest/joineRML_0.4.7_20250114_073418/Windows/00check.log > > Status: OK > Debian: < https://win-builder.r-project.org/incoming_pretest/joineRML_0.4.7_20250114_073418/Debian/00check.log > > Status: 1 NOTE The NOTE in particular is: > * checking re-building of vignette outputs ... [116s/30s] NOTE > Re-building vignettes had CPU time 3.9 times elapsed time I emailed Uwe Ligges and got a reply: > We see > Flavor: r-devel-linux-x86_64-debian-gcc > Check: re-building of vignette outputs, Result: NOTE > Re-building vignettes had CPU time 3.9 times elapsed time > which suggests you are using more than 2 cores which is not permitted by default. There is only one function in my package that uses multiple cores: bootSE(). However, this function is not called in any of my vignettes because it is computationally expensive. The Rmd code has `eval = FALSE` options for all of these cases. Therefore, I am at a loss as to why these vignettes would be using more than 2 cores or what is causing this, or why it only impacts the CRAN CMD check Debian system. I noticed this has been a common reported issue (e.g., https://github.com/Rdatatable/data.table/issues/5658), but mainly for those using data.table or openMP; I use neither. The same issue was showing for some examples also, which I dealt with by wrapping in \dontrun{} — not ideal, but seemed quickest way to avoid. I have tried many things to fix this: 1. Modifying the vignettes to make faster 2. Adding various combinations of Sys.setenv("OMP_THREAD_LIMIT" = 1), Sys.setenv("OMP_NUM_THREADS" = 1), options(Ncpus = 1), options(cores = 2) to the Rmd vignettes 3. Checked the package builds using r-lib/actions (GitHub actions) and r-hub Debian platform — I cannot reproduce this CRAN error CRAN will not accept the update to my package until this NOTE is squashed. If anyone is able to provide a recommendation on what I might do, I would appreciate it. Kind regards, Graeme Hickey [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
