[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