Bug 1120256 - [patch] make libcap-ng buildable with python3
Summary: [patch] make libcap-ng buildable with python3
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libcap-ng
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-16 14:41 UTC by Bohuslav "Slavek" Kabrda
Modified: 2015-05-08 22:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-08 22:55:37 UTC


Attachments (Terms of Use)
Make libcap-ng buildable with python3 (1.07 KB, patch)
2014-07-16 14:41 UTC, Bohuslav "Slavek" Kabrda
no flags Details | Diff

Description Bohuslav "Slavek" Kabrda 2014-07-16 14:41:46 UTC
Created attachment 918442 [details]
Make libcap-ng buildable with python3

Hi, I'm attaching a simple patch to fix libcap-ng builds with Python 3.X. The problem is that Python builds since 3.2 started adding so called "abi flags" to include dirs names, as specified in upstream PEP [1]. For example, standard Fedora python3 build has include dir /usr/include/python3.Xm. The safest way to get include dir is to ask Python for it, which is what this patch does. Note that this patch *is* backwards compatbile with Python 2.X.
AFAICS everything else should work fine, since SWIG generates python3-enabled code by default - it'd be nice if you could accept this patch and add libcap-ng-python3 subpackage. Thanks!

[1] http://legacy.python.org/dev/peps/pep-3149/

Comment 1 Steve Grubb 2014-07-20 13:40:17 UTC
Thanks for the patch. How does this work? When compiled on a python3 system, does it produce both python3 and python2 files? Why would a python3 subpackage be needed? I don't really follow python programming at all and am not sure what the supporting spec file changes might be.

This is in upstream commit #60.

Comment 2 Bohuslav "Slavek" Kabrda 2014-07-29 14:53:40 UTC
So, let me elaborate a bit:
There's an accepted systemwide Fedora change to make Python 3 the default Python interpreter in Fedora 22 [1]. That means two different things for different kinds of packages:
- "applications" (e.g. packages that are supposed to be used directly by Fedora users) should switch from Python 3 to Python 2 if possible
- "libraries" (e.g. something that other libraries/applications import and is not directly runnable) should start providing python3-* subpackages to be importable in Python 3
- Python 2 and Python 3 have different load paths and are not binary compatbile, so in the second case ("library", which applies to libcap-ng) both python- and python3- subpackages should be provided, so that people can use libraries on both interpreters.

The above means, that where possible, Python bindings should be built twice during rpmbuild and python3- subpackage (libcap-ng-python3 in your case) should be provided.
In term of specfile changes, I guess it's easier to build libcap-ng twice, once with
./configure PYTHON=%{__python2}
and once with
./configure PYTHON=%{__python3}

The motivation for libcap-ng specifically is, that it's on LiveCD and our primary target with [1] is to only have Python 3 on LiveCD - meaning that we need libcap-ng to provide python3 subpackage.
Hope this answers the questions - feel free to ask more if not!

[1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default

Comment 3 Steve Grubb 2014-08-23 19:22:15 UTC
Hi, I was doing some testing on RHEL6. Libcap-ng now fails to build by crashing in configure:

checking whether to create python bindings... testing
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.6/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.6/site-packages
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named sysconfig
configure: error: Python explicitly required and python headers found

Do you have any idea what was wrong? This is the patch:

https://fedorahosted.org/libcap-ng/changeset?reponame=&new=60%40trunk&old=59%40trunk

Comment 4 Bohuslav "Slavek" Kabrda 2014-08-25 13:35:14 UTC
(In reply to Steve Grubb from comment #3)
> Hi, I was doing some testing on RHEL6. Libcap-ng now fails to build by
> crashing in configure:
> 
> checking whether to create python bindings... testing
> checking for python... /usr/bin/python
> checking for python version... 2.6
> checking for python platform... linux2
> checking for python script directory... ${prefix}/lib/python2.6/site-packages
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.6/site-packages
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named sysconfig
> configure: error: Python explicitly required and python headers found
> 
> Do you have any idea what was wrong? This is the patch:
> 
> https://fedorahosted.org/libcap-ng/
> changeset?reponame=&new=60%40trunk&old=59%40trunk

Sorry, this is my mistake from the previous patch. "sysconfig" is not available as a module in Python 2.6. Instead of "import sysconfig", you should use "from distutils import sysconfig" (the rest stays the same). This works in Python 2.6, 2.7 and 3.X.

Comment 5 Steve Grubb 2014-08-29 21:03:53 UTC
OK. That fixed the problem. I confirm a good build on older OS. Thanks!

So, back in comment#2, it was mentioned that I would need to build the library twice. Is there another package that does this same thing? I am looking for an example. The project page doesn't really give any advice to packagers about how to do this or example spec file changes.

If I can work out the spec file changes, I'll go ahead and do a release and push it through the build system.

Comment 6 Bohuslav "Slavek" Kabrda 2014-09-01 14:22:07 UTC
Here's how the libpwquality maintainer has handled it [1].

More generally, there are some notes on python3- subpackages building in Python packaging guidelines [2]. The examples are Python extension modules (e.g. not libraries with Python bindings like in this case), but the approach applies to any package that is supposed to be built against both Python major versions.

Hope this helps and thanks!

[1] http://pkgs.fedoraproject.org/cgit/libpwquality.git/commit/?id=c57e81ff0077f481fa98a5d98f6d406c7deab9d0
[2] http://fedoraproject.org/wiki/Packaging:Python#Building_more_than_once

Comment 7 Bohuslav "Slavek" Kabrda 2014-12-03 07:29:41 UTC
Steve, is there anything else I can help with? It'd be really great if we could finish this and close the bug. Thanks!

Comment 8 Bohuslav "Slavek" Kabrda 2015-01-15 10:53:13 UTC
Ping, anything I can help with here?

Comment 9 Jaroslav Reznik 2015-03-03 17:03:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 10 Steve Grubb 2015-05-08 22:55:37 UTC
This turned out to be quite challenging. It was a combination of swig, autotools, and python3 that made it an unholy mess. In any event, its now built in rawhide.


Note You need to log in before you can comment on or make changes to this bug.