https://bugzilla.redhat.com/show_bug.cgi?id=835432
Bug ID: 835432 QA Contact: extras-qa@fedoraproject.org Severity: medium Version: rawhide Priority: unspecified CC: notting@redhat.com, package-review@lists.fedoraproject.org Assignee: nobody@fedoraproject.org Summary: Review Request: <main package name here> - <short summary here> Regression: --- Story Points: --- Classification: Fedora OS: Linux Reporter: john@zultron.com Type: --- Documentation: --- Hardware: All Mount Type: --- Status: NEW Component: Package Review Product: Fedora
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.... 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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
John Morris john@zultron.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |john@zultron.com Version|rawhide |16
https://bugzilla.redhat.com/show_bug.cgi?id=835432
John Morris john@zultron.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |177841 (FE-NEEDSPONSOR)
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Ankur Sinha (FranciscoD) sanjay.ankur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sanjay.ankur@gmail.com Summary|Review Request: <main |Review Request: |package name here> - <short |python-pycxx - Write Python |summary here> |extensions in C++
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Alec Leamas leamas.alec@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leamas.alec@gmail.com
--- Comment #1 from Alec Leamas leamas.alec@gmail.com --- 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...
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #2 from Alec Leamas leamas.alec@gmail.com --- Created attachment 594412 --> https://bugzilla.redhat.com/attachment.cgi?id=594412&action=edit Outcome of fedora-review tool
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Matthias Runge mrunge@matthias-runge.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrunge@matthias-runge.de Version|16 |rawhide
--- Comment #3 from Matthias Runge mrunge@matthias-runge.de --- 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#R... and do some "informal" reviews.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Ken Dreyer ktdreyer@ktdreyer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ktdreyer@ktdreyer.com
--- Comment #4 from Ken Dreyer ktdreyer@ktdreyer.com --- Hi Alec, would you mind pasting your review into the ticket itself, so it's easier for other users to read?
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #5 from John Morris john@zultron.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #6 from John Morris john@zultron.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #7 from Richard Shaw hobbes1069@gmail.com --- 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}..."
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #8 from Richard Shaw hobbes1069@gmail.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #9 from Alec Leamas leamas.alec@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #10 from John Morris john@zultron.com --- (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!
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #11 from John Morris john@zultron.com --- Created attachment 594636 --> https://bugzilla.redhat.com/attachment.cgi?id=594636&action=edit 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
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #12 from Richard Shaw hobbes1069@gmail.com --- 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"?
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #13 from John Morris john@zultron.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #14 from John Morris john@zultron.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #15 from John Morris john@zultron.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #16 from Matthias Runge mrunge@matthias-runge.de --- 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...
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #17 from Richard Shaw hobbes1069@gmail.com --- (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...
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #18 from Matthias Runge mrunge@matthias-runge.de --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #19 from John Morris john@zultron.com --- 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....
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! :)
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #20 from Richard Shaw hobbes1069@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Matthias Runge mrunge@matthias-runge.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks|177841 (FE-NEEDSPONSOR) |
--- Comment #21 from Matthias Runge mrunge@matthias-runge.de --- John, I've sponsored you.
Richard, just go ahead with the review.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #22 from John Morris john@zultron.com --- 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! ;)
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Richard Shaw hobbes1069@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|nobody@fedoraproject.org |hobbes1069@gmail.com Flags| |fedora-review+
--- Comment #23 from Richard Shaw hobbes1069@gmail.com --- 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/%%7Bmodname%7D-%%7Bversion%7D.tar.gz should be: Source0: http://downloads.sourceforge.net/cxx/%%7Bmodname%7D-%%7Bversion%7D.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 ***
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #24 from John Morris john@zultron.com --- 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/%%7Bmodname%7D-%%7Bversion%7D.tar.gz should be: Source0: http://downloads.sourceforge.net/cxx/%%7Bmodname%7D-%%7Bversion%7D.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....
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #25 from John Morris john@zultron.com --- 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/%%7Bmodname%7D-%%7Bversion%7D.tar.gz should be: Source0: http://downloads.sourceforge.net/cxx/%%7Bmodname%7D-%%7Bversion%7D.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....
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #26 from John Morris john@zultron.com --- (Whoops, diregard comment 24, incorrect link; comment 25 is correct)
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #27 from Richard Shaw hobbes1069@gmail.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
John Morris john@zultron.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-cvs?
--- Comment #28 from John Morris john@zultron.com --- New Package SCM Request ======================= Package Name: python-pycxx Short Description: Write Python extensions in C++ Owners: zultron Branches: f16 f17 InitialCC: hobbes1069
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #29 from Richard Shaw hobbes1069@gmail.com --- 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!
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #30 from John Morris john@zultron.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #31 from Jon Ciesla limburgher@gmail.com --- Git done (by process-git-requests).
https://bugzilla.redhat.com/show_bug.cgi?id=835432
John Morris john@zultron.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs+ |fedora-cvs?
--- Comment #32 from John Morris john@zultron.com --- 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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #33 from Richard Shaw hobbes1069@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #34 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #35 from Fedora Update System updates@fedoraproject.org --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |ON_QA
--- Comment #36 from Fedora Update System updates@fedoraproject.org --- python-pycxx-6.2.4-2.fc17 has been pushed to the Fedora 17 testing repository.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #37 from Jon Ciesla limburgher@gmail.com --- Already done.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed| |2012-07-07 17:53:31
--- Comment #38 from Fedora Update System updates@fedoraproject.org --- python-pycxx-6.2.4-2.fc17 has been pushed to the Fedora 17 stable repository.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #39 from Fedora Update System updates@fedoraproject.org --- python-pycxx-6.2.4-2.fc16 has been pushed to the Fedora 16 stable repository.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
John Morris john@zultron.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-cvs?
--- Comment #40 from John Morris john@zultron.com --- Package Change Request ====================== Package Name: python-pycxx New Branches: el6 Owners: zultron hobbes1069 InitialCC:
Rebuilding this package for EPEL.
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #41 from Jon Ciesla limburgher@gmail.com --- Git done (by process-git-requests).
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Richard Shaw hobbes1069@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs+ |fedora-cvs?
--- Comment #42 from Richard Shaw hobbes1069@gmail.com --- Package Change Request ====================== Package Name: python-pycxx New Branches: epel7 Owners: zultron hobbes1069 InitialCC:
https://bugzilla.redhat.com/show_bug.cgi?id=835432
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs? |fedora-cvs+
https://bugzilla.redhat.com/show_bug.cgi?id=835432
--- Comment #43 from Jon Ciesla limburgher@gmail.com --- Git done (by process-git-requests).
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla