Bug 546266 - Review Request: python-ctypes - Create and manipulate C data types from Python
Summary: Review Request: python-ctypes - Create and manipulate C data types from Python
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: Package Review
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: beta
: 5.8
Assignee: Dan Horák
QA Contact:
URL:
Whiteboard:
Depends On: 632416
Blocks: 188273 545526 557062 601661 680163 681867 683304
TreeView+ depends on / blocked
 
Reported: 2009-12-10 15:07 UTC by Jiri Olsa
Modified: 2011-10-05 16:34 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-25 13:43:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jiri Olsa 2009-12-10 15:07:57 UTC
Spec URL: http://people.redhat.com/jolsa/python-ctypes/python-ctypes.spec
SRPM URL: http://people.redhat.com/jolsa/python-ctypes/python-ctypes-1.0.2-1.el5.src.rpm

Description: 
python-ctypes is a python module to create and manipulate C data types in
Python, and to call functions in dynamic link libraries/shared dlls.
It allows wrapping these libraries in pure Python.

Comment 1 Dan Horák 2009-12-16 13:19:58 UTC
formal review is here, see the notes below:

OK	source files match upstream:
	    7f77f2b507a50f292297831ee50e310037398e14  ctypes-1.0.2.tar.gz
OK	package meets naming and versioning guidelines.
OK	specfile is properly named, is cleanly written and uses macros consistently.
BAD	dist tag is present.
OK	build root is correct.
OK	license field matches the actual license.
OK	license is open source-compatible (MIT). License text included in package.
OK	latest version is being packaged.
OK	BuildRequires are proper.
OK	compiler flags are appropriate.
OK	%clean is present.
OK	package builds in mock (Rawhide/x86_64).
OK	debuginfo package looks complete.
BAD	rpmlint is silent.
OK	final provides and requires look sane.
N/A	%check is present and all tests pass.
OK	no shared libraries are added to the regular linker search paths.
OK	owns the directories it creates.
OK	doesn't own any directories it shouldn't.
OK	no duplicates in %files.
BAD	file permissions are appropriate.
OK	no scriptlets present.
OK	code, not content.
OK	documentation is small, so no -docs subpackage is necessary.
OK	%docs are not necessary for the proper functioning of the package.
OK	no headers.
OK	no pkgconfig files.
OK	no libtool .la droppings.
OK	not a GUI app.

- hardcoded .el5 instead of %{?dist}
- rpmlint complains a bit
python-ctypes.x86_64: W: executable-stack /usr/lib64/python2.4/site-packages/_ctypes.so
    => probably a result of using hand-coded assembler code, for a fix see http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/rpms/s390utils/RHEL-5/0011-s390-tools-1.8.1-execstack.patch
python-ctypes.x86_64: E: non-standard-executable-perm /usr/lib64/python2.4/site-packages/_ctypes_test.so 0775
python-ctypes.x86_64: E: non-standard-executable-perm /usr/lib64/python2.4/site-packages/_ctypes.so 0775
    => 0755 is expected, either do a chmod in %install or use %attr in %files
- the package contains and uses a copy of the libffi library, a system copy should be used (doesn't exist in RHEL5) or it should be packaged separately

Comment 2 Jiri Olsa 2010-01-14 13:03:50 UTC
Is it necessary to create libffi package? Here are some arguments to keep it inside python-ctypes pkg:

- the python-ctypes package is only for need of iotop
- python-ctypes is included in the python > 2.4 so there's no need for this pkg in RHEL6 and forward
- python-ctypes is not actualy building the libffi library, it takes some of the objects and compiles them into ctypes.so extension


jirka

Comment 3 Jiri Olsa 2010-01-14 13:04:55 UTC
Is it necessary to create libffi package? Here are some arguments to keep it inside python-ctypes pkg:

- the python-ctypes package is only for need of iotop
- python-ctypes is included in the python > 2.4 so there's no need for this pkg in RHEL6 and forward
- python-ctypes is not actualy building the libffi library, it takes some of the objects and compiles them into ctypes.so extension


jirka

Comment 4 Bill Nottingham 2010-01-14 15:55:28 UTC
Ugh. So, in the past, we've had packages build their own libffi until a system one was packaged, as the ffi maintainers didn't want it packaged until recently.

My biggest concern is that if it's not actually using the library, but only objects from the library, that it would require a lot of contortions to get it to use the library proper.

Comment 5 Dan Horák 2010-01-20 14:28:49 UTC
Ok, then let the ffi "library" be part of the python-ctypes package, no need to complicate things too much.

Jiri, please fix the remaining issues.

Comment 7 Dan Horák 2010-02-01 15:51:53 UTC
All issues are fixed, but use the default %defattr(-,root,root,-) on the imported package. And I would use chmod 0755 %{python_sitearch}/*.so in %install instead of the explicit %attr, but that's just my preference.

This package is APPROVED.

Comment 9 Dave Malcolm 2010-08-02 15:26:30 UTC
BTW, has this been tested with SELinux?  In the version of ctypes in our python rpms we patch ctypes somewhat to avoid mapping pages as both writable and executable (which would otherwise lead to an AVC denial, IIRC).

Comment 10 Larry Troan 2010-08-03 21:56:39 UTC
Missed 5.6. Do we push to 5.7 or CLOSE=WONTFIX for RHEL5?

Comment 14 RHEL Program Management 2011-05-31 14:02:24 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 15 Larry Troan 2011-07-18 08:27:44 UTC
Pushed to 5.8 for consideration.

Comment 16 Lukáš Nykrýn 2011-08-24 10:21:02 UTC
(In reply to comment #9)
> BTW, has this been tested with SELinux?  In the version of ctypes in our python
> rpms we patch ctypes somewhat to avoid mapping pages as both writable and
> executable (which would otherwise lead to an AVC denial, IIRC).

Is there some detail info about this problem? There is a patch in RHEL-6, which is called python-2.6-ctypes-noexecmem, but it is incompatible with this version of ctypes, so do I need to backport it?

Comment 17 Dave Malcolm 2011-08-24 19:17:20 UTC
(In reply to comment #16)
> (In reply to comment #9)
> > BTW, has this been tested with SELinux?  In the version of ctypes in our python
> > rpms we patch ctypes somewhat to avoid mapping pages as both writable and
> > executable (which would otherwise lead to an AVC denial, IIRC).
> 
> Is there some detail info about this problem? There is a patch in RHEL-6, which
> is called python-2.6-ctypes-noexecmem, but it is incompatible with this version
> of ctypes, so do I need to backport it?

[CCing dwalsh]

This was added due to bug 488396, which is this upstream bug:
  http://bugs.python.org/issue5504

(see also bug 522731).

Comment 18 Dan Horák 2011-08-25 13:43:56 UTC
closing per #5 in https://home.corp.redhat.com/wiki/package-list-process#rhel5-add

Comment 19 Linda Wang 2011-10-05 16:34:07 UTC
correction: closing per #6 in 
https://home.corp.redhat.com/wiki/package-list-process#rhel5-add


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