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).
Yet another additional comment: I'm a noob regarding package submission, please guide me through if necessary...
OK, I'll take the review.
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.
(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.
ping?
(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.
ping Michael.
Closing due to submitter inactivity.
Created attachment 458758 [details] SPEC file
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
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}.
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.
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"
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
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.
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.
(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
(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
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.
(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..
(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..?
(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> 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
So are you interested in becoming a Fedora packager?
(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?
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.
In bug #652803 I submitted a review request for a font package. Should I specify NEEDSPONSOR there also?
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.
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.
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> 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> 1.13-2 - avoid automatic provides for .so - add check section rather than bundling the tests
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> 1.14-1 +- sync with upstream + * Mon Nov 15 2010 Michael J Gruber <mjg> 1.13-3 - include lgpl-2.1.txt in doc - include all doc in toplevel dir rather than subdir
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.
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...]
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.
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.
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...
(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.
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.
(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
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.
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
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I cannot create this package, due to the following failure: Email address mjg 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.
(In reply to comment #42) > I cannot create this package, due to the following failure: > > Email address mjg 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) 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)?
(In reply to comment #43) > That (mjg) 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.
(In reply to comment #44) > (In reply to comment #43) > > That (mjg) 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.
Git done (by process-git-requests).
gmpy-1.14-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gmpy-1.14-1.fc14
gmpy-1.14-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/gmpy-1.14-1.fc13
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
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.
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.