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

[Felix Salfelder]

On Thu, Jan 17, 2019 at 07:55:38AM +0100, Carsten Schoenert wrote:
> man gbp-dch

thanks for the suggestion. will dig into that on occasion.

> [..]
> bump to dh 12 would work.
> [..]
> It's a bit test and try. You already get debhelper in version 12

good. done.

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

thank you.

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

I looked closer and it actually found 3 warnings about unnecessary -ldl.
This will be fixed in 0.0.3, i put in a workaround.

2 more are about debian/tmp.out, "the hack".

- binaries to analyze should already be installed
    but it's not, because it is the hack file.
- package could avoid a useless dependency
    no. these are the only purpose of the hack

nothing sensible i can do about these.

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

I used "dh_shlibdeps -- -v" to see all of them.

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

I don't understand. there is a private library, libgnucap-python.so with
a hand full of symbols. dh_shlibdeps warnings does not mention these. To
be sure, I then uninstalled libgnucap-python.so, and they still resolve,
hinting that dh is doing the right thing.

the other symbols are all either libgnucap or python (unless i am
missing an outlier).

I am still convinced that "it's probably a plugin" correctly describes
the situation and that the manual is right in disregarding these
warnings. What else could I do? the whole intent is to resolve these
symbols when loading the plugin.

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

Which i think is the correct behaviour. afaict, there is no package
dependency implied by these symbols.

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

the excessive amount of warnings unfortunate. But i am not any better
than the manual, suggesting to ignore it. Perhaps the good news is that
there are no binary dependencies beyond the obvious python, numpy and
gnucap, and this is very unlikely to change.

> 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

good to know. However, -l will only help resolving local symbols, such
as in private libraries, which do not seem to be the issue.

> Maybe someone here on the list can give further pointing, otherwise
> debian-python will be the right place for getting in contact.

I am totally interested, but i have to postpone it.

Thanks a lot.
felix