Re: [R-pkg-devel] State of the art for UBSAN testing

[Ralf Stubner]

Thanks Gábor! If one checks the output, one can indeed find the UBSAN
error. Problem solved!

Ralf

On Thu, May 16, 2024 at 8:40 PM Gábor Csárdi  wrote:
>
> R-hub v2 has UBSAN testing, the clang-asan image also has UBSAN. [1]
>
> With the glitch that UBSAN errors do not fail the build because of a bug [2],
> so you'll need to look at the results even if the build has passed.
>
> Gabor
>
> [1] https://r-hub.github.io/containers/
> [2] https://github.com/r-hub/actions/issues/16
>
> On Thu, May 16, 2024 at 10:27 PM Ralf Stubner  wrote:
> >
> > Dear all,
> >
> > I have been asked to fix a UBSAN error in my dqrng package. The error
> > itself and the necessary fix are quite straight forward. However, I
> > want to make 100% sure that I am really fixing the error. In the past
> > I had used rhub for tasks like that. But it seems like the new rhub v2
> > offers only ASAN testing. I have also tried various docker images
> > (wch1/r-debug, old rhub images, rocker), but with none of them I was
> > able to reproduce the error seen on CRAN. What would you consider as
> > "state of the art" for reproducing UBSAN errors?
> >
> > Thanks
> > Ralf
> >
> > __
> > 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] State of the art for UBSAN testing

[Gábor Csárdi]

R-hub v2 has UBSAN testing, the clang-asan image also has UBSAN. [1]

With the glitch that UBSAN errors do not fail the build because of a bug [2],
so you'll need to look at the results even if the build has passed.

Gabor

[1] https://r-hub.github.io/containers/
[2] https://github.com/r-hub/actions/issues/16

On Thu, May 16, 2024 at 10:27 PM Ralf Stubner  wrote:
>
> Dear all,
>
> I have been asked to fix a UBSAN error in my dqrng package. The error
> itself and the necessary fix are quite straight forward. However, I
> want to make 100% sure that I am really fixing the error. In the past
> I had used rhub for tasks like that. But it seems like the new rhub v2
> offers only ASAN testing. I have also tried various docker images
> (wch1/r-debug, old rhub images, rocker), but with none of them I was
> able to reproduce the error seen on CRAN. What would you consider as
> "state of the art" for reproducing UBSAN errors?
>
> Thanks
> Ralf
>
> __
> 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] State of the art for UBSAN testing

[Ralf Stubner]

Dear all,

I have been asked to fix a UBSAN error in my dqrng package. The error
itself and the necessary fix are quite straight forward. However, I
want to make 100% sure that I am really fixing the error. In the past
I had used rhub for tasks like that. But it seems like the new rhub v2
offers only ASAN testing. I have also tried various docker images
(wch1/r-debug, old rhub images, rocker), but with none of them I was
able to reproduce the error seen on CRAN. What would you consider as
"state of the art" for reproducing UBSAN errors?

Thanks
Ralf

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

Re: [R-pkg-devel] Altrep header, MSVC, and STRUCT_SUBTYPES macro

[David Cortes]

Thanks for the hints.

Unfortunately, after some further testing, it seems this was just a
matter of getting lucky - using the alternative non-STRUCT_SUBTYPES 
def. of Altrep still leads to memory corruptions and crashes, just at
different points than when using the STRUCT_SUBTYPES definition. Sorry
for the trouble.

> Interesting ABI incompatibility you've found. Can you show a minimal
> example? I've tried playing with https://godbolt.org/ 

May I ask: how would you go around getting R code into Godbolt? Getting
something like the Altrep definitions and methods would involve a large
amount of R headers joined together before any package code.

> Out of curiousity - which functionalities are those ?

As I understand it (not the author of the package), this is about
integrations with frameworks for GPU computing, and the Altrep code is
used for returning the results of model fitting and serialization
functions, so unfortunately not feasible to move it to a different
package.

> it's also important to find out where exactly the
> incompatibility arises from

I unfortunately haven't been able to isolate the issue, and am not sure
how to. As far as I can tell, the altrep methods are calling the
functions which they were assigned so at least the 'set' and 'dataptr'
methods are working, but memory corruptions that crash the program
happen after calling such altrep methods, particularly when there is a
combination of 'R_UnwindProtect', C++ 'catch' that involves destructing
variables before 'R_ContinueUnwind', and then 'Rf_error'.

On Thu, 2024-05-16 at 16:25 +0300, Ivan Krylov wrote:
> В Wed, 15 May 2024 18:54:37 +0200
> David Cortes  пишет:
> 
> > The code compiles without errors under MSVC, but executing code
> > that
> > involves returning Altrep objects leads to segfaults and memory
> > corruptions, even though it works fine under other compilers.
> > 
> > I see the R Altrep header has this section:
> > #define STRUCT_SUBTYPES
> > #ifdef STRUCT_SUBTYPES
> > # define R_SEXP(x) (x).ptr
> > # define R_SUBTYPE_INIT(x) { x }
> >   typedef struct { SEXP ptr; } R_altrep_class_t;
> > #else
> > # define R_SEXP(x) ((SEXP) (x))
> > # define R_SUBTYPE_INIT(x) (void *) (x)
> >   typedef struct R_altcls *R_altrep_class_t;
> > #endif
> 
> Interesting ABI incompatibility you've found. Can you show a minimal
> example? I've tried playing with https://godbolt.org/ and passing
> around values of type R_altrep_class_t between functions, but
> couldn't
> convince "x64 msvc v19.latest" to generate different assembly no
> matter
> whether R_altrep_class_t was a pointer or a struct containing a SEXP.
> 
> > If I manually edit the R header to remove the definition of
> > 'STRUCT_SUBTYPES', leading to the second definition of
> > 'R_altrep_class_t' being used, then things work as expected when
> > the
> > package is compiled with MSVC (no segfaults and no memory
> > corruptions).
> 
> While it's hard to argue with results (I don't think it'll ever be
> broken on x86_64 Windows), this workaround relies on undefined
> behaviour and will only work as long as the ABI as understood by GCC
> passes a structure with a pointer inside exactly the same way as the
> ABI as understood by MSVC passes a bare pointer.
> 
> Isolating the MSVC-specific code as suggested by Vladimir should be
> safer, but it's also important to find out where exactly the
> incompatibility arises from. The GCC and MSVC parts still have to use
> a
> common ABI to talk to each other.
> 

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

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Ivan Krylov via R-package-devel]

В Thu, 16 May 2024 16:01:45 +
Zeinab Mashreghi  пишет:

> checking HTML version of manual ... NOTE
> Found the following HTML validation problems:
> All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type"
> attribute
> All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Michael Dewey]

Dear Zeinab

Perhaps the insights in https://github.com/tidymodels/infer/issues/455 
will help you especially if you are using roxygen2


Michael

On 16/05/2024 17:01, Zeinab Mashreghi wrote:

Hi,

Thank you very much for your helpful suggestion! Following your advice, I 
revisited the package and made necessary adjustments to the description file. 
However, it appears that there are now some issues with HTML validation in the 
.Rd files. Here's the relevant excerpt, and I've attached the log for further 
reference.

checking HTML version of manual ... NOTE
Found the following HTML validation problems:
All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type" attribute
All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Goldfeld, Keith via R-package-devel]

Zeinab

I have found that setting this system value to FALSE eliminates the issue:

Sys.setenv("_R_CHECK_RD_VALIDATE_RD2HTML_" = FALSE)

- Keith

On 5/16/24, 12:02 PM, "R-package-devel on behalf of Zeinab Mashreghi" 
mailto:r-package-devel-boun...@r-project.org> on behalf of 
z.mashre...@uwinnipeg.ca > wrote:


[EXTERNAL]


Hi,


Thank you very much for your helpful suggestion! Following your advice, I 
revisited the package and made necessary adjustments to the description file. 
However, it appears that there are now some issues with HTML validation in the 
.Rd files. Here's the relevant excerpt, and I've attached the log for further 
reference.


checking HTML version of manual ... NOTE
Found the following HTML validation problems:
All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type" attribute
All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Zeinab Mashreghi]

Hi,

Thank you very much for your helpful suggestion! Following your advice, I 
revisited the package and made necessary adjustments to the description file. 
However, it appears that there are now some issues with HTML validation in the 
.Rd files. Here's the relevant excerpt, and I've attached the log for further 
reference.

checking HTML version of manual ... NOTE
Found the following HTML validation problems:
All.data.html:4:1 (All.data.Rd:10): Warning:  inserting "type" attribute
All.data.html:12:1 (All.data.Rd:10): Warning: 

Re: [R-pkg-devel] Altrep header, MSVC, and STRUCT_SUBTYPES macro

[Ivan Krylov via R-package-devel]

В Wed, 15 May 2024 18:54:37 +0200
David Cortes  пишет:

> The code compiles without errors under MSVC, but executing code that
> involves returning Altrep objects leads to segfaults and memory
> corruptions, even though it works fine under other compilers.
> 
> I see the R Altrep header has this section:
> #define STRUCT_SUBTYPES
> #ifdef STRUCT_SUBTYPES
> # define R_SEXP(x) (x).ptr
> # define R_SUBTYPE_INIT(x) { x }
>   typedef struct { SEXP ptr; } R_altrep_class_t;
> #else
> # define R_SEXP(x) ((SEXP) (x))
> # define R_SUBTYPE_INIT(x) (void *) (x)
>   typedef struct R_altcls *R_altrep_class_t;
> #endif

Interesting ABI incompatibility you've found. Can you show a minimal
example? I've tried playing with https://godbolt.org/ and passing
around values of type R_altrep_class_t between functions, but couldn't
convince "x64 msvc v19.latest" to generate different assembly no matter
whether R_altrep_class_t was a pointer or a struct containing a SEXP.

> If I manually edit the R header to remove the definition of
> 'STRUCT_SUBTYPES', leading to the second definition of
> 'R_altrep_class_t' being used, then things work as expected when the
> package is compiled with MSVC (no segfaults and no memory
> corruptions).

While it's hard to argue with results (I don't think it'll ever be
broken on x86_64 Windows), this workaround relies on undefined
behaviour and will only work as long as the ABI as understood by GCC
passes a structure with a pointer inside exactly the same way as the
ABI as understood by MSVC passes a bare pointer.

Isolating the MSVC-specific code as suggested by Vladimir should be
safer, but it's also important to find out where exactly the
incompatibility arises from. The GCC and MSVC parts still have to use a
common ABI to talk to each other.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] CRAN packages dependency on bioconductor packages

[Dirk Eddelbuettel]

On 16 May 2024 at 05:34, Duncan Murdoch wrote:
| I forget now, but presumably the thinking at the time was that Suggested 
| packages would always be available for building and checking vignettes.

Yes. I argued for years (cf https://dirk.eddelbuettel.com/blog/2017/03/22/
from seven (!!) years ago) and CRAN is slowly moving away from that implicit
'always there' guarantee to prefering explicit enumerations -- and now even
tests via the NoSuggests flavour.

As Uwe stated in this thread, having the vignette dependencies both in
Suggests as well as in the VignetteHeader should do. And it is the Right
Thing (TM) to do.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] CRAN packages dependency on bioconductor packages

[Sebastian Meyer]

Am 16.05.24 um 11:34 schrieb Duncan Murdoch:

On 2024-05-16 4:15 a.m., Sebastian Meyer wrote:

Am 15.05.24 um 00:09 schrieb Lluís Revilla:

Hi Junhui,

There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle 
installed.
I don't know if it is possible to use a vignette output conditionally 
with

knitr: In any case it seems that it would be a requirement (Imports, or
Depends).


Yes, I'd consider the package providing the vignette output format for
the rmarkdown engine, here BiocStyle, as a strong dependency of that
vignette.


It is documented in WRE as a soft dependency of the package: "As Sweave 
is the only engine supplied with the R distribution, the package 
providing any other engine must be specified in the ‘VignetteBuilder’ 
field of the package DESCRIPTION file, and also specified in the 
‘Suggests’, ‘Imports’ or ‘Depends’ field (since its namespace must be 
available to build or check your package)."


I forget now, but presumably the thinking at the time was that Suggested 
packages would always be available for building and checking vignettes.


With most soft dependencies, it's up to the package writer to handle the 
possibility that it is missing, but here, I think it has to be the check 
code that does it, skipping the vignette test if the builder is missing.


Yes, re-building vignettes is skipped when a VignetteBuilder package is 
unavailable.


In the present case, the VignetteBuilder package that provides the 
engine is knitr and BiocStyle is used for an alternative rmarkdown 
output format. Not sure if the latter should be declared as an 
additional VignetteBuilder even if it does not provide the vignette 
engine, but you are right that it comes very close.




Alternatively, it could be required to be a hard dependency, but that 
seems too strong:  most package users don't need to rebuild vignettes.


Agreed. Declaring it as part of the vignette's \VignetteDepends is what 
I'd do to solve the check issue.


Sebastian Meyer



Duncan Murdoch


  The error from the additional "noSuggests" check

() shows it
cannot be rebuild if BiocStyle is unavailable.

The 'StepReg' vignette could use a metadata line to declare strong
vignette dependencies, for example:

  %\VignetteDepends{StepReg, BiocStyle, kableExtra}

(I haven't checked if this list is complete.)

This avoids spurious check errors in incomplete setups, such as when
mass-checking packages (e.g., reverse dependencies) without some of the
suggested packages being installed.

Best,

Sebastian Meyer



However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from 
rmarkdown

if I recall correctly).
You will remove a dependency and avoid this problem entirely.

Best,

Lluís


On Tue, 14 May 2024 at 22:48, Li, Junhui  
wrote:



Hi everyone,

I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:

output:
    BiocStyle::html_document:
  toc_float: true
    BiocStyle::pdf_document: default

In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:

VignetteBuilder: knitr
biocViews:
Suggests:
  knitr,
  testthat,
  BiocStyle,
  kableExtra

You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev

There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error 
message

occurred when I attempted to upload it to CRAN:

* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'

SUMMARY: processing the following file failed:
 'StepReg.Rmd'

Error: Vignette re-building failed.
Execution halted

For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.

Thanks,
Junhui

  [[alternative HTML version deleted]]

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



[[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] CRAN packages dependency on bioconductor packages

[Uwe Ligges]

On 16.05.2024 10:15, Sebastian Meyer wrote:

Am 15.05.24 um 00:09 schrieb Lluís Revilla:

Hi Junhui,

There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle installed.
I don't know if it is possible to use a vignette output conditionally 
with

knitr: In any case it seems that it would be a requirement (Imports, or
Depends).


Yes, I'd consider the package providing the vignette output format for 
the rmarkdown engine, here BiocStyle, as a strong dependency of that 
vignette. The error from the additional "noSuggests" check 
() shows it 
cannot be rebuild if BiocStyle is unavailable.


The 'StepReg' vignette could use a metadata line to declare strong 
vignette dependencies, for example:


     %\VignetteDepends{StepReg, BiocStyle, kableExtra}


Indeed, having it listed in Suggests plus the \VignetteDepends 
declaration should suffice.


Best,
Uwe Ligges





(I haven't checked if this list is complete.)

This avoids spurious check errors in incomplete setups, such as when 
mass-checking packages (e.g., reverse dependencies) without some of the 
suggested packages being installed.


Best,

 Sebastian Meyer



However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from 
rmarkdown

if I recall correctly).
You will remove a dependency and avoid this problem entirely.

Best,

Lluís


On Tue, 14 May 2024 at 22:48, Li, Junhui  
wrote:



Hi everyone,

I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:

output:
   BiocStyle::html_document:
 toc_float: true
   BiocStyle::pdf_document: default

In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:

VignetteBuilder: knitr
biocViews:
Suggests:
 knitr,
 testthat,
 BiocStyle,
 kableExtra

You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev

There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error message
occurred when I attempted to upload it to CRAN:

* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'

SUMMARY: processing the following file failed:
    'StepReg.Rmd'

Error: Vignette re-building failed.
Execution halted

For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.

Thanks,
Junhui

 [[alternative HTML version deleted]]

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



[[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] CRAN packages dependency on bioconductor packages

[Duncan Murdoch]

On 2024-05-16 4:15 a.m., Sebastian Meyer wrote:

Am 15.05.24 um 00:09 schrieb Lluís Revilla:

Hi Junhui,

There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle installed.
I don't know if it is possible to use a vignette output conditionally with
knitr: In any case it seems that it would be a requirement (Imports, or
Depends).


Yes, I'd consider the package providing the vignette output format for
the rmarkdown engine, here BiocStyle, as a strong dependency of that
vignette.


It is documented in WRE as a soft dependency of the package: "As Sweave 
is the only engine supplied with the R distribution, the package 
providing any other engine must be specified in the ‘VignetteBuilder’ 
field of the package DESCRIPTION file, and also specified in the 
‘Suggests’, ‘Imports’ or ‘Depends’ field (since its namespace must be 
available to build or check your package)."


I forget now, but presumably the thinking at the time was that Suggested 
packages would always be available for building and checking vignettes.


With most soft dependencies, it's up to the package writer to handle the 
possibility that it is missing, but here, I think it has to be the check 
code that does it, skipping the vignette test if the builder is missing.


Alternatively, it could be required to be a hard dependency, but that 
seems too strong:  most package users don't need to rebuild vignettes.


Duncan Murdoch


 The error from the additional "noSuggests" check

() shows it
cannot be rebuild if BiocStyle is unavailable.

The 'StepReg' vignette could use a metadata line to declare strong
vignette dependencies, for example:

  %\VignetteDepends{StepReg, BiocStyle, kableExtra}

(I haven't checked if this list is complete.)

This avoids spurious check errors in incomplete setups, such as when
mass-checking packages (e.g., reverse dependencies) without some of the
suggested packages being installed.

Best,

Sebastian Meyer



However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from rmarkdown
if I recall correctly).
You will remove a dependency and avoid this problem entirely.

Best,

Lluís


On Tue, 14 May 2024 at 22:48, Li, Junhui  wrote:


Hi everyone,

I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:

output:
BiocStyle::html_document:
  toc_float: true
BiocStyle::pdf_document: default

In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:

VignetteBuilder: knitr
biocViews:
Suggests:
  knitr,
  testthat,
  BiocStyle,
  kableExtra

You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev

There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error message
occurred when I attempted to upload it to CRAN:

* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'

SUMMARY: processing the following file failed:
 'StepReg.Rmd'

Error: Vignette re-building failed.
Execution halted

For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.

Thanks,
Junhui

  [[alternative HTML version deleted]]

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



[[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] Assistance Needed to Resolve CRAN Submission Note

[Ivan Krylov via R-package-devel]

Dear Zeinab,

Welcome to R-package-devel!

В Thu, 16 May 2024 03:22:56 +
Zeinab Mashreghi  пишет:

> I recently submitted my R package to CRAN, and I received this note
> from the CRAN teams: "checking CRAN incoming feasibility ... NOTE."

Without a link to the full error log and, ideally, to the source code
of the package, it's impossible to help with such a NOTE, because the
check for "CRAN incoming feasibility" encompasses many tests. I was
lucky to fish your package from the archived queue and correlate it
with the publicly available logs, but it's not always this simple:

https://win-builder.r-project.org/incoming_pretest/bootsurv_0.0.0.9000_20240515_212834/

>> New submission

This is expected and will always result in a NOTE to flag the package
to a CRAN reviewer.

>> Version contains large components (0.0.0.9000)

The convention is to use version components like 9000 for pre-release,
untested versions of packages. Could you please use a version like
0.0.1 for the version of the package to be released on CRAN?

> Unknown, possibly misspelled, fields in DESCRIPTION:
>  ‘ImportFrom’ ‘Data’

'importFrom' is a NAMESPACE file directive [1]. The DESCRIPTION must
list 'Imports:' instead [2]. What did you intend to mean with the Data:
field of your DESCRIPTION?

>> The Title field should be in title case. Current version is:
>> ‘Bootstrap Methods for complete (absence of missing values) survey
>> data’
>> In title case that is:
>> ‘Bootstrap Methods for Complete (Absence of Missing Values) Survey
>> Data’

This is yet another CRAN convention. You'll need to change the 'Title:'
field of the DESCRIPTION file.

>> * checking Rd line widths ... NOTE
>> Rd file 'boot.twostage.Rd':
>>  \examples lines wider than 100 characters:

Could you please wrap the lines of your \examples{} sections to 100
characters or less?

>> * checking examples ... [21m/21m] NOTE
>> Examples with CPU (user + system) or elapsed time > 5s
>>user system  elapsed
>> boot.weights.stsrs 1242.735  0.492 1243.285
>> boot.twostage 9.799  0.0489.847

The \examples{...} in your documentation are not only to be read by the
user. R CMD check runs them periodically on the CRAN servers. The user
should also be able to run example(boot.weights.stsrs) and see your
code directly in action. CRAN requires examples to run in 5 seconds or
less, both elapsed and CPU time. An example(...) that runs for 20
minutes is way too long. You'll need to find a way to reduce the time
spent in the example.

Wasn't something like this said in the e-mail you received from CRAN?

> When I run R CMD check on my device, I do not encounter any issues,

Even with R CMD check --as-cran?

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports

[2]
https://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file

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

Re: [R-pkg-devel] Assistance Needed to Resolve CRAN Submission Note

[Michael Dewey]

Dear Zeinab

It would help if you gave us more information. What exactly was the NOTE 
which it gave you?


Michael

On 16/05/2024 04:22, Zeinab Mashreghi wrote:

Hi,

I hope this message finds you well.

I recently submitted my R package to CRAN, and I received this note from the CRAN teams: 
"checking CRAN incoming feasibility ... NOTE."

When I run R CMD check on my device, I do not encounter any issues, and I am 
unsure of the specific steps I need to take to resolve this note.

Could you please provide guidance on how to address this note and ensure my 
package meets CRAN's requirements for submission? Any insights or 
recommendations you can offer would be greatly appreciated.

Thank you in advance for your assistance.

Best regards,
Zeinab

---

Zeinab Mashreghi, PhD
Associate Professor
Department of Mathematics and Statistics

P 204.786.9366


[[alternative HTML version deleted]]

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



--
Michael

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

Re: [R-pkg-devel] CRAN packages dependency on bioconductor packages

[Sebastian Meyer]

Am 15.05.24 um 00:09 schrieb Lluís Revilla:

Hi Junhui,

There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads to:
https://www.stats.ox.ac.uk/pub/bdr/noSuggests/StepReg.out
Where you can see that it fails if a user don't have BiocStyle installed.
I don't know if it is possible to use a vignette output conditionally with
knitr: In any case it seems that it would be a requirement (Imports, or
Depends).


Yes, I'd consider the package providing the vignette output format for 
the rmarkdown engine, here BiocStyle, as a strong dependency of that 
vignette. The error from the additional "noSuggests" check 
() shows it 
cannot be rebuild if BiocStyle is unavailable.


The 'StepReg' vignette could use a metadata line to declare strong 
vignette dependencies, for example:


%\VignetteDepends{StepReg, BiocStyle, kableExtra}

(I haven't checked if this list is complete.)

This avoids spurious check errors in incomplete setups, such as when 
mass-checking packages (e.g., reverse dependencies) without some of the 
suggested packages being installed.


Best,

Sebastian Meyer



However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from rmarkdown
if I recall correctly).
You will remove a dependency and avoid this problem entirely.

Best,

Lluís


On Tue, 14 May 2024 at 22:48, Li, Junhui  wrote:


Hi everyone,

I recently developed an R package called 'StepReg' and used the
Bioconductor R package 'BiocStyle' in my vignettes, as shown below:

output:
   BiocStyle::html_document:
 toc_float: true
   BiocStyle::pdf_document: default

In my DESCRIPTION file, I added 'BiocStyle' to the Suggests field and
included a new line 'biocViews:', as follows:

VignetteBuilder: knitr
biocViews:
Suggests:
 knitr,
 testthat,
 BiocStyle,
 kableExtra

You may find all those information here:
https://github.com/JunhuiLi1017/StepReg/tree/dev

There were no error messages when checking with 'R CMD check' and on
https://win-builder.r-project.org/upload.aspx. However, an error message
occurred when I attempted to upload it to CRAN:

* checking re-building of vignette outputs ... ERROR
Error(s) in re-building vignettes:
--- re-building 'StepReg.Rmd' using rmarkdown
Error: processing vignette 'StepReg.Rmd' failed with diagnostics:
there is no package called 'BiocStyle'
--- failed re-building 'StepReg.Rmd'

SUMMARY: processing the following file failed:
'StepReg.Rmd'

Error: Vignette re-building failed.
Execution halted

For version 1.5.0 (
https://cran.r-project.org/web/packages/StepReg/index.html), I
successfully uploaded it to CRAN without including 'biocViews:' in the
DESCRIPTION file two months ago. However, I'm encountering difficulties
this time. Any insights or suggestions on resolving this issue would be
greatly appreciated.

Thanks,
Junhui

 [[alternative HTML version deleted]]

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



[[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] Assistance Needed to Resolve CRAN Submission Note

[Zeinab Mashreghi]

Hi,

I hope this message finds you well.

I recently submitted my R package to CRAN, and I received this note from the 
CRAN teams: "checking CRAN incoming feasibility ... NOTE."

When I run R CMD check on my device, I do not encounter any issues, and I am 
unsure of the specific steps I need to take to resolve this note.

Could you please provide guidance on how to address this note and ensure my 
package meets CRAN's requirements for submission? Any insights or 
recommendations you can offer would be greatly appreciated.

Thank you in advance for your assistance.

Best regards,
Zeinab

---

Zeinab Mashreghi, PhD
Associate Professor
Department of Mathematics and Statistics

P 204.786.9366


[[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] Interpretation of rhub check failures

[Gábor Csárdi]

The lines
```
* checking examples with --run-donttest ...
Error: The operation was canceled.
```
and the 6 hours running time means that your build gets stuck while
running the examples, and then cancelled after 6 hours, that's the
time limit for a build.

This might or might not be specific for GitHub Acitions. If you want
to fix it, you'll need to figure out why the examples get stuck. Try
downloading the build artifacts, and see the output of the examples.
You might need to add more output to see what's going on.

Gabor

On Thu, May 16, 2024 at 1:18 AM Leonardo Cefalo
 wrote:
>
> Dear all,
>
> I should submit a new version of the package SchoolDataIT
>  and
> before doing so I need to check it on multiple flavors.
>
> So I have started trying some checks with rhub.
> I have loaded the new version of the package on github
> .
> It basically fails all checks, even if changes with respect to the
> previous version (the one on CRAN) are minor and should have no impact
> on the *most likely* causes of error, nor do devtools::check() or
> devtools::check_win_devel() return any error (but I cannot rely solely
> on these two checks since I have already experienced how unpredictably
> they behave on different flavors).
>
> What I am wondering about, however, is how to interpret error outputs
> like this
> (https://github.com/lcef97/SchoolDataIT/actions/runs/9092369467/job/24988944819,
> ubuntu-clang) or
> this(https://github.com/lcef97/SchoolDataIT/actions/runs/9092427648/job/24989126404
> atlas). I guess something wrong happens in the functions with
> --run-donttest.
>
> Could somebody please point me a way to interpret  these failures, or
> way to run checks with operating systems different than mine that does
> not involve the passage on github?
>
> Thank you very much in advance
> Best regards
> Leonardo
> 
> Sostieni la formazione e la ricerca universitaria con il tuo 5 per mille
> all'Università di Bari.
> Firma la casella "Finanziamento della ricerca scientifica e della
> Università"
> indicando il codice fiscale 80002170720.
>
> Il tuo contributo può fare la differenza: oggi più che mai!
>
> __
> 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