Any feedback? any at all?

[Allen S. Rout]

Hi, folks. 

I've now got my script in such a form that I can generate, build, and
check most of the 'broad' dependency tree for ggplot2.  There are
several package build errors which I haven't started running down; I'm
not sure if they're relevant to my case.

Do any of you have any interest in this?  I was thinking it might help
accellerate new R packages' introduction to e.g. EPEL, but my sense
now is that you'd much rather hand-craft every one.  If our goals are
just skew, I'm fine with that.

I've put nearly a work week into this over the last few months, and am
very near the end of what I need for my local concerns.  I can happily
put a bit more time to address things you-all want done, if your
perspective is something like "We could use this, if he'd just [x, y,
z]".  Getting stuff accepted 'upstream' is worthwhile in my work
environment.

But if you're never going to be interested in the mass maintenance of
these packages, I'll just stop bothering you.



- Allen S. Rout

[Jack Tanner]

This seems like it's going to be extremely useful when I get back to working on
ggplot2. Thanks for your hard work. Unfortunately, that project just got punted down the
priority list for me, so I can't really offer any constructive feedback right now.

----------------------------------------
>  To: fedora-r-devel-list(a)redhat.com
>  From: asr(a)ufl.edu
>  Date: Wed, 23 Sep 2009 15:04:45 -0400
>  Subject: [Fedora-r-devel-list] Any feedback? any at all?
>
>
>  Hi, folks.
>
>  I've now got my script in such a form that I can generate, build, and
>  check most of the 'broad' dependency tree for ggplot2. There are
>  several package build errors which I haven't started running down; I'm
>  not sure if they're relevant to my case.
>
>  Do any of you have any interest in this? I was thinking it might help
>  accellerate new R packages' introduction to e.g. EPEL, but my sense
>  now is that you'd much rather hand-craft every one. If our goals are
>  just skew, I'm fine with that.
>
>  I've put nearly a work week into this over the last few months, and am
>  very near the end of what I need for my local concerns. I can happily
>  put a bit more time to address things you-all want done, if your
>  perspective is something like "We could use this, if he'd just [x, y,
>  z]". Getting stuff accepted 'upstream' is worthwhile in my work
>  environment.
>
>  But if you're never going to be interested in the mass maintenance of
>  these packages, I'll just stop bothering you.
>
>
>
>  - Allen S. Rout
>
>  _______________________________________________
>  Fedora-r-devel-list mailing list
>  Fedora-r-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-r-devel-list 
 		 	   		  
_________________________________________________________________
Lauren found her dream laptop. Find the PC that’s right for you.
http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290

[Allen S. Rout]

Jack Tanner <ihok-PkbjNfxxIARBDgjK7y7TUQ(a)public.gmane.org&gt; writes:

>  This seems like it's going to be extremely useful when I get back
> to
>  working on ggplot2. Thanks for your hard work. Unfortunately, that
>  project just got punted down the priority list for me, so I can't
>  really offer any constructive feedback right now. 

OK, sounds like I should just get my undergarments unwadded, and wait
for someone else to get a Round Tuit.


- Allen S. Rout

[Tom Moertel]

Allen S. Rout wrote:
>  I've now got my script in such a form that I can generate, build,
> and
>  check most of the 'broad' dependency tree for ggplot2. 
I am interested in seeing your script.  It sounds like it embodies a lot 
of knowledge about building a bunch of R packages, and that knowledge is 
  valuable.  I'd hope we can make some use of it.  :-)

Cheers,
Tom

[Allen S. Rout]

Tom Moertel <tom-RKvYLT2W2Q9BDgjK7y7TUQ(a)public.gmane.org&gt; writes:

>  I am interested in seeing your script.  It sounds like it embodies a
>  lot of knowledge about building a bunch of R packages, and that
>  knowledge is valuable.  I'd hope we can make some use of it.  :-) 
http://nersp.osg.ufl.edu/~asr/media/R2spec-2.6.2-asr.src.rpm

It depends now on python-cheetah (available from EPEL).

Updated instructions: 

---- 

for me to get the dependencies to build and install all (most) of
ggplot2's broad depgraph, I must:

yum install openmpi openmpi-devel openmpi-libs unixODBC-devel pvm tcl tcl-devel
perl-DateManip  perl-Date-Calc perl-version

and then install from EPEL:

environment-modules-3.2.6-4.el5.x86_64.rpm
mpich2-1.1.1-1.el5.x86_64.rpm
perl-IO-stringy-2.110-5.el5.noarch.rpm
perl-Jcode-2.06-6.el5.noarch.rpm
perl-OLE-Storage_Lite-0.14-9.el5.noarch.rpm
perl-Parse-RecDescent-1.96-1.el5.noarch.rpm
perl-Spreadsheet-WriteExcel-2.18-1.el5.noarch.rpm
perl-Unicode-Map-0.112-12.el5.x86_64.rpm

and then install from the graphviz people: 

graphviz-2.24.0-1.el5.x86_64.rpm
graphviz-devel-2.24.0-1.el5.x86_64.rpm


After installing the r2spec and the sysdeps, I made a temp directory,
/var/tmp/Rbuild.  I've got every script running happily from '.'; so
there's no specialness about the tempdir any more.

There, I ran (as root): [...]

I heard the 'prefer not running as root' from earlier: since step N
below is to install all these packages, is that really practical?  In
any case, the below can be run as a normal user, but the install steps
below can't.

# clear; R2spec  -n "Allen S. Rout" -e
&quot;asr-hnhdhkBXzx8(a)public.gmane.org&quot;  -c   --force  --suggests  --verbose 
--package  ggplot2


This downloaded the CRAN-like lists of packages, downloaded source
tarballs, and built (and copied) the specfiles and source.  

It also generated a few dot files, including the broad and narrow
dependency graphs for the requested package.

It also generates a 'buildorderlist'; a path through the depgraph such
that each package is attempted only after its dependencies are
processed.

Then I stripped out the packages I knew would not complete their RPM
build (mentioned below)

# mv buildorderlist buildorderlist.orig

# egrep -v
"R-Rmpi|R-rsprng|R-multcomp|R-flexmix|R-RandomFields|R-MCMCpack|R-tcltk2"
buildorderlist.orig > buildorderlist

Then I ran

 /usr/lib/python2.4/site-packages/r2spec/buildfromlist.sh

Is it evil for me to have put the script in there?  This is certainly
not general-purpose; putting it in the default bin would be silly.

This will build and install all of the RPMs in the broad graph. ... If
the individual builds work.

This script uses '.'  or environment variable 'RBUILDLOG' as a tempdir
extensively; it drops a build log and an install log for every package
addressed.  That way when things eventually bust you can see where
they went wrong.

Then I ran

 /usr/lib/python2.4/site-packages/r2spec/checkfromlist.sh

which runs 'R CMD check' on every package, again logging, and
summarizing success or failure in 'checkresults'.

The check step took about 5.5 hours for me.


----

I still fail to build (and haven't investigated much yet):

tcltk2:  Fails to install: need tclsh8.3, not 8.4 ? 

multcomp: requires Survival >= 2.35.7 ? ...

flexmix: dep on multcomp

R-RandomFields, R-MCMCpack: uncaught debug files in the build tree.

MPI, sprng

----




- Allen S. Rout

[Tom Callaway]

On 09/23/2009 03:04 PM, Allen S. Rout wrote:
>  Do any of you have any interest in this?  I was thinking it might
> help
>  accellerate new R packages' introduction to e.g. EPEL, but my sense
>  now is that you'd much rather hand-craft every one.  If our goals are
>  just skew, I'm fine with that. 
This is very interesting, please keep at it!

I think that there is no need to hand-craft every R package, but that
each R spec file needs to be:

* Sanity checked, and adjusted as necessary
* Actively maintained

I don't want to simply run any tool, generate a bunch of spec files, get
them into Fedora/EPEL, and then let them stagnate because one person
owns all of CRAN. :)

With that said, a tool that can automate any portion of the process is
very useful.

~spot

[Allen S. Rout]

"Tom \"spot\" Callaway"
<tcallawa-H+wXaHxf7aLQT0dZR+AlfA(a)public.gmane.org&gt; writes:

>  I think that there is no need to hand-craft every R package, but
> that
>  each R spec file needs to be:
>
>  * Sanity checked, and adjusted as necessary
>  * Actively maintained 
>  I don't want to simply run any tool, generate a bunch of spec
> files,
>  get them into Fedora/EPEL, and then let them stagnate because one
>  person owns all of CRAN. :) 
Keen; can you refine those statements?

I might be able to address 'actively maintained' by analogy to the
debian folks' efforts on this.  They regularly run basically an update
which detects package availability changes, and builds the new ones.
So, a "reasonable" time after a new package appears on CRAN, it
appears in the apt repo Dirk's maintaining.  That's clearly one
component of active maintenance; do you have more off the top of your
head?

As for 'sanity checked', I don't know what that means.  I'd like to
pretend that any package for which R CMD check passes successfully has
been sanity checked, but I know that to be a skewed persepctive. :) If
you can give me criteria, I can start working to implement them.



- Allen S. Rout