Re: [R-pkg-devel] CRAN test complaints about package that passes most platforms
> On Aug 11, 2023, at 1:41 PM, J C Nash wrote: > > - Is there an M1Mac test platform to which packages can be submitted? Brian > Ripley did have one, but trying the link I used before seems not to present > a submission dialog. Perhaps: https://mac.r-project.org/macbuilder/submit.html -Roy ** "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
[R-pkg-devel] CRAN test complaints about package that passes most platforms
My nlsr package was revised mid-February. After CRAN approved it, I got a message that it was "failing" M1Mac tests. The issue turned out to be ANOTHER package that was being used in an example in a vignette. Because M1 does not provide the IEEE 754 80 bit registers, a method in package minqa did not "converge", that is, it did not pass a termination test. Relaxing a tolerance got a "pass" on the test service for M1 Mac then available. This issue can be found by searching the web, though it probably deserves some clarity in R documentation somewhere. The presentation of such problems can, of course, take many forms. There was a minor revision to nlsr in May to rationalize the names of some functions to produce summary information about solutions. This seemed to give no issues until now. Two days ago, however, I received a msg that the (unchanged!) package is failing tests on M1 and on Fedora clang r-devel tests in building some vignettes. The messages are about pandoc and a missing file "framed.sty". All other tests showing on CRAN are OK. When I try with R-hub I seem to get even more complaints than the messages from CRAN, but about the same issues, and about vignette building. 2 queries: - Is anyone else getting similar messages? If so, it may be useful to share notes to try to get this resolved. It seems within reason that the issue is some unfortunate detail in Fedora and M1 that interacts with particular syntax in the vignette, or that the setup of those machines is inadequate. Comparing notes may reveal what is causing complaints and help to fix either in the .Rmd vignettes or in the pandoc structure. - Is there an M1Mac test platform to which packages can be submitted? Brian Ripley did have one, but trying the link I used before seems not to present a submission dialog. I'd like to be helpful, but have a suspicion that a humble package developer is being used as a stooge to find and fix software glitches outside of R. However, if it's a matter of an unfortunate mismatch of document and processor, I'll be happy to help document and fix it. It would be a pity if vignettes cause enough trouble that developers simply don't include them. Best, John Nash __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] preventing auto-update of R and c2d4u r-cran-* packages on Ubuntu 22.04
On 11 August 2023 at 07:54, Thomas Petzoldt wrote: | After moving this discussion to R-SIG-Debian | (https://stat.ethz.ch/pipermail/r-sig-debian/2023-August/thread.html), | Dirk Eddelbuettel suggested five different approaches. | | I made indeed a snapshot (a local copy) of the complete "site-library" | folder to another place of the file system (e.g. | "site-library-snapshot"). In the .Renviron file of the shiny user, the | environment variable R_LIBS_USER then points to this location. The base | packages from "library" are conservative, so I decided to use them from | the original position. | | Finally, an rmarkdown script provided by the shiny-server can report the | value of .libPaths() and versions and locations of installed packages: | | installed.packages()[,2:3] | | This works well, except for a package that contained relative symbolic | links to the file system. Perfect, and thanks for reporting back. One other exception would be 'bad' packages with a hard code installation path (via rpath or install_name_tool) but luckily CRAN outlaws that so it should be rare (but 'been there, done that' and had to fix a package or two of mine). In short, 'should work most of the time as described here'. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
