Arch Linux RFCs

0001 Using RFCs

Mon, 01 Jan 0001 00:00:00 +0000

Using RFCs#

Date proposed: 2021-02-03
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1

Summary#

A Request for Comment (RFC) is a way for Arch Linux contributors to propose, design, and discuss new features and changes in project direction in a focused environment.

Motivation#

Finding consensus on overarching or more involved topics in Arch Linux has historically been driven by discussions on mailing lists, in the distribution’s various IRC channels, the wiki and the forums. While under certain circumstances this process is still valid and does work, it has a tendency to lead to unfocused and inconclusive discussions while lacking a transparent process. In addition, the results of decision-making are often oblique to newcomers, as they may only exist in the logs of chats or mailing lists, that are not accessible to everyone. When considering the different entities (project leader, developers, trusted users, support staff) that Arch Linux consists of, it becomes apparent that distribution-wide topics do not have a platform, as the specific entities have specialized (access-restricted) communication channels and concern themselves (sometimes exclusively) with a specialized topic.

0002 Provide a x86-64-v3 microarchitecture level port

Mon, 01 Jan 0001 00:00:00 +0000

Provide a x86-64-v3 microarchitecture level port#

Date proposed: 2020-03-02
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0002

Summary#

Provide a second Arch Linux port using -march=x86-64-v3 in the build flags.

Motivation#

Arch used to pride itself in providing optimised binaries out of the box. However, the days where our i686 showed improvements over other distributions are long behind us.

Recently, AMD, Intel, Red Hat, and SUSE collaborated to define three x86-64 microarchitecture levels on top of the x86-64 baseline. The three microarchitectures group together CPU features roughly based on hardware release dates.

0003 Updates to build flags

Mon, 01 Jan 0001 00:00:00 +0000

Updates to build flags#

Date proposed: 2020-03-04
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0003

Summary#

Updating our buildflags will improve our packages security.

Motivation#

Compiler security features have advanced since we last updated our buildflags. While we have enabled some of these by default in our compilers, there is further improvements to be made.

This RFC puts forward a set of compiler flags that have seen real world usage in other distributions e.g. Fedora and Ubuntu.

Specification#

We will change the distributed makepkg.conf to the following:

0004 LTO by Default

Mon, 01 Jan 0001 00:00:00 +0000

LTO by Default#

Date proposed: 2021-02-04
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0004

Summary#

Enable link time optimization (LTO) of packages by default by adding the -flto flag. This provides smaller, faster executables/DSOs, and improves GCC diagnostics.

Motivation#

Arch packages are super slow, and they need to be super fast! One way to improve optimisation is through LTO.

LTO gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module. This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time). Clang does similar LTO, but dumps its internal representation as LLVM byte-code.

0006 Adoption of a distribution-wide Code of Conduct

Mon, 01 Jan 0001 00:00:00 +0000

Adoption of a distribution-wide Code of Conduct#

Date proposed: 2021-09-15
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6

Summary#

The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it.

Motivation#

A Code of Conduct is a useful document to describe the "norms, rules, and responsibilities or proper practices of an individual party or an organization" (see Wikipedia article). Arch Linux is a community of entities, that consists of direct participants such as developers, trusted users, support staff and users that communicate with one another over various channels. As with all social constructs, the Arch Linux community is not immune to disagreements on technical or personal level.

0007 Rename the Trusted User role

Mon, 01 Jan 0001 00:00:00 +0000

Rename the Trusted User role#

Date proposed: 2021-10-07
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7

Summary#

It was shown in some cases that the Trusted User (TU) role naming led to some confusion and misunderstanding in broader contexts outside Arch Linux. Furthermore, it has been discussed that it also resulted in similar confusion among members of Arch Linux internally. This RFC remedies that with a better-suited term to reflect more accurately upon TUs’ roles and responsibilities as well as their position in the Arch Linux Organisation.

0009 Mediation Program

Mon, 01 Jan 0001 00:00:00 +0000

Mediation Program#

Date proposed: 2021-12-07
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/9

Summary#

Add an official mediation program to our organization consisting of elected mediators to help settle disputes and provide a clear escalation path.

Motivation#

Currently, we lack an established way to settle personal disputes. Furthermore, we do not provide a visible escalation path, making resolving a dispute or acquiring help for a two-or-more-sided resolution intransparent. Without mediators and an escalation path, we risk people emotionally resigning when a dispute cannot be resolved independently. The mediation program helps to mitigate the risk of losing contributors and aims to prevent social barriers between people. Our staff and volunteers are our most valuable resource after all.

0010 Adopt PEP 517 tooling for Python packages

Mon, 01 Jan 0001 00:00:00 +0000

Adopt PEP 517 tooling for Python packages#

Date proposed: 2022-02-19
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0010

Summary#

Replace setup.py with PEP 517 tooling (python-build/python-installer) for all Python packages where this approach is viable.

Motivation#

There are two main points.

Direct `setup.py` calls are deprecated#

The setuptools upstream has deprecated direct setup.py calls, and plans to remove support for them in the future. Please see setuptools#2088 and setuptools#2080 for more context.

`setup.py install` calls install old-style Python metadata#

The metadata installed by setup.py install is the old-style "egg" format (.egg-info). This is essentially implementation-defined by setuptools and has been replaced by a standardized format (.dist-info). By moving to the PEP 517 tooling, we will be using the wheel format, which has the standardized metadata.

0011 Store PGP keys for source file signatures alongside the PKGBUILD

Mon, 01 Jan 0001 00:00:00 +0000

Store PGP keys for source file signatures alongside the PKGBUILD#

Date proposed: 2022-03-20
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/11

Summary#

Store the PGP signing keys listed in a PKGBUILD's validpgpkeys array alongside the PKGBUILD in our VCS.

Motivation#

The PGP keyserver infrastructure has become increasingly brittle over recent years. This can make helping with updates or rebuilds of packages difficult due to lack of access to the valid signing key. Having the signing key exported alongside the PKGBUILD would allow for anybody to import the key into their keyring and verify the source.

0014 Merge package repositories

Mon, 01 Jan 0001 00:00:00 +0000

Merge package repositories#

Date proposed: 2022-09-01
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14

Summary#

Merge the pacman repository [community] into [extra] as well as the packaging VCS location community into packages.

The [core] repository remains limited to Developers.

New Package Maintainers will be restricted to publish packages solely to [testing] for the first two months of their active packaging actions.

Motivation#

In early days, the Trusted User packagers were meant to be a completely decoupled group from Arch Linux and hence got a dedicated optional pacman repository and VCS. Over the time, the distinction of packages between [community] and [extra] became blurry and at the latest since the official re-integration and rename of the Trusted Users into the Arch Linux organization the barrier became moot and essentially just obstructive.

0016 Use SPDX license identifiers in PKGBUILDs

Mon, 01 Jan 0001 00:00:00 +0000

Use SPDX license identifiers in PKGBUILD#

Date proposed: 2022-11-17
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/16

Summary#

Change to using SPDX license identifiers in the PKGBUILD license value for packages in all repositories.

Motivation#

The license identifiers we use have become inadequate for the large array of open-source licenses in use today, and no longer properly describe the licenses that they are meant to represent. When it was devised, there was no commonly accepted standard for license identifiers, and so it was necessary to develop one that would work for Arch’s use case.

0017 Increase _FORTIFY_SOURCE level to 3

Mon, 01 Jan 0001 00:00:00 +0000

Increase _FORTIFY_SOURCE level to 3#

Date proposed: 2023-01-05
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0017

Summary#

Adjust packaging CFLAGS from -D_FORTIFY_SOURCE=2 to -D_FORTIFY_SOURCE=3 for better fortification coverage

Motivation#

For a long time, we have been using -D_FORTIFY_SOURCE=2 in our build flags to detect C memory management problems at build time. Recently, glibc (2.34) added \_FORTIFY_SOURCE=3 to add extra checking. This has been supported in clang for some time, and is now available in GCC with the release of version 12.

0019 Moderator role for the AUR

Mon, 01 Jan 0001 00:00:00 +0000

Moderator role for the AUR#

Date proposed: 2023-06-27
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/19

Summary#

Create a dedicated role for the moderation of the AUR that supports and eventually replaces the Package Maintainers as the current moderators.

Motivation#

Currently, Arch Linux has 64 Package Maintainers. Historically known as Trusted Users (TU), they had two main responsibilities: Moderation of the AUR and moving popular AUR packages to the official Arch Linux repositories. The combination of those two responsibilities has not worked out since quite some time, as most package maintainers simply do not really intend to moderate the platform. On the other hand potential moderators have a hard time applying as package maintainers just for the sake of moderating the AUR. This RFC proposes to split the old TU role into Package Maintainers and AUR Moderators to have a clear separation of concern and allow for an easier way to recruit AUR Moderators.

0020 Sources for Python packaging

Mon, 01 Jan 0001 00:00:00 +0000

Sources for Python packaging#

Date proposed: 2023-07-14
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20

Summary#

Default to not using PyPI for Python package sources and only use the platform if there is no other alternative.

Motivation#

Historically, Arch Linux has relied upon source distribution (sdist) tarballs hosted on PyPI for its Python packages.

However, over the years the use of the platform became more and more burdensome for packagers:

stable, predictable download links were no longer publicly advertised (instead download links with hashes are advertised over the web UI)
the availability of OpenPGP signatures for sources were deemed to obscurity by not showing them in the download section
eventually existing OpenPGP signatures were no longer available since they were deprecated in May 2023 (https://blog.pypi.org/posts/2023-05-23-removing-pgp/)

Moreover, several issues exist with sdist tarballs, that do not occur with upstream provided sources:

0021 Create a distribution Developer Manual

Mon, 01 Jan 0001 00:00:00 +0000

Create a distribution Developer Manual#

Date proposed: 2023-08-23
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0021

Summary#

This RFC proposes the migration of Arch Linux’s operational distro specifications from existing ArchWiki and other sources to a dedicated GitLab developer manual repository. The intention is to document how to run the distribution while leveraging GitLab’s collaboration features and streamlined workflows for maintaining and evolving the resulting specifications. This change aims to centralize and enhance the efficiency of specification management while preserving the integrity of the community-contributed content in the Wiki.

0023 Add -Wl,-z,pack-relative-relocs

Mon, 01 Jan 0001 00:00:00 +0000

Add -Wl,-z,pack-relative-relocs#

Date proposed: 2023-09-03
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0023

Summary#

Add -Wl,-z,pack-relative-relocs to our LDFLAGS in order to reduce the size of relocations.

Motivation#

-z pack-relative-relocs moves relative relocations from the .rela.dyn section into a new .relr.dyn section with a significantly more compact encoding, supported since glibc 2.36, GNU Binutils 2.38 and LLVM 15.

This can reduce the size of libraries a lot, e.g. the installed size of libphonenumber dropped from about 17 MB to 7 MB.

0025 Make dbus-broker our default D-Bus daemon

Mon, 01 Jan 0001 00:00:00 +0000

Make dbus-broker our default D-Bus daemon#

Date proposed: 2023-12-08
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/25

Summary#

Make dbus-broker our default D-Bus daemon, while still allowing the venerable dbus-daemon to be used and minimizing the disruption of existing installations.

Motivation#

dbus-broker provides better performance and higher reliability than dbus-daemon, with per-user accounting of resources in the broker. For more information, see the dbus-broker wiki.

It integrates better with systemd, asking the manager to start transient services when D-Bus services define systemd unit to be activated, avoiding launching services into the D-Bus daemon's cgroup.

0026 Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Mon, 01 Jan 0001 00:00:00 +0000

Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to#

Date proposed: 2023-12-14
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/26

Summary#

This RFC proposes to add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to the default compilation flags to improve the effectiveness of profiling and debugging tools.

Most of this RFC was adapted from my Fedora change proposal.

Motivation#

Why perform full system profiling#

Generally, when implementing optimizations after receiving a report on a performance issue, there are two hurdles a developer must overcome:

They have to recompile their program with sufficient debugging information to enable accurate and reliable profiling. Frame pointers are an example of such information. They have to reproduce the scenario under which the software performed poorly. They have to gather the necessary profiling data by running the recompiled program in the reproduced scenario. After gathering the profiling data, the developer can use that data to guide possible optimizations. Usually, this ends being an iterative process, where a possible optimization is implemented, and the scenario is rerun with the recompiled program to measure the effects on performance.

0029 Mirror Definition

Mon, 01 Jan 0001 00:00:00 +0000

Mirror Definition#

Date proposed: 2023-11-20
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29

Summary#

Before this proposal, a large sum of work related to mirrors were manual labor with potential for errors and mistakes. This RFC outlines definitions and guidelines surrounding a new workflow and processes for becoming, maintaining and decommissioning mirrors.

Motivation#

Mirrors are a well known concept on a abstract level as it’s one of the foundations of most Linux distributions. However, the Arch Linux instructions and guidelines surrounding mirrors are manual and prone to errors and delays. Having users report mirror details in a free-text-format, along with manual work to copy and enter this information directly into a database is a tedious process.

0031 Allow all staff to create RFCs

Mon, 01 Jan 0001 00:00:00 +0000

Allow all staff to create RFCs#

Date proposed: 2024-03-05
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/31

Summary#

Grant all Arch Linux staff members, not limited to those in packaging roles, the privilege to initiate RFCs directly, aligning with the broad range of topics these documents encompass.

Motivation#

The RFC process, as outlined in "Using RFCs," aims to enhance transparency and leverage the full spectrum of community expertise, covering a broad range of topics beyond packaging. The current requirement for RFC initiation, namely support from a Developer or Package Maintainer, unintentionally restricts contributions from non-packaging staff.

0032 Arch Linux Ports

Mon, 01 Jan 0001 00:00:00 +0000

Arch Linux Ports#

Date proposed: 2024-03-11
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32

Summary#

Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution.

Motivation#

Arch Linux has historically been ported to different CPU architectures over the years. However, over the past decade we have not done enough to develop and foster expertise when it comes to this topic. Several separate projects exist today for the sole purpose of porting Arch Linux to e.g. ARM, LoongArch and RISC-V¹.

0040 License Package Sources

Mon, 01 Jan 0001 00:00:00 +0000

License Package Sources#

Date proposed: 2024-08-07
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0040

Summary#

Our package sources currently do not have explicit licenses. This RFC proposes to license all Arch Linux package sources under the terms of the Zero-Clause BSD license.

Motivation#

NOTE: This RFC was not written by lawyers so any statements about legal things are merely the result of research.

Arch Linux package sources (PKGBUILD and strictly related files such as e.g. .install, .desktop or systemd files) currently lack a license. This is potentially problematic as it leaves the licensing of package sources open to interpretation. Some users have expressed concerns about this (ML1, Parabola Licensing Issue).

0043 Streamline the RFC writing process

Mon, 01 Jan 0001 00:00:00 +0000

Streamline the RFC writing process#

Date proposed: 2024-08-30
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0043

Summary#

Streamline the writing and publishing of RFCs by relying on markdown and dedicated spellcheckers and linters.

Motivation#

ReStructuredText (RST) is currently used for writing and publishing Arch Linux RFCs. While used in specific ecosystems (e.g. Python) and in publishing, it is considered less widespread and more exotic than markdown.

Markdown is widely adopted across many platforms and tools, including GitLab and Hugo (which is used for generating the static website at https://rfc.archlinux.page/). Additionally, a large set of linters and check tools exist for it and due to its widespread use, many people have a basic understanding of how to use it.

0046 Upstream Package Sources

Mon, 01 Jan 0001 00:00:00 +0000

Upstream package sources#

Date proposed: 2024-11-14
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46

Summary#

Improve the security of Arch Linux distribution packages by relying on transparent and, if possible, cryptographically verifiable upstream sources by default. Provide guidelines and best practices for distribution package maintainers in a document covering various source types and technologies for digital signatures. Communicate the common goal of transparent and secure package delivery for package maintainers as well as upstream project maintainers.

0050 Official WSL image for Arch Linux

Mon, 01 Jan 0001 00:00:00 +0000

Official WSL image for Arch Linux#

Date proposed: 2025-02-11
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/50

Summary#

Provide an official Arch Linux WSL image.

The WSL images are hosted on our geo mirrors.
We plan to include this image in Microsoft’s official distribution manifest to simplify the installation process for users.
We do not intend to distribute this image through the Microsoft Store due to concerns about its terms of service and their implications for our trademarks.

0051 Shorten default TCP keepalive time

Mon, 01 Jan 0001 00:00:00 +0000

Shorten default TCP keepalive time#

Date proposed: 2025-02-21
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/51

Summary#

Set our default net.ipv4.tcp_keepalive_time to override the extremely conservative kernel default.

Motivation#

The Linux kernel supports using “TCP keepalive” in order to signal to the other endpoint as well as anything in-between that a TCP connection which is currently transferring no data is still connected.

The default parameters for this feature make it send a packet every 75 seconds after the connection has been idle for 2 hours.

0052 REUSE for package license linting

Mon, 01 Jan 0001 00:00:00 +0000

REUSE for package license linting#

Date proposed: 2025-03-11
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0052

Summary#

Utilize REUSE for package license linting for all package sources.

Motivation#

While Arch Linux package sources have an explicit license through RFC40, externally fetched sources used for packaging are not explicitly marked with a license.

REUSE is a specification from the Free Software Foundation Europe (FSFE) that allows downstream projects to clearly map copyright and license information to sources in package repositories.

0054 Establish default build flags for Fortran

Mon, 01 Jan 0001 00:00:00 +0000

Establish default build flags for Fortran#

Date proposed: 2025-05-04
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0054

Summary#

This RFC establishes default build flags (FFLAGS, FCFLAGS, DEBUG_FFLAGS) for compiling Fortran code in Arch Linux packages, aligning them with the security hardening standards defined for C.

Motivation#

Arch Linux has been using build flags for security hardening of C and C++ code for a long time. Since RFC0026, Arch Linux also sets RUSTFLAGS. The support for configuring Fortran build flags was recently implemented in pacman. This relies on exporting FFLAGS and FCFLAGS, which are consumed by GNU autotools and passed to the Fortran 77 and Fortran 90 compilers, respectively. Other build systems may also use these variables, e.g. CMake passes FFLAGS to any Fortran compiler.

0059 Automated digital signing of OS artifacts

Mon, 01 Jan 0001 00:00:00 +0000

Automated digital signing of OS artifacts#

Date proposed: 2025-06-17
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/59

Summary#

Introduce a centralized, hardware backed solution for the digital signing of OS artifacts. Gradually replace the need for manual signing of artifacts throughout the distribution.

The stepwise plan in this document will eventually lead to changes for the following existing roles within Arch Linux staff:

Package maintainers will no longer sign packages using their individual OpenPGP private key.
The amount of OpenPGP certificates for main signing key holders to care for will be drastically reduced.
The DevOps team will have to monitor and administrate additional physical machines.

New groups of people within Arch Linux staff will

0063 buildbtw build service

Mon, 01 Jan 0001 00:00:00 +0000

buildbtw build service#

Date proposed: 2025-09-23
Authors: Rafael Epplée (raffomania), Levente Polyak (anthraxx)
RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/63

Summary#

This RFC proposes a first vertical slice of a build service to streamline rebuilding packages with many reverse dependencies. It tackles problems like repetitive manual work, blocking staging repositories, missed reverse dependencies and lack of shared context, like build logs. Goals include automating rebuilds and build ordering, enabling unattended builds, and providing isolated repos for parallel work. Builds run in secure virtual machines via a GitLab executor, organized into namespaces with histories and automatic dependency graphs. Interaction happens through CLI (pkgctl) and a web UI with SSO.

Arch Linux RFCs

0001 Using RFCs

Using RFCs#

Summary#

Motivation#

0002 Provide a x86-64-v3 microarchitecture level port

Provide a x86-64-v3 microarchitecture level port#

Summary#

Motivation#

0003 Updates to build flags

Updates to build flags#

Summary#

Motivation#

Specification#

0004 LTO by Default

LTO by Default#

Summary#

Motivation#

0006 Adoption of a distribution-wide Code of Conduct

Adoption of a distribution-wide Code of Conduct#

Summary#

Motivation#

0007 Rename the Trusted User role

Rename the Trusted User role#

Summary#

0009 Mediation Program

Mediation Program#

Summary#

Motivation#

0010 Adopt PEP 517 tooling for Python packages

Adopt PEP 517 tooling for Python packages#

Summary#

Motivation#

Direct setup.py calls are deprecated#

setup.py install calls install old-style Python metadata#

0011 Store PGP keys for source file signatures alongside the PKGBUILD

Store PGP keys for source file signatures alongside the PKGBUILD#

Summary#

Motivation#

0014 Merge package repositories

Merge package repositories#

Summary#

Motivation#

0016 Use SPDX license identifiers in PKGBUILDs

Use SPDX license identifiers in PKGBUILD#

Summary#

Motivation#

0017 Increase _FORTIFY_SOURCE level to 3

Increase _FORTIFY_SOURCE level to 3#

Summary#

Motivation#

0019 Moderator role for the AUR

Moderator role for the AUR#

Summary#

Motivation#

0020 Sources for Python packaging

Sources for Python packaging#

Summary#

Motivation#

0021 Create a distribution Developer Manual

Create a distribution Developer Manual#

Summary#

0023 Add -Wl,-z,pack-relative-relocs

Add -Wl,-z,pack-relative-relocs#

Summary#

Motivation#

0025 Make dbus-broker our default D-Bus daemon

Make dbus-broker our default D-Bus daemon#

Summary#

Motivation#

0026 Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags

Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to#

Summary#

Motivation#

Why perform full system profiling#

0029 Mirror Definition

Mirror Definition#

Summary#

Motivation#

0031 Allow all staff to create RFCs

Direct `setup.py` calls are deprecated#

`setup.py install` calls install old-style Python metadata#