Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Martin Morgan]

It is wrong to say that ‘it will never be solved for R.4.0.0’. Rather, ‘it will 
never be a problem for R.4.0.0’.

rtracklayer 1.51.5 was only ever built, checked, distributed (and installed in 
a correctly configured system, using the rules of install.packages and 
tools:::.BioC_version_associated_with_R_version(), or of 
BiocManager::install()) on R-devel (now R-4-1-0-branch). So R-4.0.* has never 
supported version 1.51.5 of rtracklayer.

No Bioconductor package built on R-4.0.* would propagate (be visible to 
install.packages()) with a dependency on rtracklayer-1.51.5. A CRAN package 
with a dependency on rtracklayer-1.51.5 (this is hypothetical, I do not believe 
it is the case for CNVScope), would be correctly flagged as an error – this 
version of rtracklayer will never be available on R-4.0.*, and the CRAN package 
author would have to re-assess the reasons for specifying the dependency for 
that version of R.

Bioconductor does rarely produce ‘impossible’ dependencies particularly in the 
Bioconductor ‘devel’ branch (when a package builds and checks even though one 
of its dependencies builds but does not pass check), but these are transient 
and an artifact of the Bioconductor  build system – the lagging package Is 
usually promptly updated so the published dependency is satisfied.


From: Henrik Bengtsson 
Date: Tuesday, May 18, 2021 at 2:41 PM
To: Martin Morgan 
Cc: "Dalgleish, James (NIH/NCI) [F]" , 
"r-package-devel@r-project.org" 
Subject: Re: [R-pkg-devel] Old version of rtracklayer on a single check server

I stand corrected about the R-devel version (and now R 4.1.0) on CRAN.

However, isn't it the case that it will never be solved for R 4.0.0 (to become 
R-oldrel on CRAN) and CRAN will keep reporting an error on MS Windows there 
because https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html 
provides only an older version for MS Windows?

If so, an alternative to relying on Suggests is to make the package depend on R 
(>= 4.1.0).

/Henrik

On Tue, May 18, 2021, 09:08 Martin Morgan 
mailto:mtmorgan.b...@gmail.com>> wrote:
That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc";)["rtracklayer", "Version"]`) is 
1.51.5.

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
mailto:r-package-devel-boun...@r-project.org>
 on behalf of henrik.bengts...@gmail.com> 
wrote:

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel 
mailto:r-package-devel@r-project.org>> wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Henrik Bengtsson]

I stand corrected about the R-devel version (and now R 4.1.0) on CRAN.

However, isn't it the case that it will never be solved for R 4.0.0 (to
become R-oldrel on CRAN) and CRAN will keep reporting an error on MS
Windows there because
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html provides
only an older version for MS Windows?

If so, an alternative to relying on Suggests is to make the package depend
on R (>= 4.1.0).

/Henrik

On Tue, May 18, 2021, 09:08 Martin Morgan  wrote:

> That’s not correct Henrik.
>
> CRAN follows CRAN rules for installing packages, so uses
> tools:::BioC_version_for_R_version(). For R-devel we have
>
> > R.version.string
> [1] "R Under development (unstable) (2021-05-18 r80323)"
> > tools:::.BioC_version_associated_with_R_version()
> [1] '3.13'
>
> For this version of Bioconductor, the rtracklayer version (from
> https://bioconductor.org/packages/3.13/rtracklayer, or
> `available.packages(repos = 
> "https://bioconductor.org/packages/3.13/bioc";)["rtracklayer",
> "Version"]`) is 1.51.5.
>
> So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the
> wrong version of rtracklayer for R-devel.
>
> Martin Morgan
>
> On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" <
> r-package-devel-boun...@r-project.org on behalf of
> henrik.bengts...@gmail.com> wrote:
>
> It's a problem with Bioconductor and a broken release history of
> 'rtracklayer' on MS Windows (e.g.
> https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
> plus how each Bioconductor version is tied to a specific R version.
> In other words, even if they fix it in Bioconductor 3.13 (for R
> 4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
> you're package will keep failing on Windows for R 4.0.0.  The reason
> why it can't be fixed in Bioconductor 3.12 is that they have now
> frozen that release forever.
>
> Because of this, I suspect the only solution is to make 'rtracklayer'
> an optional package, i.e. move it to Suggests: and update all your
> code to run conditionally of that package being available. I recommend
> you reach out to the bioc-devel mailing list for advice.
>
> /Henrik
>
> On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
> R-package-devel  wrote:
> >
> > To any who might have an idea:
> >
> > I've been reading several posts in the digest about dependency
> version issues on the check servers and I'm having my own issue, which I
> can't solve because I can't upgrade the check server's package version:
> > * installing *source* package 'CNVScope' ...
> > ** using staged installation
> > ** R
> > ** data
> > *** moving datasets to lazyload DB
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > Warning: multiple methods tables found for 'export'
> > Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
> versionCheck = vI[[j]]) :
> >   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is
> required
> > Calls:  ... namespaceImportFrom -> asNamespace ->
> loadNamespace
> > Execution halted
> > ERROR: lazy loading failed for package 'CNVScope'
> > * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
> >
> > These errors tend to be check server dependent (only occurs on
> r-devel-windows-ix86+x86_64<
> https://cran.r-project.org/web/checks/check_flavors.html#r-devel-windows-ix86_x86_64>)
> and I'm just trying to make the small change to closeAllConnections() that
> was asked earlier of maintainers by Kurt Hornik and the CRAN team, but I
> can't because of this old package version on the devel check server, which
> has the same error:
> >
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> >
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
> >
> > Is there any way around this? I notice the maintainer of the
> 'gtsummary' package had a similar issue:
> >
> > "> I am trying to make a release that depends on gt v0.3.0, but I
> get an error
> >
> > > when I test the package on Windows Dev
> `devtools::check_win_devel()` that
> >
> > > the gt package is available but it's an unsuitable version.  Does
> anyone
> >
> > > know why the gt v0.3.0 is unavailable?"
> >
> >
> >
> > I'm open to any suggestions, but can't see a way around this issue
> from my end without the ability to service the check server.
> >
> >
> > Thanks,
> > James Dalgleish
> > Cancer Genetics Branch,
> > Center for Cancer Research,
> > National Cancer Institute,
> > National Institutes of Health,
> > Bethesda, MD
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-d

Re: [R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines

[Toby Hocking]

Hi Tomas, these are really helpful suggestions, which are not at all
discussed in the current Writing R Extensions, nor in CRAN Repository
Policy. Would you please consider adding this information to one of these
official sources of documentation?

On Fri, May 14, 2021 at 3:59 AM Tomas Kalibera 
wrote:

>
> On 5/14/21 4:19 AM, SN248 wrote:
> > Thank you Tomas and Sokol for your suggestions.
> >
> > Based on Tomas' suggestion, it seems the best way forward would be to
> > first request CRAN maintainers to install libsbml on the CRAN
> > machines. It is quite straightforward to install the library from the
> > instructions provided online. If the installation fails on a
> > particular architecture, I should try bundling the source code and
> > creating the static libraries.
>
> Please let me clarify, I am not suggesting that you ask CRAN team to
> create the distribution packages for you, but only to install an
> existing distribution package (in case they are not doing that already).
>
> The distribution package is usually a script which automatically
> downloads the software, builds it, picks up the results, adds some
> meta-data about dependencies, and archives them in a supported format.
> Someone has to create the distribution package, and I am suggesting that
> you as R package maintainer should do that, possibly getting help from
> other volunteers e.g even on the R-devel mailing list. The CRAN team
> would only add that package name to their list of installed packages (in
> case it is not there implicitly, i.e. they possibly won't have to do
> anything).
>
> So first, I would should check for existing distribution packages. Most
> distributions have their own indexing/search support, but you can also
> look online as follows.
>
> For Linux distributions, there is e.g. pkgs.org for the first quick
> search (libsml-devel, libsbml-dev might be what you are looking for).
>
> For Windows, msys2 packages are here
> https://github.com/msys2/MINGW-packages/, rtools packages are here
> https://github.com/r-windows/rtools-packages (so there is
> mingw-w64-libsbml). MXE packages are here
> https://github.com/mxe/mxe/tree/master/src and the customized version
> for R is here
>
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/
> (so upstream MXE doesn't have sbml, but the customized has libsbml).
>
> For macOS, recipes for R are here
> https://github.com/R-macos/recipes/tree/master/recipes and it does not
> have sbml library as far as I can see.
>
> So, if you wanted your package to use sbml, the best way would be to
> test it with the sbml package from all the distributions mentioned above
> (from Linux, at least the ones used by CRAN - Debian/Ubuntu, Fedora).
> Then, you would create a recipe (distribution package) for macOS, test
> it with your package, and contribute to the "recipes" above. When
> creating the recipe, look at other recipes to get the form, and look at
> sbml in the previously mentioned distributions to see how to
> download/build it (in addition to the online manual you mentioned).
>
> Once that is in, you could submit your package to CRAN, following the
> usual checks you do when submitting packages. And then, in case it
> failed on some of the CRAN machines, you could contact the individual
> maintainer and ask for installing that distribution package of the given
> name. In some cases it won't be necessary (the machines would already
> have the package, they may be installing all available packages
> automatically).
>
> This may sound like a bit of work, but that is the price for adding
> dependencies on native libraries, and someone has to do this work.
> Installing libraries manually on the check machines is not going to
> scale and may be too much burden for many end users, apart from
> difficulties with repeatability, maintenance, etc.
>
> Best
> Tomas
>
> >
> > Thanks again for your help.
> > Satya
> >
> > On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera
> > mailto:tomas.kalib...@gmail.com>> wrote:
> >
> >
> > On 5/13/21 7:06 AM, SN248 wrote:
> > > I am working on a package which provides an interface to the
> > libsbml C++
> > > library (http://sbml.org/Software/libSBML
> > ) in R. The source code of this
> > > package (r2sbml) can be found at the following link
> > >
> > > https://github.com/sn248/r2sbml 
> > >
> > > The package passes CRAN checks with `R CMD check` on my machine,
> > but I do
> > > have dependency (libsbml library) installed on my machine (OSX)
> with
> > > headers and static libs at the usual locations, i.e.,
> > /usr/local/include
> > > and /usr/local/lib. The package also passes CRAN check on a
> > Windows machine
> > > with libsbml installed using Rtools40 and msys2. The DESCRIPTION
> > file lists
> > > libsbml in SystemRequirements but `R CMD check` obviously fails
> > on 

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Martin Morgan]

That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc";)["rtracklayer", "Version"]`) is 
1.51.5. 

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
 
wrote:

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel  wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64)
 and I'm just trying to make the small change to closeAllConnections() that was 
asked earlier of maintainers by Kurt Hornik and the CRAN team, but I can't 
because of this old package version on the devel check server, which has the 
same error:
> 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
>
> Is there any way around this? I notice the maintainer of the 'gtsummary' 
package had a similar issue:
>
> "> I am trying to make a release that depends on gt v0.3.0, but I get an 
error
>
> > when I test the package on Windows Dev `devtools::check_win_devel()` 
that
>
> > the gt package is available but it's an unsuitable version.  Does anyone
>
> > know why the gt v0.3.0 is unavailable?"
>
>
>
> I'm open to any suggestions, but can't see a way around this issue from 
my end without the ability to service the check server.
>
>
> Thanks,
> James Dalgleish
> Cancer Genetics Branch,
> Center for Cancer Research,
> National Cancer Institute,
> National Institutes of Health,
> Bethesda, MD
>
>
> [[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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Old version of rtracklayer on a single check server

[Henrik Bengtsson]

It's a problem with Bioconductor and a broken release history of
'rtracklayer' on MS Windows (e.g.
https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
plus how each Bioconductor version is tied to a specific R version.
In other words, even if they fix it in Bioconductor 3.13 (for R
4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
you're package will keep failing on Windows for R 4.0.0.  The reason
why it can't be fixed in Bioconductor 3.12 is that they have now
frozen that release forever.

Because of this, I suspect the only solution is to make 'rtracklayer'
an optional package, i.e. move it to Suggests: and update all your
code to run conditionally of that package being available. I recommend
you reach out to the bioc-devel mailing list for advice.

/Henrik

On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
R-package-devel  wrote:
>
> To any who might have an idea:
>
> I've been reading several posts in the digest about dependency version issues 
> on the check servers and I'm having my own issue, which I can't solve because 
> I can't upgrade the check server's package version:
> * installing *source* package 'CNVScope' ...
> ** using staged installation
> ** R
> ** data
> *** moving datasets to lazyload DB
> ** inst
> ** byte-compile and prepare package for lazy loading
> Warning: multiple methods tables found for 'export'
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = 
> vI[[j]]) :
>   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is required
> Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
> Execution halted
> ERROR: lazy loading failed for package 'CNVScope'
> * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
>
> These errors tend to be check server dependent (only occurs on 
> r-devel-windows-ix86+x86_64)
>  and I'm just trying to make the small change to closeAllConnections() that 
> was asked earlier of maintainers by Kurt Hornik and the CRAN team, but I 
> can't because of this old package version on the devel check server, which 
> has the same error:
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
> https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
>
> Is there any way around this? I notice the maintainer of the 'gtsummary' 
> package had a similar issue:
>
> "> I am trying to make a release that depends on gt v0.3.0, but I get an error
>
> > when I test the package on Windows Dev `devtools::check_win_devel()` that
>
> > the gt package is available but it's an unsuitable version.  Does anyone
>
> > know why the gt v0.3.0 is unavailable?"
>
>
>
> I'm open to any suggestions, but can't see a way around this issue from my 
> end without the ability to service the check server.
>
>
> Thanks,
> James Dalgleish
> Cancer Genetics Branch,
> Center for Cancer Research,
> National Cancer Institute,
> National Institutes of Health,
> Bethesda, MD
>
>
> [[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

[R-pkg-devel] Old version of rtracklayer on a single check server

[Dalgleish, James (NIH/NCI) [F] via R-package-devel]

To any who might have an idea:

I've been reading several posts in the digest about dependency version issues 
on the check servers and I'm having my own issue, which I can't solve because I 
can't upgrade the check server's package version:
* installing *source* package 'CNVScope' ...
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Warning: multiple methods tables found for 'export'
Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = 
vI[[j]]) :
  namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is required
Calls:  ... namespaceImportFrom -> asNamespace -> loadNamespace
Execution halted
ERROR: lazy loading failed for package 'CNVScope'
* removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'

These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64)
 and I'm just trying to make the small change to closeAllConnections() that was 
asked earlier of maintainers by Kurt Hornik and the CRAN team, but I can't 
because of this old package version on the devel check server, which has the 
same error:
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out

Is there any way around this? I notice the maintainer of the 'gtsummary' 
package had a similar issue:

"> I am trying to make a release that depends on gt v0.3.0, but I get an error

> when I test the package on Windows Dev `devtools::check_win_devel()` that

> the gt package is available but it's an unsuitable version.  Does anyone

> know why the gt v0.3.0 is unavailable?"



I'm open to any suggestions, but can't see a way around this issue from my end 
without the ability to service the check server.


Thanks,
James Dalgleish
Cancer Genetics Branch,
Center for Cancer Research,
National Cancer Institute,
National Institutes of Health,
Bethesda, MD


[[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] InvalidUrlException for fontawesome icons in Rmarkdown vignette

[Vincent Nijs]

I see the same issue come up on rhub and the issue has also started showing
up for the previous version of the package. See results link below.

https://cran.r-project.org/web/checks/check_results_radiant.html

On Mon, May 17, 2021 at 6:10 AM Uwe Ligges 
wrote:

> Perhaps simply ask the CRAN crew to run the checks again, but as you do
> not say which package this is about etc, we can hardly help.
>
> Best,
> Uwe Ligges
>
> On 16.05.2021 08:16, Vincent Nijs wrote:
> > Hi,
> >
> > I submitted a minor update to a package and ran into the vignette
> > warning/error shown. FYI the package change had nothing to do with the
> > vignette.
> >
> > Flavor: r-devel-windows-ix86+x86_64
> > Check: re-building of vignette outputs, Result: WARNING
> >Error(s) in re-building vignettes:
> >--- re-building 'programming.Rmd' using rmarkdown
> >pandoc.exe: Could not fetch
> >
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEE4Up6Lwg$
> > <
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!QDKkOEM4b68jQTdP9_B69YPFnkWW3hUKU0TnKHzueExJp5xLhyR22STQL1kQ0BZLBY0$
> >
> >InvalidUrlException "
> >
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEE4Up6Lwg$
> > <
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!QDKkOEM4b68jQTdP9_B69YPFnkWW3hUKU0TnKHzueExJp5xLhyR22STQL1kQ0BZLBY0$
> >"
> > "URL must be absolute"
> >Error: processing vignette 'programming.Rmd' failed with diagnostics:
> >pandoc document conversion failed with error 67
> >--- failed re-building 'programming.Rmd'
> >
> > I have used the Rmarkdown header below for this package for a number of
> > years and it has never caused an issue. The URL is absolute and links
> > properly. The vignette also builds fine locally.
> >
> > I'm stuck and hope you can shed some light on this problem.
> >
> > Thanks,
> >
> > Vincent
> >
> > ---
> > title: Programming with Radiant
> > author: "Vincent R. Nijs, Rady School of Management (UCSD)"
> > date: "`r Sys.Date()`"
> > output:
> >rmarkdown::html_vignette:
> >  css:
> >
> https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEE4Up6Lwg$
> > vignette: >
> >%\VignetteIndexEntry{Programming with Radiant}
> >%\VignetteEngine{knitr::rmarkdown}
> >\usepackage[utf8]{inputenc}
> > ---
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> >
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!Mih3wA!RgyNlE6MVL47VVcjFz5JmMHpLjgnleTMV8PUzdHRhLsF840eotO4MEEPPgZZbg$
> >
>

[[alternative HTML version deleted]]

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