Re: [Bioc-devel] "Error: duplicate commits" when pushing FamAgg to Bioconductor git

Thanks Nitesh for your quick reply! > On 13 Feb 2018, at 16:47, Turaga, Nitesh > wrote: > > Hi, > > It seems that there are multiple levels of duplication on your repository. > > You seem to have issued the “merge” with not the current bioconductor devel >

Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

On 13 February 2018 at 22:07, Ralf Stubner wrote: > On 13.02.2018 05:49, Baptiste Auguie wrote: > > On 13 February 2018 at 01:05, Dirk Eddelbuettel > > wrote: > > Maybe we are setting a more global "no advanced lapack"

Re: [Bioc-devel] rsvg on mac

Hi Kevin, As Val said, some CRAN packages with native code won't compile on our Windows or Mac builders because of missing components, and rsvg is one of them. Please keep in mind that we already install many external components required for the compilation of Bioconductor packages. The process

Re: [R-pkg-devel] Solaris and ggplot2

Hi, Glancing at the R CMD check errors, available at: https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/RJafroc-00install.html) It seems like the issues relate to ambiguous calls to 'sqrt()'. This particular issue is discussed in R-exts, at:

Re: [R-pkg-devel] Solaris and ggplot2

This is probably because stringi does not compile on r-hub, and ggplot2 depends on stringi. This is a known and as of yet unsolved issue: https://github.com/gagolews/stringi/issues/275 Gabor On Tue, Feb 13, 2018 at 10:58 PM, Dev Chakraborty wrote: > My package RJafroc,

[R-pkg-devel] Solaris and ggplot2

My package RJafroc, which is currently on CRAN, passes all operating systems except solaris-x86-patched, and as a result has been flagged for removal. Using R-hub builder, I am unable to reproduce the log file because a required package, ggplot2, does not exist for Solaris. I found the following

Re: [Bioc-devel] rsvg on mac

Valerie, Ok, I understand the difference now. Would it be possible to install the system requirement for rsvg ( just on devel)? I'm trying to generate plots in either PNG or SVG with OpenBabel. For PNG, OpenBabel requires it's own Cario library be installed on the system (doesn't

Re: [Bioc-devel] Access to push to pacakges Polyester and Ballgown

Thanks Jack. I've added you to both packages. Before you have access, you'll need to fill out this form https://docs.google.com/forms/d/e/1FAIpQLSdlTbNjsQJDp0BA480vo4tNufs0ziNyNmexegNZgNieIovbAA/viewform Please use your github username on the form - we'll get your ssh keys from that

Re: [Bioc-devel] Access to push to pacakges Polyester and Ballgown

Yes we are adding him to both On Tue, Feb 13, 2018, 10:53 AM Jack Fu wrote: > Thanks for checking Valerie. My github id is jmf47. > > Thanks! > Jack > > On Feb 13, 2018, at 10:22 AM, Obenchain, Valerie < > valerie.obench...@roswellpark.org> wrote: > > Hi, > > Jack, It doesn't

Re: [Bioc-devel] "Error: duplicate commits" when pushing FamAgg to Bioconductor git

Hi, It seems that there are multiple levels of duplication on your repository. You seem to have issued the “merge” with not the current bioconductor devel but the (now deprecated) GitHub- bioconductor mirror, multiple times. Please correct me if this is not accurate. I’m wondering why the

Re: [Bioc-devel] Access to push to pacakges Polyester and Ballgown

Thanks for checking Valerie. My github id is jmf47. Thanks! Jack On Feb 13, 2018, at 10:22 AM, Obenchain, Valerie > wrote: Hi, Jack, It doesn't look like you currently have access to other Bioconductor packages - is

Re: [Bioc-devel] Access to push to pacakges Polyester and Ballgown

Hi, Jack, It doesn't look like you currently have access to other Bioconductor packages - is that correct? If you don't currently have access, I need to know your github username. Jeff, are we adding Jack to both polyester and ballgown? Valerie On 02/13/2018 02:57 AM, Jeff Leek wrote: HI

Re: [Bioc-devel] rsvg on mac

Hi, By default, the build system installs CRAN dependencies on the Mac and Windows builders with 'type=both': install.packages("mypackage", type="both") This means it first tries to install the binary and if that fails, it tries to install from source. Packages without native code or

Re: [Rd] R Compilation gets stuck on Windows 64

Set the location of atlas path in mkrules.local to what you need, then edit arc/extra/blas/makevars.win to read lopenblas_haswell-r0.2.20 instead of the two libraries there in the atlas section. I think I described this in my more recent instructions. Avi On Tue, Feb 13, 2018 at 8:18 AM Indrajit

Re: [Rd] R Compilation gets stuck on Windows 64

On Tue, Feb 13, 2018 at 2:18 PM, Indrajit Sen Gupta wrote: > In the file MkRules.local.in, I see the line: USE_ATLAS = NO which I believe > needs to be changed to YES. But how do I specify the BLAS file > libopenblas_haswell-r0.2.20.a and its location? I have never done

Re: [Rd] R Compilation gets stuck on Windows 64

In the file MkRules.local.in, I see the line: USE_ATLAS = NO which I believe needs to be changed to YES. But how do I specify the BLAS file *libopenblas_haswell-r0.2.20.a *and its location? Regards, Indrajit On Tue, Feb 13, 2018 at 6:41 PM, Indrajit Sen Gupta wrote: > I

Re: [Rd] R Compilation gets stuck on Windows 64

I was able to compile the R from the github by running build-r-devel.bat! Now need to see how to compile it with BLAS. Regard, Indrajit On Tue, Feb 13, 2018 at 5:45 PM, Jeroen Ooms wrote: > On Tue, Feb 13, 2018 at 12:22 PM, Indrajit Sen Gupta >

Re: [Rd] R Compilation gets stuck on Windows 64

On Tue, Feb 13, 2018 at 12:22 PM, Indrajit Sen Gupta wrote: > Hi Avraham, > > I tried with the patched version. The same error message. > > gcc -std=gnu99 -m64 -shared -s -mwindows -o R.dll R.def console.o dynload.o > editor.o embeddedR.o extra.o malloc.o opt.o pager.o

Re: [Rd] R Compilation gets stuck on Windows 64

Hi Avraham, I tried with the patched version. The same error message. gcc -std=gnu99 -m64 -shared -s -mwindows -o R.dll R.def console.o dynload.o editor.o embeddedR.o extra.o malloc.o opt.o pager.o preferences.o psignal.o rhome.o rt_complete.o rui.o run.o shext.o sys-win32.o system.o dos_wglob.o

Re: [Bioc-devel] Access to push to pacakges Polyester and Ballgown

HI Bioc Team If you could please add Jack that would be great! Jeff On Mon, Feb 12, 2018 at 7:53 AM Jack Fu wrote: > Hi Bioc team, > > I'm currently maintaining the packages Ballgown and polyester. However, > I haven't been able to access the new system since the change in

Re: [Rd] Fix minor typo in error message from grDevices

Fixed, thanks, Tomas On 02/12/2018 09:33 PM, John Blischak wrote: > Hi, > > I fixed a minor typo in an error message from grDevices. Please see > attached for a patch to revision 74246. > > Thanks, > > John > > > __ > R-devel@r-project.org mailing list

Re: [Rd] Setting the path to Rtools for package compilation on Windows

On Tue, Feb 13, 2018 at 7:45 AM, Peter Langfelder wrote: > Hi all, > > I'm trying to set up the Windows Rtools toolset for building packages > with compiled code. I installed for Windows R-3.4.3 from CRAN and > installed Rtools-3.4 in a custom location M:\R\R-3.4.3 and

Re: [R-pkg-devel] new package? - Sports data from transfermarkt.com using rvest

Dear Peter and Thierry, thank you for your answers. I indeed contacted transfermarkt.com and write this just to finish up this conversation. Here is part of their answer: "thank you for getting in touch with us. Basically our data is copyrighted under German law by Transfermarkt, so there is

Re: [Rd] Setting the path to Rtools for package compilation on Windows

Thanks for the report - this has been already reported as bug 17376, it is caused by scripts that build the Windows binaries and by now has been fixed in R-patched and R-devel snapshot builds. So as a solution that works now I would recommend using R-patched. Tomas On 02/13/2018 08:33 AM,

Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

On 13.02.2018 05:49, Baptiste Auguie wrote: > On 13 February 2018 at 01:05, Dirk Eddelbuettel > wrote: > Maybe we are setting a more global "no advanced lapack" for Windows that > assures success when we assume that the other system will always >