twinkle 1.10.1

[Peter Colberg]

Hi Rolf,

On Sat, Oct 29, 2016 at 01:52:42PM +0200, Rolf Leggewie wrote:
> thank you for your mails.  My apologies for not responding sooner.

Thank you for finally responding. I admit I was a bit worried when you
started pushing commits without having replied to any of my messages.

> Well, I do not mention the files out of boredom.  I've been a long-time
> DM and found that information to be helpful.  I do not think it will
> interfere with your style and do not intend to change the style for my
> good dozen packages.  Only other option would be to use two different
> commit styles and frankly, I think that's far too much trouble.  I hope
> you won't mind.

Indeed, if it is your style then I won’t mind.

> Case in point of filenames being helpful information; your commit
> c198607bc.  "Bump debhelper compat level to 10" would have never led me
> to believe that you would touch debian/rules to drop the parallel
> building.  Frankly, I think that should have been an atomic commit of
> its own.  Why did you drop it after all?  It seems to have worked fine here.

At compat level 10 --parallel is enabled by default, so the option is
now redundant. You are perfectly right, it would have been better to
split this into two commits. I tend to be a bit too minimalist and
assume too much context that another developer might not have.

> My tarball IS reproducible, apparently just differently from your
> setup.  I did use uscan and gbp as requested.  My main machine runs
> Ubuntu trusty and I think you might be relying on a feature that was
> only introduced later.  I noticed now that I do get an error like
> 
> $ uscan --report
> uscan warning: unrecognised option repacksuffix=+dfsg
> $

I see, then it seems that this older version of uscan does not build
reproducible tarballs yet. Take a look at the output of `file`; for
the trusty tarball it shows a gzip timestamp, for the tarball created
on Debian unstable it does not. (This and an empty gsm/ directory with
a deviating timestamp led me to assume that the tarball was manually
packed for some reason.)

pristine-tar has a peculiar issue with the latest two tarballs:

  # pristine-tar commit ../twinkle_1.10.1+dfsg.orig.tar.gz
  xdelta: warning: no matches found in from file, patch will apply without it
  xdelta: warning: no matches found in from file, patch will apply without it
  xdelta: warning: no matches found in from file, patch will apply without it
  xdelta: warning: no matches found in from file, patch will apply without it
  xdelta: warning: no matches found in from file, patch will apply without it
  warning: pristine-gz cannot reproduce build of ../twinkle_1.10.1+dfsg.orig.tar.gz; storing 85% size diff in delta (979743 bytes)
  (Please consider filing a bug report so the delta size can be improved.)
  pristine-tar: committed twinkle_1.10.1+dfsg.orig.tar.gz.delta to branch pristine-tar

As you can see from the pristine-tar branch, both the 1.10.0 and 1.10.1
tarballs were committed in full (~1 MB). I am reporting a bug against
pristine-tar, but so far I have no idea what could be the reason.

> BTW, "Explicitly build depend on libucommon-dev" has a very different
> meaning from "Explicitly build-depend on libucommon-dev".  It should
> have been the latter in the changelog but too late now.

Perfect, you are even more picky than me.

My apologies for not pinging you for review before uploading the package.

Again, I was unsure of what to expect from you since you suddenly
reappeared after 7 months of silence (#814396), had not done any
work on the package but wished to be added to Uploaders, and did
not comment on any of my suggestions.

After reading your reply I am confident that you will be a reliable
maintainer of twinkle. So, if you don’t mind, how about we ping each
other for review before uploading twinkle? With, say, a wait time of
at most a week if the other maintainer does not reply? I suggest you
also have your DM bit set for twinkle so you can upload yourself.

Best regards,
Peter