Is anything happening with introducing MPFR 4 into Fedora? I found these: https://fedoraproject.org/wiki/Changes/mpfr-4.0.0 https://bugzilla.redhat.com/show_bug.cgi?id=1537252 but they indicate that efforts to update have come to a halt. I ask because I have had to patch 2 of my packages to keep them working with MPFR 3, and I've got more that are said to work with either version 3 or version 4. I am willing to put some effort into making the update happen. I agree with the previous assessments that we will probably have to make the two versions parallel installable for awhile, possibly for quite awhile, until everything can be migrated to version 4. This is the list of source packages in Fedora 30 that depend on libmpfr, with asterisks by the ones I maintain, comaintain, or just tend to meddle with: R-Rmpfr Singular (*) apron (*) arb (*) arm-none-eabi-gcc-cs avr-gcc cross-gcc fawkes flint (*) gap-pkg-float (*) gappa (*) gawk gcc gdb genius ghdl giac gnome-calculator gretl ledger libbytesize libfplll (*) libmpc libqalculate libscs mingw-gcc mpfi (*) nacl-gcc ocaml-mlgmpidl ocaml-tplib (*) octave-interval openscad polymake (*) pynac (*) python-fpylll (*) python-gmpy2 (*) rasqal sagemath (*) sirocco (*) texlive-base why (*) Wow, I didn't realize how many packages I work with that consume mpfr. That makes 16 out of 41, so I can manage moving 40% of the mpfr-using packages over to version 4 all by myself. And, truth be told, there are 4 more on that list that I've committed changes to at one point or another, so I've had my fingers on 50% of them. Good grief. Is somebody working on this already, and if so, what have you accomplished so far, and what are your future plans? How can I help? -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I should be more specific. By 'this' I mean packaging a library which already exists in Fedora, but is of lower version.

On Sat, Jul 6, 2019 at 1:55 PM Jakub Jelinek <jakub(a)redhat.com&gt; wrote: > There is no way around having some compatibility version, either in > the same > or other rpm, at least for a short period of time, because gcc > needs libmpfr > and libmpfr needs to be built with gcc, so if you upgrade > incompatibly > libmpfr, you will build that package, but once it is in the > buildroots, gcc > will not install anymore and so nothing that needs gcc to build > will > succeed building. Right. I think James's question was about submitting a package for review that is a different version of a package owned by somebody else. The maintainer of record for mpfr is Pavel Cahyna. I see he has an mpfr COPR: https://copr.fedorainfracloud.org/coprs/pcahyna/mpfr4/ but it looks like it hasn't been touched in a long time. This is what fedora-active-user has to say about him: Last login in FAS: pcahyna 2019-05-16 Last action on koji: Fri, 11 Aug 2017 package list entry revoked: zisofs-tools in f25 by pkgdb Last package update on bodhi: 2018-02-25 21:51:52 on package mpfr-3.1.6-1.fc27 Last actions performed according to fedmsg: - joerg.schilling(a)fokus.fraunhofer.de updated nothing on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-07-04 08:29:55 () - ekanter(a)rcn.com updated nothing on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-07-04 08:06:42 () - rgm(a)htt-consult.com updated nothing on RHBZ#1583845 'Cannot write to CDrom at all' on 2019-06-27 10:22:24 () - joerg.schilling(a)fokus.fraunhofer.de updated nothing on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-06-26 06:21:01 () - ekanter(a)rcn.com updated 'cc' on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-06-26 06:02:22 () - pdupre(a)gmx.com updated 'cc' on RHBZ#1457252 'gnuplot-5.2.7 is available' on 2019-06-09 12:07:09 () - kevin(a)tigcc.ticalc.org updated 'cc' on RHBZ#1583845 'Cannot write to CDrom at all' on 2019-06-05 14:27:05 () - kevin(a)tigcc.ticalc.org updated 'cc' on RHBZ#1583845 'Cannot write to CDrom at all' on 2019-06-05 14:19:32 () - kevin(a)tigcc.ticalc.org updated 'cc', 'dup_id', and 'resolution' on RHBZ#1580021 'wodim missing u+s will prevent usage at ...' on 2019-06-05 14:19:32 () - upstream-release-monitoring updated 'short_desc' on RHBZ#1457252 'gnuplot-5.2.7 is available' on 2019-05-29 01:05:26 () Last email on mailing list: ERROR:active-user:[Errno socket error] [Errno -2] Name or service not known Hmmm, what happened with the email on mailing list check? The current mpfr library (3.1.6) has soname "libmpfr.so.4". The new mpfr library (4.0.2) has soname "libmpfr.so.6". We want to keep both sonames available until all consumers can be switched to mpfr4, which may take awhile. We are not changing versions of libmpc, so the soname of "libmpc.so.3" is fixed. Therefore, we have to have the following packages, and their -devel subpackages, and it has to be possible to have them all installed in the same buildroot: - mpfr 3.1.6 - mpfr 4.0.2 - libmpc 1.1.0 linked with mpfr 3.1.6 - libmpc 1.1.0 linked with mpfr 4.0.2 I think it would be nice to have the "mpfr" package mean the latest version (i.e., 4.0.2), and introduce an mpfr3 package to hold 3.1.6. Likewise, it would be nice to have the "libmpc" package mean the version linked with mpfr 4.0.2, and introduce something, say "libmpc-mpfr3", to hold the version linked with mpfr 3.1.6. I can be swayed otherwise, but that would let us preserve package history, and we can hopefully drop the mpfr3 and libmpc-mpfr3 packages from the distribution someday. The tricky part, of course, is not breaking gcc while updating. Here is one way that could be accomplished. Caveat: I haven't actually tried doing this. If this seems reasonable, I would like to create a COPR and start doing these builds to make sure nothing breaks. - Alter the mpfr package to produce mpfr3, mpfr3-devel, mpfr, and mpfr-devel packages. The mpfr3 library has the old soname, the mpfr library has the new soname. The -devel packages must be installable in parallel, so the mpfr3 packages have libmpfr3.so*, /usr/include/mpfr3.h, and /usr/include/mpf2mpfr3.h. - Alter the libmpc package to produce libmpc and libmpc-mpfr3 packages. The libmpc package keeps the current soname. The libmpc-mpfr3 package gets the soname “libmpc-mpfr3.so.3”. Both are linked against mpfr3! That’s important! The -devel packages must be installable in parallel, so the libmpc- mpfr3 packages have libmpc-mpfr3.so* and /usr/include/mpc-mpfr3.h. - Build gcc with mpfr3 and libmpc-mpfr3. This means that gcc no longer depends on the mpfr and libmpc packages, so we can change them without breaking gcc. We will have to patch gcc to use the mpfr3 header file names and link with the altered library names. - Build libmpc again. Now libmpc-mpfr3 is linked with mpfr3 and libmpc is linked with mpfr. - Build gcc with mpfr and libmpc. We just drop the patch we used two steps ago and rebuild. Now gcc works with the new packages, and packages that use mpfr can be upgraded to mpfr4 at their leisure (but will FTBFS if they require mpfr 3, because of the altered header file and library names). Packages that use libmpc, however, are broken because libmpc is now linked with mpfr 4. Those packages must be moved to mpfr4 or built against libmpc- mpfr3. They are: o arm-none-eabi-gcc-cs o avr-gcc o cross-gcc o gap-pkg-float o ghdl o gnome-calculator o mingw-gcc o python-gmpy2 o sagemath I suggest this order for building packages. Each must be built against mpfr 4, or patched to continue building with mpfr 3. This order takes dependencies into account: - gawk (because it is in the default buildroot) - gdb (likewise) - All of these can be done in parallel: R-Rmpfr, arm-none-eabi-gcc- cs, avr-gcc, cross-gcc, fawkes, flint, gappa, genius, ghdl, gnome-calculator, gretl, ledger, libbytesize, libfplll, libqalculate, libscs, mingw-gcc, mpfi, ocaml-mlgmpidl, octave-interval, openscad, python-gmpy2, rasqal, sirocco - These can be done in parallel. Names in parentheses indicate dependencies: apron (ocaml-mlgmpidl), arb (flint), gap-pkg-float (mpfi), giac (mpfi), ocaml-tplib (ocaml-mlgmpidl), python-fpylll (libfplll), Singular (flint) - polymake (Singular), pynac (giac, Singular), why (apron) - sagemath (polymake, pynac) - texlive-base, just because it is a huge monster, so I want to deal with it last. It could probably be moved higher in this list. That is certainly not the only approach that can be taken. If somebody has a better idea, please share it. It is too late to attempt this for Fedora 31, but I would like to get the approach solidified and everything ready to go so this can land as early as possible in the Fedora 32 cycle. Regards, -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I'm not sure. In this case, though, i don't think we need it. I've been building packages in a local mock for the last few days. I've still got 6 to go, and so far I've only hit 2 issues, neither of them related to MPFR. Unless something comes up with these last few, I think we need the MPFR 3 and MPC-linked-with-MPFR-3 compatibility packages only to get gcc switched over, then we can discard them and have an entirely MPFR 4 distribution.

Pavel, are you around? Some of these packages take a long time to build, but I think if we had, say, a 4 or 5 day window in which the gcc and texlive maintainers agreed not to do any new builds, we could get Fedora switched entirely over to MPFR 4. We need to start figuring out when that should happen. We are already past the deadline for system-wide change proposals for Fedora 31, but if we get our ducks in a row, we can perhaps get this into Fedora 32 as soon as that window opens. (I'm assuming this will be a system-wide change since it affects gcc.)

Nice work Jerry! I remember it being quite difficult to get into contact with Pavel last time I tried. I eventually had to use the non-responsive maintainer procedure.

On Fri, Jul 12, 2019 at 9:07 AM Jerry James <loganjerry(a)gmail.com&gt; wrote: > I'm down to these 3 still to go: arm-none-eabi-gcc-cs, avr-gcc, and > cross-gcc. Those gcc builds take a long time. :-) So far the builds > have gone smoothly. All the builds have completed without trouble. I did have to patch a couple of packages to use mpfr_rootn_ui() instead of mpfr_root(). That required a little care since those two functions are only *mostly* equivalent. Other than that, there have been no issues at all. > Does anyone at RedHat know if Pavel is on vacation? If not, what is > the best way to contact him? I would like to ask again if anyone who works at RedHat can check on Pavel's status. It would be good to know if he is not available until <DATE>, or if he is too busy to pay attention to mpfr. Thank you.

On Wed, Jul 24, 2019 at 12:00 PM Pavel Cahyna <pcahyna(a)redhat.com&gt; wrote: > On Thu, Jul 18, 2019 at 11:31:02AM -0600, Jerry James wrote: > > I would like to ask again if anyone who works at RedHat can check > > on > > Pavel's status. It would be good to know if he is not available > > until > > <DATE>, or if he is too busy to pay attention to mpfr. Thank > > you. > > Hi, sorry for the delayed reply. I will not be able to look into it > before Monday. [Nearly 2 months later] I need some advice on how to proceed. I am ready to move the mpfr 4 change forward, but the 2 lines above are the only communication I've ever had from the package owner. There is already a change page here, which could be reused with some minor edits: https://fedoraproject.org/wiki/Changes/mpfr-4.0.0 And that change page links to an existing releng issue where releng agreed that the only action required by them is management of a side tag: https://pagure.io/releng/issue/7247 I would like to revive/hijack those to get this moving again. What should I do about the maintainer, who is probably very busy with other work? Since gcc uses mpfr, the package is a critical one for Fedora. If it is not inconsistent with RedHat's goals or policies, could I perhaps step into a comaintainer role for mpfr? Since this thread is so old, I will repeat that I have done successful x86_64 mock builds of all dependent packages. I've got the right sequence of builds all worked out and ready to go. There may be problems on other arches; if so, I am ready to fix them. -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org