I was about to send updated package to CRAN. Then I am asked to agree that I fixed following issues found in previous package (which was added to CRAN anyway).
But how to fix this? How to make package installable on r-oldrel-osx-x86_64
Google doesn't give any hints :-(
Related
I have troubles with installing the package fwildclusterboot. It says that it is no longer available in CRAN. Also didn't succeed even when I exploited it from the archive. I was searching for some new version but could not find it.
Can you please help me how to do it?
I am the author of fwildclusterboot.
Due to issues with a broken dependency I did not manage to fix on time, fwildclusterboot is temporarily not available on CRAN. The long story is that a dependencies' dependency failed a test, then the dependency was not fixed, therefore archived on CRAN, and I did not manage to a) drop the dependency on time and pass all CRAN notes within the given two-three week time limit. Now I am trying to bring the package back, but CRAN is not very responsive towards me.
In the meantime, you can download the package from R universe (a CRAN alternative, set up by rOpensci) by running install.packages('fwildclusterboot', repos ='https://s3alfisc.r-universe.dev'). I hope the package will be back on CRAN soon!
I am trying to use the allanvar package which is documented on this rdocumentation page and this rdrr.io cran page. When I attempt to load it I get the following
> install.packages("allanvar")
Error: package 'allanvar' is not available
Am I doing something wrong, or has it been yanked?
To see if a package has been archived, you can go to its CRAN page. In this case, it is https://cran.r-project.org/web/packages/allanvar , but it's the same url pattern for other packages. Just put the package name after the last forward slash.
You will see on this page that it has been archived since 2020. To get the last stable CRAN version (which passed all CRAN checks with R version 4.0.2), you can do:
devtools::install_version('allanvar', version = '1.1')
This package is archived. This could be due to some minuscule thing that would be resolved soon, see this.
In the meantime, I'd install this using the GitHub repo:
remotes::install_github("jhidalgocarrio/allanvar")
One of my R package DiallelAnalysisR was removed from the CRAN repository. Now I fixed the problem and want to resubmit it to CRAN. However, after submitted the package I got the following NOTE
CRAN teams' auto-check service
Flavor: r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
Maintainer: 'Muhammad Yaseen <myaseen208#gmail.com>'
Any hints to fix this NOTE. Thanks
You actually don't need to do anything. Just mention in cran_comments.md why the package got archived and that you have fixed the cause of that, and that's it.
You can ignore this NOTE.
I submitted a package to CRAN recently, which was a great achievement for me.
Within 48 hours, I found that the Windows binary didn't build correctly due to a mistake on my part. Using rhub, I corrected this and would like the corrected version on CRAN.
I've been reading through the policies:
https://cran.r-project.org/web/packages/policies.html
I upped the version of the package, and re-submitted last month. However, I never heard back from the CRAN volunteers.
What is the procedure for correcting a package with binary build failures? Am I misunderstanding how to correct the package with CRAN?
Any help appreciated
I have an R package that I successfully submitted to CRAN over a year ago. I am ready to submit an update, however I see in the package check results an error: Package suggested but not available for checking: ‘rgdal’
This R package passes checks with R CMD check --as-cran on macOS, winbuilder with R-devel and on ubuntu. But I don't understand why rgdal was not available for checking in that one instance, and I am trying to avoid this same error cropping up again.
A quick google search shows this same error showing up for quite a few R packages, always only for r-release-osx-x86_64.
Is this something I should be concerned with?
In the end, I was able to ignore this issue, and this was not a problem. The same error did not crop up with the submission of the package update.