Wiki - https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-rpm-support-for-…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
RPM supports creating users and groups according to configuration
provided in sysusers.d snippets shipped in package payload.
The goal of the proposal is to fully integrate this RPM functionality in Fedora.
== Owner ==
* Name: Michal Sekletar, Zbigniew Jędrzejewski-Szmek, Panu Matilainen
* Email: msekleta(a)redhat.com, zbyszek(a)in.waw.pl, pmatilai(a)redhat.com
== Detailed Description ==
This proposal consists of two parts. The first is to make sure that
rpm functionality is fully enabled in Fedora. The second is to update
packaging guidelines and raise awareness about the new simpler user
creation method for rpm packages. The goal is a fully declarative
system user and group management in all RPMs. Over time we should be
able to drop all manual `useradd`/`groupadd` invocations or use of
`%sysusers_create_compat` macro in rpm scriptlets.
Support for sysusers was added in rpm 4.19.0. Support for group
membership (`m` lines) was added in rpm 4.20.0. Support for
locked-down users (`u!` lines) was added for rpm 4.21.0. The rpm
package has patches to disable user/group creation
([https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm-4.18.92-disable-s…
rpm-4.18.92-disable-sysusers.patch]) and make user/group dependencies
weak ([https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/rpm-4.19.91-weak-user…
rpm-4.19.91-weak-user-group.patch]).
== Feedback ==
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Discussion] about idea to submit the proposal on fedora-devel list.
== Benefit to Fedora ==
* Declarative system user and group management by packages
* Potential for spec file simplification, concretely, removal of
relevant part of %pre scripts in some packages.
* Ability to query what user and groups are provided by given package
as well as ability to have dependencies on users/groups from different
packages.
* Make use of native rpm functionality in favor of current
%sysusers_compat_create.
== Scope ==
* Proposal owners:
** Change rpm so that it generates hard dependency between packages A
and B in case B depends on user or group provided by package A. Rpm
currently has downstream patch so that only weak dependencies are
generated.
** Make sure that previous change in rpm doesn't cause package
dependency loops during system installation.
** Work on fix for shadow-utils so that useradd and groupadd work
correctly in chroot on SELinux enabled systems (shadow-utils
[https://github.com/shadow-maint/shadow/issues/940| issue].)
* Other developers:
** We would welcome any help with shadow-utils
[https://github.com/shadow-maint/shadow/issues/940| issue].
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
There is no upgrade/compatibility impact.
== How To Test ==
* Select rpm package that creates system user/group account in %pre
* Remove part of %pre scriptlet that handles user/group creation
* Create equivalent
[https://www.freedesktop.org/software/systemd/man/latest/sysusers.d.html|
sysusers.d] configuration file and ship it as part of rpm payload
under /usr/lib/sysusers.d/.
* Rebuild the package
* Verify that package has been built correctly and it has rpm provides
for installed user account and group (e.g. `user(foo) =
ABUNCHOFHEXHERE`, `group(bar) = ADIFFERNTBUNCHOFHEXHERE`). Use `rpm
-qP $package | awk '/(user|group)\(/ {print $3}' | base64 -d` and
check that the output looks reasonable.
* Verify that you can install the package and installed files have
correct ownership.
== User Experience ==
There shouldn't be any user observable change to previous state.
Potential packaging related benefits are mostly of interest to package
maintainers.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: If we are not confident by mass-rebuild that
we can deliver the feature we will postpone its delivery to later
Fedora release. There are no explicit rollback/cleanup actions that
need to taken.
* Contingency deadline: Mass Rebuild of RPMs on Wed 2025-01-15.
* Blocks release? No
== Documentation ==
[https://github.com/rpm-software-management/rpm/blob/master/docs/manual/user…
sysusers.d support in RPM].
== Release Notes ==
N/A
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Protobuf_5.x/6.x
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-protobuf-5-x-6-x…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update Protobuf to the latest version (5.x), and 6.x if it arrives in
time before freeze in Q1 2025. Note that Protobuf's versioning is
complicated, C++ and Python are at version 5, other language bindings
at version 4, and they all embed the version of `protoc`; we are using
the C++ version here so we can reference its
[https://protobuf.dev/support/version-support/#cpp support policy].
A compatibility package, `protobuf3` will be packaged for current
`protobuf` dependencies, but will be marked as deprecated as v3 EOLed
in March 2024.
== Owner ==
* Name: [[User:salimma|Michel Lind]], [[User:jonathanspw|Jonathan
Wright]], [[User:ngompa|Neal Gompa]]
* Email: michel(a)michel-slm.name, jonathan(a)almalinux.org, ngompa13(a)gmail.com
== Detailed Description ==
`protobuf` has historically been a problem to maintain in Fedora
because upstream aggressively releases new versions; we hope to make
it easier to keep up by providing compatibility packages for the older
major version as soon as a new major version of `protobuf` C++ is out.
Specifically, we will start by packaging `protobuf3` for legacy use
cases and updating `protobuf` to version 5, then when version 6 is
out, immediately package `protobuf5` and update `protobuf` to version
6.
Older `protobuf` versions will be marked as `deprecated()` as soon as
upstream considers them out of support, and once this happens we have
the option of retiring them as soon as either there is a major
security issue affecting it or, in Rawhide, as soon as there are no
longer any dependent package.
We will add version suffixes for the binary packages for `protobuf`
5.x/6.x, and if we don't see any issue, for the compat `protobuf3`
subpackages as well.
== Feedback ==
== Benefit to Fedora ==
Other packagers and users benefit from having an up to date version of
Protobuf. This would unblock updating several dependent packages.
== Scope ==
* Proposal owners:
** Package `protobuf3`
** Provide a COPR for testing
** Update `protobuf` in COPR
** Rebuild dependents in a COPR to make sure this work
** Send PRs to packages that need to be adapted to build against `protobuf3`
** (stretch) send PRs to packages to switch them to use `protobuf` 5.x/6.x
* Other developers:
** Help update your own packages to ideally use `protobuf` 5.x/6.x or
at least to switch them to use `protobuf3`
** Report packaging issues
* Release engineering: [https://pagure.io/releng/issue/12506 #12506]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This should have minimal impact for users. The only issue would be if
a package transitively depends on both `protobuf` 3.x and 5.x/6.x at
build time.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
== User Experience ==
Users will benefit from having newer packages available that are
currently blocked on the stale `protobuf` version
== Dependencies ==
70 source RPMs
<nowiki>$ fedrq whatrequires protobuf-devel --src
CuraEngine-1:5.4.0-7.fc42.src
CuraEngine_grpc_definitions-0.1.0-7.fc42.src
HepMC3-3.3.0-2.fc41.src
OliveTin-2022.11.14-8.fc40.src
actor-framework-1.0.1-1.fc42.src
android-tools-1:35.0.1-2.fc41.src
bear-3.1.5-2.fc42.src
bloaty-1.1-38.fc42.src
buildbox-1.2.33-1.fc42.src
caffe-1.0^git20200212.9b89154-14.fc42.src
chatty-0.8.5-1.fc42.src
chromiumos-platform-0~20240902git67bc17e-4.fc42.src
clementine-1.4.0~rc2-10.fc42.src
cockatrice-2.9.0-5.fc41.src
credentials-fetcher-1.3.6-0.fc40.src
criu-4.0-3.fc42.src
dnsdist-1.9.7-1.fc42.src
fcitx5-mozc-2.17.2102.102.1-36.20230508git242b4f7.fc42.src
gazebo-10.2.0-11.fc42.src
grpc-1.48.4-41.fc42.src
hidviz-0.2-6.fc41.src
ignition-msgs-1.0.0-21.fc41.src
ignition-transport-4.0.0-22.fc41.src
kf5-kitinerary-23.08.5-3.fc42.src
kismet-0.0.2023.07.R1-7.fc41.src
kitinerary-24.12.0-1.fc42.src
kosmindoormap-24.12.0-1.fc42.src
libarcus-5.3.0-5.fc41.src
libcompizconfig-1:0.8.18-14.fc41.src
libopenshot-0.3.3-4.fc42.src
liborc-2.0.3-1.fc42.src
libphonenumber-8.13.50-3.fc42.src
libzypp-17.34.1-4.fc42.src
marble-1:24.12.0-1.fc42.src
merkaartor-0.20.0-3.fc42.src
meson-1.5.1-1.fc42.src
mmsd-tng-2.5.0-4.fc41.src
mosh-1.4.0-6.fc41.src
mozc-2.29.5111.102-11.fc42.src
mumble-1.4.287-5.fc41.src
mypaint-2.0.1-11.fc41.src
nanopb-0.4.9-1.fc42.src
ncid-1.17-3.fc42.src
ncnn-20240820-1.fc42.src
netdata-2.0.3-2.fc42.src
onnx-1.15.0-4.fc41.src
onnxruntime-1.17.3-6.fc42.src
opencv-4.10.0-7.fc42.src
opentrep-0.07.16-1.fc42.src
osgearth-3.7-2.fc42.src
osmpbf-1.5.1-4.fc41.src
paraview-5.12.1-8.fc42.src
pdns-4.9.2-2.fc42.src
pdns-recursor-5.1.2-2.fc42.src
perfetto-48.0-1.fc42.src
perl-Alien-ProtoBuf-0.09-24.fc41.src
plasma-dialer-1:6.2.4-1.fc42.src
pokerth-1.1.2-30.fc41.src
protobuf-c-1.5.0-4.fc41.src
protozero-1.7.1-9.fc41.src
python-torch-2.5.0-1.fc42.src
python-torchaudio-2.4.1-2.fc42.src
qt6-qtgrpc-6.8.1-2.fc42.src
raceintospace-2.0.0-12.rc1.fc41.src
ricochet-1.1.4-36.fc41.src
root-6.32.08-2.fc42.src
rust-tonic-types-0.12.3-1.fc42.src
spacebar-1:6.2.4-1.fc42.src
srpc-0.10.3-1.fc42.src
usbguard-1.1.3-2.fc41.src
</nowiki>
== Contingency Plan ==
* Contingency mechanism:
The minimum change we can do is update `protobuf` to the latest 3.x,
but that still requires some compatibility testing and leave us with
an obsolete version
* Contingency deadline:
Beta freeze
* Blocks release?
Yes
== Documentation ==
N/A
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/PackitDistgitCI
Discussion Thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-packit-as-a-dist…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This change aims to change a dist-git CI solution to one based on
Packit and deprecate current solutions (Fedora CI and Zuul).
This change does not affect the tests being run and the test execution
service (=Testing Farm), but the mechanism used to trigger and report
them.
This is strictly not related to the opt-in Packit-provided workflows.
(I.e. this does not require using Packit for release syncing.) A
slightly different branding might be used to avoid confusion.
== Owner ==
* Name: [[User:lachmanfrantisek| František Lachman]]
* Email: flachman(a)redhat.com
* Name: [[User:lbarczio| Laura Barcziova]]
* Email: lbarczio(a)redhat.com
* Name: [[User:mmassari| Maja Massarini]]
* Email: mmassari(a)redhat.com
* Name: [[User:mfocko| Matej Focko]]
* Email: mfocko(a)redhat.com
* Name: [[User:nforro| Nikola Forro]]
* Email: nforro(a)redhat.com
== Detailed Description ==
Since Packit has a long-term and feature-rich integration with Testing
Farm and also automation around dist-git pull requests, the Packit
team is willing to help with a current, non-ideal, situation with
dist-git CI. It looks like there are not enough resources to properly
support and improve the current solutions (Fedora CI and Zuul). This
proposal does not influence Fedora CI Bodhi testing but might be
considered as a next step.
Fedora CI maintenance had been a long-term concern without a clear
owner for the dist-git integration and with plans to move it to the
Testing Farm team. The Testing Farm team would like to avoid
maintenance of these and rather have only a single integrator both
upstream and downstream.
Since Packit Fedora automation heavily relies on working CI on
dist-git pull requests, we need to make sure it works reliably.
Most of the code is already there in
[https://github.com/packit/packit-service/ Packit’s codebase]. The
work is mainly about plumbing everything together and making sure it
works as expected.
We welcome any suggestions but these are the phases we are thinking about:
* '''phase 0: (current state)'''
** opt-in (by Packit service configuration)
** Scratch build being run (example PR)
* '''phase 1:'''
** opt-in (publicly available)
** Scratch build being run
** time: ~ month
* '''phase 2:'''
** opt-in (publicly available)
** scratch build +
[https://github.com/fedora-ci/installability-pipeline installability
check]
** time: ~ month
* '''phase 3:'''
** opt-in (publicly available)
** scratch build +
[https://github.com/fedora-ci/installability-pipeline installability
check] + user-defined TMT tests (as separate results)
** time: ~ month
* '''final phase ~ Fedora CI replacement:'''
** by-default
** Fedora CI is deprecated
** Separate Packit deployment instance for CI; running in the Fedora
Infrastructure.
** opt-out in favour of Zuul
** scratch build +
[https://github.com/fedora-ci/installability-pipeline installability
check] + user-defined TMT tests (as separate results)
** time: ~ enough time for people to try before defaulting
* '''next steps'''
** Everything currently run by Fedora Zuul on dist-git pull requests
is run via Packit (opt-in).
** Deprecate dist-git tenant on Fedora Zuul instance.
=== Risks: ===
* Deployment to Fedora infrastructure
** Despite Packit requiring only OpenShift for its deployment, there
can still be problems found when deploying to another cluster.
** Some work is required to be done by the Fedora Infrastructure team
that we can’t influence.
* Performance
** When going to the final phase when run by default, the load might
significantly increase. Despite the number of packages actively using
dist-git pull requests is not huge, we still need to be prepared.
* dist-git git forge switch
** Despite Packit being written in a git-forge-independent way, there
can still be some issues related to it (be it on Packit's side or
not).
** (Forgejo-support in the underlying forge-unifying library is being
researched and [https://github.com/packit/ogr/issues/866 work] can
start soon.)
=== Support: ===
* For transparency, the Packit team is a Red Hat team under the same
manager as the CPT team (=Copr and Mock) and in the same group as
Testing Farm and other community-related projects.
* The team works and plans in public (see
[https://github.com/orgs/packit/projects/7 the Packit Team Kanban
Board]) and welcomes any external contributor to collaborate.
* To have more Fedora control over the suggested service, the team
wants to deploy it to the Fedora Infrastructure OpenShift cluster and
give the Fedora Infrastructure team access to it so the Packit team
can’t become a bottleneck.
* In case of interest, we welcome anyone to join us in this effort.
* We are active in the #packit(a)fedora.im Matrix channel but a separate
channel can be used to improve the communication.
A couple of links to better understand the current situation:
* https://pagure.io/fedora-ci/general/issue/476
* https://pagure.io/fedora-infrastructure/issue/11920
* https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
* https://github.com/packit/packit-service/issues/2453
== Feedback ==
* Confusion with the current Packit workflows
** Rebranding might be needed.
* There are concerns about fragmentation across Fedora services.
** Packit’s goal is not to implement everything but rather integrate
existing services and provide the best user experience. This can lead
to the reduction of services users need to interact with.
** Packit is already in the ecosystem so it’s about using it for more use cases.
* STI is currently not supported by Packit.
** Technically it can be introduced (because Testing Farm supports
it), but since it has been obsoleted for some time and there is a
[https://fedoraproject.org/wiki/Changes/DeprecateSTI Change Proposal]
to not support it, this might not be needed at all. (We can use this
as an opportunity to move away.)
* What to do about test/pipeline definition repositories? Who should
be responsible for it and how to better collaborate on these?
** As a result of this change, we would like to improve also situation
around the responsibilities of shared plans and clearly state who is
responsible for which part. Packit can but not need to maintain these
repositories.
* Should Packit aim to run Zuul plans for everyone? (The plans that
are not run by Fedora CI.)
** Ideally, the topic of the check choice should not be part of this
change but we can do the installability check by default and let
people opt-in to checks currently run by Zuul. (And make it possible
to run these by default if there is a broader agreement.)
* Should there be an opt-out mechanism for the final solution?
** If needed, we can allow this, but ideally, there should be a
broader discussion and agreement if packages can opt-out from default
jobs.
* Why not pick current solutions?
** Covered more in the Benefits section and motivation, but the main
difference is not so much in technical differences but in a team
dedicated to maintaining and further developing the solution.
* What will be the effect on Koji? Won't it increase the load because
of the duplicate scratch builds?
** At the end, there will be only a single dist-git CI so there won't
be any duplicates.
** For the opt-in phases, the duplicates are possible.
*** We can ask people to opt-out from Zuul if they opt-in to
Packit-based CI. For Fedora CI, we would welcome any suggestion if
there isn't a way to opt-out from it.
*** We can also try to share scratch builds with other solutions but
since it's only for a limited time, this might not be worth the time.
== Benefit to Fedora ==
* Single CI system to run and maintain.
** Both for the user and resource efficiency (e.g. single scratch
build, single service to maintain).
* Reliable and actively maintained+developed CI
** Most importantly, the Packit team offers not only the
implementation but also people to support the service. (We consider
this to be the main issue with the current solutions.)
** We sadly hear regular complaints about the stability of both
existing solutions and issues needing to be fixed for a long time.
(This is mainly related to the previous point that people do not have
enough time for it.)
** Packit has a history of being reliable
([https://packit.dev/docs/service-level-objectives#slo1-changes-to-github-prs…
current set of SLOs], dist-git specific ones might be defined) and has
a dedicated team.
** We also developed multiple mechanisms to make the testing process
more reliable (e.g. auto-retry on infrastructure issues and so-called
babysitting tasks to check for results if the result message got
lost).
* Feature-rich CI experience
** The CI integrations do not need to be only about triggering the
test job and reporting, but also about being able to rerun a
particular part of the test suite or influence the test job workflow
based on some rules (e.g. based on labels). People can decide what to
run and if to run it automatically or manually. This is especially
useful when speaking about user-defined tests.
* Same UX for upstream and downstream
** This would allow people to have the very same test experience and
definitions both upstream and downstream.
** Packit handles not only tests. We want to unify the experience for
the whole pipeline from upstream through dist-git and Koji to Bodhi.
* Implementation of git-forge agnostic thanks to a unified git-forge
API (Pagure and GitLab are available now, Forgejo is being researched
and [https://github.com/packit/ogr/issues/866 work] can start soon).
** This work can be coordinated with the git-forge swap for a smoother
transition and to save time migrating the existing solutions.
* Possible future enhancements when this work is done:
** Copr builds (available in upstream)
** OpenScanHub checks (available in upstream)
** Reverse-dependency builds/tests (via Koschei, research done)
== Scope ==
* Proposal owners:
** Implement the solution following the phases above and communicate
the milestones publically.
** Update Fedora documentation.
** Agree on the ownership of shared test plans.
* Other developers:
No functional change that might affect maintainers. Only UX differences.
* Release engineering: -
** Coordination with release engineering is not required. A mass
rebuild is not necessary for this change.
* Policies and guidelines: documentation needs to be updated
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
This proposal aligns with Fedora’s strategy of improving contributor
experience and easing workflows, supporting a more efficient and
user-friendly ecosystem.
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
During phases 1-3, one can opt-in to this solution and try it for
real. (Most probably via global configuration, similar to the Zuul
approach. Team has a
[https://github.com/packit/packit-service/issues/2628 research task]
in progress on this topic. Suggestions welcome.)
== User Experience ==
* The functionality and workflow will be preserved.
* As a reaction to a dist-git pull request a scratch build and a
follow-up test are being triggered. Users are notified about progress
via statuses that lead to [https://dashboard.packit.dev/ Packit
dashboard] providing more details about builds and tests.
== Dependencies ==
Ending support for STI tests (being submitted as another change) might
ease the implementation.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A
* Contingency deadline: N/A
* Blocks release? No
If the implementation is not ready in time, we can (maybe temporarily)
stay with one of the current solutions.
== Documentation ==
Team research about technical feasibility of this functionality:
https://packit.dev/research/integrations/fedora-ci
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/GnomeShellExtensionDependencyGenerat…
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-gnome-shell-exte…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Implement a dependency generator for GNOME Shell extensions that would
make the binary RPM depend on the correct versions of GNOME Shell
== Owner ==
* Name: [[User:salimma|Michel Lind]], [[User:ngompa|Neal Gompa]]
* Email: michel(a)michel-slm.name, ngompa13(a)gmail.com
== Detailed Description ==
GNOME Shell extensions ship with a `metadata.json` that lists the
supported versions of GNOME Shell. This data is currently unused when
packaging an extension, unless the package maintainer explicitly
transfer this information to the spec -- and then keeps it up to date.
With this Change Proposal implemented, the binary RPM would
automatically declare its dependency on the right versions of GNOME
Shell, ensuring that we will discover after mass rebuild if some
extensions need to be updated because they will FTI.
== Feedback ==
== Benefit to Fedora ==
This will result in an improved user experience for our users, because
extensions that install are now more likely to work.
It will also help extension packagers, as they get early signal that
an extension needs to be updated, by getting a FTI bug not long after
the mass rebuild is complete.
== Scope ==
* Proposal owners:
** Implement a dependency generator and package it as
`gnome-shell-extension-rpm-macros`
** make `gnome-shell` `Provides: gnome-shell(api) == MAJOR_VER` to
make the implementation of the generator easier
** Get this package pulled in by `redhat-rpm-config`
** Optionally get this into `epel-rpm-macros` for EPEL 10
** Provide a COPR for other developers to test
* Other developers:
** Test your package by explicitly adding the new dependency generator
package as a `BuildRequires` and dropping the `Requires` on
`gnome-shell`
** If that works, once the new package is in Fedora and pulled in by
`redhat-rpm-config`, you may (but do not have to) drop the `Requires`
on `gnome-shell` as it will be redundant
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines:
[https://pagure.io/packaging-committee/pull-request/1425 FPC #1425]
This should only land after implementation is done
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
N/A. This change would be transparent to packagers and end-users - it
will allow packagers to clean up their spec by removing the explicit
`Requires` on `gnome-shell` but that is optional
== Early Testing (Optional) ==
== How To Test ==
== User Experience ==
== Dependencies ==
This requires changes to `gnome-shell` and optionally
`redhat-rpm-config`. The former significantly eases implementation, as
it allows a 1:1 mapping between the version listed in `metadata.json`
and what we express in the binary RPM. The latter is required to make
this transparent to other packagers; if that change does not go
through this becomes a self-contained change and extension maintainers
can opt in by BR-ing the package
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
If the dependency generator turns out to be very buggy, we can stop
pulling it in `redhat-rpm-config`
* Contingency deadline:
Beta freeze
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Django_5x
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-django-5-x-self-…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update the default Django stack in Fedora from 4.2 to 5.x
(Note: 5.2 is scheduled to be released in April so F42 might initially
ship with 5.1)
== Owner ==
* Name: [[User:Salimma|Michel Lind]], [[User:Ngompa|Neal Gompa]],
[[User:Carlwgeorge|Carl George]]
* Email: michel(a)michel-slm.name, ngompa13(a)gmail.com, carl(a)redhat.com
== Detailed Description ==
This change will update Django in Fedora to the latest upstream
release, clean up some packaging tech debt, and avoid confusion where
in the past, `python-django4.2` was newer than `python-django` for a
period.
Similar to the packaging approach for the Python interpreter itself,
we're moving to a single source RPM for each Django major version. The
major version initially shipped with a given Fedora release will have
unsuffixed binary packages (e.g. `python3-django`) while any newer or
older versions will have suffixed binary packages (e.g.
`python3-django5`). Suffixed packages (source and binary) will only
list the major version (so `python-django5` instead of
`python-django5.1`).
== Feedback ==
== Benefit to Fedora ==
This change makes the Django packaging in Fedora consistent with that
in EPEL, where due to lifecycle considerations, for EPEL 8 and above
we only package `python-django3` and `python-django4.2` instead of
python-django, allowing them to be retired if they are EOL upstream
and there are serious security issues.
Django itself takes backward compatibility seriously, and within a
given major version, minor versions only drop features that are
already deprecated in the previous major version. That being said,
because only X.2 releases are LTS releases, this approach let us move
fast and introduce the latest Django major version without affecting
those on the 'default' version that ships at the time of release.
Users can swap out Django versions as they please among the different
supported versions, as the packages are designed to be swappable.
Lastly, some packaging remnant from the time where Django provides
both Python 2 and Python 3 packages will be dropped - e.g. the aliases
for `django-admin` will be removed.
== Scope ==
* Proposal owners:
** introduce python-django5 for all Fedora releases (default for F42+,
versioned for older releases)
** retire python-django from Fedora
** audit packages that explicitly depend on `python3-django` and file
bugs requesting they change to use the automatic Python dependency
generators or explicitly depend on `python3dist(django)`
* Other developers:
** if your package explicitly depends on `python3-django`, change to
use the automatic Python dependency generators or explicitly depend on
`python3dist(django)`. This is optional but will let your package runs
against alternate Django versions and rebuildable in EPEL
** help test switching between Django stacks
* Release engineering: [https://pagure.io/releng/issue/12507 #12507]
<!-- 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 -->
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
== How To Test ==
== User Experience ==
End users will mostly not be affected - installing `python3-django` as
before will just work. The suffixed django-admin launcher scripts are
going away, but the change owners believe the usage of these is
minimal to non-existent - they just denote the version of the Python
runtime, and we have not released Django for anything but the base
runtime ever since we stopped building for Python 2.7.
== Dependencies ==
None that would be affected; a dependency check with `fedrq` indicates
that some packages are hardcoding dependencies on python3-django,
which should be fixed for EPEL, but because in Fedora we will keep
shipping unversioned binary packages they won't be affected
<nowiki>$ fedrq whatrequires python3-django -F
"multiline:source,requires" --notsrc | grep django | grep -v
'python3.13dist(django)' | grep python3-django
osh : python3-django >= 3.2
python-django-ajax-selects : python3-django
python-django-angular : python3-django
python-django-annoying : python3-django
python-django-authority : python3-django
python-django-database-url : python3-django
python-django-filter : python3-django-rest-framework
python-django-formtools : python3-django >= 1.7
python-django-health-check : python3-django
python-django-ipware : python3-django
python-django-pipeline : python3-django
python-django-pytest : python3-django
python-django-redis : python3-django
python-django-reversion : python3-django
python-django-rules : python3-django
python-django-tagging : python3-django
python-django-tastypie : python3-django
python-django-threadedcomments : python3-django
python-mozilla-django-oidc : python3-django</nowiki>
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
Change owners will update the existing python-django package to 5.x
* Contingency deadline:
Beta freeze - whenever the deadline is for retiring the old
python-django package
* Blocks release?
No
== Documentation ==
N/A (not a System Wide Change)
A README.Fedora describing the maintenance process will be included in
the new python-django5 package and copied into other versioned
packages (right now python-django4.2) when they are updated or created
== Release Notes ==
N/A
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/dropingOfCertPemFile
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-dropping-of-cert…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
In order to increase the performance of OpenSSL by default using
directory-hash format we need to drop the /etc/pki/tls/cert.pem file
to prevent it from being loaded by default. This also includes the
certificate bundles in /etc/pki/tls/certs/ folder(ca-certificates.crt,
ca-bundle.crt).
== Owner ==
* Name: [[User:Fkrenzel| František Krenželok]]
* Email: fkrenzel(a)redhat.com
== Detailed Description ==
In order to improve the loading time of OpenSSL, a directory-hash
support was added to ca-certificates. In order for OpenSSL to use the
directory-hash format by default we need to stop it from trying to
load /etc/pki/tls/cert.pem by deleting it. This also applies to the
certificate bundles in /etc/pki/tls/certs/ folder(ca-certificates.crt,
ca-bundle.crt).
== Feedback ==
=== (a) Changing the OpenSSL configuration directory (OPENSSLDIR) ===
Automated tools often rely on the output of openssl version -d to
infer locations such as <OPENSSLDIR>/'''openssl.cnf''' as the
configuration file.
Changing OPENSSLDIR risks breaking these assumptions and complicating
integrations.
A possible solution could be changing the directory to something like
/usr/lib/openssl/ and shipping a symlink, e.g.,
`/usr/lib/openssl/openssl.cnf -> /etc/pki/tls/openssl.cnf.` However,
this is less than ideal.
=== (b) Patching the OpenSSL source code ===
This approach involves patching OpenSSL to use directories outside of
the OPENSSLDIR/certs default for the root certificates.
Although it avoids relocating the configuration file.
It introduces a downstream patch that would need to be maintained
indefinitely(There are already loads of patches and the maintainers
really dislike this idea).
Such a patch would also be unexpected behavior for users accustomed to
upstream defaults.
This was partly discussed here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Note: Option (a) is gravely discouraged. Option (b) could be
implemented instead, but it still has drawbacks, including potentially
unforeseen ones.
== Benefit to Fedora ==
Applications using OpenSSL(possibly other libraries as well) will
benefit from much faster initialization of OpenSSL.
== Scope ==
* Other developers:
Any package loading the root certificates from any of the following bundles:
`/etc/pki/tls/cert.pem`
`/etc/pki/tls/certs/ca-certificates.crt`
`/etc/pki/tls/ca-bundle.crt`
needs to preferably use the defaults of the library or if they must,
use the `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem` file
instead.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: neither does nor doesn't
== Upgrade/compatibility impact ==
Once this change is integrated, the packages/software using any of the
following files `/etc/pki/tls/cert.pem`
`/etc/pki/tls/certs/ca-certificates.crt` `/etc/pki/tls/ca-bundle.crt`
as a root certificate bundle file might encounter connectivity issues.
== How To Test ==
Target behavior: OpenSSL initialization takes less time when the file
isn't present compared to it being there.
1. The following will create a symlink for testing after the change
has been integrated(i.e. the `.../tls/cert.pem` file is missing)
`ln -s /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/pki/tls/cert.pem`
2. Test the time of OpenSSL initialization or a package using it with
and without the aforementioned symlink.
(If there is no difference for package then it is most likely due to
OpenSSL not being configured to search for certs in default location)
== User Experience ==
Packages using a OpenSSL will have faster initialization time.
== Dependencies ==
Any package using
`/etc/pki/tls/cert.pem`,`/etc/pki/tls/certs/ca-certificates.crt` or
`/etc/pki/tls/ca-bundle.crt` file are affected. It is required that
the maintainers change this so that user experience is not
compromised.
== Contingency Plan ==
* Contingency mechanism: We will postpone the change if majority or
critical package owners will be unable to make appropriate changes.
* Contingency deadline: before end of beta freeze(2025-02-18).
* Blocks release? The feature doesn't block release.
== Documentation ==
The change is documented as a part of ca-certificates package changelog.
== Release Notes ==
The /etc/pki/tls/cert.pem certificate file has been Removed.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hi folks,
The elections for the Fedora Linux 41 cycle have completed and the results
are as follows:
## Fedora Engineering Steering Committee (FESCo)
The following candidates are elected to FESCo:
* Kevin Fenzi
* Zbigniew Jędrzejewski-Szmek
* David Cantrell
* Tomáš Hrčka
* Fabio Alessandro Locati
## Fedora Mindshare Committee
Luis Bazan is elected to the Fedora Mindshare Committee.
Congratulations to all those elected and thank you to the candidates and
voters.
For more details, see the Community Blog post:
https://communityblog.fedoraproject.org/f41-election-results/
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney