Hello,
Thank you for your suggestions, but as you might understand, I do not have the capacity to resolve problems of dependent packages when building with autoconf-2.71.
I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for other maintainers, so they are able to make appropriate changes and test them in copr. Testing is possible by pushing the changes to a new created branch "rawhide-autoconf-2.71", where in your package you can use autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for autoconf-2.69). After pushing to the given branch, the package will be built automatically in copr and you can test the update of your package. You can do this many times until you are certain your package works good.
Thanks for understanding and cooperation.
Ondrej
On Tue, Mar 9, 2021 at 10:19 AM Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote:
_______________________________________________On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj <odubaj@xxxxxxxxxx> wrote:If any concerns about the autoconf2.69-2.69 compat package ? If needed it can be implemented as non-parallelly instalable,Really .. instead wasting time on packaging stuff which is ~7 years old it would be better to use that time to fix one of those handful packages which are still not ac 2.71 compliant (like openldap https://bugs.openldap.org/show_bug.cgi?id=9485).Listing all those failing packages + posting URL from where is possible to upload ac 2.71 package would allow more people to work on those few remaining packages which still needs to be cleaned/updated.Otherwise some stuff will end up like the firefox, mozjs, nss, nspr packages which still are using even older autoconf :/ (which is in own sense ridiculous that one of the most actively maintained source trees still is using so old build tooling)Some time ago gcc, binutils IIRC received an update for ac 2.71 so at least those two should be by now off-the-table (Am I right?).In many cases executing "autoupdate", adding patch out of the changes generated by that command to spec and submitting PR/MR against the original source tree is all what needs to be done. This is not rocket science ..So .. anyone knows any other packages dist sources trees on which something like "autoreconf -fiv" fails?So far I found only two like that: openldap and gettext (in that case most of the issues are caused by using gnulib which is another swampy area).It is still plenty of time before the f35 cycle needs to be finished, and still it can be done RightWay(tm) .. no rush.For now posting ~óne time a week with updates about progress on wiping out ac 2.69 should allow IMO final upgrade autoconf to 2.71 relatively soon.kloczek--Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
