[R-pkg-devel] Cryptic error on Windows but not Debian

2023-11-18 Thread Adam
I pass on Debian but have an ERROR on Windows dev. version of R. I'm
confused for 2 reasons:

1. The example should not be running in the first place, as it has
@examplesIf megamation:::mm_has_creds(), which should be FALSE for CRAN (it
depends on env. variables)

2. I see the example printed twice with strange formatting?

Running examples in 'megamation-Ex.R' failed
The error most likely occurred in:

> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: mm_get
> ### Title: Get data
> ### Aliases: mm_get
>
> ### ** Examples
>
> ## Don't show:
> if (megamation:::mm_has_creds()) (if (getRversion() >= "3.4") withAutoprint 
> else force)({ # examplesIf
+ ## End(Don't show)
+ # Get all work orders from Jan. 2023 containing trades ADMIN and IT:
+
+ # First create a Date-type vector
+ jan_2023 <- seq.Date(
+   as.Date("2023-01-01"),
+   as.Date("2023-01-31"),
+   by = "day"
+ )
+
+ # Then prefix the trade values with the "containing" modifier "[]"
+ # since trade is a list column in the work order table
+ admin_and_it <- c("[]ADMIN", "[]IT")
+
+ mm_get("workorder", date = jan_2023, trade = admin_and_it)
+ ## Don't show:
+ }) # examplesIf
> jan_2023 <- seq.Date(as.Date("2023-01-01"), as.Date("2023-01-31"), by = "day")
> admin_and_it <- c("[]ADMIN", "[]IT")
> mm_get("workorder", date = jan_2023, trade = admin_and_it)
Error in `req_perform()`:
! Failed to parse error body with method defined in `req_error()`.
Caused by error in `httr2::resp_body_json()`:
! Unexpected content type "text/html".
• Expecting type "application/json" or suffix "json".


Best,
Adam

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Cryptic error on Windows but not Debian

2023-11-18 Thread Adam
Dear Ivan,

Thank you for explaining in such depth. I had not submitted to CRAN before.
I will look into tools::R_user_dir().

- May you point me toward the policy that the package should not edit
.Renviron? I thought I was following best practices, but maybe things have
changed. For instance, this package changes the .Renvrion GitHub -
ropensci/qualtRics: Download ⬇️ Qualtrics survey data directly into R!
<https://github.com/ropensci/qualtRics> with the difference being that they
do not use withr::defer().

- It occured to me I need skip_on_cran() for the test "mm_authorize() sets
credentials". That is because testing_key(), which refers to an env var, is
not available on CRAN.  Even without testing_key(), the test
"mm_authorize() sets credentials" does not error. It gives a message

-- Skip (Line 4): mm_authorize() sets credentials --


Reason: Can't find envvar MEGAMATION_KEY_HTTR2


but since CMD check does not print this as a NOTE, and testthat does not
print it either, I was unaware of it.

Best,
Adam


On Sat, Nov 18, 2023 at 12:35 PM Ivan Krylov  wrote:

> В Fri, 17 Nov 2023 17:08:13 -0500
> Adam  пишет:
>
> > 1. The example should not be running in the first place, as it has
> > @examplesIf megamation:::mm_has_creds(), which should be FALSE for
> > CRAN (it depends on env. variables)
>
> The tarball I have fished from CRAN says version 0.2.0, but your GitHub
> repo <https://github.com/asadow/megamation/> says version 0.1.0.
> (For best results, help us to help you by showing the source code.) Have
> you submitted this package to CRAN before? Did it previously contain a
> test that ran mm_authorize(overwrite = TRUE)?
>
> This is incredibly weird, but since your examples don't seem to run
> Sys.setenv() and have never ran mm_authorize(), my only low-probability
> guess is that the .Renviron changes from mm_authorize(overwrite = TRUE)
> in your tests/testthat/test-authorize.R turned out to persist from the
> check run of the previous version of your package.
>
> It may be a better idea to make use of tools::R_user_dir() in
> mm_authorize() and the rest of the package (and to be much more careful
> when unit-testing this function: changing user files and other global
> state in tests and examples is against CRAN policy) and leave
> ~/.Renviron for the user to edit.
>
> > 2. I see the example printed twice with strange formatting?
>
> This is how @examplesIf works: it wraps your code in if (condition)
> withAutoprint { your code }. The first time is R echoing the source
> code back; the second time is R printing every line of the
> withAutoprint(...) code block before it's executed. withAutoprint helps
> you see the exact line where your example fails; otherwise you'd see
> the whole block of code start to execute and then fail somewhere.
>
> --
> Best regards,
> Ivan
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Cryptic error on Windows but not Debian

2023-11-18 Thread Adam
Thank you dearly, Simon, for pointing out the policy. May a test do the
following?

1. Save the user's original value for env var X.
2. Write a new value for env var X during a test.
3. Write back the original value for env var X at the end of the test.

An example:

test_that("mm_authorize() sets credentials", {
  skip_on_cran()
  key_original <- mm_key()
  url_original <- mm_url()
  withr::defer({
mm_authorize(
  key = key_original,
  url = url_original,
  overwrite = TRUE
)
  })
  mm_authorize(
key = "1",
url = "https://api.megamation.com/uw/joe/";,
overwrite = TRUE
  )
  expect_false(
endsWith(Sys.getenv("MEGAMATION_URL"), "/")
  )
})

Best,
Adam


On Sat, Nov 18, 2023 at 4:52 PM Simon Urbanek 
wrote:

> Adam,
>
>
> > On Nov 19, 2023, at 9:39 AM, Adam  wrote:
> >
> > Dear Ivan,
> >
> > Thank you for explaining in such depth. I had not submitted to CRAN
> before.
> > I will look into tools::R_user_dir().
> >
> > - May you point me toward the policy that the package should not edit
> .Renviron?
>
>
> It is the policy you have agreed to when submitting your package to CRAN:
>
> "CRAN Repository Policy
> [...]
> The code and examples provided in a package should never do anything which
> might be regarded as malicious or anti-social. The following are
> illustrative examples from past experience.
> [...]
>  - Packages should not write in the user’s home filespace (including
> clipboards), nor anywhere else on the file system apart from the R
> session’s temporary directory. [...]
>   For R version 4.0 or later (hence a version dependency is required or
> only conditional use is possible), packages may store user-specific data,
> configuration and cache files in their respective user directories obtained
> from tools::R_user_dir(), provided that by default sizes are kept as small
> as possible and the contents are actively managed (including removing
> outdated material).
> "
>
> Cheers,
> Simon
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Cryptic error on Windows but not Debian

2023-11-18 Thread Adam
Thank you so much for clarifying this.

Best,
Adam


On Sat, Nov 18, 2023 at 6:14 PM Simon Urbanek 
wrote:

> Adam,
>
> no, it is your code in mm_authorize() that violates the CRAN policy, it is
> not about the test. You may not touch user's .Renviron and there is no
> reason to resort to such drastic measures. If you want to cache user's
> credentials, you have to do it in a file located via tools::R_user_dir().
>
> Cheers,
> Simon
>
>
> On Nov 19, 2023, at 12:07 PM, Adam  wrote:
>
> Thank you dearly, Simon, for pointing out the policy. May a test do the
> following?
>
> 1. Save the user's original value for env var X.
> 2. Write a new value for env var X during a test.
> 3. Write back the original value for env var X at the end of the test.
>
> An example:
>
> test_that("mm_authorize() sets credentials", {
>   skip_on_cran()
>   key_original <- mm_key()
>   url_original <- mm_url()
>   withr::defer({
> mm_authorize(
>   key = key_original,
>   url = url_original,
>   overwrite = TRUE
> )
>   })
>   mm_authorize(
> key = "1",
> url = "https://api.megamation.com/uw/joe/";,
> overwrite = TRUE
>   )
>   expect_false(
> endsWith(Sys.getenv("MEGAMATION_URL"), "/")
>   )
> })
>
> Best,
> Adam
>
>
> On Sat, Nov 18, 2023 at 4:52 PM Simon Urbanek 
> wrote:
>
>> Adam,
>>
>>
>> > On Nov 19, 2023, at 9:39 AM, Adam  wrote:
>> >
>> > Dear Ivan,
>> >
>> > Thank you for explaining in such depth. I had not submitted to CRAN
>> before.
>> > I will look into tools::R_user_dir().
>> >
>> > - May you point me toward the policy that the package should not edit
>> .Renviron?
>>
>>
>> It is the policy you have agreed to when submitting your package to CRAN:
>>
>> "CRAN Repository Policy
>> [...]
>> The code and examples provided in a package should never do anything
>> which might be regarded as malicious or anti-social. The following are
>> illustrative examples from past experience.
>> [...]
>>  - Packages should not write in the user’s home filespace (including
>> clipboards), nor anywhere else on the file system apart from the R
>> session’s temporary directory. [...]
>>   For R version 4.0 or later (hence a version dependency is required or
>> only conditional use is possible), packages may store user-specific data,
>> configuration and cache files in their respective user directories obtained
>> from tools::R_user_dir(), provided that by default sizes are kept as small
>> as possible and the contents are actively managed (including removing
>> outdated material).
>> "
>>
>> Cheers,
>> Simon
>>
>>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Cryptic error on Windows but not Debian

2023-11-18 Thread Adam
Thank you, Chris. I plan to explore the method you described as simply
removing the authorize function would be a shame. Your description of the
past was certainly worthwhile and enlightening.

Best,
Adam


On Sat, Nov 18, 2023 at 6:40 PM Kenny, Christopher <
christopherke...@fas.harvard.edu> wrote:

> Rather than using tools::R_user_dir(), you can also ask the user for a
> path where they would like to save the information to. This allows you to
> test it with a temporary directory file, but would allow the user to
> specify their .Renviron file, if they so choose. This acts as a middle
> ground managing a separate package-specific file and storing it as an
> environmental variable. This is how I approach it in a handful of packages,
> including `feltr` (see
> https://github.com/christopherkenny/feltr/blob/HEAD/R/felt_key.R) and
> `bskyr` (see
> https://github.com/christopherkenny/bskyr/blob/main/R/auth_user.R).
>
> For what it's worth, some of this confusion may come from a relatively
> recent change in interpretation of the policy mentioned below by Simon
> (even though the text has long read that way). For years, CRAN allowed
> packages which had the practice of opting into writing to the default
> .Renviron file. That old reading comports with the example you point to in
> qualtRics, where the writing is controlled by the `install` argument, with
> a default of FALSE. Since sometime in the last year, the interpretation was
> updated and you are now met with a message from the volunteer which states:
> "Please ensure that your functions do not write by default or in your
> examples/vignettes/tests in the user's home filespace (including the
> package directory and getwd()). This is not allowed by CRAN policies.
> Please omit any default path in writing functions. In your
> examples/vignettes/tests you can write to tempdir()."
>
> The approach used in `feltr` and other packages to explicitly require a
> path as an argument appears to be okay with the new reading of the policy.
> (At least, the CRAN volunteers seem to accept packages which use this
> approach.)
>
> Best,
> Chris
>
>
> From: R-package-devel  on behalf
> of Simon Urbanek 
> Sent: Saturday, November 18, 2023 6:14 PM
> To: Adam 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] Cryptic error on Windows but not Debian
>
> Adam,
>
> no, it is your code in mm_authorize() that violates the CRAN policy, it is
> not about the test. You may not touch user's .Renviron and there is no
> reason to resort to such drastic measures. If you want to cache user's
> credentials, you have to do it in a file located via tools::R_user_dir().
>
> Cheers,
> Simon
>
>
> > On Nov 19, 2023, at 12:07 PM, Adam  wrote:
> >
> > Thank you dearly, Simon, for pointing out the policy. May a test do the
> following?
> >
> > 1. Save the user's original value for env var X.
> > 2. Write a new value for env var X during a test.
> > 3. Write back the original value for env var X at the end of the test.
> >
> > An example:
> >
> > test_that("mm_authorize() sets credentials", {
> >   skip_on_cran()
> >   key_original <- mm_key()
> >   url_original <- mm_url()
> >   withr::defer({
> > mm_authorize(
> >   key = key_original,
> >   url = url_original,
> >   overwrite = TRUE
> > )
> >   })
> >   mm_authorize(
> > key = "1",
> > url = "https://api.megamation.com/uw/joe/ <
> https://api.megamation.com/uw/joe/>",
> > overwrite = TRUE
> >   )
> >   expect_false(
> > endsWith(Sys.getenv("MEGAMATION_URL"), "/")
> >   )
> > })
> >
> > Best,
> > Adam
> >
> >
> > On Sat, Nov 18, 2023 at 4:52 PM Simon Urbanek <
> simon.urba...@r-project.org <mailto:simon.urba...@r-project.org>> wrote:
> > Adam,
> >
> >
> > > On Nov 19, 2023, at 9:39 AM, Adam  asebsadow...@gmail.com>> wrote:
> > >
> > > Dear Ivan,
> > >
> > > Thank you for explaining in such depth. I had not submitted to CRAN
> before.
> > > I will look into tools::R_user_dir().
> > >
> > > - May you point me toward the policy that the package should not edit
> .Renviron?
> >
> >
> > It is the policy you have agreed to when submitting your package to CRAN:
> >
> > "CRAN Repository Policy
> > [...]
> > The code and examples provided in a package should never do anything
> which might be regarded as malicious or anti-social. The following are
> illus

[R-pkg-devel] '! LaTeX Error: Option clash for package xcolor' on linux-based builds

2018-12-20 Thread Adam Price
Hi,

I am currently having an issue getting past a warning that's occurring on
linux based builds for my vignette.  The warning is: "! LaTeX Error: Option
clash for package xcolor."

The check results are here:
https://cran.r-project.org/web/checks/check_results_DEVis.html

I currently cannot reproduce this issue on my side, and travis-ci checks do
not seem to produce this warning.  I can only see it currently when
submitting an update to my package and failing the CRAN auto-checks.

I have recently changed from PDF vignette to html-based, and am not sure
why LaTeX packages would even be loading in this case.  I have attempted to
correct for it based on this post (
https://github.com/haozhu233/kableExtra/issues/274) which claims the issue
is a conflict between kableExtra and xcolor.

Some relevant sections of code from the vignette might include:
"
vignette: |
  %\VignetteIndexEntry{DEVis}
  %\usepackage[utf8]{inputenc}
  %\usepackage[table]{xcolor}
  %\VignetteEngine{knitr::knitr}
---

```{r loadData, echo = F, eval = TRUE}
#load("../data/exampleData.Rda")
knitr::opts_knit$set(root.dir = '../vignettes/')
knitr::opts_chunk$set(fig.path='figure/graphics-',
 cache.path='cache/graphics-',
 fig.align='center',
 external=TRUE,
 echo=TRUE,
 warning=FALSE,
 fig.pos='H'
)
  a4width<- 8.3
  a4height<- 11.7
library(kableExtra)
library(rmarkdown)
library(knitr)
options(knitr.table.format = "html")
options(kableExtra.latex.load_packages = FALSE)
"


The full package code can be found here: https://github.com/price0416/DEvis

I would appreciate any insight anyone can offer into this issue, as I
cannot update my package until I get to the bottom of this!  Thanks very
much in advance!

Best,
-Adam

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


[R-pkg-devel] LaTeX warnings on debian builds only

2019-01-18 Thread Adam Price
Hi,

I am currently having an issue getting past a warning that's occurring on
linux based builds for my vignette.  The warning is: "! LaTeX Error: Option
clash for package xcolor."

The check results are here:
*https://win-builder.r-project.org/incoming_pretest/DEVis_1.0.1_20181220_164555/Debian/00check.log
<https://win-builder.r-project.org/incoming_pretest/DEVis_1.0.1_20181220_164555/Debian/00check.log>*

Windows and OS X builds work fine, but I don't have access to a debian
machine that I can reproduce this on.  I currently cannot reproduce this
issue on my side, and travis-ci checks do not seem to produce this warning
for linux on ubuntu.  I can only see it currently when submitting an update
to my package and failing the CRAN auto-checks.

I have recently changed from PDF vignette to html-based, and am not sure
why LaTeX packages would even be loading in this case.  I have attempted to
correct for it based on this post (
https://github.com/haozhu233/kableExtra/issues/274
) which claims the issue is a conflict between kableExtra and xcolor.

Some relevant sections of code from the vignette might include:
"
vignette: |
  %\VignetteIndexEntry{DEVis}
  %\usepackage[utf8]{inputenc}
  %\usepackage[table]{xcolor}
  %\VignetteEngine{knitr::knitr}
---

```{r loadData, echo = F, eval = TRUE}
#load("../data/exampleData.Rda")
knitr::opts_knit$set(root.dir = '../vignettes/')
knitr::opts_chunk$set(fig.path='figure/graphics-',
 cache.path='cache/graphics-',
 fig.align='center',
 external=TRUE,
 echo=TRUE,
 warning=FALSE,
 fig.pos='H'
)
  a4width<- 8.3
  a4height<- 11.7
library(kableExtra)
library(rmarkdown)
library(knitr)
options(knitr.table.format = "html")
options(kableExtra.latex.load_packages = FALSE)
"


The full package code can be found here: https://github.com/price0416/DEvis

I would appreciate any insight anyone can offer into this issue, as I
cannot update my package until I get to the bottom of this!  Thanks very
much in advance!

Best,
-Adam

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


[R-pkg-devel] Help passing CRAN pre-checks

2025-05-12 Thread Adam Loy
Hi all,

I am having trouble getting past the pre-checks for CRAN, but things check
out in my testing localling in the cloud. I get this message on Debian:

Error: package or namespace load failed for ‘HLMdiag’ in
dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object
'/srv/hornik/tmp/CRAN_pretest/HLMdiag.Rcheck/00LOCK-HLMdiag/00new/HLMdiag/libs/HLMdiag.so':

/srv/hornik/tmp/CRAN_pretest/HLMdiag.Rcheck/00LOCK-HLMdiag/00new/HLMdiag/libs/HLMdiag.so:
undefined symbol: dgetri_
Error: loading failed

The package uses RcppArmadillo so I thought the issue was an error in
the makefile, but I think that checks out.

Any help would be appreciated. My codebase is on github:
https://github.com/aloy/HLMdiag


Thank you,

Adam

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Problem with package containing spatial data

2023-02-08 Thread Adam H. Sparks
Hi Igor,
I’ve a couple packages that have spatial data in them that I maintain. I’ve 
opted to package up the data as a geopackage file and import it as an {sf} 
object. Edzer Pebesma suggests this to circumvent changes in the {sf} package 
from affecting native {sf} objects that are distributed as part of a package. 
Maybe this is an option for you?

In https://github.com/adamhsparks/extractOz, see /inst/extdata for the 
geopackage file and https://github.com/adamhsparks/extractOz/blob/main/R/data.R 
for handling the data importing and making available in the R session on 
package load.

Best,
Adam

> On 8 Feb 2023, at 10:32 pm, Igor L  wrote:
> 
> Hello all,
> 
> I'm developing a package that contains spatial data about public safety in
> Rio de Janeiro.
> 
> The problem is that when I use the usethis::use_data function which
> transforms the shapefile data into a file with the .rda extension, I cannot
> use the geometry attribute to create a map.
> 
> E.g.:
> 
> # Raw-data script:
> 
> spatial_aisp <- sf::st_read('data-raw/shp_aisp/lm_aisp_2019.shp')
> 
> plot(spatial_aisp) # works
> 
> # Same data from .rda file after use usethis::use_data(spatial_aisp,
> overwrite = TRUE)
> 
> x <- ispdata::spatial_aisp
> 
> plot(x) # do not work
> 
> Error message:
> Error in data.matrix(x) :
>  'list' object cannot be coerced to type 'double'
> 
> 
> This is happening with all spatial data in the package. I'm using lazydata:
> true and have already disabled file compression options, but the problem
> persists.
> 
> Any ideas?
> 
> Scripts can be accessed at https://github.com/igorlaltuf/ispdata
> 
> Thanks!
> -- 
> *Igor Laltuf Marques*
> Economist (UFF)
> Master in Urban and Regional Planning (IPPUR-UFRJ)
> Researcher at ETTERN and CiDMob Laboratories
> https://igorlaltuf.github.io/
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] CRAN rules re. web scraping?

2020-01-27 Thread Adam H Sparks
 file, header = header, sep = sep, quote =
> > quote, :
> > more columns than column names
> > Calls: read.testURLs -> read.csv -> read.table
> >
> > That does not conform to the policy on Internet access, not least as no
> > attempt is made to check if the file was created, let alone that it has
> > the expected layout. Nor does it conform to the policy on not writing
> > anywhere in the file space (and that shows on its CRAN results page too).
> >
> > Please correct ASAP and before Feb 4 to safely retain the package on
> CRAN.
> >
> > --
> > Brian D. Ripley,  rip...@stats.ox.ac.uk
> > Emeritus Professor of Applied Statistics, University of Oxford
> >
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> **
> "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
>


-- 
Dr Adam H. Sparks
http://adamhsparks.netlify.com/
Associate Professor of Field Crops Pathology   |   Centre for Crop Health
|  Office C313

Phone (+61) 07 46311948  |  Mobile 0415 489 422 | Twitter @adamhsparks
<https://twitter.com/adamhsparks>

Institute for Life Sciences and the Environment |  Research and Innovation
Division
University of Southern Queensland | Toowoomba, Queensland | 4350 | Australia

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


[R-pkg-devel] Still Getting an Error in Winbuilder

2020-09-17 Thread Adam H Sparks
Hi all-
I’ve followed Nick’s thread about the error on Winbuilder with Naniar with 
interest, since at the same time I was having issues with GSODR, 
https://github.com/ropensci/GSODR <https://github.com/ropensci/GSODR> as well. 
I was hoping that the issue was resolved but I’m still getting the same error 
message that Nick reported and I experienced last month as well when submitting 
to Winbuilder. I get the same response both with the devel and current release 
tests. Today, the response has been much faster, previously it would take >24 
hrs for me to get the following response. 

* using log directory 'd:/RCompile/CRANguest/R-devel/GSODR.Rcheck'
* using R Under development (unstable) (2020-09-09 r79174)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'GSODR/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'GSODR' version '2.1.2'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... ERROR
Check process probably crashed or hung up for 20 minutes ... killed
Most likely this happened in the example checks (?),
if not, ignore the following last lines of example output:

 End of example output (where/before crash/hang up occured ?) 
Here’s the submission URL response 
https://win-builder.r-project.org/4Y3Ffqcq25n1 
<https://win-builder.r-project.org/4Y3Ffqcq25n1> for my latest attempt. 

Is there some way to approach this that handles the issue satisfactorily? I’ve 
a simple bug fix update ready to go but want to be sure and check it with 
Winbuilder first. It it passes build tests on R HUB for Windows and Ubuntu and 
it passes build with no warnings, errors, or notes for me on macOS locally, as 
well as on GitHub actions (Windows, macOS, and Ubuntu).

With thanks,
Adam


--
Dr Adam H. Sparks 
Associate Professor of Field Crops Pathology | Centre for Crop Health 
Institute for Agriculture and the Environment | Research and Innovation 
Division 
University of Southern Queensland | Toowoomba, Queensland | 4350 | Australia 

https://www.adamhsparks.com/




[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel