On 02.11.19 16:15, intrigeri wrote:
Hi Matthias,
Matthias Klose:
apparmor b-d's on python3-all-dev, but only builds for the default version. This
makes it harder to prepare python transitions. Please build for all supported
python versions.
Example build log at
https://launchpad.net/ubuntu/+source/apparmor/2.13.3-5ubuntu2/+build/17926986
My understanding of this build log is that:
- src:apparmor's debian/rules does try to build for all
supported python3's
- The build for python 3.8 fails with:
./libraries/libapparmor.python3.8/conftest.c:18: undefined reference to
`Py_Initialize'
As you noted in another bug report, this should fail the build
(set -e) but does not. I've applied your patch in sid so I hope
it's now fixed, as in: this specific failure should now make the
package FTBFS, which is more correct feedback.
- The build for python 3.7 succeeds.
So, it seems to me that:
- "only builds for the default version" is incorrect, this bug
report is therefore invalid, and should be closed.
well, it appears so, when looking at the binary package produced.
- src:apparmor fails to build for python 3.8, which is itself
a bug. I'll report it right away so it's tracked.
FTR, the call to Py_Initialize seems to come from
libraries/libapparmor/m4/ac_python_devel.m4 in upstream Git;
it can also be found in libraries/libapparmor/configure
in the upstream tarball (bold guess: the former is used to
generate the later at upstream release time).
yes, however you should not try to build an embedded interpreter when the only
thing you are doing is to test for the buildability of an extension module.
Did I misunderstand something?
I still think there is some bug, either upstream or in the packging which
doesn't propagate the exit code.
Matthias
