Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12966 > unrolled thread

help with FTBFS bug due to python3.8/3.9 confusion

Back to article view | Back to linux.debian.maint.python

Contents

  help with FTBFS bug due to python3.8/3.9 confusion Stephen Sinclair <radarsat1@gmail.com> - 2020-10-26 09:00 +0100
    Re: help with FTBFS bug due to python3.8/3.9 confusion Andrey Rahmatullin <wrar@debian.org> - 2020-10-26 11:00 +0100

#12966 — help with FTBFS bug due to python3.8/3.9 confusion

Hello Debian Python members,

I am looking into a bug in a Debian Science package that I maintain
and need some information.  It is a C++ library with a complicated
CMake setup that also produces a Python binding via swig.

Recently a FTBFS bug was filed against the package because apparently
it does not select the right Python after the introduction of Python
3.9.

The bug report can be found here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972394

The recommendations are to change the build-dep on "python-dev" to
"python-all-dev", and I can confirm that this does allow the package
to build.  (Is this the right thing to do?)

However, autopkgtest tests still fail.  The commenter in that bug
report claims, "the lack of 3.8 modules in the package also explains
your problem."  However, I do not understand that claim -- wouldn't it
be counter-productive to specify which minor version of Python the
package depends on?  I would need to update this manually when the
default switches to Python 3.9.

Although the CMake build is quite complicated and therefore I can
expect such problems, but I am nonetheless confused why it would
select the wrong Python version, as I do specify the Python executable
via the command,

> -DPYTHON_EXECUTABLE=$(shell which python3)"

Is there a better way to find the path to the default python interpreter?

kind regards,
Steve

[toc] | [next] | [standalone]

#12968

[Multipart message — attachments visible in raw view] — view raw

On Mon, Oct 26, 2020 at 08:54:37AM +0100, Stephen Sinclair wrote:
> The recommendations are to change the build-dep on "python-dev" to
> "python-all-dev", and I can confirm that this does allow the package
> to build.  (Is this the right thing to do?)
Building a module for all supported Python versions is a right thing to
do.

> However, autopkgtest tests still fail.  The commenter in that bug
> report claims, "the lack of 3.8 modules in the package also explains
> your problem."  However, I do not understand that claim -- wouldn't it
> be counter-productive to specify which minor version of Python the
> package depends on?  I would need to update this manually when the
> default switches to Python 3.9.
If you are packaging a public module you need to provide it for all
supported Python versions.
Not sure which tests fail and how, I don't think this is described
anywhere?

> Although the CMake build is quite complicated and therefore I can
> expect such problems, but I am nonetheless confused why it would
> select the wrong Python version, as I do specify the Python executable
> via the command,
> 
> > -DPYTHON_EXECUTABLE=$(shell which python3)"
> 
> Is there a better way to find the path to the default python interpreter?
When building a public module you don't need to care about the default
version.

-- 
WBR, wRAR

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web