Hi Jim,
seems like we got in contact to the perfectly right time. :-)
I'm happily waiting for your colleagues showing up at the Debian Med
list (which I'd strongly recommend for this purpose since I'm just a
member of the team and not the whole team ;-)) and repeat that one of
them might be interested in our Mentoring of the Month effort
https://wiki.debian.org/DebianMed/MoM
Looking forward to a great cooperation
Andreas.
On Thu, Feb 27, 2014 at 12:17:09AM -0800, Jim Kent wrote:
Disabling the pslCheck seems like the sensible and pragmatic thing.
I'm going to write a short note introducing you to Hiram Clawson, and
also
Ann Zweig our project manager (and Hiram's boss). It is actually part of
our grant to package the tools in ways to make it easier for people to
use
them. Our current system is not so bad, but it requires people to
actually read the README, and set an environment variable. This was
state
of the art in 1985, but not the
config
make
make install
people are used to these days, never mind a RPM or anything more recent,
and most of the younger programmers get lost.
I do think we want to do some renaming of directories and the like as
part
of this process, and ideally end up with all the code that is under one
license under the same subdirectory. It's somewhat close to that, but
there are enough exceptions to be a pain. We switched from CVS to git
about 2 years ago in large part to make moving directories around much
less
of a pain in the butt, so we _can_ do this now, but it's been sort of a
back burner thing, and is only about 10% complete.
Anyway, we are paid by the taxpayers to do this sort of work, and will
make some time for it. We would welcome your help, and getting it into
Debian is as good a starting point as any, better than most if we have
support from that group.
Take care,
Jim
On Wed, Feb 26, 2014 at 11:16 PM, Andreas Tille <tille@debian.org>
wrote:
Hi Jim,
On Wed, Feb 26, 2014 at 10:33:59PM -0800, Jim Kent wrote:
I'm glad you isolated it to the -O2.
:-)
I don't think there's a super easy way to cut pslCheck out of the
whole
1,200,000 UCSC genomics source tree.
For the moment I simply disabled this check. I guess it is also this
way sufficient to detect potential problems (and it was not the
pslCheck
that failed in the first place).
I would, on the other hand, be very
happy for you to take on the job of packaging up that whole source
tree
for
Debian. I could refer you to a less busy member of my staff, Hiram
Clawson, who has a _lot_ of experience helping people get that to
build.
This is a very cool offer. I actually have thought about packaging the
whole UCSC genomics source tree as well since it obviously contains
several tools that perfectly fit in our scope. I wonder whether Hiram
might even like to learn something about Debian packaging. In our team
we have quite some tradition in mentoring people as you can see here:
https://wiki.debian.org/DebianMed/MoM
Perhaps it comes handy if somebody in your team is capable to create
Debian packages which in the end is not more than wrapping up the build
process into some sceme.
BTW, when I inspected the jksrc source tree (and also in the specific
case of the blat source) I realised that it might make real sense to
enable dynamic linking of the tools against the static libraries you
are
creating. The Debian way to do this would be to create two packages:
lib<name> containing the dynamic libraries
lib<name>-dev containing the static libraries and header files
To approach this easily it is quite convenient to use either GNU
automake or cmake (at your preference) since these build systems easily
support the creation of dynamic and static libraries in parallel. This
would also simplify the hancling of MACHTYPE in your makefiles since
these Build systems are capable to handle this automatically. In
short:
before we might start packaging the whole source tree it would be quite
sensible to switch to an advanced build system which would be also in
your profit at the end.
The licensing of it is quite complex alas. There are three main
parts:
- a small part which is owned by me in a directory called jkOwnLib,
and
in
the blat directories
This would probably make a separate library package. However, you
might
consider a name which is more descriptive than jkOwnLib.
- a medium sized part that contains stuff we regard as generally
useful
which is essentially public domain, but that we are happy distributed
under
a BSD or MIT license
Cool. That would be very interesting.
- a large part that is genomics in general, and UCSC Genome Browser
in
particular specific that is owned by UCSC and has a license much like
blat
- free for personal, academic, and non-profit use, and requiring a
license
for commercial use. In this case the licence needs to come from UCSC
(contact Will Hale) rather than Kent Informatics (contact Heidi
Brumbaugh).
In case we have a good plan about the technical details we should
probable contact these persons regarding the licensing.
Kind regards
Andreas.
--
http://fam-tille.de
--
http://fam-tille.de