From Fedora Project Wiki

 
(37 intermediate revisions by 11 users not shown)
Line 8: Line 8:
== Structure ==
== Structure ==
There are two tiers of architectures with Fedora support:
There are two tiers of architectures with Fedora support:
* [[PrimaryArchitectures|  Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. To put it simply: These are the architectures for which Fedora will delay a release if they are not functional. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
* [[PrimaryArchitectures|  Primary Architectures]] : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
* [[TomCallaway/SecondaryArchitecturesSecondary Architectures]] : These are architectures with motivated Architecture Maintainer Teams, and build hardware. Build failures on secondary architectures are not fatal: if packages successfully build for the primary architectures, they push independently of any secondary architecture build successes or failures.
* [[AlternativeArchitecturesAlternative Architectures]] : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.


{{Anchor|PrimaryArchitectures}}
{{Anchor|PrimaryArchitectures}}
=== Primary Architectures ===
=== Primary Architectures ===
* [[Architectures/ARM|ARM]] (as of Fedora 20)
* <strike>[[Architectures/ARM|ARM]]-hfp (32-bit, little-endian, hfp for ARMv7→) (as of Fedora 20, until Fedora 37)</strike>
* x86 (32-bit)
* <strike>[[Architectures/x86|x86]] (32-bit for i686→) (until Fedora 25)</strike>
* [[Architectures/x86-64|x86_64]] (64-bit)
* [[Architectures/x86-64|x86_64]] ([https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels v1] 64-bit)
* ARM [[Architectures/AArch64|AArch64]] (64-bit, little-endian for ARMv8→)
{{Anchor|SecondaryArchitectures}}
{{Anchor|SecondaryArchitectures}}


=== Secondary Architectures ===
=== Alternative Architectures ===
* [[Architectures/AArch64|ARM AArch64]]
* <strike>[[Architectures/ARM|ARM]]-sfp (32-bit, little-endian, sfp for ARMv5→)</strike>
* <strike>[[Architectures/IA64|IA64]]</strike>
* <strike>[[Architectures/IA64|IA64]]</strike>
* [[Architectures/MIPS|MIPS]]
* [[Architectures/MIPS|MIPS]]-64el (mips64r2, little endian, n64 ABI)
* [[Architectures/MIPS|MIPS]]-el (mips32r2, little endian, o32 ABI)
* <strike>[[Architectures/MIPS|MIPS]]-n32el (mips64r2, little endian, n32 ABI)</strike>
* <strike>[[Architectures/Parisc|Parisc]]</strike>
* <strike>[[Architectures/Parisc|Parisc]]</strike>
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike>
* <strike>[[Architectures/PowerPC|PowerPC]] (32-bit)</strike>
* [[Architectures/PowerPC|PowerPC64]] (64-bit big-endian)
* <strike>[[Architectures/PowerPC|PowerPC64]] (64-bit, big-endian for POWER5→)</strike>
* [[Architectures/PowerPC|PowerPC64le]] (64-bit little-endian) POWER8+
* [[Architectures/PowerPC|PowerPC64le]] (64-bit, little-endian for POWER8→)
* [[Architectures/s390x|s390x]] (64-bit)
* [[Architectures/RISC-V|RISC-V]] (64-bit open source ISA)
* [[Architectures/s390x|s390x]] (64-bit for zEC12→)
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike>
* <strike>[[Architectures/SPARC|SPARC]] (32-bit)</strike>
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit)</strike>
* <strike>[[Architectures/SPARC|SPARC64]] (64-bit for sun4u→)</strike>
* <strike>[[Architectures/x86|x86]] (32-bit for i686→) (Fedora 26 until Fedora 30)</strike>


{{Anchor|Architecture Maintainer Teams}}
{{Anchor|Architecture Maintainer Teams}}
Line 34: Line 39:
== Architecture Maintainer Teams ==
== Architecture Maintainer Teams ==


In order to manage and support secondary architectures, each secondary architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead.  
In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead.  


=== Architecture Maintainer Team Responsibilities ===
=== Architecture Maintainer Team Responsibilities ===


* Receiving notifications of secondary arch build successes and failures
* Receiving notifications of alternative arch build successes and failures
* Patching packages cleanly such that they build and function correctly on the secondary architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages (with some exceptions, such as, glibc, kernel, anaconda), permitting them special access to make changes. This ability requires a great amount of respect, and secondary architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.
* Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.
* Resolving architecture specific bugs filed against packages
* Resolving architecture specific bugs filed against packages
* Holding regular status meetings on IRC for the architecture
* Holding regular status meetings on IRC for the architecture
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for secondary architectures will be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If a secondary architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.
* Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.
* Maintaining and hosting the buildserver(s) and storage for that architecture
* Maintaining and hosting the buildserver(s) and storage for that architecture
* Composing trees for that architecture
* working with [https://docs.pagure.org/releng/ Release Engineering] on Composing trees for that architecture
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.
* Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.
* Deliver progress reports to FESCo on a monthly basis
* Participate in and give progress reports to the Release Engineering meeting on a weekly basis


Each secondary architecture maintainer team will have a dedicated mailing list (e.g. fedora-sparc-list) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.
Each alternative architecture maintainer team will have a dedicated mailing list (e.g. fedora-arm@lists.fp.o) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.


There is a generic secondary arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org]  one or more team members should subscribe here.
There is a generic alternative arch list at [https://admin.fedoraproject.org/mailman/listinfo/secondary secondary@lists.fedoraproject.org]  one or more team members should subscribe here.


In addition, secondary architecture teams '''should''' do the following:
In addition, alternative architecture teams '''should''' do the following:
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)
* Run regular 'rebuild all in mock' runs (usually requires dedicated system)


Line 58: Line 63:


=== Buildsystems ===
=== Buildsystems ===
Secondary architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to provide hosting space for Secondary architecture systems at this time. Secondary Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors.  All builds have to happen in a native environment.  this means cross compiling is not allowed,  you can however use virtualisation to emulate your target system.
Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors.  All builds have to happen in a native environment.  this means cross compiling is not allowed,  you can however use virtualisation to emulate your target system.


=== File Storage ===
=== File Storage ===
Secondary architectures will need to provide their own file storage for the buildsystem, composed trees will be hosted at http://secondary.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror secondary architecture trees on an arch-by-arch basis.
Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.


=== Tree Composition ===
=== Tree Composition ===
Fedora Release Engineering will not have any responsibility for composing Secondary Architecture trees. Composing trees and install media is the responsibility of the Secondary Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).
Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).


=== Sandbox Systems ===
=== Sandbox Systems ===
Secondary architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.
Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.


'''***TODO***''' Document how to set this up.
'''***TODO***''' Document how to set this up.
Line 76: Line 81:


=== Divergence from Primary Architectures ===
=== Divergence from Primary Architectures ===
Secondary architecture package trees should be as close to primary architecture package trees as possible. Secondary architectures should not use older versions or customized (hacked up) packages. Secondary architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support secondary architectures must be committed in GIT for each package.
Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.


=== ExcludeArch & ExclusiveArch ===
=== ExcludeArch & ExclusiveArch ===
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.
Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.


By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new secondary architectures, rather than being immediately ignored by a blanket ExclusiveArch.
By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling


=== Tracker Bugs ===
=== Tracker Bugs ===
Any packager which sets ExcludeArch for an architecture must open a bug against that package, and block that bug against the appropriate ExcludeArch blocker bug.
Any packager which excludes an architecture for a package needs to open a [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures  bug report against an ExcludeArch blocker bug].
 
This will help the architecture team track and fix packages for their architecture.
This will help the Secondary Architecture team track and fix packages for their architecture.

Latest revision as of 12:50, 19 June 2024

Fedora Architectures

Author: Tom 'spot' Callaway, others



Structure

There are two tiers of architectures with Fedora support:

  • Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
  • Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures.

Primary Architectures

  • ARM-hfp (32-bit, little-endian, hfp for ARMv7→) (as of Fedora 20, until Fedora 37)
  • x86 (32-bit for i686→) (until Fedora 25)
  • x86_64 (v1 64-bit)
  • ARM AArch64 (64-bit, little-endian for ARMv8→)

Alternative Architectures

  • ARM-sfp (32-bit, little-endian, sfp for ARMv5→)
  • IA64
  • MIPS-64el (mips64r2, little endian, n64 ABI)
  • MIPS-el (mips32r2, little endian, o32 ABI)
  • MIPS-n32el (mips64r2, little endian, n32 ABI)
  • Parisc
  • PowerPC (32-bit)
  • PowerPC64 (64-bit, big-endian for POWER5→)
  • PowerPC64le (64-bit, little-endian for POWER8→)
  • RISC-V (64-bit open source ISA)
  • s390x (64-bit for zEC12→)
  • SPARC (32-bit)
  • SPARC64 (64-bit for sun4u→)
  • x86 (32-bit for i686→) (Fedora 26 until Fedora 30)

Architecture Maintainer Teams

In order to manage and support alternative architectures, each alternative architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead.

Architecture Maintainer Team Responsibilities

  • Receiving notifications of alternative arch build successes and failures
  • Patching packages cleanly such that they build and function correctly on the alternative architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages, permitting them special access to make changes. This ability requires a great amount of respect, and alternative architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.
  • Resolving architecture specific bugs filed against packages
  • Holding regular status meetings on IRC for the architecture
  • Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for alternative architectures can be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If an alternative architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.
  • Maintaining and hosting the buildserver(s) and storage for that architecture
  • working with Release Engineering on Composing trees for that architecture
  • Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.
  • Participate in and give progress reports to the Release Engineering meeting on a weekly basis

Each alternative architecture maintainer team will have a dedicated mailing list (e.g. fedora-arm@lists.fp.o) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.

There is a generic alternative arch list at secondary@lists.fedoraproject.org one or more team members should subscribe here.

In addition, alternative architecture teams should do the following:

  • Run regular 'rebuild all in mock' runs (usually requires dedicated system)

Logistics

Buildsystems

Alternative architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to guarantee to provide hosting space for Alternative Architecture systems at this time. Alternative Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure and be accessed by all fedora contributors. All builds have to happen in a native environment. this means cross compiling is not allowed, you can however use virtualisation to emulate your target system.

File Storage

Alternative architectures will need to provide their own file storage for the buildsystem, there may be some available from Fedora Infrastructure, composed trees will be hosted at https://dl.fedoraproject.org/pub/fedora-secondary. Fedora mirrors can choose whether they wish to mirror alternative architecture trees on an arch-by-arch basis.

Tree Composition

Fedora Release Engineering will not have any responsibility for composing Alternative Architecture trees for Architectures that are built outside of primary koji. Composing trees and install media is the responsibility of the Alternative Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).

Sandbox Systems

Alternative architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with packager access can ssh into the box, using their FAS credentials.

***TODO*** Document how to set this up.

While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.

Packaging Issues

Divergence from Primary Architectures

Alternative architecture package trees should be as close to primary architecture package trees as possible. Alternative architectures should not use older versions and must not use customized (hacked up) packages. Alternative architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support alternative architectures must be committed in GIT for each package.

ExcludeArch & ExclusiveArch

Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.

By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new alternative architectures, rather than being immediately ignored by a blanket ExclusiveArch. There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling

Tracker Bugs

Any packager which excludes an architecture for a package needs to open a bug report against an ExcludeArch blocker bug. This will help the architecture team track and fix packages for their architecture.