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

Bug#635593: qa.debian.org: PTS shows incorrect latest upstream version



Package: qa.debian.org
Severity: normal

The ‘python-coverage’ package has a ‘debian/watch’ file. This
configuration allows ‘uscan’ to correctly report the latest upstream
version:

=====
$ uscan --verbose --report
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   opts="uversionmangle=s/(\d)([a-z]\d+)$/$1~$2/"     http://pypi.python.org/packages/source/c/coverage/coverage-(.+).tar.gz
-- Found the following matching hrefs:
     coverage-3.0.1.tar.gz
     coverage-3.0.tar.gz
     coverage-3.0b3.tar.gz
     coverage-3.1.tar.gz
     coverage-3.1b1.tar.gz
     coverage-3.2.tar.gz
     coverage-3.2b1.tar.gz
     coverage-3.2b2.tar.gz
     coverage-3.2b3.tar.gz
     coverage-3.2b4.tar.gz
     coverage-3.3.1.tar.gz
     coverage-3.3.tar.gz
     coverage-3.4.tar.gz
     coverage-3.4b1.tar.gz
     coverage-3.4b2.tar.gz
     coverage-3.5.tar.gz
     coverage-3.5b1.tar.gz
Newest version on remote site is 3.5, local version is 3.4
 => coverage-3.5.tar.gz already in package directory
-- Scan finished
=====

The PTS page <URL:http://packages.qa.debian.org/p/python-coverage.html>
disagrees though:

=====
A new upstream version is available: 3.5~b1, you should consider packaging it.
=====

The PTS is evidently using the watch file's version mangling (that's how
the ‘~’ is introduced), but is comparing the resulting version string
incorrectly and coming up with a wrong value for the latest version.

The correct “new upstream version” at this point in time is not “3.5~b1”
but instead is “3.5”, as correctly determined by ‘uscan’. The PTS should
use the same comparison algorithm in order to get the same result.

-- 
 \      “Nullius in verba” (“Take no-one's word for it”) —motto of the |
  `\                                   Royal Society, since 1663-06-30 |
_o__)                                                                  |
Ben Finney <ben@benfinney.id.au>



Reply to: