Re: Debian Policy 18.104.22.168 released
- Date: Sun, 8 Apr 2018 07:28:20 +0800
- From: Paul Wise <pabs@xxxxxxxxxx>
- Subject: Re: Debian Policy 22.214.171.124 released
On Sat, Apr 7, 2018 at 8:49 PM, Ole Streicher wrote:
> I have a number of "uncommon" upstreams:
It would be really nice if these folks could switch to something more
standard. Have they considered using a version control system for a
> * aladin, download http://aladin.unistra.fr/java/download/AladinSrc.jar
> look for the VERSION string in cds/aladin/Aladin.java and remove the
> leading "v" (and for Pre-releases, download AladinBetaSrc.jar, or a
> ad-hoc named jar, like AladinSrcV10Premiere.jar).
The version number can be obtained here:
With a pagemangle, uscan could detect the version and associated tarball.
> * coyote, http://www.idlcoyote.com/programs/zip_files/coyoteprograms.zip
> look for the latest file date in the zip file (no upstream versioning)
There is apparently a github org for this:
With a pagemangle, you can get the latest date from that:
> * idlastro, https://idlastro.gsfc.nasa.gov/ftp/astron.tar.gz
> similar (latest file date; no upstream versioning)
There is apparently a github repo for this, use pagemangle:
> * mpfit, https://cow.physics.wisc.edu/~craigm/idl/down/mpfit.tar.gz
> Take version number from "Revision" in mpfit.pro and add the latest
> file date
This contains the mpfit.pro Revision and all dates, use pagemangle:
PS: the $Id things are from CVS, could you ask upstream to publicly
expose their CVS repository?
> * skyview, https://skyview.gsfc.nasa.gov/current/jar/skyview.jar
> look for "Version=" in skyview.settings
The version number is listed on two pages, use pagemangle:
Unfortunately both are outdated compared to the jar...
> * starjava-*, download via svn (subdir of https://github.com/Starlink/starjava)
> add the main LICENSE.txt file,
> get the version from build.xml property, and add latest file date
> (but download only tagged versions of starjava-topcat, starjava-ttools,
> and starjava-table).
uscan can deal with git repos just fine.
> The rules may change over time (since I try to convince them to be more
> friendly here), so unless there is a flexible way for me to change them
> myself, I doubt it would be a good idea to put it there.
We could add you to the salsa qa group so you can commit them, but
given the above I think most are best dealt with by uscan.