Bug 537366
Summary: | Review Request: cgal-python - Python bindings for the CGAL library | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paulo Roma Cavalcanti <promac> |
Component: | Package Review | Assignee: | Chen Lei <supercyper1> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, laurent.rineau__fedora, promac, supercyper1, tomspur |
Target Milestone: | --- | Flags: | supercyper1:
fedora-review?
laurent.rineau__fedora: needinfo- |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-06-04 13:22:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Paulo Roma Cavalcanti
2009-11-13 10:44:09 UTC
Just a few comments, because there is no src.rpm anymore... - Why do you package the pdf via self.downloading anyway? - Use BR: mpfr-devel and not libmpfr.so Some comments: BuildRequires need to be adjusted: python-devel >= 2.3 -> python2-devel gcc-c++ not needed libmpfr.so qt-devel boost-devel gmp-devel not needed (ship with CGAL-devel ) Fixed. SPEC URL: http://roma.fedorapeople.org/specs/cgal-python.spec SRPM URL: http://roma.fedorapeople.org/srpms/cgal-python-0.9.4-0.8.beta1.fc12.src.rpm Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2034791 gcc is failing on F13. It is really impressive ... (In reply to comment #4) > gcc is failing on F13. It is really impressive ... I currently ran under F-13, but here it's not failing... It completely freezes the system and I needed to to a hard reboot. I looked at 'top' and 80% of my little RAM was used by exactly the same file like in the scratch till the freeze was there. -> build above bindings/Geometric_Optimisation/Py_Min_ellipse_2.cpp ('My little RAM' is 4GB!!) Don't know, how I can further help with this... It compiles just fine on F12, F11 and F10, either directly or with mock. No problem at all. The culprit seems to be gcc/F13. This seems to be fixed already: https://bugzilla.redhat.com/show_bug.cgi?id=571051 Can we proceed with the review? Thanks. Confimed. Cleanly compiles now with the latest koji build http://koji.fedoraproject.org/koji/buildinfo?buildID=158875 (In reply to comment #7) > This seems to be fixed already: > https://bugzilla.redhat.com/show_bug.cgi?id=571051 > Can we proceed with the review? > Thanks. Still waiting gcc-4.4.3-8.fc13, since it doesn't push to the stable yet. It has been already moved to stable, and should work now. Thanks. (In reply to comment #10) > It has been already moved to stable, and should work now. > > Thanks. I'll try to reivew it this weekend, I'm busy those days. %{!?with_rhel:%{python_sitearch}/*.egg-info} Shoule be changed to :%{python_sitearch}/*.egg-info See https://fedoraproject.org/wiki/Packaging:Python_Eggs#Providing_Eggs_for_non-setuptools_packages %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} -> %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif (In reply to comment #12) > %{!?with_rhel:%{python_sitearch}/*.egg-info} > Shoule be changed to :%{python_sitearch}/*.egg-info > See > https://fedoraproject.org/wiki/Packaging:Python_Eggs#Providing_Eggs_for_non-setuptools_packages I see. There is a way of generating the egg-info for rhel, by using setuptools: ---------------------------------------- %build CFLAGS="$RPM_OPT_FLAGS" %{__python} -c 'import setuptools; execfile("setup.py")' build %install rm -rf $RPM_BUILD_ROOT %{__python} -c 'import setuptools; execfile("setup.py")' install --skip-build --root $RPM_BUILD_ROOT ---------------------------------------- Although I run cgal-python in rhel5, one has to build CGAL first, and I am not intending to take both packages to EPEL (I think CGAL is not part of EPEL yet). Therefore, I think that the use of setuptools for Fedora is unnecessary. But I can use it if you think it is better this way. > > %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > -> > %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print(get_python_lib())")} > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} > %endif This part I did not understand. Why the test? I do not even use python_sitelib. (In reply to comment #13) > (In reply to comment #12) > > %{!?with_rhel:%{python_sitearch}/*.egg-info} > > Shoule be changed to :%{python_sitearch}/*.egg-info > > See > > https://fedoraproject.org/wiki/Packaging:Python_Eggs#Providing_Eggs_for_non-setuptools_packages > I see. There is a way of generating the egg-info for rhel, by using setuptools: > ---------------------------------------- > %build > CFLAGS="$RPM_OPT_FLAGS" %{__python} -c 'import setuptools; > execfile("setup.py")' build > %install > rm -rf $RPM_BUILD_ROOT > %{__python} -c 'import setuptools; execfile("setup.py")' install --skip-build > --root $RPM_BUILD_ROOT > ---------------------------------------- > Although I run cgal-python in rhel5, one has to build CGAL first, and > I am not intending to take both packages to EPEL (I think CGAL is not part of > EPEL yet). > Therefore, I think that the use of setuptools for Fedora is unnecessary. > But I can use it if you think it is better this way. > > You should follow the item - "Providing Eggs for non-setuptools packages" to provide egg for rhel or simply remove %bcond_with rhel and %with_rhel macros. If you like, you can maintain CGAL for epel by "Package Change CVS Request" without package review. > > %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > -> > > %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) > > %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print(get_python_lib())")} > > %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} > > %endif > This part I did not understand. Why the test? I do not even use python_sitelib. See https://fedoraproject.org/wiki/Packaging:Python#Macros Well, I made the modifications and now the egg-info is being build for rhel5 too (I built for rhel 5 using the new spec). However, it is not clear for me whether I should use the setuptools for Fedora also, which just work the same way as before, or keep using the conditionals. What do you think? SPEC: http://roma.fedorapeople.org/specs/cgal-python.spec I will wait for your opinion before updating the .src.rpm Thanks. (In reply to comment #15) > Well, I made the modifications and now the egg-info is being build for > rhel5 too (I built for rhel 5 using the new spec). > However, it is not clear for me whether I should use the setuptools > for Fedora also, which just work the same way as before, or keep using the > conditionals. > What do you think? > SPEC: > http://roma.fedorapeople.org/specs/cgal-python.spec > I will wait for your opinion before updating the .src.rpm It'll be better to remove %bcond_with rhel and %{with rhel} macros and using %if ! (0%{?fedora} > 8 || 0%{?rhel} > 5) instead, the upcoming rhel6 will automatically generate egg-info files. You don't need BR:python-setuptools for fedora >8 || rhel >5. Thanks, Chen Lei I think that is it: SPEC: http://roma.fedorapeople.org/specs/cgal-python.spec SRPM: http://roma.fedorapeople.org/srpms/cgal-python-0.9.4-0.9.beta1.fc12.src.rpm The SRPM is good enough to pass the review. But koji build for devel/rawhide failed, cgal-python may be incompatible with CGAL-3.6-0.1.beta1. See http://koji.fedoraproject.org/koji/taskinfo?taskID=2126047 Paulo, Any updates in here? It is nearing a month day after tomorrow ? :) -- Regards, Rakesh Pandit Unfortunately, every time CGAL changes its API it takes a long time to appear a fix for cgal-python. What I do on my systems is create a compat-CGAL package for keeping running cgal-python with the previous version of CGAL, while having the newest version of CGAL installed: CGAL-3.6-1.fc12.x86_64 CGAL-demos-source-3.6-1.fc12.x86_64 CGAL-devel-3.6-1.fc12.x86_64 compat-CGAL-35-3.5.1-1.fc12.x86_64 I still have some applications that are not running correctly with CGAL-3.6 ... So, what you plan to do here? For information, cgal-python is deprecated in favor of the complete new project cgal-bindings: http://code.google.com/p/cgal-bindings/ (In reply to Laurent Rineau from comment #22) > For information, cgal-python is deprecated in favor of the complete new > project cgal-bindings: > http://code.google.com/p/cgal-bindings/ Paulo, I suggest you close that review request, and maybe submit a new one for cgal-bindings. Close this bug. It was stalled for one year and half. And anyway, the current Python bindings for CGAL are from cgal-bindings: https://github.com/CGAL/cgal-swig-bindings |