Web lists-archives.com

Re: Debian Policy 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.