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
______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
