Re: r-cran-pbdzmq reporting erroneously new upstream version
On Wed, Jan 27, 2021 at 04:48:53PM +0100, Andreas Tille wrote:
> Hi Gordon,
>
> after your change[1] uscan started reporting new upstream version which
> is wrong. Thus I reverted that change at the expense that the final source
> tarball is wrongly named which is a consequence of the repackaging which
> does not respect the filemangle option. It is caused by the call
>
Yes, I noticed this was broken by 3f15ecad (in 0.3.4+dfsg-1), but I pushed a
subsequent commit cf38b12a which I think had already solved the issue
(although this obviously isn't reflected in UDD etc since it hasn't been
uploaded).
While both your commit yesterday and cf38b12a correctly report
uscan info: => Package is up to date
I think you've regressed getting a tarball with the correct name
Running uscan -v --force with cf38b12a gives
uscan info: Launch mk-origtargz with options:
--package r-cran-pbdzmq --version 0.3.4 --repack-suffix +dfsg
--compression default --directory .. --copyright-file
debian/copyright ../pbdZMQ_0.3-4.tar.gz
Successfully repacked ../pbdZMQ_0.3-4.tar.gz as
../r-cran-pbdzmq_0.3.4+dfsg.orig.tar.xz, deleting 272 files from it.
While your version 2f026e10 from yesterday:
uscan info: Launch mk-origtargz with options:
--package r-cran-pbdzmq --version 0.3-4 --repack-suffix +dfsg
--repack --compression xz --directory .. --copyright-file
debian/copyright ../r-cran-pbdzmq-0.3.4.tar.gz
Successfully repacked ../r-cran-pbdzmq-0.3.4.tar.gz as
../r-cran-pbdzmq_0.3-4+dfsg.orig.tar.xz, deleting 272 files from it.
(Unless I'm misunderstanding which way round you think the --version
flag should be)
> uscan info: Launch mk-origtargz with options:
> --package r-cran-pbdzmq --version 0.3-4 --repack-suffix +dfsg --repack --compression xz --directory .. --copyright-file debian/copyright ../r-cran-pbdzmq-0.3.4.tar.gz
>
> For some reason uscan insists in specifying a --version option (in this
> case the wrong one for whatever reason). I think there is no really good
> solution (besides fixing uscan) for this package. However, I think we
> should avoid that uscan reports "new upstream version" which is a real
> nuisance since the package always adds noise to our QA tools. I could
> somehow live with renaming the wrongly named repackaged tarball (as it
> is now in my commit). But may be it is time to fix #898037 and end the
> nasty version mangling and use an epoch. Or even ask upstream for a new
> "release" version 0.4 - just to help us out of this dilemma.
>
Given the rarity of updates to this package, I think the main issue is
just that it doesn't report being wrongly out of date on QA/UDD. I
would just upload a -2 with fixed d/watch and continue to wait to see
if upstream releases a 0.4 version to fix #898037. I don't think our
issues with version numbers are sufficient grounds to ask them to do so.
> What do you think?
>
> Kind regards
>
> Andreas.
Gordon
>
>
> [1] https://salsa.debian.org/r-pkg-team/r-cran-pbdzmq/-/commit/3f15ecadc1a5397f1558951a0fb5fb8b7da39283
> [2] https://salsa.debian.org/r-pkg-team/r-cran-pbdzmq/-/commit/2f026e10dde9d9ce4126ee204ab071645ffd9452
>
> --
> http://fam-tille.de
Reply to: