Re: [Rd] Creating RPMs for Packages
On Wed, 2010-01-06 at 13:35 -0500, Max Kuhn wrote: > Before I try to write any code, does anyone see any issues with this > (or has it already been done)? Is this a ridiculous approach? You are for sure not alone in this effort to package R. A number of RPMs have already made their way into Fedora and tools have been developed to help this process. One of them is R2spec [1], which I have worked on. I would also point you to a 'fork' of R2spec [2] which aims at building RPM more than spec (reason why they did not merge). R2spec aims a helping to generate spec files as close as possible to the final one for inclusion in official Fedora/EPEL repositories. Allen S. Rout have made a nice job converting R2spec to generate RPM directly, solving some of the circular dependences issues. For the rest I believe Marc already point you to the right places. Best regards, Pierre [1] https://fedorahosted.org/r2spec [2] https://www.redhat.com/archives/fedora-r-devel-list/2009-September/msg00023.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Creating RPMs for Packages
On Jan 6, 2010, at 12:35 PM, Max Kuhn wrote: My company is trying to manage R installations across a number large SMP machines. We're thinking out the best way to manage the packages installs and updates. They would be happy if we could work out RPM's for package installations (traceable, easily facilitated with existing sw management tools). I don't know a lot and RPMs beyond how to use them, but it seems plausible to write R code to create the RPM package. If we need to update package X, which triggers and update of ancillary packages Y and Z, it should be possible to use available.packages() to figure out the dependencies, download the sources, write out the RPM headers and package things up. Before I try to write any code, does anyone see any issues with this (or has it already been done)? Is this a ridiculous approach? Thanks, Max Max, It would certainly be beneficial for you or someone at your shop to get intimately familiar with creating RPM packages for Fedora/RHEL if that is the way you want to go. There are various detail issues involved in creating RPMs and for R packages specifically. The following page from the Fedora wiki would likely serve as a starting point for creating and maintaining R related RPMs: https://fedoraproject.org/wiki/Packaging:R The Fedora and RHEL/EPEL folks (basically the same people) are providing standardized RPMs for selected CRAN packages and it would make sense from a consistency perspective, not to mention not re- inventing the wheel, to learn from their activity. The R package managers involved in maintaining the R related RPMs have their own e-mail list which you might find helpful, albeit the volume there is low: https://www.redhat.com/mailman/listinfo/fedora-r-devel-list and of course we have our own Fedora SIG: https://stat.ethz.ch/mailman/listinfo/r-sig-fedora HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating RPMs for Packages
My company is trying to manage R installations across a number large SMP machines. We're thinking out the best way to manage the packages installs and updates. They would be happy if we could work out RPM's for package installations (traceable, easily facilitated with existing sw management tools). I don't know a lot and RPMs beyond how to use them, but it seems plausible to write R code to create the RPM package. If we need to update package X, which triggers and update of ancillary packages Y and Z, it should be possible to use available.packages() to figure out the dependencies, download the sources, write out the RPM headers and package things up. Before I try to write any code, does anyone see any issues with this (or has it already been done)? Is this a ridiculous approach? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] wiki down?
Does anyone have an address for a maintainer, or know what's going on? cheers Ben Bolker b...@bolker-lap2:~$ ping wiki.r-project.org PING econum.umh.ac.be (193.190.194.5) 56(84) bytes of data. ^C --- econum.umh.ac.be ping statistics --- 8 packets transmitted, 0 received, 100% packet loss, time 6999ms b...@bolker-lap2:~$ traceroute wiki.r-project.org traceroute to wiki.r-project.org (193.190.194.5), 30 hops max, 40 byte packets 1 ctx-5500-n060.core.ufl.edu (128.227.60.1) 2.072 ms 2.182 ms 2.330 ms 2 128.227.111.233 (128.227.111.233) 0.393 ms 0.413 ms 0.535 ms 3 ctx36-nexus-msfc-1-v40-1.ns.ufl.edu (128.227.236.5) 0.427 ms 0.458 ms 0.459 ms 4 ctx36-ewan-msfc-1-v50-1.ns.ufl.edu (128.227.236.86) 1.212 ms 1.143 ms 1.111 ms 5 ssrb230a-ewan-msfc-1-v704-1.ns.ufl.edu (128.227.252.50) 0.960 ms 0.989 ms 0.966 ms 6 jax-flrcore-7609-1-te31-1805.net.flrnet.org (198.32.155.221) 6.594 ms 6.523 ms 6.582 ms 7 tlh-flrcore-7609-1-te33-1.net.flrnet.org (198.32.155.17) 9.804 ms 9.818 ms 9.871 ms 8 hous-te0501-v513.layer3.nlr.net (198.32.155.254) 25.790 ms 25.810 ms 25.717 ms 9 atla-hous-70.layer3.nlr.net (216.24.186.9) 50.786 ms 50.816 ms 50.706 ms 10 wash-atla-64.layer3.nlr.net (216.24.186.21) 64.592 ms 64.755 ms 64.966 ms 11 newy-wash-98.layer3.nlr.net (216.24.186.22) 70.267 ms 70.299 ms 70.251 ms 12 216.24.184.86 (216.24.184.86) 153.551 ms 153.544 ms 153.535 ms 13 belnet-gw.rt1.ams.nl.geant2.net (62.40.124.162) 156.964 ms 156.927 ms 156.883 ms 14 10ge.ar1.mon.belnet.net (193.191.17.154) 158.453 ms 158.415 ms 158.367 ms 15 umh-1.customer.mons.belnet.net (193.191.11.138) 158.589 ms 158.690 ms 158.649 ms 16 193.190.193.10 (193.190.193.10) 159.595 ms 160.831 ms 160.799 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -- Ben Bolker Associate professor, Biology Dep't, Univ. of Florida bol...@ufl.edu / people.biology.ufl.edu/bolker GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc signature.asc Description: OpenPGP digital signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] missing R-devel/po
> Petr Savicky writes: > When i unpack R-devel_2010-01-05.tar.bz2 and run ./configure on > two Linux machines, i get the error message > configure: creating ./config.status > config.status: creating Makeconf > config.status: creating Makefile > config.status: creating doc/Makefile > config.status: creating doc/html/Makefile > config.status: creating doc/manual/Makefile > config.status: creating etc/Makefile > config.status: creating etc/Makeconf > config.status: creating etc/Renviron > config.status: creating etc/ldpaths > config.status: creating m4/Makefile > config.status: error: cannot find input file: po/Makefile.in.in > For R-devel_2010-01-04.tar.bz2, ./configure runs fine. > The reason could be that R-devel_2010-01-05.tar.bz2 does not > contain the directory "R-devel/po". This directory is present in > R-devel_2010-01-04.tar.bz2 and contains the file "R-devel/po/Makefile.in.in". > I see the directory "R-devel/po" at https://svn.r-project.org/R/trunk/, > so the problem could be just temporary. A problem from a recent change causing make dist to fail in subdir tests (so subdir tests is empty and po is missing). We're working on a fix. Best -k > Petr Savicky. > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] missing R-devel/po
When i unpack R-devel_2010-01-05.tar.bz2 and run ./configure on two Linux machines, i get the error message configure: creating ./config.status config.status: creating Makeconf config.status: creating Makefile config.status: creating doc/Makefile config.status: creating doc/html/Makefile config.status: creating doc/manual/Makefile config.status: creating etc/Makefile config.status: creating etc/Makeconf config.status: creating etc/Renviron config.status: creating etc/ldpaths config.status: creating m4/Makefile config.status: error: cannot find input file: po/Makefile.in.in For R-devel_2010-01-04.tar.bz2, ./configure runs fine. The reason could be that R-devel_2010-01-05.tar.bz2 does not contain the directory "R-devel/po". This directory is present in R-devel_2010-01-04.tar.bz2 and contains the file "R-devel/po/Makefile.in.in". I see the directory "R-devel/po" at https://svn.r-project.org/R/trunk/, so the problem could be just temporary. Petr Savicky. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lapack problem on Linux fedora 11
I need your help to make R works on my linux box, runing fedora 11. Few things on the machine and steps I did: 1. uname -a shows: Linux bagvapp 2.6.29.4-167.fc11.i586 #1 SMP Wed May 27 17:14:37 EDT 2009 i686 athlon i386 GNU/Linux 2. it has a gcc (version 4.4) RedHat's build 3. the g77 comes with the box does not work (R's configure tells it could not compile simple fortran code); so I download and install a binary version of gfortran (version 4.5) and set the LD_LIBRARY_PATH. 4. download R-2.10.1; ./configure --with-readline=no --with-x=no (i.e., I did not use --with-blas or --with-lapack as the manuals indicated; the box does have its copy of blas.so and lapack.so under /usr/lib) 5. my test of lapack in R is to run: library(nlme); and then run the example from this package: fm1 <- nlme(height ~ SSasymp(age, Asym, R0, lrc), data = Loblolly, fixed = Asym + R0 + lrc ~ 1, random = Asym ~ 1, start = c(Asym = 103, R0 = -8.5, lrc = -3.3)) 6. here is the error: + + + + Error in chol.default((value + t(value))/2) : lapack routines cannot be loaded In addition: Warning message: In chol.default((value + t(value))/2) : unable to load shared library '/usr/local/lib/R/modules//lapack.so': /usr/local/lib/R/modules//lapack.so: cannot restore segment prot after reloc: Permission denied Other things I tried: *. remove the -O2 flag while compiling lapack *. "ln -s" this linux box's copy of lapack.so *. replace the lapack.so with the other .so created by R, namely libRlapack.so (why R creates two copies of the .so?) None of those work. Help please. Hongbin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64
dear prof brian : I saw the svn changes ,but i think src\xz\makefile.win maybe not correct at ifeq ($(strip $(WIN)),64) OBJECTS = $(SOURCES:.c=.o) crc32_x86.o crc64_x86.o else OBJECTS = $(SOURCES:.c=.o) crc32_fast.o crc64_fast.o endif should be ifeq ($(strip $(WIN)),32) OBJECTS = $(SOURCES:.c=.o) crc32_x86.o crc64_x86.o else OBJECTS = $(SOURCES:.c=.o) crc32_fast.o crc64_fast.o endif because gcc64 can't compile crc32_x86.s crc64_x86.s,but gcc 32 can , so gcc64 must compile the crc32_fast.c crc64_fast.c best wishs Gong Yu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64
I have successfully downloaded the files and looked at the source changes. I did that on Linux, and am now downloading on Vista64. I think I understand most of the changes, and will get back to you later if I have any questions. BTW, where in the world are you (so I can undersand what timezone you are in)? Brian Ripley On Wed, 6 Jan 2010, Gong Yu wrote: When I try to upload to your sever,filezilla report error ,so I upload to other place the source code and bin can download at: http://download.cos.name/incoming/r64-src-and-bin-for-win64.zip (attention: the source code may be contain error,you are welcome report bugs to me) the tool-chain can download at: http://download.cos.name/incoming/Rtools64.zip (attention: the gcc included in the tool-chain is a native gcc 4.5.0 for win64(20091231), I download from http://www.equation.com/servlet/equation.cmd?fa=fortran and it's free and GPLed,so we can use it ) the change file is 1. 3 manifest files in gnuwin32\front-end\*.manifest,which is have wrong arch 2. gnuwin32\fix\h\config64.h 3. graphappmain.c,rterm.c,rgui.c (main change) 4. makefile and mkrules in gunwin32, 5. rscript.c in src\unix 6. every c file in extra\xz\*.c that have a main function (just comment out or delete the main function) 7. change the R\share\make\var.mk,(comment out the tcltk) 8. may be more files, but I can't recall now,so if there have an error then you can tell me,i will try figure it out - Original Message From: Uwe Ligges To: Gong Yu Cc: Prof Brian Ripley ; r-wind...@r-project.org Sent: Wed, January 6, 2010 5:03:52 PM Subject: Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64 On 06.01.2010 10:02, Uwe Ligges wrote: On 06.01.2010 01:54, Gong Yu wrote: I will follow the GPL rule, upload the source code, but i can't make diff, because in my office's pc there is no svn and gnutools. Thanks. If you upload the sources and indicate which files you have changed, we can easily diff ourselves. I see you tried to upload, but the file came in empty. Best wishes, uwe Best wishes, Uwe - Original Message From: Prof Brian Ripley To: Uwe Ligges Cc: Gong Yu; r-wind...@r-project.org Sent: Tue, January 5, 2010 9:20:59 PM Subject: Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64 On Tue, 5 Jan 2010, Uwe Ligges wrote: Dear Yu, thank you very much for the informations and the files. I just allocated some matrices and it seems to works (and allocated up to 4GB for me - stopped due to an R internal limit, obviously). Anyway, it would be really helpful to get the sources - the binary does ot really help for making the 64-bit version (including daily patched and devel versions and all packages) available to the public. This would also allow to run the regression tests and apply some other checks. Can you use a portable archive format rather than .rar? I'll need to install some means of unpacking that (7zip?). R itself can produce a .tar.gz (or even .tar.zx) file. Please note (like my comment below about that 'mingw64' distribution) that you are not allowed by R's licence to distribute such a binary build without the modified sources you used. So we really do need the sources to keep this above board (and sending it to us is 'distribution'). Brian Ripley You can upload with anonymous access to ftp://win-builder.r-project.org/R-devel/ Thank you very much! Best wishes, Uwe On 05.01.2010 02:46, Gong Yu wrote: Dear Uwe Ligges 1. I use ftp://ftp.equation.com/gcc/gcc-4.5-20091231-64.exe + msys +perl, Aha, that is not the distribution from the mingw64 project. Is it a native Win64 toolchain? Where are the sources (which GPL requires to be made available in a non-proprietary format in parallel)? and the source code i used is R 2.11.0 devel(i not sure the exact svn version,but it is last month) 2. I not familiar with diff ,so I afraid I can't give you a patch,but alternative I can upload the source my changed or the whole source code. 3. mainly changed 3 manifest files in gnuwin32\front-end , config64.h graphappmain.c,rterm.c,rgui.c, makefile in gunwin32, rscript.c in src\unix 4. also changed some c files in xz dir,because mingw64 if you can provide a space I can first upload the R 64 bin file ,the tool-chain i used, then the whole R source (because there still some problems in the sources ,so it maybe a few day later) Best wishes, Gong Yu --- On Mon, 1/4/10, Uwe Ligges wrote: From: Uwe Ligges Subject: Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64 To: "Arm Gong" Cc: r-devel@r-project.org, r-wind...@r-project.org Date: Monday, January 4, 2010, 10:11 AM Dear Arm Gong, we are certianly very interested. How many files (and which) did you patch, which version of the different MinGW tools did you use? It would be nice if we would be able to build 64-bit versions of CRAN. Can you send the information (including required patches) in a mail
Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64
When I try to upload to your sever,filezilla report error ,so I upload to other place the source code and bin can download at: http://download.cos.name/incoming/r64-src-and-bin-for-win64.zip (attention: the source code may be contain error,you are welcome report bugs to me) the tool-chain can download at: http://download.cos.name/incoming/Rtools64.zip (attention: the gcc included in the tool-chain is a native gcc 4.5.0 for win64(20091231), I download from http://www.equation.com/servlet/equation.cmd?fa=fortran and it's free and GPLed,so we can use it ) the change file is 1. 3 manifest files in gnuwin32\front-end\*.manifest,which is have wrong arch 2. gnuwin32\fix\h\config64.h 3. graphappmain.c,rterm.c,rgui.c (main change) 4. makefile and mkrules in gunwin32, 5. rscript.c in src\unix 6. every c file in extra\xz\*.c that have a main function (just comment out or delete the main function) 7. change the R\share\make\var.mk,(comment out the tcltk) 8. may be more files, but I can't recall now,so if there have an error then you can tell me,i will try figure it out - Original Message From: Uwe Ligges To: Gong Yu Cc: Prof Brian Ripley ; r-wind...@r-project.org Sent: Wed, January 6, 2010 5:03:52 PM Subject: Re: [Rd] I have finished compiling of R 64 bit on 64 bit Windows use MINGW64 On 06.01.2010 10:02, Uwe Ligges wrote: > > > On 06.01.2010 01:54, Gong Yu wrote: >> I will follow the GPL rule, upload the source code, but i can't make >> diff, because in my office's pc there is no svn and gnutools. > > Thanks. If you upload the sources and indicate which files you have > changed, we can easily diff ourselves. I see you tried to upload, but the file came in empty. Best wishes, uwe > Best wishes, > Uwe > > >> - Original Message >> From: Prof Brian Ripley >> To: Uwe Ligges >> Cc: Gong Yu; r-wind...@r-project.org >> Sent: Tue, January 5, 2010 9:20:59 PM >> Subject: Re: [Rd] I have finished compiling of R 64 bit on 64 bit >> Windows use MINGW64 >> >> On Tue, 5 Jan 2010, Uwe Ligges wrote: >> >>> Dear Yu, >>> >>> thank you very much for the informations and the files. >>> I just allocated some matrices and it seems to works (and allocated >>> up to 4GB for me - stopped due to an R internal limit, obviously). >>> >>> Anyway, it would be really helpful to get the sources - the binary >>> does ot really help for making the 64-bit version (including daily >>> patched and devel versions and all packages) available to the public. >>> This would also allow to run the regression tests and apply some >>> other checks. >> >> Can you use a portable archive format rather than .rar? I'll need to >> install some means of unpacking that (7zip?). R itself can produce a >> .tar.gz (or even .tar.zx) file. >> >> Please note (like my comment below about that 'mingw64' distribution) >> that you are not allowed by R's licence to distribute such a binary >> build without the modified sources you used. So we really do need the >> sources to keep this above board (and sending it to us is >> 'distribution'). >> >> Brian Ripley >> >>> You can upload with anonymous access to >>> ftp://win-builder.r-project.org/R-devel/ >>> >>> Thank you very much! >>> >>> Best wishes, >>> Uwe >>> >>> >>> >>> On 05.01.2010 02:46, Gong Yu wrote: Dear Uwe Ligges 1. I use ftp://ftp.equation.com/gcc/gcc-4.5-20091231-64.exe + msys +perl, >> >> Aha, that is not the distribution from the mingw64 project. Is it a >> native Win64 toolchain? Where are the sources (which GPL requires to >> be made available in a non-proprietary format in parallel)? >> and the source code i used is R 2.11.0 devel(i not sure the exact svn version,but it is last month) 2. I not familiar with diff ,so I afraid I can't give you a patch,but alternative I can upload the source my changed or the whole source code. 3. mainly changed 3 manifest files in gnuwin32\front-end , config64.h graphappmain.c,rterm.c,rgui.c, makefile in gunwin32, rscript.c in src\unix 4. also changed some c files in xz dir,because mingw64 if you can provide a space I can first upload the R 64 bin file ,the tool-chain i used, then the whole R source (because there still some problems in the sources ,so it maybe a few day later) Best wishes, Gong Yu --- On Mon, 1/4/10, Uwe Ligges wrote: > From: Uwe Ligges > Subject: Re: [Rd] I have finished compiling of R 64 bit on 64 bit > Windows use MINGW64 > To: "Arm Gong" > Cc: r-devel@r-project.org, r-wind...@r-project.org > Date: Monday, January 4, 2010, 10:11 AM > Dear Arm Gong, > > we are certianly very interested. How many files (and > which) did you patch, which version of the different MinGW > tools did you use? > > It would be nice if we would be able to build 64-bit > versions of CRAN. > > Can you send the information (including r