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. 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
