Stepping down as Fedora Jam maintainer
by Erich Eickmeyer
Hello all,
A little over a year ago, I came to the Fedora project to revive and
modernize the Fedora Jam project. I have successfully done that. My
vision was that it would be a great way to help develop and test the
most recent advancements in Linux audio.
Unfortunately, or fortunately, life has a way of changing for the good
or the bad. Back in November, I was offered an opportunity that I could
not pass-up: becoming the User Experience Director for the Kubuntu
Focus brand of laptops made by MindShareManagement. Since then, I have
become an integral member of that team, directly reporting to the CTO,
CEO, and President, working directly with the PR and Sales and
Marketing directors. It has been a blast, and is a project that works
directly with Ubuntu and Debian to create, as we put it, the "Ultimate
Linux Laptop". As a MOTU for Ubuntu, this was a perfect fit.
I didn't come here to be a shill for Ubuntu or to advertise my work,
but rather, to illustrate the level of involvement. It has taken up a
majority of my time, and my work with Ubuntu Studio is directly
involved with the project as well as both Ubuntu Studio and the Kubuntu
Focus laptop have similar synergies.
Because of the amount of time involved in these projects, something has
to give. For that reason, I must step-down as Fedora Jam maintainer. My
plan is to continue to maintain certain packages within Fedora (which,
admittedly, I've been slacking on), but I am orphaning the vast
majority of my packages. Here's the list:
Add64
dssi
dssi-vst
fedora-jam-backgrounds*
fedora-jam-kde-theme*
fluidsynth
fluidsynth-dssi
freqtweak
gnome-guitar
harmony-seq
hexter-dssi
jackctlmmc
jmeters
libinstpatch
lv2-c++-tools
lv2-fabla
lv2-ll-plugins
lv2-mdaEPiano
lv2-newtonator
lv2-sorcer
lv2-swh-plugins
lv2-vocoder-plugins
meterbridge
non-daw
portmidi
radium-compressor
realTimeConfigQuickScan
whysynth-dssi
xsynth-dssi
*These packages have pagure repos which I'd be happy to hand over to
whoever takes these.
I do want to thank everyone for the opportunity, including Matthew
Miller, Ben Cotton, Neal Gompa, and many others that helped me revive
this project. I'm sad to let it go, and I'm not sure what's going to
happen to it, but I hope someone who has a passion for the latest
technologies in Linux Audio and music production can take it over.
Thanks,
Erich Eickmeyer
2 years, 8 months
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags. This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.
== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: law(a)redhat.com
== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.
This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file. This should significantly
improve build times for most packages in Fedora.
To ensure that we can identify packages that need the opt-in now and
in the future, the plan is to pass to brp-strip-lto a flag indicating
whether or not the package has opted into -ffat-lto-objects. If
brp-strip-lto finds .o/.a files, but the package has not opted into
-ffat-lto-objects, then brp-strip-lto would signal an error.
== Benefit to Fedora ==
The key benefit to Fedora is improved package build times and lower
load on the builders.
== Scope ==
* Proposal owners: The feature owner (Jeff Law) will need to settle on
a suitable RPM macro to indicate an opt-in to -ffat-lto-objects,
implement the necessary tests in brp-strip-lto and opt-in the initial
set of packages. This will be accomplished by doing the prototype
implementation locally, building all the Fedora packages to generate
the opt-in set. Committing the necessary opt-ins, then committing the
necessary changes to the RPM macros.
* Other developers: There should be minimal work for other
developers. The most likely scenarios where other developers will
need to get involved would include:
# Packages which are excluded from x86_64 builds and which need the
opt-in will need the appropriate package owners to add the opt-in.
# Packages which are FTBFS when the builds are run to find the set of
packages that need to opt-in and which need to opt-in will need
packager attention.
# It is possible that the faster builds may trigger build failures in
packages that have missing dependencies in their Makefiles. We saw a
few of these during the initial LTO work and those packages were
either fixed or -j parallelism removed. This work may expose more of
these problems.
I expect these all to be relatively rare occurences, but with 9000+
packages in Fedora I wouldn't be surprised if we see a few of each of
these issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed) This
should have no release engineering impacts.
* Policies and guidelines: The packaging guidelines will need to be
updated to document the new macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This proposal does not align with any
current Fedora Objectives.
== Upgrade/compatibility impact ==
This change should have zero impact on upgrade/compatibility. In
fact, the change should have no user visible impacts.
== How To Test ==
No special testing is needed. Any issues with this proposal will show
up as FTBFS issues.
== User Experience ==
Users should see no changes to the user experience.
== Dependencies ==
Packages which need to opt-in to -ffat-lto-objects will need their
.spec files updated to include the
new macro.
== Contingency Plan ==
If this can not be completed by final development freeze, then the RPM
macro changes would not be installed and the change could defer to
Fedora 35.
* Contingency mechanism: Proposal owner will only commit the RPM macro
changes once the opt-in package set has been identified and opt-ins
added to those package's spec files. So no special contingency
mechanism should be needed
* Contingency deadline: It is most beneficial to have this completed
before the mass rebuild; however, the drop dead date should be beta
freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
No upstream documentation. Packaging guidelines will need a minor update.
== Release Notes ==
I do not expect this change to require any release notes.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 8 months
Assimp soname bump
by Rich Mattes
Hi,
I plan to update assimp from 3.3.1 to the latest release (5.0.1) in
rawhide this week. The following packages will be affected:
fawkes-0:1.3.0-11.fc33.src
mrpt-0:1.4.0-17.fc33.src
pioneer-0:20200203-1.fc33.src
vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src
I will take care of the rebuilds and any fallout/updates that need to
happen.
Rich
2 years, 8 months
How to easily automate test builds in a COPR project
by Richard Shaw
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
was hoping for something that took less time as I don't have a lot of that
:)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or
something like that. And then use a script to substitute into "%global
tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
2 years, 9 months
The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
2 years, 9 months
F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Nodejs16
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
will carry 16.x as the default Node.js interpreter for the system. The
14.x and 12.x interpreters will remain available as non-default module
streams.
== Owner ==
* Name: [[User:zvetlik| Zuzana Svetlikova]]
* Email: zsvetlik(a)redhat.com
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 35 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users nodejs-16.x and the matching npm
package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
16.x release, Fedora 35 will also have the 14.x and 12.x releases
available as selectable module streams.
== Scope ==
* Proposal owners: The packages are already built for Fedora 33, 34
and 35 in a non-default module stream. On June 14th, 2021, the
nodejs-16.x packages will be built in the non-modular repository and
thus become the default in Fedora 35.
* Other developers: Any developer with a package that depends on
Node.js at run-time or build-time should test with the 16.x module
stream enabled as soon as possible. Issues should be reported to
nodejs(a)lists.fedoraproject.org
* Release engineering: We will coordinate with the Node.js SIG to
create a side-tag to perform the rebuilds before making 16.x the
default.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 33 or Fedora 34 with
the non-modular nodejs-14.x packages will be automatically upgraded to
the 16.x packages when they upgrade to Fedora 35, which may cause
issues. If users are running software known not to support Node.js
16.x yet, they can switch the system to use 14.x with '''dnf module'''
commands.
== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 16.x being installed.
* Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x
installed (non-modular) results in an upgrade to nodejs-16.x
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:14` module enabled does *not* result in an upgrade to 16.x and
still has `nodejs:14` enabled on Fedora 35.
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:16` module enabled upgrades successfully and still has
`nodejs:16` enabled on Fedora 33.
== User Experience ==
Users will have the 16.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 16.x, they will need to be updated, made
modular and dependent upon the `nodejs:14` stream or else removed from
Fedora 35.
Prior to the switchover date to Node.js 16.x as the default, packagers
are strongly encouraged to test their existing Node modules with 16.x
via the Modular version by running:
<pre>
dnf module reset nodejs
dnf module install nodejs:16/development
</pre>
Packagers can also test their builds using `mock` by creating the file
`/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following
contents:
<pre>
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
config_opts['module_install'] = ['nodejs:16/development']
include('templates/fedora-rawhide.tpl')
</pre>
Then call
<pre>
mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo
</pre>
(Note that the `--enablerepo=rawhide-modular` portion looks redundant,
but this is because of
[https://github.com/rpm-software-management/mock/issues/591 a mock
bug])
== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 14.x as the default Node.js interpreter. This will
require bumping epoch.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* https://nodejs.org/dist/latest-v16.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md
== Release Notes ==
Fedora 35 now ships with Node.js 16.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 14.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:14
</pre>
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9
by Florian Weimer
TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library
creates problems, so we are removing it. There may be some
hickups. Full updates with “dnf update” are recommended.
We expect that we will soon be able to import glibc upstream snapshots
regularly into Fedora 35 and CentOS Stream 9. We did such regular
imports for the past couple of Fedora rawhide releases, but the
situation will be slightly different, as explained below. The snapshots
will also land in CentOS Stream 9, after a delay as the result of a
different testing pipeline.
glibc 2.33 and earlier accidentally provided an very generic ROP gadget
in the statically linked startup code that is present in every program
(even dynamically linked ones). We have removed the ROP gadget and
moved that particular initialization code into the dynamically linked
part, but that means that the interface between the startup code and the
dynamically loaded glibc parts had to change. As a result, any program
linked against glibc 2.34 will not run with glibc 2.33 or any earlier
version. (Some of you may remember the memcpy(a)GLIBC_2.14 issue, it was
similar.) This version requirement will be properly reflected in RPM
dependencies.
glibc 2.34 removes libpthread as a separate library. This is based on
the observation that most processes load libpthread anyway. (On this
system, I count 141 out of 159 processes that load libpthread.) One
particularly thorny issue is that certain NSS modules depend on
libpthread, and if the main program is not linked (indirectly) against
libpthread, loading such NSS modules effectively loads libpthread via
dlopen, which is something that glibc has never supported well.
Furthermore, the availability of some pthread_* functions without
-lpthread has been a source of confusion to developers, resulting in
both overlinking and underlinking.
We started the libpthread transition in glibc 2.33 when we added the
__libc_single_threaded variable as a replacement for the weak symbol
hacks that some libraries use to detect single-threaded processes. (For
example, libstdc++ used to do this to avoid using atomic instructions in
std::shared_ptr.) Backwards compatibility for dynamically linked
binaries should be preserved (as usual), but we know of one issue on
ppc64le, where the weak symbol hacks resulted in slightly corrupt
binaries. Upstream glibc did not accept the proposed backwards
compatibility enhancement so far. Instead, we will rebuild affected
distribution binaries with a binutils version which handles weak symbols
slightly differently, avoiding the corruption. As we plan to perform
these rebuilds before the new glibc lands in the buildroot, the
requirement to upgrade to the new binaries before or at the same time of
the upgrade to the glibc upstream snapshot will NOT be reflected in RPM
dependencies. A full upgrade using “dnf update” will work, however.
In addition to the removal of libpthread, I also hope to remove libdl
and librt. This means that new GLIBC_2.34 symbols will be added to
libc.so.6 (e.g., timer_create(a)GLIBC_2.34). The librt removal in
particular will probably not land with the first imported snapshot.
This is unfortunate because RPM does not have a way to express this:
there's just a blanket Provides: libc.so.6(GLIBC_2.34), which will
already be included in the first snapshot that adds the symbol
__lib_start_main@(a)GLIBC_2.34 (whether or not the RPM package includes
timer_create(a)GLIBC_2.34 as well). Some tools in the fedpkg/centpkg/mock
sphere try to install builds from the Koji buildroot into installations
from composes, without upgrading everything to the current buildroot, so
it's possible that glibc won't be upgraded to match the requirements of
RPMs directly imported from the buildroot. Developers encountered
similar issues with glibc snapshot imports (e.g., around the symbol
pthread_getattr_np). Our RPM infrastructure does not have per-symbol
dependencies, so there isn't much we can do about it at the packaging
level. It's a transitory issue during rawhide/CentOS Stream 9
development; the finished release will add all GLIBC_2.34 symbols in one
upgrade, so end users won't see it in a Fedora 34 to Fedora 35 upgrade
or a CentOS Stream 8 to CentOS Stream 9 upgrade.
We think there is value in providing access to these snapshots early,
and will try to make the transitions as smooth as possible, within the
constraints outlined above.
Thanks,
Florian
2 years, 10 months
Let's retire original glib and gtk+
by Michael Catanzaro
Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era.
This is would take out the gtk+ package (GTK 1) along with it. (I'm not
proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now,
since GLib 2 was released in March 2002. That's a real long time to
maintain a compatibility package, so I'm not sympathetic to anything
that still requires it.
GLib 2 has been API and ABI stable for 19 years now, so it's not moving
too fast for your package to depend on. :) The full list of packages
still depending on GLib 1 is below. If you own one of the below
packages, please consider upgrading to GLib 2. The only one that I
recognize is Sagemath.
$ sudo dnf repoquery --recursive --whatrequires glib
Last metadata expiration check: 0:28:04 ago on Fri 07 May 2021 09:06:03
AM CDT.
Singular-0:4.1.1p3-24.fc34.x86_64
Singular-doc-0:4.1.1p3-24.fc34.x86_64
Singular-emacs-0:4.1.1p3-24.fc34.x86_64
Singular-surfex-0:4.1.1p3-24.fc34.x86_64
bubblemon-0:1.46-29.fc34.x86_64
collectd-xmms-0:5.12.0-2.fc34.x86_64
gap-pkg-happrime-0:0.6-5.20190208.edfbd41.fc34.noarch
gap-pkg-happrime-doc-0:0.6-5.20190208.edfbd41.fc34.noarch
gap-pkg-singular-0:2020.12.18-2.fc34.noarch
gap-pkg-singular-doc-0:2020.12.18-2.fc34.noarch
glib-devel-1:1.2.10-62.fc34.i686
glib-devel-1:1.2.10-62.fc34.x86_64
golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch
gtk+-1:1.2.10-96.fc34.i686
gtk+-1:1.2.10-96.fc34.x86_64
gtk+-devel-1:1.2.10-96.fc34.i686
gtk+-devel-1:1.2.10-96.fc34.x86_64
gxvattr-0:1.3-42.fc34.x86_64
librcc-devel-0:0.2.12-18.fc34.i686
librcc-devel-0:0.2.12-18.fc34.x86_64
librcc-gtk+-0:0.2.12-18.fc34.i686
librcc-gtk+-0:0.2.12-18.fc34.x86_64
logjam-xmms-1:4.6.2-25.fc34.x86_64
manedit-0:1.2.1-25.fc34.x86_64
qepcad-B-0:1.74-1.fc34.x86_64
sagemath-0:9.2-4.fc34.x86_64
sagemath-core-0:9.2-4.fc34.x86_64
sagemath-data-0:9.2-4.fc34.noarch
sagemath-data-combinatorial_designs-0:9.2-4.fc34.noarch
sagemath-data-conway_polynomials-0:9.2-4.fc34.noarch
sagemath-data-elliptic_curves-0:9.2-4.fc34.noarch
sagemath-data-elliptic_curves_large-0:9.2-4.fc34.noarch
sagemath-data-etc-0:9.2-4.fc34.noarch
sagemath-data-graphs-0:9.2-4.fc34.noarch
sagemath-data-polytopes_db-0:9.2-4.fc34.noarch
sagemath-jupyter-0:9.2-4.fc34.x86_64
sagemath-sagetex-0:9.2-4.fc34.x86_64
surf-geometry-0:1.0.6-29.fc34.x86_64
xarchon-0:0.50-35.fc34.x86_64
xconvers-0:0.8.3-27.fc34.x86_64
xdialog-0:2.3.1-28.fc34.x86_64
xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-devel-1:1.2.11-41.20071117cvs.fc34.i686
xmms-devel-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-flac-0:1.3.3-7.fc34.x86_64
xmms-libs-1:1.2.11-41.20071117cvs.fc34.i686
xmms-libs-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-pulse-0:0.9.4-27.fc34.x86_64
Michael
2 years, 10 months
F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild
== Summary ==
Enable broken RPATH detection
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot...
buildroot policy] script by default. This will make the RPM build fail
once a broken RPATH was detected within a binary or a shared library
file. An opt-out mechanism will be provided as well.
== Owner ==
* Name: [[User:cstratak| Charalampos Stratakis]]
* Email: cstratak AT redhat.com
== Detailed Description ==
The dynamic linker and loader (ld.so) is responsible for resolving
runtime dependencies of executables and shared library files through a
search hierarchy. However some packages (usually through their
upstream buildsystems) contain a hard-coded path within their binaries
or .so files, by using the -R or -rpath flag during compilation, which
is called an RPATH. By utilizing RPATH, ELF files can point to
directories to be included in the search path, on runtime, to resolve
their dependencies.
While RPATH can be used for non-standard directories, such as a place
containing private libraries of the project, when it points to a value
already provided by the search path of ld.so, it changes the hierarchy
of the search by placing the system defaults first.
(a) DT_RPATH -> (b) LD_LIBRARY_PATH -> (c) DT_RUNPATH -> (d) cache
(/etc/ld.so.cache) -> (e) system defaults
This could present a variety of issues, such as LD_LIBRARY_PATH
overrides not working, incomplete dependency resolution, loading of
wrong libraries etc. In general, changing the default search hierarchy
could lead to unforeseen bugs and issues - in a similar manner as
adding /usr/lib64 to LD_LIBRARY_PATH.
Another problem of a hardcoded RPATH is security. When an ELF object
contains an RPATH pointed to a directory not managed by the system,
where some malicious actor has write permissions to, it's relatively
easy to execute arbitrary code.
Performance can be also affected, since probing explicitly e.g.
/usr/lib64 through RPATH adds extra open/openat system calls to the
process startup.
In Fedora the use of such RPATH is
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
forbidden], but it was never enforced. This change intends to ratify
that by executing `/usr/lib/rpm/check-rpaths` during rpmbuild, after
%install, and fail the build if an RPATH entry was detected. This
change will not affect RPATH's pointing to private libraries.
=== Definition of a broken RPATH ===
This change will use the
[https://github.com/rpm-software-management/rpm/blob/master/scripts/check-...
rpm script] for checking the broken RPATH's.
The categories are:
* standard RPATHs (e.g. `/usr/lib` or `/usr/lib64`); such RPATHs are a
minor issue but are introducing redundant searchpaths without
providing a benefit. They can also cause errors in multilib
environments.
* invalid RPATHs; these are RPATHs which are neither absolute nor
relative filenames and can therefore be a SECURITY risk
* insecure RPATHs; these are relative RPATHs which are a SECURITY risk
* the special `$ORIGIN` RPATHs are appearing after other RPATHs; this
is just a minor issue but usually unwanted
* the RPATH is empty; there is no reason for such RPATHs and they
cause unneeded work while loading libraries
* an RPATH references `..` of an absolute path; this will break the
functionality when the path before `..` is a symlink
=== Opting out ===
A standard opt-out mechanism is provided, same as the other
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot...
buildroot policy scripts], if the script provides incorrect results
for your package. Simply add `%define __brp_check_rpaths %{nil}` on
top of your SPEC. According to the guidelines, any package that
disables a BRP script this way, MUST also note the reason in an
accompanying comment.
== Feedback ==
The change [https://pagure.io/packaging-committee/issue/886 has been
proposed] a long time ago through FPC and the general consensus is
that it needs to be done along with an overhaul of the Fedora
documentation in regards to RPATH.
An [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
email thread] was also started on Fedora devel regarding this change.
There have been multiple requests in the past to enable that check, as
well as various attempts to remove RPATH's from packages in the
distro. [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
0] [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
1][https://lists.fedoraproject.org/archives/list/devel@lists.fedoraprojec...
2][https://lists.fedoraproject.org/archives/list/devel@lists.fedoraprojec...
3]
As for other distributions, Debian [https://wiki.debian.org/RpathIssue
discourages] the use of RPATH, openSUSE
[https://en.opensuse.org/openSUSE:Packaging_checks#Beware_of_Rpath
forbids it] by running the check from rpmlint after every package
build and Arch and Gentoo point out to possible insecure usage at
their respective documentation pages.
Also there has been a relevant [https://bugs.python.org/issue36659
discussion] in the upstream python community.
== Benefit to Fedora ==
The main benefit of this change is avoiding bugs that might stem from
hardcoded RPATH values which include but not limited to: loading of
wrong or malicious code, wrong dependency resolution of object files
etc. There will also be a performance increase by derived from
avoiding unnecessary system calls required for handling RPATH's.
In addition the RPATH related packaging guidelines will be enforced by
the build system.
== Scope ==
* Proposal owners: Merge the
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/132
pull request] to redhat-rpm-config to enable running the check-rpaths
script after %install.
* Other developers: After merging the changes to redhat-rpm-config the
affected package maintainers that will see their packages' builds
fail, will need to review their usage of RPATH and either remove it or
workaround the issue. The packages currently failing to build due to
RPATH issues, so far, are listed in the wiki page
* Release engineering: This change doesn't require coordination with
rel-eng, as any issues will be caught during the regular mass rebuild
of packages.
* Policies and guidelines: TODO: The guidelines will be overhauled to
take into account accepted usage or RPATH, clarification of the policy
and ways to opt-out.
FPC ticket: https://pagure.io/packaging-committee/issue/886
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There will be no visible impact to non-packagers. Packagers will need
to fix their packages if an broken RPATH entry was detected, as a
broken RPATH will make the rpmbuild fail either in koji or locally.
== How To Test ==
* Mock build testing:
Initiate a Fedora rawhide mock chroot and install the modified
redhat-rpm-config:
mock -r fedora-rawhide-x86_64 --install
https://download.copr.fedorainfracloud.org/results/cstratak/rpath/fedora-...
Build your package with the --no-clean option:
mock -r fedora-rawhide-x86_64 --no-clean <srpm>
* Local testing: Building rpm's locally should already reveal the
issue as the .rpmmacros file defines the RPATH check. Sample of a
vanilla .rpmmacros file:
%_topdir %(echo $HOME)/rpmbuild
%__arch_install_post \
[ "%{buildarch}" = "noarch" ] || QA_CHECK_RPATHS=1 ; \
case "${QA_CHECK_RPATHS:-}" in [1yY]*) /usr/lib/rpm/check-rpaths ;; esac \
/usr/lib/rpm/check-buildroot
* rpmlint test: The binary-or-shlib-defines-rpath test from the
BinariesCheck module will reveal RPATH usage.
rpmlint -c BinariesCheck <binary rpm>
e.g.: rpmlint -c BinariesCheck -v audiofile-0.3.6-27.fc34.x86_64.rpm
audiofile.x86_64: I: checking
audiofile.x86_64: E: binary-or-shlib-defines-rpath
/usr/bin/sfconvert ['/usr/lib64']
audiofile.x86_64: E: binary-or-shlib-defines-rpath
/usr/bin/sfinfo ['/usr/lib64']
1 packages and 0 specfiles checked; 2 errors, 0 warnings.
== User Experience ==
N/A (While this is a system wide change the impact is not visible to
regular users, only to packagers as described above).
== Dependencies ==
The change depends on modifying redhat-rpm-config.
== Contingency Plan ==
* Contingency mechanism: The change to redhat-rpm-config will be reverted
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
TODO:
The documentation of the packaging guidelines will be updated to
reflect the changes that this change brings. Updated guidelines will
be https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months