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

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

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] Package failing reverse dependency checks

[Lluís Revilla]

Hi David,

Dependency checks cannot be run on win /Mac builders as far as I know.
Some packages have more than 2000 packages depending on them.
It would be too much for the heavily used CRAN's machines.

Best,

Lluís

On Thu, 8 Feb 2024 at 13:52, David Hugh-Jones 
wrote:

> Thanks for this tip. Out of interest, is there a way to make win/Mac
> builder run revdep checks?
>
> Writing: wyclif.substack.com
> Book: www.wyclifsdust.com
>
>
> On Thu, 8 Feb 2024 at 10:26, Lluís Revilla 
> wrote:
>
>> Hi David,
>>
>> If you didn't increase the version number it could happen that the old
>> version of the package was used (as CRAN might not be aware that there is a
>> new version).
>> The CRAN repository policy says: "Increasing the version number at each
>> submission reduces confusion so is preferred even when a previous
>> submission was not accepted".
>> In addition, it is easier to track how smooth the submission process is
>> for maintainers/developers.
>>
>> I would recommend submitting again, changing the version number of the
>> package.
>> Checking on  win builders and macos builders CRAN provides is the closest
>> one, other approaches include rhub2.
>>
>> Best,
>>
>> Lluís
>>
>>
>>
>> On Thu, 8 Feb 2024 at 10:24, David Hugh-Jones 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to upload a new version of my "huxtable" package. It is
>>> currently failing reverse dependency checks for two packages (homnormal
>>> and
>>> RSStest). The relevant failures are below.
>>>
>>> I got this failure one time, and fixed the problem, which relates to
>>> mistakenly relying on the Suggested: knitr package (see here for the
>>> commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
>>> commit, reverse dependency checks for homnormal and RSStest pass on my
>>> machine, when testing either with revdepcheck::revdep_check or
>>> tools::check_packages_in_dir, and even when knitr is not installed. But,
>>> after I uploaded the new package to CRAN, the same failure recurred.
>>>
>>> My new release candidate had the same version number as the previous one
>>> (which had failed the revdep check, and therefore not been published on
>>> CRAN). Is it possible that CRAN just tested the old version again?
>>>
>>> If not, then can anyone suggest the best way to debug a revdep check on
>>> as
>>> close a setup to the CRAN machines as possible?
>>>
>>> Cheers,
>>> David
>>>
>>> Git tag for the last CRAN submission:
>>> https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
>>>
>>> Info from the CRAN email:
>>> --
>>> Debian: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
>>> >
>>> RSStest, homnormal
>>>
>>> Log dir: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
>>> >
>>> The files will be removed after roughly 7 days.
>>>
>>> Pretests:
>>> Windows: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
>>> >
>>> Debian: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
>>> >
>>> --
>>> Changes to worse in reverse depends:
>>>
>>> Package: homnormal
>>> Check: examples
>>> New result: ERROR
>>>   Running examples in ‘homnormal-Ex.R’ failed
>>>   The error most likely occurred in:
>>>
>>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>>   > ### Name: Brown_Forsythe
>>>   > ### Title: Brown-Forsythe Test for Homogeniety
>>>   > ### Aliases: Brown_Forsythe
>>>   >
>>>   > ### ** Examples
>>>   >
>>>   > data(FH_data)
>>>   >x1=FH_data$SurvivalTime
>>>   >x2=FH_data$HospitalNo
>>>   >Brown_Forsythe(x1,x2)
>>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>>   Calls: Brown_Forsythe ... loadNamespace -> withRestarts ->
>>> withOneRestart
>>> -> doWithOneRestart
>>>   Execution halted
>>>
>>> Package: RSStest
>>> Check: examples
>>>

Re: [R-pkg-devel] Package failing reverse dependency checks

[Lluís Revilla]

Hi David,

If you didn't increase the version number it could happen that the old
version of the package was used (as CRAN might not be aware that there is a
new version).
The CRAN repository policy says: "Increasing the version number at each
submission reduces confusion so is preferred even when a previous
submission was not accepted".
In addition, it is easier to track how smooth the submission process is for
maintainers/developers.

I would recommend submitting again, changing the version number of the
package.
Checking on  win builders and macos builders CRAN provides is the closest
one, other approaches include rhub2.

Best,

Lluís



On Thu, 8 Feb 2024 at 10:24, David Hugh-Jones 
wrote:

> Hi all,
>
> I'm trying to upload a new version of my "huxtable" package. It is
> currently failing reverse dependency checks for two packages (homnormal and
> RSStest). The relevant failures are below.
>
> I got this failure one time, and fixed the problem, which relates to
> mistakenly relying on the Suggested: knitr package (see here for the
> commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
> commit, reverse dependency checks for homnormal and RSStest pass on my
> machine, when testing either with revdepcheck::revdep_check or
> tools::check_packages_in_dir, and even when knitr is not installed. But,
> after I uploaded the new package to CRAN, the same failure recurred.
>
> My new release candidate had the same version number as the previous one
> (which had failed the revdep check, and therefore not been published on
> CRAN). Is it possible that CRAN just tested the old version again?
>
> If not, then can anyone suggest the best way to debug a revdep check on as
> close a setup to the CRAN machines as possible?
>
> Cheers,
> David
>
> Git tag for the last CRAN submission:
> https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
>
> Info from the CRAN email:
> --
> Debian: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
> >
> RSStest, homnormal
>
> Log dir: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
> >
> The files will be removed after roughly 7 days.
>
> Pretests:
> Windows: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
> >
> Debian: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
> >
> --
> Changes to worse in reverse depends:
>
> Package: homnormal
> Check: examples
> New result: ERROR
>   Running examples in ‘homnormal-Ex.R’ failed
>   The error most likely occurred in:
>
>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>   > ### Name: Brown_Forsythe
>   > ### Title: Brown-Forsythe Test for Homogeniety
>   > ### Aliases: Brown_Forsythe
>   >
>   > ### ** Examples
>   >
>   > data(FH_data)
>   >x1=FH_data$SurvivalTime
>   >x2=FH_data$HospitalNo
>   >Brown_Forsythe(x1,x2)
>   Error in loadNamespace(x) : there is no package called ‘knitr’
>   Calls: Brown_Forsythe ... loadNamespace -> withRestarts -> withOneRestart
> -> doWithOneRestart
>   Execution halted
>
> Package: RSStest
> Check: examples
> New result: ERROR
>   Running examples in ‘RSStest-Ex.R’ failed
>   The error most likely occurred in:
>
>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>   > ### Name: teststat_MRSS
>   > ### Title: Median Ranked Set Sampling Test
>   > ### Aliases: teststat_MRSS
>   >
>   > ### ** Examples
>   >
>   > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
>   > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
>   > teststat_MRSS(x1,x2,tn=1000)
>   Error in loadNamespace(x) : there is no package called ‘knitr’
>   Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
> -> doWithOneRestart
>   Execution halted
>
> [[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] new maintainer for CRAN package XML

[Lluís Revilla]

Dear Uwe and the CRAN team,

Many thanks for maintaining the package for so long (>10 years!).

I see the latest changes are in some internal C code related to
updating the libxml2 library.
In CRAN's experience, is this the highest time consuming task?

I have some questions about how the maintenance transfer will go:
Would someone from the CRAN team help/review the new maintainer for some time?
Or would there be a change in the "cre" role and that's all the
further involvement of the CRAN team with the package (besides the
excellent checks on CRAN)?

For anyone considering it, I analyzed a bit the situation of XML and
RCurl: https://llrs.dev/post/2023/05/03/cran-maintained-packages/
In short, with ~300 direct dependencies, and many highly used, across
CRAN and Bioconductor's packages.

Kind regards,

Lluís


On Mon, 22 Jan 2024 at 15:51, 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.
>
> So we are looking for a person volunteering to take over 'XML'.
> Please let us know if you are interested.
>
> For the CRAN team,
> Uwe Ligges
> __
> 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 for Resolving Submission Issues with openaistream Package

[Lluís Revilla]

Hi Li Gen,

This NOTE is part of the new checks on CRAN to comply with its policy.
The error message was introduced in c85587 (2023/11/22), when
incorporating this suggestion
https://bugs.r-project.org/show_bug.cgi?id=18611.
You can see the changes and checks in the browser here:
https://github.com/r-devel/r-svn/commit/c82305de4adc1a8ee01aaf3b4c84bd55721e77fc)
But the solution is what Ivan already wrote: simply provide a file
LICENSE that can be read with read.dcf with those two fields.

Best regards,

Lluís


On Mon, 22 Jan 2024 at 15:19, Ivan Krylov via R-package-devel
 wrote:
>
> Hello Li Gen and welcome to R-package-devel!
>
> В Mon, 22 Jan 2024 17:50:33 +0800
>  пишет:
>
> > The specific areas of concern are:License Information: There's a note
> > indicating that the license stub is an "invalid DCF". I've used 'MIT
> > + file LICENSE' as the licensing terms. I would appreciate guidance
> > on how to correctly format this section to meet the DCF standards.
>
> Leave just the following lines in the LICENSE file, as it currently is
> on CRAN [*]:
>
> YEAR: 2023
> COPYRIGHT HOLDER: openaistream authors
>
> Why would you like to change it? CRAN doesn't want packages to provide
> yet another copy of the MIT license inside the tarball. The text of the
> MIT license is always available in an R install at
> file.path(R.home('share'), 'licenses', 'MIT').
>
> If you need a copy of the MIT license inside your GitHub repository,
> store it elsewhere (e.g. LICENSE.md) and list it in .Rbuildignore [**].
>
> Since you composed your e-mail in HTML and left your mailer to generate
> a plain text equivalent, we only got the latter, somewhat mangled:
> https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010356.html
>
> Please compose your messages to R mailing lists in plain text.
>
> --
> Best regards,
> Ivan
>
> [*]
> https://cran.r-project.org/web/packages/openaistream/LICENSE
>
> [**]
> https://cran.r-project.org/doc/manuals/R-exts.html#Building-package-tarballs
>
> __
> 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] Status of adbcpostgresql

[Lluís Revilla]

Hi Dewey,

Currently there are several packages on a subfolder for human inspection.
I don't think you can do anything else: sending this email might help
drawing attention from your reviewer to your package.
There might be some issues in the package that you'll need to address, try
to find them in advance or prepare a reply for them.

Probably the reviewer is busy with other non-CRAN related things. Or maybe
the review fell between emails.
After a couple of weeks you could try again sending an email to the
reviewer.

Best,

Lluís

On Thu, 5 Oct 2023 at 03:39, Dewey Dunnington  wrote:

> Hi all,
>
> I submitted the first release of adbcpostgresql (an R repackaging of
> ADBC's Postgres driver) about a month ago and it has been pending human
> inspection (I think) since then. I did reply-all to the email once to
> inquire about status but haven't heard back. Where is the best place to
> direct communication about the status of the package? I am certainly
> happy to fix any problems that arise.
>
> Cheers,
>
> -dewey
>
> __
> 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] What to do when a package is archived from CRAN

[Lluís Revilla]

The reasons that CRAN has for this (from:
https://cran.r-project.org/src/contrib/PACKAGES.in) are:

X-CRAN-History: Archived on 2023-08-19 for policy violation.
  Downloading on installation from github.
  Unarchived on 2023-08-30.
X-CRAN-Comment: Archived on 2023-08-31 for policy violation.
  .
  Downloading on installation from github.

I see your file src/rust/Cargo.lock has some references to github.com
which is probably what has triggered this.
I'm sorry I cannot help further.

Good luck!


On Thu, 31 Aug 2023 at 14:54, Dirk Eddelbuettel  wrote:

>
> On 31 August 2023 at 07:32, SHIMA Tatsuya wrote:
> | I submitted prqlr 0.5.1 yesterday, which is almost identical to prqlr
> | 0.5.0, and prqlr is now available again on CRAN.
> | Thanks to the CRAN reviewers for their quick reaction.
>
> And it is gone again (per CRANberries). Never a dull moment with CRAN.
>
> 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
>

[[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 submissions no auto-processed message

[Lluís Revilla]

Hi,

Are you referring to your package formods?
I see it was released the same Friday 17 and it is already on CRAN.

If this is not the package, it might be on the backlog of packages
submitted to CRAN.
You can check the queue at:
https://r-hub.github.io/cransays/articles/dashboard.html

Best,

Lluís


On Sun, 27 Aug 2023 at 23:16, John Harrold  wrote:

> Howdy Folks,
>
> I submitted a package on Friday. I got the normal email where you have to
> click on the link to confirm. Then I got an email saying that the package
> was uploaded. Normally after that I get an email saying the package was
> auto-processed. That generally doesn't take very long (typically less than
> an hour). I wanted to know if there was something on the backend that was
> causing a delay, or if there was something wrong and I needed to resubmit
> it.
>
> Thank you,
> John
> :wq
>
> [[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] Missing ggPMX causing failure for nlmixr2rpt

[Lluís Revilla]

Dear John,

I think the problem is that the package ggPMX is suggested, but
nlmixr2rpt isn't prepared for when it isn't available.
In such cases, a package shouldn't fail the checks.

>From the CRAN policies https://cran.r-project.org/web/packages/policies.html :
"A package listed in ‘Suggests’ or ‘Enhances’ should be used
conditionally in examples or tests if it cannot straightforwardly be
installed on the major R platforms. (‘Writing R Extensions’ recommends
that they are always used conditionally.)"

Among other things in the file test-rptnlmixr.R you load several
suggested packages without checking if they are available.
You should only run those tests and examples that need those packages
if they are available.
Checking via:  if (requireNamespace("ggPMX", verbose = FALSE) could be enough

There's also an example that seems to be failing, I didn't understand
the reason behind it but it might be related.

Best,

Lluís


On Fri, 2 Jun 2023 at 02:49, John Harrold  wrote:
>
> Hello,
>
> I recently got a "Dear Maintainer" email from Brian Ripley. It was
> concerning the nlmixr2rpt package I maintain:
>
> https://cran.r-project.org/web/checks/check_results_nlmixr2rpt.html
>
> It looks like there is an error on r-release-linux-x86_64 that is causing
> it. If I'm reading that correctly there is a problem finding ggPMX on that
> flavor. If I look at the check results for ggPMX it seems to be building
> fine there:
>
> https://cran.r-project.org/web/checks/check_results_ggPMX.html
>
> Am I reading that correctly that ggPMX not being found is the cause of my
> issues? If that's the case and it seems to be present now, can I just wait
> and let CRAN machines find it? Or should I just resubmit with those pieces
> removed from the version I submit to CRAN?
>
> --
> Thank you,
> John
> :wq
>
> [[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] CRAN Vignette pdfs garbled in Firefox pdf viewer

[Lluís Revilla]

Hi,

I can't read any vignettes of gcplyr in Firefox 109.0.1 from a Windows 10.
But sorry, I don't have any solution.

On Thu, 9 Feb 2023 at 21:18, Duncan Murdoch 
wrote:

> On 09/02/2023 10:27 a.m., Mike Blazanin wrote:
> > Hi all, my package gcplyr has several vignettes which, from CRAN, appear
> > garbled when opened with Firefox's pdf viewer (
> > https://cran.r-project.org/web/packages/gcplyr/index.html).
> Specifically,
> > instead of regular characters, there are numerous black-outlined white
> > boxes with text inside like "EO 88" or "EO 55". This doesn't occur with
> the
> > pdf vignettes on Github (https://github.com/mikeblazanin/gcplyr/). This
> > also doesn't occur when CRAN pdfs are opened with Chrome's pdf viewer or
> > Microsoft Edge's pdf viewer, nor when files are downloaded from CRAN and
> > opened with a local pdf viewer.
>
> I don't see a problem in Firefox 109.0.1 on a Mac.  Maybe the "0.1" is a
> bug fix?  Or maybe I looked in the wrong place.  Could you be very
> specific, i.e. URL, page, line.
>
>
> Duncan Murdoch
>
>
> >
> > The issue was documented here:
> > https://github.com/mikeblazanin/gcplyr/issues/112
> >
> > Anyone have any suggestions for what could be causing this?
> >
> > Thanks!
> > Mike Blazanin
> >
> >   [[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
>

[[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 ‘wflo’ was removed from the CRAN repository.

[Lluís Revilla]

Hi,

I would still submit the package:
First I agree with Ben that the note is worth fixing (and easily enough you
just need to remove rgdal from your Description if it is not used.)
Second, and more important, because perhaps in the 9 months since the last
check changes in r-devel or quality checks might currently cause the
package to fail the checks.

The idea behind CRAN, and packages repositories like it (Bioconductor), is
that packages in them should work together.
Sometimes this makes it easier for developers to write more complex
packages but dependencies have their own cost such as this situation.
You can share your package via other methods but usually users install
packages from repositories.

Cheers,

Lluís


On Thu, 22 Sept 2022 at 22:25, Ben Bolker  wrote:

>* Automatic unarchiving *might* happen because someone on the CRAN
> team happens to read this thread, but you will improve your odds greatly
> by e-mailing c...@r-project.org with as polite a request as you can
> manage ...
>
>   * My guess is that nothing will happen until you resubmit (FWIW the
> NOTE definitely seems like something CRAN would object to, so you should
> fix it before resubmitting ...)
>
>good luck,
> Ben Bolker
>
> On 9/22/22 4:15 PM, Carsten Croonenbroeck wrote:
> > Hi Lluís,
> >
> > thanks for the clarification. And kudos to your detective flair. I’m
> serious about that, as I would never have found out about this chain of
> events.
> >
> > Well, there are no error or warnings to fix, so I think it would be best
> if someone from the CRAN team could “unarchive” wflo since there is no
> problem there and none of the events that were set in motion were due to
> any of my doings. Actually, I don’t really agree to have to resubmit, and
> my time for doing so is very limited. Maybe in the next few weeks or so.
> >
> > Best
> >
> > Carsten
> >
> >
> > Von: Lluís Revilla [mailto:lluis.revi...@gmail.com]
> > Gesendet: Donnerstag, 22. September 2022 15:33
> > An: Carsten Croonenbroeck
> > Cc: r-package-devel@r-project.org
> > Betreff: Re: [R-pkg-devel] Package ‘wflo’ was removed from the CRAN
> repository.
> >
> > Hi Carsten,
> >
> > This seems to be an unfortunate chain of events between different
> packages: RcppMLPACK -> emstreeR -> wflo
> >
> > Package RcppMLPACK was archived on 2021-12-20 as issues were not
> corrected despite reminders.
> > This resulted in the package emstreeR being archived on 2021-12-20 as
> requires archived package 'RcppMLPACK'.
> > Which also resulted in your package, wflo, being archived.
> > Later, emstreeR was unarchived on 2022-03-21 after a successful
> submission improving the dependencies (probably removing the dependency to
> RcppMLPACK).
> > You can see the source of this info on
> https://cran.r-project.org/src/contrib/PACKAGES.in
> >
> > About the emails, usually maintainers whose package depends on a package
> that is about to be removed receive an email with a date by which they
> should fix the problems.
> > But, as I am not part of the CRAN team I cannot check it.
> >
> > I would recommend preparing a new submission with all the errors and
> warnings fixed.
> > Note that I think the package will be checked as a new package.
> >
> > Best,
> >
> > Lluís
> >
> >
> >
> >
> >
> > On Thu, 22 Sept 2022 at 13:17, Carsten Croonenbroeck <
> carsten.croonenbro...@uni-rostock.de carsten.croonenbro...@uni-rostock.de>> wrote:
> > Hi,
> >
> > I was really, really, really surprised to learn today that my package
> “wflo” was removed from CRAN almost a year ago!
> >
> > Telling from the output at https://CRAN.R-project.org/package=wflo,
> this is due to my package being “Archived on 2021-12-20 as requires
> archived package 'emstreeR'.” However, emstreeR is in no way archived (see
> https://CRAN.R-project.org/package=emstreeR). Clicking “check results
> archive”, it says that there is only a note
> >
> > Result: NOTE
> >  Namespace in Imports field not imported from: ‘rgdal’
> >   All declared Imports should be used.
> >
> > which is indeed correct, I don’t use rgdal anymore. What now, remove the
> rgdal import and resubmit? How come I wasn’t informed, my E-Mail is running
> perfectly. Very puzzling…
> >
> > Best
> >
> > Carsten
> >
> >  [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org<mailto:R-package-devel@r-project.org>
> mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-de

Re: [R-pkg-devel] Package ‘wflo’ was removed from the CRAN repository.

[Lluís Revilla]

Hi Carsten,

This seems to be an unfortunate chain of events between different packages:
RcppMLPACK -> emstreeR -> wflo

Package RcppMLPACK was archived on 2021-12-20 as issues were not corrected
despite reminders.
This resulted in the package emstreeR being archived on 2021-12-20 as
requires archived package 'RcppMLPACK'.
Which also resulted in your package, wflo, being archived.
Later, emstreeR was unarchived on 2022-03-21 after a successful submission
improving the dependencies (probably removing the dependency to RcppMLPACK).
You can see the source of this info on
https://cran.r-project.org/src/contrib/PACKAGES.in

About the emails, usually maintainers whose package depends on a package
that is about to be removed receive an email with a date by which they
should fix the problems.
But, as I am not part of the CRAN team I cannot check it.

I would recommend preparing a new submission with all the errors and
warnings fixed.
Note that I think the package will be checked as a new package.

Best,

Lluís





On Thu, 22 Sept 2022 at 13:17, Carsten Croonenbroeck <
carsten.croonenbro...@uni-rostock.de> wrote:

> Hi,
>
> I was really, really, really surprised to learn today that my package
> “wflo” was removed from CRAN almost a year ago!
>
> Telling from the output at https://CRAN.R-project.org/package=wflo, this
> is due to my package being “Archived on 2021-12-20 as requires archived
> package 'emstreeR'.” However, emstreeR is in no way archived (see
> https://CRAN.R-project.org/package=emstreeR). Clicking “check results
> archive”, it says that there is only a note
>
> Result: NOTE
> Namespace in Imports field not imported from: ‘rgdal’
>  All declared Imports should be used.
>
> which is indeed correct, I don’t use rgdal anymore. What now, remove the
> rgdal import and resubmit? How come I wasn’t informed, my E-Mail is running
> perfectly. Very puzzling…
>
> Best
>
> Carsten
>
> [[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] Change package maintainer

[Lluís Revilla]

Hi,

I agree that the email handshake is the best approach (and very
reasonable to expect it).
I thought that maybe in cases like this there was a waiting period
and/or multiple attempts to contact the maintainer and someone on the
mailing list might have had some experience with the process.
When I'm ready to take over the package I will ask the CRAN team and
give them more details.

Many thanks to all.

Lluís Revilla

On Fri, 2 Jul 2021 at 08:38, Uwe Ligges  wrote:
>
>
>
> On 01.07.2021 23:52, Duncan Murdoch wrote:
> > On 01/07/2021 3:11 p.m., Dirk Eddelbuettel wrote:
> >>
> >> On 1 July 2021 at 20:00, Lluís Revilla wrote:
> >> | I have a question related to changing maintainers.
> >> | What happens when the old/current maintainer does not respond to
> >> | emails or other methods of contact?
> >> | Would the new maintainer need to wait until the package is removed
> >> | from CRAN to submit it again?
> >>
> >> Not speaking for CRAN here but my understanding always was that a full
> >> and
> >> complete 'email handshake' with both old and new maintainer was strongly
> >> preferred / the default simply to prevent misunderstandings or
> >> shenanigans.
> >
> > I'd agree in the normal case where the package is still active on CRAN.
> >
> > In the case where a package has unaddressed issues with no response to
> > CRAN from the maintainer, they'd probably be quite happy to have someone
> > volunteer to take over.
>
> ... and if in doubt, ask the CRAN team and give them details.
>
> Best,
> Uwe Ligges
>
>
> > Duncan Murdoch
> >
> > __
> > 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] Change package maintainer

[Lluís Revilla]

Thanks Uwe for answering,

I have a question related to changing maintainers.
What happens when the old/current maintainer does not respond to
emails or other methods of contact?
Would the new maintainer need to wait until the package is removed
from CRAN to submit it again?

Best,

Lluís

PS: Not sure if my related question should be in another thread or not.


On Thu, 1 Jul 2021 at 18:00, Uwe Ligges  wrote:
>
> Both ways are fine with us, but the auto confirmation request will be
> sent out in any case.
>
> Best,
> Uwe Ligges
>
>
> On 01.07.2021 17:57, rmendelss gmail wrote:
> > Hi Uwe:
> >
> > Is what you described the preferred way to change maintainers  (I have just 
> > taken over another package),  or would you prefer receiving an email from 
> > the old maintainer before the submission?
> >
> > Thanks,
> >
> > -Roy
> >
> >> On Jul 1, 2021, at 8:38 AM, Uwe Ligges  
> >> wrote:
> >>
> >>
> >>
> >> On 01.07.2021 16:10, Javier García Chamorro wrote:
> >>> Hi there, I have recently uploaded the first version of my R package to
> >>> CRAN. As it is part of my final degree project, I need to change the
> >>> maintainer to my supervisor, now that I have finished the project.
> >>> I changed in the DESCRIPTION file the proper data to do so, but when
> >>> receiving back the email from CRAN the only NOTE I have is this one:
> >>> * checking CRAN incoming feasibility ... NOTE
> >>> Maintainer: 'Fernando Carazo Developer '
> >>> New maintainer:
> >>>Fernando Carazo Developer 
> >>> Old maintainer(s):
> >>>Javier Garcia Developer 
> >>
> >> 1. Correct the name of the new maintainer whose family name is probably 
> >> not "Developer". Apparently nobody spotted this in your initial submission.
> >>
> >> 2. After successful submission to CRAN, the old maintainer will receive a 
> >> confirmation request which you have to respond to.
> >>
> >> Best,
> >> Uwe Ligges
> >>
> >>
> >>
> >>> What do I need to do here?
> >>> Thank you
> >>> Javier
> >>> [[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

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

[R-pkg-devel] CRAN submissions

[Lluís Revilla]

Hi all,

Some time ago, there was a question[1] about "how long is the average
waiting time when submitting a new package ("newbies") until you get a
manual reply or it's on CRAN, submitting an update with all OK before
it hits CRAN".

I have analyzed the data provided by cransays[2] (Many thanks!). You
can find it on this post https://llrs.dev/2021/01/cran-review/
Some key points:
 - Most submission happens in the first days of the week and towards
the middle of the month
 - Most of the submissions disappear from the CRAN queue in less than a day.
 - There's a new package submission to CRAN every hour.
 - It was impossible to know when there was a reply from CRAN, as no
information is openly available.
 - Not possible to know when a package is all OK before it hits CRAN
as some packages remain in the queue even after acceptance (perhaps
with metacran this could be answered).

Hope it's a useful guide. Thanks to the CRAN reviewers for their task,
Best,

Lluís


[1]: https://stat.ethz.ch/pipermail/r-package-devel/2020q4/006174.html
[2]: https://lockedata.github.io/cransays/articles/dashboard.html

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

Re: [R-pkg-devel] Error during automatic check for vignette re-building - The magick package is required to crop

[Lluís Revilla]

Dear Pablo,

Sometimes when building a vignette the lines reported are a bit off (I
usually check the code above and below those lines).
I could reproduce the error on R 4.0.1, the error is triggered on
lines 515-519 on the following code:

relationship_plot(qtl_file=out.qtls.filtered, x="Abbrev", y="Ref_ID",
cex=1,gap=2.5,degree = 60,
canvas.xlim = c(-5, 5),
canvas.ylim = c(-3, 3),
grid.col = color.grid)

Hope you can solve it.

Cheers,

Lluís


On Thu, 5 Nov 2020 at 22:00, Pablo Fonseca  wrote:
>
> Dear Lluís Revilla,
>
> Thank you very much for the comments and suggestions. I changed the vignette 
> format from the BiocStyle to a regular html. However, I am still getting an 
> error.  Now, the error is "Input vector too short" and it is related with the 
> same code chunk lines 465-506.
>
> I can't figure out a possible reason for this issue. Any comment or 
> suggestion will be very welcome.
>
> Kind regards.
>
>
> Pablo Augusto de Souza Fonseca, Ph.D.
> Postdoctoral Fellow at University of Guelph
> Centre for Genetic Improvement of Livestock
> E pfons...@uoguelph.ca
> W http://animalbiosciences.uoguelph.ca/abscpeople/pfonseca
> 
> From: Lluís Revilla 
> Sent: Thursday, November 5, 2020 11:38 AM
> To: Pablo Fonseca 
> Cc: Duncan Murdoch ; r-package-devel@r-project.org 
> 
> Subject: Re: [R-pkg-devel] Error during automatic check for vignette 
> re-building - The magick package is required to crop
>
> CAUTION: This email originated from outside of the University of Guelph. Do 
> not click links or open attachments unless you recognize the sender and know 
> the content is safe. If in doubt, forward suspicious emails to 
> ith...@uoguelph.ca
>
>
> Hi Pablo,
>
> "The magick package is required to crop"  is related to using
> BiocStyle for your vignette. Not sure what causes it, but I reported
> this error some time ago:
> https://github.com/Bioconductor/BiocStyle/issues/77.
> On related issues and on bioc-devel mailing list
> (https://stat.ethz.ch/pipermail/bioc-devel/2020-April/016656.html) it
> is mentioned to use knitr::opts_chunk$set(crop = NULL) to solve it.
> If the package is intended for CRAN I would recommend not using
> BiocStyle template, which would also solve this.
>
> Best,
>
> Lluís
>
> On Thu, 5 Nov 2020 at 17:28, Pablo Fonseca  wrote:
> >
> > Dear Duncan Murdoch,
> >
> > Thank you for the quickly reply. Yes, the package is on Github. Any comment 
> > or suggestion will be very welcome.
> >
> > https://github.com/pablobio/GALLO
> >
> > Kind regards.
> >
> > Pablo Augusto de Souza Fonseca, Ph.D.
> > Postdoctoral Fellow at University of Guelph
> > Centre for Genetic Improvement of Livestock
> > E pfons...@uoguelph.ca  <mailto:pfons...@uoguelph.ca>
> > W http://animalbiosciences.uoguelph.ca/abscpeople/pfonseca  
> > <http://animalbiosciences.uoguelph.ca/abscpeople/pfonseca>
> > 
> > From: Duncan Murdoch 
> > Sent: Thursday, November 5, 2020 11:22 AM
> > To: Pablo Fonseca ; r-package-devel@r-project.org 
> > 
> > Subject: Re: [R-pkg-devel] Error during automatic check for vignette 
> > re-building - The magick package is required to crop
> >
> > CAUTION: This email originated from outside of the University of Guelph. Do 
> > not click links or open attachments unless you recognize the sender and 
> > know the content is safe. If in doubt, forward suspicious emails to 
> > ith...@uoguelph.ca
> >
> >
> > On 05/11/2020 10:55 a.m., Pablo Fonseca wrote:
> > > Dear all,
> > >
> > > Currently I am trying to update my package (GALLO) with some small edits 
> > > in the code. However, the package is not passing in the automatic check. 
> > > I am getting only two warnings:
> > >
> > > The first one is a warning related with the maintainer email (my email in 
> > > the case), which is correct. I really think that this is not the cause of 
> > > the package failure during the automatic checking.
> >
> > The first one is actually about your version number:  you called it
> > version 1.0, but CRAN already has 1.0.  You need to increase the number.
> >
> >
> > >
> > > The second warning is a problem during the vignette rebuilding. The 
> > > warning is "The magick package is required to crop". In my first 
> > > submission I didn't experience this error. In the recent submissions for 
> > > updates, I included the magick package as a dependency of the package. 
> > > However, this did

Re: [R-pkg-devel] Error during automatic check for vignette re-building - The magick package is required to crop

[Lluís Revilla]

Hi Pablo,

"The magick package is required to crop"  is related to using
BiocStyle for your vignette. Not sure what causes it, but I reported
this error some time ago:
https://github.com/Bioconductor/BiocStyle/issues/77.
On related issues and on bioc-devel mailing list
(https://stat.ethz.ch/pipermail/bioc-devel/2020-April/016656.html) it
is mentioned to use knitr::opts_chunk$set(crop = NULL) to solve it.
If the package is intended for CRAN I would recommend not using
BiocStyle template, which would also solve this.

Best,

Lluís

On Thu, 5 Nov 2020 at 17:28, Pablo Fonseca  wrote:
>
> Dear Duncan Murdoch,
>
> Thank you for the quickly reply. Yes, the package is on Github. Any comment 
> or suggestion will be very welcome.
>
> https://github.com/pablobio/GALLO
>
> Kind regards.
>
> Pablo Augusto de Souza Fonseca, Ph.D.
> Postdoctoral Fellow at University of Guelph
> Centre for Genetic Improvement of Livestock
> E pfons...@uoguelph.ca  
> W http://animalbiosciences.uoguelph.ca/abscpeople/pfonseca  
> 
> 
> From: Duncan Murdoch 
> Sent: Thursday, November 5, 2020 11:22 AM
> To: Pablo Fonseca ; r-package-devel@r-project.org 
> 
> Subject: Re: [R-pkg-devel] Error during automatic check for vignette 
> re-building - The magick package is required to crop
>
> CAUTION: This email originated from outside of the University of Guelph. Do 
> not click links or open attachments unless you recognize the sender and know 
> the content is safe. If in doubt, forward suspicious emails to 
> ith...@uoguelph.ca
>
>
> On 05/11/2020 10:55 a.m., Pablo Fonseca wrote:
> > Dear all,
> >
> > Currently I am trying to update my package (GALLO) with some small edits in 
> > the code. However, the package is not passing in the automatic check. I am 
> > getting only two warnings:
> >
> > The first one is a warning related with the maintainer email (my email in 
> > the case), which is correct. I really think that this is not the cause of 
> > the package failure during the automatic checking.
>
> The first one is actually about your version number:  you called it
> version 1.0, but CRAN already has 1.0.  You need to increase the number.
>
>
> >
> > The second warning is a problem during the vignette rebuilding. The warning 
> > is "The magick package is required to crop". In my first submission I 
> > didn't experience this error. In the recent submissions for updates, I 
> > included the magick package as a dependency of the package. However, this 
> > didn't fixed the issue. Additionally, I can't reproduce the errors in my 
> > machines, even when running R CMD check --as-cran. The error seems to be 
> > related with the lines 465-495 from the vignette. I double checked the code 
> > and introduced some small changes (such as reducing the figure dimensions).
>
> I am not sure about this one; I'd need to look at the package to check.
> Is it on Github?
>
> Duncan Murdoch
>
> >
> > Have ever someone faced a similar issue? However, it seems ineffective. Is 
> > there any possibility to be a false negative?
> >
> > I am sending bellow the links for the check logs.
> >
> > package GALLO_1.0.tar.gz does not pass the incoming checks automatically, 
> > please see the following pre-tests:
> > Windows: 
> > 
> > Status: 2 WARNINGs
> > Debian: 
> > 
> > Status: 2 WARNINGs
> >
> > Last released version's CRAN status: ERROR: 1, WARN: 11
> > See: 
> >
> >
> > Kind regards.
> >
> >
> > Pablo Augusto de Souza Fonseca, Ph.D.
> > Postdoctoral Fellow at University of Guelph
> > Centre for Genetic Improvement of Livestock
> > E pfons...@uoguelph.ca  
> > W http://animalbiosciences.uoguelph.ca/abscpeople/pfonseca  
> > 
> >
> >[[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

Re: [R-pkg-devel] checking PDF version of manual without hyperrefs or index ... ERROR

[Lluís Revilla]

Hi Anthony,

I stumbled with the same issue for a package I submitted recently, the
problem seems to be that LaTex doesn't know how to map this unicode
character to a typesetting.

My unicode character was \u2229 and I tried several ways to avoid this warning.
On the vignette built with knitr I declared the unicode character the
following way:
%\DeclareUnicodeCharacter{2229}{$\cap$}
On the man pages I had to use a bit of code to print the right symbol:
\ifelse{latex}{\out{$\cup$}}{\ifelse{html}{\out{}}{}}.}

This way it passes the CRAN checks on all the machines and I didn't
get any comment from the reviewer.
In your case a similar changing the symbol might work, if there isn't
any symbol you'll probably need to map the ligature in latex:
tex.stackexchange.com/a/230140/178206.
Not sure how to include that map with the package tho.

Hope this helps,

Lluís

On Thu, 29 Oct 2020 at 15:35, Anthony Hammond  wrote:
>
> Hello,
> I'm attempting to upload a package to CRAN and although it passes the R CMD
> checks that I run, it doesn't pass the CRAN check and the response I get is
> pasted below. I've looked online and found numerous solutions; some made no
> sense to me & others didn't work.
> I tried downloading and putting upquote.sty and inconsolata.sty files into
> the latex folder. I also tried typing --no-manual in the project options
> under R CMD check options.
> Still the CRAN submission email response provided the below error.
> What can I do to make this go away and have my package accepted?
> It probably doesn't help that I know next to nothing about LaTeX.
> Incidentally I don't mind not having a pdf manual, so if there is a simple
> way to avoid the check by requesting not to have one, that'll do.
> Any assistance would be greatly appreciated.
>
> Kind Regards
> Anthony
>
> * checking PDF version of manual ... WARNING
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> ! Package inputenc Error: Unicode char fl (U+FB02)
> (inputenc)not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type  H   for immediate help.
> * checking PDF version of manual without hyperrefs or index ... ERROR
> * checking for detritus in the temp directory ... OK
> * DONE
> Status: 1 ERROR, 1 WARNING, 3 NOTEs
>
> [[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