[Pkg-zsh-devel] zsh-syntax-highlighting 0.6.0~rc1-1 uploaded to mentors.debian.net

Tue Aug 1 00:15:39 UTC 2017

Axel Beckert wrote on Tue, Aug 01, 2017 at 01:43:01 +0200:
> Hi Daniel,
> 
> Daniel Shahaf wrote:
> > Good morning Axel,
> 
> Oh, ah, different time zones? 1:30 in the late night here. (Ok, can be
> considered morning technically.)
> 

In a manner of speaking, yes.  I was writing the greeting in UGT. :-)

> > > > It was a little trickier than I'd expected since I had to do a minor
> > > > history surgery (details in the log messages),
> > > 
> > > Indeed sounds hairy. But looks well solved to me. I like the verbose
> > > commit message with the ascii-art-ish history tree.
> > 
> > Verbose commit messages is a habit that was indoctrinated into me
> > early on.
> 
> Good habit, that. :-)
> 

It's from here: https://github.com/apache/subversion/commits/trunk

> > I didn't get any lintian warnings in my build.  My builds used to run
> > lintian automatically; I'll restore that behaviour.
> 
> Maybe it's also because I run lintian even with --pedantic?
> 

No, not that.

I think it's because my ~/.devscripts and ~/.sbuildrc are configured to
run lintian (with «--display-info --display-experimental --pedantic»),
but my ~/.pbuilderrc is not.  I'm looking into using a 'B' or 'I'
pbuilder hook to get pdebuild to run lintian automagically.  (Is there a
better way?)

When I ran lintian, it also complained about testsuite-autopkgtest-missing,
but that can't be fixed without patching the upstream test suite to run
against an installed tree.  Between that and the fact that you didn't
mention it in your email at all, I reckon it's not a priority.

> > > Some comments about the remaining lintian warnings:
> > > 
> > > I: zsh-syntax-highlighting source: debian-rules-parses-dpkg-parsechangelog (line 20)
> > > I: zsh-syntax-highlighting source: debian-rules-parses-dpkg-parsechangelog (line 21)
> > > 
> > > Lintian is probably right, but that's nothing urgent at all IMHO.
> > 
> > Will fix.

Fixed now.  (Not pushed yet.)

> > > P: zsh-syntax-highlighting source: debian-watch-may-check-gpg-signature
> > > 
> > > Mostly target towards upstream, but since you're also upstream...
> > > I'd sponsor it without a fix for that, nevertheless. But you might
> > > want to look into that at some point in the future. :-)
> > 
> > The upstream tag _is_ signed; the problem is just that debian/watch
> > doesn't check the signature.  Added to my list.
> 
> Well, yes and no. debian/watch can't check signed tags. It can just
> check detached signature files to tar balls, usually with the file
> suffix ".sig" or ".asc".

I'd looked at this before I read your reply, and planned to use a github
API for 'git tag -v', which seems to provide the information needed by
uscan(1):

	commit cd2952115e3723ae44eb9eee7decdca0a68a5895
	Author: Daniel Shahaf <d.s at daniel.shahaf.name>
	Date:   Mon Jul 31 22:57:05 2017 +0000

	    d/watch: Record plan for addressing lintian warning debian-watch-may-check-gpg-signature.

	diff --git a/debian/watch b/debian/watch
	index 0eb7e09..e6821c4 100644
	--- a/debian/watch
	+++ b/debian/watch
	@@ -1,4 +1,10 @@
	 # 'man uscan' for the format and usage of this file
	+#
	+# TODO: Re: lintian warning debian-watch-may-check-gpg-signature
	+#   Upstream signs tags.  It should be possible to retrieve & verify the
	+#   signatures on tag objects using the
	+#   <https://developer.github.com/v3/git/tags/#tag-signature-verification>
	+#   API, which is currently in beta.
	 version=3
	 opts=filenamemangle=s/.+\/(\d+\.\d+\.\d+)\.tar\.gz/zsh-syntax-highlighting-$1\.tar\.gz/ \
	 https://github.com/zsh-users/zsh-syntax-highlighting/tags .*/archive/(?:zsh-syntax-highlighting-)?(\d+\.\d+\.\d+)\.tar\.gz

(I haven't pushed that yet.)

Moreover, the _origtar d/rules target does verify the signature.
I think that at least partially addresses the lintian warning (although,
granted, it'd be preferable not to have to use a custom process).

> I noticed the signed tags btw. due to having this in my global
> .gitconfig:
> 
> [log]
>         showSignature = true

Good to know… but on my system (stretch), this only shows signatures
on commits, not on tags?

Also, that option is not completed by _git (probably because it's not
mentioned in git-config(1)).

> 
> > I'll fix the line length issue and try to upload rc1-2; if that
> > fails, I'll circle back and ask for a sponsored upload.
> 
> *nod*
> 
> I will be on the road the next two days on my way to SHA, so you might
> not get a quick response.
> 

No rush.  (& Have fun)

> > Quick question: the process for uploading to experimental is just to put
> > "experimental" in d/changelog before uploading, right?
> 
> Yes. And please check if the resulting .changes file contains a
> "Distribution: experimental" header afterwards.

Yes, it does.  Thanks for the heads up.

> > I.e., is the dput(1) invocation is identical for unstable and
> > experimental uploads? (I've checked maint-guide and
> > developers-reference.)
> 
> Yes. And if you use dput-ng instead of plain dput (same command,
> different package), it will also check for such glitches as the one
> mentioned above. (Not sure if the original dput gained support for
> such checks in the meanwhile, too.)
> 

I use dput-0.12.1.  I gather dput-ng is a drop-in replacement.  I should
probably upgrade, but it might break something…

> > Thanks for the detailed review.
> 
> Well, it didn't feel that detailed. But then again, the debdiff of
> non-upstream changes wasn't that big either. :-)

Yeah.  Upstream was relatively quiet, so I decided to cut a stable
release off master, and only after that to start merging some
outstanding feature branches.

Cheers,

Daniel