Bug 527462 - Review Request: gmpy - Python interface to GMP
Summary: Review Request: gmpy - Python interface to GMP
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Susi Lehtola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-06 13:49 UTC by Michael J Gruber
Modified: 2010-12-01 21:57 UTC (History)
3 users (show)

Fixed In Version: gmpy-1.14-1.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-01 21:54:41 UTC
Type: ---
susi.lehtola: fedora-review+
tibbs: fedora-cvs+


Attachments (Terms of Use)
SPEC file (744 bytes, application/octet-stream)
2010-11-08 14:46 UTC, Michael J Gruber
no flags Details

Description Michael J Gruber 2009-10-06 13:49:04 UTC
SPEC URL:
http://mjg.fedorapeople.org/rpmdev/python-gmpy.spec
(based on mandriva version 1.01-3)

SRPM URL:
http://mjg.fedorapeople.org/rpmdev/python-gmpy-1.04-1.fc11.src.rpm

Upstream URL:
http://code.google.com/p/gmpy/

Description:
The General Multiprecision PYthon project (GMPY) focuses on
Python-usable modules providing multiprecision arithmetic
functionality to Python programmers. The project mission includes both
C and C++ Python-modules (for speed) and pure Python modules (for
flexibility and convenience); it potentially includes integral,
rational and floating-point arithmetic in any base. Only
cross-platform functionality is of interest, at least for now.

Additional comments:
python-mpmath (in review) makes use of gmpy when present. This speeds up the mpmath unit tests by a factor 2.3 for me. Of course, gmpy is of independent interest (e.g. standalone, sage).

Comment 1 Michael J Gruber 2009-10-06 13:50:16 UTC
Yet another additional comment:
I'm a noob regarding package submission, please guide me through if necessary...

Comment 2 Susi Lehtola 2009-10-06 14:51:25 UTC
OK, I'll take the review.

Comment 3 Susi Lehtola 2009-10-06 15:05:05 UTC
First notes:

- Don't use
 %define version 1.04
or
 %define name	python-%{module}
Just use the Version: and Name: tag. The corresponding macros will be automatically defined.

- I don't recommend using
 %define module	gmpy
either, but that's more of a stylistic point. If you decide to stick with it, use %global instead of %define
http://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define

- You are missing the Source URL
http://www.fedoraproject.org/wiki/Packaging/SourceURL

- The license tag is incorrect (you need to version it)
http://fedoraproject.org/wiki/Licensing#Good_Licenses

http://fedoraproject.org/wiki/Licensing/FAQ#How_do_I_figure_out_what_version_of_the_GPL.2FLGPL_my_package_is_under.3F

- Drop the explicit Requires: gmp, it is automatically picked up by rpm
http://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires

- Instead of
 %__python
it is possible to use just
 python

- Don't use
 %files -f INSTALLED_FILES
list the files explicitly instead. Here you will need the python-sitearch macro from
http://fedoraproject.org/wiki/Packaging:Python#System_Architecture

- Consider using a more recommended value of buildroot
 %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag

- The changelog entry from Thu May 04 2006 has broken UTF-8, the � should be é. You can probably just drop the old changelog, since you will end up rewriting a major part of the spec file anyway.

Comment 4 Michael J Gruber 2009-10-06 15:32:28 UTC
(In reply to comment #3)

> You can probably just drop the old changelog, since you will end up rewriting a
> major part of the spec file anyway.  

Thanks for the hints. I guess it's better starting from scratch than starting from mandrake...

I'll try my best, after recovering from the shock that the sheer amount of fedora package submission guidelines created.

Comment 5 Susi Lehtola 2010-01-01 23:00:26 UTC
ping?

Comment 6 Michael J Gruber 2010-01-04 11:08:10 UTC
(In reply to comment #5)
> ping?  

Pong!
I guess it took 2 months to recover from the shock mentioned in comment #4...

I'll give it a try.

Comment 7 Susi Lehtola 2010-07-03 23:37:52 UTC
ping Michael.

Comment 8 Susi Lehtola 2010-11-06 13:13:51 UTC
Closing due to submitter inactivity.

Comment 9 Michael J Gruber 2010-11-08 14:46:16 UTC
Created attachment 458758 [details]
SPEC file

Comment 10 Michael J Gruber 2010-11-08 14:49:35 UTC
Sorry for the lag...

I've rewritten the SPEC file from scratch now.

The SPEC is attached and also here, along with the SRPM:

http://mjg.fedorapeople.org/rpmdev/python-gmpy.spec

http://mjg.fedorapeople.org/rpmdev/python-gmpy-1.13-1.fc14.src.rpm

rpmlint clean

Build and tested on F14 x86_64: gmpy tests as well as python-mpmath tests
(mpmath uses gmpy automatically if present, and tests still succeed - much faster)

Please reopen and bear with me :)

Michael

Comment 11 Susi Lehtola 2010-11-08 14:57:33 UTC
A few notes:

- add a description.

- You're mixing styles: %{buildroot} vs. $RPM_BUILD_ROOT. Choose one and stick with it.

- Please add " -O1 --skip-build" to the install command as in the python specfile template.

- The %files section needs improvement. The statement
 %{python_sitearch}/
ends up owning the system python directory, which is not wanted. Probably it should be something like
 %{python_sitearch}/gmpy/
 %{python_sitearch}/gmpy-%{version}-py*.egg-info/
to behave nicely.

- This is an arch dependent package, so the build command should include a CFLAGS statement, as in the python specfile template
 CFLAGS="$RPM_OPT_FLAGS" python setup.py build
If you go with macro style, change $RPM_OPT_FLAGS to %{optflags}.

Comment 12 Susi Lehtola 2010-11-08 14:59:00 UTC
Also, note that this package CAN be named just "gmpy", as the naming guidelines state:

"Packages of python modules (thus they rely on python as a parent) use a slightly different naming scheme. They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script.

There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable."

I recommend using "gmpy" as the name.

Comment 13 Susi Lehtola 2010-11-08 15:00:40 UTC
You can use

A C-coded Python extension module that wraps the GMP library to provide to Python code fast multiprecision arithmetic (integer, rational, and float), random number generation, advanced number-theoretical functions, and more.

as the description. Furthermore, I'd change the summary to
"A Python interface to the GNU Multiple Precision Arithmetic Library"

Comment 14 Michael J Gruber 2010-11-08 15:38:41 UTC
OK, updated SPEC and SRPM are here:

http://mjg.fedorapeople.org/rpmdev/gmpy.spec

http://mjg.fedorapeople.org/rpmdev/gmpy-1.13-1.fc14.src.rpm

I tried to heed all the advice given above.

I marked the spec attachment obsolete since upload somewhere + link seems to be recommended.

Please note that the packaging guidelines
- mix macro and var style, 
- mention --skip-build and CFLAGS in the py2/py3 section only
- recommend leaving out the BuildRoot tag, clean sections etc., even though rpmlint issues warnings.

This could be easier on noobs ;)

Also, I think I need to specify FE-NEEDSPONSOR somewhere.

Michael

Comment 15 Susi Lehtola 2010-11-08 16:47:04 UTC
Oh right, you're not sponsored. No matter, I'm a sponsor and can sponsor you.

However, first you must show me your knowing of the Fedora guidelines, most importantly
 http://fedoraproject.org/wiki/Packaging/Guidelines
 http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
Additionally to the Packaging Guidelines, there are a bunch of language / application specific guidelines that are linked to in the Packaging Guidelines.

Here are some tricks of the trade:
http://fedoraproject.org/wiki/Packaging_tricks
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
http://fedoraproject.org/wiki/Common_Rpmlint_issues

I will sponsor you if you have at least one other submission and perform a couple of informal reviews of packages of other people.

Please review only packages *not* marked with FE-NEEDSPONSOR. I will have to do the full formal review after you to check that you have got everything correctly. Once I have sponsored you you will be able to do formal reviews of your own.

Comment 16 Susi Lehtola 2010-11-08 16:49:16 UTC
Furthermore, whenever you make changes to the spec file, be sure to increment the Release tag and make a corresponding entry in the changelog. This makes it easier for other people to track down what you have done.

The release should be currently set to 2.

Comment 17 Michael J Gruber 2010-11-08 17:02:36 UTC
(In reply to comment #16)
> Furthermore, whenever you make changes to the spec file, be sure to increment
> the Release tag and make a corresponding entry in the changelog. This makes it
> easier for other people to track down what you have done.
> 
> The release should be currently set to 2.

You mean even before version 1 shows up anywhere?? Without having the build submitted anywhere for inclusion? I guess I'd rather put up a git repo for that spec...

Michael

Comment 18 Michael J Gruber 2010-11-08 17:13:53 UTC
(In reply to comment #15)
> Oh right, you're not sponsored. No matter, I'm a sponsor and can sponsor you.
> 
> However, first you must show me your knowing of the Fedora guidelines, most
> importantly
>  http://fedoraproject.org/wiki/Packaging/Guidelines
>  http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
> Additionally to the Packaging Guidelines, there are a bunch of language /
> application specific guidelines that are linked to in the Packaging Guidelines.

I think I've proven already I don't know them, and given the sheer extent, I probably never will.

> Here are some tricks of the trade:
> http://fedoraproject.org/wiki/Packaging_tricks
> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
> http://fedoraproject.org/wiki/Common_Rpmlint_issues
> 
> I will sponsor you if you have at least one other submission and perform a
> couple of informal reviews of packages of other people.

such as python-mpmath, see bug#525192 ;)

> Please review only packages *not* marked with FE-NEEDSPONSOR. I will have to do
> the full formal review after you to check that you have got everything
> correctly. Once I have sponsored you you will be able to do formal reviews of
> your own.

/wiki/PackageMaintainers/Join says package approval then apply for sponsorship.
In fact, I'm not interested in doing formal reviews, I just wanted to submit a spec for packaging, not knowing what that would encompass.

Man, and I thought *we* (the Git folks) are making it hard for 1st time submitters...

Michael

Comment 19 Susi Lehtola 2010-11-08 17:19:32 UTC
rpmlint output:

gmpy.src: W: spelling-error %description -l en_US multiprecision -> multiprocessing, multiprocessor, imprecision
gmpy.src: W: invalid-url Source0: http://gmpy.googlecode.com/files/gmpy-1.13.zip HTTP Error 404: Not Found
gmpy.x86_64: W: spelling-error %description -l en_US multiprecision -> multiprocessing, multiprocessor, imprecision
gmpy.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/gmpy.so gmpy.so()(64bit)
gmpy.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/gmpy-1.13/test/test_large.py
gmpy.x86_64: W: file-not-utf8 /usr/share/doc/gmpy-1.13/doc/gmpydoc.txt
gmpy.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/gmpy.so 0775L
3 packages and 0 specfiles checked; 1 errors, 6 warnings.

Warnings 1-3 can be ignored. The rest will have to be tended to.

First of all, the private-shared-object-provides warning means that RPM's automatic library provides mechanism is picking up the shared library as a Provides, which it should not do. Adding

# we don't want to provide private python extension libs
%{?filter_setup:
%filter_provides_in %{python_sitearch}/.*\.so$ 
%filter_setup
}

to the beginning of the specfile should fix this issue.


Warning 5 is caused by test/test_large.py containing DOS style line endings. One can fix this in the %prep phase using the trick at 
 http://fedoraproject.org/wiki/PackagingTricks#Remove_DOS_line_endings
However, I'm not sure the test directory should be shipped at all. A better alternative is to run the tests in the build. You can do this by adding

***

%check
# Make python see the library that we have just compiled
libdir=`ls build/|grep lib`
export PYTHONPATH=`pwd`/build/$libdir

cd test
python gmpy_test.py

***

to the spec file (without the ***, of course).


Fix warning 6 with e.g. placing

# Convert files to utf-8
for file in doc/gmpydoc.doc; do
    iconv -f ISO-8859-1 -t UTF-8 -o $file.new $file && \
    touch -r $file $file.new && \
    mv $file.new $file
done

in %prep, directly after %setup, as instructed in 
http://fedoraproject.org/wiki/PackagingTricks#Convert_encoding_to_UTF-8


And finally, the last warning can be fixed by running

chmod 755 %{buildroot}%{python_sitearch}/gmpy.so

at the end of %install.

Comment 20 Susi Lehtola 2010-11-08 17:20:52 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Furthermore, whenever you make changes to the spec file, be sure to increment
> > the Release tag and make a corresponding entry in the changelog. This makes it
> > easier for other people to track down what you have done.
> > 
> > The release should be currently set to 2.
> 
> You mean even before version 1 shows up anywhere?? Without having the build
> submitted anywhere for inclusion? I guess I'd rather put up a git repo for that
> spec...

Well, it *does show up* in the review. This review has already been open for a year, so you can guess what would happen if the release tag were the same the whole time..

Comment 21 Susi Lehtola 2010-11-08 17:23:11 UTC
(In reply to comment #18)
> /wiki/PackageMaintainers/Join says package approval then apply for sponsorship.
> In fact, I'm not interested in doing formal reviews, I just wanted to submit a
> spec for packaging, not knowing what that would encompass.

Oh. Well, since packagership implies being able to perform reviews, the requirements for membership can seem somewhat strict.

If you're not interested in Fedora package maintainership, then maybe it's better to close this review altogether..?

Comment 22 Michael J Gruber 2010-11-09 16:45:57 UTC
(In reply to comment #19)

[I've learnt by now that rpmlint is called rpmlint and speclint for a good reason...]

I've incorporated all suggestions including

> chmod 755 %{buildroot}%{python_sitearch}/gmpy.so
> 
> at the end of %install.

even though rpmlint does not show the corresponding warning for me, and on my system gmpy.so gets installed 755 even without it. If setup.py is indeed umask dependent I'd call it borken...

New spec and srpm are at

http://mjg.fedorapeople.org/rpmdev/gmpy.spec
http://mjg.fedorapeople.org/rpmdev/gmpy-1.13-2.fc14.src.rpm

F14 builds at

http://koji.fedoraproject.org/koji/taskinfo?taskID=2590481

* Tue Nov 11 2010 Michael J Gruber <mjg@fedoraproject.org> 1.13-2
- avoid automatic provides for .so
- add check section rather than bundling the tests
- convert latin1 doc file to utf8 during prep
- chmod 755 the installed .so

Cheers,
Michael

Comment 23 Susi Lehtola 2010-11-11 08:18:53 UTC
So are you interested in becoming a Fedora packager?

Comment 24 Michael J Gruber 2010-11-11 09:32:14 UTC
(In reply to comment #23)
> So are you interested in becoming a Fedora packager?

Yes.

In comment #22 I described the changes to my spec file submission, trying to incorporate all suggested changes. 

I've also done an informal review for bug #623868 .

Should I list or link to other contributions here or on my fedoraproject user page?

Comment 25 Susi Lehtola 2010-11-12 10:55:26 UTC
OK, I'll have a look at it later. I forgot to mention this before: use
 %doc README doc/*
instead of
 %doc README doc/
since in the latter case you end up with the doc/ directory in /usr/share/doc/gmpy-%{version}/, which in this case doesn't really make sense since there are just a few files there. (You don't have to do this change straightaway.)

(In reply to comment #24)
> Should I list or link to other contributions here or on my fedoraproject user
> page?

Please list your contributions here.

Bug #623868 seems to be already assigned, so I can't take it over; we'll just have to wait until the assignee does review.

If you make another submission and another informal review, we should be OK.

Comment 26 Michael J Gruber 2010-11-12 20:02:29 UTC
In bug #652803 I submitted a review request for a font package. Should I specify NEEDSPONSOR there also?

Comment 27 Susi Lehtola 2010-11-12 21:07:42 UTC
No, there's no need. Do the other informal review and we should be fine. I'll try to have a look at your submissions during the weekend.

Comment 28 Susi Lehtola 2010-11-15 13:14:02 UTC
rpmlint is now at:

gmpy.src: W: spelling-error %description -l en_US multiprecision -> multiprocessing, multiprocessor, imprecision
gmpy.src: W: invalid-url Source0: http://gmpy.googlecode.com/files/gmpy-1.13.zip HTTP Error 404: Not Found
gmpy.x86_64: W: spelling-error %description -l en_US multiprecision -> multiprocessing, multiprocessor, imprecision
3 packages and 0 specfiles checked; 0 errors, 3 warnings.


MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK
MUST: The spec file for the package is legible and macros are used consistently. OK
MUST: The package must be named according to the Package Naming Guidelines. OK
MUST: The spec file name must match the base package %{name}. OK
MUST: The package must be licensed with a Fedora approved license and meet the  Licensing Guidelines. OK

MUST: The License field in the package spec file must match the actual license. OK
- License header exists only in src/gmpy.c which states LGPLv2+, thus the intention of the author can be considered clear.

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK
cf6ef1c3beda3ae291da9bdad36d4e9e  gmpy-1.13.zip
cf6ef1c3beda3ae291da9bdad36d4e9e  ../SOURCES/gmpy-1.13.zip

MUST: The package MUST successfully compile and build into binary rpms. OK
MUST: The spec file MUST handle locales properly. N/A
MUST: Optflags are used and time stamps preserved. OK
MUST: Packages containing shared library files must call ldconfig. N/A
MUST: A package must own all directories that it creates or require the package that owns the directory. OK
MUST: Files only listed once in %files listings. OK
MUST: Debuginfo package is complete. OK
MUST: Permissions on files must be set properly. OK
MUST: Large documentation files must go in a -doc subpackage. N/A

MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. NEEDSWORK
- Add the license, lgpl-2.1.txt, to %doc.

MUST: Header files must be in a -devel package.N/A
MUST: Static libraries must be in a -static package. N/A
MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A
MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A
MUST: Packages does not contain any .la libtool archives. N/A
MUST: Desktop files are installed properly. N/A
MUST: No file conflicts with other packages and no general names. OK
SHOULD: %{?dist} tag is used in release. OK
SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK
SHOULD: The package builds in mock. OK


So, in summary, what you need to is change
 %doc README doc/
to
 %doc README lgpl-2.1.txt doc/*
to fix the two issues. After that, this package is good to go.

Comment 29 Michael J Gruber 2010-11-15 13:46:08 UTC
V3 according to review comments (thanks!):

http://mjg.fedorapeople.org/rpmdev/python-gmpy.spec

http://mjg.fedorapeople.org/rpmdev/python-gmpy-1.13-3.fc14.src.rpm

http://koji.fedoraproject.org/koji/taskinfo?taskID=2601767

diff --git a/SPECS/gmpy.spec b/SPECS/gmpy.spec
index 9864d93..8c6dcb0 100644
--- a/SPECS/gmpy.spec
+++ b/SPECS/gmpy.spec
@@ -1,6 +1,6 @@
 Name:          gmpy
 Version:       1.13
-Release:       2%{?dist}
+Release:       3%{?dist}
 Summary:       A Python interface to the GNU Multiple Precision Arithmetic Library
 
 Group:         Development/Libraries
@@ -60,11 +60,15 @@ rm -rf %{buildroot}
 %defattr(-,root,root,-)
 %{python_sitearch}/gmpy.so
 %{python_sitearch}/gmpy-%{version}-py*.egg-info
-%doc README doc/
+%doc README lgpl-2.1.txt doc/*
 
 
 
 %changelog
+* Mon Nov 15 2010 Michael J Gruber <mjg@fedoraproject.org> 1.13-3
+- include lgpl-2.1.txt in doc
+- include all doc in toplevel dir rather than subdir
+
 * Tue Nov 11 2010 Michael J Gruber <mjg@fedoraproject.org> 1.13-2
 - avoid automatic provides for .so
 - add check section rather than bundling the tests

Comment 30 Michael J Gruber 2010-11-18 08:55:25 UTC
I'm not sure whether I should wait for 1.13-3 to go through, but here's an update for upstream's release from today. They say:

"gmpy 1.14 was released on November 18, 2010. A significant memory leak was fixed. This is a highly recommended upgrade."

(For an update to an existing package, I should probably put this in the spec changelog.)

http://mjg.fedorapeople.org/rpmdev/gmpy.spec
http://mjg.fedorapeople.org/rpmdev/gmpy-1.14-1.fc14.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2607773

diff --git a/SPECS/gmpy.spec b/SPECS/gmpy.spec
index 8c6dcb0..12036e6 100644
--- a/SPECS/gmpy.spec
+++ b/SPECS/gmpy.spec
@@ -1,6 +1,6 @@
 Name:          gmpy
-Version:       1.13
-Release:       3%{?dist}
+Version:       1.14
+Release:       1%{?dist}
 Summary:       A Python interface to the GNU Multiple Precision Arithmetic Library
 
 Group:         Development/Libraries
@@ -65,6 +65,9 @@ rm -rf %{buildroot}
 
 
 %changelog
+* Thu Nov 18 2010 Michael J Gruber <mjg@fedoraproject.org> 1.14-1
+- sync with upstream
+
 * Mon Nov 15 2010 Michael J Gruber <mjg@fedoraproject.org> 1.13-3
 - include lgpl-2.1.txt in doc
 - include all doc in toplevel dir rather than subdir

Comment 31 Susi Lehtola 2010-11-18 09:11:36 UTC
Good.

I'm just waiting for you to do another informal review; when you've done that I'll sponsor you. Please review only packages that are not assigned yet and not marked with FE-NEEDSPONSOR.

Comment 32 Michael J Gruber 2010-11-18 13:04:52 UTC
Informal review for bug #608332 which is unassigned and has no FE-NEEDSPONSOR. [Took me a while to find one which is not a merge review...]

Comment 33 Michael J Gruber 2010-11-18 13:25:07 UTC
Now, I don't know what magic removed my review in comment #32. Luckily I had saved most parts:

OK source files match upstream:
5095f72025132711c472b5a0db6417be13492b6ce09a74dfea9afe27165a6000  rootplot-1.1.tar.gz

OK package meets naming and versioning guidelines.
NOT OK specfile is properly named, is cleanly written and uses macros consistently.
OK dist tag is present.
OK build root is correct.
OK license field matches the actual license.
OK license is open source-compatible.
license text not included upstream.
NOT OK latest version is being packaged.
OK BuildRequires are proper.
OK %clean is present.
OK package builds in koji.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2608031
OK package installs properly.
OK rpmlint is silent.
(3 spellcheck warnings which can be ignored.)
OK final provides and requires are sane:
rpm -qp --provides RPMS/noarch/rootplot-1.1-1.fc14.noarch.rpm

rootplot = 1.1-1.fc14

rpm -qp --requires RPMS/noarch/rootplot-1.1-1.fc14.noarch.rpm

/usr/bin/python
numpy
python(abi) = 2.7
python-matplotlib
root-python
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

N/A %check is present and all tests pass:
OK no shared libraries are added to the regular linker search paths.
OK owns the directories it creates.
NOT OK doesn't own any directories it shouldn't.
OK no duplicates in %files.
OK file permissions are appropriate.
OK no scriptlets present.
OK documentation is small, so no -docs subpackage is necessary.
OK %docs are not necessary for the proper functioning of the package.
OK no headers.
OK no pkgconfig files.
OK no libtool .la droppings.
N/A desktop files valid and installed properly.

So the remianing issues are:

- Use macros rather than vars consistently (e.g. buildroot).
- You can use "python" directly.
- The latest upstream version is 2.2.
- Use %{python_sitelib}/root2matplotlib etc. so that you do not own all of sitelib.

Also, running the first example

http://packages.python.org/rootplot/plot_directive/pyplots/first.py

through python gives

Traceback (most recent call last):
  File "first.py", line 1, in <module>
    import rootplot.root2matplotlib as r2m
ImportError: No module named rootplot.root2matplotlib

Adjusting the import line results in a segmentation violation, which may very well be ROOT's fault.

Comment 34 Michael J Gruber 2010-11-18 13:27:17 UTC
Uhm, sorry for making a fool out of myself by mixing up tabs and, thus, bugs. The review is where it is supposed be.

rm -f comment #33.

Comment 35 Susi Lehtola 2010-11-18 16:29:42 UTC
OK. I can now sponsor you. However, you need to change your bugzilla email to a non-fedoraproject.org address. Currently the accounts system isn't capable of handling them...

Comment 36 Michael J Gruber 2010-11-18 17:02:20 UTC
(In reply to comment #35)
> OK. I can now sponsor you. However, you need to change your bugzilla email to a
> non-fedoraproject.org address. Currently the accounts system isn't capable of
> handling them...

My bugzilla account lists these permissions:

You have the following permission bits set on your account:
editbugs 	Can edit all aspects of any bug.
fedora_bugs 	Fedora Bugs Group to edit bug severity and priority
fedora_contrib 	Fedora Project Contributors
setpriority 	Can Set Priority of Bugs (internal)

Doesn't this mean that it's connected to my FAS account? (I'm a BugZapper sleeper, so to say).

I think during my account setup some helpful soul did some magic.

Comment 37 Susi Lehtola 2010-11-18 17:15:10 UTC
I don't remember the exact reason why packagers can't have a fedoraproject.org email in bugzilla. There's some problem with the package and accounts system.

I can't add you to the packager group without an external email address, which must then be the same as the one in bugzilla. You can change your BZ email in the Bugzilla settings. Email addresses are not revealed in BZ to people who are not logged in.

Comment 38 Michael J Gruber 2010-11-19 08:05:09 UTC
(In reply to comment #37)
> I don't remember the exact reason why packagers can't have a fedoraproject.org
> email in bugzilla. There's some problem with the package and accounts system.
> 
> I can't add you to the packager group without an external email address, which
> must then be the same as the one in bugzilla. You can change your BZ email in
> the Bugzilla settings. Email addresses are not revealed in BZ to people who are
> not logged in.

While I think that my bugzilla account *is* linked up with my FAS account (because of the associated permissions) I changed my bugzilla e-mail address to the one my FAS account forwards to. After logging in with the new address, permissions are the same, so at least there's no harm done :)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 39 Susi Lehtola 2010-11-19 09:44:55 UTC
This package has been APPROVED


I've added and sponsored you to the packager group. You can now proceed by requesting GIT branches for this package.

Comment 40 Michael J Gruber 2010-11-19 10:19:26 UTC
New Package SCM Request
=======================
Package Name: gmpy
Short Description: A Python interface to the GNU Multiple Precision Arithmetic Library
Owners: mjg 
Branches: f13 f14 el6
InitialCC:



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 41 Michael J Gruber 2010-11-19 10:20:09 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 42 Jason Tibbitts 2010-11-22 13:49:22 UTC
I cannot create this package, due to the following failure:

Email address mjg@fedoraproject.org is not a valid bugzilla email address.  Either make a bugzilla account with that email address or change your email address in the Fedora Account System https://admin.fedoraproject.org/accounts/ to a valid bugzilla email address and try again.

I'm not really sure what the problem is, honestly.  I asked on the admin channel but it's a bit early.

Comment 43 Michael J Gruber 2010-11-22 14:10:07 UTC
(In reply to comment #42)
> I cannot create this package, due to the following failure:
> 
> Email address mjg@fedoraproject.org is not a valid bugzilla email address. 
> Either make a bugzilla account with that email address or change your email
> address in the Fedora Account System https://admin.fedoraproject.org/accounts/
> to a valid bugzilla email address and try again.
> 
> I'm not really sure what the problem is, honestly.  I asked on the admin
> channel but it's a bit early.

This is crazy.

That (mjg@fp.org) used to be my bugzilla email address, and it was linked up perfectly with my FAS account because my bz account had the permissions which the bugzappers membership imply.

Nevertheless I was told I need to change my bugzilla e-mail address to the one my fedoraproject.org account forwards to, or else I couldn't be sponsored.

So I did the change.

Should I try changing back my bz e-mail to mjg@fp (which I would prefer anyways)?

Comment 44 Susi Lehtola 2010-11-22 14:38:44 UTC
(In reply to comment #43)
> That (mjg@fp.org) used to be my bugzilla email address, and it was linked up
> perfectly with my FAS account because my bz account had the permissions which
> the bugzappers membership imply.
> 
> Nevertheless I was told I need to change my bugzilla e-mail address to the one
> my fedoraproject.org account forwards to, or else I couldn't be sponsored.
> 
> So I did the change.
> 
> Should I try changing back my bz e-mail to mjg@fp (which I would prefer
> anyways)?

This is exactly the problem that I ran into before, when I tried to use my fp address in Bugzilla. I think the email in FAS and in BZ should be the same.

However, I don't see why there should be any problems now - Michael's emails in FAS and BZ would seem to be the same gmail account.

Comment 45 Michael J Gruber 2010-11-22 14:45:48 UTC
(In reply to comment #44)
> (In reply to comment #43)
> > That (mjg@fp.org) used to be my bugzilla email address, and it was linked up
> > perfectly with my FAS account because my bz account had the permissions which
> > the bugzappers membership imply.
> > 
> > Nevertheless I was told I need to change my bugzilla e-mail address to the one
> > my fedoraproject.org account forwards to, or else I couldn't be sponsored.
> > 
> > So I did the change.
> > 
> > Should I try changing back my bz e-mail to mjg@fp (which I would prefer
> > anyways)?
> 
> This is exactly the problem that I ran into before, when I tried to use my fp
> address in Bugzilla. I think the email in FAS and in BZ should be the same.
> 
> However, I don't see why there should be any problems now - Michael's emails in
> FAS and BZ would seem to be the same gmail account.

Quite some time ago, I had some helpful soul fix this for me so that my bz account acquired the correct permissions (I thought I'd mentioned). So our situation might only have seemed to be the same.

I reverted the email-change (back to my fp address), we'll see whether another attempt by Jason succeeds now.

Comment 46 Jason Tibbitts 2010-11-22 15:26:09 UTC
Git done (by process-git-requests).

Comment 47 Fedora Update System 2010-11-22 17:06:09 UTC
gmpy-1.14-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gmpy-1.14-1.fc14

Comment 48 Fedora Update System 2010-11-22 17:07:28 UTC
gmpy-1.14-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/gmpy-1.14-1.fc13

Comment 49 Fedora Update System 2010-11-23 21:52:02 UTC
gmpy-1.14-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gmpy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gmpy-1.14-1.fc14

Comment 50 Fedora Update System 2010-12-01 21:54:33 UTC
gmpy-1.14-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 51 Fedora Update System 2010-12-01 21:57:36 UTC
gmpy-1.14-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.


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