Re: [Rd] RTools40 Error - sh: line 1: gcc: command not found
Thanks. Not sure how I ended up on 40 instead of 42.
After deleting the 40 version and installing the 42 version, the 42
installer seemed to create path variables for 40. I just edited that
however and the jsonlite test worked.
I do think that it would be advisable to tell users to check the path and
explain what result is desired there. Many users would benefit from knowing
that they need R's executables and the RTools bin on their path and that
they can add them via the *user *environment variables, which saves them
from needing administrative permission (and is better anyway for system
maintenance).
However, it's less important now that I see that the installer handles it
for you.
Thank you again.
On Mon, Nov 28, 2022 at 3:54 PM Simon Urbanek
wrote:
> Gene,
>
> I believe you have the wrong page - the link you listed is for an old
> version of R (4.0-4.1) - the current one (for 4.2.x) is
>
> https://cran.r-project.org/bin/windows/Rtools/rtools42/rtools.html
>
> Cheers,
> Simon
>
>
> > On 29/11/2022, at 7:39 AM, Gene Leynes wrote:
> >
> > Hello,
> >
> > I installed git bash for windows, R, RStudio, and R Tools on a fresh
> > Windows 10 machine.
> >
> > I followed the directions for RTools:
> > https://cran.r-project.org/bin/windows/Rtools/rtools40.html
> >
> > I added RTools to my user path, but I was getting an error when
> > installing jsonlite from source (even though it could find "make"
> > correctly). So, I tried the .Renviron method, and that didn't work
> either.
> >
> > I was getting errors like this:
> >
> >> install.packages("jsonlite", type = "source")
> > --- Please select a CRAN mirror for use in this session ---
> > trying URL '
> https://cloud.r-project.org/src/contrib/jsonlite_1.8.3.tar.gz'
> > Content type 'application/x-gzip' length 1053099 bytes (1.0 MB)
> > downloaded 1.0 MB
> >
> >
> > * installing *source* package 'jsonlite' ...
> > ** package 'jsonlite' successfully unpacked and MD5 sums checked
> > ** using staged installation
> > ** libs
> > gcc -I"C:/Users/XXX/AppData/Local/Programs/R/R-42~1.2/include"
> > -DNDEBUG -Iyajl/api
> > -I"c:/rtools42/x86_64-w64-mingw32.static.posix/include"
> > -D__USE_MINGW_ANSI_STDIO -O2 -Wall -std=gnu99 -mfpmath=sse -msse2
> > -mstackrealign -c base64.c -o base64.o
> > sh: line 1: gcc: command not found
> > make: *** [C:/Users/ XXX
> > /AppData/Local/Programs/R/R-42~1.2/etc/x64/Makeconf:253:
> > base64.o] Error 127
> > ERROR: compilation failed for package 'jsonlite'
> > * removing
> > 'C:/Users/375492/AppData/Local/Programs/R/R-4.2.2/library/jsonlite'
> >
> >
> > The downloaded source packages are in
> >‘C:\Users\ XXX
> > \AppData\Local\Temp\RtmpeCLXit\downloaded_packages’
> > Warning message:
> > In install.packages("jsonlite", type = "source") :
> > installation of package ‘jsonlite’ had non-zero exit status
> >
> >
> > I can't reproduce this part, but at one point it said that gcc wasn't
> found
> > in C:\rtools40\mingw_64\bin (not sure where the underscore was, but it
> had
> > an underscore)
> >
> > I noticed that my folder is named C:\rtools40\mingw64\bin
> >
> > That gave me the idea to add C:\rtools40\mingw64\bin to my user path
> which
> > resolved the issues. Adding that to the path allowed me to compile from
> > source, etc. Fixed RStudio and the R GUI (whatever we call it now).
> >
> > TLDR: I think there's a bug in the installer or something that creating
> an
> > incompatible path name with an underscore, or the instructions are
> missing
> > the advice to add C:\rtools40\mingw{WIN}\bin to the path.
> >
> >
> >
> > Somewhat related:
> >
> > By the way, I think adding RTools to the user path is the superior option
> > for Windows users, and I would like to propose an edit to that
> > documentation.
> >
> > First, it will help avoid complications for users who may
> > experience different paths for ~ depending on network availability.
> >
> > Second, it is a more standard way to edit the path and helps users learn
> > what's going on with the path and makes R less of a mysterious "exception
> > to the rule". No other program uses ~/.Renviron to edit the path.
> >
> > Although it's worth mentioning the option to create ~/.Renviorn, it
> > shouldn't be the primary instruction.
> >
> > Would it be possible to create a pull request for those edits? I don't
> know
> > where that documentation is maintained.
> >
> >
> > Thank you, and I hope you all are doing well.
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RTools40 Error - sh: line 1: gcc: command not found
On 11/28/22 23:33, Gene Leynes wrote:
Thanks. Not sure how I ended up on 40 instead of 42.
After deleting the 40 version and installing the 42 version, the 42
installer seemed to create path variables for 40. I just edited that
however and the jsonlite test worked.
Rtools42 is not creating variables for Rtools40, so that shouldn't be
the cause.
You can have Rtools40 and Rtools42 both installed on the machine (if
needed, e.g. for older versions of R).
I do think that it would be advisable to tell users to check the path and
explain what result is desired there. Many users would benefit from knowing
that they need R's executables and the RTools bin on their path and that
they can add them via the *user *environment variables, which saves them
from needing administrative permission (and is better anyway for system
maintenance).
However, it's less important now that I see that the installer handles it
for you.
Right, the paths don't have to be set manually when using the defaults.
For other cases, please see
https://cran.r-project.org/bin/windows/base/howto-R-4.2.html
Best
Tomas
Thank you again.
On Mon, Nov 28, 2022 at 3:54 PM Simon Urbanek
wrote:
Gene,
I believe you have the wrong page - the link you listed is for an old
version of R (4.0-4.1) - the current one (for 4.2.x) is
https://cran.r-project.org/bin/windows/Rtools/rtools42/rtools.html
Cheers,
Simon
On 29/11/2022, at 7:39 AM, Gene Leynes wrote:
Hello,
I installed git bash for windows, R, RStudio, and R Tools on a fresh
Windows 10 machine.
I followed the directions for RTools:
https://cran.r-project.org/bin/windows/Rtools/rtools40.html
I added RTools to my user path, but I was getting an error when
installing jsonlite from source (even though it could find "make"
correctly). So, I tried the .Renviron method, and that didn't work
either.
I was getting errors like this:
install.packages("jsonlite", type = "source")
--- Please select a CRAN mirror for use in this session ---
trying URL '
https://cloud.r-project.org/src/contrib/jsonlite_1.8.3.tar.gz'
Content type 'application/x-gzip' length 1053099 bytes (1.0 MB)
downloaded 1.0 MB
* installing *source* package 'jsonlite' ...
** package 'jsonlite' successfully unpacked and MD5 sums checked
** using staged installation
** libs
gcc -I"C:/Users/XXX/AppData/Local/Programs/R/R-42~1.2/include"
-DNDEBUG -Iyajl/api
-I"c:/rtools42/x86_64-w64-mingw32.static.posix/include"
-D__USE_MINGW_ANSI_STDIO -O2 -Wall -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c base64.c -o base64.o
sh: line 1: gcc: command not found
make: *** [C:/Users/ XXX
/AppData/Local/Programs/R/R-42~1.2/etc/x64/Makeconf:253:
base64.o] Error 127
ERROR: compilation failed for package 'jsonlite'
* removing
'C:/Users/375492/AppData/Local/Programs/R/R-4.2.2/library/jsonlite'
The downloaded source packages are in
‘C:\Users\ XXX
\AppData\Local\Temp\RtmpeCLXit\downloaded_packages’
Warning message:
In install.packages("jsonlite", type = "source") :
installation of package ‘jsonlite’ had non-zero exit status
I can't reproduce this part, but at one point it said that gcc wasn't
found
in C:\rtools40\mingw_64\bin (not sure where the underscore was, but it
had
an underscore)
I noticed that my folder is named C:\rtools40\mingw64\bin
That gave me the idea to add C:\rtools40\mingw64\bin to my user path
which
resolved the issues. Adding that to the path allowed me to compile from
source, etc. Fixed RStudio and the R GUI (whatever we call it now).
TLDR: I think there's a bug in the installer or something that creating
an
incompatible path name with an underscore, or the instructions are
missing
the advice to add C:\rtools40\mingw{WIN}\bin to the path.
Somewhat related:
By the way, I think adding RTools to the user path is the superior option
for Windows users, and I would like to propose an edit to that
documentation.
First, it will help avoid complications for users who may
experience different paths for ~ depending on network availability.
Second, it is a more standard way to edit the path and helps users learn
what's going on with the path and makes R less of a mysterious "exception
to the rule". No other program uses ~/.Renviron to edit the path.
Although it's worth mentioning the option to create ~/.Renviorn, it
shouldn't be the primary instruction.
Would it be possible to create a pull request for those edits? I don't
know
where that documentation is maintained.
Thank you, and I hope you all are doing well.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
Re: [R-pkg-devel] Logical Inconsistency of check regarding URL?
Dear Michael, On Tue, 29 Nov 2022 08:19:40 +0100 "Dr. habil. Michael Thrun" wrote: > URL: https://www.deepbionics.org (moved to > https://mthrun.github.io/index) > From: DESCRIPTION > Status: 301 > Message: Moved Permanently > Please change http --> https, add trailing slashes, or follow moved > content as appropriate. " The "HTTPS and trailing slashes" part is a red herring. The idea is to only have URLs in your package that return HTTP code 200. The website https://www.deepbionics.org redirects to https://mthrun.github.io/index, which is, strictly speaking, against the letter of the rules [1]. Websites that redirect from http://... to https://... and from .../website/path to .../website/path/ (and the other way around) are a common cause of such redirects, which is why Uwe mentioned it (I think), but this isn't the reason for the redirection at https://www.deepbionics.org. I think you could make the argument that https://www.deepbionics.org is the canonical URL for the website and the way it _currently_ works (by returning a 301 redirect to https://mthrun.github.io/index) is an implementation detail that should be ignored, but I don't know whether CRAN reviewers would agree. I think it should be possible to set up your domain and GitHub Pages to serve mthrun.github.io at the address www.deepbionics.org without a redirection [2], but I've never tried it myself. > First, do we not communicate with CRAN anymore through the submission > procedure of the package? If not, which is the correct line of > communication in such a case? There was a case once when the reviewer was mistaken (they were in the process of heroically clearing out the "newbies" queue that almost reached 80 packages, aged 10 days and more, all by themselves, so a certain amount of fatigue was to be expected) and I was able to argue my way out of a rejection by replying to the reviewer. I think that the way to go is to either submit a package with requested changes and an incremented version or to reply-to-all and argue the case for the package as it is now. > Third, why can I have a CRAN package "DataVisualizations" with this > URL online, another one named "GeneralizedUmatrix" uploaded the same > day with the same URL, which both are OK, but the URL in > "DatabionicSwarm" is not? Has anything changed recently regarding the way your domain is set up? It really is strange that the check passed for one of the packages but not the other. > Fifth, why do we need https/TLS/SSL? I think you're right (see also: depriving an existing website of its certificate as a means of censorship), but the browser makers may end up destroying TLS-less workflow for us in a few years. Thankfully, it's not a requirement of CRAN to have only HTTPS links. I probably shouldn't continue this topic because the question of "how the Web should function" tends to result in pointlessly heated debates. -- Best regards, Ivan [1] https://cran.r-project.org/web/packages/URL_checks.html [2] https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Logical Inconsistency of check regarding URL?
Dear Michael, I second Ivan's suggestion to use a custom domain on your GitHub Pages website and I also want to add that this solves your certificate issue as a nice side-effect. GitHub will automatically create a certificate for you, for free, via Let's Encrypt: https://github.blog/2018-05-01-github-pages-custom-domains-https/ Best, Hugo On 29/11/2022 08:55, Ivan Krylov wrote: Dear Michael, On Tue, 29 Nov 2022 08:19:40 +0100 "Dr. habil. Michael Thrun" wrote: URL: https://www.deepbionics.org (moved to https://mthrun.github.io/index) From: DESCRIPTION Status: 301 Message: Moved Permanently Please change http --> https, add trailing slashes, or follow moved content as appropriate. " The "HTTPS and trailing slashes" part is a red herring. The idea is to only have URLs in your package that return HTTP code 200. The website https://www.deepbionics.org redirects to https://mthrun.github.io/index, which is, strictly speaking, against the letter of the rules [1]. Websites that redirect from http://... to https://... and from .../website/path to .../website/path/ (and the other way around) are a common cause of such redirects, which is why Uwe mentioned it (I think), but this isn't the reason for the redirection at https://www.deepbionics.org. I think you could make the argument that https://www.deepbionics.org is the canonical URL for the website and the way it _currently_ works (by returning a 301 redirect to https://mthrun.github.io/index) is an implementation detail that should be ignored, but I don't know whether CRAN reviewers would agree. I think it should be possible to set up your domain and GitHub Pages to serve mthrun.github.io at the address www.deepbionics.org without a redirection [2], but I've never tried it myself. First, do we not communicate with CRAN anymore through the submission procedure of the package? If not, which is the correct line of communication in such a case? There was a case once when the reviewer was mistaken (they were in the process of heroically clearing out the "newbies" queue that almost reached 80 packages, aged 10 days and more, all by themselves, so a certain amount of fatigue was to be expected) and I was able to argue my way out of a rejection by replying to the reviewer. I think that the way to go is to either submit a package with requested changes and an incremented version or to reply-to-all and argue the case for the package as it is now. Third, why can I have a CRAN package "DataVisualizations" with this URL online, another one named "GeneralizedUmatrix" uploaded the same day with the same URL, which both are OK, but the URL in "DatabionicSwarm" is not? Has anything changed recently regarding the way your domain is set up? It really is strange that the check passed for one of the packages but not the other. Fifth, why do we need https/TLS/SSL? I think you're right (see also: depriving an existing website of its certificate as a means of censorship), but the browser makers may end up destroying TLS-less workflow for us in a few years. Thankfully, it's not a requirement of CRAN to have only HTTPS links. I probably shouldn't continue this topic because the question of "how the Web should function" tends to result in pointlessly heated debates. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Two packages with the same name
Thanks, Dirk and Uwe, for your helpful replies. I have learned from this situation that there is some risk involved in depending on a package that is not available in CRAN or on Bioconductor. Peter On Mon, Nov 28, 2022 at 1:18 PM Uwe Ligges wrote: > > > On 28.11.2022 19:36, Dirk Eddelbuettel wrote: > > > > On 28 November 2022 at 12:15, Peter Carbonetto wrote: > > | I maintain the mashr R package ( > https://cran.r-project.org/package=mashr), > > | which has been on CRAN a little over 2 years. The mashr package > depends on > > | another package, flashr, which is available from an external repository > > | (via *Additional_repositories*). > > | > > | Very recently, we have found ourselves in the awkward situation that > there > > | are now two flashr packages: > > | > > | https://cran.r-project.org/package=flashr > > | > > | (mashr is listed as one of the reverse dependencies of this package, > which > > | is incorrect.) > > | > > | Does anyone have any suggestions for how to navigate this awkward > > | situation? The problem needs to be fixed by Dec 7 otherwise mashr will > be > > | taken off CRAN. On the other hand, the new "flashr" seems like a nice > > | package, and I don't see any reason why it shouldn't exist on CRAN. > > > > Yikes. My tendency would be to work with what is under your control and > have > > your 'flashr' package renamed in its 'additional repository'. Also keep > the > > existing one (for existing users), and new one (say, 'flashr2' or any > other > > name, maybe even 'flashr4mashr'), upload to the 'additional repository' > and > > then update 'mashr'. > > > > As far as CRAN is concerned, there is really only one 'flashr'. > > Indeed, and CRAN makes sure that a new package does not take a name from > CRAN nor BioC, which are what we call mainstream repositories. > In order to prevent what happened, choose a rather unique name - and > perhaps consider to submit that to CRAN, too. > > We see "flashr" and similar names are also used in other projects, so > one more point for a new name. > > Best, > Uwe Ligges > > > Hth, Dirk > > > [[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] LAPACK errors in r-devel only
Thank you so much Simon, I had completely missed this change in passing strings
to Fortran and the new approach which will be enforced from R 4.3.0. A very
interesting read and I think you're right -- making those changes is compiling
now on r-hub, so I've attempted a new CRAN submission and keeping fingers
crossed.
Also, my apologies for not linking to the sources ... I should have deferred
posting to the morning when I was more awake!
Many thanks,
Louis
From: Simon Urbanek
Sent: 29 November 2022 01:27
To: ASLETT, LOUIS J.M.
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] LAPACK errors in r-devel only
[EXTERNAL EMAIL]
Louis,
you didn't provide any details (please always post a link to the sources you're
talking about!), but I suspect you are missing character length arguments,
Lapack.h has:
F77_NAME(dgeevx)(const char* balanc, const char* jobvl, const char* jobvr,
const char* sense, const int* n, double* a, const int* lda,
double* wr, double* wi, double* vl, const int* ldvl,
double* vr, const int* ldvr, int* ilo, int* ihi,
double* scale, double* abnrm, double* rconde, double* rcondv,
double* work, const int* lwork, int* iwork, int* info
FCLEN FCLEN FCLEN FCLEN);
23 = without lengths, 27 = with lengths, so presumably the R in question is
compiled with USE_FC_LEN_T and thus your call is missing the corresponding
FCONE entries - see R-ext 6.6.1 Fortran character strings.
Cheers,
Simon
> On 29/11/2022, at 12:36 PM, ASLETT, LOUIS J.M.
> wrote:
>
> I submitted a package update to CRAN in the hopes of reinstating an archived
> package, {PhaseType}. The update is mostly to remove a dependency on another
> archived package, and to add registrations of C functions.
>
> Everything is fine on r-release, but on r-devel I have errors. I tested this
> with r-hub prior to submission, but wondered if there were issues there
> because the errors didn't make any sense, so I (perhaps wrongly) submitted to
> CRAN and the errors have been repeated but again *only* for r-devel.
>
> The full error log (so long as it lasts) is here:
> https://win-builder.r-project.org/incoming_pretest/PhaseType_0.2.0_20221124_233702/
>
> Essentially, the compile errors exclusively relate to LAPACK functions which
> should be completely stable. As far as I can tell (welcome any correction)
> the r-devel build is expecting a different number of arguments for these
> LAPACK functions than r-release, which honestly baffles me.
>
> For example, I note the error:
>
> #> PHT_MCMC_Aslett.c:180:157: error: too few arguments to function call,
> expected 27, have 23
> #> F77_CALL(dgeevx)(, , , , n, NULL, n, NULL, NULL,
> NULL, n, NULL, n, NULL, NULL, NULL, NULL, NULL, NULL, , , NULL,
> );
> 1721
>
> However, the standard LAPACK interface documentation for dgeevx (see eg
> https://netlib.org/lapack/explore-html/d9/d8e/group__double_g_eeigen_ga4e35e1d4e9b63ba9eef4ba8aff3debae.html
> ) shows that the 23 arguments I am passing is correct (and has been for
> years), not the 27 the r-devel build for some reason expects.
>
> Any help greatly appreciated. I've replied along these lines to CRAN
> rejection message, but opening this question to the list in the hope of
> assistance in understanding what's going on with r-devel on such a
> bog-standard LAPACK function, which must have been stable for over a decade.
>
> Thanks in anticipation!
>
> Louis
>
> __
> 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] Single page reference manual in html format
Hi Jonathan, I've done a first attempt at a package to generate one-page html reference manuals. The package is called 'postdoc' and you can read about it here: https://ropensci.org/blog/2022/11/29/postdoc-docs/ To get a quick impression, find example manuals for base-R packages here: https://r-universe.dev/manuals/ and many others on https://r-universe.dev (examples linked in the above blog post). I am interested to hear if this format works better for you than the PDF manual, and how we can further improve it. Jeroen On Sat, Apr 16, 2022 at 8:49 AM Jonathan Godfrey wrote: > > > Hello all, > > I rarely contribute to discussions on this list, but learn lots while I hang > about. I saw the first post in this thread and hoped that it would lead to a > strong positive response from people I've come to respect. > > The idea of removing pdf manuals is hugely attractive to my community. The > LaTeX driven pdf is as good for blind people today, as it was in the 20th > century. It isn't, full stop, end of story. The ability to incorporate > mathematical expressions in help pages has been awesome if done in HTML with > MathJax, but has made the prospect of reliance on a pdf even less attractive > than it was before. > > I'd really like to see someone justify the use of the single pdf manual with > a 2022 lens. What is its value to the community? And what is its cost? I'm > sure there was a need for the single pdf way back, but what is its real value > today? > > I accept that there are other reasons why a package needs CRAN to do some pdf > checking, including Sweave vignettes, but should every package have to play > pdf games because some do? I loved LaTeX (and Sweave) in the day, but while > those tools have stood still, R markdown and HTML have materially improved my > life. > > Surely it ought to be possible for a package maintainer to choose the pdf or > an HTML pathway. (?) It must surely be possible to accomplish sufficient > tests for quality of a package's documentation with an HTML destination as it > is in the current pdf manual process. To meet the CRAN standards, a single > HTML construct (one file or a collection of linked ones) is all that needs to > be put on the table. After all, there's only one pdf option on the table at > present and no one seems to have wanted to change that in the 15+ years I've > been using R. I don't see a full bells and whistles solution as necessary for > CRAN's needs; anyone who wants the fancy stuff can already do that with tools > like pkgdown anyway. > > As a package maintainer, I tire of the reminders that I don't have qpdf > installed. I don't use the tool for anything else so I won't bother to > install it. I know the pdf is not too big and don't need a tool to tell me. > I'd love to see a reduction in the plethora of tools and tests needed to get > a package thoroughly tested. I've been tempted to remove vignettes entirely > because it takes too long to repeatedly process them, but I did cull the > content dramatically and put most of it in an external location. If the > intention of the designed process was to make me and others use external > repositories instead of fully self-contained packages with all their > associated documentation, then perhaps we have success. > > > I'm now going to present some ideas that might seem unnecessary, but I spend > a lot of my time as an advocate for disabled people. This is not the first > time I've seen good people, albeit unwittingly ableist people, make life > harder for disabled people in their midst. I say "unwitting" not to suggest > foolishness of any kind, but blissful lack of awareness. Whether it is > intentional or not, and I honestly believe it isn't, the outcome is the same > in that marginalised people get marginalised. > > Asking package maintainers to go out and use another package is analogous to > asking one architect to employ another architect to design the wheelchair > ramps to the buildings they design, or worse, ask the wheelchair user to > bring their own ramps. > > The best tools that provide accessibility for disabled users are the ones > that no one knows they are using. R markdown to HTML creates extremely > readable content and most authors won't ever know that this is so. They don't > need to know, but my community benefits hugely. > > The HTML resulting from R markdown vignettes and other documentation and > papers almost meets the Web Content Accessibility Guidelines (WCAG) put out > by the WWW Consortium, whereas the LaTeX driven pdf always fails the > international standard for pdf. I can help improve the HTML, but the LaTeX > community has collectively failed to get their primary output files to an > acceptable standard, and I therefore cannot help. > > My advice to everyone involved in running CRAN, and I do solely from a > disabled person's perspective, is to make it hard to do the wrong thing, and > much easier to do the right
Re: [Bioc-devel] Builds suddenly failing
I can reproduce this locally using the most recent R and packages. It could be a dependency of your package changed or a change in base R itself. Please investigate and make sure you are using the latest version of R and all the latest versions of Bioconductor/R packages. BiocManager::install / BiocManager::valid can assist in making sure all dependent packages are up-to-date. Cheers, Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel on behalf of Garrett Jenkinson Sent: Tuesday, November 29, 2022 7:45 AM To: bioc-devel@r-project.org Subject: [Bioc-devel] Builds suddenly failing I recently (over past couple weeks) started receiving notices like the one below, despite not having pushed any changes to my package for quite some time (and all builds passing previously). Was there a change to the build system or requirements that could be causing this? Thank you, Garrett > On Nov 28, 2022, at 11:00 AM, bbs-nore...@bioconductor.org wrote: > > [This is an automatically generated email. Please don't reply.] > > Hi borealis maintainer, > > According to the Multiple platform build/check report for BioC 3.16, > the borealis package has the following problem(s): > > o ERROR for 'R CMD build' on nebbiolo2. See the details here: > > https://secure-web.cisco.com/1yYO2YUe1UiuNkFx0y64nsi6WQNfgKzqbJOCD-Fyq9tB_EQ2UIKmRoVx3OJB_9XnqK4BaciWccM7ppHEsACYoovKith-vZ8LQ3ZxIk6ytI-zRwqQzi5SBOU8TN9MivO3ffF0Lf2EGRixdhx_m9HdpqtXeCxei1t-THmtCztDyJb71d9o3WBJN9LIvWhygfiSouoWWKymcKae4Ea8AuCsD0VDhe_g8Od5_XDLkzIdQMmiCkdx4hnXuQeN0J1m4MB5L8wF1rX5NBs4U67NQVa8i2wT2qNomo1JZWdmpFbDTZtrA5VrT2aAlZJr0DmYzOLqD/https%3A%2F%2Fmaster.bioconductor.org%2FcheckResults%2F3.16%2Fbioc-LATEST%2Fborealis%2Fnebbiolo2-buildsrc.html > > Please take the time to address this by committing and pushing > changes to your package at git.bioconductor.org > > Notes: > > * This was the status of your package at the time this email was sent to you. >Given that the online report is updated daily (in normal conditions) you >could see something different when you visit the URL(s) above, especially > if >you do so several days after you received this email. > > * It is possible that the problems reported in this report are false > positives, >either because another package (from CRAN or Bioconductor) breaks your >package (if yours depends on it) or because of a Build System problem. >If this is the case, then you can ignore this email. > > * Please check the report again 24h after you've committed your changes to > the >package and make sure that all the problems have gone. > > * If you have questions about this report or need help with the >maintenance of your package, please use the Bioc-devel mailing list: > > > https://secure-web.cisco.com/1ZnkeN4Bfuhvu5fUtz5DlrFpIA2ciPrPY7zSyYhJaT5h3tPFLbExjeQJRJi3OT2pZb78IFlecW1BGiemtUWeB2KzvD1f67N5yS-66nSEHFB0rMFtB_gTlGNc2sRwlxqs_bopCm9XSCiXUxJkPIl0JLtaZzUpYiuU2KWTxr_Py7dj7KxlTM6OjFAiw1vt8dvt-MVMYSpFzlUKaUWngPW_eu1238KQhScmg-XirsCWpGnnl0d7zxMHYVKjd6fpaiA2UjxLYyruUxNLL9-tUUc23f1c6FoagLHmwoRtvhwmFlidsssv2ym3oTyjUI9ylKBkG/https%3A%2F%2Fbioconductor.org%2Fhelp%2Fmailing-list%2F > >(all package maintainers are requested to subscribe to this list) > > For immediate notification of package build status, please > subscribe to your package's RSS feed. Information is at: > > https://secure-web.cisco.com/1Fb-DxurFeFFKXfdhCwe_aHhRNecgBZPGJAy4Yjjgxe00eCNnOuo8564REQO4x1zDqCn-qwzNVdHhRt2G_rriLREKrzk7OA_SKSOxp9DTz1qFpPcvosXAz_rqCLtexPhl9JKsTDQGInBXSag8bXY6Jf4JIq3gJ68h8Oy60ychStonfauULvBEQiXvKbTwNRk7RCorhfPBDEF7mTU23oYwyGy38htVDJwVS66J6o7KHm0DF7BHZwi1J5qXvmoUOm1PRyaQyPFLv26nTjOOyc1DwHEGP3iEc8x0bhoZyTn_weXQw-sb0C9FBAcgco22SLe-/https%3A%2F%2Fbioconductor.org%2Fdevelopers%2Frss-feeds%2F > > Thanks for contributing to the Bioconductor project! > ___ Bioc-devel@r-project.org mailing list https://secure-web.cisco.com/1t1xLCGieDtTnlbd2aA995uaKO0xS4jC6Bg-VoYVLIhlZPZHjgs0sQ54cpIvoHThNfeERvp6NI586P27ngK_JR7ASRH5YESPDQA5Pk0uujaEpq3X2nZl2y0fbZE6G03F-hqq61CyJniNjnng-pLlH2eoxxXWhUftikI3AQLagzUt5IN1A8RB_SMrh_atYp14Ayxns5J8tqBJn_ZJJmtgfPHUTwB3tmNyZrMScGBAWjXqcq7S6KOrg3UIALmGsC6YRVKSUbZCih4w3JFJxH9Ly9PAFPj_qnWQGgHFuEi7DdArdLJd01d7vg8Hurm1nW6hx/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your
Re: [Bioc-devel] Give commit access to new author
I can assist with this but need additional information to create a Bioconductor Git Credentials account. What is her name? Does she have a personal github account that we could reuse username for the Bioconductor Git Credentials account. Cheers, Lori Shepherd - Kern Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 From: Bioc-devel on behalf of Lambda Moses Sent: Monday, November 28, 2022 6:27 PM To: bioc-devel@r-project.org Subject: [Bioc-devel] Give commit access to new author Hi, I would like to add a new author to the packages Voyager and SFEData, of which I'm an original author, and give her git commit access to the repos on Bioconductor. Her email is kayla...@caltech.edu Thanks, Lambda ___ Bioc-devel@r-project.org mailing list https://secure-web.cisco.com/1GyW4HtJk2KSUWjouUahTR4QcL8DiHJc1SQ46nwxlpsIcGAimVct0GR0tOv1TlxPlasoID3QyZAb_jimwgm1Mel1iP6ZlUOdboS9PY3X64jl_nNVdFnLgYQ1nr9BBRs7WzBWC64B04Z7vc7dLGy7g_5pXuuwJbPSP3HpIxy7cCgjGDBlnWgGs9vY2A36jCqB56BRdxo2peXw2N2-tCLQyq3sVW9kCjBXpMOkaJ63gUpHJEWT95HUvZRh4OXe4wEx1UAh3JRVQ7h7ZNrwW1_9UlEqZ4Trx7jT1ibi1qV9q8T38l3gUUewctGvKxYIQcc_NgLjIlHbDmzLPVATKAlZmrA/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Builds suddenly failing
I recently (over past couple weeks) started receiving notices like the one below, despite not having pushed any changes to my package for quite some time (and all builds passing previously). Was there a change to the build system or requirements that could be causing this? Thank you, Garrett > On Nov 28, 2022, at 11:00 AM, bbs-nore...@bioconductor.org wrote: > > [This is an automatically generated email. Please don't reply.] > > Hi borealis maintainer, > > According to the Multiple platform build/check report for BioC 3.16, > the borealis package has the following problem(s): > > o ERROR for 'R CMD build' on nebbiolo2. See the details here: > > https://master.bioconductor.org/checkResults/3.16/bioc-LATEST/borealis/nebbiolo2-buildsrc.html > > Please take the time to address this by committing and pushing > changes to your package at git.bioconductor.org > > Notes: > > * This was the status of your package at the time this email was sent to you. >Given that the online report is updated daily (in normal conditions) you >could see something different when you visit the URL(s) above, especially > if >you do so several days after you received this email. > > * It is possible that the problems reported in this report are false > positives, >either because another package (from CRAN or Bioconductor) breaks your >package (if yours depends on it) or because of a Build System problem. >If this is the case, then you can ignore this email. > > * Please check the report again 24h after you've committed your changes to > the >package and make sure that all the problems have gone. > > * If you have questions about this report or need help with the >maintenance of your package, please use the Bioc-devel mailing list: > > https://bioconductor.org/help/mailing-list/ > >(all package maintainers are requested to subscribe to this list) > > For immediate notification of package build status, please > subscribe to your package's RSS feed. Information is at: > > https://bioconductor.org/developers/rss-feeds/ > > Thanks for contributing to the Bioconductor project! > ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
