Discussion:
All free packages of CRAN an BioConductor built for Debian and Ubuntu
(too old to reply)
Steffen Möller
2011-02-17 12:06:08 UTC
Permalink
Dear all,

the Debian Med Sprint on Bioinformatics saw a phone call from Christian's mobile across the Atlantic and there was no way back
after that: we have run the cran2deb [1] routines from Charles and Dirk on all of CRAN and Bioconductor for the amd64 platform.
This means that every package was built with pbuilder, the most reliable confirmation to know the dependencies set right. The
process has been completed for Debian and is still running for Ubuntu. We are now keen to get feedback from the list to learn if
the packages are up to your all's expectations and/or what there should be done to them before announcing their availability to
the world at large.

The architecture-independent packages from Debian should be bit-identical to what a rebuild on Ubuntu produces. We will test that
hypothesis over the upcoming days. The packages are produced for both 64-bit Debian squeeze and Bio-Linux6/Ubuntu 10.04 LTS. For
the binary packages however we _do_ expect differences when there are different sonames for libraries in the individual
distributions. But again, for most packages there should be no difference between our two worlds. It would be nice if some R
professionals on Ubuntu could confirm that what is installable from the Debian-produced repository is also working nicely for them.

The repositories of CRAN and BioConcuctor are at
Debian: http://master.dermacloud.uni-luebeck.de/cran2deb/rep/
Ubuntu: http://bioinformatics.rri.sari.ac.uk/cran2deb/rep/

With best regards and many many thanks to all who were involved

Tony and Steffen

[1] https://r-forge.r-project.org/projects/cran2deb/
Andreas Tille
2011-02-17 15:38:29 UTC
Permalink
Hi,
Post by Steffen Möller
The repositories of CRAN and BioConcuctor are at
Debian: http://master.dermacloud.uni-luebeck.de/cran2deb/rep/
Ubuntu: http://bioinformatics.rri.sari.ac.uk/cran2deb/rep/
Congratulations!

Besides the availability in this repository: Is there any sense in moving
some key packages inside official Debian?

Moreover we should probably generate reflect the BioConductor packages
in our bio task to some extend. These packages should at least be
installable if you include the URL above in your sources.list via the
suggests of a metapackage.

Kind regards and thanks for your effort

Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@an3as.eu
Steffen Möller
2011-02-17 18:29:23 UTC
Permalink
Post by Andreas Tille
Hi,
Post by Steffen Möller
The repositories of CRAN and BioConcuctor are at
Debian: http://master.dermacloud.uni-luebeck.de/cran2deb/rep/
Ubuntu: http://bioinformatics.rri.sari.ac.uk/cran2deb/rep/
Congratulations!
Besides the availability in this repository: Is there any sense in moving
some key packages inside official Debian?
One is tempted to think so for some BioConductor packages for instance. But I
would be sufficiently busy for now to work with the automated variant.
Post by Andreas Tille
Moreover we should probably generate reflect the BioConductor packages
in our bio task to some extend. These packages should at least be
installable if you include the URL above in your sources.list via the
suggests of a metapackage.
I was thinking about a bioconductor source package that comes with some binaries
that depend on various related subgroups of the archive. Those packages could
add the URL to /etc/apt/sources.d, learn the gpg key of the archive and then
run apt-get update ... would be a bit strange, no?
Post by Andreas Tille
Kind regards and thanks for your effort
Thank you for your support, let's learn if there are problems of any sort

best,

Steffen
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmx.de
Andreas Tille
2011-02-17 21:39:41 UTC
Permalink
Post by Steffen Möller
One is tempted to think so for some BioConductor packages for instance. But I
would be sufficiently busy for now to work with the automated variant.
I ddn't say that it is your job. Somebody else could just make a list.
Usually packaging R-packages is a 15min job so for filling some time you
wait for another package to build ...
Any volunteer to create a list of most wanted BioConductor packages?
Post by Steffen Möller
Post by Andreas Tille
Moreover we should probably generate reflect the BioConductor packages
in our bio task to some extend. These packages should at least be
installable if you include the URL above in your sources.list via the
suggests of a metapackage.
I was thinking about a bioconductor source package that comes with some binaries
that depend on various related subgroups of the archive. Those packages could
add the URL to /etc/apt/sources.d, learn the gpg key of the archive and then
run apt-get update ... would be a bit strange, no?
I'm afraid I do not fully understand what you mean.

Kind regards

Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@an3as.eu
Charles Plessy
2011-02-18 02:35:28 UTC
Permalink
Post by Steffen Möller
I was thinking about a bioconductor source package that comes with some binaries
that depend on various related subgroups of the archive. Those packages could
add the URL to /etc/apt/sources.d, learn the gpg key of the archive and then
run apt-get update ... would be a bit strange, no?
Hi Steffen,

One possible starting point :

http://git.debian.org/?p=debian-med/r-bioconductor-biobase.git

For the addition to /etc/apt/sources.d, I think I recall that something similar
was discussed on debian-***@l.d.o or debian-***@l.d.o recently, and the
feeling was strongly negative, see http://lists.debian.org/debian-mentors/2010/11/msg00174.html
(Sorry that I could not find this reference faster and reply to an earlier email you sent)

This said, the r-bioconductor-biobase could carry proeminent instructions on
how to enable your cran2deb repository.

By the way, can you use a magic tilde to ensure that the cran2deb packages have
a lower version number than possible official packages? For instance,
r-bioc-abarray_1.18.0-1cran1_all.deb would become r-bioc-abarray_1.18.0-1~cran1_all.deb.

Have a nice day, and many thanks for this great effort.
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Manuel Prinz
2011-02-18 08:54:52 UTC
Permalink
First of all, this is very good news! Thanks to everyone involved for
the effort!
Post by Charles Plessy
For the addition to /etc/apt/sources.d, I think I recall that something similar
feeling was strongly negative, see http://lists.debian.org/debian-mentors/2010/11/msg00174.html
(Sorry that I could not find this reference faster and reply to an earlier email you sent)
Right, adding entries to /e/a/sources.list.d is a big no-no. This is and
should stay the administrators domain. The only viable approach here is
to create a package for this single file and make sure that *no* other
packages depend on it, so it does *not* get pulled in automatically. The
key to the respective repository could be added as well. But that is
just for convenience. It is basically a no-brainer to add that repo. And
it's not an issue for live-systems such as BioLinux, as they can
customize their system as they please.

Anyway, the question to me boils down to the one in the subject: How can
we properly integrate cran2deb-built packages into Debian? There are a
lot of useful packages in CRAN, and even if we're mostly concerned about
BioConductor at the moment, it would be nice to have the whole CRAN in
Debian.

The main problem I see is the copyright review. This is not done in
cran2deb (not for every file, at least) and probably the main concern
for ftp-master. I'm not sure how to solve that properly. Maybe a file
with checksums of all files in a tarball signed by a DD might suffice.
Or a signed debian/copyright file. (Just brain-storming.)
Post by Charles Plessy
From a technical point of view, this might be (relatively) easy, as the
source packages could be pulled and build via the buildd network. But
maybe there's complexity involved that I don't see right now.

Given that ftp-masters meet next month, it might be a good point for
their agenda? I could bring this up and maybe even meet with them to
discuss that, as they meet "just around the corner". Anyone interested?

Best regards,
Manuel
Andreas Tille
2011-02-18 10:08:20 UTC
Permalink
Hi,

probably not the right list, debian-science list comes rather to mind
because Dirk Eddelbuettel (in CC) is also reading there. So please move
to this list in case you want to continue discussing this issue.
Post by Manuel Prinz
Anyway, the question to me boils down to the one in the subject: How can
we properly integrate cran2deb-built packages into Debian? There are a
lot of useful packages in CRAN, and even if we're mostly concerned about
BioConductor at the moment, it would be nice to have the whole CRAN in
Debian.
Probably yes because we have a better grip on Dependencies.
Post by Manuel Prinz
The main problem I see is the copyright review. This is not done in
cran2deb (not for every file, at least) and probably the main concern
for ftp-master. I'm not sure how to solve that properly. Maybe a file
with checksums of all files in a tarball signed by a DD might suffice.
Or a signed debian/copyright file. (Just brain-storming.)
I once suggested a similar brain-stormish idea to Dirk (IMHO in PM some
years ago). Yes, the copyright issue is the hardest reason why
automatic builds can not go into Debian. However, we could consider
manually written copyright files step by step for packages in our interest
and trigger a move to official Debian in case this file exists. I do
not think that any signed checksums are needed.
Post by Manuel Prinz
Given that ftp-masters meet next month, it might be a good point for
their agenda? I could bring this up and maybe even meet with them to
discuss that, as they meet "just around the corner". Anyone interested?
I'd consider this a good idea. However, you should definitely
coordinate with Dirk. IMHO it makes no sense to convince ftpmaster to
accept something if the main person who is involved into cran2deb
refuses to do something into this direction.

Kind regards

Andreas.

--
http://fam-tille.de
Tony Travis
2011-02-21 15:37:55 UTC
Permalink
Post by Andreas Tille
Hi,
probably not the right list, debian-science list comes rather to mind
because Dirk Eddelbuettel (in CC) is also reading there. So please move
to this list in case you want to continue discussing this issue.
Post by Manuel Prinz
Anyway, the question to me boils down to the one in the subject: How can
we properly integrate cran2deb-built packages into Debian? There are a
lot of useful packages in CRAN, and even if we're mostly concerned about
BioConductor at the moment, it would be nice to have the whole CRAN in
Debian.
[...]
Hi, Andreas.

If Bioconductor is no longer releavant to Debian-Med, what were our
discussions in Travemuende, and Steffen's work on cran2deb all about?

Bye,

Tony.
--
Dr. A.J.Travis, University of Aberdeen, Rowett Institute of Nutrition
and Health, Greenburn Road, Bucksburn, Aberdeen AB21 9SB, Scotland, UK
tel +44(0)1224 712751, fax +44(0)1224 716687, http://www.rowett.ac.uk
mailto:***@abdn.ac.uk, http://bioinformatics.rri.sari.ac.uk
Andreas Tille
2011-02-21 17:38:03 UTC
Permalink
Hi Tony,
Post by Tony Travis
Post by Andreas Tille
Hi,
probably not the right list, debian-science list comes rather to mind
because Dirk Eddelbuettel (in CC) is also reading there. So please move
to this list in case you want to continue discussing this issue.
Post by Manuel Prinz
Anyway, the question to me boils down to the one in the subject: How can
we properly integrate cran2deb-built packages into Debian? There are a
lot of useful packages in CRAN, and even if we're mostly concerned about
BioConductor at the moment, it would be nice to have the whole CRAN in
Debian.
[...]
If Bioconductor is no longer releavant to Debian-Med, what were our
discussions in Travemuende, and Steffen's work on cran2deb all about?
Huh - that seems to be a perfect missunderstanding to me! How in the
world came you to the conclusion Bioconductor would not be relevant to
Debian Med? Do you think so because I suggested to move the discussion
to Debian Science list? My reason to do so was because there are
several technicans involved in R packaging lurking at this list (most
specifically the main R packagers like Dirk) but not here on the Debian
Med list and we would hide competent eyes from our discussion here. The
question was a pure technical one and not about the content of handling
bio-medical problems.

So my original offer stays valid: Just provide a list of those
BioConductor packages which have the highest relevance for you and we
will include them into official Debian (in addition to the BioConductor
cran2deb effort). This has several advantages but also the drawback
of outdated packages. My concern was to keep the advantages by at the
same time sovling the problem of outdated packages for cran2deb *and*
BioConductor - but that's simply a non-biological question and does
not need to be discussed primarily here on this list.

Sorry if I have uses a misunderstandable wording

Andreas.
--
http://fam-tille.de
Tony Travis
2011-02-21 22:38:43 UTC
Permalink
Post by Andreas Tille
[...]
Post by Tony Travis
If Bioconductor is no longer releavant to Debian-Med, what were our
discussions in Travemuende, and Steffen's work on cran2deb all about?
Huh - that seems to be a perfect missunderstanding to me! How in the
world came you to the conclusion Bioconductor would not be relevant to
Debian Med?
Hi, Andreas.

Our misunderstanding is not perfect, but at least it's symmetrical :-)

I think Bioconductor *is* relevant to Debian-Med, and I'm grateful to
the Debian-Med developers who I met in Travemuende for their help with
automatically packaging Bioconductor for Ubuntu using cran2deb.
Post by Andreas Tille
Do you think so because I suggested to move the discussion
to Debian Science list?
Yes, I misunderstood why you wanted to move the discussion...
Post by Andreas Tille
My reason to do so was because there are
several technicans involved in R packaging lurking at this list (most
specifically the main R packagers like Dirk) but not here on the Debian
Med list and we would hide competent eyes from our discussion here. The
question was a pure technical one and not about the content of handling
bio-medical problems.
Both me and Steffen have signed up to the cran2deb project, but you are
right that many others are working on CRAN. What surprised me is that
few people seem to be interested in packaging Bioconductor, which is not
part of CRAN. One reason, as we've discussed, is that Bioconductor is
not 'core' R. However, because the Bioconductor source archive is the
same format as CRAN it means we can, and did, use cran2deb on it.
Post by Andreas Tille
So my original offer stays valid: Just provide a list of those
BioConductor packages which have the highest relevance for you and we
will include them into official Debian (in addition to the BioConductor
cran2deb effort).
In the short-term, I'll use the Ubuntu repository that Steffen helped me
to create on our bioinformatics server in Aberdeen. If and when the
cran2deb Bioconductor packages for Debian that Steffen has built make it
into Sid, and then into Ubuntu I'll look at them again.
Post by Andreas Tille
This has several advantages but also the drawback
of outdated packages. My concern was to keep the advantages by at the
same time sovling the problem of outdated packages for cran2deb *and*
BioConductor - but that's simply a non-biological question and does
not need to be discussed primarily here on this list.
I think we need to be clear that we are not attempting to package CRAN,
rather we are using the same cran2deb software to package Bioconductor.
Post by Andreas Tille
Sorry if I have uses a misunderstandable wording
No problem, and I hope I've explained clearly that my interest is in
Bioconductor not CRAN. I already use the official CRAN Ubuntu deb's.

Bye,

Tony.
Andreas Tille
2011-02-22 07:27:36 UTC
Permalink
Post by Tony Travis
Both me and Steffen have signed up to the cran2deb project, but you are
right that many others are working on CRAN. What surprised me is that
few people seem to be interested in packaging Bioconductor, which is not
part of CRAN. One reason, as we've discussed, is that Bioconductor is
not 'core' R. However, because the Bioconductor source archive is the
same format as CRAN it means we can, and did, use cran2deb on it.
... and because cran2deb is used I wanted to discuss with as many as
possible cran2deb people.
Post by Tony Travis
In the short-term, I'll use the Ubuntu repository that Steffen helped me
to create on our bioinformatics server in Aberdeen. If and when the
cran2deb Bioconductor packages for Debian that Steffen has built make it
into Sid, and then into Ubuntu I'll look at them again.
As far as I know the cran2deb packages will *not* automatically make it
into sid (be it from CRAN or BioConductor). That is actually the
problem I tried to discuss. Having some packages hanging around does
not move them to ftpmaster. This is a manual step which needs actively
checking the copyright. We also can not start a Denial of Service
Attack on ftpmaster by pushing automatically 3000 packages in the
incoming queue. So I repeat: If you want *any* BioConductor package
into sid you need to *name* them and let us work on the copyright file
and upload to new queue step by step. There is no automatic propagation
of these packages and there will never be. For a first shot onto this
you might just answer to this mail what BioConductor packages you used
the last two weeks. Lets start with these and add more later.
Post by Tony Travis
Post by Andreas Tille
This has several advantages but also the drawback
of outdated packages. My concern was to keep the advantages by at the
same time sovling the problem of outdated packages for cran2deb *and*
BioConductor - but that's simply a non-biological question and does
not need to be discussed primarily here on this list.
I think we need to be clear that we are not attempting to package CRAN,
rather we are using the same cran2deb software to package Bioconductor.
I perfectly understood this but besides of the purpose of a package
technically it does not matter from what archive you are building. It
just needs to be done. The Debian Med list tries to gather those
information which is connected to the purpose of application and will
adjust it to the general framework.
Post by Tony Travis
Post by Andreas Tille
Sorry if I have uses a misunderstandable wording
No problem, and I hope I've explained clearly that my interest is in
Bioconductor not CRAN. I already use the official CRAN Ubuntu deb's.
Yes, you did, but you did not yet provided a list of your most favourite
BioConductor packages.

Kind regards

Andreas.
--
http://fam-tille.de
Tony Travis
2011-02-22 22:34:41 UTC
Permalink
Post by Andreas Tille
[...]
As far as I know the cran2deb packages will *not* automatically make it
into sid (be it from CRAN or BioConductor). That is actually the
problem I tried to discuss.
Hi, Andreas.

Sorry, I didn't realise that was the problem you are concerned about.
Post by Andreas Tille
Having some packages hanging around does
not move them to ftpmaster. This is a manual step which needs actively
checking the copyright. We also can not start a Denial of Service
Attack on ftpmaster by pushing automatically 3000 packages in the
incoming queue.
I understand what you mean, but I've not suggested we do anything like
that. My first objective was to use cran2deb to create Bioconductor deb
packages for my own use under Ubuntu, as Steffen has done for Debian.
We've made our two repositories available for anyone who is interested.
How to submit the packages formally to Debian is a different topic.
Post by Andreas Tille
So I repeat: If you want *any* BioConductor package
into sid you need to *name* them and let us work on the copyright file
and upload to new queue step by step. There is no automatic propagation
of these packages and there will never be. For a first shot onto this
you might just answer to this mail what BioConductor packages you used
the last two weeks. Lets start with these and add more later.
I only use Bioconductor via GenePattern but I'm helping my colleague
Philip de Groot at Wageningen University to package GenePattern. Many
Bioconductor R libraries are used in different GenePattern modules. At
present we install them from source using R. I could post Philip's R
Bioconductor install script, but it installs dozens of Bioconductor
libraries and their dependencies.

If you want me to name some important Bioconductor packages I use then I
suggest "simpleaffy" and its dependencies:

http://bioconductor.org/packages/2.6/bioc/html/simpleaffy.html
Post by Andreas Tille
[...]
I perfectly understood this but besides of the purpose of a package
technically it does not matter from what archive you are building. It
just needs to be done. The Debian Med list tries to gather those
information which is connected to the purpose of application and will
adjust it to the general framework.
Debian-Med has already helped me achieve my first objective and I'm very
grateful for that. However, I must leave the task of deciding if
Bioconductor packages are of sufficient general interest to include them
in Debian Sid to other people. Many of us already install and use
Bioconductor packages directly from R, and we accept their licences.

Thanks for helping me to understand a little more what Debian-Med is
about but, as you said, the topic of submitting packages generated
automatically by cran2deb to Debian should be discussed elsewhere.

Bye,

Tony.
Andreas Tille
2011-02-23 20:35:07 UTC
Permalink
Post by Tony Travis
If you want me to name some important Bioconductor packages I use then I
http://bioconductor.org/packages/2.6/bioc/html/simpleaffy.html
OK. I'll take a look if time permits.
Post by Tony Travis
Debian-Med has already helped me achieve my first objective and I'm very
grateful for that.
I'm really happy that you see it that way! However, for clarification
issues I'd like to be picky on the wording. The help provided for your
objective was done by *people* who were working (NOT) by chance in the
Debian Med project and these were working on a larger community effort.
Very strictly speaking Debian Med is a Debian internal effort and as I
liked to point out the Bioconductor Debian packages are not in Debian,
will never be there except of those cherries we might pick and thus the
objective you had is an effort which is not part of Debian Med itself.

For sure we will continue to support your attempt and from a bio-medical
community forming point around Debian Med we are for sure very keen on
helping you. I just considered the example above as a good way to
explain what Debian Med is (and what it is not). So Debian Med is a
Debian internal effort which is driven by supporters who want to make
this system as good and as popular as possible. We see your interest
and try to help you with all our skills and knowledge to make you keen
on using Debian Med (as a Debian subset) because you see that you can
run all your BioConductor stuff very easily on it.
Post by Tony Travis
However, I must leave the task of deciding if
Bioconductor packages are of sufficient general interest to include them
in Debian Sid to other people. Many of us already install and use
Bioconductor packages directly from R, and we accept their licences.
The license ist most probably fine in nearly all cases - it just needs
to be checked.

Kind regards

Andreas.
--
http://fam-tille.de
Manuel Prinz
2011-02-25 19:55:28 UTC
Permalink
Post by Tony Travis
If you want me to name some important Bioconductor packages I use
http://bioconductor.org/packages/2.6/bioc/html/simpleaffy.html
Out of curiosity, I hacked a script (quick and dirty) that gathers
dependancy information from the Packages file of Steffen's cran2deb
repository[1] and draws a dependency graph that can be processed
with dot. An example output is attached.[2] It also gives some stats
on stderr about how many packages depend on a package. Dunno whether
or not this is useful, though.

Dashed entries are BioConductor packages, solid ones are from CRAN.
Post by Tony Travis
From the later, only r-cran-rsqlite is not yet in Debian. In order
to package r-bioc-simpleaffy, one CRAN package and 11 BioConductor
packages need to be packaged. One could start from the source
packages created by cran2deb. I'm not a user of BioConductor myself
but if there are a few people willing to work on that, I'd volunteer
to help with reviews and uploads. The packages should be beginner
friendly, so maybe someone would like to pick those up?!

Best regards,
Manuel

[1] http://master.dermacloud.uni-luebeck.de/cran2deb/rep/dists/testing/main/binary-amd64/Packages
[2] Created by calling: perl bioc-depends.pl r-bioc-simpleaffy | dot -Tpdf -or-bioc-simpleaffy.pdf
Andreas Tille
2011-02-25 21:47:49 UTC
Permalink
Post by Manuel Prinz
Out of curiosity, I hacked a script (quick and dirty) that gathers
dependancy information from the Packages file of Steffen's cran2deb
repository[1] and draws a dependency graph that can be processed
with dot. An example output is attached.[2] It also gives some stats
on stderr about how many packages depend on a package. Dunno whether
or not this is useful, though.
Cool! :-)
Post by Manuel Prinz
Dashed entries are BioConductor packages, solid ones are from CRAN.
Post by Tony Travis
From the later, only r-cran-rsqlite is not yet in Debian. In order
to package r-bioc-simpleaffy, one CRAN package and 11 BioConductor
packages need to be packaged. One could start from the source
packages created by cran2deb. I'm not a user of BioConductor myself
but if there are a few people willing to work on that, I'd volunteer
to help with reviews and uploads. The packages should be beginner
friendly, so maybe someone would like to pick those up?!
I'd really like to recommend this as beginners task because on one hand
you have the cran2deb source packages on the other hand you have several
R packages in our SVN. So it should be a copy-paste-modify like task
which has some lerning effect for newcomers but might be a bit boring
for people who might use their skills for more difficult tasks.

Any takers?

Kind regards

Andreas.
--
http://fam-tille.de
Tony Travis
2011-02-25 23:09:46 UTC
Permalink
Post by Manuel Prinz
Post by Tony Travis
If you want me to name some important Bioconductor packages I use
http://bioconductor.org/packages/2.6/bioc/html/simpleaffy.html
Out of curiosity, I hacked a script (quick and dirty) that gathers
dependancy information from the Packages file of Steffen's cran2deb
repository[1] and draws a dependency graph that can be processed
with dot. An example output is attached.[2] It also gives some stats
on stderr about how many packages depend on a package. Dunno whether
or not this is useful, though.
Hi, Manuel.

Well, I think that it's very useful - Thanks!
Post by Manuel Prinz
Dashed entries are BioConductor packages, solid ones are from CRAN.
Post by Tony Travis
From the later, only r-cran-rsqlite is not yet in Debian. In order
to package r-bioc-simpleaffy, one CRAN package and 11 BioConductor
packages need to be packaged. One could start from the source
packages created by cran2deb. I'm not a user of BioConductor myself
but if there are a few people willing to work on that, I'd volunteer
to help with reviews and uploads. The packages should be beginner
friendly, so maybe someone would like to pick those up?!
My original idea was to re-package the Bioconductor packages that are
required by GenePattern for Debian/Ubuntu. This would require quite a
lot of packages, and their dependencies, to be re-packaged. However, now
that we have a way of automatically creating source packages with
cran2deb it might be a tractable proposition to prepare the sub-set of
Bioconductor packages needed for GenePattern for submission to Debian.

My objective is to package GenePattern for Debian/Ubuntu, using the
existing CRAN packages in Debian/Ubuntu to satisfy dependencies. I'm
still waiting for the Broad Institute to tell us under what licence we
can redistribute GenePattern, but they are interested in our efforts.

Bye,

Tony.
Steffen Möller
2011-02-26 12:38:51 UTC
Permalink
Post by Tony Travis
Post by Manuel Prinz
Post by Tony Travis
If you want me to name some important Bioconductor packages I use
http://bioconductor.org/packages/2.6/bioc/html/simpleaffy.html
Out of curiosity, I hacked a script (quick and dirty) that gathers
dependancy information from the Packages file of Steffen's cran2deb
repository[1] and draws a dependency graph that can be processed
with dot. An example output is attached.[2] It also gives some stats
on stderr about how many packages depend on a package. Dunno whether
or not this is useful, though.
Hi, Manuel.
Well, I think that it's very useful - Thanks!
Post by Manuel Prinz
Dashed entries are BioConductor packages, solid ones are from CRAN.
Post by Tony Travis
From the later, only r-cran-rsqlite is not yet in Debian. In order
to package r-bioc-simpleaffy, one CRAN package and 11 BioConductor
packages need to be packaged. One could start from the source
packages created by cran2deb. I'm not a user of BioConductor myself
but if there are a few people willing to work on that, I'd volunteer
to help with reviews and uploads. The packages should be beginner
friendly, so maybe someone would like to pick those up?!
My original idea was to re-package the Bioconductor packages that are
required by GenePattern for Debian/Ubuntu. This would require quite a
lot of packages, and their dependencies, to be re-packaged. However, now
that we have a way of automatically creating source packages with
cran2deb it might be a tractable proposition to prepare the sub-set of
Bioconductor packages needed for GenePattern for submission to Debian.
My objective is to package GenePattern for Debian/Ubuntu, using the
existing CRAN packages in Debian/Ubuntu to satisfy dependencies. I'm
still waiting for the Broad Institute to tell us under what licence we
can redistribute GenePattern, but they are interested in our efforts.
Some of those packages are updated rather frequently. This is where
the main work goes into - not into the initial packaging, and this is
why this cran2deb bits came into play.

The philosophy of Dirk and Charles is that the automated builds shall
substitute the manual builds. If there is something to be changed to
the build process, then this patch should become part of cran2deb
(which can be done) and/or be communicated back upstream. This is why
the Debian version information does not offer any "~" magic and does
not do the "0cranX" for new packages like the friendly Ubuntu does.

We could overrule this, certainly, as Dirk keeps reminding us, this
is our repository. But we certainly need to think twice about if those
packages are not possibly too much evolving to be of any use in the
main distribution in the first place. For BioConductor's Debian packages
I would tend to think that a separate repository may be preferable.

Feedback on the usability of those packages so far was rather limited.
We shall now announce it to Debian's R SIG mailing list, give it some
time there and then go to the BioConductor mailing list.

Best,

Steffen
Karsten Hilbert
2011-02-26 12:59:51 UTC
Permalink
Post by Steffen Möller
We could overrule this, certainly, as Dirk keeps reminding us, this
is our repository. But we certainly need to think twice about if those
packages are not possibly too much evolving to be of any use in the
main distribution in the first place. For BioConductor's Debian packages
I would tend to think that a separate repository may be preferable.
Does this not mean that there ought to be a more convenient way for
users to discover that they need to activate an additional repository
(say, by somehow providing "pointers" from dummy meta "packages" within
the main archive towards other repos, or else via some tasks-like
mechanism or some such) and a user-friendly way of enabling such
repos ?

To provide this infrastructure is surely out of scope for Debian Med
proper but seems to be a useful target for Blends as such but needs
to be implemented in core Debian.

Karsten
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmx.net
Tony Travis
2011-02-26 13:48:43 UTC
Permalink
Post by Karsten Hilbert
Post by Steffen Möller
We could overrule this, certainly, as Dirk keeps reminding us, this
is our repository. But we certainly need to think twice about if those
packages are not possibly too much evolving to be of any use in the
main distribution in the first place. For BioConductor's Debian packages
I would tend to think that a separate repository may be preferable.
Does this not mean that there ought to be a more convenient way for
users to discover that they need to activate an additional repository
(say, by somehow providing "pointers" from dummy meta "packages" within
the main archive towards other repos, or else via some tasks-like
mechanism or some such) and a user-friendly way of enabling such
repos ?
To provide this infrastructure is surely out of scope for Debian Med
proper but seems to be a useful target for Blends as such but needs
to be implemented in core Debian.
Hi, Karsten.

I think you're right - In Bio-Linux, we already use a mirror of Dirk +
Charles's CRAN-R package repository. We don't use the core Debian CRAN
packages:

# apt-cache policy r-base
r-base:
Installed: (none)
Candidate: 2.12.1-1lucid0
Version table:
2.12.1-1lucid0 0
500 http://www.stats.bris.ac.uk/R/bin/linux/ubuntu/ lucid/ Packages
2.10.1-2 0
500 http://gb.archive.ubuntu.com/ubuntu/ lucid/universe Packages

I'm new to Debian-Med and I must admit that although I've found the
people here to be very helpful indeed, I now realise that as Andreas
said submitting all of Bioconductor as separate packages for inclusion
in Debian "will never happen". In some respects, this underlies mine and
Steffen's decision to create our own Debian/Ubuntu Bioconductor package
repositories using cran2deb. As you've pointed out, this topic is
outside the scope of Debian-Med, so we should probably take our
discussion of packaging Bioconductor for Debian/Ubuntu elsewhere.

Thanks for your constructive comments,

Tony.
Steffen Möller
2011-02-26 15:42:47 UTC
Permalink
Hello,
Post by Tony Travis
Post by Karsten Hilbert
Post by Steffen Möller
We could overrule this, certainly, as Dirk keeps reminding us, this
is our repository. But we certainly need to think twice about if those
packages are not possibly too much evolving to be of any use in the
main distribution in the first place. For BioConductor's Debian packages
I would tend to think that a separate repository may be preferable.
Does this not mean that there ought to be a more convenient way for
users to discover that they need to activate an additional repository
(say, by somehow providing "pointers" from dummy meta "packages" within
the main archive towards other repos, or else via some tasks-like
mechanism or some such) and a user-friendly way of enabling such
repos ?
To provide this infrastructure is surely out of scope for Debian Med
proper but seems to be a useful target for Blends as such but needs
to be implemented in core Debian.
[Tony to Karsten:]
Post by Tony Travis
I think you're right - In Bio-Linux, we already use a mirror of Dirk +
Charles's CRAN-R package repository. We don't use the core Debian CRAN
# apt-cache policy r-base
Installed: (none)
Candidate: 2.12.1-1lucid0
2.12.1-1lucid0 0
500 http://www.stats.bris.ac.uk/R/bin/linux/ubuntu/ lucid/ Packages
2.10.1-2 0
500 http://gb.archive.ubuntu.com/ubuntu/ lucid/universe Packages
I'm new to Debian-Med and I must admit that although I've found the
people here to be very helpful indeed, I now realise that as Andreas
said submitting all of Bioconductor as separate packages for inclusion
in Debian "will never happen". In some respects, this underlies mine and
Steffen's decision to create our own Debian/Ubuntu Bioconductor package
repositories using cran2deb. As you've pointed out, this topic is
outside the scope of Debian-Med, so we should probably take our
discussion of packaging Bioconductor for Debian/Ubuntu elsewhere.
I may have some advantage in interpreting the en_DE here (or be completely
misled). From how I read Karsten's and Andreas's replies, they are full
of sympathy and harmony with us and our cran2debbing. Karsten came to
accept that a separate repository for CRAN and BioConductor may be
preferable for Debian and Ubuntu to have, since even with the biannual
updates of Ubuntu one wants to update the applications, not the complete
OS. The installation from either source should be somehow "orthogonal"
and not be bound to e.g. 10.04 LTS.

What Karsten was saying is that if there is such a demand for separate
repositories, e.g. Debian has "non-free" offered itself, but there is the
independent repository for multimedia already, then the core Debian people
should start some head scratching on how Debian could develop further to
start integrating those better. This would also help e.g. the repositories
for skype, Opera, Eucalyptus, Mozilla.org, ... donno. This
"beyond Debian Med" was thus meant to support us. And I think Karsten
is right.

My personal interest for the moment is mostly on the scientific
functionality of the packages we provided. The deeper integration
of external repositories will also happen without me ;) The testing
we cannot do alone.

Best,

Steffen
Karsten Hilbert
2011-02-26 18:17:58 UTC
Permalink
Post by Steffen Möller
I may have some advantage in interpreting the en_DE here (or be completely
misled). From how I read Karsten's and Andreas's replies, they are full
of sympathy and harmony with us and our cran2debbing.
That is correct.
Post by Steffen Möller
What Karsten was saying is that if there is such a demand for separate
repositories, e.g. Debian has "non-free" offered itself, but there is the
independent repository for multimedia already, then the core Debian people
should start some head scratching on how Debian could develop further to
start integrating those better. This would also help e.g. the repositories
for skype, Opera, Eucalyptus, Mozilla.org, ... donno. This
"beyond Debian Med" was thus meant to support us.
Yes, absolutely.

Karsten
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmx.net
Andreas Tille
2011-02-26 21:12:32 UTC
Permalink
Post by Karsten Hilbert
Does this not mean that there ought to be a more convenient way for
users to discover that they need to activate an additional repository
(say, by somehow providing "pointers" from dummy meta "packages" within
the main archive towards other repos, or else via some tasks-like
mechanism or some such) and a user-friendly way of enabling such
repos ?
I'm not against a separate repository. However, regarding advertising
packages via package dependencies properly (and in turn having them
mentioned accordingly on our tasks pages) we con only do this with
official Debian packages. That's IMHO a fair reason to inject the most
important (=the packages which are explicitely requested by our users)
into official Debian. If we advertise the option how to enable an
external repository (perhaps by providing examples for
/etc/apt/{sources.list.d,preferences.d}) the problem of high frequency
updates is not that urgent as it was mentioned by Steffen. I'm actually
not fully convinced that every scientist really wants to update his
system that frequently and is keen on following upstream updates all the
time.
Post by Karsten Hilbert
To provide this infrastructure is surely out of scope for Debian Med
proper but seems to be a useful target for Blends as such but needs
to be implemented in core Debian.
I'm in favour of a general Blends solution but this solution is
definitely limited to some constraints mentioned above.

Kind regards

Andreas.
--
http://fam-tille.de
Steffen Möller
2011-02-26 22:05:49 UTC
Permalink
Post by Andreas Tille
Post by Karsten Hilbert
Does this not mean that there ought to be a more convenient way for
users to discover that they need to activate an additional repository
(say, by somehow providing "pointers" from dummy meta "packages" within
the main archive towards other repos, or else via some tasks-like
mechanism or some such) and a user-friendly way of enabling such
repos ?
I'm not against a separate repository. However, regarding advertising
packages via package dependencies properly (and in turn having them
mentioned accordingly on our tasks pages) we con only do this with
official Debian packages.
When looking at how Debian is working today, then what you said above
seems true. But maybe we generate ideas how to keep something separate
and nonetheless announce it a bit more and/or make installation. For
all reading this who might not have looked at it, yet:
http://debian-multimedia.org/
is fantastic. Maybe we even get Tony back to Debian after a look at
it (just kidding). I am still annoyed that it was mouth propaganda
that brought me to it and not some official Debian page.

The external repository should be fine as long as there is no package
in Debian main dependening on something from the external repository.
And when that happens, well, then those dependencies would indeed need
to be adopted.
Post by Andreas Tille
That's IMHO a fair reason to inject the most
important (=the packages which are explicitely requested by our users)
into official Debian.
I would wait for the explicit demand for those to be added.
Post by Andreas Tille
If we advertise the option how to enable an
external repository (perhaps by providing examples for
/etc/apt/{sources.list.d,preferences.d}) the problem of high frequency
updates is not that urgent as it was mentioned by Steffen. I'm actually
not fully convinced that every scientist really wants to update his
system that frequently and is keen on following upstream updates all the
time.
You are definitely right. Many will not like it. Es Tony said,
especially not so while a particular project is running. One would
need to set a package on hold, then, or just not update at all.
Post by Andreas Tille
Post by Karsten Hilbert
To provide this infrastructure is surely out of scope for Debian Med
proper but seems to be a useful target for Blends as such but needs
to be implemented in core Debian.
I'm in favour of a general Blends solution but this solution is
definitely limited to some constraints mentioned above.
We should somehow start with external repositories and see what we
can learn from it. We have two - one is the Ubuntu 10.04 based Bio-Linux
and the other now is the CRAN/BioConductor - and one obvious issue
is that neither will be completely compatible with Debian stable.
What exactly this means in practice we don't know yet. Our luck for
CRAN/BioConductor is that the version R in unstable is backported to
all versions of Debian and those of Ubuntu. This way we have a
pan-release interface for the packaging -- at least for the platform-
independent packages. For the others - let's see and think.

Steffen
Andreas Tille
2011-02-27 07:28:59 UTC
Permalink
[CC to debian-blends because it might concern other Blends seeking
ways to handle external archives. Short intro: BioConductor contains
a lot (> 1000) R packages which are turned automatically into Debian
packages using cran2deb. There is a big interest in these packages
but there is no chance to get them all into Debian because we have
on one side no manpower to check them all licensewise and we also
do not want to run a denial of service attack on ftpmaster.]
Post by Steffen Möller
When looking at how Debian is working today, then what you said above
seems true. But maybe we generate ideas how to keep something separate
and nonetheless announce it a bit more and/or make installation. For
http://debian-multimedia.org/
is fantastic.
While I'm using it myself I would not call it fantastic. I have learned
to know several people who consider it a very bad way to provide
non-free and even more importantly non-distributable software which is
not tested in any way and conflicts with properly maintained Debian
packages. While the truth is probably somewhere inbetween and I do not
share this option - even if I just was running in some version conflict
problems which was quite annoying and the contrary of fantastic.

But we are in a different (and better) position than debian-multimedia:
We are not talking about non-distributable software. As far as I
understood we just have the external archive of the BioConductor
software and for the moment we assume that the software inside is
distributable (it is just not checked if this is true).

We could even add all those packages as "Suggests" to a metapackage (we
can not use recommends because recommended packages need to be in main)
and since apt 0.8.11.2 finally #473089 was fixed and provides a simple
to find way to install suggested packages (--install-suggests) this
could easily provided to users in conncetion with a sources.list line as
I suggested in my last mail. In contrast to debian-multimedia this
situation is much better (provided that really all licenses of
BioConductor really allow distribution).

The only problem we have is that we are not able to properly advertise
these packages apropriately on our tasks pages - and this was an
explicite and fully reasonable requirement in your mail to do proper
advertising and not learning about something by chance. But we have no
information about these in UDD and thus can not put them on our tasks
page. I actually have a plan to import external sources into UDD (I
have even code ready to inject SkoleLinux archive into UDD modulo some
testing) we could inject such a BioConductor archive into UDD and
somehow tweack this information into the tasks pages. This has just to
be worked out in the Blends scope properly.
Post by Steffen Möller
Maybe we even get Tony back to Debian after a look at
it (just kidding).
Kidding? That's just a matter of time. ;-))
Post by Steffen Möller
I am still annoyed that it was mouth propaganda
that brought me to it and not some official Debian page.
Mouth propaganda??? It's the first Google Link for "Debian Multimedia"
search ... and there is a reason why people who work on properly
distributable multimedia packages do not really like this.
Post by Steffen Möller
The external repository should be fine as long as there is no package
in Debian main dependening on something from the external repository.
... and not "Recommending" (that's an important point). We can only
Suggest packages outside Debian main archive.
Post by Steffen Möller
And when that happens, well, then those dependencies would indeed need
to be adopted.
What we currently do in Blends frame is to verify whether a package
which is mentioned as "Depends" in the tasks page is really in main and
if it is not it is only Suggested. That will be possible to do also
with BioConductor packages. However as long as we can not inject the
metainformation of such packages we can not properly put them on our
tasks pages and we have no real QA control over these packages (can
not use BTS etc).
Post by Steffen Möller
Post by Andreas Tille
That's IMHO a fair reason to inject the most
important (=the packages which are explicitely requested by our users)
into official Debian.
I would wait for the explicit demand for those to be added.
Well, Tony just mentioned some interesting package and if time permits
(or some volunteer steps up) we can package it manually - IMHO that's no
conflict at all. We just have packaged several packages from CRAN as
well.
Post by Steffen Möller
Post by Andreas Tille
If we advertise the option how to enable an
external repository (perhaps by providing examples for
/etc/apt/{sources.list.d,preferences.d}) the problem of high frequency
updates is not that urgent as it was mentioned by Steffen. I'm actually
not fully convinced that every scientist really wants to update his
system that frequently and is keen on following upstream updates all the
time.
You are definitely right. Many will not like it. Es Tony said,
especially not so while a particular project is running. One would
need to set a package on hold, then, or just not update at all.
Either this or we might keep some more "stable" and highly requested
packages of BioConductor inside Debian in a highly tested version and
leave the Bioconductor2Deb packages archive for people who want the
latest and greatest (which does not conflict with everything I suggested
above).
Post by Steffen Möller
We should somehow start with external repositories and see what we
can learn from it. We have two - one is the Ubuntu 10.04 based Bio-Linux
and the other now is the CRAN/BioConductor - and one obvious issue
is that neither will be completely compatible with Debian stable.
What exactly this means in practice we don't know yet. Our luck for
CRAN/BioConductor is that the version R in unstable is backported to
all versions of Debian and those of Ubuntu. This way we have a
pan-release interface for the packaging -- at least for the platform-
independent packages. For the others - let's see and think.
So the plan is clear: We find even more studios packagers for the
packages we spotted as important which take over what is on my packaging
agenda which gives me the spare time which is needed to properly
finalise the work I started on external Blends archives. :-)

Kind regards

Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-blends-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@an3as.eu
Tony Travis
2011-02-28 00:55:58 UTC
Permalink
Post by Steffen Möller
[...]
When looking at how Debian is working today, then what you said above
seems true. But maybe we generate ideas how to keep something separate
and nonetheless announce it a bit more and/or make installation. For
http://debian-multimedia.org/
is fantastic. Maybe we even get Tony back to Debian after a look at
it (just kidding). I am still annoyed that it was mouth propaganda
that brought me to it and not some official Debian page.
Hi, Steffen.

I already mentioned to Andreas that Ubuntu is in most repects Debian.

The Debian and Ubuntu communities do, in fact, work together towards
common objectives. However, I created 'biobuntu' based on Ubuntu 6.06
and deb's from NEBC's Debian Sarge-based Bio-Linux4 because the user
experience with Ubuntu, even at 6.06, was so much better than Debian.

Tim has done a great job with the Ubuntu Lucid-based Bio-Linux6, but it
would not be a good user experience at all running it under Debian with
Iceweasel instead of Firefox, for example, and lots of non-free things
missing. These things do matter, even though we all know that the two
Linux platforms are almost identical underneath the GUI...

The vast majority of biologists use M$ Windows on their desktop, and
don't care about the server. However, to encourage biologists to use
Linux on the desktop as, presumably Debian-Med wants to, the user
experience needs to be at least as good as M$ Windows and preferably
better. I've just tried Debian 6 - It really is NOT better than M$.

This thread is a total turn-off for me about Debian-Med. Even though you
were joking about me going back to Debian, I can tell you that I never
will because in trying to win hearts and minds of ordinary users Debian
has already lost the fight. This sort of internecine conflict between
two very similar Linux distributions is pointless.

It is what Debian and Ubuntu have in common that attracted me to
Debian-Med. The people here have been very helpful indeed, but the
Debian politics I've witnessed recently are a wake-up call to me. What
is the big deal about the fact that we set up two Bioconductor repo's?

I'm glad that I've had the opportunity to understand why Bioconductor
can't simply be added to Debian-Med for the reasons that Andreas has
explained. I'm new to all this and it wasn't obvious to me at the outset
that it would be a problem, but cherry-picking a few popular
Bioconductor packages for inclusion in Debian-Med is a futile exercise.

What I would like to see us do is make a big effort to get cran2deb
working with all of Bioconductor on our two prototype repositories, with
less concern about the licences. Bioconductor is, after all, freely
available. In the first instance, I want to make a stable Bioconductor
available to users of Bio-Linux6 (64-bit Ubuntu 10.04).

If it's not appropriate to discuss that here, let's discuss getting
cran2deb working properly with all Bioconductor licences elsewhere.

Bye,

Tony.
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@minke.ukfsn.org
Charles Plessy
2011-02-28 14:09:09 UTC
Permalink
Post by Tony Travis
It is what Debian and Ubuntu have in common that attracted me to
Debian-Med. The people here have been very helpful indeed, but the
Debian politics I've witnessed recently are a wake-up call to me.
What is the big deal about the fact that we set up two Bioconductor
repo's?
Hi Tony,

I think that there is a confusion between Policy and politics :)

Debian packages are hand made and eye-reviewed, this is one core procedure
that can not be changed without changing Debian's identity.

The Biocoductor cran2deb repository is a great achievement that I hope we
will support and advertise appropriately, through packages in our archive
and documentation on our website.

Steffen's message in http://lists.debian.org/***@gmx.de suggests
that there will be a more general announcement. This would be a good
candidate for being added to our website in its news section:
http://www.debian.org/devel/debian-med/News/

Likewise, detailed instructions could be added to our website… Suggestions
welcome !

In parallell, I think that it will be complementary to distribute some
Bioconductor packages in Debian itself, in particular some that fit well
with in our tasks.

Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Olivier Sallou
2011-02-28 15:35:09 UTC
Permalink
Hi Charles,
will you have time to have a look to Gbrowse2 package or should I
request an other sponsor ?

I successfully packaged it and removed most of lintian warns (a few man
related remains)

Thanks

Olivier
Charles Plessy
2011-02-28 23:41:37 UTC
Permalink
Post by Olivier Sallou
Hi Charles,
will you have time to have a look to Gbrowse2 package or should I
request an other sponsor ?
I successfully packaged it and removed most of lintian warns (a few
man related remains)
Dear Olivier,

thanks a lot for all the work you did. I was super-busy this month, with
some family visit, and a very intensive conference at work. But I hope that
I will be able to look at Gbrowse2 this week.

Since it is a big package, other people are of course very welcome to
look at it.

Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Charles Plessy
2011-03-01 04:28:32 UTC
Permalink
Post by Charles Plessy
Post by Olivier Sallou
Hi Charles,
will you have time to have a look to Gbrowse2 package or should I
request an other sponsor ?
I successfully packaged it and removed most of lintian warns (a few
man related remains)
Dear Olivier,
thanks a lot for all the work you did. I was super-busy this month, with
some family visit, and a very intensive conference at work. But I hope that
I will be able to look at Gbrowse2 this week.
Dear Olivier,

I had a very, very brief look and realised that gbrowse does not build in
a minimal environment (pbuilder, sbuild, …). Can you try to iterate through
the build dependancies and correct them? Here is the tail of the build log:

perl: already installed (5.10.1-17 >= 5.10.0 is satisfied)
sqlite3: missing
libdbd-sqlite3-perl: missing
quilt: missing
libterm-readkey-perl: missing
Checking for dependency conflicts...
E: Broken packages
Installing positive dependencies: bioperl debhelper perl-depends libbio-graphics-perl libcapture-tiny-perl libcgi-session-perl libgd-gd2-noxpm-perl libio-string-perl libjson-perl libstatistics-descriptive-perl libwww-perl sqlite3 libdbd-sqlite3-perl quilt libterm-readkey-perl
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
libbio-graphics-perl : Depends: libgd-gd2-perl (>= 2.3) but it is not going to be installed


Do not hesitate to ask for help or advice.

Also, I just read on the BioPerl mailing list that there may be an update soon.
This is probably very relevant for Gbrowse; let's keep an eye on it.

Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Olivier Sallou
2011-03-01 07:35:40 UTC
Permalink
I gonna have a look.
Most deps are set with perl debian package helper. I will try with pbuilder
Post by Charles Plessy
Post by Charles Plessy
Post by Olivier Sallou
Hi Charles,
will you have time to have a look to Gbrowse2 package or should I
request an other sponsor ?
I successfully packaged it and removed most of lintian warns (a few
man related remains)
Dear Olivier,
thanks a lot for all the work you did. I was super-busy this month, with
some family visit, and a very intensive conference at work. But I hope that
I will be able to look at Gbrowse2 this week.
Dear Olivier,
I had a very, very brief look and realised that gbrowse does not build in
a minimal environment (pbuilder, sbuild, …). Can you try to iterate through
perl: already installed (5.10.1-17>= 5.10.0 is satisfied)
sqlite3: missing
libdbd-sqlite3-perl: missing
quilt: missing
libterm-readkey-perl: missing
Checking for dependency conflicts...
E: Broken packages
Installing positive dependencies: bioperl debhelper perl-depends libbio-graphics-perl libcapture-tiny-perl libcgi-session-perl libgd-gd2-noxpm-perl libio-string-perl libjson-perl libstatistics-descriptive-perl libwww-perl sqlite3 libdbd-sqlite3-perl quilt libterm-readkey-perl
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
libbio-graphics-perl : Depends: libgd-gd2-perl (>= 2.3) but it is not going to be installed
Do not hesitate to ask for help or advice.
Also, I just read on the BioPerl mailing list that there may be an update soon.
This is probably very relevant for Gbrowse; let's keep an eye on it.
Have a nice day,
--
gpg key id: 4096R/326D8438 (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@irisa.fr
Olivier Sallou
2011-03-01 08:01:30 UTC
Permalink
Hi Charles,
could you tell me which command you used ?

I tried with pbuilder:

pbuilder build gbrowse_2.26-1.dsc

and it works fine for me....

Olivier
Post by Charles Plessy
Post by Charles Plessy
Post by Olivier Sallou
Hi Charles,
will you have time to have a look to Gbrowse2 package or should I
request an other sponsor ?
I successfully packaged it and removed most of lintian warns (a few
man related remains)
Dear Olivier,
thanks a lot for all the work you did. I was super-busy this month, with
some family visit, and a very intensive conference at work. But I hope that
I will be able to look at Gbrowse2 this week.
Dear Olivier,
I had a very, very brief look and realised that gbrowse does not build in
a minimal environment (pbuilder, sbuild, …). Can you try to iterate through
perl: already installed (5.10.1-17>= 5.10.0 is satisfied)
sqlite3: missing
libdbd-sqlite3-perl: missing
quilt: missing
libterm-readkey-perl: missing
Checking for dependency conflicts...
E: Broken packages
Installing positive dependencies: bioperl debhelper perl-depends libbio-graphics-perl libcapture-tiny-perl libcgi-session-perl libgd-gd2-noxpm-perl libio-string-perl libjson-perl libstatistics-descriptive-perl libwww-perl sqlite3 libdbd-sqlite3-perl quilt libterm-readkey-perl
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
libbio-graphics-perl : Depends: libgd-gd2-perl (>= 2.3) but it is not going to be installed
Do not hesitate to ask for help or advice.
Also, I just read on the BioPerl mailing list that there may be an update soon.
This is probably very relevant for Gbrowse; let's keep an eye on it.
Have a nice day,
--
gpg key id: 4096R/326D8438 (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@irisa.fr
Charles Plessy
2011-03-01 08:13:36 UTC
Permalink
Post by Olivier Sallou
Hi Charles,
could you tell me which command you used ?
pbuilder build gbrowse_2.26-1.dsc
Hi Olivier,

I used sbuild…

I will not have time today, but I will also try with pbuilder later.

Bonne journée,
--
Charles
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Andreas Tille
2011-03-01 10:05:59 UTC
Permalink
Post by Charles Plessy
Post by Olivier Sallou
Hi Charles,
could you tell me which command you used ?
pbuilder build gbrowse_2.26-1.dsc
Hi Olivier,
I used sbuild…
I will not have time today, but I will also try with pbuilder later.
I used pbuilder the following way:

$ sudo pbuilder update
$ tar -xzf *.orig.tar.gz
$ cp -a <path_to_packaging>/debian GBrowse-2.26
$ cd GBrowse-2.26
$ pdebuild

This creates successfully a package where I have the following
issues:

1. Scripts in /bin should be in /usr/bin and should not contain the
*.pl extension (this was discussed several times on mailing lists -
feel free to ask for more detailed reasons)
Lintian:
W: gbrowse: script-with-language-extension bin/bed2gff3.pl
...

2. The only reason for an arch dependant package seems to be
/usr/lib/perl5/auto/Bio/Graphics/Browser2/CAlign/CAlign.so
It is not a good idea to have a package of large size (10MB) with
only one single small file which is arch dependant. So it is
advisable to split this up in a reasonable manner. I'd suggest
to move /usr/share/gbrowse2/databases into a separate package
gbrowse-data (arch=all). This makes a sensible split and should
be not to large in size for the arch=any part (remember: All
arch=any packages are ported to >10 architectures and mirrored
to an order of at least 1000 mirrors world wide. We should do
our share to nowaste these resources.

3. There is no need to provide a file
/usr/share/doc/gbrowse/INSTALL.gz
Hey, tha package *is* installed, right? If there are some things
to do left, just mention it in README.Debian

4. The init scripts do not support dependency based boot:

W: gbrowse: init.d-script-has-bad-start-runlevel /etc/init.d/gbrowse-slave 28
W: gbrowse: init-d-script-stops-in-s-runlevel /etc/init.d/gbrowse-slave
E: gbrowse: init.d-script-missing-dependency-on-remote_fs /etc/init.d/gbrowse-slave: required-start
E: gbrowse: init.d-script-missing-dependency-on-remote_fs /etc/init.d/gbrowse-slave: required-stop

5. Some other important lintian issues:

E: gbrowse: package-installs-packlist usr/lib/perl5/auto/GBrowse/.packlist
W: gbrowse: package-contains-upstream-install-documentation usr/share/doc/gbrowse/INSTALL.gz
W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/prototype.js
W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/scriptaculous.js


Thanks for your work on this package and keep on asking if you need
help in one of the issues mentioned above

Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@an3as.eu
Olivier Sallou
2011-03-01 11:04:30 UTC
Permalink
Hi,
I gonna have a look for the -data package, but won't be so easy due to
the way this is done in gbrowse....

For other comments this is strange, I made some modifications to remove
pl extensions errors, start/stop errors and INSTALL warning, I do not
have lintian errors anymore on this...
When did you this?
Post by Andreas Tille
Post by Charles Plessy
Post by Olivier Sallou
Hi Charles,
could you tell me which command you used ?
pbuilder build gbrowse_2.26-1.dsc
Hi Olivier,
I used sbuild…
I will not have time today, but I will also try with pbuilder later.
$ sudo pbuilder update
$ tar -xzf *.orig.tar.gz
$ cp -a<path_to_packaging>/debian GBrowse-2.26
$ cd GBrowse-2.26
$ pdebuild
This creates successfully a package where I have the following
1. Scripts in /bin should be in /usr/bin and should not contain the
*.pl extension (this was discussed several times on mailing lists -
feel free to ask for more detailed reasons)
W: gbrowse: script-with-language-extension bin/bed2gff3.pl
...
2. The only reason for an arch dependant package seems to be
/usr/lib/perl5/auto/Bio/Graphics/Browser2/CAlign/CAlign.so
It is not a good idea to have a package of large size (10MB) with
only one single small file which is arch dependant. So it is
advisable to split this up in a reasonable manner. I'd suggest
to move /usr/share/gbrowse2/databases into a separate package
gbrowse-data (arch=all). This makes a sensible split and should
be not to large in size for the arch=any part (remember: All
arch=any packages are ported to>10 architectures and mirrored
to an order of at least 1000 mirrors world wide. We should do
our share to nowaste these resources.
3. There is no need to provide a file
/usr/share/doc/gbrowse/INSTALL.gz
Hey, tha package *is* installed, right? If there are some things
to do left, just mention it in README.Debian
W: gbrowse: init.d-script-has-bad-start-runlevel /etc/init.d/gbrowse-slave 28
W: gbrowse: init-d-script-stops-in-s-runlevel /etc/init.d/gbrowse-slave
E: gbrowse: init.d-script-missing-dependency-on-remote_fs /etc/init.d/gbrowse-slave: required-start
E: gbrowse: init.d-script-missing-dependency-on-remote_fs /etc/init.d/gbrowse-slave: required-stop
E: gbrowse: package-installs-packlist usr/lib/perl5/auto/GBrowse/.packlist
W: gbrowse: package-contains-upstream-install-documentation usr/share/doc/gbrowse/INSTALL.gz
W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/prototype.js
W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/scriptaculous.js
Thanks for your work on this package and keep on asking if you need
help in one of the issues mentioned above
Andreas.
--
gpg key id: 4096R/326D8438 (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@irisa.fr
Andreas Tille
2011-03-01 13:31:54 UTC
Permalink
Post by Olivier Sallou
I gonna have a look for the -data package, but won't be so easy due to
the way this is done in gbrowse....
In principle it should not be that hard. At last resort you can

override_dh_install:
dh_install
move files around

IN any case you need to depend from gbrowse-data.
Post by Olivier Sallou
For other comments this is strange, I made some modifications to remove
pl extensions errors, start/stop errors and INSTALL warning, I do not
have lintian errors anymore on this...
When did you this?
Uhm, wait a moment - I had an old SVN checkout. I'll keep on posting
later.

Sorry for the confusion

Andreas.
--
http://fam-tille.de
Andreas Tille
2011-03-01 14:40:10 UTC
Permalink
Post by Andreas Tille
Uhm, wait a moment - I had an old SVN checkout. I'll keep on posting
later.
I commited two changes to SVN:

1. Use wildcard when mentioning the manpages to install.
This way dh_installmans does not try to install non-existing
manpages (at least I can not find these in my tarball -
there is only docs/gbrowse.1 but none of the others mentioned
in your file.
Any idea how to get the missing manpages?

2. Move binaries from /bin to /usr/bin

Because you asked about lintian: You most probably are using an
outdated lintian which is not as verbose as the one you get when trying

apt-get -t unstable install lintian

Please try again - there are other issues left and there are also hints
how to fix them whan using `lintian -i`. Just ask again if even the
latest lintian does not produce any problem.

Kind regards

Andreas.
--
http://fam-tille.de
Olivier Sallou
2011-03-01 14:51:52 UTC
Permalink
I use latest lintian and man pages are present in my package, I checked.
Did you apply the patch?
I added many of the man pages with the patch

Lintian still show 3 missing man pages and some man issues in a few.
Fixing man issue may be difficult as doc is extracted from perl files
automatically (perl2mod I think or something like that).

I gonna move bins as requested

Olivier
Post by Andreas Tille
Post by Andreas Tille
Uhm, wait a moment - I had an old SVN checkout. I'll keep on posting
later.
1. Use wildcard when mentioning the manpages to install.
This way dh_installmans does not try to install non-existing
manpages (at least I can not find these in my tarball -
there is only docs/gbrowse.1 but none of the others mentioned
in your file.
Any idea how to get the missing manpages?
2. Move binaries from /bin to /usr/bin
Because you asked about lintian: You most probably are using an
outdated lintian which is not as verbose as the one you get when trying
apt-get -t unstable install lintian
Please try again - there are other issues left and there are also hints
how to fix them whan using `lintian -i`. Just ask again if even the
latest lintian does not produce any problem.
Kind regards
Andreas.
--
gpg key id: 4096R/326D8438 (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@irisa.fr
Andreas Tille
2011-03-01 15:34:50 UTC
Permalink
Post by Olivier Sallou
I use latest lintian and man pages are present in my package, I checked.
Did you apply the patch?
Uhmm, not my day - old patch. :-(
Post by Olivier Sallou
I added many of the man pages with the patch
While it is perfectly valid to add the man pages via a patch (especially
if you plan to foreward this patch upstream) I would consider it way
more usual to move all manpages written by a Debian Maintainer to
debian/*.1. So what you are doing is not really wrong but might not
be the best idea (= just a hint, feel free to keep it as is).
Post by Olivier Sallou
Lintian still show 3 missing man pages and some man issues in a few.
Fixing man issue may be difficult as doc is extracted from perl files
automatically (perl2mod I think or something like that).
If lintian is simply nitpicking and you would like to provide the
manpages that way you might consider debian/lintian-overrides to make
sure these warnings will not hide other problems. With lintian 2.4.3
I get in addition to the manpage issues:

W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/prototype.js
W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/scriptaculous.js

As lintian suggests you might consider making the package dependant from
libjs-prototype and libjs-scriptaculous and add debian/links width

usr/share/javascript/prototype/prototype.js usr/share/gbrowse2/htdocs/js/prototype.js
usr/share/javascript/scriptaculous/scriptaculous.js usr/share/gbrowse2/htdocs/js/scriptaculous.js

(Just did something similar with python-cogent).
Post by Olivier Sallou
I gonna move bins as requested
I did it before I wrote my last mail.

Thanks for your packaging work (and sorry for the confusion I might have
caused when inspecting old code). Charles, could your please have a
look if you consider it ready for sponsering?

Kind regards

Andreas.
--
http://fam-tille.de
Olivier Sallou
2011-03-01 15:44:34 UTC
Permalink
for javascript dependencies, gbrowse use the latest ones. I can't
consider using the debian ones as I do not know exact gbrowse
requirements for those libraries. All I know is the current version in
use as they include it.

One possible thing would be to upgrade prototype/scriptaculous to latest
versions in debian repository.
Should I use maintainers to upgrade it?

Olivier
Post by Olivier Sallou
I use latest lintian and man pages are present in my package, I checked.
Did you apply the patch?
Uhmm, not my day - old patch.:-(
Post by Olivier Sallou
I added many of the man pages with the patch
While it is perfectly valid to add the man pages via a patch (especially
if you plan to foreward this patch upstream) I would consider it way
more usual to move all manpages written by a Debian Maintainer to
debian/*.1. So what you are doing is not really wrong but might not
be the best idea (= just a hint, feel free to keep it as is).
Post by Olivier Sallou
Lintian still show 3 missing man pages and some man issues in a few.
Fixing man issue may be difficult as doc is extracted from perl files
automatically (perl2mod I think or something like that).
If lintian is simply nitpicking and you would like to provide the
manpages that way you might consider debian/lintian-overrides to make
sure these warnings will not hide other problems. With lintian 2.4.3
I get in addition to the manpage issues:

W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/prototype.js
W: gbrowse: embedded-javascript-library usr/share/gbrowse2/htdocs/js/scriptaculous.js

As lintian suggests you might consider making the package dependant from
libjs-prototype and libjs-scriptaculous and add debian/links width

usr/share/javascript/prototype/prototype.js usr/share/gbrowse2/htdocs/js/prototype.js
usr/share/javascript/scriptaculous/scriptaculous.js usr/share/gbrowse2/htdocs/js/scriptaculous.js

(Just did something similar with python-cogent).
Post by Olivier Sallou
I gonna move bins as requested
I did it before I wrote my last mail.

Thanks for your packaging work (and sorry for the confusion I might have
caused when inspecting old code). Charles, could your please have a
look if you consider it ready for sponsering?

Kind regards

Andreas.

-- http://fam-tille.de
-- To UNSUBSCRIBE, email to debian-med-***@lists.debian.org with a
subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@an3as.eu
Andreas Tille
2011-03-01 18:54:16 UTC
Permalink
Post by Olivier Sallou
for javascript dependencies, gbrowse use the latest ones. I can't
consider using the debian ones as I do not know exact gbrowse
requirements for those libraries. All I know is the current version in
use as they include it.
Both JS libraries have the same version as in gbrowse is packaged in
experimental. Perhaps this can be simply solved by pinging the authors
about the reason for this. It might simply be a remaining of the
release process.
Post by Olivier Sallou
One possible thing would be to upgrade prototype/scriptaculous to latest
versions in debian repository.
I do not consider it worth spending much time into it just to resolve
a lintian warning. My concern is about security: Copies of code just
suck security wise and it should be avoided if possible.
Post by Olivier Sallou
Should I use maintainers to upgrade it?
Simply ask them if a transition from experimental to unstable can be
done in a reasonable time frame. We should keep in mind that even if we
upload gbrowse soonish it will be at the end of the queue where other
recently uploaded packages are hanging around. Chances are not bad that
the question becomes a non issue once gbrowse will enter unstable. I'd
regard it a fair compromise just to ignore the issue for now and update
the package once it has entered unstable and re-check the version of the
JS libraries at this time.

Kind regards

Andreas.
--
http://fam-tille.de
Charles Plessy
2011-03-07 01:09:05 UTC
Permalink
Post by Charles Plessy
I will not have time today, but I will also try with pbuilder later.
Dear Olivier,

I did not have time to try pbuilder. Instead, I inspected the source files of
Gbrowse, and documented their copyright notices and licenses in
debian/copyright. That was tedious and time-consuming, but it is required
before uploading to the Debian archive.

Default license is GPL version 1 or superior, or Artistic version 2. This
license is not in /usr/share/doc/common-licenses, so it needs to be in
debian/copyright. A large number of files are still GPL-1+ or Artistic (not
version 2), and I grouped them in the same paragraph after collating their
copyright notices. I also found some files whose license is MIT or LGPL.

Importantly, I found files that are obviously not the work of the main authors,
and that do not have a license. Of them, one is probably free (readseq.c), but
for the other, htdocs/css/dropdown/default_theme.css and
htdocs/css/dropdown/dropdown.css, there is not evidence that they are
redistributable. We need the confirmation directly by the authors or through
the Gbrowse developers.

Can you or somebody else doublecheck that I have not forgotten something ?

Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Tony Travis
2011-02-28 21:56:43 UTC
Permalink
Post by Andreas Tille
Post by Tony Travis
It is what Debian and Ubuntu have in common that attracted me to
Debian-Med. The people here have been very helpful indeed, but the
Debian politics I've witnessed recently are a wake-up call to me.
What is the big deal about the fact that we set up two Bioconductor
repo's?
Hi Tony,
I think that there is a confusion between Policy and politics :)
Hi, Charles.

I believe that 'policy' is generally a good thing, as a statement of
intent. My wake-up call is about Debian politics, by which I mean the
way that Debian makes collective decisions. I'm new to all this and I
must admit that I find political correctness an obstacle to progress.

Please don't misunderstand - I believe in FLOSS, and I support Debian
policy. However, I'm now rather more aware than I was that the biggest
difference between Debian and Ubuntu is their underlying politics :-)
Post by Andreas Tille
Debian packages are hand made and eye-reviewed, this is one core procedure
that can not be changed without changing Debian's identity.
OK, I understand that better now.
Post by Andreas Tille
The Biocoductor cran2deb repository is a great achievement that I hope we
will support and advertise appropriately, through packages in our archive
and documentation on our website.
This is mostly Steffen's work, but I'm grateful to Debian-Med for
organizing the 'sprint' in Travemuende where I was able to raise the
topic and get real help from you all to create an Ubuntu repository.
Post by Andreas Tille
that there will be a more general announcement. This would be a good
http://www.debian.org/devel/debian-med/News/
Yes, I think that would help us publicise our efforts to re-package
Bioconductor automatically for Debian/Ubuntu using cran2deb.
Post by Andreas Tille
Likewise, detailed instructions could be added to our website… Suggestions
welcome !
Ah, detailed instructions... That will be a work in progress ;-)
Post by Andreas Tille
In parallell, I think that it will be complementary to distribute some
Bioconductor packages in Debian itself, in particular some that fit well
with in our tasks.
I'm not sure how useful that would be, because even re-packaging one
Bioconductor simpleaffy package, and its dependencies is not trivial.

Most users import Bioconductor libraries from the main Bioconductor
repository, or a mirror, into their local R instance from source using
bioclite. What incentive would there be for people to install a few
manually comitted deb packages from Debian-Med instead of adding an
external APT repository with most/all Bioconductor deb's available?

What I think might be more useful is packaging cran2deb itself, and
documenting how to use it to create a Bioconductor deb repository.

Bye,

Tony.
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@minke.ukfsn.org
Andreas Tille
2011-02-28 22:19:53 UTC
Permalink
Post by Tony Travis
Most users import Bioconductor libraries from the main Bioconductor
repository, or a mirror, into their local R instance from source using
bioclite. What incentive would there be for people to install a few
manually comitted deb packages from Debian-Med instead of adding an
external APT repository with most/all Bioconductor deb's available?
As I said: We currently have no means to advertise BioConductor packages
inside the projects nor doe we have proper means to set Dependencies on
packages outside Debian. IMHO users would profit from both things which
might be a reason to manually package a relevant subset (if time permits
and other more important jobs are done).
Post by Tony Travis
What I think might be more useful is packaging cran2deb itself, and
documenting how to use it to create a Bioconductor deb repository.
Does it make sense to recalculate a Bioconductor deb repository over
and over instead of just mirroring the result of one single cran2deb
run which would be (re)done in a reasonable frequence?

Kind regards

Andreas.
--
http://fam-tille.de
Tony Travis
2011-02-28 23:26:57 UTC
Permalink
Post by Andreas Tille
[...]
Does it make sense to recalculate a Bioconductor deb repository over
and over instead of just mirroring the result of one single cran2deb
run which would be (re)done in a reasonable frequence?
Hi, Andreas.

That's not really what I had in mind - I was thinking more about the
detailed instructions for installing "cran2deb" that Charles mentioned.
It seemed like something that would be more suitable to encapsulate in a
deb package, rather than in a READ_ME for manual installation.

Admittedly, few people would install a "cran2deb" package. However, me
and Steffan have both installed "cran2deb" manually from Dirk's SVN. I
was, of course, tempted to create a simple binary package in completely
the wrong way but, so far, I've resisted ;-)

Many supporting tools like "pbuilder" that are used by "cran2deb" are in
fact available as deb packages. It just seemed like a useful idea.

Bye,

Tony.
Andreas Tille
2011-03-01 08:02:41 UTC
Permalink
Hi Tony,
Post by Tony Travis
Post by Andreas Tille
Does it make sense to recalculate a Bioconductor deb repository over
and over instead of just mirroring the result of one single cran2deb
run which would be (re)done in a reasonable frequence?
That's not really what I had in mind - I was thinking more about the
detailed instructions for installing "cran2deb" that Charles mentioned.
It seemed like something that would be more suitable to encapsulate in a
deb package, rather than in a READ_ME for manual installation.
Ahh OK. I agree it often makes sense to have code packaged also for a
local installation. If it is in this sense I agree.

Thanks for the clarification

Andreas.

PS: Also thanks for your Debian criticism which seems valid modulo the
outdated version you experienced. I hope that Squeeze might have
given a different experience regarding Java support - later more
about this.
--
http://fam-tille.de
Steffen Möller
2011-03-01 11:40:28 UTC
Permalink
Hello,
Post by Tony Travis
Post by Andreas Tille
[...]
Does it make sense to recalculate a Bioconductor deb repository over
and over instead of just mirroring the result of one single cran2deb
run which would be (re)done in a reasonable frequence?
That's not really what I had in mind - I was thinking more about the
detailed instructions for installing "cran2deb" that Charles
mentioned. It seemed like something that would be more suitable to
encapsulate in a deb package, rather than in a READ_ME for manual
installation.
Admittedly, few people would install a "cran2deb" package. However, me
and Steffan have both installed "cran2deb" manually from Dirk's SVN. I
was, of course, tempted to create a simple binary package in
completely the wrong way but, so far, I've resisted ;-)
Dirk and Charles were not in favour of having a Debian package for
cran2deb in the past. They may have changed their opinion by now. There
is a bit of a hen-and-egg problem with r-cran-digest, which is also
created by Dirk (as upstream) but not in our main distribution.

I had added the "debian" directory to the cran2deb source tree. It works
for me - but still leaves some considerable bits for a human soul to
fiddle here and there. The build and run time dependencies should all
be fine.

I suggest to just give it some more time and collect more experiences.

Best,

Steffen
Andreas Tille
2011-02-28 22:59:08 UTC
Permalink
Hi Tony,

I would like to discuss this topic in a separate thread on
debian-project where it might belong to.
it would not be a good user experience at all running it under Debian with
Iceweasel instead of Firefox, for example, and lots of non-free things
missing. These things do matter, even though we all know that the two
Linux platforms are almost identical underneath the GUI...
The vast majority of biologists use M$ Windows on their desktop, and
don't care about the server. However, to encourage biologists to use
Linux on the desktop as, presumably Debian-Med wants to, the user
experience needs to be at least as good as M$ Windows and preferably
better. I've just tried Debian 6 - It really is NOT better than M$.
Could you please be a bit more verbose on this. The only hard facts
I can make out from your mail are these:

- Iceweasel instead of Firefox
Debian does not rename Firefox just for the fun of it. We just
had a longish discussion about it with lawyers involved and they
came to the conclusion that we have no other chance than renaming
Firefox. Please do not blame Debian for other projects unusual
licenses.

- lots of non-free things missing
Can you please be a bit more verbose what exactly you are missing
(in general and specifically for your work as biologist).
I think I remember your unhappyness about Gnash. Anything else?

I personally admit that I simply have to trust your opinion that Debian
is not better than M$ because I do not know any M$ operating system well
enough to make a knowledgeable decision. My frustration when I touched
such systems were most probably based on my beginner status I have on
these but I would really like to hear some points which make me
understand your statement. (This is really an honest question.)
This thread is a total turn-off for me about Debian-Med. Even though you
were joking about me going back to Debian, I can tell you that I never
will because in trying to win hearts and minds of ordinary users Debian
has already lost the fight. This sort of internecine conflict between
two very similar Linux distributions is pointless.
I personally do not see a conflict between Debian and Ubuntu neither is
there any sign of a internecine one. I take your comment really
seriosely but to fully understand what you would expect (except Mozilla
changing its license and some better replacements of non-free tools).
For my perception criticism is the best way to progress and I really
hope that we will be able to meet your user experience in the future
better than in the past.
It is what Debian and Ubuntu have in common that attracted me to
Debian-Med. The people here have been very helpful indeed, but the
Debian politics I've witnessed recently are a wake-up call to me. What
is the big deal about the fact that we set up two Bioconductor repo's?
I think this was clarified and that there is no politics involved here.
Debian packages are simply handcrafted. There are people out there who
explain Debian as: Ubuntu but tested. I do not want to overstress this
polemic argument but there is some truth in it and hopefully makes you
understand that this has nothing at all to do with politics but rather
with quality and technical perfectness.

[I think your other questions are answered on the Debian Med mailing
list. I simply wanted to share some negative user experience in
contrast to several good critics on debian-project list. For the
readers here: I highly regard Tony's opinion. Please do not start
a flamewar about his opinion.]

Kind regards

Andreas.
--
http://fam-tille.de
Tony Travis
2011-03-01 00:37:23 UTC
Permalink
Post by Andreas Tille
Hi Tony,
I would like to discuss this topic in a separate thread on
debian-project where it might belong to.
Hi, Andreas.

OK, the topic is now closed on Debian-Med.
Post by Andreas Tille
[...] I simply wanted to share some negative user experience in
contrast to several good critics on debian-project list. For the
readers here: I highly regard Tony's opinion. Please do not start
a flamewar about his opinion.]
I don't want to start an advocacy debate about Debian vs. Ubuntu,
because that has been done to death elsewhere. My objective is to win
the hearts and minds of biologists using M$ Windows to run Bio-Linux,
the current version of which is based on 64-bit Ubuntu 10.04 LTS.

Together with my colleagues, I arranged a biologist's 'power' user
workshop in Florence during which we spent one of the three days in a
University computer lab set up entirely with Debian Etch workstations
running Iceweasel, to connect as NX clients to NuGO-Linux servers.

http://nbx.nugo.org

It was not my idea to use Debian clients. It was a facility offered to
us by the University of Florence and I was happy to accept the offer. I
did not anticipate the problems that we encountered doing something as
simple as running an NX client. The session was a complete disaster
until we rapidly installed the non-free Sun Java and browser plugin.

First off, our NuGO servers use the NX 'helper' applet that did not work
with gcj and IcedTea, to load a native NX client. Then as part of the
excercise we wanted to run Adobe reader. These things are trivial to do
under M$ Windows and I found myself unable to convince anyone that it
was a good idea to run Linux on the client-side. Needless to say, this
all worked perfectly from my Bio-Linux (Ubuntu) laptop.

I used Debian on SPARC and x86/x86_64 on workstations and servers long
before Ubuntu was released, and I'm well aware that Ubuntu is nothing
without Debian. However, my own experience of non-expert users being
introduced to Debian for the first time is a lot less satisfactory than
when they are introduced to Ubuntu. I'm not in any way detracting from
the huge achievements of Debian. I'm just saying that I found it easier
to convince sceptical M$ Windows users to run an NX client on their own
machine to access an Ubuntu server, or run Ubuntu on their own machine
than I did to convince them to use Debian for any purpose.

As Andreas said, this is not flame-bait - It's just my opinion, and I've
posted a message here on debian-project because he asked me to.

Bye,

Tony.
Sebastian Hilbert
2011-03-01 18:56:01 UTC
Permalink
Hi all,

I missed the beginning of the thread but neverthelesse I would like to chip in
a few thoughts as well.

The goal seems to be to make Debian as attractive to a biologist as MS. Worthy
goal but

1) When you decide to use Debian (for whatever reason) you accept the
responsibilities and ideas behind it (like it or not)

So if Debian decides (usually for good reasons) to exclude something then it
is their decision and one has to live with it when one *decides* to use
Debian.

2) If you *decide* that you want to use Debian and *not accept* Debian's
decision then you are on your own to find clever ways to circumvent the
problems (e.g. set up your own repositories to fill the gap) but you cannot
expect the Debian people to change their mind.

It is well know that having strict principles will not make your life easier.
So the goal should not be to change Debian until it will meet the principles
of MS so your problems will go away but educate biologists that the tradeoff
is worth it.

If one (biologist) does not *want* to accept the tradeoffs imposed by Debian
one should rather look for alternatives or stay with MS. There is little to be
gained *making* people like Debian without them *genuinely* accepting its
principles.

See. I would like to make my electric car go 900 km per charge like my diesel
car. Well I either accept the fact that this currently is not possible and
start to like my electric car or I stay with my diesel car. I am not going to
lure diesel car drivers into an electric car well knowing that they will
dislike the experience. And neither will I pressure the electric car maker to
add a diesel engine so the diesel car drivers will feel at home. It is all
about decisions.

I personally have stoped to *talk people into Linux*. They either find their
way themselves (and I will provide support) or they will stay with Windows.

As for the NX example. They went closed source recently. And if they really
wanted they could make it run on gcj and IcedTea.So it would be worth the
effort to kindly ask them to make it work on Debian.

But I probably totally missed the point.

Best regards,
Sebastian
Tony Travis
2011-03-01 20:34:37 UTC
Permalink
Post by Sebastian Hilbert
Hi all,
I missed the beginning of the thread but neverthelesse I would like to chip in
a few thoughts as well.
The goal seems to be to make Debian as attractive to a biologist as MS. Worthy
goal but
1) When you decide to use Debian (for whatever reason) you accept the
responsibilities and ideas behind it (like it or not)
So if Debian decides (usually for good reasons) to exclude something then it
is their decision and one has to live with it when one *decides* to use
Debian.
Hi, Sebastian.

The beginning of the thread was a joke by Steffen Moeller on Debian-Med
that I might be persuaded to return to Debian from Ubuntu...

Andreas posted his response to my comments on Debian-Med here instead
because it seemed like a more appropriate forum.

In fact, I did decide to use Debian long before Ubuntu existed and for
good reasons. In particular, cross-platform support on SPARC and x86.

What's frustrated me is that it seems to be a lot more difficult than I
first realised to put the Bioconductor repository as deb packages into
Debian according to the accepted policy. The issue of making Debian (or
Ubuntu) attractive to biologists is a side issue. However, it was a
topic that I raised at the recent Debian-Med sprint in Travemuende.

In my opinion, there is very little difference between Debian and Ubuntu
at the technical level. Someone, somewhere, suggested that Ubuntu is
Debian untested. I think that is a bit unfair, but it's true that Ubuntu
is nothing without Debian. However, when introducing naive users to
Debian and Ubuntu their reactions are quite different because Ubuntu
seems like a credible alternative to M$ but Debian does not.

In the struggle to win the hearts and minds of biologists to use
Bio-Linux instead of M$ Windows we've introduced them to Ubuntu, not
Debian. Bio-Linux was originally based on Red-Had Linux, then Debian
Sarge. At this point, I created 'biobuntu' using the Debian packages
from Bio-Linux4 and the Ubuntu Dapper (6.06 LTS) live CD:

https://blueprints.launchpad.net/ubuntu/+spec/biobuntu

The UK NEBC (Natural Environment Research Council Environmental
Bioinformatics Centre), the creators of Bio-Linux, then developed
Bio-Linux5 based on Ubuntu Hardy (8.04 LTS) and I helped them instead of
developing 'biobuntu' any further. Now, NEBC have released 64-bit
Bio-Linux6, and one objective of our Debian-Med meeting was to foster
collaboration between Debian-Med and Bio-Linux. The snag, for me, is
that I want to continue using Ubuntu not Debian. That, in itself, is not
a big problem. However, it raises the question of why I feel so strongly
that the user experience really does matter.
Post by Sebastian Hilbert
2) If you *decide* that you want to use Debian and *not accept* Debian's
decision then you are on your own to find clever ways to circumvent the
problems (e.g. set up your own repositories to fill the gap) but you cannot
expect the Debian people to change their mind.
Although I used Debian a lot in the past, I now use Ubuntu. I attended
the sprint because want to learn how to work in a way that facilitates
cooperation between the two. I have very little experience of Debian
policy (intent) or politics (how collective decisions are made) so this
is all new to me. I don't expect Debian to change, I was trying to
explain to Steffen and Andreas why I don't want to return to Debian,
from Ubuntu but I do want to work on projects that are relevant to both.
Post by Sebastian Hilbert
It is well know that having strict principles will not make your life easier.
So the goal should not be to change Debian until it will meet the principles
of MS so your problems will go away but educate biologists that the tradeoff
is worth it.
That's rather patronising, and not helpful to my argument. I don't think
biologists are stupid people - I used to be a biologist :-)
Post by Sebastian Hilbert
If one (biologist) does not *want* to accept the tradeoffs imposed by Debian
one should rather look for alternatives or stay with MS. There is little to be
gained *making* people like Debian without them *genuinely* accepting its
principles.
I'm not suggesting that we make anyone do anything. I don't know where
you got that impression from. In my experience most biologists are
pragmatic and they use whatever tools are available. Rather than just
accepting trade-offs imposed by Debian, I want biologists to get the
best experience possible. The point I raised with Andreas is that IMHO
the user experience of Ubuntu 10.04 LTS is 'better' than Debian 6. Of
course we know that it's all practically the same under the GUI, but I
don't think I'm alone in believing that a good user experience matters.
Post by Sebastian Hilbert
See. I would like to make my electric car go 900 km per charge like my diesel
car. Well I either accept the fact that this currently is not possible and
start to like my electric car or I stay with my diesel car. I am not going to
lure diesel car drivers into an electric car well knowing that they will
dislike the experience. And neither will I pressure the electric car maker to
add a diesel engine so the diesel car drivers will feel at home. It is all
about decisions.
Sorry, I think you've taken my comments the wrong way...
Post by Sebastian Hilbert
I personally have stoped to *talk people into Linux*. They either find their
way themselves (and I will provide support) or they will stay with Windows.
I work as a bioinformatician (formerly a biologist) and most often I
encounter people who try to use M$ Windows to do bioinformatics, but
reach a point where they realise that they can't go any further. I would
not dream of "talking" anyone into using Linux. That's not what my
comments were about. They were about expectations that M$ Windows users
have about how to use a computer. I want to help them use Linux without
them having to climb up a steep learning curve. The issue is not about
'converting' M$ Windows users to our cause, it's about why I believe
that Ubuntu meets M$ Windows users expectations better than Debian. As I
said before, I don't want to start an advocacy debate.
Post by Sebastian Hilbert
As for the NX example. They went closed source recently. And if they really
wanted they could make it run on gcj and IcedTea.So it would be worth the
effort to kindly ask them to make it work on Debian.
I've got an iMac at home running Ubuntu and I use the "qtnx" client on
it because there is no free-as-in-beer Nomachine NX client for PowerPC
Linux. However, we use the FreeNX server in Bio-Linux. The problem was
with Nomachine's Java 'helper' applet. Most of the biologists who use
our NuGO machines use a web browser to run the 'helper' applet, which
checks/updates the native NX client on their M$ Windows or Mac client.

What was such a disaster for me at the meeting in Florence was that they
were familiar with this working well from $M Windows but saw how many
problems we encountered doing the same thing under Debian. It was an
uncomfortable moment. The computer lab now runs M$ WIndows :-(
Post by Sebastian Hilbert
But I probably totally missed the point.
Maybe, a little :-)

Bye,

Tony.
Karsten Hilbert
2011-02-27 10:01:20 UTC
Permalink
1) Debian packages are not supposed to edit the configuration
of other packages.

2) apt-get provides /etc/apt/sources.list.d/

I am correct to assume that if a Debian packages needs to
modify sources.list (indirectly) it should drop a .conf file
into /etc/apt/sources.list.d/ ?

If so we could

- provide a meta package r-cran-repository which

- installs /etc/apt/sources.list.d/r-cran-repository.conf
- post-install runs "apt-get update" ?

- Suggests: a few main packages in r-cran-repository
- that way "apt-get --install-suggests install r-cran-repository" acts like an "R-CRAN task"
- Does that even work with already-installed packages ?
- if not we'd want/need an r-cran-most-common.deb Depends: r-cran-repository

- Lists: all (?) packages in r-cran-repository
- that way "apt-cache search some-r-cran-package" would find r-cran-repository and/or r-cran-most-common

I'm sure there's flaws in this scheme. Please find them.

Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Andreas Tille
2011-02-27 14:39:11 UTC
Permalink
Post by Karsten Hilbert
1) Debian packages are not supposed to edit the configuration
of other packages.
2) apt-get provides /etc/apt/sources.list.d/
I am correct to assume that if a Debian packages needs to
modify sources.list (indirectly) it should drop a .conf file
into /etc/apt/sources.list.d/ ?
Yes. However, opinions vary about the usage of this. But from my
perspective this our use case is prefectly apropriate here.
Post by Karsten Hilbert
If so we could
- provide a meta package r-cran-repository which
- installs /etc/apt/sources.list.d/r-cran-repository.conf
Yes.
Post by Karsten Hilbert
- post-install runs "apt-get update" ?
No. You can not run another apt-get process from apt-get. That
needs to be done afterwards (if I'm not totally wrong here).
Post by Karsten Hilbert
- Suggests: a few main packages in r-cran-repository
- that way "apt-get --install-suggests install r-cran-repository" acts like an "R-CRAN task"
In principle yes. We could even go further and drop
APT::Install-Suggests into /etc/apt/apt.conf.d to enforce
this - but I would absolutely not like this because it
might have several other unwanted consequences.
Post by Karsten Hilbert
- Does that even work with already-installed packages ?
I have not tested it but I would expect this. If the BioConductor
cran2deb repository contains higher versions than in Debian main
these will be installed - provided that you give no other advise
via /etc/apt/preferences.d.
Post by Karsten Hilbert
- if not we'd want/need an r-cran-most-common.deb Depends: r-cran-repository
The problem of this approach would be that it could not go into main
Debian because it would Depend (Recommend) packages outside. In the
consequence we can not build this with our tasks tools. For these two
reasons I'm in favour of the first method using suggests.
Post by Karsten Hilbert
- Lists: all (?) packages in r-cran-repository
- that way "apt-cache search some-r-cran-package" would find r-cran-repository and/or r-cran-most-common
That's fine.
Post by Karsten Hilbert
I'm sure there's flaws in this scheme. Please find them.
The main problem in my eyes is that we do not have the metainfo of the
external packages in UDD and thus can not put them on our tasks pages.
So they are not visible for Joe Random Debian-Med-User.

Kind regards

Andreas.
--
http://fam-tille.de
Charles Plessy
2011-02-26 13:30:33 UTC
Permalink
Post by Steffen Möller
The philosophy of Dirk and Charles is that the automated builds shall
substitute the manual builds. If there is something to be changed to
the build process, then this patch should become part of cran2deb
(which can be done) and/or be communicated back upstream. This is why
the Debian version information does not offer any "~" magic and does
not do the "0cranX" for new packages like the friendly Ubuntu does.
We could overrule this, certainly, as Dirk keeps reminding us, this
is our repository. But we certainly need to think twice about if those
packages are not possibly too much evolving to be of any use in the
main distribution in the first place. For BioConductor's Debian packages
I would tend to think that a separate repository may be preferable.
Hi Steffen

I read again the emails we exchanged on this subject, and I am not sure that
not using the "~" magic is done on purpose. The problem is that once a
repository started without, it is not easy to introduce it. Especially since we
have a similar philosophy for the backports, I think that the unofficial
packages we distribute should not take precedence over Debian's main archive.

Charles (not the same as mentionned above)
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-med-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@merveille.plessy.net
Olivier Sallou
2011-03-07 12:42:47 UTC
Permalink
It seems that main authors did not make such work :-(
I will try to have a look for those files (css) or see with authors.

Regarding included javascript librairies, expected versions are still in experimental. I contacted maintainer and he told me he should move them to sid in a short time.

So i suggest to wait for those libraries to be moved to sid and I will update scripts to use them instead of packaging them with gbrowse.
If this takes a too long time, I will keep them included for the moment...

Olivier

Le 3/7/11 2:09 AM, Charles Plessy a écrit :

Le Tue, Mar 01, 2011 at 05:13:36PM +0900, Charles Plessy a écrit :



I will not have time today, but I will also try with pbuilder later.

Dear Olivier,

I did not have time to try pbuilder. Instead, I inspected the source files of
Gbrowse, and documented their copyright notices and licenses in
debian/copyright. That was tedious and time-consuming, but it is required
before uploading to the Debian archive.

Default license is GPL version 1 or superior, or Artistic version 2. This
license is not in /usr/share/doc/common-licenses, so it needs to be in
debian/copyright. A large number of files are still GPL-1+ or Artistic (not
version 2), and I grouped them in the same paragraph after collating their
copyright notices. I also found some files whose license is MIT or LGPL.

Importantly, I found files that are obviously not the work of the main authors,
and that do not have a license. Of them, one is probably free (readseq.c), but
for the other, htdocs/css/dropdown/default_theme.css and
htdocs/css/dropdown/dropdown.css, there is not evidence that they are
redistributable. We need the confirmation directly by the authors or through
the Gbrowse developers.

Can you or somebody else doublecheck that I have not forgotten something ?

Have a nice day,
--
gpg key id: 4096R/326D8438 (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Continue reading on narkive:
Loading...