[Pkg-electronics-devel] gnucap package.

[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)

> > I: gnucap source: vcs-field-uses-insecure-uri vcs-git git://anonscm.debian.org/pkg-electronics/gnucap.git
>
> [..] Take a look at existing packages on Salsa.

i have put https://anonscm.debian.org/git/pkg-electronics/gnucap.git, is
this acceptable? i don't know when/how pkg-electronics will move to
salsa, but i could relocate the package if/when this happens.

> > I: gnucap source: debian-rules-parses-dpkg-parsechangelog (line 4)

fixed.

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

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

> > 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: libgnucap0: hardening-no-bindnow usr/lib/x86_64-linux-gnu/libgnucap.so.0
> > I: gnucap-default-plugins0: hardening-no-bindnow usr/lib/x86_64-linux-gnu/gnucap0/gnucap-default-plugins.so
> > I: gnucap: hardening-no-bindnow usr/bin/gnucap
> > I: gnucap: hardening-no-bindnow usr/bin/gnucap-modelgen
> 
> Can also be ignored for now.

ok.

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

> >> I: libgnucap0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libgnucap.so.
> > W: gnucap-default-plugins0: missing-depends-line
> 
> That's a serious problem which needs to be fixed, otherwise the plugins
> may be not usable because of not added needed depended libraries for
> using them.
>
> You will need to add a override for dh_shlibdeps in debian/rules and add
> the needed call so dh_shlibdeps can find the needed dependencies. Have a
> look at the man page and existing packages on Salsa e.g. kopanocore

${shlibs:Depends} was missing in the plugin dependencies (fixed). now i get

Depends: libc6 (>= 2.14), libgcc1 (>= 1:4.0), libstdc++6 (>= 5.2)

which looks correct to me.

> If you have further question please tell us, if the package is more
> clean we can talk about sponsoring.

that sounds promising. let me know what you need or disagree with.

best regards
felix