Re: Packages silently dropping approved changes
The current status is: - opentoonz: was adapted in https://src.fedoraproject.org/rpms/opentoonz/pull-request/1, built and updated - openmeeg: was re-adapted in https://src.fedoraproject.org/rpms/openmeeg/pull-request/2, built and updated Thanks Diego and Antonio for your quick response. - freefem++: a re-adaptation was proposed in https://src.fedoraproject.org/rpms/freefem++/pull-request/2 I would also like to note that freefem's current configuration has many issues, as can be seen in the linking result: $ ldd /usr/bin/FreeFem++ [snip] liblapack.so.3 => /lib64/liblapack.so.3 (0x7f4969c0) libopenblas.so.0 => /lib64/libopenblas.so.0 (0x7f4967828000) [snip] libflexiblas.so.3 => /lib64/libflexiblas.so.3 (0x7f496680) [snip] libblas.so.3 => /lib64/libblas.so.3 (0x7f4967626000) [snip] The final binary links to 4 different libraries with an overlapping set of symbols. At the same time, other libraries used by freefem (such as arpack, suitesparse, etc.) are using libflexiblas. So this situation is far from ideal, because mixing them is not a good idea. The patch linked above solves this and produces a clean list of dependencies. Iñaki On Fri, 26 Aug 2022 at 15:44, Ben Beasley wrote: > > The policies specifying use of FlexiBLAS[1] are full of MUSTs; you can’t just > opt out and reject all prospective PRs out of hand. If someone can get the > package working with FlexiBLAS, you should accept a PR. If you think > freefem++ needs to be exempt from the requirement, you should open an FPC > ticket[2] explaining why and requesting an explicit exception. > > [1] > https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/#_packaging_blaslapack_dependent_packages > [2] https://pagure.io/packaging-committee/issues > > On Thu, Aug 25, 2022, at 6:36 PM, Ralf Corsépius wrote: > > Am 25.08.22 um 23:00 schrieb Iñaki Ucar: > >> On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar wrote: > >>> > >>> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius wrote: > > Am 25.08.22 um 13:19 schrieb Iñaki Ucar: > > > I assume their maintainers didn't do it on purpose, maybe it was > > easier for a certain update, didn't have time to look into it and > > weren't aware of the guideline. But this is very frustrating. Seeing > > many hours of work just wiped out without any notice or explanation is > > very frustrating. > > In my case (freefem++), it was actually was a mixture of all. > > To cut a long story short: This flexblas stuff doesn't "harmonize well" > with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. > > Because of this, when going after freefem++'s regressions, years after > the flexiblas changes had been introduced, I inadvertedly and > accidentally reverted the flexblas related changes, because these > apparently do not work out with freefem++. > >>> > >>> How exactly does flexiblas break freefem++? I see v4.10 was built just > >>> fine. Then v4.11 reverted to openblas. If it works with openblas, I > >>> see no reason to break with flexiblas, among other things because > >>> openblas is the default backend. Moreover, arpack, superlu, > >>> suitesparse and other BuildRequires link against flexiblas. > >> > >> In fact, freefem++ was one of the easiest packages to adapt: you just > >> set the library, and it does nothing fancy nor too-clever to try to > >> discover anything. > > Then you haven't looked into details (build.log rsp. config.status). > > > > flexiblas causes freefem's configure script to produce bogus results. > > > > > > Here's a simple patch [1] and a successful scratch > >> build [2], with all checks passing. Please let me know if I'm missing > >> anything, but otherwise, I'll open a PR. > > Please don't and also abstain from submitting pull requests. > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@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 > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Iñaki Úcar
Re: Packages silently dropping approved changes
The policies specifying use of FlexiBLAS[1] are full of MUSTs; you can’t just opt out and reject all prospective PRs out of hand. If someone can get the package working with FlexiBLAS, you should accept a PR. If you think freefem++ needs to be exempt from the requirement, you should open an FPC ticket[2] explaining why and requesting an explicit exception. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/#_packaging_blaslapack_dependent_packages [2] https://pagure.io/packaging-committee/issues On Thu, Aug 25, 2022, at 6:36 PM, Ralf Corsépius wrote: > Am 25.08.22 um 23:00 schrieb Iñaki Ucar: >> On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar wrote: >>> >>> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius wrote: Am 25.08.22 um 13:19 schrieb Iñaki Ucar: > I assume their maintainers didn't do it on purpose, maybe it was > easier for a certain update, didn't have time to look into it and > weren't aware of the guideline. But this is very frustrating. Seeing > many hours of work just wiped out without any notice or explanation is > very frustrating. In my case (freefem++), it was actually was a mixture of all. To cut a long story short: This flexblas stuff doesn't "harmonize well" with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. Because of this, when going after freefem++'s regressions, years after the flexiblas changes had been introduced, I inadvertedly and accidentally reverted the flexblas related changes, because these apparently do not work out with freefem++. >>> >>> How exactly does flexiblas break freefem++? I see v4.10 was built just >>> fine. Then v4.11 reverted to openblas. If it works with openblas, I >>> see no reason to break with flexiblas, among other things because >>> openblas is the default backend. Moreover, arpack, superlu, >>> suitesparse and other BuildRequires link against flexiblas. >> >> In fact, freefem++ was one of the easiest packages to adapt: you just >> set the library, and it does nothing fancy nor too-clever to try to >> discover anything. > Then you haven't looked into details (build.log rsp. config.status). > > flexiblas causes freefem's configure script to produce bogus results. > > > Here's a simple patch [1] and a successful scratch >> build [2], with all checks passing. Please let me know if I'm missing >> anything, but otherwise, I'll open a PR. > Please don't and also abstain from submitting pull requests. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages silently dropping approved changes
On Fri, 26 Aug 2022 at 00:44, Ralf Corsépius wrote: > > > > Am 25.08.22 um 23:00 schrieb Iñaki Ucar: > > On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar wrote: > >> > >> On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius wrote: > >>> > >>> Am 25.08.22 um 13:19 schrieb Iñaki Ucar: > >>> > I assume their maintainers didn't do it on purpose, maybe it was > easier for a certain update, didn't have time to look into it and > weren't aware of the guideline. But this is very frustrating. Seeing > many hours of work just wiped out without any notice or explanation is > very frustrating. > >>> > >>> In my case (freefem++), it was actually was a mixture of all. > >>> > >>> To cut a long story short: This flexblas stuff doesn't "harmonize well" > >>> with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. > >>> > >>> Because of this, when going after freefem++'s regressions, years after > >>> the flexiblas changes had been introduced, I inadvertedly and > >>> accidentally reverted the flexblas related changes, because these > >>> apparently do not work out with freefem++. > >> > >> How exactly does flexiblas break freefem++? I see v4.10 was built just > >> fine. Then v4.11 reverted to openblas. If it works with openblas, I > >> see no reason to break with flexiblas, among other things because > >> openblas is the default backend. Moreover, arpack, superlu, > >> suitesparse and other BuildRequires link against flexiblas. > > > > In fact, freefem++ was one of the easiest packages to adapt: you just > > set the library, and it does nothing fancy nor too-clever to try to > > discover anything. > Then you haven't looked into details (build.log rsp. config.status). Could you please describe the issues? > flexiblas causes freefem's configure script to produce bogus results. If you are referring to this line configure: -- NO ARPACK -- enable_download : no , wget: yes then I have good news. I think we can agree that the configure script is a mess. It just needed a simple fix to make that test successful, namely, to substitute -llapack with -lflexiblas. Please take a look at https://koji.fedoraproject.org/koji/taskinfo?taskID=91264332. I see no differences in the list of "configure: ++ " that the script produces > Here's a simple patch [1] and a successful scratch > > build [2], with all checks passing. Please let me know if I'm missing > > anything, but otherwise, I'll open a PR. > Please don't and also abstain from submitting pull requests. I'm sorry, I'm trying to help here. But it's difficult if I don't know the specific trouble you run into. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages silently dropping approved changes
Am 25.08.22 um 23:00 schrieb Iñaki Ucar: On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar wrote: On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius wrote: Am 25.08.22 um 13:19 schrieb Iñaki Ucar: I assume their maintainers didn't do it on purpose, maybe it was easier for a certain update, didn't have time to look into it and weren't aware of the guideline. But this is very frustrating. Seeing many hours of work just wiped out without any notice or explanation is very frustrating. In my case (freefem++), it was actually was a mixture of all. To cut a long story short: This flexblas stuff doesn't "harmonize well" with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. Because of this, when going after freefem++'s regressions, years after the flexiblas changes had been introduced, I inadvertedly and accidentally reverted the flexblas related changes, because these apparently do not work out with freefem++. How exactly does flexiblas break freefem++? I see v4.10 was built just fine. Then v4.11 reverted to openblas. If it works with openblas, I see no reason to break with flexiblas, among other things because openblas is the default backend. Moreover, arpack, superlu, suitesparse and other BuildRequires link against flexiblas. In fact, freefem++ was one of the easiest packages to adapt: you just set the library, and it does nothing fancy nor too-clever to try to discover anything. Then you haven't looked into details (build.log rsp. config.status). flexiblas causes freefem's configure script to produce bogus results. Here's a simple patch [1] and a successful scratch build [2], with all checks passing. Please let me know if I'm missing anything, but otherwise, I'll open a PR. Please don't and also abstain from submitting pull requests. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages silently dropping approved changes
On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar wrote: > > On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius wrote: > > > > Am 25.08.22 um 13:19 schrieb Iñaki Ucar: > > > > > I assume their maintainers didn't do it on purpose, maybe it was > > > easier for a certain update, didn't have time to look into it and > > > weren't aware of the guideline. But this is very frustrating. Seeing > > > many hours of work just wiped out without any notice or explanation is > > > very frustrating. > > > > In my case (freefem++), it was actually was a mixture of all. > > > > To cut a long story short: This flexblas stuff doesn't "harmonize well" > > with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. > > > > Because of this, when going after freefem++'s regressions, years after > > the flexiblas changes had been introduced, I inadvertedly and > > accidentally reverted the flexblas related changes, because these > > apparently do not work out with freefem++. > > How exactly does flexiblas break freefem++? I see v4.10 was built just > fine. Then v4.11 reverted to openblas. If it works with openblas, I > see no reason to break with flexiblas, among other things because > openblas is the default backend. Moreover, arpack, superlu, > suitesparse and other BuildRequires link against flexiblas. In fact, freefem++ was one of the easiest packages to adapt: you just set the library, and it does nothing fancy nor too-clever to try to discover anything. Here's a simple patch [1] and a successful scratch build [2], with all checks passing. Please let me know if I'm missing anything, but otherwise, I'll open a PR. [1] https://src.fedoraproject.org/fork/iucar/rpms/freefem++/c/a9da37dfd71508b4bad124fdbfd190b417f0afb2 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=91253729 -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages silently dropping approved changes
On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius wrote: > > Am 25.08.22 um 13:19 schrieb Iñaki Ucar: > > > I assume their maintainers didn't do it on purpose, maybe it was > > easier for a certain update, didn't have time to look into it and > > weren't aware of the guideline. But this is very frustrating. Seeing > > many hours of work just wiped out without any notice or explanation is > > very frustrating. > > In my case (freefem++), it was actually was a mixture of all. > > To cut a long story short: This flexblas stuff doesn't "harmonize well" > with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. > > Because of this, when going after freefem++'s regressions, years after > the flexiblas changes had been introduced, I inadvertedly and > accidentally reverted the flexblas related changes, because these > apparently do not work out with freefem++. How exactly does flexiblas break freefem++? I see v4.10 was built just fine. Then v4.11 reverted to openblas. If it works with openblas, I see no reason to break with flexiblas, among other things because openblas is the default backend. Moreover, arpack, superlu, suitesparse and other BuildRequires link against flexiblas. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packages silently dropping approved changes
Am 25.08.22 um 13:19 schrieb Iñaki Ucar: I assume their maintainers didn't do it on purpose, maybe it was easier for a certain update, didn't have time to look into it and weren't aware of the guideline. But this is very frustrating. Seeing many hours of work just wiped out without any notice or explanation is very frustrating. In my case (freefem++), it was actually was a mixture of all. To cut a long story short: This flexblas stuff doesn't "harmonize well" with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++. Because of this, when going after freefem++'s regressions, years after the flexiblas changes had been introduced, I inadvertedly and accidentally reverted the flexblas related changes, because these apparently do not work out with freefem++. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Packages silently dropping approved changes
Hi all, Many of you know that proposing, discussing, and implementing a change proposal is quite an effort, especially if you do this in your spare time. I did this some releases ago in [1] to try to improve the situation regarding BLAS/LAPACK management in Fedora. It wasn't easy, but it was a success, and now we have specific packaging guidelines [2] and one of the best BLAS/LAPACK stacks out there IMHO. Given that this is not so common, I routinely (every now and then, not very often) check for new packages that may not be aware of this guideline, so that they may need adaptation. What I didn't expect was to find already adapted packages silently dropping this change, and going back to linking specific libraries instead of FlexiBLAS. :( I assume their maintainers didn't do it on purpose, maybe it was easier for a certain update, didn't have time to look into it and weren't aware of the guideline. But this is very frustrating. Seeing many hours of work just wiped out without any notice or explanation is very frustrating. I opened the corresponding BZ [3-4], but it would be great if these checks and BZ could be automated somewhere. If so, please let me know where the proper place for this is and I'll open an issue. [1] https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/BLAS_LAPACK/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2121388 [4] https://bugzilla.redhat.com/show_bug.cgi?id=2121389 -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
