[R-pkg-devel] CRAN badges in README

[Helmut Schütz]

Dear all,

we are using badges in README files of our packages on GitHub and CRAN. 
Recently wrong results are reported:


https://github.com/Helmut01/replicateBE#readme shows CRAN Error
https://cran.r-project.org/web/packages/replicateBE/readme/README.html 
shows CRAN Not OK
though OK at 
https://cran.r-project.org/web/checks/check_results_replicateBE.html


https://github.com/Detlew/Power2Stage#readme shows CRAN Not OK
though OK at 
https://cran.r-project.org/web/checks/check_results_Power2Stage.html


https://github.com/Detlew/PowerTOST#readme shows CRAN Error
https://cran.r-project.org/web/packages/PowerTOST/readme/README.html 
shows CRAN Not OK
though one NOTE at 
https://cran.r-project.org/web/checks/check_results_PowerTOST.html


All badges are linked with https://cranchecks.info/badges/worst/{package 
name}
I checked about 1 month ago and the first 2 showed CRAN OK and the last 
CRAN Note – which was correct.


Any ideas?

Helmut

--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/

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

[R-pkg-devel] dependency fails checking a package on ASAN/UBSAN (on r-hub)

[Georgi Boshnakov]

Hi,

A package submitted on CRAN shows problems only on ASAN/UBSAN.
I  used 'r-hub' (rhub::check()) to check if my update has fixed that on that 
platform but
This is unsuccessful since a dependency fails to install.

The dependency in question is 'xml2'  so it surely can be installed one way or 
another but do I need to give additional parameters? The report from r-hub is at
HTML


Georgi Boshnakov

[[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 Windows failure due to old pandoc ?

[Dirk Eddelbuettel]

On 26 September 2020 at 14:42, Dirk Eddelbuettel wrote:
| 
| On 26 September 2020 at 14:20, Duncan Murdoch wrote:
| | On 26/09/2020 12:54 p.m., Dirk Eddelbuettel wrote:
| | Hmmm, that's strange.  From what I can see you only get the --lua-filter 
| | if pandoc 2.0 is available:
| | 
| | 
https://github.com/rstudio/rmarkdown/blob/66d27e09befd5f0579f0f4e27c4b9325284b9b15/R/pandoc.R#L719
| | 
| | I think this is the current rmarkdown version.
| 
| I was using a different document driver which may not make that check.
| 
| In the meantime, I think I will just follow the usual advice 'stop doing that
| then' after complaining that it hurts and may just switch to a pdf vignette.

And with a little more, I convinced the maintainer of the markdown style in
question to adopt Duncan's suggested pandoc version fix offered by rmarkdown.

I never heard back from CRAN, neither via a direct message, nor here.

Dirk

-- 
https://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] dependency fails checking a package on ASAN/UBSAN (on r-hub)

[Gábor Csárdi]

It seems that Debian testing has a new version of libxml2, or maybe
the ICU is newer, and the xml package does not compile with this.

I am afraid that xml2 needs some fixes to solve this. It might be
enough to require C++11 support. If you don't want to wait for the
xml2 maintainer, then you can fork the repo, add C++11 support to your
fork, and then (temporarily) add a `Remotes` field to `DESCRIPTION`
that points to your fork.

Gabor

On Thu, Oct 1, 2020 at 1:08 PM Georgi Boshnakov
 wrote:
>
> Hi,
>
> A package submitted on CRAN shows problems only on ASAN/UBSAN.
> I  used 'r-hub' (rhub::check()) to check if my update has fixed that on that 
> platform but
> This is unsuccessful since a dependency fails to install.
>
> The dependency in question is 'xml2'  so it surely can be installed one way 
> or another but do I need to give additional parameters? The report from r-hub 
> is at
> HTML
>
>
> Georgi Boshnakov
>
> [[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] CRAN badges in README

[Zhian N. Kamvar]

You might be having browser cache issues because I just looked and 
things are fine on this end. You can double check in another browser or 
clear the cache (usually via Preferences > Settings > Security).


FWIW, cran checks is an rhub/rOpenSci project: 
https://blog.r-hub.io/2019/06/10/cran-checks-api/, and not controlled by 
the CRAN team.


Best,

Zhian

On 10/1/20 3:52 AM, Helmut Schütz wrote:

Dear all,

we are using badges in README files of our packages on GitHub and 
CRAN. Recently wrong results are reported:


https://github.com/Helmut01/replicateBE#readme shows CRAN Error
https://cran.r-project.org/web/packages/replicateBE/readme/README.html 
shows CRAN Not OK
though OK at 
https://cran.r-project.org/web/checks/check_results_replicateBE.html


https://github.com/Detlew/Power2Stage#readme shows CRAN Not OK
though OK at 
https://cran.r-project.org/web/checks/check_results_Power2Stage.html


https://github.com/Detlew/PowerTOST#readme shows CRAN Error
https://cran.r-project.org/web/packages/PowerTOST/readme/README.html 
shows CRAN Not OK
though one NOTE at 
https://cran.r-project.org/web/checks/check_results_PowerTOST.html


All badges are linked with 
https://cranchecks.info/badges/worst/{package name}
I checked about 1 month ago and the first 2 showed CRAN OK and the 
last CRAN Note – which was correct.


Any ideas?

Helmut



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

Re: [R-pkg-devel] CRAN badges in README

[Helmut Schütz]

Dear Zhian,

Zhian N. Kamvar wrote on 2020-10-01 16:43:
You might be having browser cache issues because I just looked and 
things are fine on this end. You can double check in another browser 
or clear the cache (usually via Preferences > Settings > Security).


FWIW, cran checks is an rhub/rOpenSci project: 
https://blog.r-hub.io/2019/06/10/cran-checks-api/, and not controlled 
by the CRAN team.


Sorry, seems that rhub suffered from hiccups. All fine now without 
clearing the cache. Case closed.


All the best,
Helmut

--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/

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

[R-pkg-devel] Non-mainstream repository dependence for CRAN vignette building

[Bennett Nicolas]

Dear list

I’m in the process of submitting a package to CRAN that uses a non-mainstream 
repository for several data packages that are too large for CRAN (~50 MB in 
total) and therefore live in a drat repository hosted by gh. Data from these 
packages is used during vignette building and unsurprisingly, CRAN checks throw 
a “re-building of vignette” warning.

1. Is such a warning acceptable or is vignette re-build required to run through?
2. Is it allowed to create a set-up that essentially runs `install.packages()` 
during CRAN checks to make the non-mainstream repo packages available?
3. Are there any go-to solutions for such a scenario? I tried knitr caching, 
but was unsuccessful, to get that to work. What I’m currently doing is masking 
the package function that loads data and supplying the required data with the 
package. But this unnecessarily inflates package size (and adds complexity), as 
the data is already conveniently and separately available as an R package.

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

Re: [R-pkg-devel] Non-mainstream repository dependence for CRAN vignette building

[Max Turgeon]

Hi Nicholas,

I see two potential solutions, maybe other people will suggest different ones:

  1. You can make the evaluation of the whole vignette dependent on the data 
packages being available. Here's an example from one of my packages: 
https://github.com/sahirbhatnagar/casebase/blob/3403e0451ba5f0bf122924729ba85a904cf16082/vignettes/smoothHazard.Rmd#L22-L27

  2. You create the vignette on your machine and add it to the package as a 
"static vignette". Here's a blog post on how to do it (it's also been discussed 
on this list before, have a look at the archive): 
http://www.markvanderloo.eu/yaRb/2019/01/11/add-a-static-pdf-vignette-to-an-r-package/

Each approach has its pros and cons. In the first solution, a potential issue 
is that the complete vignettes may rarely be available on a user's machine, 
unless they install the data package first and build from source. In the second 
solution, there's more maintenance for you.

Best,


Max Turgeon
Assistant Professor
Department of Statistics
Department of Computer Science
University of Manitoba
maxturgeon.ca



From: R-package-devel  on behalf of 
Bennett Nicolas 
Sent: Thursday, October 1, 2020 1:46 PM
To: r-package-devel@r-project.org 
Subject: [R-pkg-devel] Non-mainstream repository dependence for CRAN vignette 
building


Caution: This message was sent from outside the University of Manitoba.


Dear list

I�m in the process of submitting a package to CRAN that uses a non-mainstream 
repository for several data packages that are too large for CRAN (~50 MB in 
total) and therefore live in a drat repository hosted by gh. Data from these 
packages is used during vignette building and unsurprisingly, CRAN checks throw 
a �re-building of vignette� warning.

1. Is such a warning acceptable or is vignette re-build required to run through?
2. Is it allowed to create a set-up that essentially runs `install.packages()` 
during CRAN checks to make the non-mainstream repo packages available?
3. Are there any go-to solutions for such a scenario? I tried knitr caching, 
but was unsuccessful, to get that to work. What I�m currently doing is masking 
the package function that loads data and supplying the required data with the 
package. But this unnecessarily inflates package size (and adds complexity), as 
the data is already conveniently and separately available as an R package.

Best,
Nicolas
__
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