Latest upstream release: 2.70 Current version/release in rawhide: 2.69-34.fc33 URL: http://www.gnu.org/software/autoconf/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/141/
An HTTP error occurred downloading the package's new Source URLs: Getting http://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz to ./autoconf-2.70.tar.xz
FEDORA-2020-457325b654 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-457325b654
So, this breaks many packages including Python: https://koschei.fedoraproject.org/affected-by/autoconf?epoch1=0&version1=2.69&release1=34.fc33&epoch2=0&version2=2.70&release2=1.fc34&collection=f34 + autoconf Can't locate File/Compare.pm in @INC (you may need to install the File::Compare module) (@INC contains: /usr/share/autoconf /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /usr/share/autoconf/Autom4te/FileUtils.pm line 142. BEGIN failed--compilation aborted at /usr/share/autoconf/Autom4te/FileUtils.pm line 142. Compilation failed in require at /usr/bin/autom4te line 46. BEGIN failed--compilation aborted at /usr/bin/autom4te line 46.
2.69 => 2.70 is huge step forward. I'd even suggest testing this in Copr first (build 2.70 and rebuild all packages that depend on libtool/automake/autoconf against that)
Understand, sorry for the problems. Working immeadiately on untaging the build safely from rawhide.
> Working immeadiately on untaging the build safely from rawhide. Thanks.
According to the documentation https://fedoraproject.org/wiki/Package_maintenance_guide#Removing_a_package_build_pending_for_Rawhide_or_Branched I am experiencing some issues with permissions $ koji untag-pkg f34 autoconf-2.70-1.fc34 2020-12-09 10:58:13,217 [ERROR] koji: ActionNotAllowed: tag requires autosign permission
This gas been untagged via https://pagure.io/releng/issue/9895
(In reply to Pavel Raiskup from comment #4) > 2.69 => 2.70 is huge step forward. I'd even suggest testing this in Copr > first > (build 2.70 and rebuild all packages that depend on libtool/automake/autoconf > against that) It might deserve change proposal? https://docs.fedoraproject.org/en-US/program_management/changes_policy/
Latest upstream release: 2.71 Current version/release in rawhide: 2.69-35.fc34 URL: http://www.gnu.org/software/autoconf/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/141/
Created attachment 1751887 [details] [patch] Update to 2.71 (#1905678)
the-new-hotness/release-monitoring.org's scratch build of autoconf-2.71-1.fc32.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=60775815
Just a note. I've got a way we can do widespread testing of an autoconf upgrade. In particular I have a Jenkins builder which knows about all the binary packages in Fedora. It also has the ability to inject a priority repo into the build process to override packages from the standard buildroot. The jobs are set up to do a package build with and without the priority repo and save the generated config.h files from both builds. If both package builds pass and the generated config.h files are identical, then the job is considered successful otherwise it's a failure and can be investigated. This was used to evaluate the effects of LTO on F33, including capturing issues with LTO optimizing away poorly written autoconf tests. We've also used it extensively to find potential problems with compiler updates in Fedora. If you'd like me to run a build with a autoconf candidate, don't hesitate to reach out.
Jeff, thanks for your note. Testing with your Jenkins builder will be awesome. Currently we are testing package build using copr and rebuilding all dependent packages (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/). This seems to be a great opportunity to validate if the new version of autoconf didn't break anything. What do you need from me to run the Jenkins build ? Thanks!
build available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=61096508
Change proposal: https://fedoraproject.org/wiki/Changes/Autoconf_271
So I think a reasonable plan for testing would be to start the builder next week with the autoconf build referenced above. I'll pass along a URL for the jenkins instance once things are spinning.
Great, thank you very much.
Rebase prepared in PR: https://src.fedoraproject.org/rpms/autoconf/pull-request/8#
Compat package for autoconf-2.69 prepared below: for non-paralell instalation with autoconf-2.71: https://src.fedoraproject.org/rpms/autoconf/pull-request/9# for paralell instalation with autoconf-2.71: https://src.fedoraproject.org/rpms/autoconf/pull-request/10