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(a)gmail.com>
wrote:
On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj <odubaj(a)redhat.com>
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(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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure