[Pkg-electronics-devel] preparation of gnucap-python 0.0.2-2 (Re: Processed: python3.6)

[Carsten Schoenert]

Hello Felix,

Am 17.01.19 um 03:52 schrieb Felix Salfelder:
...
> 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?

man gbp-dch

If you want to use this and some other functionality of gbp is of course
up to you. I wont live without that tool anymore, it saves a lot of time
on my side and also a lot of keyboard hacking.

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

You are the maintainer of your package, you should know best what your
build setup is doing and how your build environment is working and how a
bump to dh 12 would work.

Given the experience I've made with dh 12 so far your package isn't that
special corner case (e.g. exotic build system, non typical paths, ...)
that it would not work or break. And if not, well if nobody is starting
to use newer versions we wouldn't have tester for new features.

It's a bit test and try. You already get debhelper in version 12
installed so it's one file you need to change and test. I always try to
update the packages before the final hard freeze to recent versions of
the Debian tools.

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

I've run 'uscan --no-download --verbose' locally and the output was
fine. Sometimes the service behind this watch check seems to be not
working as expected. No hard problem, but you wont see potential
packages that would benefit from a version update in your maintainer
site probably.

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

You need to read a bit between the lines I guess.

There are some lines that referring a symbol that is made of C++ code,
these symbols must come from your package and if not would mean some
other package is shipping library with unsolvable symbols with would be
serious issue of course.

To solve this you need to tell dh_shlibdeps were this symbol can be
found, I bet within your private libs.

The other messages about all these symbols from the Python libraries are
similar. dh_shlibdeps don't know were these symbols can be found because
it ha no information where to search for them.

Finally you get a high risk that at least one dependency is missing the
the control section for your binary packages.

You can use sources.debian.net to find package which also use a manually
call of dh_shlibdeps.

https://codesearch.debian.net/search?q=dh_shlibdeps+-a+-l

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

I'm also not an expert about Python C/C++ bindings and I can't give a
useful suggestion on this specif thing here. But thankfully Debian has
some really experienced people about this topic and that why I suggested
to get in contact with them. Maybe someone here on the list can give
further pointing, otherwise debian-python will be the right place for
getting in contact.

https://lists.debian.org/debian-python/

In the end "the hack" you have used isn't that problematic, I'm a bit
more concerned about the massive warnings of dpkg-shlibs.

-- 
Regards
Carsten Schoenert