[Debian-med-packaging] Bug#1001657: Ball fails its autopkgtest - how to properly deal with sip files?

[Nilesh Patra]

On 15 December 2021 2:36:14 pm IST, Andreas Tille <andreas at fam-tille.de> wrote:
>Hi Étienne,
>
>Am Tue, Dec 14, 2021 at 11:13:21PM +0100 schrieb Étienne Mollier:
>> Étienne Mollier, on 2021-12-14:
>> > However, once the sip file is caught, the package fails to build
>> > from source due to various errors in the generated code.  The
>> > patch also addresses one of them in its second hunk.  I think I
>> > was stuck on some "overrides" related errors, but they were
>> > interleaved within sip output, I can send a proper log later
>> > this week after an overnight build if needed.
>> 
>> I forgot I had one other patch to address PyString issues, part
>> of the ftbfs.  And also forgot to mention that I had to enforce
>> -DSIP_LIBRARIES=/usr/lib/python3/dist-packages from the cmake
>> call in d/rules.
>> 
>> In hope this helps,
>
>May be you can simply push your patches to make sure everything is
>stored visibly.
>
>What I'm currently wondering is the following:  According to popcon[1]
>python3-ball has 2 votes and its only dependency ballview has 10 votes.
>This makes no real sense if ballview would really need python3-ball.

Based on the package description, python3-ball has the "python bindings" for the library packages.
ballview does not seem to use the python bindings at all (as you'd normally expect).

The python package is probably available for the case if you want to use the library itself in the python code and use it programmatically.
The upstream wiki page seems to concur:

https://github.com/BALL-Project/ball/wiki/BALLPythonScripting

But I have no idea if these bindings are of any use. We can only know when someone who knows the software well can tell. 
So I'll echo the same thing you wrote below. Steffen to clarify :-

>Upstream does not seem to be active any more but may be Steffen (in
>CC) can clarify this.