Bug 248363 - Review Request: mpfr - A C library for multiple-precision floating-point computations
Summary: Review Request: mpfr - A C library for multiple-precision floating-point com...
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jochen Schmitt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 248354 (view as bug list)
Depends On: 225809
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-16 13:55 UTC by Ivana Varekova
Modified: 2014-01-06 13:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-06 14:27:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jochen: fedora-review+


Attachments (Terms of Use)
fixed srpm (773.88 KB, application/x-redhat-package-manager)
2007-07-20 07:56 UTC, Ivana Varekova
no flags Details
fixed srpm (again) (782.92 KB, application/x-redhat-package-manager)
2007-07-20 08:53 UTC, Ivana Varekova
no flags Details
proposed version of gmp package (2.42 MB, application/x-rpm)
2007-07-23 12:28 UTC, Ivana Varekova
no flags Details

Description Ivana Varekova 2007-07-16 13:55:23 UTC
Spec URL: http://people.redhat.com/varekova/mpfr.spec
SRPM URL: http://people.redhat.com/varekova/mpfr-2.2.1-1.src.rpm
Description: 
The MPFR library is a C library for multiple-precision floating-point
computations with "correct rounding". The MPFR is efficient and
also has a well-defined semantics. It copies the good ideas from the
ANSI/IEEE-754 standard for double-precision floating-point arithmetic
(53-bit mantissa). MPFR is based on the GMP multiple-precision library.

Comment 1 Jochen Schmitt 2007-07-16 16:19:28 UTC
Good:
+ Package meets naming guildlines.
+ SPEC file name matches with package base name.
+ License tag says GPL
+ Project home page says LGPL as package license
+ Package contains verbatim copy of the license text
+ SPEC is written in English
+ SPEC file is legible
+ Tar ball matches with upstream
  (md5sum: 40bf06f8081461d8db7d6f4ad5b9f6bd)
+ Package has correct build root
+ BuildRequires are not redundant
+ Local build works fine.
+ package has %defattr an proper file permissions
+ %doc section is small
+ %doc section doesn't affect run time
+ Package contains no duplicates in the %file list
+ Changelog entries are ok.
+ Rpmlint is quite on source package.
+ Rpmlint is quite on binary packages
+ Mock build works fine for Devel (x86_64, i386, ppp64, ppc)

Bad:
- Package needs a Conflict tag, because the current gmp package contains the
mpfr package
- Unnecessary condition on deleting build root in %clean section
- Devel package contains static library




Comment 2 Ivana Varekova 2007-07-20 07:56:59 UTC
Created attachment 159633 [details]
fixed srpm

Thanks for your review the attached srpm fixes bugs you mentioned.

Comment 3 Ivana Varekova 2007-07-20 08:05:14 UTC
*** Bug 248354 has been marked as a duplicate of this bug. ***

Comment 4 Jakub Jelinek 2007-07-20 08:24:28 UTC
The mpfr library is released under LGPL2.1, how can saying it is GPL in the
License tag be a "Good" thing?  Of course you can relicense LGPL2.1 code as GPL,
but why would you do that?  License: LGPL would be much better (unless with the
advent of GPL3, LGPL3, LGPL2.5 we start being more explicit and write
GPL2, GPL2+, GPL3, GPL3+, LGPL2, LGPL2+, LGPL2.1, LGPL2.1+, LGPL2.5, LGPL3,
LGPL3+ etc. in License tags.

Also, upstream mpfr releases stable fixes on top of the last release
as a cummulative patch, see http://www.mpfr.org/mpfr-current/patches
It would be good to apply this in the spec file.

Comment 5 Ivana Varekova 2007-07-20 08:53:41 UTC
Created attachment 159634 [details]
fixed srpm (again)

Thanks Jakub, problems you mention are fixed in this version.

Comment 6 Laurent Rineau 2007-07-21 11:07:10 UTC
As far as I understand, that package cannot be push in Fedora, unless bug 
#225809 is closed, and libmpfr.a (and mpfr headers) removed from gmp-devel.

There is not a log of traffic in bug #225809. I do not even know if somebody 
is actually maintaining gmp (the version in Fedora is obsolete).

Ivana, what is your plan? Waiting for GMP maintainers to fix their package?


Comment 7 Jochen Schmitt 2007-07-22 17:56:40 UTC
(In reply to comment #6)
> As far as I understand, that package cannot be push in Fedora, unless bug 
> #225809 is closed, and libmpfr.a (and mpfr headers) removed from gmp-devel.

Yes, you right.

> There is not a log of traffic in bug #225809. I do not even know if somebody 
> is actually maintaining gmp (the version in Fedora is obsolete).
> Ivana, what is your plan? Waiting for GMP maintainers to fix their package?

We have to poke the gmp maintainer to do the split, because without the split 
we can't release a separate mpfr library.




Comment 8 Jochen Schmitt 2007-07-22 17:57:00 UTC
(In reply to comment #6)
> As far as I understand, that package cannot be push in Fedora, unless bug 
> #225809 is closed, and libmpfr.a (and mpfr headers) removed from gmp-devel.

Yes, you right.

> There is not a log of traffic in bug #225809. I do not even know if somebody 
> is actually maintaining gmp (the version in Fedora is obsolete).
> Ivana, what is your plan? Waiting for GMP maintainers to fix their package?

We have to poke the gmp maintainer to do the split, because without the split 
we can't release a separate mpfr library.




Comment 9 Jochen Schmitt 2007-07-22 19:41:10 UTC
I have create a suggestion for the gmp package on gmp-4.2.1.

So I thing, you should add a 'Conflict: gmp < 4.2.1' statement into your package.

Comment 10 Ivana Varekova 2007-07-23 08:37:44 UTC
Hello,
I'm gmp maintainer too so I'd like to update gmp in devel branch too, but I
don't want to remove mpfr files from gmp for long time without existence of the
separate mpfr package. So I plan to do both these changes (update gmp and remove
mpfr files from gmp and add mpfr package) when this review will be approved. 
I will update the conflict flag when I will build the new gmp version. 
Thanks for your comments.


Comment 11 Laurent Rineau 2007-07-23 08:51:44 UTC
Nice to hear that, Ivana. Do you have a gmp package updated, so that we can 
test it with the mpfr RPM of this bug?


Comment 12 Ivana Varekova 2007-07-23 12:28:10 UTC
Created attachment 159779 [details]
proposed version of gmp package

Oops good idea - so this is the proposed version of gmp package.

Comment 13 Ivana Varekova 2007-07-26 07:52:04 UTC
Is there any other problem? Could somebody approved this package review please?
Thanks.

Comment 14 Jochen Schmitt 2007-07-26 13:47:15 UTC
I'm waiting to see a package, where are complaints are fixed.

If I see this package, I will be able to approve your package.

Comment 15 Ivana Varekova 2007-07-26 14:03:05 UTC
The srpm from comment #5 should have all fixes. Is there any problem with this
package? (perhaps I overlook some comment?)

Comment 16 Jochen Schmitt 2007-07-26 14:39:28 UTC
Soory for my mistake. I have got a look on it and it's looks fine.


*** YOU ARE APPROVED ***

Comment 17 Ivana Varekova 2007-07-26 14:47:00 UTC
Package Name: mpfr 
Short Description: A C library for multiple-precision floating-point computations
Owners: varekova@redhat.com
Branches:


Comment 18 Ivana Varekova 2007-08-06 14:27:37 UTC
mpfr-2.2.1-1 package is just built. If there is any problem please create a
separate bug for this component.

Comment 19 Björn 'besser82' Esser 2014-01-06 13:09:39 UTC
Package Change Request
======================
Package Name: mpfr
New Branches: el5
Owners: besser82

Comment 20 Gwyn Ciesla 2014-01-06 13:16:40 UTC
Any comments from the Fedora maintainers?


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