Hi folks,
I wanted to share with you that the CFP deadline for Flock to Fedora has
been extended to close at 23:59 UTC on March 3rd 2025, so there is still
time to submit your proposal for a talk, workshop or BoFs if you would like
to present/host at Flock this year! We will be in Prague, Czechia from June
5 - 8, with June 8 being an optional social day based on the great feedback
we got from hosting a self-funded and optional trip to Niagara Falls last
year in Rochester. More details to come about that day, but the
important part is the CFP is *still_open*!
Please take a read of the community blog post
<https://communityblog.fedoraproject.org/flock-to-fedora-cfp-extension-tada-…>
for much more details about the event and themes, and dont hesitate to
reach out if you have any questions.
Best of luck and hope to see many of you at Flock!
Aoife
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/SwitchToJXLforDefaultWallpaper
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-disabling-suppor…
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 ==
The default Fedora wallpaper will switch from PNG to JXL format.
== Owner ==
* Name: [[User:luya| Luya Tshimbalanga]]
* Email: luya(a)fedoraproject.org
== Detailed Description ==
For a long time, the default Fedora wallpaper used PNG format to
preserve the integrity of the design. The drawback is the large file
size for packaging and for the time of day animation. The Design team
switched to JXL to address the issue drastically saving the size of
the media while maintaining the quality of the wallpapers.
== Feedback ==
== Benefit to Fedora ==
* The size of the default wallpaper is drastically reduced when using
JXL format compared to PNG. An example is on this [Fedora 42 Default
Wallpaper ticket](https://gitlab.com/fedora/design/team/release-artwork/default-wallp…
showing both versions for comparison.
== Scope ==
* Proposal owners:
The Design team switch the format from PNG to JXL format for the
default wallpaper on Fedora Workstation and Spin variants (optional
for spins setting a different default backgrounds).<!-- What work do
the feature owners have to accomplish to complete the feature in time
for release? Is it a large change affecting many parts of the
distribution or is it a very isolated change? What are those
changes?-->
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* 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 ==
No major impact for desktop environment supporting JXL format. If
needed, convert JXL to JPEG as fallback.
== Early Testing (Optional) ==
== How To Test ==
* Up to date Fedora Linux 41 Workstation and variants (spins included).
* Enable [COPR repository](https://copr.fedorainfracloud.org/coprs/g/design-suite/fxx-back…
from ''@design-suite/fxx-backgrounds'' or download from the [main
repository](https://koji.fedoraproject.org/koji/buildinfo?buildID=2658799)
* For Workstation Edition and variants like Cinammon spin and Design
Suite, install both ''f42-backgrounds-base'' and
''f42-background-gnome'' using the command <nowiki>sudo dnf install
f42-backgrounds-{base,gnome}</nowiki>.
* For KDE Edition and variants, install both ''f42-backgrounds-base''
and ''f42-background-kde'' using the command <nowiki>sudo dnf install
f42-backgrounds-{base,kde}</nowiki>
* For XFCE and variants, install both ''f42-backgrounds-base'' and
''f42-background-xfce'' using the command <nowiki>sudo dnf install
f42-backgrounds-{base,xfce}</nowiki>
* For Budgie Edition, install both ''f42-backgrounds-base'' and
''f42-background-budgie'' using the command <nowiki>sudo dnf install
f42-backgrounds-{base,budgie}</nowiki>
* For MATE and variants like Design Suite, install both
''f42-backgrounds-base'' and ''f42-background-mate'' using the command
<nowiki>sudo dnf install f42-backgrounds-{base,mate}</nowiki>
== User Experience ==
The change is invisible for the uses with lower footprint.
== Dependencies ==
== Contingency Plan ==
Revert to PNG format.
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoBuildEngine
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-disabling-suppor…
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 ==
We disable support of building engines in OpenSSL and remove the
deprecated openssl-devel-engine subpackage.
== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbelyavs(a)redhat.com
== Detailed Description ==
We are going to build OpenSSL without engine support. Engines are not
FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
The engine functionality we are aware of (PKCS#11, TPM) is covered by
providers. The package necessary to build engines
(openssl-devel-engine) is already declared as deprecated and will be
removed. For the applications that still unconditionally refer to
openssl/engine.h we will provide a dummy engine.h file
== Feedback ==
== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to the engine. So we reduce the maintenance
burden and potentially attack surface.
== Scope ==
* Proposal owners: maintainers of packages relying to openssl engine
functionality
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
This change probably requires mass-rebuild.
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
== How To Test ==
Applications using OpenSSL ENGINE API can't be built.
ENGINE API is still exported by libcrypto.
== User Experience ==
Users will have to reconfigure systems to providers if they use
engines. No other changes are expected.
== Dependencies ==
In theory, all OpenSSL-dependent packages. In practice, only those
that explicitly use ENGINE api.
== Contingency Plan ==
Reenable openssl-devel-engine package keeping it deprecated
* Contingency mechanism: N/A
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
TBD
== Release Notes ==
TBD
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Maven4
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-maven-4-system-w…
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 ==
Add Apache Maven 4 to Fedora Linux 43 as parallel-installable
alternative to Maven 3.
== Owner ==
* Name: [[User:Mizdebsk|Mikolaj Izdebski]]
* Email: <mizdebsk(a)redhat.com>
== Detailed Description ==
Maven 4 is a new major version of Maven after 15 years of Maven 3.
It brings many improvements, but also breaking changes.
Maven 4.0.0-rc-2 has been released in December 2024.
Final 4.0.0 version is expected to be released in year 2025.
In case the final version 4.0.0 is not released in time before Fedora
Linux 43 change completion deadline, a release candidate version will
be included in Fedora Linux 43 and may be updated to a newer version
later in Fedora Linux 43 lifecycle.
The goal of this change is to package Maven 4 and make it available as
alternative to Maven 3 in Fedora Linux 43.
It is not a goal to replace Maven 3, Maven 3 will continue to be
available to users.
It is not a goal of this change to build Fedora packages with Maven 4
- XMvn, %mvn_build etc. will continue to use Maven 3.
Switching Java packaging tools to use Maven 4 is planned in the future
and a separate system-wide change proposal is expected be submitted
for that effort, targeting a future Fedora Linux version newer than
43.
== Feedback ==
== Benefit to Fedora ==
Java software developers will be able to use the latest version of the
most popular Java development tool.
Fedora packagers will be able to start packaging Maven 4 plugins and
extensions in preparation for switching Fedora packages to be built
with Maven 4 by default in the future.
== Scope ==
* Proposal owners:
** package [https://src.fedoraproject.org/rpms/maven4 maven4] and all
of its dependencies and make them available in Fedora Linux 43
** ensure that all [https://src.fedoraproject.org/tests/maven maven
tests] are passing, including upstream integration tests (core ITs)
** ensure that maven4 package works in parallel with maven
* Other developers: N/A (not needed for this Change)
* 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: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Maven 4 will be added as a new package, parallel-installable with Maven 3.
Existing users and systems with Maven 3 installed won't be affected by
this change.
== Early Testing (Optional) ==
== How To Test ==
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Fix_limitations_in_gpgverify
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-fix-limitations-…
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 ==
<code>gpgverify</code> is a wrapper around <code>gpgv</code> designed to
make it easy for packagers to do source file verification correctly. By
accident it has some limitations that a few unusual packages have to work
around. This change removes those limitations, reducing the need for
workarounds.
== Owner ==
* Name: [[User:Rombobeorn| Björn Persson]]
* Email: [mailto:bjorn@xn--rombobjrn-67a.se Bjorn(a)xn--rombobjrn-67a.se]
== Current status ==
[[Category:ChangeReadyForWrangler]]
[[Category:SystemWideChange]]
<!-- It's not allowed to be self-contained because the change owner
isn't a maintainer of the package. -->
* Targeted release:
[https://docs.fedoraproject.org/en-US/releases/f43/ Fedora Linux 43]
* Last updated: <!-- this is an automatic macro — you don't need to
change this line -->
{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* [<link to devel-announce post will be added by Wrangler> Announced]
* [<will be assigned by the Wrangler> Discussion thread]
* FESCo issue: <will be assigned by the Wrangler>
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
== Detailed Description ==
<code>gpgverify</code> was originally written to handle the common cases
described in
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_ver…
the source file verification policy].
Since then a few unusual cases have turned up that nobody thought of when the
policy was written:
<ul><li><p>Some upstream developers publish their OpenPGP keys as separate
files instead of a combined keyring. Nginx is one example. It's a good practice
that should be encouraged. Listing each key as a separate source file in a
package makes it easy to see in the revision history whether a single key has
been added or the whole set of keys has been replaced.</p>
<p>The old <code>gpgverify</code> accepts only one keyring, so
separate keys must
be combined into a single file to be passed to <code>gpgverify</code>. There's
no reason to make packagers do that. <code>gpgv</code> accepts multiple
keyrings. The new <code>gpgverify</code> can also accept multiple keyrings and
pass them to <code>gpgv</code>.</p></li>
<li><p>Some upstream developers publish clearsigned files of checksums
of tarballs
instead of detached signatures of the tarballs. It would be easier for
everybody if they'd skip the intermediate checksum and just sign their
tarballs, but since this occurs, we should do what we can to make it easy for
packagers to verify such signatures. This is important especially because of a
treacherous pitfall: It's easy to use GnuPG wrong so that attackers can add
unsigned text to a clearsigned file and make it seem like the whole file is
verified.</p>
<p>The old <code>gpgverify</code> requires a detached signature, so any package
that needs to verify a clearsigned file has to bypass <code>gpgverify</code>
and invoke <code>gpgv</code> directly. <code>git-lfs.spec</code> tries to do
that, and gets it wrong, so it's vulnerable to spoofing. The new
<code>gpgverify</code>
can verify clearsigned files. If the signature is not detached, it insists on
writing the verified data to an output file. Further processing shall trust
only the verified contents of the output file, not the clearsigned
file.</p></li>
<li><p><code>gpgv</code> accepts keys in the keybox format. The new
<code>gpgverify</code>
also accepts them, in case anyone needs to use one.</p></li></ul>
Some people might think these limitations are unimportant because they don't
affect many packages. That's not how security works. Security requires closing
<em>every</em> loophole.
== Feedback ==
There has been no reaction whatsoever in the year and a half
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261
the merge request]
has been open.
== Benefit to Fedora ==
Maintainers of a few packages will be able to remove workarounds for the
old <code>gpgverify</code>'s limitations.
Preventing a loophole in the signature verification in even a single package
prevents attackers from using that package as an attack vector, thus improving
security for everybody.
== Scope ==
* Proposal owners:
** Implement the improvements in <code>gpgverify</code> – done.
** Write testcases – done.
* Other developers:
** Maintainers of <code>redhat-rpm-config</code>:
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261
Merge the improvements].
* Release engineering: N/A
* Policies and guidelines: No change to policies is proposed. The
Packaging Guidelines don't currently cover the unusual cases addressed
by these improvements, and it can continue to be so. If, however,
there is a desire for the Packaging Guidelines to contain complete
instructions for every possible case, then some amendments will be
needed.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: The Community Operations 2.0
Initiative, which aims to address friction in the contribution
process, may be relevant.
== Upgrade/compatibility impact ==
These improvements are fully backward-compatible. No currently working spec file
will break.
== How To Test ==
Testcases are included in
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261
the merge request].
Those same testcases
[https://www.rombobjörn.se/gpgverify-tests/ are also available for
manual testing].
Run them through <code>rpmbuild --rebuild</code>. Those with “bad” or
“invalid” in the name shall fail to build. All the others shall build
successfully.
== User Experience ==
Tightening the supply chain security will slightly decrease the risk that
users will have their computers breached through compromised Fedora packages.
== Dependencies ==
As the author isn't a maintainer of <code>redhat-rpm-config</code>,
the change depends
on a maintainer
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261
merging the improvements].
== Contingency Plan ==
* Contingency mechanism: The maintainers of
<code>redhat-rpm-config</code> can revert the commits and rebuild,
should it become necessary.
* Contingency deadline: Before any mass rebuild (because
hypothetically, if <code>gpgverify</code> would break, it could cause
many packages to fail to build).
* Blocks release? Yes. (If it would cause important packages to fail
to build, that is. But the code is already written and tested.)
== Documentation ==
The help text that <code>/usr/lib/rpm/redhat/gpgverify --help</code> prints
has been updated to explain the new parameters. One can also see the help text
by simply reading
[https://src.fedoraproject.org/fork/rombobeorn/rpms/redhat-rpm-config/raw/gp…
the file].
== Release Notes ==
N/A
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
In accordance with FESCo's Inactive Packager Policy[1], packagers that have been identified as inactive have a ticket
in the find-inactive-packagers repo[2]. One week after the final release, packagers who remain inactive will be removed
from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket
that you're still around will prevent you from showing up in the second round.)
If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the
find-inactive-packagers repo[4] if it's not there already.
For the curious, here are the stats from today's run:
### Found 1486 users in the packager group. ###
### Found 635 users with no builds in Koji over the last year. ###
### Found 305 users with no activity in pagure/src.fp.org over the last year. ###
### Found 288 users which didn't post any message in Fedora Discussion over the last year. ###
### Found 252 users which also show no activity in Bodhi over the last year. ###
### Found 226 users which also show no activity in mailing lists over the last year. ###
### Found 160 users which also show no activity in Bugzilla over the last year. ###
[1]
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
[2]
https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&sta…
[3]
https://pagure.io/find-inactive-packagers/issues?tags=feature
[4]
https://pagure.io/find-inactive-packagers/new_issue
Here it's the full list of users detected as inactive:
acui
adobes
affix
aglitke
airwave
ajmitchell
akasko
alexlan
alissonbruno
alphacc
als
arnd
arozansk
aruiz
astepano
bcornec
beldmit
benesv
bilelmoussaoui
brendt
brenton
brouhaha
bskeggs
chedi
chrissie
cn137
cooperlees
dachary
damien-lemoal
dang
davanum
davem
davidx
dcbw
deekej
dhat180
diaasami
djuran
dlehman
dmurphy18
dprince
dwysocha
edward-evans-aiven
ellio167
fenris02
fsimonce
gholms
gtiwari
hanoglu
hguemar
hushan
hvad
ib54003
icon
idiez
ikedas
imullins
irina
jbenc
jfsaucier
jkaluza
jlanda
jmarcin
jmoyer
joev
jolsa
jpechane
jsafrane
jschmidb
juergh
kanitha
kasong
kc8hfi
ksiddiqu
kumarpraveen
labbott
law
laxathom
lchilton
lkiesow
lucab
lucarval
lucilanga
luigifab
lulinqing
lupinix
major
malmond
mangelajo
markuss
martstyk
matwey
mcascella
mcbeeffx
mdcornu
mhough
michaelanguskelly
mkosek
mprivozn
msk61
murphyp
nickboldt
nim
niohiani
nkondras
nyoxi
pbabinca
pcolby
phuzion
pidgornyy
plfiorini
pmyers
poros
psalaba
puiterwijk
quintela
ralphlange
ravindrakumar
rerickso
reznik
rlescak
rpeterso
rrendec
saakla
scoady
sdyroff
sfroemer
shoracek
siddharths
siddharthvipul1
sinnykumari
snecker
snirkel
spotlesstofu
stbenjam
szidek
terrycloth
thoger
tlavocat
torbuntu
toshio
totol
tscherf
u1f35c
van
vgoyal
victortyau
vishalvvr
vmakarov
vponcova
xinghong
yahmad
yashn
yizhengxie
yonhan
yunyings
zaitcev
zaitseff
zkota
zvetlik
In accordance with FESCo policy[1], the following provenpackagers will
be submitted for removal in two weeks based on a lack of Koji builds
submitted in the last six months. If you received this directly, you
can reply off-list to indicate you should still be in the
provenpackager group.
Note that removal from this group is not a "punishment" or a lack of
appreciation for the work you have done. The intent of the process is
to ensure contributors with distro-wide package privileges are still
active and responsive. This process is done regularly at the branch
point in each release.
[1]
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintain…
Checked 123 provenpackagers
The following 9 provenpackagers have not submitted a Koji build since at least 2024-08-12 00:00:00:
mohanboddu
jerboaa
rmattes
pbrady
pmikova
dwmw2
otaylor
mgieseki
wtogami