Latest revision as of 13:11, 26 August 2021

Autoconf-2.71

Summary

Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.

Owner

Name: Ondrej Dubaj
Email: odubaj@redhat.com

Current status

Targeted release: Fedora Linux 36
Last updated: 2021-08-26
FESCo issue: #2579
Tracker bug: #1936597
Release notes tracker: #661

Detailed Description

Upgrading autoconf from version 2.69 to version 2.71 according to new upstream release. Version 2.70 is skipped due to multiple ABI incompatibilities, where some of them were fixed in version 2.71. Years of development differ these two releases, so problems are expected.

This change might easily cause fails during builds of multiple packages, as some of them still require autoconf-2.69. This step must be properly discussed with maintainers of dependent packages, which should forward this change proposal to their upstream projects.

Feedback

Benefit to Fedora

Brings a stable and up-to-date version of autoconf according to upsteam release. It is expected, that in the future many upstream development teams will use autoconf-2.71 as their default builder, so Fedora will be prepared for such a step.

Scope

Proposal owners:
- Prepare autoconf-2.71 as RPM package for Fedora Rawhide
- Prepare autoconf2.69-2.69 as RPM compat package for Fedora Rawhide
- Check software that requires autoconf or autoconf-2.69 and rebuild it with autoconf-2.71, if failed and autoconf-2.69 is required, compat package will be used
- Build autoconf-2.71 to Rawhide in a side-tag (https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
- Rebuild depended packages with autoconf-2.71 in the side-tag
- Merge the side-tag to Rawhide

Other developers:
- Check if their packages can be build with autoconf-2.71, if not, they are required to use autoconf2.69-2.69 compat package and also are required to make the appropriate changes to their packages.
Release engineering: #Releng issue number
- Developers are advised to check their packages and build them in a prepared side-tag with autoconf-2.71, if failed, they are required to use compat package instead

Policies and guidelines:
- No guidelines need to be updated according to this change.

Trademark approval:

Alignment with Objectives:

Upgrade/compatibility impact

Problems during build can appear in multiple packages what can lead to build failure, as multiple packages require autoconf-2.69 as their upstream dependency. These problems have to be resolved before adding autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages are having problems during build, which could be caused by a problem with same pattern.

How To Test

Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).

The best way to rebuild new version of package against autoconf-2.71 is to create a pull-request against your dist-git repository (against rawhide branch). After that, you package will be automatically rebuild in the mentioned copr. Please find your package in the "Builds" tab and search in the various sub-tabs for your build.

If possible, please prepare a pull-request, so you can easily merge it, when the change will be executed.

For local testing and building, please download mock-config from the given copr repository and use it with your mock:

copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg

mv odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg /etc/mock

Now we may run: mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild <package-1.0-1.src.rpm>

Common failures and appropriate fixes available here: https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit?usp=sharing

Please do not hesitate to provide you own fix by using comment or proposing a suggestion to the document

If there is a need to test packages for other architectures than x86_64, we can use module chain-builds. Please use this option only in case you are not able to test the changes using mock or copr. Big thanks to Honza Horak for this idea and providing the yaml file.

All you need is to make appropriate changes, push them to private branch in fedora dist-git, modify the provided testmodule.yaml file and run fedpkg module-build --scratch --file testmodule.yaml --watch. After this, please wait for the results. It may take a while, as building autoconf-2.71 can take up to 1 hour.

---

 document: modulemd
 version: 2
 data:
   name: testmodule
   stream: 1.0
   summary: Testing a thing
   description: Just for a testing purposes
   license:
     module: [MIT]
   dependencies:
     - buildrequires:
         platform: [f35]
       requires:
         platform: [f35]
   components:
     rpms:
       autoconf:
         rationale: autoconf-2.71
         ref: private-rawhide-autoconf-2.71
         buildorder: 0
       unixODBC:
         rationale: package to be tested
         ref: private-rawhide-autoconf-2.71
         buildorder: 1

After merging the changes needed for autoconf-2.71 and successfully building the package, scratch-builds for all dependent packages will be scheduled to verify everything works as expected. After the scratch-builds will be done, F36FTBFS tracking issues will be created in bugzilla for all packages, which have failed during the scratch-rebuild. There is no need to do a regular build for dependent packages, as we are testing only build-time functionality and run-time functionality of packages should not be changed with autoconf-2.71. Therefore there is no need to do a regular release bump and a build.

User Experience

Users will be able to use the newer version (2.71) of autoconf, and building packages with autoconf-2.69 won't be available, as it won't be present on the specific fedora version. This can affect 3rd partly packages, which are not part of Fedora.

Dependencies

Hundreds of packages have build dependency on autoconf, therefore it is a huge step forward for Fedora, what should be properly discussed and tested. List of dependent packages with their ability to be built with autoconf-2.71 can be found in the given copr project (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)

We should also look at dependent packages of libtool and automake (other critical autotools packages), as there might be some incompatibilities with the new autoconf version.

Contingency Plan

Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide
Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
Blocks release? No

Documentation

Latest autoconf documentation: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html

Release Notes

Release notes for autoconf-2.70: https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html

Release notes for autoconf-2.71: https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html

@@ Line 20: / Line 20: @@
 == Current status ==
-[[Category:ChangeAnnounced]]
+[[Category:ChangeAcceptedF36]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 27: / Line 27: @@
 <!-- Select proper category, default is Self Contained Change -->
-[[Category:SelfContainedChange]]
+[[Category:SystemWideChange]]
 <!-- [[Category:SystemWideChange]] -->
-* Targeted release: [[Releases/35 | Fedora 35 ]]
+* Targeted release: [[Releases/36 | Fedora Linux 36 ]]
 * Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
@@ Line 38: / Line 38: @@
 ON_QA -> change is fully code complete
 -->
-* FESCo issue: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/2579 #2579]
-* Tracker bug: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1936597 #1936597]
-* Release notes tracker: <will be assigned by the Wrangler>
+* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/661 #661]
 == Detailed Description ==
@@ Line 86: / Line 86: @@
 <!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 **Prepare autoconf-2.71 as RPM package for Fedora Rawhide
-**Check software that requires `autoconf` or `autoconf-2.69` and rebuild it with autoconf-2.71
+**Prepare autoconf2.69-2.69 as RPM compat package for Fedora Rawhide
+**Check software that requires `autoconf` or `autoconf-2.69` and rebuild it with autoconf-2.71, if failed and autoconf-2.69 is required, compat package will be used
 **Build autoconf-2.71 to Rawhide in a side-tag (https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
 **Rebuild depended packages with autoconf-2.71 in the side-tag
@@ Line 93: / Line 94: @@
 * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
-**Check if their packages can be build with autoconf-2.71
+**Check if their packages can be build with autoconf-2.71, if not, they are required to use autoconf2.69-2.69 compat package and also are required to make the appropriate changes to their packages.
 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
 The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
+**Developers are advised to check their packages and build them in a prepared side-tag with autoconf-2.71, if failed, they are required to use compat package instead
-* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Policies and guidelines: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
+**No guidelines need to be updated according to this change.
-* Trademark approval: N/A (not needed for this Change)
+* Trademark approval:
 <!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
@@ Line 132: / Line 135: @@
 Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).
-Mass rebuild of dependent packages in a side tag.
+The best way to rebuild new version of package against autoconf-2.71 is to create a pull-request against your dist-git repository (against rawhide branch). After that, you package will be automatically rebuild in the mentioned copr. Please find your package in the "Builds" tab and search in the various sub-tabs for your build.
+If possible, please prepare a pull-request, so you can easily merge it, when the change will be executed.
+For local testing and building, please download mock-config from the given copr repository and use it with your mock:
+`copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64  > odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg`
+`mv odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg /etc/mock`
+Now we may run:
+`mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild <package-1.0-1.src.rpm>`
+Common failures and appropriate fixes available here:
+https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit?usp=sharing
+Please do not hesitate to provide you own fix by using comment or proposing a suggestion to the document
+If there is a need to test packages for other architectures than x86_64, we can use module chain-builds. Please use this option only in case you are not able to test the changes using mock or copr. Big thanks to Honza Horak for this idea and providing the yaml file.
+All you need is to make appropriate changes, push them to private branch in fedora dist-git, modify the provided testmodule.yaml file and run `fedpkg module-build --scratch --file testmodule.yaml  --watch`. After this, please wait for the results. It may take a while, as building autoconf-2.71 can take up to 1 hour.
+` ---
+  document: modulemd
+  version: 2
+  data:
+    name: testmodule
+    stream: 1.0
+    summary: Testing a thing
+    description: Just for a testing purposes
+    license:
+      module: [MIT]
+    dependencies:
+      - buildrequires:
+          platform: [f35]
+        requires:
+          platform: [f35]
+    components:
+      rpms:
+        autoconf:
+          rationale: autoconf-2.71
+          ref: private-rawhide-autoconf-2.71
+          buildorder: 0
+        unixODBC:
+          rationale: package to be tested
+          ref: private-rawhide-autoconf-2.71
+          buildorder: 1`
+After merging the changes needed for autoconf-2.71 and successfully building the package, scratch-builds for all dependent packages will be scheduled to verify everything works as expected. After the scratch-builds will be done, F36FTBFS tracking issues will be created in bugzilla for all packages, which have failed during the scratch-rebuild. There is no need to do a regular build for dependent packages, as we are testing only build-time functionality and run-time functionality of packages should not be changed with autoconf-2.71. Therefore there is no need to do a regular release bump and a build.
 == User Experience ==
 <!-- If this change proposal is noticeable by users, how will their experiences change as a result?

Search

Changes/Autoconf 271: Difference between revisions