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

Étienne Mollier emollier at emlwks999.eu
Wed Dec 15 20:42:00 GMT 2021


Hi Andreas, Hi Nilesh, Hi Steffen,

Interesting, my overnight build resulted in the following
failure to build from source, which mismatches what I was
recalling:

	/<<PKGBUILDDIR>>/source/PYTHON/EXTENSIONS/BALL/file.sip: In function ‘int convertTo_OpenMode(PyObject*, void**, int*, PyObject*)’:
	/<<PKGBUILDDIR>>/source/PYTHON/EXTENSIONS/BALL/file.sip:74:25: error: ‘PyInt_Check’ was not declared in this scope; did you mean ‘PySet_Check’?
	   74 |                 return (PyInt_Check(sipPy) || BALL_IS_SUBCLASS_INSTANCE(sipPy, OpenMode));
	      |                         ^~~~~~~~~~~
	      |                         PySet_Check
	/<<PKGBUILDDIR>>/source/PYTHON/EXTENSIONS/BALL/file.sip:76:13: error: ‘PyInt_Check’ was not declared in this scope; did you mean ‘PySet_Check’?
	   76 |         if (PyInt_Check(sipPy))
	      |             ^~~~~~~~~~~
	      |             PySet_Check
	/<<PKGBUILDDIR>>/source/PYTHON/EXTENSIONS/BALL/file.sip:78:28: error: ‘PyInt_AS_LONG’ was not declared in this scope; did you mean ‘PyLong_AS_LONG’?
	   78 |                 int mode = PyInt_AS_LONG(sipPy);
	      |                            ^~~~~~~~~~~~~
	      |                            PyLong_AS_LONG

I haven't investigated further but it seems that a somewhat
recent upload of sip /could/ have fixed some of the issues I
have been running in a few months ago.  The logged errors look
not too convoluted for someone comfortable with python bindings.

Nilesh Patra, on 2021-12-15:
>On 15 December 2021 2:36:14 pm IST, Andreas Tille <andreas at fam-tille.de> wrote:
> > May be you can simply push your patches to make sure everything is
> > stored visibly.

Pushed, Thanks for the nudge.  (Sorry, I couldn't push yesterday
for dumb reasons.)

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

This was my perception of the situation when I tried to make
use of ballview myself, to make sure the software was operating
properly without all the python3 bindings.

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

Have a nice day,  :)
-- 
Étienne Mollier <emollier at emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20211215/82a0abfe/attachment-0001.sig>


More information about the Debian-med-packaging mailing list