Yes. If you could reiterate some of the links, or if you prefer just forward this whole thread to Hiram, it would be great. Then I can go back to wrestling with the ENCODE monster!
On Thu, Feb 27, 2014 at 12:31 AM, Andreas Tille <[email protected]> wrote: > 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 <[email protected]> > 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 >
