from:"Emmanuel Blondel"

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

2017-05-25 Thread Emmanuel Blondel

Dear all,

I've just submitted a new package named geometa, for which i received the 
message below. Indeed i had sent in my submission some question mark about the 
warning i obtain during R CMD check:

In case of R release and R devel, I got the following warning:

Conversion of 'README.md' failed:
pandoc.exe: Could not fetchhttps://img.shields.io/badge/Github-0.1--0-blue.svg
TlsExceptionHostPort (HandshakeFailed Error_EOF) "img.shields.io" 443

I've been looking for information about it, and it seems to be reported as bug 
of Pandoc. Same occur if I use an http link instead. I didn't find any 
successful alternative to remove this warning, and of course for this package 
and others i maintain, i would like to keep the 2 badges, 1 for CRAN and 1 for 
Github so user can quickly check if there is a pending revision in Github.

R CRAN checks links:
- old release:https://win-builder.r-project.org/GphApwuaD56b
- release:https://win-builder.r-project.org/maQicmvW941l
- devel:https://win-builder.r-project.org/OLSqwXd4W442

I would be very grateful if someone can shed light on this, and suggest a 
solution, so i could re-submit the package to CRAN.

Best regards
Emmanuel


 Message transf�r� 
Sujet : [CRAN-pretest-archived] CRAN submission geometa 0.1-0
Date :  Thu, 25 May 2017 20:21:22 +0200
De :uwe.lig...@r-project.org
R�pondre � :c...@r-project.org
Pour :  emmanuel.blond...@gmail.com
Copie � :   c...@r-project.org



Dear maintainer,
  
package geometa_0.1-0.tar.gz does not pass the incoming checks automatically, 
please see the pre-test at:

Status: 1 WARNING, 1 NOTE
  
Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the 
R-package-devel mailing list:

If you are fairly certain the rejection is a false positive, please reply-all 
to this message and explain.
  
More details are given in the directory:

The files will be removed after roughly 7 days.
  
  
Best regards,
CRAN teams' auto-check service


[[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] Package submission - Issue with pandoc in R CMD check

2017-05-27 Thread Emmanuel Blondel

Thanks Uwe for your clarifications. Can you let me know if i need to 
change something on my side, and/or resubmit the package to CRAN? (the 
warning on Pandoc was the only one) Thanks in advance


Best,
Emmanuel

Le 26/05/2017 à 00:11, Uwe Ligges a écrit :
This is currently under inspection by the CRAN team. Apparently 
img.shields.io have changed the cypher settings and pandoc fails with 
the new settings. We may have to disable *.md processing for some time.


Best,
Uwe Ligges



On 25.05.2017 20:59, Emmanuel Blondel wrote:

Dear all,

I've just submitted a new package named geometa, for which i received 
the message below. Indeed i had sent in my submission some question 
mark about the warning i obtain during R CMD check:


In case of R release and R devel, I got the following warning:

Conversion of 'README.md' failed:
pandoc.exe: Could not 
fetchhttps://img.shields.io/badge/Github-0.1--0-blue.svg

TlsExceptionHostPort (HandshakeFailed Error_EOF) "img.shields.io" 443

I've been looking for information about it, and it seems to be 
reported as bug of Pandoc. Same occur if I use an http link instead. 
I didn't find any successful alternative to remove this warning, and 
of course for this package and others i maintain, i would like to 
keep the 2 badges, 1 for CRAN and 1 for Github so user can quickly 
check if there is a pending revision in Github.


R CRAN checks links:
- old release:https://win-builder.r-project.org/GphApwuaD56b
- release:https://win-builder.r-project.org/maQicmvW941l
- devel:https://win-builder.r-project.org/OLSqwXd4W442

I would be very grateful if someone can shed light on this, and 
suggest a solution, so i could re-submit the package to CRAN.


Best regards
Emmanuel


 Message transf�r� 
Sujet : [CRAN-pretest-archived] CRAN submission geometa 0.1-0
Date : Thu, 25 May 2017 20:21:22 +0200
De : uwe.lig...@r-project.org
R�pondre � : c...@r-project.org
Pour : emmanuel.blond...@gmail.com
Copie � : c...@r-project.org



Dear maintainer,
   package geometa_0.1-0.tar.gz does not pass the incoming checks 
automatically, please see the pre-test at:
<https://win-builder.r-project.org/incoming_pretest/170525_152229_geometa_010/00check.log> 


Status: 1 WARNING, 1 NOTE
   Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for 
help on the R-package-devel mailing list:

<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
If you are fairly certain the rejection is a false positive, please 
reply-all to this message and explain.

   More details are given in the directory:
<https://win-builder.r-project.org/incoming_pretest/170525_152229_geometa_010> 


The files will be removed after roughly 7 days.
  Best regards,
CRAN teams' auto-check service


[[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] Package submission - Issue with pandoc in R CMD check

2017-05-27 Thread Emmanuel Blondel

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. 
Thanks & best regards


Le 27/05/2017 à 16:25, Uwe Ligges a écrit :
> For geometa:
>
> If you resubmit without the access to "img.shields.io", we can publish 
> now. Otherweise, as we have not yet managed to get a univesally 
> working pandoc on the CRAN master, we cannot publish your package yet.
>
> Best,
> Uwe Ligges
>
>
>
>
>
> On 27.05.2017 16:20, Emmanuel Blondel wrote:
>> Thanks Uwe for your clarifications. Can you let me know if i need to 
>> change something on my side, and/or resubmit the package to CRAN? 
>> (the warning on Pandoc was the only one) Thanks in advance
>>
>> Best,
>> Emmanuel
>>
>> Le 26/05/2017 à 00:11, Uwe Ligges a écrit :
>>> This is currently under inspection by the CRAN team. Apparently 
>>> img.shields.io have changed the cypher settings and pandoc fails 
>>> with the new settings. We may have to disable *.md processing for 
>>> some time.
>>>
>>> Best,
>>> Uwe Ligges
>>>
>>>
>>>
>>> On 25.05.2017 20:59, Emmanuel Blondel wrote:
>>>> Dear all,
>>>>
>>>> I've just submitted a new package named geometa, for which i 
>>>> received the message below. Indeed i had sent in my submission some 
>>>> question mark about the warning i obtain during R CMD check:
>>>>
>>>> In case of R release and R devel, I got the following warning:
>>>>
>>>> Conversion of 'README.md' failed:
>>>> pandoc.exe: Could not 
>>>> fetchhttps://img.shields.io/badge/Github-0.1--0-blue.svg
>>>> TlsExceptionHostPort (HandshakeFailed Error_EOF) "img.shields.io" 443
>>>>
>>>> I've been looking for information about it, and it seems to be 
>>>> reported as bug of Pandoc. Same occur if I use an http link 
>>>> instead. I didn't find any successful alternative to remove this 
>>>> warning, and of course for this package and others i maintain, i 
>>>> would like to keep the 2 badges, 1 for CRAN and 1 for Github so 
>>>> user can quickly check if there is a pending revision in Github.
>>>>
>>>> R CRAN checks links:
>>>> - old release:https://win-builder.r-project.org/GphApwuaD56b
>>>> - release:https://win-builder.r-project.org/maQicmvW941l
>>>> - devel:https://win-builder.r-project.org/OLSqwXd4W442
>>>>
>>>> I would be very grateful if someone can shed light on this, and 
>>>> suggest a solution, so i could re-submit the package to CRAN.
>>>>
>>>> Best regards
>>>> Emmanuel
>>>>
>>>>
>>>>  Message transf�r� 
>>>> Sujet : [CRAN-pretest-archived] CRAN submission geometa 0.1-0
>>>> Date : Thu, 25 May 2017 20:21:22 +0200
>>>> De : uwe.lig...@r-project.org
>>>> R�pondre � : c...@r-project.org
>>>> Pour : emmanuel.blond...@gmail.com
>>>> Copie � : c...@r-project.org
>>>>
>>>>
>>>>
>>>> Dear maintainer,
>>>>package geometa_0.1-0.tar.gz does not pass the incoming checks 
>>>> automatically, please see the pre-test at:
>>>> <https://win-builder.r-project.org/incoming_pretest/170525_152229_geometa_010/00check.log>
>>>>  
>>>>
>>>> Status: 1 WARNING, 1 NOTE
>>>>Please fix all problems and resubmit a fixed version via the 
>>>> webform.
>>>> If you are not sure how to fix the problems shown, please ask for 
>>>> help on the R-package-devel mailing list:
>>>> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>>>> If you are fairly certain the rejection is a false positive, please 
>>>> reply-all to this message and explain.
>>>>More details are given in the directory:
>>>> <https://win-builder.r-project.org/incoming_pretest/170525_152229_geometa_010>
>>>>  
>>>>
>>>> The files will be removed after roughly 7 days.
>>>>   Best regards,
>>>> CRAN teams' auto-check service
>>>>
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>>
>>>>
>>>> __
>>>> R-package-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>

-- 
*Emmanuel Blondel*
International Consultant | CEO
/Geographic Information Systems in Agronomy, Environment, Fishery & 
Marine Sciences/
41, Avenue du Vacayrial
81370 Saint Sulpice la Pointe, France
Tel: +33 (0) 6 45 97 87 52
Website: http://eblondel.github.io <http://eblondel.github.io/#/services>
Email: emmanuel.blond...@gmail.com <mailto:emmanuel.blond...@gmail.com>

[[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] new maintainer for CRAN package XML

2024-01-24 Thread Emmanuel Blondel

if XML is deprecated, then what would be the choice for a package 
maintainer? Move to xml2 probably at some point I assume


I use XML in the R packages I've been developing. For some of them, I 
started before CRAN started being the maintainer, and before xml2 
inception. The thing is that XML fulfills requirements, it works and 
fulfills needs of depending packages that made the choice to use it. For 
this, it deserves to be maintained in CRAN, without having to enter into 
comparison exercices with other packages that , as of today, may be 
better to rely on (with certainly very good reasons).


Moving to xml2 (or whatever other package), which although I could agree 
on the principle, can be costly for packages that use extensively XML. 
Doing so would mean that we first get the assurance that all XML 
features are covered elsewhere, and can be migrated smoothly.


In any case, please acknowledge that this kind of migration may take 
time and require resources that vary (or even are missing) depending on 
the package projects. I doubt having CRAN setting a common deadline for 
retirement is a good way to foster an efficient maintenance of R 
packages depending on XML. It would be good to receive guidance how to 
migrate, while ensuring backward compatibility on our package features.


Best

Le 24/01/2024 à 15:59, Jeroen Ooms a écrit :

On Mon, Jan 22, 2024 at 3:51 PM Uwe Ligges
 wrote:

Dear package developers,

the CRAN team (and Professor Ripley in particular) has been the defacto
maintainer of CRAN package 'XML'.
Our hope was that maintainers of packages depending on XML will migrate
to other packages for reading XML structures. This has not happened and
we still see dozens of strong dependencies on XML.

How is this hope communicated? Many R users assume that XML package is
in great shape and the preferable choice because it is maintained by
the CRAN team and r-core members.

Perhaps one could follow the precedent from the rgdal retirement, and
set a deadline.

One way to communicate this effectively would be by introducing a
formal deprecation field in the package description. This could then
be displayed on the XML CRAN html page, and when loading the package
interactively. Other packages that import such a deprecated package
could be given a CMD check warning.

__
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] Issue with package check on Debian, XML issue?

2018-12-16 Thread Emmanuel Blondel (GMAIL)

Dear all, I've received some notice from CRAN to fix issues in geometa 
pkg i'm maintaining. I've fixed some issue, and tried to upload a 
package package. I've tested the package on x86_64-pc-linux-gnu (64-bit) 
/ Ubuntu 14.04.5 LTS, and Windows OS. For both, R CMD check goes well. 
Here results for Win.


https://win-builder.r-project.org/7ZXV14p14Spe
https://win-builder.r-project.org/RwX93ZPJuMr8
https://win-builder.r-project.org/9O8W7dYJLlOW

I've received pre-archived message here below stating that they are 
still issues on Debian.


I receive  2 messages that let me suspect this is due to an issue with 
XML package:


Error: package or namespace load failed for ‘XML’:

 .onLoad failed in loadNamespace() for ‘XML’, details:

  call: dyn.load(file, DLLpath = DLLpath, ...)

  error: unable to load shared object 
‘/home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/XML/libs/XML.so’:


  /home/hornik/tmp/R.check/r-devel-clang/Work/build/Packages/XML/libs/XML.so: 
failed to map segment from shared object

(this message also appears in this moment for XML package checks 
https://cran.r-project.org/web/checks/check_results_XML.html)


and

Unknown IO errorfailed to load external entity


Would someone have any idea what could be wrong? I'm stuck on that.

Thanks in advance for your help,

Best,
Emmanuel


 Message transféré 
Sujet : [CRAN-pretest-archived] CRAN submission geometa 0.4-0
Date :  Sun, 16 Dec 2018 17:24:56 +0100
De :lig...@statistik.tu-dortmund.de
Répondre à :cran-submissi...@r-project.org
Pour :  emmanuel.blond...@gmail.com
Copie à :   cran-submissi...@r-project.org



Dear maintainer,
package geometa_0.4-0.tar.gz does not pass the incoming checks 
automatically, please see the following pre-tests:
Windows: 
<https://win-builder.r-project.org/incoming_pretest/geometa_0.4-0_20181216_165029/Windows/00check.log>

Status: OK
Debian: 
<https://win-builder.r-project.org/incoming_pretest/geometa_0.4-0_20181216_165029/Debian/00check.log>

Status: 2 ERRORs
Last released version's CRAN status: ERROR: 10, NOTE: 1, OK: 1
See: <https://CRAN.R-project.org/web/checks/check_results_geometa.html>
CRAN Web: <https://cran.r-project.org/package=geometa>
Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help 
on the R-package-devel mailing list:

<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
If you are fairly certain the rejection is a false positive, please 
reply-all to this message and explain.

More details are given in the directory:
<https://win-builder.r-project.org/incoming_pretest/geometa_0.4-0_20181216_165029/>
The files will be removed after roughly 7 days.
*** Strong rev. depends ***: geonapi ows4R
Best regards,
CRAN teams' auto-check service

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
  Maintainer: 'Emmanuel Blondel '

Flavor: r-devel-windows-ix86+x86_64
Check: Overall checktime, Result: NOTE
  Overall checktime 18 min > 10 min

Flavor: r-devel-linux-x86_64-debian-gcc
Check: examples, Result: ERROR
  Running examples in 'geometa-Ex.R' failed
  The error most likely occurred in:
  
  > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
  > ### Name: GMLBaseUnit
  > ### Title: GMLBaseUnit
  > ### Aliases: GMLBaseUnit
  > ### Keywords: GML ISO base definition unit
  > 
  > ### ** Examples
  > 
  >   gml <- GMLBaseUnit$new()
  >   gml$setDescriptionReference("someref")
  >   gml$setIdentifier("identifier", "codespace")
  >   gml$addName("name1", "codespace")
  [1] TRUE
  >   gml$addName("name2", "codespace")
   --- FAILURE REPORT -- 
   --- failure: length > 1 in coercion to logical ---
   --- srcref --- 
  : 
   --- package (from environment) --- 
  geometa
   --- call from context --- 
  FUN(X[[i]], ...)
   --- call from argument --- 
  (class(self[[x]]) %in% c("environment", "function")) || (x %in% 
  private$system_fields)
   --- R stacktrace ---
  where 1: FUN(X[[i]], ...)
  where 2: lapply(X = X, FUN = FUN, ...)
  where 3: sapply(fields, function(x) {
  (class(self[[x]]) %in% c("environment", "function")) || (x %in% 
  private$system_fields)
  })
  where 4: metadataElement1$encode(addNS = TRUE, validate = FALSE, 
resetSerialID = FALSE, 
  setSerialID = FALSE)
  where 5: ISOAbstractObject$compare(x, metadataElement)
  where 6: FUN(X[[i]], ...)
  where 7: lapply(X = X, FUN = FUN, ...)
  where 8: sapply(self[[field]], function(x) {
  ISOAbstractObject$compare(x, metadataElement)
  })
  where 9: self$contains(field, metadataElement)
  where

[R-pkg-devel] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes

2019-05-24 Thread Emmanuel Blondel (GMAIL)

Dear all, I write here as i'm in process to submit a revision of 
/geometa/ package to CRAN in which i've enabled some coercing methods 
between main metadata object ISOMetadata from geometa, and foreign 
metadata objects (from emld / ncdf4 packages)

I've received a "pre-test archived" notification, because of the 
folllowing warnings dealing with the coercing:

   Warning: in method for 'coerce' with signature '"ISOMetadata","emld"': no 
definition for classes "ISOMetadata", "emld"
   Warning: in method for 'coerce' with signature '"emld","ISOMetadata"': no 
definition for classes "emld", "ISOMetadata"
   Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"': no 
definition for classes "ncdf4", "ISOMetadata"

Detail at: 
https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log

I've found this thread that seems to discuss the same matter: 
https://github.com/r-spatial/sf/issues/129 . I'm facing the same 
situation where there is no good reason enough to add emld, ncdf4 as 
Imports, but rather to keep them as Suggests, as they are only used in 
these specific converters. In the doubt, i prefer asking here if there 
is some good practice to deal with these warnings, eventually to avoid 
it, or if this is considered by CRAN team as false positive.

Thanks a lot for your advice,

Best,
Emmanuel



[[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] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes

2019-05-26 Thread Emmanuel Blondel (GMAIL)


Thank

Thank you Martin for your help and for this solution, warnings 
disappeared with this, and i've re-submitted the package.


Best,
Emmanuel

Le 26/05/2019 à 10:13, Martin Morgan a écrit :

Since ncdf4 (and emld) both use S3 class systems, it is sufficient to simply 
declare

 setOldClass("ncdf4")

some time prior to using setAs() .

Martin

On 5/24/19, 6:41 PM, "R-package-devel on behalf of Emmanuel Blondel (GMAIL)" 
 wrote:

 Dear all, I write here as i'm in process to submit a revision of
 /geometa/ package to CRAN in which i've enabled some coercing methods
 between main metadata object ISOMetadata from geometa, and foreign
 metadata objects (from emld / ncdf4 packages)
 
 I've received a "pre-test archived" notification, because of the

 folllowing warnings dealing with the coercing:
 
Warning: in method for 'coerce' with signature '"ISOMetadata","emld"': no definition for classes "ISOMetadata", "emld"

Warning: in method for 'coerce' with signature '"emld","ISOMetadata"': no definition for 
classes "emld", "ISOMetadata"
Warning: in method for 'coerce' with signature '"ncdf4","ISOMetadata"': no definition for 
classes "ncdf4", "ISOMetadata"
 
 Detail at:

 
https://win-builder.r-project.org/incoming_pretest/geometa_0.5-0_20190524_153346/Windows/00check.log
 
 I've found this thread that seems to discuss the same matter:

 https://github.com/r-spatial/sf/issues/129 . I'm facing the same
 situation where there is no good reason enough to add emld, ncdf4 as
 Imports, but rather to keep them as Suggests, as they are only used in
 these specific converters. In the doubt, i prefer asking here if there
 is some good practice to deal with these warnings, eventually to avoid
 it, or if this is considered by CRAN team as false positive.
 
 Thanks a lot for your advice,
 
 Best,

 Emmanuel
 
 
 
 	[[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] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

2020-09-02 Thread Emmanuel Blondel (GMAIL)

Dear all,

I've received a notification of errors from CRAN on some package (zen4R) 
recently updated, being asked to fix within the 2 weeks before archiving.

The error deals with 'keyring' package import at test time, on _Fedora_ 
flavors only.

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


I'm not running this OS so I used the R-hub package builder 
(https://builder.r-hub.io/advanced ) 
to re-test on these flavors:

     - Fedora Linux, R-devel, GCC : 
https://builder.r-hub.io/status/zen4R_0.4.tar.gz-8031e4afba828ef9d3f7933b7231207e
 


     - Fedora Linux, R-devel, clang, gfortran: 
https://builder.r-hub.io/status/zen4R_0.4.tar.gz-5fc1d63c756b7c4b650da06ed87f7c35
 


On both, status is OK, so I still wonder why I get these errors on CRAN,

Your advice in order to solve that would be much appreciated,

Thanks a lot

Emmanuel




[[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] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

2020-09-03 Thread Emmanuel Blondel (GMAIL)


Thanks both for your quick answers,

I've implemented a solution to avoid the keyring issue by handling 
properly the error, and catch it properly in test-all.R (as a better 
control to deactivate CI integration tests if Zenodo token is invalid - 
which is the case on CRAN).


https://github.com/eblondel/zen4R/commit/ff3c34a20b486e547bbc684a696cfe15eb8c37bd 
<https://github.com/eblondel/zen4R/commit/ff3c34a20b486e547bbc684a696cfe15eb8c37bd>


zen4R has been resubmitted and Fedora CRAN builds are fine now.

Emmanuel

Le 03/09/2020 à 00:39, Gábor Csárdi a écrit :

On Wed, Sep 2, 2020 at 11:11 PM Dirk Eddelbuettel  wrote:


On 2 September 2020 at 23:59, Emmanuel Blondel (GMAIL) wrote:

[...]

| Your advice in order to solve that would be much appreciated,

Life, as they say, "is too short" so you could just comment-out the test.

Indeed, it is probably best not to run this test on CRAN's machines.

It probably fails because CRAN's keyring package is built without the
OS's keyring library, at least on Fedora.

But really, ideally you would not access the OS keyring in test cases,
except when running on a CI, or on the developers' machines.

Gabor

[...]


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

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

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

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

Re: [R-pkg-devel] new maintainer for CRAN package XML

[R-pkg-devel] Issue with package check on Debian, XML issue?

[R-pkg-devel] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes

Re: [R-pkg-devel] Advice on setAs - issue of "in method for 'coerce' with signature / no definition for classes

[R-pkg-devel] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

Re: [R-pkg-devel] Advice for solving ERRORs in Fedora reported on CRAN / zen4R package

9 matches

Site Navigation

Mail list logo

Footer information