Spec URL: https://jamesturner246.fedorapeople.org/mpfr-3.1.6/mpfr.spec SRPM URL: https://jamesturner246.fedorapeople.org/mpfr-3.1.6/mpfr-3.1.6-1.fc28.src.rpm Description: [first package - require sponsor] A C library for multiple-precision floating-point computations. Fedora Account System Username: jamesturner246 This is the version 3.1.16 update of the MPFR arbitrary-precision floating-point arithmetic library. Version 3.1.16 brings many bugfixes (see http://www.mpfr.org/mpfr-3.1.5/#fixed), and an improved manual. I have also fixed a long-standing encoding problem with the Texinfo manual, initially reported Jan 2016 (see https://bugzilla.redhat.com/show_bug.cgi?id=1299649). The package also contains the latest patches for this version, and some streamlining of the spec file. Due to this being my first package submission for Fedora, I would like to request sponsorship. I have tried to contact the original maintainer of MPFR, Pavel Cahyna (pcahyna), but have had no response, so would like to volunteer myself as a new maintainer. However, it is in my interests that this package remains updated and functional in Fedora. Regarding my employment and experience: I am the author of MPFA (https://github.com/jamesturner246/mpfa): a multi-precision range analysis library, which makes heavy use of the MPFR package in review. I am studying a PhD thesis in numerical methods at University of Sussex, but am quite familiar with C programming, Git, Fedora and GNU buildsystems used in industry. Here is a link to the last modified Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=23871092 Many thanks, and look forward to hearing from you. James Paul Turner. jamesturner246
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers http://bugz.fedoraproject.org/mpfr
> Summary: A C library for multiple-precision floating-point computations The leading "A C" is a example of a summary where the leading article is superfluous and reduces readability. https://fedoraproject.org/wiki/Examples_of_good_package_summaries > BuildRequires: autoconf libtool gmp-devel Requiring gmp-devel is a hint that it links with libgmp somehow. > Requires: gmp >= 4.2.3 https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires > Requires(post): /sbin/ldconfig > Requires(postun): /sbin/ldconfig With the scriptlets running /sbin/ldconfig directly, there are automatic dependencies on /sbin/ldconfig. > %package devel > Requires: %{name} = %{version}-%{release} https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package > Requires(post): /sbin/install-info > Requires(preun): /sbin/install-info Also see the %post and %preun sections. There are official scripts for a long time: https://fedoraproject.org/wiki/Packaging:Scriptlets#Texinfo > If you want to develop applications which will use the MPFR library, > you'll need to install the mpfr-devel package. You'll also need to > install the mpfr package. Redundant instructions. mpfr is installed automatically due to dependencies.
Michael. Thank you for your feedback. I have initiated the unresponsive packager procedure: https://bugzilla.redhat.com/show_bug.cgi?id=1529827 I have also made changes to the specfile which hopefully fix the previous issues. Furthermore, I have also updated MPFR to the just-released version 4.0.0. Specfile: https://jamesturner246.fedorapeople.org/mpfr-4.0.0/mpfr.spec SRPM: https://jamesturner246.fedorapeople.org/mpfr-4.0.0/mpfr-4.0.0-1.fc28.src.rpm Do respond if any issues remain - it is appreciated. All the best, James.
I forgot the Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=23945790
There is an API change in MPFR 4, see http://www.mpfr.org/mpfr-current/#changes (also its soname changes to libmpfr.so.6). Given that quite a lot of packages depend on mpfr, are they ready to cope with this API change?
See https://fedoraproject.org/wiki/Changes/mpfr-4.0.0 and https://pagure.io/releng/issue/7247 I looked at how the Ruby_2.5 folks were handling things, and they seemed to have a nice plan. The packages can be rebuilt and tested in a separate Koji tag, such that, if there are any problems, the tag can simply be deleted without merging. I will test and take care of the possible reintroduction of https://bugzilla.redhat.com/show_bug.cgi?id=515958 once we have the tag.
*** This bug has been marked as a duplicate of bug 1537252 ***