Re: [R-pkg-devel] Format/parser for NEWS (not NEWS.Rd)?

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

Re: [R-pkg-devel] Submitting CRAN packages with hard-to-meet dependencies

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

[R-pkg-devel] Pkgs with ToS violations

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

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

mund.de> 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 <e...@debian.org> wrote: >> >>> >

[R-pkg-devel] [Learning] the secret of Win[dows C-backed packages]

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

Re: [R-pkg-devel] [Learning] the secret of Win[dows C-backed packages]

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

Re: [R-pkg-devel] robust download function in R (similar to wget)?

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

Re: [R-pkg-devel] automated testing for an SSH tunneling package?

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:

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

(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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

r 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 imag