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

[Spencer Graves]

  Thanks very much to Iñaki Ucar, Adam H Sparks, and Roy 
Mendelssohn for their replies that helped me understand what I needed to 
do to fix problems identified in the CRAN Checks.  I believe that those 
problems are not fixed in the development version of Ecfun available at 
"https://github.com/sbgraves237/Ecfun".  The package still needs more 
work, but I will make Prof. Ripley's Feb. 4 deadline.



  Thanks again,
  Spencer Graves


On 2020-01-23 01:55, Iñaki Ucar wrote:

On Thu, 23 Jan 2020 at 02:49, Spencer Graves
 wrote:

Hello, All:


GOOD NEWS AND BAD NEWS:


* First the good news:  I heard from Brian Ripley;  see below.
His web site says, "He retired in August 2014 on grounds of ill health."
(http://www.stats.ox.ac.uk/~ripley/)  I was pleased to see that he seems
to be well enough to send me the email below.


* BAD NEWS:  My Ecfun package is violating current CRAN rules
regarding "not writing anywhere in the file space".  (See below.)


QUESTION:


How do you suggest I respond to this?


It's hard for me to fix, because I cannot replicate the error and
I don't understand the rules Prof. Ripley is trying to enforce. The
"CRAN Package Check Results for" this package show an error on 1
platform (r-devel-linux-x86_64-fedora-gcc), NOTEs on 3 platforms
(Fedora-clang and Debian), and "OK" on 9 others.  I can program selected
tests not to run on CRAN, e.g., with (!fda::CRAN()).


However, I suspect I should be able to do better than that.


Suggestions?

The message from Prof. Ripley is crystal-clear, and exposes two issues
(Internet access, writing files) that have been discussed many times
in this list. A quick scan of the CRAN policy [1] yields:

- Packages which use Internet resources should fail gracefully with an
informative message if the resource is not available (and not give a
check warning nor error).

- 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.

[1] https://cran.r-project.org/web/packages/policies.html

Iñaki


Thanks,
Spencer Graves


p.s.  The development version of this package is available at
"https://github.com/sbgraves237/Ecfun";.


https://cloud.r-project.org/web/checks/check_results_Ecfun.html


 Forwarded Message 
Subject:CRAN package Ecfun
Date:   Tue, 21 Jan 2020 21:26:02 +
From:   Prof Brian Ripley 
Reply-To:   CRAN 
To: Spencer Graves 
CC: CRAN 



This has been intermittently failing its checks for a week: different
check runs failed (in the 24h prior to) the 14th, 15th, 17th and today.
The current failure is

Check: examples
Result: ERROR
Running examples in ‘Ecfun-Ex.R’ failed
The error most likely occurred in:

  > ### Name: read.testURLs
  > ### Title: Read a file produced by testURLs
  > ### Aliases: read.testURLs
  > ### Keywords: IO
  >
  > ### ** Examples
  >
  > # Test only 2 web sites, not the default 4,
  > # and test only twice, not the default 10 times:
  > tst <- testURLs(c(
+ PVI="http://en.wikipedia.org/wiki/Cook_Partisan_Voting_Index";,
+ house="http://house.gov/representatives";),
+ n=2, maxFail=2)
1
1579634784, PVI, TRUE 0.828
1579634785, house, FALSE 0.051
1579634785, house, FALSE 0.048
2
1579634785, PVI, TRUE 0.043
1579634785, house, FALSE 0.11
1579634785, house, FALSE 0.035
  >
  > # The above should have created a file 'testURLresults.csv'
  > # in the working directory. Read it.
  >
  > dat <- read.testURLs()
Error in read.table(file = 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




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

Re: [R-pkg-devel] need help addressing future timestamp error

[Gábor Csárdi]

Yes, the time of R-hub's Solaris machine is probably off

Gabor

On Thu, Jan 23, 2020 at 9:17 PM Merlise Clyde, Ph.D.  wrote:
>
> I am checking my package for Solaris via rhub and this week have encountered 
> the following error:  "This system is set to the wrong time: please fix".  
> The output suggests that the time is off by 1 hour.  This occurs only on 
> Solaris, but I am not sure if that is because that is the only platform 
> checking timestamps and it is a problem in my setup -or- it is problem with 
> the rhub configuration.
>
> I have tried setting my MAC to use UTC timezone, but still encounter the 
> error. I am also encountering this when building the package under fedora and 
> submitting via rhub.
> (source code is at https://github.com/merliseclyde/BAS)
>
> Any suggestions ?   The error seems to stop the build, so I cannot verify if 
> the other parts of the check (testthat output in particular) are successful, 
> which are needed for the CRAN submission.
>
> Thanks in advance - Merlise
>
> Build ID:   BAS_1.5.5.tar.gz-44c32b29bc7a4127be3adfc60c81e330
> Platform:   Oracle Solaris 10, x86, 32 bit, R-patched (experimental)
> Submitted:  16 minutes 55 seconds ago
> Build time: 16 minutes 54.1 seconds
> ERRORS:
>
>
> * checking for future file timestamps ... ERROR
> This system is set to the wrong time: please correct
>system: 2020-01-23 21:14 (UTC)
>   correct: 2020-01-23 20:14 (UTC)
>
>
>
> Merlise A Clyde
> Professor Department of Statistical Science
> Duke University
> http://stat.duke.edu/~clyde
>
> cl...@duke.edu
> 919 681 8440
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> 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-pkg-devel] need help addressing future timestamp error

[Merlise Clyde, Ph.D.]

I am checking my package for Solaris via rhub and this week have encountered 
the following error:  "This system is set to the wrong time: please fix".  The 
output suggests that the time is off by 1 hour.  This occurs only on Solaris, 
but I am not sure if that is because that is the only platform checking 
timestamps and it is a problem in my setup -or- it is problem with the rhub 
configuration.

I have tried setting my MAC to use UTC timezone, but still encounter the error. 
I am also encountering this when building the package under fedora and 
submitting via rhub.
(source code is at https://github.com/merliseclyde/BAS)

Any suggestions ?   The error seems to stop the build, so I cannot verify if 
the other parts of the check (testthat output in particular) are successful, 
which are needed for the CRAN submission.

Thanks in advance - Merlise

Build ID:   BAS_1.5.5.tar.gz-44c32b29bc7a4127be3adfc60c81e330
Platform:   Oracle Solaris 10, x86, 32 bit, R-patched (experimental)
Submitted:  16 minutes 55 seconds ago
Build time: 16 minutes 54.1 seconds
ERRORS:


* checking for future file timestamps ... ERROR
This system is set to the wrong time: please correct
   system: 2020-01-23 21:14 (UTC)
  correct: 2020-01-23 20:14 (UTC)



Merlise A Clyde
Professor Department of Statistical Science
Duke University
http://stat.duke.edu/~clyde

cl...@duke.edu
919 681 8440






[[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-pretest-archived] CRAN submission EventDetectR 0.3.4

[Uwe Ligges]

Sorry, you asked for

Maintainer field differs from that derived from Authors@R
  Maintainer: ‘Sowmya Chandrasekaran’
  Authors@R:  ‘Frederik Rehbach ’


Obvisouly, both fields diaagree. Pkease omit the Mainainer field from 
the original sources. R CMD build will auto generate the maintainer 
field from the Authors@R field and indert the person with cre role as 
maintainer.


Please fix and resubmit.

Best,
Uwe Ligges




On 23.01.2020 15:21, Sowmya C wrote:

Dear CRAN/DEVEL Team,


I am looking forward for kind reply. The two NOTEs are intended changes
that we made and I think the rejection made is a false positive. Kindly do
the needful.

Regards
Sowmya Chandrasekaran

On Mon 13 Jan, 2020, 16:31 Sowmya C,  wrote:


Dear CRAN Team,

Thanks a lot for your quick response. This package is being developed as a
part of a funded research project. And currently i am working on this and
wish to be the maintainer of the package. And hence we wish to change the
maintainer from "Margarita Rebolledo " to ‘Sowmya
Chandrasekaran’. The same has been updated in the
description file and it is the two "Notes". Kindly do the needful.

Regards
Sowmya

##
1.
* checking CRAN incoming feasibility ... NOTE

Maintainer: ‘Sowmya Chandrasekaran’

New maintainer:
   Sowmya Chandrasekaran
Old maintainer(s):
   Margarita Rebolledo 

2.

* checking DESCRIPTION meta-information ... NOTE
Maintainer field differs from that derived from Authors@R
   Maintainer: ‘Sowmya Chandrasekaran’
   Authors@R:  ‘Frederik Rehbach ’



On Mon, Jan 13, 2020 at 4:19 PM  wrote:


Dear maintainer,

package EventDetectR_0.3.4.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/EventDetectR_0.3.4_20200113_160520/Windows/00check.log



Status: 2 NOTEs
Debian: <
https://win-builder.r-project.org/incoming_pretest/EventDetectR_0.3.4_20200113_160520/Debian/00check.log



Status: 2 NOTEs

Last released version's CRAN status: OK: 13
See: <
https://CRAN.R-project.org/web/checks/check_results_EventDetectR.html>

CRAN Web: 

Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on
the R-package-devel mailing list:

If you are fairly certain the rejection is a false positive, please
reply-all to this message and explain.

More details are given in the directory:
<
https://win-builder.r-project.org/incoming_pretest/EventDetectR_0.3.4_20200113_160520/



The files will be removed after roughly 7 days.

No strong reverse dependencies to be checked.

Best regards,
CRAN teams' auto-check service
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
   Maintainer: 'Sowmya Chandrasekaran'

   New maintainer:
 Sowmya Chandrasekaran
   Old maintainer(s):
 Margarita Rebolledo 

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: DESCRIPTION meta-information, Result: NOTE
   Maintainer field differs from that derived from Authors@R
 Maintainer: 'Sowmya Chandrasekaran'
 Authors@R:  'Frederik Rehbach '





[[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] Alternatives to R-devel on a Mac for package checking?

[David Hugh-Jones]

The other obvious online checker is rhub, via the rhub package.
David


On Wed, 15 Jan 2020 at 21:39, Jonathan Greenberg  wrote:

> One of the issues I'm running into is that it seems every time there's a
> Mac update something gets broken with regards to compilers, making it
> incredibly challenging to get the development install of R working with
> Rcpp (which is a requirement for the packages I need to use to check my
> packages).
>
> I'd like to start moving towards an easier approach rather than spending
> days fixing various issues on my Mac just to run a simple --as-cran check
> on a package with the latest  r-devel.  I was HOPING there is an up-to-date
> Docker for the r-development 4.0 version out in the wild, but it seems like
> the rocker r-devel is just 3.6.2.  Any ideas?
>
> docker run --rm -ti rocker/r-devel
>
> Alternatively, are there any decent online checkers (except the CRAN
> ones)?  r-forge seems to not do r-devel checks anymore.
>
> --j
>
> [[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] Adding .exes to R package?

[Ivan Krylov]

On Wed, 22 Jan 2020 20:54:40 +
Jonathan Greenberg  wrote:

> Are there reasonable tutorials on how to do this?

If you absolutely have to do this, take a look at the tinytex package.
It is basically an installer for a preselected set of packages from TeX
Live inside a platform-specific directory. However, if you go this way,
I would like to ask you to preserve the use of manually-installed GDAL
as an option, because I consider manually installed (or distro-provided
in case of GNU/Linux) binaries much easier to trust than automatically
downloaded ones.

"Writing R extensions" mentions _building_ executables as part of the
package a few paragraphs down 1.1.5 Package subdirectories, but
describes such packages as "very special cases" and requiring a lot of
additional hassle: you'd have to provide src/Makefile{,.win} that
should manually build the shared object and the executables and
src/install.libs.R that would install both the shared object and the
executables. I don't think this approach is viable, since latest GDAL
sources are about 13M in size (compressed), and maintaining both the
package and the GDAL binaries would be a serious duplication of effort.

-- 
Best regards,
Ivan

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