[R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

[stefano]

Hello,

I would like to point out that I (and others in various forums) find that
the CRAN check with the note :


*checking CRAN incoming feasibility ... NOTEMaintainer*

Triggers an email saying


1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
automatically*

2) *Please fix all problems and resubmit a fixed version via the webform*


While apparently nothing should be done, at least according to some forum
post
https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer

It would be nice to avoid this from the test side or the email side. It is
pretty confusing for developers who think that they have to act.


Best wishes.

*Stefano *



Stefano Mangiola | Postdoctoral fellow

Papenfuss Laboratory

The Walter Eliza Hall Institute of Medical Research

+61 (0)466452544

[[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] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

[stefano]

Hello Uwe,

OK sorry for that.

Best wishes.

*Stefano *



Stefano Mangiola | Postdoctoral fellow

Papenfuss Laboratory

The Walter Eliza Hall Institute of Medical Research

+61 (0)466452544


Il giorno mar 9 giu 2020 alle ore 00:40 Uwe Ligges <
lig...@statistik.tu-dortmund.de> ha scritto:

>
>
> On 08.06.2020 16:26, stefano wrote:
> > Hello,
> >
> > I would like to point out that I (and others in various forums) find that
> > the CRAN check with the note :
> >
> >
> > *checking CRAN incoming feasibility ... NOTEMaintainer*
>
>
> Not true, it also says
>
> Flavor: r-devel-windows-ix86+x86_64
> Check: running examples for arch 'x64', Result: NOTE
>Examples with CPU (user + system) or elapsed time > 10s
>  user system elapsed
>lower_triangular-methods 11.48  011.5
>
> Please reduce each example to less than 5 sec.
>
> Best,
> Uwe Ligges
> >
> > Triggers an email saying
> >
> >
> > 1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
> > automatically*
> >
> > 2) *Please fix all problems and resubmit a fixed version via the webform*
> >
> >
> > While apparently nothing should be done, at least according to some forum
> > post
> >
> https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer
> >
> > It would be nice to avoid this from the test side or the email side. It
> is
> > pretty confusing for developers who think that they have to act.
> >
> >
> > Best wishes.
> >
> > *Stefano *
> >
> >
> >
> > Stefano Mangiola | Postdoctoral fellow
> >
> > Papenfuss Laboratory
> >
> > The Walter Eliza Hall Institute of Medical Research
> >
> > +61 (0)466452544
> >
> >   [[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-pkg-devel] documentation of generic '['

[Berri, Stefano]

Hi. 

I am having problems with R CMD check around documentation of method "[". I am 
pretty sure I didn't have this WARNING when I used R-3.0.2. I have tried many 
things, but I am not sure how to fix it.


$  R CMD check encore
...
* using R version 3.2.3 (2015-12-10)
...
* checking for missing documentation entries ... WARNING
Undocumented S4 methods:
  generic '[' and siglist 'encore,ANY,ANY'
All user-level objects in a package (including S4 classes and methods)
should have documentation entries.
See chapter 'Writing R documentation files' in the 'Writing R
Extensions' manual.
...

Everything else is OK, there is an unrelated NOTE we are addressing

# R CODE ##

setMethod("[", "encore", function(x,i,j,drop){
... code here ...
})

# DOCUMENTATION #

\name{encore-class}
\Rdversion{0.1}
\docType{class}
\alias{encore}
\alias{subtraction-class}
\alias{encore-class}
\alias{dConn-class}

\alias{[,encore-method}

... description of the class, no explicit description of method "[" though 

##

I have tried various things searching around, but I seem to introduce new 
WARNINGS without removing the one I have.

I have read the "Writing R documentation files", but there is no special 
description of method "[", and I am struggling to understand what's wrong.

Thank you very much in advance

Stefano

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

Re: [R-pkg-devel] documentation of generic '['

[Berri, Stefano]

Thank you Joris and Duncan!

\alias{[, encore,ANY,ANY-method}

is all it is needed to fix the WARNING.

Now that it is fixed, I will try to follow your other suggestions and move the 
documentation outside the class documentation (probably with other accessors 
would make more sense) and add 

S4method{generic}{signature_list}(argument_list)

cheers

Stefano

From: jorism...@gmail.com [mailto:jorism...@gmail.com] On Behalf Of Joris Meys
Sent: 09 March 2016 13:15
To: Berri, Stefano
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] documentation of generic '['

Hi Stefano,
did you try moving the method to a separate file already? I've noticed that 
documentation of classes and methods in the same .Rd file isn't very 
straightforward. You need a \usage{} section to document the method, and that's 
likely to cause trouble when used in a class document. 

In any case, afaik you need a :
\S4method{generic}{signature_list}(argument_list)
in the usage section, and you have to refer to the method as 

\alias{[, encore,ANY,ANY-method}
See 
https://cran.r-project.org/doc/manuals/R-exts.html#Documenting-S4-classes-and-methods
Cheers
Joris
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Ensuring permanence and SHA consistency of released CRAN packages for validated software

[Borini, Stefano]

Hello,

Validated software needs to ensure consistency and reproducibility of its 
environment, potentially in years' time, when the audit comes. For this reason, 
we identify all SHA of the packages we download from CRAN to ensure that the 
package has not changed after the fact, something that may signal us that the 
package has been corrupted, or malicious code has been added after the fact, 
and also guarantees the auditors that the packages are indeed the correct ones 
as they were at the time of release.

Currently I am dealing with a package that I downloaded once in the past, 
MASS_7.3-54. This package used to have SHA256

b800ccd5b5c2709b1559cf5eab126e4935c4f8826cf7891253432bb6a056e821  
MASS_7.3-54.tar.gz

The current package has instead SHA:

eb644c0e94b447c46387aa22436ef5a43192960ee9cfd0df2940f4a4116179ae  
MASS_7.3-54.tar.gz

This triggers all sort of alarms. It is established poor practice to replace a 
package after the fact exact for these reasons. Once a package is released, it 
should remain immutable. Subsequent builds can be introduced with a different 
build number.

The change appears to be due to the fact that CRAN rebuilds packages 
occasionally, for reasons to me unknown. Diffing the old and the new 
MASS_7.3.54.tar.gz reveals the change to be due to this:

$ diff -Naur MASS_1/ MASS_2/
diff -Naur MASS_1/DESCRIPTION MASS_2/DESCRIPTION
--- MASS_1/DESCRIPTION  2021-05-03 10:03:00.0 +0100
+++ MASS_2/DESCRIPTION  2021-05-03 10:03:50.0 +0100
@@ -33,4 +33,4 @@
   David Firth [ctb]
 Maintainer: Brian Ripley 
 Repository: CRAN
-Date/Publication: 2021-05-03 09:03:00 UTC
+Date/Publication: 2021-05-03 09:03:50 UTC
diff -Naur MASS_1/MD5 MASS_2/MD5
--- MASS_1/MD5  2021-05-03 10:03:00.0 +0100
+++ MASS_2/MD5  2021-05-03 10:03:50.0 +0100
@@ -1,4 +1,4 @@
-560f72bfd93ac57532d2cf113078d2e7 *DESCRIPTION
+ecf84f78aac3c625898be45513307d79 *DESCRIPTION
 35aff05a505ecf7e81e0473767794ca9 *INDEX
 c7acdc0fa828f781a0a5586ab9d4fa1b *LICENCE.note
 0ac7b30ad35a4c19ea69d76a6a366b02 *NAMESPACE

Please prevent SHA changes of released packages on CRAN. Once a package is 
released, it should not be touched again.

--

Stefano Borini
Principal Analytical Tools Developer
AstraZeneca R&D BioPharmaceuticals | Data Science & AI | Early Biometrics & 
Statistical Innovation






AstraZeneca UK Limited is a company incorporated in England and Wales with 
registered number:03674842 and its registered office at 1 Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only 
and may contain confidential and privileged information. If they have come to 
you in error, you must not copy or show them to anyone; instead, please reply 
to this e-mail, highlighting the error to the sender and then immediately 
delete the message. For information about how AstraZeneca UK Limited and its 
affiliates may process information, personal data and monitor communications, 
please see our privacy notice at 
www.astrazeneca.com<https://www.astrazeneca.com>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Ensuring permanence and SHA consistency of released CRAN packages for validated software

[Borini, Stefano]

Then I argue that the model is wrong. Platforms change all the time, but 
package release and package testing are two separate operations. I also guess 
it hardly scales. If the number of packages were to increase, you can’t rebuild 
and retest them all every time a linux distribution changes something and you 
want to retest the whole lot against it.


--
Stefano Borini
Principal Analytical Tools Developer
AstraZeneca R&D BioPharmaceuticals | Data Science & AI | Early Biometrics & 
Statistical Innovation



From: Iñaki Ucar 
Date: Thursday, 17 March 2022 at 10:16
To: "Borini, Stefano" 
Cc: Dirk Eddelbuettel , Henrik Bengtsson 
, "r-package-devel@r-project.org" 

Subject: Re: [R-pkg-devel] Ensuring permanence and SHA consistency of released 
CRAN packages for validated software

On Thu, 17 Mar 2022 at 10:08, Borini, Stefano
 wrote:
>
> Sure, but why rebuild the package that has already been built?

Because the rest of the stack evolves and changes (compilers, shared
libraries, other packages), so you need to periodically (or, better
and more efficiently, each time a dependency changes) rebuild stuff to
check that it still works. Linux distributions have dedicated services
for this (see e.g. [1]).

[1] https://koschei.fedoraproject.org/<https://koschei.fedoraproject.org>

--
Iñaki Úcar



AstraZeneca UK Limited is a company incorporated in England and Wales with 
registered number:03674842 and its registered office at 1 Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only 
and may contain confidential and privileged information. If they have come to 
you in error, you must not copy or show them to anyone; instead, please reply 
to this e-mail, highlighting the error to the sender and then immediately 
delete the message. For information about how AstraZeneca UK Limited and its 
affiliates may process information, personal data and monitor communications, 
please see our privacy notice at 
www.astrazeneca.com<https://www.astrazeneca.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] Ensuring permanence and SHA consistency of released CRAN packages for validated software

[Borini, Stefano]

CRAN rebuilds binary packages because of (potential) changes in
build-time dependencies. ABI changes, in the loose sense of the term.
E.g. package A can call the shared library of another package B. If
the ABI of B changes, then you need to rebuild A.

AFAICT packages are rebuilt frequently and often. E.g. if you look at
the package time stamps of the package files at
https://cran.r-project.org/bin/windows/contrib/4.2/
 you see that many
(most?) of the binaries were (re)built yesterday.

Well, the binaries it’s a different story and needs its own solution. I am 
referring to the source packages, not the binary ones. So I suspect that when 
the binaries are rebuilt, the DESCRIPTION file in the source package is updated 
as well by the build system.
That’s what creates the issue.

Some time ago I suggested adding the Build field to the metadata, for
similar reasons. The Build field helps you decide if your package is
out of date or not, but a hash is obviously better, as you can also
use it to check the integrity of the package file.

One concern CRAN had with the Build field was that if
`update.packages()` used this field to decide if a package should be
updated, that would cause too many downloads.

I agree that it would be great to add the sha256 (or other) hash to
DESCRIPTION.

You can’t do that because then you would end up in a chicken egg situation 
where the sha of the tgz package depends on the content of the DESCRIPTION 
which would depend on the sha of the package.

Do you want me to study in more details on how it’s worked out in python? We 
could come up with a similar strategy, but I hardly doubt it will be 
implementable quickly and effortlessly.
Probably the easiest strategy is to have a gpg signature for each package, but 
it can get heavy for maintainers at CRAN, and it still does not really solve 
the problem if it’s automated. Whatever changes the source DESCRIPTION file, 
will have to repackage the source tar.gz, and then sign it anew.


AstraZeneca UK Limited is a company incorporated in England and Wales with 
registered number:03674842 and its registered office at 1 Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only 
and may contain confidential and privileged information. If they have come to 
you in error, you must not copy or show them to anyone; instead, please reply 
to this e-mail, highlighting the error to the sender and then immediately 
delete the message. For information about how AstraZeneca UK Limited and its 
affiliates may process information, personal data and monitor communications, 
please see our privacy notice at 
www.astrazeneca.com

[[alternative HTML version deleted]]

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

[R-pkg-devel] Compact pdf warning

[Stefano Renzetti]

Hi,

I receive the following warning when I check my package:

checking sizes of PDF files under ‘inst/doc’ ... WARNING
  ‘gs+qpdf’ made some significant size reductions:
     compacted ‘gwqs-vignette.pdf’ from 458Kb to 162Kb
  consider running tools::compactPDF(gs_quality = "ebook") on these files

For this warning I tried to add the option "--compact-vignettes=both" in the 
build source package R CMD build additional options but it did not work. When I 
use the tools::compactPDF(gs_quality = "ebook") command it is able to create 
the compacted pdf but then when I build the package then it rebuilds the 
vignette and the size is still the before one. Do you have any suggestion?

Thanks in advance,
Stefano

[[alternative HTML version deleted]]

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

[R-pkg-devel] Unable to reproduce reported problems. Docker image?

[Borini, Stefano]

I am currently trying to submit a package to CRAN, and I see no problems in 
running the test on my package on Linux ubuntu 18.04 and the latest compiled R.
Is there a docker image of the CRAN automatic build system so that one can try 
to reproduce the problem in house?

Thanks





AstraZeneca UK Limited is a company incorporated in England and Wales with 
registered number:03674842 and its registered office at 1 Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only 
and may contain confidential and privileged information. If they have come to 
you in error, you must not copy or show them to anyone; instead, please reply 
to this e-mail, highlighting the error to the sender and then immediately 
delete the message. For information about how AstraZeneca UK Limited and its 
affiliates may process information, personal data and monitor communications, 
please see our privacy notice at 
www.astrazeneca.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Unable to reproduce reported problems. Docker image?

[Borini, Stefano]

Thanks. What is the recommended strategy in this case? Keep submitting and 
patching until it passes?


On 30/01/2020, 22:48, "Dirk Eddelbuettel"  wrote:


On 30 January 2020 at 21:40, Borini, Stefano wrote:
| I am currently trying to submit a package to CRAN, and I see no problems 
in running the test on my package on Linux ubuntu 18.04 and the latest compiled 
R.
| Is there a docker image of the CRAN automatic build system so that one 
can try to reproduce the problem in house?

In short, no.

There are Docker containers provided by the Rocker Project, by RHub, and by
others, but none of these _exactly_ match the CRAN containers.  Closing this
gap has been discussed, alas time is short and limited so nuttin' to show.

Dirk

--

https://clicktime.symantec.com/39by3e5jiumtscrjhg8uNwd6H2?u=http%3A%2F%2Fdirk.eddelbuettel.com
 | @eddelbuettel | e...@debian.org





AstraZeneca UK Limited is a company incorporated in England and Wales with 
registered number:03674842 and its registered office at 1 Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only 
and may contain confidential and privileged information. If they have come to 
you in error, you must not copy or show them to anyone; instead, please reply 
to this e-mail, highlighting the error to the sender and then immediately 
delete the message. For information about how AstraZeneca UK Limited and its 
affiliates may process information, personal data and monitor communications, 
please see our privacy notice at 
www.astrazeneca.com<https://www.astrazeneca.com>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Unable to reproduce reported problems. Docker image?

[Borini, Stefano]

I think (but I am not sure) that I narrowed down the issue to a stochastic 
process that has no seed defined. Unfortunately it's not my package so I have 
to do mostly guesswork on this regard.
What has surprised me though, is that I managed to get exact same results on 
three different platforms (linux, mac, windows) and three different versions 
(3.4, 3.5.3, and development), but the only platform that shows the variation 
is the CRAN one. Only when I added a single throwaway sample() call I got the 
same behaviour on my machines.

Thank you for your help.


On 31/01/2020, 14:10, "Martin Morgan"  wrote:

it probably makes sense to more directly indicate what package is causing 
problems (e.g., sharing the location of a public repository of the source) and 
the nature of the error (cut-and-paste the check output here?). Likely this 
will lead both to insight into the problem being flagged by the builder, and 
the reason why you are not able to reproduce it.

Martin Morgan

On 1/31/20, 9:04 AM, "R-package-devel on behalf of Dirk Eddelbuettel" 
 wrote:


On 31 January 2020 at 09:11, Borini, Stefano wrote:
| Thanks. What is the recommended strategy in this case? Keep 
submitting and patching until it passes?

Standard debugging, and (as Uwe already said) win-builder for that OS, 
rhub
for others, and asking here, ...  Imperfect, but doable.

It would be so nice to have actual Docker containers to reproduce 
issues.
Maybe one day.

Dirk

--

https://clicktime.symantec.com/3LGnbPsU527tgDjdhmUzsay6H2?u=http%3A%2F%2Fdirk.eddelbuettel.com
 | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list

https://clicktime.symantec.com/3Pzw1p1VBawxJbHABzaUeBq6H2?u=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel






AstraZeneca UK Limited is a company incorporated in England and Wales with 
registered number:03674842 and its registered office at 1 Francis Crick Avenue, 
Cambridge Biomedical Campus, Cambridge, CB2 0AA.

This e-mail and its attachments are intended for the above named recipient only 
and may contain confidential and privileged information. If they have come to 
you in error, you must not copy or show them to anyone; instead, please reply 
to this e-mail, highlighting the error to the sender and then immediately 
delete the message. For information about how AstraZeneca UK Limited and its 
affiliates may process information, personal data and monitor communications, 
please see our privacy notice at 
www.astrazeneca.com<https://www.astrazeneca.com>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel