[pkg-bioc] what's up?

Egon Willighagen e.willighagen@science.ru.nl
Thu, 17 Mar 2005 10:47:34 +0100


On Thursday 17 March 2005 04:00 am, Dirk Eddelbuettel wrote:
> On 16 March 2005 at 13:14, Egon Willighagen wrote:
> | On Tuesday 15 March 2005 03:04 pm, Egon Willighagen wrote:
> | > I'm back from vacation, and started up creating amd64 debs for CRAN
> | > packages again. You might have seen the commits to Alioth...
> | >
> | > After 276+ build debs, I found that most actually compile...
> |
> | Done. 448 debs build for CRAN with the script in CVS (v1.9).
>
> Good work!
>
> http://cran.r-project.org/src/contrib/checkSummary.html now shows 504, but
> we don't of course need the r-recommended packages, or the ones already
> packaged.

I've added a section for packages in Debian. Should we skip creating *all* 
packages in Debian, or still try to get them to build with the new script?

Anyway, I've now set up a section in the script for those which fail and which 
are already in Debian:

## packages which are already in Debian, and which fails with the current 
script.
my @alreadyindebian = (
  "its",        ## in Debian as r-cran-its
  "rsprng",     ##              r-cran-rsprng
);


> | The can't-build set is not that large:
> |
> | my @cannotbuild = ("genetics",   ## depends on 'gdata' which is not on
> | CRAN
>
> Maybe it is in BioC?

Have to check. What's the status of the bioc2deb.pl script?

> |                    "its",        ## fails with: Error in
> | loadNamespace(name) : There is no package called 'its'
>
> Sort-of a non-issue as this is maintained inside Debian by me. I guess the
> loadNamespace thing is an upstream buglet which I never pushed that hard.
>
> What this trips up, though, is that my incarnation of the script did not
> attempt to build what was already available according to dpkg/apt. As I
> have r-cran-its installed, it never tried to build its here.
>
> So I guess we need a finer breakdown of what to build, or not.

Added section for stuff in Debian already...

> |                    "LDheatmap",  ## depends on genetics which cannot be
> | build "mimR",
> |                    "r.matlab",   ## problems defining the dependency...
> | it complains about the '.' in the name
>
> Ok, that would be a bug. Can you try to fix that?

I've added a file TODO to CVS.

> |                    "RmSQL", "ROracle",
> |                    "RSQLite",    ## has some Windows libs that trip
> | lintian up "RScaLAPACK", ## need to sort -dev packages out "rsprng",    
> | ## need to figure out why this fails
>
> Also available in Debian as r-cran-rsprng. So as above for its.

Marked as such in CVS.

> |                    "RNetCDF",    ## doesn't find netcdf in /usr
>
> I can't remember how I patched that, but I could look it up. I think the
> configure in rnetcdf needs some help.
>
> |                    "SciViews",   ## depends on tcltk but is not on CRAN
>
> Errr, tcltk ships with r-base-core!!  But I think it needs some tcltk extra
> we may not have. I've lost track.

:) Marked in TODO.

> |                    "seao",       ## fails with Lintian warning: W: seao
> | source: maintainer-upload-has-incorrect-version-number 0.2.1-0.r2d.1; W:
> | seao source: binary-nmu-debian-revision-in-source 0.2.1-0.r2d.1
> |                    "seao.gui",   ## depends on seao
> |                    "spdep",      ## fails with: Error in
> | .DESC[["Package"]] : subscript out of bounds
> |                    "survey",     ## fails with: Error in
> | open.connection(con, "rb") : unable to open connection
> |                    "udunits",    ## dep=udunits not in Debian
>
> I have a local package of udunits and -dev here which I could send you. I
> am a little unsure if we can redistribute this. NCAR has odd copyrights.

Marked in TODO as a 'ask debian-legal'.

> |                    "uroot",      ## depends on tcltk but is not on CRAN
>
> Wrong, see above.

In TODO too.

> |                    "IDPmisc",    ## fails with: Error in
> | loadNamespace(name) : There is no package called 'IDPmisc'
> |                    ## BioC: can't do annaffy as we lack GO and KEGG data
> | pkgs "annaffy",
> |                    ## the next list of packages is mentioned in CRAN's
> | Description subdir
> |                    ## but the tar.gz is not on CRAN. Dates for last test
> | are behind package name
> |                    "gmp",        ## 2005-02-21
> |                    "boa",        ## 2005-02-21
> | );
> |
> | my @cannotbuildamd64 = ("rpvm",        ## fails
> | with: /usr/bin/ld:
> | /usr/lib/gcc-lib/x86_64-linux/3.3.5/../../../../lib64/libgpvm3.a(pvmgsu_c
> |ore.o): relocation R_X86_64_32 can not be used when making a shared
> | object; recompile with -fPIC
> |                         "rgl",         ## fails with:
> | usr/bin/ld: /usr/X11R6/lib/libGL.a(glapi.o): relocation R_X86_64_32 can
> | not be used when making a shared object; recompile with -fPIC
> | );
> |
> | I've not looked into these problems.
>
> It's a known Debian bug, and I had a lengthy argument with its maintainer
> who refuses to fix this. It's broken upstream, but simply needs a better
> Makefile just like the one Kai, Elijah and I produced for SPRNG when I
> needed SPRNG for rsprng and R's SNOW.
>
> But it shows that our needs-to-build / cannot-build info needs another
> per-architecture dimension.

Marked in the TODO.

> | Ok, what remains to be done before actual setting up a repository?
> | - bugs db on Alioth?
>
> I'm not too concerned about that so I'll let Matt venture into that. We
> could start by having a repository and not yet announce it widely. A BTS
> can wait, in my book.

We can just use the TODO.

> | - caching of the ChangeLog's
>
> As flat files?  More funky?  Do you want to prototype something?

Flat files... What I need to figure out is:

- where in cran2deb.pl the ChangeLog is created
- add detection of a cached ChangeLog there
- detect wether it's a debian -(n+1) release or a new upstream release
- have his append to the cache

> | For the rest, it seems that the script is doing quite a good job!
>
> Yes.
>
> | Some minor issues:
> |
> | 1. the descriptions has too many '.'s... e.g.:
> |
> | Description: GNU R package "R Based Genetic Algorithm"
> |  R based genetic algorithm for binary and floating pointchromosomes.
> |  .
> |  Author(s): Egon Willighagen <e.willighagen@science.ru.nl>
> |  Date: 2005-03-15
> |  .
>
> That is the best I could do in a quick job with Perl. Better Perl wizardry
> welcome.  It;s difficult, though, as the DESCRIPTION format it not enforced
> by CRAN.  What is done here is done via a smart Perl formatting heuristic.
> I think we'd waste out time trying to better that.

I'll see if I have make a simple patch to at least remove the spurious periods 
on empty lines. (Should not be that difficult...)

> One day we may have DESCRIPTION stored in a db anyway ...
>
> | 2. Maintainer: Dirk Eddelbuettel <edd@debian.org>
> |
> | Which should probably now say something like:
> |
> | Maintainer: Alioth collborative packaging for CRAN and Bioconductor
> | <pkg-bioc-devel@lists.alioth.debian.org>
>
> Yes, of course.  The name is good, but a bit long (and with a typo).  Maybe
>
>  Maintainer: Debian CRAN/BioC packaging group
> <pkg-bioc-devel@lists.alioth.debian.org>
>
> or
>
>  Maintainer: CRAN/BioC packagers <pkg-bioc-devel@lists.alioth.debian.org>
>
> which fits one line.

Added the last to CVS.

> Good work, Egon. Thanks for pushing the cart that much further along.
>
> April 15 is the deadline for DSC2005 submission if we wanted to jointly
> talk about this.  Would make for a nice deadline (August) for actually
> having something working :)   Any takers?

What's DSC2005? A google showed a conference on transport simulation... ??

Egon