[Pkg-electronics-devel] gnucap package.

[Felix Salfelder]

Hello Carsten.

On Tue, Mar 06, 2018 at 10:56:56AM +0100, Carsten Schoenert wrote:
> > 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.

i have added a README.source. the preferred workflow is "as simple as
possible". there is not much traffic here, as most functionality is (and
will be) implemented as plugins.

> Also the specific circumstances about the upstream releasing and
> development can be added to that file.

done.

> The git tree seems to have the classical minimal three branches for
> Debian packaging, there is master, upstream and pristine-tar.

yes.

> Is there a reason why the branch upstream isn't up2date with the tag
> upstream/0.36_20171003?

on my end "upstream" and the tag are at 519303bf34ef0b2d. (strange?)

> 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.

the upstream repo is based on the ancient debian packageing repo,
because that was the only repo out there.  at that time, upstream only
used a non-public CSV, and the releases were provided as tarballs.  the
packageing "upstream" branch with the tarball imports became the
upstream "master" branch.

i prefer to keep the upstream repo within the packageing repo (avoiding
tarball ex/imports).

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

some of this seems to be about (much) more complex cases. i can dig into
this more. please point out things i am getting completely wrong.

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

nice! never heard of that. (i do not have a strong opinion on flags,
hence used the default)

> 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.

done.

> 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.

i have rebased everything in the course of moving to salsa. lots of
changes were related to intermediate releases that have never been
uploaded. this is mostly gone now.

> 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.

generally, there are no changes required relative to the previous
uploads, as the package now looks entirely different. if it fails to
meet some standard, then not because i have bumped the version.

anyway i have put a commit message with hints to the paragraphs in the
standard that seemed relevant within the bump range.

> 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.

> >>> 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?

revisited. i like it better now.

> >>> I: gnucap source: testsuite-autopkgtest-missing
> [..]
> 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 see. thanks for the explanation.

> 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.

done (overridden)

> 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.

I assume that this does not require a lintian override.

> 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.

fixed.

> 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.

done.

> But better would be to place it again
> under the hood of the pkg-electronics team in my eyes.

it's now in my personal salsa space [1]. i will move it to d-science or
pkg-electronics. whatever happens first.

> 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

done, unless i'm missing something.

thank you
felix

[1] https://salsa.debian.org/felixs-guest/gnucap.git