Hi Gordon,
On Thu, Jan 28, 2021 at 08:32:29AM +0000, Gordon Ball wrote:
> 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).
Yes, IMHO we should do an upload which fixes this.
> 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
Yes, that's what I tried to explain and what is the reason for not
just uploading.
> 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 should not set the --version flag at all which would lead
to a correct stripped tarball name.
> > 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.
I think the same - otherwise I would have done some action.
If you can find a solution that on one hand reports correctly that
tha package is up to date *and* results in a correctly named source
tarball I'd be more than happy. If not I suggest you upload at least
something that reports correct package update status and leaves some
manual work (which is seldom enough) for the maintainer.
Kind regards
Andreas.
> > [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
>
--
http://fam-tille.de