[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: packaging UCSC kent tools for debian-med

Good Morning Andreas:

Yes, the versioned tar balls can be seen here:


Note the userApps.vNNN.src.tgz files
with the newest one always as simply userApps.src.tgz

These binaries can be built thusly:

rm -fr userApps
wget --timestamping  http://hgdownload.cse.ucsc.edu/admin/exe/userApps.src.tgz
tar xvzf userApps.src.tgz
cd userApps
MAKE="make -j 24" make -j 24 > make.log 2>&1

Resulting binaries end up in userApps/bin/

The versioned tarballs do not unpack into unique named directories,
they unpack in the same 'userApps' binary:

This is the same result:

rm -fr userApps
wget --timestamping  http://hgdownload.cse.ucsc.edu/admin/exe/userApps.v323.src.tgz
tar xvzf userApps.v323.src.tgz
cd userApps
MAKE="make -j 24" make -j 24 > make.log 2>&1

Please note the userApps/README file for expected system requirements
and alternative build procedures using 'git', for example:


This code will not compile nor function on sparc or alpha machines.
Only x86_64 and Mac OSX have been tested.  There is no comprehensive test suite,
although some binaries do have a 'make test' target but it is all a manual
procedure, nothing automatic.


On 10/18/15 12:12 AM, Andreas Tille wrote:

are there any news about versioned tarballs of your software at
genome-source.cse.ucsc.edu ?

Kind regards


On Wed, Aug 27, 2014 at 11:04:13AM +0200, Andreas Tille wrote:
Hi again,

please see my additions inline!

On Wed, Aug 27, 2014 at 10:52:35AM +0200, Andreas Tille wrote:
Hi Hiram,

I hope you don't mind if I'm putting Debian Med list in the discussion
which I would like you to do in pure technical discussion as well.

On Wed, Aug 27, 2014 at 12:00:59AM -0700, Hiram Clawson wrote:
Good Evening Andreas:

I'm curious if there would be a way to fit this building procedure
into the Debian-Med project:


Note steps 1, 2, 3 near the top of the README after the 'System Requirements'

I fully realize this isn't they way packages are supposed to work, but at
this time, this is the best we have.

Simply from reading the README I can not see anything unusual.  Step 1
(fetching the tarball) is totally normal workflow,

Some correction to what I said here:  Please provide a *versioned*
tarball!  Every tarball should have a version to be able to detect updates.

Moreover once I have checked the tarball I realised that the problematic
license which was discussed previously[0] remains.  So *if* this software
should be distributed by Debian this needs to be fixed first.

step 2 is cd-ing to
the unpackaged dir and call make is also pretty normal except that this
make call is done by the debhelper tools.  The only difference is step 3
where we do not move files to /usr/local but rather into /usr/bin inside
the Debian package.

Perhaps there could be a way to
encapsulate these first three steps into some kind of building/packaging
business that would satisfy the standard build and packaging procedures ?

Yes, for sure.  That's the day job of a Debian packager.  Do you want to
learn how to do this?  If yes we could offer mentoring in the so called
Mentoring of the Month[1] effort.  While there is right now the
September slot occupied I would try hard to help you as well since if we
want to get these tools included (and I would really love to see this)
we need to start right now.

So are you able to invest some time slots into the packaging and want to
work together with us please subscribe this mailing lists (links should be
given on the Wiki page[1]) and ask for help here in case of trouble or
if you need some kickstart help.

Thanks for your interest in Debian Med


[1] https://wiki.debian.org/DebianMed/MoM

[0] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-March/025520.html


To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: https://lists.debian.org/20140827090413.GC25601@an3as.eu

Reply to: