[Pkg-electronics-devel] Processed: python3.6

[Felix Salfelder]

Hi Carsten.

Thanks for your feedback.

On Wed, Jan 16, 2019 at 08:50:39PM +0100, Carsten Schoenert wrote:
[..]
> The following patch archives the same behavior but increases the
> readability of debian/rules a bit.
> 
> > [..]
> > -usr/share/doc/gnucap-python/NEWS
> > +NEWS
> > [..]
> > -       cp NEWS debian/tmp/usr/share/doc/gnucap-python/NEWS

done.

> You will need to the quite the same again once Python3.8 will the
> default Python3 version in Debian.
> [..]
> So it's better to use the virtual package python3-dev here instead of
> python3.7-dev! Look at the dependencies of python3-dev.
> The same is valid for the Python2 version here, just use python-dev

I made this change.

> Some more suggestions.
> Have a look at the output of the Lintian QS tool, it helps you find QA
> issues you probably not see directly.
> 
> > $ lintian -IE
> [..]
> 
> Lintian warnings should really be investigated and fixed, the first
> informative issue is also easy to fix, just check if you need to do
> further QA work because of the current actual policy and increase the
> S-V if ready. I assume you don't need to do anything to be able to do so.
> 
> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-3-0

bumped to 4.3.0. There are no additional Lintian warnings induced by
that change.

> The package holds a git-buildpackage configuration file but it seem you
> do most of the work manually. Do you know the option 'dch' for creating
> or updating the changelog file?

I can see d/gbp.conf, and yes, I should try and use dch more often than
not. But what is the connection between those?

> The package is using debhelper 11, we are right in the beginning of the
> freeze. The current version is 12, time to update?
> 
> https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/

It says "We generally recommand (sic) you defer migrating to compat 12
until bullseye". AFAIU the migration does affect the compression of
example files, and not much more. I wouldn't mind to migrate, but please
override the quoted recommendation.

> Consider to order the Build-Depends entries alphabetical, it helps to
> find packages in question more quickly (or not).

I ran wrap-and-sort.

> The tracker website is mentioning that gnucap-python could be marked
> Multi-Arch: same.

makes sense. done.

FWIW: I also found the "Problems while searching for a new upstream
version" in the tracker. The watch file is beyond me. Unfortunately the
tarballs are not on a proper fileserver but buried somewhere on
gitlab.com.

> dpkg-shlibdeps is printing really a lot of warnings! You will need to
> tune the creation of the dependencies by modify this target in the rules
> file. Just have a look at existing packages what this for similar
> reasons and also have a look into the man page(s). The most of these
> warnings are probably from used symbols found in private libs.

Many times dpkg-shlibdeps warns "it's probably a plugin", but that's
obviously right. The manual says "If the binary is really a plugin, then
disregard this warning". Not sure how to proceed from here.

> The comment in debian/rules seems more to explain the used hack than a
> correct solution. I guess other package maintainer of python bindings
> have the same or similar problems to solve. So looking into other
> packages should give some inspiration or at show people that can be asked.

Ideally there would be another package implementing something like
gnucap-python. While I agree that it *should* exist, I couldn't find it.
Such a package would have made things easier from the beginning.

For the record, the workaround in question, that lead to the "hack" in
d/rules goes back to the way python import wraps dlopen. Upon importing
a shared object into a python session, libraries that the object links
to are reinstanciated. Here (in gnucap/__init__.py) this can lead to
several instances of libgnucap. Usually, this is not an issue, as python
bindings are one way: You start a python session, then import some
module, the module loads a library, and you get (exactly) one instance
of that library. But then, gnucap-python also does it the other way
round: You run a gnucap session (A) and load a python extension that
imports gnucap-python (B) from within that session. Both (A) and (B)
must share an instance of libgnucap for this to possibly work. Hence the
nonstandard PyDLL.dlopen kludge simulating linkage.

Obviously, dh cannot detect the shared library dependency in the
PyDLL.dlopen call, leave alone the actually intended SONAME dependency.
To me, it seems to be an unfortunate combination of python avoiding
RTLD_GLOBAL, and bidirectional wrappers requiring exactly that
(coincidently just POSIX). If this is wrong, then it had to be addressed
upstream, making the hack obsolete. But I am not an expert, sure I am
interested in any hints or references.

thanks
felix