Actually more than 23 minutes check time for a single package is really
excessive, can you pls cut that down?
This comes from
** running tests for arch 'i386' ... [509s] OK
** running tests for arch 'x64' ... [501s] OK
so only tests take 1010 seconds already.
I see that lme4 is a really important package that may justify some
extra check time, but this is really a lot.
Can you please reduce the check time in the tests? e.g. using toy data
and few iterations? Or by running less important tests only
conditionally if some environment variable is set that you only define
on your machine?
Best,
Uwe Ligges
On 12.10.2020 22:25, Ben Bolker wrote:
Thanks, but I don't think that's the problem because:
(1) Those are reported as being from the last released version, not
this one.
(2) As far as I can tell from my local tests, I'm pretty sure I've
fixed these issues in the current release.
(3) In my experience UBSAN tests don't generally get re-run for a
while after the initial CRAN testing anyway ...
cheers
Ben
On 10/12/20 4:23 PM, Iñaki Ucar wrote:
On Mon, 12 Oct 2020 at 22:04, Ben Bolker <bbol...@gmail.com> wrote:
Before I risk wasting the CRAN maintainers' time with a query, can
anyone see what I'm missing here? Everything I can see looks OK, with
the possible exception of the 'NA' result for "CRAN incoming
feasibility" on r-devel-windows-ix86+x86_64 (which surely isn't my
fault???)
Any help appreciated, as always.
Ben Bolker
There are UBSAN issues:
Last released version's additional issues:
gcc-UBSAN
<https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/lme4>
______________________________________________
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
