Re: [R-pkg-devel] OFFICIAL: R-devel check error: package or NAMESPACE load failed, there is no package called broom
OFFICIAL
Many thanks Pedro and Hadley
Just to complete the thread if anyone else experiencing similar problems.
This package uploaded to CRAN with no problems on second attempt so likely just
bad timing.
Interesting that broom is failing CRAN tests though. I will keep an eye on
that as I import it with my package.
Georgie
-Original Message-
From: Aphalo, Pedro J
Sent: 10 September 2019 15:39
To: Hadley Wickham ; Georgina Anderson
Cc: r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] OFFICIAL: R-devel check error: package or NAMESPACE
load failed, there is no package called broom
It seems that 'broom' itself is failing tests on CRAN under Windows oldrel, and
this may cause it to be missing from the R installation running tests on CRAN.
See:
https://cran.r-project.org/web/checks/check_results_broom.html
Pedro.
--
Pedro J. Aphalo
University Lecturer, Principal Investigator Organismal and Evolutionary Biology
(OEB) Research Programme University of Helsinki Finland
> -Original Message-
> From: R-package-devel On
> Behalf Of Hadley Wickham
> Sent: 10 September 2019 15:16
> To: Georgina Anderson
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] OFFICIAL: R-devel check error: package or
> NAMESPACE load failed, there is no package called broom
>
> This works for me locally too, so I'd recommend trying win-devel again.
> Sometimes you catch it in an inconsistent state and your check fails
> for reasons unrelated to your package.
>
> Hadley
>
> On Sat, Sep 7, 2019 at 3:50 PM Georgina Anderson
> wrote:
> >
> > OFFICIAL
> >
> > Hi
> >
> > Any help with the following update to my package PHEindicatormethods
> would be appreciated.
> >
> > I have made a very minor change to the package to fix dependencies
> > on the
> tidyr:nest() function as tidyr v 1.0.0 is due to be released with
> breaking changes on 9th September.
> > The version I am trying to upload to CRAN is 1.1.5 available here:
> > https://github.com/PublicHealthEngland/PHEindicatormethods
> >
> >
> > When I run devtools::check_win_devel locally (Windows 10 laptop, R
> > 3.6.1, rStudio 1.2.1335) it passes with no NOTES, ERRORS or WARNINGS
> > (locally it also passes devtools::check_win on release and
> > oldrelease and devtools::check_rhub)
> >
> > When I submit to CRAN I have been notified that package
> PHEindicatormethods_1.1.5.tar.gz does not pass the incoming checks
> automatically, signposting failing pre-tests on Windows:
> >
> > * using R Under development (unstable) (2019-09-02 r77130)
> >
> > * using platform: x86_64-w64-mingw32 (64-bit)
> >
> > * using session charset: ISO8859-1
> >
> >
> >
> > This is the log file available for 7 days:
> > https://win-builder.r-project.org/incoming_pretest/PHEindicatormetho
> > ds _1.1.5_20190905_224346/Windows/00check.log
> >
> > Below are two sections from the log that show the errors:
> >
> >
> > > library('PHEindicatormethods')
> >
> > Error: package or namespace load failed for 'PHEindicatormethods' in
> loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> >
> > there is no package called 'broom'
> >
> > Execution halted
> >
> > ** running examples for arch 'x64' ... ERROR
> >
> > Running examples in 'PHEindicatormethods-Ex.R' failed
> >
> > The error occurred in:
> >
> > R Under development (unstable) (2019-09-02 r77130) -- "Unsuffered
> Consequences"
> >
> > Copyright (C) 2019 The R Foundation for Statistical Computing
> >
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> >
> >
> > Error: processing vignette 'WorkedExamples_phe_sii.Rmd' failed with
> diagnostics:
> >
> > package or namespace load failed for 'PHEindicatormethods' in
> loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
> >
> > there is no package called 'broom'
> >
> > --- failed re-building 'WorkedExamples_phe_sii.Rmd'
> >
> > SUMMARY: processing the following file failed:
> >
> > 'WorkedExamples_phe_sii.Rmd'
> >
> > Error: Vignette re-building failed.
> >
> > Execution halted
> >
> > I have checked the broom package and its upstream dependency on
> > generics -
> I notice the tidy() function was moved from broom to generics a while
> back but this was before I submitted the current version (1.1.3) of my
> package to CRAN so not sure this can be the problem, although one of
> my functions does reference broom::tidy(). The evidence seems to
> point to changes in R-devel causing something in my package to break
> but without being able to reproduce the errors seen by CRAN I'm finding it
> difficult to pinpoint the problem.
> >
> > Thanks
> > Georgie
> >
> >
> >
> *
> *
> > The information contained in the EMail and any attachments is
> > confidential and intended solely and for the attention and use of
> > the named addressee(s). It may not be disclosed to any other person
> > without the express authority of Public Health England, or the
> > inten
Re: [R-pkg-devel] R, BLAS, and FCLEN
A followup question: Is it possible to call a BLAS/LAPACK subroutine, where one parameter is character, from FORTRAN (77) code called by .Fortran? (No problem "in the past".) And if yes, how? Documentation describes calls from C to Fortran and vice versa, but not this situation (AFAICS). Yes, I know that .Fortran is not well seen these days, but my fortran code is ancient, from the before-R era, and I would like to leave it as-is. G, Den 2019-09-01 kl. 21:46, skrev Göran Broström: On 2019-08-31 18:47, Göran Broström wrote: I'm having difficulties updating my package eha: When I run standard checks 'at home' everything is fine, but 'CRAN-submissions' reports (among other things): geomsup.f:324:9: warning: type of ‘dgemv’ does not match original declaration [-Wlto-type-mismatch] 324 | & one, score, ione) | ^ /home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type mismatch in parameter 12 107 | F77_NAME(dgemv)(const char *trans, const int *m, const int *n, | ^ This is odd since the LAPACK subroutine dgemv takes only 11 parameters. However, in include/R_ext/BLAS.h we have F77_NAME(dgemv)(const char *trans, const int *m, const int *n, const double *alpha, const double *a, const int *lda, const double *x, const int *incx, const double *beta, double *y, const int *incy FCLEN); with a 12th parameter FCLEN?? How am I supposed to fix this, and what the ... is FCLEN? googling leads to nothing useful (for me). It seems as if R is redefining some standard LAPACK routines. Also a note I do not understand (in this context): note: type ‘void’ should match type ‘long int’ Any help is much appreciated. Best, Göran PS. How can I trigger these Warnings 'at home'? See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks to Uwe Ligges). Another relevant document seems to be (2019-05-15): https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html First sentence: "Recent version of the GNU Fortran compiler (7, 8, 9) include optimizations that break interoperability between C and Fortran code with BLAS/LAPACK." And later: "For the time being, everyone should use -fno-optimize-sibling-calls with GFortran version 7 and newer." G, __ 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 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] GSL update on CRAN
Hi, I hope you don't mind me asking again: Does anybody have an idea on how to implement the whole GSL library in my package? I was not able to find sth. on Google. Whom should I contact for asking whether it is possible to update GSL for Windows on CRAN? There were no warnings or errors in the CRAN checks for debian. For Windows on CRAN, the compiler gives only an error where a GSL routine of version 2.3 is used. Best wishes Raphael On Fri, 06 Sep 2019 08:19:37 +0200 "Raphael Hartmann" wrote: > >Hello, > >I developed an R package that requires at least version 2.3 of GSL >(ftp://ftp.gnu.org/gnu/gsl/). The newest version is 2.6. > >Version 2.3 is now available for over two years, and I was wondering >whether it was possible to update GSL on the win-builder? I would >really appreciate it. Without it my package will be rejected on CRAN. > >Or is there an option to include the whole GSL library in the package? > >On my machines (two debian based and one Windows server 16 and one >Windows 10) the package passes the checks of "R CMD check --as-cran". >On builder.r-hub.io with Windows server 12 it is also successful. > >I would be glad for any advice / suggestions / hints. > > >Best wishes >Raphael > >__ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Albert-Ludwigs-Universität Freiburg Institute of Psychology, Cognition, Action, and Sustainability Engelbergerstrasse 41 D-79085 Freiburg Phone: +49 761 203 2465 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
