[Pkg-electronics-devel] gnucap package.

Tue Mar 6 09:56:56 UTC 2018

Hello Felix,

further down my new comments on your recent modifications and work.

Am 06.03.2018 um 01:25 schrieb Felix Salfelder:
> Dear Carsten.
> 
> Thanks a lot for your feedback.
> 
>> Thanks for taking care of this package, I had a quick view into the tree.
>> First of all, two important technical points I see with the tree you
>> have given.
> 
>> It is missing a tag [..] then signed tagged as '0.36_20171003'.
> 
> done.
> 
>> Next the pristine-tar commit is also missing for this upstream version
>> in the git tree too. You just need to call
>>
>>> $ pristine-tar commit ../gnucap_0.36~20171003.orig.tar.gz
> 
> oh yes, i forgot to push pristine-tar.. (done)

Does this package has a preferred packaging workflow method? E.g. like
dgit or git-buildpackage? Even if not it would be helpful for possible
other contributers to document this in debian/README.source. Also the
specific circumstances about the upstream releasing and development can
be added to that file.

The git tree seems to have the classical minimal three branches for
Debian packaging, there is master, upstream and pristine-tar.
Is there a reason why the branch upstream isn't up2date with the tag
upstream/0.36_20171003? Also why there are various commit which looks
like they are clearly upstream related in contrary the git tree is based
on the upstream Git tree? This is so far no problem, but typically you
would have a git tree with imported upstream releases or you would use
the upstream tree with additional added Debian specific branches. No
matter which model you prefer you should think about moving over to
DEP14. It's "just" a draft but widely used in between times.

http://dep.debian.net/deps/dep14/

I personally would also run wrap-and-sort on the Debian folder to
improve the readability of the sequencer files.

It's probably also fine if you add yourself to the Uploader field,
otherwise all Uploads need to be done as NMUs. Looking at the history of
the changes in the upstream branch you are much more and deeper in the
source than any other person so I see no reason why you shouldn't add
yourself to the uploaders.

Another things I'd like to suggest, please be a bit more verbose on your
commit messages. Especially third persons (like me) are depending on a
good declarative commit message to get your intention for the commits in
a really short amount of time.

E.g. your fix up commit a547260c, "default plugins: depend on
${shlibs:Depends}"

This is a bit misleading, you don't depend on ${shlibs:Depends}, you
have (re)added this variable to the list off dependencies. Why you have
(re)added this? I'd say because of it was wrongly removed in e39521ea,
so please add this to the commit message.

Also ec0b37f3, "bump standards version"

Why you have done this, why no further changes are needed. The policy
version hasn't just increased about a micro version.

All these information is later interesting while preparing the final
changelog entry and people who installing the package (or want to
install it) will use this as the only source of information want was
done in the packaging and why.

> $ wrap-and-sort -ast

[...]
>>> I: gnucap source: debian-rules-parses-dpkg-parsechangelog (line 4)
> 
> fixed.

Hmm, shouldn't DEB_VERSION_EPOCH_UPSTREAM provide the version you are
looking for?

>>> I: gnucap source: out-of-date-standards-version 3.9.8 (released 2016-04-06) (current is 4.1.3)
> 
> fixed, no further changes necessary imu.

As written above, I haven't look at this in detail, writing that no
further changes are needed and some details why are helpful for
reviewing and other contributors.

>>> I: gnucap source: testsuite-autopkgtest-missing
>>
>> Can be ignored for now.
> 
> good. the testsuite is subject to numerical noise and not meant to be
> ran unsupervised. that will not change anytime soon..

This tag is not about a testsuite the package source is probably
providing, it's more about testing within the Debian specific things.
Typical things here you can do is testing the installation the your
packages, the functionality of the binaries or libraries (think about
testing of linking against your library, the usability of development
files and symbols), testing of virtual packages and so on.

>>> I: gnucap source: debian-watch-uses-insecure-uri http://gnucap.org/archive/gnucap-(.*)\.tar\.gz
>>
>> It's the same as the first tag from that list.
> 
> i have suspended the watch file, considering the release frequency.
> 
> when upstream changed to git, no more tarballs have been uploaded. the
> releases/snapshots have just been tagged since while the versioning
> scheme has changed to plain ddmmyyyy.
> 
> i kept 0.36~ddmmyyyy for the moment, as i can't really tell if there
> will be a 0.37 some day. it's a bit odd, yet consistent with the
> previous upload.

I wouldn't have removed the watch file, it does not hurt to keep it and
releasing isn't about only the VCS system. Once a new release will
happen you can easily see this on the tracker site or on your dashboard
site. If there is no https available this tag can be overridden then.

[...]
>>> I: libgnucap0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libgnucap.so.0
>>
>> Can be done but needs a bit of deeper knowledge.
> 
> yes. i would like to postpone this. chances are, upcoming library
> versions (rare!) will be incompatible and symbols files will not really
> help.

The creation of the symbols file isn't that difficult, but as the source
is the C++ based symbols will change with every modification of the C++
compiler so the symbols files hasn't a big win like for classical C
files. But yes, can be added later.

You now have a new lintian warning about a needed higher version of
debhelper in the Build-Depends due your commit about increasing
debian/compat which had be increased to 11 directly. You should fix the
B-D accordingly.

I'm wondering a bit why lintian isn't complaining about the URL for the
value of the Format key. The URL should be using https and pointing to
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Consider to adjust this too in further modifications.

Again a word to the VCS URLs, Alioth will be shut down in a few weeks or
months. And there will be no automatic switch over of the existing
repositories. So it's up to a person to move the trees over to Salsa. As
nobody other person than you is currently taking care about this package
so the person who will need to do $something is you. :-)
I think it makes sense to move the tree to Salsa right now, maybe with
some additional clean up and rebasing if you like as long as no new
version was uploaded to the archive. Or in a first doing put it into
your personal name space on Salsa. But better would be to place it again
under the hood of the pkg-electronics team in my eyes.

So to summarize the things I'd do on your side:

* document the packaging workflow
* considering a branch layout based on DEP14
* add yourself to the uploaders
* try to be more detailed on commit messages
* evaluate the usability of DEB_VERSION_EPOCH_UPSTREAM in debian/rules
* bump compat and debhelper to version 11
* check entry for Format field in the copyright file
* prepare a movement of the tree to Salsa, maybe drop the various
  commits on the upstream branch if possible and rebase the trees

-- 
Regards
Carsten Schoenert