On 10/12/20 4:34 PM, Iñaki Ucar wrote:
You are right. I was too fast and didn't read "last released version". Then the only suspicious thing I see is: Overall checktime 23 min > 10 min
I agree that's unfortunate, but it doesn't seem grounds for summary rejection ... ? (CRAN policy says "Checking the package should take as little CPU time as possible".) You may be right: it does seem to be _de facto_ policy that any NOTE is grounds for rejection. On the other hand, this package has had NOTEs about 'installed size is <large>" for a long time, which hasn't been grounds for rejection.
cheers Ben Bolker
On Mon, 12 Oct 2020 at 22:25, Ben Bolker <bbol...@gmail.com> 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 BolkerThere 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
