Bug 835432

I attach the outcome of fedora-review. Walking down the template should give you some hints on how to improve the package. Among other things, you should be able to silence rpmlint completely here IMHO.

Just out of the top of my head it feels that the source files in /usr/share might be better off under /include in this case, something like /usr/include/cxx/src. After all, these sources are indeed development files. One path less to track... but it's really a special case.

I'm no sponsor, so...

Created attachment 594412 [details]
Outcome of fedora-review tool

Hi John,

welcome to fedora. We have a sponsorship process and detailed information on that: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Esp. you should take a look onto: 
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_packages 
and do some "informal" reviews.

Hi Alec, would you mind pasting your review into the ticket itself, so it's easier for other users to read?

Hi fellas,

Thanks for all the initial comments, very helpful.  I've been trying to figure out where that fedora-review came from.  I found docs for how to fix the problems, but none for what tool generated them in the first place.

I went back and fixed all the errors from fedora-review and rpmlint (this time including the installed package).  One warning I couldn't quite get was about the BuildRoot tag:  the specfile clearly has one.  I rechecked some docs and compared to other packages, but don't see what the problem is.

There's a new SRPM and specfile up at the same link.  A new koji scratch build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=4198057

(In reply to comment #1)
> Just out of the top of my head it feels that the source files in /usr/share
> might be better off under /include in this case, something like
> /usr/include/cxx/src. After all, these sources are indeed development files.
> One path less to track... but it's really a special case.

Yeah, /usr/include/cxx/src is a good idea, and something does need to be done about it.  Putting files in /usr/share/python2.7/cxx violates the Pkging Guidelines because no package owns /usr/share/python2.7, and it doesn't make sense for python-pycxx to own that directory.

Maybe this needs to be taken up with upstream.  I'd think these ought to be compiled for the arch and put into a static lib like %{_libdir}/pycxx.a.

Another option is to put the uncompiled sources in /usr/src/pycxx, but I haven't found a precedent for that, outside of the kernel (PlanetCCRMA does this with rt-tests, but I haven't investigated).

A complaint I have about headers in /usr/include/python2.7 is that these include files should be good for any python v.2.  That may not matter if the python minor version is guaranteed not to change within any Fedora release.

Unless you're planning on building for EL5, you don't need a BuildRoot tag anyway. If you are building for EL5 then maybe conditionalize it "%if 0%{?el5}..."

rpmlint is now silent (note: I removed Buildroot, you may want to use a conditional if you need to build for EL5.)

https://dl.dropbox.com/u/34775202/python-pycxx.spec

(In reply to comment #4)
> Hi Alec, would you mind pasting your review into the ticket itself, so it's
> easier for other users to read?

I normally do. In this case it was just the raw output from fedora-review, so I thought it not so interesting for others besides John. If/when I do a complete review (not planned) i would certainly paste it.(In reply to comment #5)

(In reply to comment #5)
> I've been trying to
> figure out where that fedora-review came from.  I found docs for how to fix
> the problems, but none for what tool generated them in the first place.

$ yum info fedora-review
$ sudo yum install fedora-review  :)

However, I use a git snapshot which is a considerable update from 0.1.3. A new release is under way.

(In reply to comment #9)
> (In reply to comment #5)
> > I've been trying to
> > figure out where that fedora-review came from.  I found docs for how to fix
> > the problems, but none for what tool generated them in the first place.
> 
> $ yum info fedora-review
> $ sudo yum install fedora-review  :)

Yeah, I found it once you typed 'fedora-review' above.  I usually see that output inlined on these tickets with no explanation of where it came from, so in my case, lucky you created an attachment instead of inlining.  ;)  Nice tool!

Created attachment 594636 [details]
Email from author:  suggestions for packaging

Hi fellas, I'm attaching an email from the author.  In summary, he discourages us from packaging PyCXX separately, and especially discourages my idea to pre-compile into arch-specific static libs.

He points out pycvs, a precedent for bundling PyCXX.  I tracked down the original Fedora review request where this same issue was discussed:

https://bugzilla.redhat.com/show_bug.cgi?id=428718#c12

Packaging binaries is out of the question.  If anyone has strong feelings about not packaging this separately, I'm ok with abandoning this.  Otherwise, I'll proceed with the current RPM.

I'll probably add a pkgconfig .pc file as Alec suggested here to make life easy for any other project maintainers who need this:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2300#c20

I would argue that this isn't a bundled library then. It's not intended to be built as a library. However, if this were used in other packages it still would mean having multiple copies of this in the repositories. 

I'm not a C programmer so I don't know how to investigate this myself (or really how to properly define the problem), but are all the functions provided by this "helper" non-library private? In other words, we don't expect that two programs using this software would/could somehow "collide"?

I'm looking at this link:

http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

In the rest of the document defines a 'library' very loosely.  It's pretty much any reusable code, whether compiled or not.

'Copylibs' are an exception; it sounds like they're snippets that are copied and pasted.  I don't think PyCXX qualifies.

Otherwise, none of other usual exceptions seem to apply.  There are no significant modifications to PyCXX that FreeCAD needs.  PyCXX is released separately from pysvn and released regularly.

If we want an exception, we can apply for one with FPC.  I'd need help with the argument; if one's not convinced himself, it's hard to convince others.  ;)

If we did decide to package this, it sounds like we would be supposed to file a duplicate library bug against the pysvn package.  I guess it wouldn't cause the maintainer too much grief since this package should be easy enough to point to.

Forgot to address this.

(In reply to comment #12)
> [...] are all the functions
> provided by this "helper" non-library private? In other words, we don't
> expect that two programs using this software would/could somehow "collide"?

The source files are statically linked into a binary executable or shared lib.  There's no main package, only a -devel package, for exactly this reason.  If two separate packages compiled and linked this code, there would be no difference at all if there was a single copy of the source files in a common location, or if there were two copies bundled in the respective source packages.

There seems to be no configuration for the software, so no opportunities for collision there.

There's a new specfile and RPM uploaded to the same links.

Updates:
- Install a pkg-config PyCXX.pc file
- Own /usr/share/python2.7/
- All rpmlint + fedora-review errors/warnings now silent

This takes care of all the issues I'm aware of.  Anyone up for a formal review?

    John

some drive by comments:

- imho, there's no need for obsoletes, there's no version to obsolete.
- buildrequires: python-devel should be python2-devel, or something like:
BuildRequires:  python2-devel
%if 0%{?with_python3}
BuildRequires:  python3-devel
%endif # if with_python3 

  https://fedoraproject.org/wiki/Packaging:Python#BuildRequires
- you should link your patches to tickets upstream, esp. you should put a comment to those patches, what they do or why they are required.
- your package python-%{modname} doesn't have %files:, it contains
[mrunge@mrungexp result]$ rpm -qlp python-pycxx-6.2.4-0.fc18.src.rpm 
pycxx-6.2.4.tar.gz
python-pycxx-6.2.4-change-include-paths.patch
python-pycxx-6.2.4-fix-indentation.patch
python-pycxx.spec

- there's python3 support built in, so you should package that too.

- compiler flags are not required for noarch packages, so either noarch, or compiler flags...

(In reply to comment #16)
> some drive by comments:
> 
> - imho, there's no need for obsoletes, there's no version to obsolete.

I did some searching and it doesn't exist in Fedora but it does on EL5. Perhaps it should be conditionalized if he intends to support EPEL?


> - buildrequires: python-devel should be python2-devel, or something like:
> BuildRequires:  python2-devel
> %if 0%{?with_python3}
> BuildRequires:  python3-devel
> %endif # if with_python3 

Yup, this will need to be fixed. I find it interesting though that the python template in rpmdev-newspec uses just python-devel.

(In reply to comment #15)
> There's a new specfile and RPM uploaded to the same links.
> 
> Updates:
> - Install a pkg-config PyCXX.pc file
> - Own /usr/share/python2.7/

I'm concerned about this one. I'm not sure anything but python should own a directly like that. Perhaps /usr/src was a good idea?

> This takes care of all the issues I'm aware of.  Anyone up for a formal
> review?

Wish I could, we still need to find you a sponsor. If you have time I'm sure one of the links from comment 3 will tell you to do informal review on other review requests. This would probably be the fastest route. If you can do a few and come back here and reference them that would help. Also, an alternative (or in addition to) might be to package something off the wish list that someone really wants.

In fact, I wonder if it would be a good idea to write to the devel list and mention you need sponsoring and are willing to package something a sponsor needs...

(In reply to comment #17)
> (In reply to comment #16)
> > some drive by comments:
> > 
> > - imho, there's no need for obsoletes, there's no version to obsolete.
> 
> I did some searching and it doesn't exist in Fedora but it does on EL5.
> Perhaps it should be conditionalized if he intends to support EPEL?

Richard, good catch! If this was mine, I'd drop support for EL5. A pretty spec would use a contitionalized obsolete, as Richard proposed.

Hi fellas,

New package:
http://www.zultron.com/static/2012/06/freecad/python-pycxx.spec
http://www.zultron.com/static/2012/06/freecad/python-pycxx-6.2.4-1.fc16.src.rpm

Bunch of changes:

- Python 3 package, 'python3-pycxx-devel', builds if '--with=python3'
  specified

- Header files installed into /usr/include/CXX.
  - Dedupes haders shared by python 2 and 3; but more important,
  - One python-version-independent pkg-config .pc file:
    'pkg-config --variable=includedir PyCXX' instead of '... Py3CXX' or 
    similar.
  - A precedent is numpy
  - If this is unacceptable, they can be moved back to 
    /usr/include/python<version>/CXX, and the pkg-config files split into
    'Py2CXX.pc' and 'Py3CXX.pc' or something equivalent

- Source files installed into /usr/src/CXX
  - Complies with FHS, though not much written about it
  - A precedent is dwm-user, which does very nearly the same thing
  - If this is unacceptable, they can be moved into the headers directory

- Lots of changes to setup.py; I hope these can be accepted upstream:
  - New patch merges old patch that converts tabs to spaces and fixes
    indentation
  - Headers and sources previously omitted are now installed by setup.py
    instead of through hackage in specfile (install_headers extended to
    handle subdirs)
  - Install only python2 or python3 code, as appropriate

I'll address some of the comments here.

(In reply to comment #16)
> - imho, there's no need for obsoletes, there's no version to obsolete.

'Obsoletes' tags removed.  I changed the package name from the old version in the Zultron repo, but I now see this is unnecessary.  BTW, I added the version to Obsoletes to silence a fedora-review warning.

> - buildrequires: python-devel should be python2-devel, or something like:
> BuildRequires:  python2-devel
> %if 0%{?with_python3}
> BuildRequires:  python3-devel
> %endif # if with_python3 
> 
>   https://fedoraproject.org/wiki/Packaging:Python#BuildRequires

Done.

> - you should link your patches to tickets upstream, esp. you should put a
> comment to those patches, what they do or why they are required.

Done.

> - your package python-%{modname} doesn't have %files:, it contains
> [mrunge@mrungexp result]$ rpm -qlp python-pycxx-6.2.4-0.fc18.src.rpm 
> pycxx-6.2.4.tar.gz
> python-pycxx-6.2.4-change-include-paths.patch
> python-pycxx-6.2.4-fix-indentation.patch
> python-pycxx.spec

Correct.  There's no regular package, only a -devel package.  Other packages linking this code don't require any extra library files or config files.

> - there's python3 support built in, so you should package that too.

Done.  'rpmbuild -ba python-pycxx.spec --with=python3' builds a python3-pycxx-devel package.

> - compiler flags are not required for noarch packages, so either noarch, or
> compiler flags...

Whoops, an artifact of the specfile I stole.  Removed.



(In reply to comment #17)
> [...]
> (In reply to comment #15)
> > - Own /usr/share/python2.7/
> 
> I'm concerned about this one. I'm not sure anything but python should own a
> directly like that. Perhaps /usr/src was a good idea?

Fixed, see above.  Agreed, /usr/src seems best, and /usr/share/python2.7 is abominal.

Whew!  Y'all are tough!  :)

(In reply to comment #19)
> Hi fellas,
> 
> New package:
> http://www.zultron.com/static/2012/06/freecad/python-pycxx.spec
> http://www.zultron.com/static/2012/06/freecad/python-pycxx-6.2.4-1.fc16.src.
> rpm

Ok, I plan to find some time tomorrow to work on the review!

 
> - Source files installed into /usr/src/CXX
>   - Complies with FHS, though not much written about it
>   - A precedent is dwm-user, which does very nearly the same thing
>   - If this is unacceptable, they can be moved into the headers directory

Sounds OK to me.

 
> (In reply to comment #17)
> > [...]
> > (In reply to comment #15)
> > > - Own /usr/share/python2.7/
> > 
> > I'm concerned about this one. I'm not sure anything but python should own a
> > directly like that. Perhaps /usr/src was a good idea?
> 
> Fixed, see above.  Agreed, /usr/src seems best, and /usr/share/python2.7 is
> abominal.
> 
> Whew!  Y'all are tough!  :)

Tough? This is just the informal review. Wait until I start the formal review :)

Mostly kidding there, the formal review is largely one giant checklist but I do occasionally find things I don't catch in a quick review. 

Or course one of the big differences with packaging for a distro vs. packaging for yourself is you have to be more rigorous and unambiguous because someone else might need to update your package and they may not have the intimate knowledge of the package and rely on a nice clean spec with good comments to minimize mistakes. This is especially important in packages like this which are unusual.

John, I've sponsored you.

Richard, just go ahead with the review.

Woo hoo, I'm a packager!  Thank you Matthias.

(In reply to comment #20)
> Or course one of the big differences with packaging for a distro vs.
> packaging for yourself is you have to be more rigorous and unambiguous
> because someone else might need to update your package and they may not have
> the intimate knowledge of the package and rely on a nice clean spec with
> good comments to minimize mistakes. This is especially important in packages
> like this which are unusual.

Yeah!  Like I said in comment #1, I've written packages for years, but only for my own repos.  You guys have helped me jump up a few levels in just a few days.

> Tough? This is just the informal review. Wait until I start the formal
> review :)

Bring it on!  ;)

Ok, here's the full review (using the handy fedora-review tool!) 

I also tried a --with=python3 build and it seemed to work as expected. Both the provides and requires seemed sane for both python2 and python3. 

One note, there seems to be a typo in the Source0: tag...
Source0:        http://prdownloads.sourceforge.net/cxx/%{modname}-%{version}.tar.gz
should be:
Source0:        http://downloads.sourceforge.net/cxx/%{modname}-%{version}.tar.gz

I'm not going to hold up the review since it's a simple fix.

Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated



==== C/C++ ====
[x]: MUST Header files in -devel subpackage, if present.
[x]: MUST Package does not contain any libtool archives (.la)
[x]: MUST Package does not contain kernel modules.
[x]: MUST Package contains no static executables.
[x]: MUST Rpath absent or only used for internal libs.
[x]: MUST Package is not relocatable.


==== Generic ====
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[-]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
[-]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
     Note: Unless packager wants to package for EPEL5 this is fine
[x]: MUST Package contains no bundled libraries.
[x]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: Clean would be needed if support for EPEL is required
[x]: MUST Sources contain only permissible code or content.
[x]: MUST Each %files section contains %defattr if rpm < 4.4
     Note: Note: defattr macros not found. They would be needed for EPEL5
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[x]: MUST Package requires other packages for directories it uses.
[-]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Fully versioned dependency in subpackages, if present.
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf would be needed if support for EPEL5 is required
[-]: MUST Large documentation files are in a -doc subpackage, if required.
[x]: MUST If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %doc.
[x]: MUST License field in the package spec file matches the actual license.
[x]: MUST License file installed when any subpackage combination is installed.
[x]: MUST Package consistently uses macros (instead of hard-coded directory
     names).
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generate any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[!]: MUST Package requires pkgconfig, if .pc files are present. (EPEL5)
     Note: Only applicable for EL-5
[-]: MUST Requires correct, justified where necessary.
[!]: MUST Rpmlint output is silent.

rpmlint python-pycxx-6.2.4-1.fc18.src.rpm

python-pycxx.src: W: invalid-url Source0: http://prdownloads.sourceforge.net/cxx/pycxx-6.2.4.tar.gz timed out
1 packages and 0 specfiles checked; 0 errors, 1 warnings.


rpmlint python-pycxx-devel-6.2.4-1.fc18.noarch.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
/home/build/835432/pycxx-6.2.4.tar.gz :
  MD5SUM this package     : e2500da3ab64cdba7ce5756945c30f91
  MD5SUM upstream package : e2500da3ab64cdba7ce5756945c30f91

[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: MUST Package contains a SysV-style init script if in need of one.
[x]: MUST File names are valid UTF-8.
[-]: MUST Useful -debuginfo package or justification otherwise.
[x]: SHOULD Reviewer should test that the package builds in mock.
[-]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it.
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: SHOULD Package functions as described.
[x]: SHOULD Latest version is packaged.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[x]: SHOULD Patches link to upstream bugs/comments/lists or are otherwise
     justified.
[x]: SHOULD The placement of pkgconfig(.pc) files are correct.
[x]: SHOULD SourceX / PatchY prefixed with %{name}.
[x]: SHOULD SourceX is a working URL.
[-]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[-]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[x]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[x]: SHOULD Spec use %global instead of %define.

Issues:
[!]: MUST Package requires pkgconfig, if .pc files are present. (EPEL5)
     Note: Only applicable for EL-5
See: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#EL5
[!]: MUST Rpmlint output is silent.

rpmlint python-pycxx-6.2.4-1.fc18.src.rpm

python-pycxx.src: W: invalid-url Source0: http://prdownloads.sourceforge.net/cxx/pycxx-6.2.4.tar.gz timed out
1 packages and 0 specfiles checked; 0 errors, 1 warnings.


rpmlint python-pycxx-devel-6.2.4-1.fc18.noarch.rpm

1 packages and 0 specfiles checked; 0 errors, 0 warnings.


See: http://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint


Generated by fedora-review 0.1.3

*** APPROVED ***

Hi Richard,

Thanks for the review!

(In reply to comment #23)
> One note, there seems to be a typo in the Source0: tag...
> Source0:       
> http://prdownloads.sourceforge.net/cxx/%{modname}-%{version}.tar.gz
> should be:
> Source0:       
> http://downloads.sourceforge.net/cxx/%{modname}-%{version}.tar.gz

(Funny, the 'prdownloads' link actually works for me (no timeout), but looking at SF's CXX pages, the 'downloads' link is the one I see.)

Fixed, new links:

http://www.zultron.com/static/2012/06/freecad/python-pycxx.spec
http://www.zultron.com/static/2012/06/freecad/python-pycxx-6.2.4-0.fc16.src.rpm

Hi Richard,

Thanks for the review!

(In reply to comment #23)
> One note, there seems to be a typo in the Source0: tag...
> Source0:       
> http://prdownloads.sourceforge.net/cxx/%{modname}-%{version}.tar.gz
> should be:
> Source0:       
> http://downloads.sourceforge.net/cxx/%{modname}-%{version}.tar.gz

(Funny, the 'prdownloads' link actually works for me (no timeout), but looking at SF's CXX pages, the 'downloads' link is the one I see.)

Fixed, new links:

http://www.zultron.com/static/2012/06/freecad/python-pycxx.spec
http://www.zultron.com/static/2012/06/freecad/python-pycxx-6.2.4-2.fc16.src.rpm

(Whoops, diregard comment 24, incorrect link; comment 25 is correct)

(In reply to comment #24)
> (Funny, the 'prdownloads' link actually works for me (no timeout), but
> looking at SF's CXX pages, the 'downloads' link is the one I see.)

It's probably just sourceforge fixing the link in the background...


> http://www.zultron.com/static/2012/06/freecad/python-pycxx.spec
> http://www.zultron.com/static/2012/06/freecad/python-pycxx-6.2.4-2.fc16.src.
> rpm

No need to post new links at this point. If everything on your end is setup you should be able to set the CVS flag at the top of this bug to "?" and post your SCM request. Don't forget to add Matthais as a maintainer in your request.

Don't worry about changing the status on the bug. When you get all your builds done and submit the packages in bodhi, there will be a field to put this bug # in. Bodhi will automatically change the status as your packages work their way into the stable repos.

New Package SCM Request
=======================
Package Name: python-pycxx
Short Description: Write Python extensions in C++
Owners: zultron
Branches: f16 f17
InitialCC: hobbes1069

New Package SCM Request
=======================
Package Name: python-pycxx
Short Description: Write Python extensions in C++
Owners: zultron mrunge
Branches: f16 f17
InitialCC: hobbes1069

Don't forget Matthias!

New Package SCM Request
=======================
Package Name: python-pycxx
Short Description: Write Python extensions in C++
Owners: zultron mrunge
Branches: f16 f17
InitialCC: hobbes1069

Oops, hope this works.

Git done (by process-git-requests).

The koji builds are done, and I'm just compiling FreeCAD against them once more to be sure everything looks good here.

Then I'll push them into bodhi.  Any recommendations for how much karma to require?  It's hard to imagine I'll be able to get more than one person to actually try it out.  :)

Usually I would leave it at the default which means it has to sit in the testing repos for a week, however, as freecad is the only package that will use this currently, setting it to 1 would be OK. Since it's not ethical to +1 it yourself :) I'll do it once I have the chance to check it out.

python-pycxx-6.2.4-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-pycxx-6.2.4-2.fc17

python-pycxx-6.2.4-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/python-pycxx-6.2.4-2.fc16

python-pycxx-6.2.4-2.fc17 has been pushed to the Fedora 17 testing repository.

Already done.

python-pycxx-6.2.4-2.fc17 has been pushed to the Fedora 17 stable repository.

python-pycxx-6.2.4-2.fc16 has been pushed to the Fedora 16 stable repository.

Package Change Request
======================
Package Name: python-pycxx
New Branches: el6
Owners: zultron hobbes1069
InitialCC: 

Rebuilding this package for EPEL.

Git done (by process-git-requests).

Package Change Request
======================
Package Name: python-pycxx
New Branches: epel7
Owners: zultron hobbes1069
InitialCC:

Git done (by process-git-requests).