Discussion:
Bug#942663: apparmor b-d's on python3-all-dev, but only builds for the default version
(too old to reply)
Matthias Klose
2019-10-19 19:30:01 UTC
Permalink
Package: src:apparmor
Version: 2.13.3-5
Severity: important
Tags: sid bullseye

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
intrigeri
2019-11-02 15:20:01 UTC
Permalink
Hi Matthias,
Post by 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.

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

Did I misunderstand something?

Cheers,
--
intrigeri
Matthias Klose
2019-11-03 09:20:01 UTC
Permalink
Post by intrigeri
Hi Matthias,
Post by 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
- src:apparmor's debian/rules does try to build for all
supported python3's
./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.
- "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.
Post by intrigeri
- 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.
Post by intrigeri
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
intrigeri
2019-11-08 08:40:01 UTC
Permalink
Control: fixed -1 2.13.3-6

Hi Matthias,
Post by Matthias Klose
I still think there is some bug, either upstream or in the packging which
doesn't propagate the exit code.
I totally agree there was such a bug in 2.13.3-5.

I believe said bug was fixed in 2.13.3-6 via #943649 (for the exit
code) and #943657 (for fixing the build against python 3.8).

I've crudely patched debian/{control,rules} to install the needed
python3.8 bits, and emulate a "py3versions -s" that would return
"python3.7 python3.8". The resulting python3-libapparmor package
contains:

./usr/lib/python3/dist-packages/LibAppArmor/_LibAppArmor.cpython-37m-x86_64-linux-gnu.so
./usr/lib/python3/dist-packages/LibAppArmor/_LibAppArmor.cpython-38-x86_64-linux-gnu.so

… which seems correct to me.

So, if this bug is still a thing in 2.13.3-6, please explain :)

Cheers,
--
intrigeri
Loading...