(Reorganize and mention update procedure) |
|||
Line 9: | Line 9: | ||
* Preparing infrastructure for fix verification for Fedora developers. | * Preparing infrastructure for fix verification for Fedora developers. | ||
== | == Discovering Packages Which Need Fixing == | ||
We build packages with instrumented `gcc` and `redhat-rpm-config` packages that fail the build if certain errors occur anywhere during the build. These forced failures are guaranteed to happen even if the build system ignores the exit status of a `gcc` command and continues regardless (for example, during `configure` checks). This is implemented by patching `gcc` in a special buildroot to log certain errors to a 1777 (sticky bit permission) directory. After the build, `redhat-rpm-config` checks if the directory is empty (or more precisely, only contains expected errors), and fails the build otherwise. | We build packages with instrumented `gcc` and `redhat-rpm-config` packages that fail the build if certain errors occur anywhere during the build. These forced failures are guaranteed to happen even if the build system ignores the exit status of a `gcc` command and continues regardless (for example, during `configure` checks). This is implemented by patching `gcc` in a special buildroot to log certain errors to a 1777 (sticky bit permission) directory. After the build, `redhat-rpm-config` checks if the directory is empty (or more precisely, only contains expected errors), and fails the build otherwise. | ||
Line 15: | Line 15: | ||
* [https://src.fedoraproject.org/fork/fweimer/rpms/gcc/tree/c99-port rawhide gcc fork with instrumentation] | * [https://src.fedoraproject.org/fork/fweimer/rpms/gcc/tree/c99-port rawhide gcc fork with instrumentation] | ||
* [https://src.fedoraproject.org/fork/fweimer/rpms/redhat-rpm-config/tree/c99-port rawhide redhat-rpm-config fork with instrumentation] | * [https://src.fedoraproject.org/fork/fweimer/rpms/redhat-rpm-config/tree/c99-port rawhide redhat-rpm-config fork with instrumentation] | ||
=== Special COPR repository with instrumented GCC === | === Special COPR repository with instrumented GCC === | ||
Line 54: | Line 46: | ||
""" | """ | ||
</nowiki> | </nowiki> | ||
== Fedora Package Updates == | |||
All identified issues need to be fixed in rawhide eventually. If a package cannot be ported, a bug needs to be filed in Bugzilla blocking [https://bugzilla.redhat.com/show_bug.cgi?id=2137516 PortingToModernCExemptions] to record this, and the package still needs to build in an early C language mode (probably C89 or C99). | |||
If an upstream fix becomes available, it may make sense to backport it before a package rebase, so that the package no longer shows up as needed porting worj. | |||
Compatibility packages and other legacy packages need to be fixed as well. | |||
=== Documenting Changes === | |||
* Fedora dist-git commit message should refer [[Changes/PortingToModernC]] and [[Toolchain/PortingToModernC]] (this page). | |||
* Fedora updates should be captured in the [fedora-modernc](https://gitlab.com/fweimer-rh/fedora-modernc) tracking repository. Please send MRs there if you fix something. | |||
* Changes that merely included what would come in through a future rebase do not need a bug in Bugzilla or filing an issue with upstream. This includes backports from upstream, or patches which merely change generated files when re-generation using the current tool version would also fix the issues. (The latter is common with old `configure` scripts.) | |||
* A bug needs to be filed in Bugzilla if there is no way to report the issue upstream, blocking [https://bugzilla.redhat.com/show_bug.cgi?id=2141798 PortingToModernCNoUpstream]. | |||
* If a package cannot be ported, a bug needs to be filed blocking [https://bugzilla.redhat.com/show_bug.cgi?id=2137516 PortingToModernCExemptions]. | |||
== Cross-Distribution Collaboration == | == Cross-Distribution Collaboration == |
Revision as of 07:44, 21 November 2022
Porting Fedora to Modern C
This page collects some technical details related to Changes/PortingToModernC.
Status
- Gathering data on implicit function declarations (e.g.,
exit (0)
called without#include <stdlib.h>
). - Gathering data on implicit
int
s (e.g., const TWO = 2). - Preparing infrastructure for fix verification for Fedora developers.
Discovering Packages Which Need Fixing
We build packages with instrumented gcc
and redhat-rpm-config
packages that fail the build if certain errors occur anywhere during the build. These forced failures are guaranteed to happen even if the build system ignores the exit status of a gcc
command and continues regardless (for example, during configure
checks). This is implemented by patching gcc
in a special buildroot to log certain errors to a 1777 (sticky bit permission) directory. After the build, redhat-rpm-config
checks if the directory is empty (or more precisely, only contains expected errors), and fails the build otherwise.
Special COPR repository with instrumented GCC
A COPR repository contains instrumented packages. Builds fail if
From time to time, error checking will break if newer gcc
or redhat-rpm-config
builds arrive in rawhide.
The following mock
configuration can be used for local builds.
config_opts['target_arch'] = 'x86_64' config_opts['legal_host_arches'] = ('x86_64',) include('templates/fedora-rawhide.tpl') config_opts['root'] = 'fedora-rawhide-modernc' config_opts['dnf.conf'] += """ [copr-fweimer-modernc] name=COPR with instrumented GCC for modern C porting baseurl=https://download.copr.fedorainfracloud.org/results/fweimer/modernc-1/fedora-rawhide-$basearch/ type=rpm-md skip_if_unavailable=False gpgcheck=1 gpgkey=https://download.copr.fedorainfracloud.org/results/fweimer/modernc-1/pubkey.gpg repo_gpgcheck=0 enabled=1 enabled_metadata=1 """
Fedora Package Updates
All identified issues need to be fixed in rawhide eventually. If a package cannot be ported, a bug needs to be filed in Bugzilla blocking PortingToModernCExemptions to record this, and the package still needs to build in an early C language mode (probably C89 or C99).
If an upstream fix becomes available, it may make sense to backport it before a package rebase, so that the package no longer shows up as needed porting worj.
Compatibility packages and other legacy packages need to be fixed as well.
Documenting Changes
- Fedora dist-git commit message should refer Changes/PortingToModernC and Toolchain/PortingToModernC (this page).
- Fedora updates should be captured in the [fedora-modernc](https://gitlab.com/fweimer-rh/fedora-modernc) tracking repository. Please send MRs there if you fix something.
- Changes that merely included what would come in through a future rebase do not need a bug in Bugzilla or filing an issue with upstream. This includes backports from upstream, or patches which merely change generated files when re-generation using the current tool version would also fix the issues. (The latter is common with old
configure
scripts.) - A bug needs to be filed in Bugzilla if there is no way to report the issue upstream, blocking PortingToModernCNoUpstream.
- If a package cannot be ported, a bug needs to be filed blocking PortingToModernCExemptions.
Cross-Distribution Collaboration
A mailing list has been set up to exchange issues and observations of wider interest: c-std-porting@lists.linux.dev (archive)
Further resources will follow as needed.
Fedora Change Tracking
Changes to Fedora packages should be captured in the [fedora-modernc](https://gitlab.com/fweimer-rh/fedora-modernc) tracking repository.
Not every build issue will have a bug in Bugzilla. But if there is no upstream with a mailing list or issue tracker to submit fixes to, it makes sense to create a bug in Bugzilla, especially for cross-distribution collaboration.
Currently, these trackers exist:
- PortingToModernC Umbrella tracker for the tracker bugs below.
- PortingToModernCExemptions Bugs which document that certain packages could not be switched to C99 or later language standards. Typically these packages keep building with
-std=gnu89
. - PortingToModernCHelpNeeded Bugs where help from the package maintainer is needed to address the issue(s).
- PortingToModernCNoUpstream Bugs to provide a reference where there is either no upstream, or the current upstream lacks a public bug tracker or version control repository
Contributing To The Porting Effort
If you want to contribute to this effort, you should subscribe to the c-std-porting
list mentioned above. If you create a Red Hat Bugzilla account, log in, and visit the Bugzilla tracker bugs linked above, a Add me to CC list check mark will appear on the bug pages. If you check that and click the Save Changes button, you will be notified of future bug changes, including bug dependency changes that indicate new issues. You can also subscribe to individual bugs that interest you.
At this point, it is too early to tell what level of knowledge and open-source experience is typically needed to successfully contribute to this project.