Bug 835432 - Review Request: python-pycxx - Write Python extensions in C++
Review Request: python-pycxx - Write Python extensions in C++
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Richard Shaw
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-26 03:37 EDT by John Morris
Modified: 2014-05-28 06:27 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-07 17:53:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
hobbes1069: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)
Outcome of fedora-review tool (12.46 KB, text/plain)
2012-06-26 05:38 EDT, Alec Leamas
no flags Details
Email from author: suggestions for packaging (3.22 KB, text/plain)
2012-06-26 19:49 EDT, John Morris
no flags Details

  None (edit)
Description John Morris 2012-06-26 03:37:48 EDT
Spec URL: http://www.zultron.com/static/2012/06/freecad/python-pycxx.spec
SRPM URL: http://www.zultron.com/static/2012/06/freecad/python-pycxx-6.2.4-0.fc16.src.rpm
Description: Write Python extensions in C++
Fedora Account System Username: zultron

PyCXX is used by FreeCAD, an RPM currently under review in RPMFusion:

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

Here's a --scratch build of this package:

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

This is my first review request, so I'll need a sponsor.  However, I'm an old hand at some of this stuff.  I've run my own repo for years at http://www.zultron.com/rpm-repo/ ; all the packages there were built from my own koji instance; I've had patches accepted into the koji source; and a recent package to make it into Fedora, zipios++, was my package that someone else helped get through the review process.

What I do need help with is complying with the Fedora Packaging Guidelines.  When one runs his own repo, there's no such thing.  ;)  I've done my best with this specfile, and the package passes rpmlint, but I'm sure I'll learn some things in this process.
Comment 1 Alec Leamas 2012-06-26 05:37:10 EDT
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...
Comment 2 Alec Leamas 2012-06-26 05:38:25 EDT
Created attachment 594412 [details]
Outcome of fedora-review tool
Comment 3 Matthias Runge 2012-06-26 05:41:36 EDT
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.
Comment 4 Ken Dreyer 2012-06-26 10:18:51 EDT
Hi Alec, would you mind pasting your review into the ticket itself, so it's easier for other users to read?
Comment 5 John Morris 2012-06-26 13:45:41 EDT
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
Comment 6 John Morris 2012-06-26 13:58:43 EDT
(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.
Comment 7 Richard Shaw 2012-06-26 14:34:52 EDT
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}..."
Comment 8 Richard Shaw 2012-06-26 15:40:36 EDT
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
Comment 9 Alec Leamas 2012-06-26 16:23:53 EDT
(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.
Comment 10 John Morris 2012-06-26 17:58:10 EDT
(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!
Comment 11 John Morris 2012-06-26 19:49:34 EDT
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
Comment 12 Richard Shaw 2012-06-26 22:12:06 EDT
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"?
Comment 13 John Morris 2012-06-27 00:00:53 EDT
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.
Comment 14 John Morris 2012-06-27 00:14:59 EDT
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.
Comment 15 John Morris 2012-06-27 03:13:50 EDT
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
Comment 16 Matthias Runge 2012-06-27 04:47:49 EDT
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...
Comment 17 Richard Shaw 2012-06-27 13:25:30 EDT
(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...
Comment 18 Matthias Runge 2012-06-27 15:13:44 EDT
(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.
Comment 19 John Morris 2012-06-28 16:20:11 EDT
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!  :)
Comment 20 Richard Shaw 2012-06-28 21:46:00 EDT
(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.
Comment 21 Matthias Runge 2012-06-29 02:33:32 EDT
John, I've sponsored you.

Richard, just go ahead with the review.
Comment 22 John Morris 2012-06-29 02:52:48 EDT
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!  ;)
Comment 23 Richard Shaw 2012-06-29 12:47:54 EDT
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 ***
Comment 24 John Morris 2012-06-29 13:39:27 EDT
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
Comment 25 John Morris 2012-06-29 13:39:58 EDT
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
Comment 26 John Morris 2012-06-29 13:41:51 EDT
(Whoops, diregard comment 24, incorrect link; comment 25 is correct)
Comment 27 Richard Shaw 2012-06-29 13:46:49 EDT
(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.
Comment 28 John Morris 2012-06-29 13:51:39 EDT
New Package SCM Request
=======================
Package Name: python-pycxx
Short Description: Write Python extensions in C++
Owners: zultron
Branches: f16 f17
InitialCC: hobbes1069
Comment 29 Richard Shaw 2012-06-29 13:56:50 EDT
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!
Comment 30 John Morris 2012-06-29 14:03:30 EDT
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.
Comment 31 Gwyn Ciesla 2012-06-29 14:06:25 EDT
Git done (by process-git-requests).
Comment 32 John Morris 2012-06-29 16:18:52 EDT
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.  :)
Comment 33 Richard Shaw 2012-06-29 16:20:58 EDT
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.
Comment 34 Fedora Update System 2012-06-29 18:31:27 EDT
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
Comment 35 Fedora Update System 2012-06-29 18:31:33 EDT
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
Comment 36 Fedora Update System 2012-06-30 17:48:23 EDT
python-pycxx-6.2.4-2.fc17 has been pushed to the Fedora 17 testing repository.
Comment 37 Gwyn Ciesla 2012-07-01 18:43:49 EDT
Already done.
Comment 38 Fedora Update System 2012-07-07 17:53:31 EDT
python-pycxx-6.2.4-2.fc17 has been pushed to the Fedora 17 stable repository.
Comment 39 Fedora Update System 2012-07-07 17:56:01 EDT
python-pycxx-6.2.4-2.fc16 has been pushed to the Fedora 16 stable repository.
Comment 40 John Morris 2012-10-18 13:54:09 EDT
Package Change Request
======================
Package Name: python-pycxx
New Branches: el6
Owners: zultron hobbes1069
InitialCC: 

Rebuilding this package for EPEL.
Comment 41 Gwyn Ciesla 2012-10-18 14:19:39 EDT
Git done (by process-git-requests).
Comment 42 Richard Shaw 2014-05-27 10:54:00 EDT
Package Change Request
======================
Package Name: python-pycxx
New Branches: epel7
Owners: zultron hobbes1069
InitialCC:
Comment 43 Gwyn Ciesla 2014-05-28 06:27:01 EDT
Git done (by process-git-requests).

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