[R-pkg-devel] Package submission - Issue with pandoc in R CMD check

[Uwe Ligges]

This should be resolved in general now.

Best,
Uwe Ligges



On 03.06.2017 15:51, Dirk Eddelbuettel wrote:
> 
> On 3 June 2017 at 08:30, Dirk Eddelbuettel wrote:
> |
> | On 27 May 2017 at 22:18, Emmanuel Blondel wrote:
> | | Dear Uwe, i clearly understand the CRAN team needs time on this. I have
> | | no problem in postponing on my side, and resubmit later next month.
> |
> | As the problem appears to be somewhat hard and rooted in two areas that are
> | difficult to effectuate change in (as in: "we" control neither the pandoc
> | binary, nor the img.shields.io webserver) I took a somewhat more pessimistic
> | view of coming changes and ... simply coded around the problem by
> |
> |   i)   caching a copy of the badge I needed in a new GitHub repository
> |
> |   ii)  enabling the web server feature of the repo
> |
> |   iii) reference that cached copy
> |
> | See the new repo 'badges' at
> |
> |   https://github.com/eddelbuettel/badges
> |
> | and a first use in my RcppArmadillo package
> |
> |   https://github.com/RcppCore/RcppArmadillo/blob/master/README.md
> |
> | which is currently simmering for already well over twenty-four hours at a low
> | temperature in the incoming area of our favourite repository.
> |
> | By using the cached copy a simple static file from a (working) server, all
> | issues with pandoc are avoided.  So far it only has "my default" license
> | badge, it would of course be trivial add others so PR away.
> 
> I should add that this works well when you only call to the license badge (or
> another static badge).
> 
> Another use case is to retrieve the code coverage badge, and that is a little
> trickier as one essentially turns of the on-demand calculation.  But to me it
> is still defensible to allow a CRAN submission, or until we get a better fix.
> 
> Dirk
>