Re: [R-pkg-devel] DigitalOcean Makefiles for compiling R-devel

[boB Rudis]

I've got a Vagrant setup (I dislike Docker on OS X) that I'm nearly
ready to push to github as well. Will post here once done.

On Wed, Jul 22, 2015 at 6:45 PM, Jonathan Callahan
 wrote:
> All,
>
> We have (finally) started testing our packages with r-revel on Digital
> Ocean virtual machines.
>
> To automate the initial setup, we have started creating Makefiles to help
> get a clean VM set up with all of the libraries and packages needed to
> build and check our own packages with R-devel.
>
> https://github.com/jonathancallahan/DigitalOcean-R-setup
>
> So far, only the Debian 7.0 and 8.1 Makefiles are fully set up for R-devel.
>
> I hope that these Makefiles may help others harness DigitalOcean to
> thoroughly test packages before submitting them to CRAN.
>
> Best,
>
> Jon
>
> --
> Jonathan Callahan, PhD
> Mazama Science
> 206-708-5028
> mazamascience.com
>
> [[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] Format/parser for NEWS (not NEWS.Rd)?

[boB Rudis]

Try looking at the source for tools:::.news_reader_default and then tools::toRd

On Wed, Oct 7, 2015 at 8:37 PM, Henrik Bengtsson
 wrote:
> Hi,
>
> I'm looking for a parser of the plain text NEWS format (not the
> NEWS.Rd format) - ideally the same on that is used by R itself.  Does
> anyone know which that one is / of such at tool?
>
> Thanks,
>
> Henrik
>
> PS. help("news") mentions tools:::news2Rd(), but that's actually
> defunct (just reported
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16556).
>
> __
> 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] Is it possible to protect a word from the spell checker?

[boB Rudis]

Is there a minimum length req for the single quote spell checker
firewall? I've been putting 'API' in proper single quotes and it
always gets flagged.

On Sun, Mar 6, 2016 at 11:08 AM, Michael Dewey  wrote:
> Thanks to all. I find it quite reassuring that even someone so steeped in R
> is still finding new things to learn, it gives me hope.
>
>
> On 02/03/2016 11:40, Uwe Ligges wrote:
>>
>> Indeed, from Writing R Extensions:
>>
>> "double quotes should be used for quotations (including titles of books
>> and articles), and single quotes for non-English usage, including names
>> of other packages and external software."
>>
>> Best,
>> Uwe
>>
>>
>>
>>
>> On 02.03.2016 09:53, Martin Maechler wrote:

 Hana Sevcikova 
  on Tue, 1 Mar 2016 11:45:34 -0800 writes:
>>>
>>>
>>>  > If it's in the DESCRIPTION file put the word into quotes.
>>>  > Hana
>>>
>>> Indeed, thank you Hana!
>>>
>>> To add - embarrassingly I've only learned this about a week ago -
>>> they need to be *single* quotes (as used 'here', they are also
>>> called 'apostroph') and *not* double quotes.
>>>
>>> Martin
>>>
>>>  > On 01/03/2016 08:47, Michael Dewey wrote:
>>>  >> The spell checker is correct they are not correctly spelled
>>> English
>>>  >> words but names. I searched the Writing R Extensions manual
>>> but did not
>>>  >> find any solution. I know it is only a NOTE not more serious.
>>>
>>> __
>>> 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
>>
>
> --
> Michael
> http://www.dewey.myzen.co.uk/home.html
>
>
> __
> 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] Submitting CRAN packages with hard-to-meet dependencies

[boB Rudis]

I would hope CRAN would let this in with some validation (even to the
point of it possibly adding a new field to DESCRIPTION). It may never
run on Slolaris or Plan 9, and I - who now runs a CRAN mirror in the
hopes to eventually have a MacBuilder equivalent service at some point
in the near future - would also appreciate not having to support large
scale library & database dependencies, even for a potentially useful
package like this. The inclusion in CRAN make packages like it usable
in situations where (for example) github packages would not be (my
previous employer did not allow non-CRAN packages to be used in
sensitive data applications).

On Mon, Apr 18, 2016 at 5:16 PM, Oliver Keyes  wrote:
> Good day,
>
> I've written an Rcpp-backed R package
> (https://github.com/Ironholds/poster) that interfaces with the
> libpostal (https://github.com/openvenues/libpostal) library, written
> in C.
>
> While the two play together perfectly nicely, the problem is
> submitting the package to CRAN: libpostal is not a common dependency
> and isn't available in a debianised form for CRAN's testing: the
> alternative approach, including libpostal *in* the R package, is made
> impossible since it downloads gigabyte-sized databases for internal
> use.
>
> What's the approach or guidance on submitting packages in this state?
> The package includes a configuration script that recognises (in a
> user-friendly way) when dependencies aren't met, and warns the user
> appropriately, but it is still ultimately an R package that will not
> compile on CRAN. Can it be submitted, albeit with installation
> skipped, or is this unacceptable?
>
> Best,
> Oliver
>
> __
> 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] Submitting CRAN packages with hard-to-meet dependencies

[boB Rudis]

So, how do we create a solid alternative to CRAN? github drat wld have
been impossible at my previous gig (for good reasons). Is it time to
try to get rOpenSci to be a legit CRAN alternative? Add enough process
around it to support things like this (i.e. a less narrowly focused
Bioconductor)? Package complexities are only going to grow, not
shrink. Such is this brave, new data science world we live in.

On Mon, Apr 18, 2016 at 8:36 PM, Dirk Eddelbuettel  wrote:
>
> My $0.02:
>
> On 18 April 2016 at 20:23, boB Rudis wrote:
> | I would hope CRAN would let this in with some validation (even to the
> | point of it possibly adding a new field to DESCRIPTION). It may never
> | run on Slolaris or Plan 9, and I - who now runs a CRAN mirror in the
> | hopes to eventually have a MacBuilder equivalent service at some point
> | in the near future - would also appreciate not having to support large
> | scale library & database dependencies, even for a potentially useful
> | package like this. The inclusion in CRAN make packages like it usable
> | in situations where (for example) github packages would not be (my
> | previous employer did not allow non-CRAN packages to be used in
> | sensitive data applications).
>
> Won't fly. Wishing and praying alone doesn't make it happen.  You are putting
> the burden on CRAN, and the two of them already have 8270+ packages to look 
> after.
>
> Suggestion below.
>
> | On Mon, Apr 18, 2016 at 5:16 PM, Oliver Keyes  wrote:
> | > Good day,
> | >
> | > I've written an Rcpp-backed R package
> | > (https://github.com/Ironholds/poster) that interfaces with the
> | > libpostal (https://github.com/openvenues/libpostal) library, written
> | > in C.
> | >
> | > While the two play together perfectly nicely, the problem is
> | > submitting the package to CRAN: libpostal is not a common dependency
> | > and isn't available in a debianised form for CRAN's testing: the
> | > alternative approach, including libpostal *in* the R package, is made
> | > impossible since it downloads gigabyte-sized databases for internal
> | > use.
>
> How about this:
>
>  -- insert a new layer between poster and libpostal which satisfies the
> build requirements for poster and lets it be installed
>
>  -- the layer intercepts calls, and with libpostal not present alerts the
> user
>
> So now postal has a wrapper which may come with its own installer support.
>
> | > What's the approach or guidance on submitting packages in this state?
> | > The package includes a configuration script that recognises (in a
> | > user-friendly way) when dependencies aren't met, and warns the user
> | > appropriately, but it is still ultimately an R package that will not
> | > compile on CRAN. Can it be submitted, albeit with installation
> | > skipped, or is this unacceptable?
>
> No because it won't build so it cannot be tested.  You can do this, but not
> on CRAN.  There is drat ...
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] What to do when you can't reproduce CRAN R CMD check unit test failures?

[boB Rudis]

did you try winbuilder R-devel? I occasionally (ok, often) forget to
do that and it sometimes kick out different errors than R-devel on
local systems.

On Wed, May 11, 2016 at 2:40 AM, Richard Cotton  wrote:
> Yesterday I uploaded a new version of the pathological package to
> CRAN.  It was initially accepted but today I got a message saying that
> some of the tests for the decompose_path function are failing under
> Windows.
>
> I've tested the package on a local Windows 10 machine with R-3.3.0 and
> R-devel, and in Win 7 and Win 8 compatibility modes, and on Windows
> Server 2012 via AppVeyor.  In all cases, all the tests pass.
>
> I tried the CRAN win builder service today, and again, all tests pass.
> http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_tests/tests_i386/testthat.Rout
> http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_tests/tests_x64/testthat.Rout
>
> The failure portion of the output I got from Uwe is as follows:
>
> * checking tests ... ERROR
> Running the tests in 'tests/testthat.R' failed.
> Last 13 lines of output:
>   1. Failure: decompose_path handles paths with no directory and a
> single extension in the filename. (@test_decompose_path.R#42)
>   2. Failure: decompose_path handles paths with no directory and a
> double extension in the filename. (@test_decompose_path.R#72)
>   3. Failure: decompose_path handles paths with no directory and no
> extension in the filename. (@test_decompose_path.R#103)
>   4. Failure: decompose_path handles filenames containing a '.' and an
> extension. (@test_decompose_path.R#133)
>   5. Failure: decompose_path handles the current directory as '.'.
> (@test_decompose_path.R#221)
>   6. Failure: decompose_path handles the parent directory as '..'.
> (@test_decompose_path.R#236)
>   7. Failure: decompose_path handles files inside '.'.
> (@test_decompose_path.R#251)
>   8. Failure: decompose_path works with a character vector input.
> (@test_decompose_path.R#321)
>   9. Failure: decompose_path works with a factor input.
> (@test_decompose_path.R#333)
>   1. ...
>
>
> Since this isn't hugely informative as to the problem, I'd like
> general advice on how I can diagnose a failing test when I can't
> reproduce it.
>
> It would also be useful if anyone can run R CMD check and see if they
> find test failures.
>
> The CRAN release is here (the problematic version is 0.0-8):
> https://cran.r-project.org/web/packages/pathological
>
> and the github version is currently in the same state, available here:
> https://github.com/richierocks/pathological
>
> --
> Regards,
> Richie
>
> Learning R
> 4dpiecharts.com
>
> __
> 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] What to do when you can't reproduce CRAN R CMD check unit test failures?

[boB Rudis]

Of course the Great And Powerful Ushey did the super-smart thing and
actually tested the code locally. Apologies for not thinking of doing
the same on my end (though I'm also OS X):

> getwd()
[1] "/Users/bob/Development/pathological"

> test()
Loading pathological
Loading required package: testthat
Testing pathological

..1..2..W...
Warnings 
---
1. copy_dir works with recursive = TRUE (@test_dir_copy.R#34) -
The files ‘javaconf’, ‘ldpaths’, ‘Makeconf’, ‘Renviron’,
‘repositories’ were not copied successfully.

Failed 
-
1. Failure: decompose_path handles missing paths.
(@test_decompose_path.R#279) -
`warnings` does not match "Coercing .+ to class
[[:punct:]]character[[:punct:]]\\.".
Actual value: "Coercing x to class ‘character’."


2. Failure: decompose_path works with a factor input.
(@test_decompose_path.R#329)
`warnings` does not match "Coercing .+ to class
[[:punct:]]character[[:punct:]]\\.".
Actual value: "Coercing x to class ‘character’."


DONE 
===

I'm using R version 3.3.0 RC (2016-05-01 r70572) & testthat 1.0.2
(2016-04-23 CRAN (R 3.3.0)

I also get those same two errors on a slightly out-of-date R-devel on Ubuntu.

On Thu, May 12, 2016 at 2:09 AM, Kevin Ushey  wrote:
> Is it possible that `getwd()` is reporting something on the CRAN build
> servers that your `decompose_path()` doesn't handle? For example, your
> tests fail for me if I run them while in the root directory (on OS X).
>
> Kevin
>
> On Thu, May 12, 2016 at 12:37 AM, Richard Cotton  
> wrote:
>> Thanks Bob,
>>
>> I'd forgotten about the option to run win-builder against R-devel.
>>
>> Though it seems that in this case, all the tests are passing there too.
>>
>> http://win-builder.r-project.org/21kc9XGKdANF/examples_and_tests/tests_i386/testthat.Rout
>> http://win-builder.r-project.org/21kc9XGKdANF/examples_and_tests/tests_x64/testthat.Rout
>>
>> I'm now completely out of ideas as to where the problem could be.
>>
>>
>> On 11 May 2016 at 15:46, boB Rudis  wrote:
>>> did you try winbuilder R-devel? I occasionally (ok, often) forget to
>>> do that and it sometimes kick out different errors than R-devel on
>>> local systems.
>>>
>>> On Wed, May 11, 2016 at 2:40 AM, Richard Cotton  
>>> wrote:
>>>> Yesterday I uploaded a new version of the pathological package to
>>>> CRAN.  It was initially accepted but today I got a message saying that
>>>> some of the tests for the decompose_path function are failing under
>>>> Windows.
>>>>
>>>> I've tested the package on a local Windows 10 machine with R-3.3.0 and
>>>> R-devel, and in Win 7 and Win 8 compatibility modes, and on Windows
>>>> Server 2012 via AppVeyor.  In all cases, all the tests pass.
>>>>
>>>> I tried the CRAN win builder service today, and again, all tests pass.
>>>> http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_tests/tests_i386/testthat.Rout
>>>> http://win-builder.r-project.org/0ZrX4I75nvzM/examples_and_tests/tests_x64/testthat.Rout
>>>>
>>>> The failure portion of the output I got from Uwe is as follows:
>>>>
>>>> * checking tests ... ERROR
>>>> Running the tests in 'tests/testthat.R' failed.
>>>> Last 13 lines of output:
>>>>   1. Failure: decompose_path handles paths with no directory and a
>>>> single extension in the filename. (@test_decompose_path.R#42)
>>>>   2. Failure: decompose_path handles paths with no directory and a
>>>> double extension in the filename. (@test_decompose_path.R#72)
>>>>   3. Failure: decompose_path handles paths with no directory and no
>>>> extension in the filename. (@test_decompose_path.R#103)
>>>>   4. Failure: decompose_path handles filenames containing a '.' and an
>>>> extension. (@test_decompose_path.R#133)
>>>>   5. Failure: decompose_path handles the current directory as '.'.
>>>> (@test_decompose_path.R#221)
>>>>   6. Failure: decompose_path handles the parent directory as '..'.
>>>> (@test_decompose_path.R#236)
>>>>   7. Failure: decompose_path handles files inside '.&#x

[R-pkg-devel] Pkgs with ToS violations

[Bob Rudis]

I came across https://cran.rstudio.com/web/packages/boxoffice/index.html
in CRAN today and while I don't expect CRAN to be a legal authority,
should there not be some kind of policy for excluding R packages that
deliberately violate (data) site ToS? (I'm asking this here vs sending
a note to CRAN folks since I tend to be a bit sensitive to this
particular issue).

Box Office Mojo - which is really just Amazon - clearly states that
the activities this package facilitates are in violation of their ToS.
Unlike examples on blogs that also violate BOM ToS, this pkg in CRAN
is almost legitimizing the violations.

Amazon only goes after a few folks a year and it's unlikely R folks
will be their target (for now) but that doesn't make it OK IMO.

Is this worth bringing up to CRAN?

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

Re: [R-pkg-devel] Pkgs with ToS violations

[Bob Rudis]

Thx folks. I didn't mean to cause a stir :-)

I've had colleagues receive cease & desists (and worse) before and
it's been my experience that a large # of folks have no idea these
type of cite restrictions exist.

-Bob

On Thu, Aug 4, 2016 at 6:36 AM, Uwe Ligges
 wrote:
> CRAN will follow up with the package maintainer.
>
> Best,
> Uwe Ligges
>
>
>
> On 04.08.2016 10:50, peter dalgaard wrote:
>>
>>
>> On 04 Aug 2016, at 05:21 , Dirk Eddelbuettel  wrote:
>>
>>>
>>> On 3 August 2016 at 22:26, Bob Rudis wrote:
>>> | I came across
>>> https://cran.rstudio.com/web/packages/boxoffice/index.html
>>> | in CRAN today and while I don't expect CRAN to be a legal authority,
>>> | should there not be some kind of policy for excluding R packages that
>>> | deliberately violate (data) site ToS? (I'm asking this here vs sending
>>> | a note to CRAN folks since I tend to be a bit sensitive to this
>>> | particular issue).
>>> |
>>> | Box Office Mojo - which is really just Amazon - clearly states that
>>> | the activities this package facilitates are in violation of their ToS.
>>> | Unlike examples on blogs that also violate BOM ToS, this pkg in CRAN
>>> | is almost legitimizing the violations.
>>> |
>>> | Amazon only goes after a few folks a year and it's unlikely R folks
>>> | will be their target (for now) but that doesn't make it OK IMO.
>>> |
>>> | Is this worth bringing up to CRAN?
>>>
>>> I think so.
>>>
>>
>>
>> By all means bring it up. But there's the usual tools-vs-action
>> discussion, and I do notice that the ToS has
>>
>> • Licensing IMDb's Content; Consent to Use Robots and Crawlers: If you are
>> interested in receiving our express written permission to use our content
>> for your non-personal (including commercial) use, please contact our
>> Licensing Department. We do allow the limited use of robots and crawlers,
>> such as those from certain search engines, with our express written consent.
>>
>> I.e., it could be a matter of suitable flagging of the software as
>> requiring permission. You likely don't wnat CRAN to run automated tests that
>> run scrapers, though.
>>
>> -pd
>>
>>
>>> Dirk
>>>
>>> --
>>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>>
>>> __
>>> 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] Would CRAN accept a package that requires cmake?

[Bob Rudis]

qtbase - https://cran.rstudio.com/web/packages/qtbase/index.html - is
just one (quickly found) example of pkgs using cmake.

the installr pkg will enable folks to install cmake on windows pretty
easily, as well.

On Wed, Aug 10, 2016 at 8:39 AM, Charles Determan  wrote:
> Greetings,
>
> I have seen this previous discussion (
> https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000115.html) on this
> question but I didn't find a clear answer.  I am looking at integrating
> some more existing open-source C++ libraries to R packages.  However, a
> handful use/require cmake for compilation.  I believe this is possible to
> do using the configure(.win) files but I want to make sure this would be
> acceptable to CRAN.
>
> Thanks,
> Charles
>
> [[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] [Learning] the secret of Win[dows C-backed packages]

[Bob Rudis]

Hey folks,

I usually stare in awe at the C-backed packages that rely on eternal
libraries which are super-easy to get working on macOS & *nix _but_ that
also work perfectly on Windows. I fire up Windows (*maybe*) once a month to
test some of my packages but I'm curious as to what I need to do to setup a
more extended toolchain to create libraries such as are found in
https://github.com/rwinlib.

Jeroen (I think others, too) seem to effortlessly package those up and I
fully grok his "anticonf" setup and the 32-bit & 64-bit Windows library
setup. I just can't seem to actually do the building.

Why I'm asking what I'm asking (below) is that I'm working on something for
the $DAYJOB now - https://github.com/hrbrmstr/wand - that requires libmagic
and I kinda, unfortunately, actually need it to also work on Windows (it
usually doesn't matter, but this time some folks who use Windows systems at
work need to use this forthcoming package).

Rather than b[eu]g Jeroen or others for library building/packaging, I'd be
very, keenly interested in learning what else besides Rtools I need to
install to be able to make similar binary bundles to include during
installation (and to have my compiled pkgs work on Windows).

My disdain for Windows and my frustration with the super-limited toolchain
components installed with Rtools is probably contributing to my inability
to solve this on my own (no bash.exe...rly?). I used to use cygwin back in
the day but there are so many cautions in the main R docs abt compatible
versions that I'd rather not spend hours or days figuring out something
that others already have.

One example here is that I actually managed to get one of the libmagic
support packages (the regex library) built and installed on Windows (in the
toolchain /usr/local) but can't get libmagic's `configure` script to
find/use it.

I'm more than willing to write up any copious pointers folks provide into a
detailed, attributed blog post or R Journal article since this is seriously
the only bit holding me back from working on and releasing a ton of other
compilation-required packages to CRAN. I also know I'm not the only one who
gets stalled when trying to get similar things (especially those with full
Boost dependencies) to work on Windows.

thx,

-Bob

[[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] [Learning] the secret of Win[dows C-backed packages]

[Bob Rudis]

Aye. I rly need to get back to my security & privacy "R" post. The
slipstreaming in of these binaries is somewhat frightening. Almost as
frightening as being stuck on Windows 😀
On Sat, Aug 13, 2016 at 13:09 Dirk Eddelbuettel  wrote:

>
> I don't think there is a good "generally applicable" solution.  We have a
> bunch of hacks. Below are three quickly picked examples from packages of
> mine:
>
> RQuantLib relies on environment variables and a 'library that needs to just
> be there' on the build host:
>
>## The environment variable QUANTLIB_ROOT has to point to an existing
> build of QuantLib
>## With R 2.12.0 and later, we also support 32 and 64 bit builds and
> need to differentiate
>PKG_CPPFLAGS=-I$(QUANTLIB_ROOT) -I../inst/include -I. -I$(BOOSTLIB)
>PKG_CXXFLAGS=$(SHLIB_OPENMP_CFLAGS) -fpermissive
>PKG_LIBS=-L$(QUANTLIB_ROOT)/lib${R_ARCH} -lQuantLib
> $(SHLIB_OPENMP_CFLAGS)
>
> RcppGSL does the same
>
>## This assumes that the LIB_GSL variable points to working GSL
> libraries
>PKG_CPPFLAGS=-I$(LIB_GSL)/include -I../inst/include
>PKG_LIBS=-L$(LIB_GSL)/lib -lgsl -lgslcblas
>
> Rblpapi copies a library (for which we have 'free' binaries but no source)
> in
> from GitHub:
>
>## target to ensure tar.gz files get unpacked
>## the opening '@' ensures operations are executed 'quietly'
>## in order to see commands as they happens add a 'v' to the tar and cp
> commands
>## curl has '-k' flag to suppress certificate warnings
>blpLibrary:
> @if [ ! -d ../inst ]; then mkdir -p ../inst; fi
> @if [ ! -d ../blp/win/${FLV} ]; then mkdir -p
> ../blp/win/${FLV}; fi
> @if [ ! -f ../blp/win/${FLV}/blpHeaders.tar.gz ]; then
> curl -s -k -L -O
> https://github.com/Rblp/blp/raw/master/headers/windows/blpHeaders.tar.gz;
> mv blpHeaders.tar.gz ../blp/win/${FLV}; tar xfz
> ../blp/win/${FLV}/blpHeaders.tar.gz -C ../inst; fi
> @if [ ! -f ../blp/win/${FLV}/blpLibrary.tar.gz ]; then
> curl -s -k -L -O
> https://github.com/Rblp/blp/raw/master/win${WIN}/blpLibrary.tar.gz; mv
> blpLibrary.tar.gz ../blp/win/${FLV}; tar xfz
> ../blp/win/${FLV}/blpLibrary.tar.gz; fi
> @if [ ! -d ${FLV} ]; then mkdir -p ${FLV}; fi
> @cp blpapi3_${WIN}.dll ${FLV}
> @if [ ! -d ../inst/libs/${FLV} ]; then mkdir -p
> ../inst/libs/${FLV}; fi
> @cp blpapi3_${WIN}.dll ../inst/libs/${FLV}
>
>
> None of that really generalizes well.  The last bit, much like the
> so-called
> anticonf pattern, is more or less a non-standard practice exposing a
> security
> risk by copying in code from a semi-random location which could be hijacked
> or man-in-the-middle'd.
>
> Really all this is just pretending that Windows is an envrionment on which
> you can deploy proper build systems -- similar to what we are used from the
> likes of dpkg/apt/yum or brew.  But in all honesty you just can't.
>
> So I would not try to aim for something overly general.  It is Windows
> after all.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[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] robust download function in R (similar to wget)?

[Bob Rudis]

libcurl (which the RCurl & curl packages are built on) do not inherently
have retry or resume partial capabilities, but those could be packaged up
into a "robustdownloader" package. There's no guarantee of wget or curl
binaries being on a system (especially Windows, even with an Rtools
installation, rly great platform there). Windows does have a PowerShell
`wget` alias for `Invoke-WebRequest` but it's woefully less powerful than
wget-proper and doesn't support the features you need and it relies on
PowerShell).

I'd suggest the creation of a separate package for robust downloading and
then relying on that or keep the solution you've got by PR #56.

On Thu, Aug 25, 2016 at 9:56 AM, Dirk Eddelbuettel  wrote:

>
> On 25 August 2016 at 08:24, Joshua Ulrich wrote:
> | Try downloader: https://cran.r-project.org/package=downloader
>
> Also, if you really want wget / know how to parameterise wget you can
> ... just depend on _wget itself_ which you can
>
> a) test for via Sys.which("wget")
>
> b) select as an option for download.file() and hence all file access.
>
> Dirk
>
> | On Thu, Aug 25, 2016 at 7:47 AM, Lucas Ferreira Mation
> |  wrote:
> | > I am creating this package  lucasmation/microdadosBrasil>
> | > that has to download data from some sources that are a bit
> | > unstable/unreliable. The problem is described in this issue
> | > .
> | >
> | > Is there a more "robust" download fucntion in R?
> | > Something similar to wget, that would:
> | >
> | > - where there are errors, repeat the download a few times before
> giving up,
> | > preferably, using partial data on a file being downloaded from previous
> | > attempts
> | > - check the integrity of the downloaded file
> | >
> | > As this has to be embedded in an R package, the solution needs to be OS
> | > independent and require no installation of external software by the
> user.
> | >
> | > regards
> | > Lucas
> | >
> | > [[alternative HTML version deleted]]
> | >
> | > __
> | > R-package-devel@r-project.org mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> |
> |
> |
> | --
> | Joshua Ulrich  |  about.me/joshuaulrich
> | FOSS Trading  |  www.fosstrading.com
> | R/Finance 2016 | www.rinfinance.com
> |
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> 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] automated testing for an SSH tunneling package?

[Bob Rudis]

I'm not sure where Jeroen is on this - https://github.com/jeroenooms/ssh -
but it might make more sense to dovetail off of it than rely on binaries
being available on systems. That's doable, but (IMO) fraught with peril.

On Fri, Sep 16, 2016 at 4:53 PM, William May  wrote:

> I wrote an SSH tunneling package (it's on Github here<
> https://github.com/wmay/tunnelr>). It runs on Mac, Linux, and Windows, at
> least in the environments I've been able to test. I would like to get it on
> CRAN if it's possible, but writing automated tests for this package is
> nightmarish.
>
> Typically, connecting to a server through the package requires manually
> entering a password, which I don't think I can automate. (I don't want to
> allow the package to enter passwords itself for security reasons.) An
> alternative is to set up public and private rsa keys so that no password is
> required. That option also gets complicated.
>
> I could imagine setting up a server solely for testing this, with a user
> that has no password, though that sounds scary. But then what happens if
> the server goes down?
>
> A second challenge applies specifically to Windows, which is the platform
> I'm most concerned about. I'm relying on PuTTY for SSH in Windows. Is there
> a way for that to be tested on CRAN?
>
> Should I even worry about CRAN testing for this? Will CRAN accept this
> package without tests?
>
> And I was surprised that an SSH tunneling package didn't already exist (I
> found it really convenient to control SSH tunneling from within R). Is
> there another reason it doesn't exist yet, or is it just the testing
> challenges?
>
> - Will
>
> [[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

[R-pkg-devel] New libcurl coming / question for pkg authors

[Bob Rudis]

(didn't know where else to post this, but pkg authors seemed to be a
good group to run this by)

Some folks may know I work in cybersecurity and my org's been talking
with the curl/libcurl community regarding:
https://curl.haxx.se/mail/lib-2016-10/0076.html

TLDR: there's a new libcurl/curl coming out in early November which
contains a number of serious security fixes (which you'll have to wait
until they disclose them publicly to know, unfortunately).

There are an ever increasing number of orgs/users who work with pkgs &
their own code that rely on the curl & RCurl pkgs and it is really
going to be in their best interest to upgrade curl/libcurl and rebuild
the pkgs, especially if they run them in a server (e.g. Shiny, model
feature generation, automated scraping) context.

I don't use Windows regularly, but IIRC CRAN builds binaries for both
RCurl & curl that are either statically linked to libcurl or bundle
the shared library. I don't remember if that's true for macOS binaries
(I tend to build my envs from verified source for various paranoid
reasons).

My q is that how do we [widespread] encourage/inform users to upgrade
libcurl and re-install the pkgs?

I can (and will) be sending the R Core folks a note (tho they are all
prbly on here) when the new code is released, but there are many folks
who won't even see this and who really should upgrade.

Most processes involving R & libcurl/curl aren't going to be directly
attacked or susceptible, but we've (my org) has been informed that
these are going to be some pretty critical vulns (again, I can't talk
more abt it) and most R users aren't going to be watching for vulns in
this context, so I'm just trying to figure out the best way to get the
word out the largest R audience. I'll be posting something on
R-bloggers after the release, but I'm hoping others can help get the
word out as well.

thx,

-Bob

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

[R-pkg-devel] log4j (CVE-2021-44228) & rJava CRAN pkgs (spoiler: no issues!)

[Bob Rudis]

Hey folks,

If you haven't heard abt the log4j vuln from Friday yet, I envy you
and def want to know how you managed to do that.

For folks who develop Java-backed packages, pls be aware there's an
arbitrary code execution issue with log4j v2 <= 2.15.0 (NOTE log4j v1
1.x are not impacted).

Thanks to a q by Sir Leeper, I've scanned all of CRAN with —
https://github.com/mergebase/log4j-detector — (and looked for the
log4j v2 jar directly) and it's all good, but wanted to let folks know
abt that tool and suggest that you run that in new packages or if you
update your old ones.

The odds of any R environment being impacted by this vulnerability
were super slim (to almost none) to begin with and — if the tool is
accurate — it's 0.

This is a technical but rly good Reddit thread on the log4j issue if
folks want some bedtime reading:
https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/

-boB

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

Re: [R-pkg-devel] Possible malware(?) in a vignette

[Bob Rudis]

The current one on CRAN does get flagged for some low-level Sigma rules b/c
of one of way a few URLs interact. I don't know if f-secure is
pedantic enough to call that malicious (it probably is, though). The
*current* PDF is "fine".

There is a major problem with the 2020 version. The file Iñaki's URL
matches the PDF that I grabbed from the Wayback Machine for the 2020 PDF
from that URL.

Simon's assertion about this *2020* file is flat out wrong. It's very bad.

Two VT sandboxes used Adobe Acrobat Reader to open the PDF and the PDF
seems to either had malicious JavaScript or had been crafted sufficiently
to caused a buffer overflow in Reader that then let it perform other
functions on those sandboxes.

They are most certainly *not* false positives, and dismissing that outright
is not great.

I'm not going to check every 2020 PDF from CRAN, but this is a big signal
to me there was an issue *somewhere* in that time period.

I do not know what cran.r-project.org resolved to for the Common Crawl at
that date (which is where archive.org picked it up to archive for the 2020
PDF version). I highly doubt the Common Crawl DNS resolution process was
spoofed _just for that PDF URL_, but it may have been for CRAN in general
or just "in general" during that crawl period.

It is also possible some malware hit CRAN during portions of that time
period and infected more than one PDF.

But, outright suggesting there is no issue was not the way to go, here.
And, someone should likely at least poke at more 2020 PDFs from CRAN
vignette builds (perhaps just the ones built that were JSS articles…it's
possible the header image sourced at that time was tampered with during
some time window, since image decoding issues have plagued Adobe Reader in
buffer overflow land for a long while).

- boB


On Thu, Jan 25, 2024 at 9:44 PM Simon Urbanek 
wrote:

> Iñaki,
>
> I think you got it backwards in your conclusions: CRAN has not generated
> that PDF file (and Windows machines are not even involved here), it is the
> contents of a contributed package, so CRAN itself is not compromised. Also
> it is far from clear that it is really a malware - in fact it's certainly
> NOT what the website you linked claims as those tags imply trojans
> disguising ZIPped executables as PDF, but the file is an actual valid PDF
> and not even remotely a ZIP file (in fact is it consistent with pdflatex
> output). I looked at the decompressed payload of the PDF and the only
> binary payload are embedded fonts so my guess would be that some byte
> sequence in the fonts gets detected as false-positive trojan, but since
> there is no detail on the report we can just guess. False-positives are a
> common problem and this would not be the first one. Further indication that
> it's a false-positive is that a simple re-packaging the streams (i.e. NOT
> changing the actual PDF contents) make the same file pass the tests as
> clean.
>
> Also note that there is a bit of a confusion as the currently released
> version (poweRlaw 0.80.0) does not get flagged, so it is only the archived
> version (from 2020).
>
> Cheers,
> Simon
>
>
>
> > On 26/01/2024, at 12:02 AM, Iñaki Ucar  wrote:
> >
> > On Thu, 25 Jan 2024 at 10:13, Colin Gillespie 
> wrote:
> >>
> >> Hi All,
> >>
> >> I've had two emails from users in the last 24 hours about malware
> >> around one of my vignettes. A snippet from the last user is:
> >>
> >> ---
> >> I was trying to install a R package that depends on PowerRLaw two
> >> weeks ago.  However my virus protection software F secure did not
> >> allow me to install it from CRAN, while installation from GitHub
> >> worked normally. Virus protection software claimed that
> >> d_jss_paper.pdf is compromised. I asked about this from our IT support
> >> and they asked it from the company F secure. Now F secure has analysed
> >> the file and according them it is malware.
> >>
> >> “Upon analyzing, our analysis indicates that the file you submitted is
> >> malicious. Hence the verdict will remain
> >
> > See
> https://www.virustotal.com/gui/file/9486d99c1c1f2d1b06f0b6c5d27c54d4f6e39d69a91d7fad845f323b0ab88de9/behavior
> >
> > According to the sandboxed analysis, there's something there trying to
> > tamper with the Acrobat installation. It tries several Windows paths.
> > That's not good.
> >
> > The good news is that, if I recreate the vignette from your repo, the
> > file is different, different hash, and it's clean.
> >
> > The bad news is that... this means that CRAN may be compromised. I
> > urge CRAN maintainers to check all the PDF vignettes and scan the
> > Windows machines for viruses.
> >
> > Best,
> > Iñaki
> >
> >
> >>
> >> ---
> >>
> >> Other information is:
> >>
> >> * Package in question:
> >> https://cran.r-project.org/web/packages/poweRlaw/index.html
> >> * Package hasn't been updated for three years
> >> * Vignette in question:
> >>
> https://cran.r-project.org/web/packages/poweRlaw/vignettes/d_jss_paper.pdf
> >>
> >> CRAN asked me to fix
> >> ht

Re: [R-pkg-devel] Possible malware(?) in a vignette

[Bob Rudis]

Simon: Is there a historical record of the hashes of just the PDFs
that show up in the CRAN web view?

Ivan: do you know what mirror NOAA used at that time to get that version of
the package? Or, did they pull it "directly" from cran.r-project.org
(scare-quotes only b/c DNS spoofing is and has been a pretty solid attack
vector)?

I've asked the infosec community if anyone has VT Enterprise to do a
historical search on any PDFs that come directly from cran.r-project.org (I
don't have VT Enterprise). It is possible there are other PDFs from that
timeframe with similar issues (again, not saying CRAN had any issues; this
could still be crawler cache poisoning).

I don't know if any university folks have grad student labor to harness,
but having a few of them do some archive.org searches for other PDFs in
that timeframe, and note the source of the archive (likely Common Crawl) if
there are other real issues, that'd be a solid path forward for triage.

The fact that the current PDF on CRAN — which uses some of the same
7-year-old PDF & JPEG images from —
https://github.com/csgillespie/poweRlaw/tree/main/vignettes — is not being
flagged, means it's likely not an issue with Colin's sources.

Simon: it might be a good idea for all *.r-project.org sites to set up CAA
records (
https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization)
since that could help prevent adjacent TLS spoofing.

Also having something running — https://github.com/SSLMate/certspotter —
can let y'all know if certs are created for *.r-project.org domains. That
won't help for well-resourced attacks, but it does add some layers that may
give a heads-up for any mid-grade spoofing attacks.

On Sat, Jan 27, 2024 at 6:18 AM Simon Urbanek 
wrote:

> Iñaki,
>
> On Jan 27, 2024, at 11:44 PM, Iñaki Ucar  wrote:
>
> Simon,
>
> Please re-read my email. I did *not* say that CRAN *generated* that file.
> I said that CRAN *may* be compromised (some virus may have modified files).
>
>
>
> I guess I should have been more clear in my response: the file could not
> have been modified by CRAN, because the package files are checksummed (the
> hashes match) so that's how we know this could not have been a virus on the
> CRAN machine.
>
>
> I did *not* claim that the report was necessarily 100% accurate. But "that
> page I linked" was created by a security firm, and it would be wise to
> further investigate any potential threat reported there, which is what I
> was suggesting.
>
>
>
> I appreciate the report, there was no objection to that. Unfortunately,
> the report has turned out to have virtually no useful information that
> would make it possible for us to investigate. The little information it
> provided has proven to be false (at least as much as could be gleamed from
> the tags), so unless we can get some real security expert to give us more
> details, there is not much more we can do given that the file is no longer
> distributed. And without more detailed information of the threat it's hard
> to see if there are any steps we could take.
>
> Back to my main original point - as far as CRAN machines are concerned, we
> did check the integrity of the files, machines and tools and found no link
> there. Hence the only path left is to get more details on the particular
> file to see if it is indeed a malware and if so, if it was just some random
> infection at the source or something bigger like Bob hinted at some
> compromised material that may have been circling in the community.
>
> Cheers,
> Simon
>
>
>
> I don't think these are "false claims".
>
> Iñaki
>
> El sáb., 27 ene. 2024 11:19, Simon Urbanek 
> escribió:
>
>> Bob,
>>
>> I was not making assertions, I was only dismissing clearly false claims:
>> CRAN did NOT generate the file in question, it is not a ZIP file trojan as
>> indicated by the AV flags and content inspection did not reveal any other
>> streams than what is usual in pdflatex output. The information about the
>> alleged malware was terribly vague and incomplete to put it mildly so if
>> you have any additional forensic information that sheds more light on
>> whether this was a malware or not, it would be welcome. If it was indeed
>> one, knowing what kind would help to see how any other instances could be
>> detected. Please contact the CRAN team if you have any such information and
>> we can take it from there.
>>
>> As you hinted yourself - there is no such thing as absolute safety - as
>> the webp exploits have illustrated very clearly a simple image can be
>> malware and the only read defense is to keep your software up to date.
>>
>> Cheers,
>> Simon
>>
>&g

Re: [R-pkg-devel] registering native routines

[Bob Rudis]

I believe you've got _some_ time. As of the changes in 3.4.0 the verbiage is:

   R CMD check --as-cran now NOTEs if the package does not register 
   its native routines or does not declare its intentions on (native) 
   symbol search. (This will become a WARNING in due course.)

And I think it's still a NOTE vs a full-on WARNING (I register all mine but can 
test this later).

Rcpp makes this super simple and the 
tools::package_native_routine_registration_skeleton() is also pretty painless 
as does Kevin Ushey's souretools::register_routines() 
(https://github.com/kevinushey/sourcetools/blob/master/R/register.R).

-boB

> On Feb 16, 2019, at 2:45 PM, Charles Geyer  wrote:
> 
> I just noticed that R package foo in the github repo
> https://github.com/cjgeyer/foo no longer passes R CMD check --as-cran.  The
> problem seems to be that it does not register native routines and thus the
> C routines cannot be found.  It does pass R CMD check (without --as-cran).
> The version of the package that does register native routines (package
> fooRegister) in the same repo passes with or without --as-cran.  So did I
> miss the announcement?  Is registration of native routines now mandatory
> for CRAN?
> 
> Just asking because I am currently teaching about R packages in PhD level
> statistical confusing and don't want to provide erroneous info.
> 
> These packages are toy packages to introduce the class to R packages.  I
> don't actually want to put them on CRAN.
> 
> -- 
> Charles Geyer
> Professor, School of Statistics
> Resident Fellow, Minnesota Center for Philosophy of Science
> University of Minnesota
> char...@stat.umn.edu
> 
>   [[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] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Bob Rudis]

It's fixed in the RC that's GA on the 11th.

I think perhaps "stealth fixed" may be more appropro since it's not in SVN 
logs, Bugzilla nor noted prominently in any of the various NEWS* files.

Then there's the "why was the core R installation using a third party, 
non-HTTPS site for this to begin with".

And, in other news, there are tests in the R source that rely on a check of 
`foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is 
registered. Thankfully there's no current IP address associated with it. 
Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might be a 
better choice as well since that won't break the reason for the connectivity 
checks and won't arbitrarily send telemetry pings to third parties in the even 
anyone outside of R Core decides to run the tests (say, when patching something 
in R).

-boB

> On Mar 7, 2019, at 07:54, Rainer M Krug  wrote:
> 
> I can confirm the same when checking on travis with r-devel.
> 
> And thanks for the tip with
> 
> env:
>  - _R_CHECK_SYSTEM_CLOCK_=0
> 
> In .travis.yml
> 
> Seems to be working now
> 
> Rainer
> 
> 
> 
>> On 7 Mar 2019, at 12:48, Ralf Herold  wrote:
>> 
>> Dear All,
>> 
>> Checking a new package under development produces a warning in a local 
>> R-devel MS Windows environment (output below).
>> 
>> Building it with R-devel on Travis fails (because warnings are changed to 
>> errors), but is successful when setting environment variable 
>> _R_CHECK_SYSTEM_CLOCK_ to zero.
>> 
>> No issue occurs when checking and building with R-stable and R-oldrel on 
>> Travis, or with any R version on win-builder.r-project.org.
>> 
>> The warning concerns using http://worldclockapi.com/, which however seems 
>> out of service ("The web app you have attempted to reach is currently 
>> stopped and does not accept any requests."). This is referenced in the main 
>> function for R CMD check 
>> (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may 
>> concern more R-devel than R-package-devel. I am posting here to check if the 
>> issue was noticed by other package developers and to check the impact.
>> 
>> Thanks for any suggestions.
>> Best regards,
>> Ralf
>> 
>> 
>> PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe' CMD check 
>> E:\mypackage_0.1.2.3.tar.gz --as-cran
>> * using log directory 'C:/Users/username/ctrdata.Rcheck'
>> * using R Under development (unstable) (2019-03-05 r76200)
>> * using platform: x86_64-w64-mingw32 (64-bit)
>> * using session charset: ISO8859-1
>> * using option '--as-cran'
>> [...]
>> * checking package directory ... OK
>> * checking for future file timestamps ...Warning in file(con, "r") :
>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status was 
>> '403 Site Disabled'
>> WARNING
>> unable to verify current time
>> * checking 'build' directory … OK
>> [...]
>> 
>> 
>> 
>> ## Ralf Herold
>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>> ## https://paediatricdata.eu/
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
> 
> 
> --
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Bob Rudis]

(a) that's gd news (#ty)
(b) genuine apologies for my confusion
(c) why was the introduction of reliance on a third-party site even under 
consideration?

> On Mar 7, 2019, at 09:32, peter dalgaard  wrote:
> 
> It's not "stealth fixed"! It was never there... (on the release branch)
> 
> The timestamp checking code is still present in R-devel. I presume something 
> needs to be done about the breakage.
> 
> - pd
> 
>> On 7 Mar 2019, at 14:38 , Bob Rudis  wrote:
>> 
>> It's fixed in the RC that's GA on the 11th.
>> 
>> I think perhaps "stealth fixed" may be more appropro since it's not in SVN 
>> logs, Bugzilla nor noted prominently in any of the various NEWS* files.
>> 
>> Then there's the "why was the core R installation using a third party, 
>> non-HTTPS site for this to begin with".
>> 
>> And, in other news, there are tests in the R source that rely on a check of 
>> `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is 
>> registered. Thankfully there's no current IP address associated with it. 
>> Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might be 
>> a better choice as well since that won't break the reason for the 
>> connectivity checks and won't arbitrarily send telemetry pings to third 
>> parties in the even anyone outside of R Core decides to run the tests (say, 
>> when patching something in R).
>> 
>> -boB
>> 
>>> On Mar 7, 2019, at 07:54, Rainer M Krug  wrote:
>>> 
>>> I can confirm the same when checking on travis with r-devel.
>>> 
>>> And thanks for the tip with
>>> 
>>> env:
>>> - _R_CHECK_SYSTEM_CLOCK_=0
>>> 
>>> In .travis.yml
>>> 
>>> Seems to be working now
>>> 
>>> Rainer
>>> 
>>> 
>>> 
>>>> On 7 Mar 2019, at 12:48, Ralf Herold  wrote:
>>>> 
>>>> Dear All,
>>>> 
>>>> Checking a new package under development produces a warning in a local 
>>>> R-devel MS Windows environment (output below).
>>>> 
>>>> Building it with R-devel on Travis fails (because warnings are changed to 
>>>> errors), but is successful when setting environment variable 
>>>> _R_CHECK_SYSTEM_CLOCK_ to zero.
>>>> 
>>>> No issue occurs when checking and building with R-stable and R-oldrel on 
>>>> Travis, or with any R version on win-builder.r-project.org.
>>>> 
>>>> The warning concerns using http://worldclockapi.com/, which however seems 
>>>> out of service ("The web app you have attempted to reach is currently 
>>>> stopped and does not accept any requests."). This is referenced in the 
>>>> main function for R CMD check 
>>>> (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may 
>>>> concern more R-devel than R-package-devel. I am posting here to check if 
>>>> the issue was noticed by other package developers and to check the impact.
>>>> 
>>>> Thanks for any suggestions.
>>>> Best regards,
>>>> Ralf
>>>> 
>>>> 
>>>> PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe' CMD check 
>>>> E:\mypackage_0.1.2.3.tar.gz --as-cran
>>>> * using log directory 'C:/Users/username/ctrdata.Rcheck'
>>>> * using R Under development (unstable) (2019-03-05 r76200)
>>>> * using platform: x86_64-w64-mingw32 (64-bit)
>>>> * using session charset: ISO8859-1
>>>> * using option '--as-cran'
>>>> [...]
>>>> * checking package directory ... OK
>>>> * checking for future file timestamps ...Warning in file(con, "r") :
>>>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
>>>> was '403 Site Disabled'
>>>> WARNING
>>>> unable to verify current time
>>>> * checking 'build' directory … OK
>>>> [...]
>>>> 
>>>> 
>>>> 
>>>> ## Ralf Herold
>>>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>>>> ## https://paediatricdata.eu/
>>>> 
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Rainer M. Krug
>>> email: Rainerkrugsde
>>> PGP: 0x0F52F982
>>> 
>>> 
>>> [[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
> 
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Internet security software?

[Bob Rudis]

As someone who is in cybersecurity as their $DAYJOB and who runs macOS as their 
primary OS (tho I pretty much run them all in one way, shape or form), I'd 
suggest:

- relying heavily on Gatekeeper/Xprotect (the built-in anti-malware solution 
that comes with macOS, provided you keep updating the OS)
- review the free tools at  and 
consider installing them for "monitoring". Specifically, I'd suggest using:
  - LuLu 
  - KnockKnowk 
  - ReiKey 
  - BlockBlock 
  - RansomWhere? 
  - OverSight 
  - Lockdown  (if you're 
stuck on seriously old macOS)
- use MalwareBytes free edition for periodic scans
- use Google Chrome Beta channel with uBlock Origin and the Disconnect 
extensions (and very few other extensions). 
  Go into uBlock Origin and enable all of the non-regional blocklists and then 
ones for your specific region.
  We're seeing regular increases in malicious advertisements across all ad 
networks.

The vast majority (if not all) of commercial or freemium macOS anti-malware 
solutions are mind-numbingly trivial to bypass. Unless you're in a regulatory 
environment that requires commercial, always-on anti-malware, I'd just run (as 
noted) the free version of Malwarebytes. If you are regulated, then it's one of 
the better ones from a commercial standpoint.

-boB


> On Feb 25, 2020, at 04:16, Joris Meys  wrote:
> 
> Hi Spencer,
> 
> I've abandoned Bitdefender for the reason you give: it gave me too much 
> trouble with false positives and seemingly random blocking of all kinds of 
> tools at one point. But the reason is not Bitdefender in itself. It worked 
> perfectly fine until the updates came for the Spectre and Meltdown 
> vulnerabilities. Somehow these patches messed with the workings of 
> Bitdefender, leading to the problems you describe. As Windows 7 is no longer 
> maintained, these problems won't be solved.
> 
> So first of all, you should abandon Windows 7. Even if it would work fine, 
> it's a huge security risk. No point in having an antivirus if you run an OS 
> that's no longer maintained. Either move to Windows 10 or change for a Linux 
> distro (Ubuntu is imho the one Windows users find most easy to adapt to. Your 
> mileage may vary).
> 
> As for antivirus, I'm now using Kaspersky and am liking it so far (2 years 
> now). I find it less intrusive than Bitdefender as well, even though I had no 
> complaints in the past. 
> 
> Kind regards
> Joris
> 
> --
> Joris Meys
> Statistical consultant
> 
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> --
> 
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
> 
> 
> From: R-package-devel  on behalf of 
> Spencer Graves 
> Sent: Monday, February 24, 2020 10:49 PM
> To: List r-package-devel
> Subject: [R-pkg-devel] Internet security software?
> 
> Hello, All:
> 
> 
>   What antivirus / internet security software do you use and
> recommend?
> 
> 
>   I've used Bitdefender for years.  However, I've been encountering
> an increasing number of problems with software I've used for years.
> Some of my problems disappear when I turn off parts of Bitdefender.
> However, I've been unable to use RStudio on my Windows 7 computer since
> early last November.  Also, when I turn off certain features of
> Bitdefender, "R CMD build sos" (with sos cloned from
> "https://github.com/sbgraves237/sos";) completes in a few minutes.  With
> Bitdefender configured normally, "R CMD build sos" stops without warning
> on "* creating vignettes".  I've left it for days like that without it
> moving beyond that point.  No error message but also no progress.
> 
> 
>   Rather than doing a web search for alternative internet security
> software, I thought I'd ask you all:  If some of you have had similar
> problems with other antivirus / internet security software, I think I'd
> be more likely to hear it from you than from a web search.  Some of my
> problems may not be due to Bitdefender, but I know that some are, and
> Bitdefender tech support answers the phone but fails to fix these problems.
> 
> 
>   Thanks,
>   Spencer Graves
> 
> __
> 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

Re: [R-pkg-devel] MacOS flat namespace

[Bob Rudis]

Can you provide a bit more context? I just grabbed the pkg source from CRAN and 
it builds fine.


$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

─ Session info 
───

 setting  value 
 version  R version 4.0.0 RC (2020-04-21 r78267)
 os   macOS Catalina 10.15.5
 system   x86_64, darwin17.0
 ui   RStudio   
 language (EN)  
 collate  en_US.UTF-8   
 ctypeen_US.UTF-8   
 tz   America/New_York  
 date 2020-05-06

─ Packages 
───

 package * version  date   lib source
 assertthat0.2.12019-03-21 [1] CRAN (R 4.0.0)
 backports 1.1.62020-04-05 [1] CRAN (R 4.0.0)
 bit * 1.1-15.2 2020-02-10 [1] CRAN (R 4.0.0)
 bit64   * 0.9-72017-05-08 [1] CRAN (R 4.0.0)
 callr 3.4.32020-03-28 [1] CRAN (R 4.0.0)
 cli   2.0.22020-02-28 [1] CRAN (R 4.0.0)
 codetools 0.2-16   2018-12-24 [1] CRAN (R 4.0.0)
 crayon1.3.42017-09-16 [1] CRAN (R 4.0.0)
 desc  1.2.02018-05-01 [1] CRAN (R 4.0.0)
 devtools* 2.2.22020-02-17 [1] CRAN (R 4.0.0)
 digest0.6.25   2020-02-23 [1] CRAN (R 4.0.0)
 ellipsis  0.3.02019-09-20 [1] CRAN (R 4.0.0)
 fansi 0.4.12020-01-08 [1] CRAN (R 4.0.0)
 fs1.4.12020-04-04 [1] CRAN (R 4.0.0)
 glue  1.4.02020-04-03 [1] CRAN (R 4.0.0)
 lattice   0.20-41  2020-04-02 [1] CRAN (R 4.0.0)
 magrittr  1.5  2014-11-22 [1] CRAN (R 4.0.0)
 memoise   1.1.02017-04-21 [1] CRAN (R 4.0.0)
 pkgbuild  1.0.62019-10-09 [1] CRAN (R 4.0.0)
 pkgload   1.0.22018-10-29 [1] CRAN (R 4.0.0)
 prettyunits   1.1.12020-01-24 [1] CRAN (R 4.0.0)
 processx  3.4.22020-02-09 [1] CRAN (R 4.0.0)
 ps1.3.22020-02-13 [1] CRAN (R 4.0.0)
 R62.4.12019-11-12 [1] CRAN (R 4.0.0)
 raster3.1-52020-04-19 [1] CRAN (R 4.0.0)
 Rcpp  1.0.4.6  2020-04-09 [1] CRAN (R 4.0.0)
 remotes   2.1.12020-02-15 [1] CRAN (R 4.0.0)
 rgdal 1.4-82019-11-27 [1] CRAN (R 4.0.0)
 rlang 0.4.52020-03-01 [1] CRAN (R 4.0.0)
 rprojroot 1.3-22018-01-03 [1] CRAN (R 4.0.0)
 rstudioapi0.11 2020-02-07 [1] CRAN (R 4.0.0)
 sessioninfo   1.1.12018-11-05 [1] CRAN (R 4.0.0)
 sp1.4-12020-02-28 [1] CRAN (R 4.0.0)
 testthat  2.3.22020-03-02 [1] CRAN (R 4.0.0)
 uFTIR   * 0.1.12020-03-11 [1] CRAN (R 4.0.0)
 usethis * 1.5.12019-07-04 [1] CRAN (R 4.0.0)
 withr 2.2.02020-04-20 [1] CRAN (R 4.0.0)

[1] /Library/Frameworks/R.framework/Versions/4.0/Resources/library

> On May 6, 2020, at 06:17, Fabio Corradini Santander  
> wrote:
> 
> Hi,
> Two months ago I released a package I developed in Debian 9 GCC (
> https://CRAN.R-project.org/package=uFTIR). The package was accepted on
> CRAN, and it can be installed on Windows and Linux machines. However, it is
> not working on MacOS. I don't know why. The problem starts after the
> installation, as the OS cannot load the compiled code. Cutting the long
> paths of CRAN, the problem looks like (for r-oldrel-osx-x86_64):
> 
> ...
> ** testing if installed package can be loaded from temporary location
> Error: package or namespace load failed for ‘uFTIR’ in dyn.load(file,
> DLLpath = DLLpath, ...):
> unable to load shared object '.../libs/uFTIR.so':
>  dlopen(.../libs/uFTIR.so, 6): Symbol not found:
> _H5P_CLS_DATASET_CREATE_ID_g
>  Referenced from: .../libs/uFTIR.so
>  Expected in: flat namespace
> in .../libs/uFTIR.so
> Error: loading failed
> ...
> (The missing symbol for r-release-osx-x86_64 is a different
> one: _jpeg_resync_to_restart)
> 
> I saw this thread (https://github.com/RcppCore/RcppArmadillo/issues/224)
> about Rcpp, but CRAN is not using gcc, but clang, so it is not really the
> same... although I was lost when they discussed about libc++ and libstdc++.
> 
> I also saw this thread from stackoverflow (
> https://stackoverflow.com/questions/40922814/error-in-dyn-loaddllfile-unable-to-load-shared-object-expected-in-flat-na)
> but I don't have a mix between cpp and plain c.
> 
> I think that probably has to do with my Makevars file (
> https://community.rstudio.com/t/error-during-the-installation-of-utf8-package/4005/2)...
> maybe I shouldn't use PKG_LIBS and LDLIBS instead? But if I change it, how
> will it affect the -already successful- installations on windows and linux?
> 
> The Makevars for Mac and Linux is:
> 
> CXX_STD = CXX11
> PKG_CXXFLAGS = $(SH