Fedora 33 Self-Contained Change proposal: Drop mod_php
by Ben Cotton
https://fedoraproject.org/wiki/Changes/drop_mod_php
== Summary ==
mod_php (apache2handler) is an optional httpd module to execute PHP
scripts, not used.
== Owner ==
* Name: [[User:Remi| Remi Collet]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
By default php-fpm is used for a few versions. mod_php is not
supported for threaded modules. mod_php usage also increases security
risk, sharing the same process than httpd.
Drop mod_php from php build. This will only affect user of httpd in
"prefork" mode, which will also use php-fpm.
php-fpm is already used but most users of httpd and nginx without any issue.
The "php" package will be kept as a metapackage, installing (weak
dependencies) most commonly used extension, thus reducing the
difference between "yum install php" (flat repository) and "yum module
install php" (modular repository).
== Benefit to Fedora ==
Only provide the modern way to execute PHP in a web server.
== Scope ==
PHP rebuild (mod_php build is already conditional)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* install and play with your web applications
== User Experience ==
No change.
== Dependencies ==
None (dependency on "php" is already forbidden by Guidelines)
== Contingency Plan ==
* revert
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
* Blocks product? product
== Documentation ==
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
15 minutes
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
21 minutes
Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
== Summary ==
As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install
earlyoom package, and enable it by default. If both RAM and swap go below
10% free, earlyoom issues SIGTERM to the process with the largest
oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL
to the process with the largest oom_score. The idea is to recover from out
of memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
== Owner ==
* Name: [[User:bcotton|Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
Shamelessly copied from Workstation, which did it in the last release:
Certain workloads have heavy memory demands, quickly consume all of RAM,
and start to heavily page out to swap. (Heavy paging, is often called "swap
thrashing" for added descriptive effect, probably because it's noticeable
and annoying). Incidental swap usage is a good thing, it frees up memory
for active pages used by a process. Heavy swap usage quickly leads to a
very negative UX, because it's slow, even on modern SSDs. Due to installer
defaults, the swap partition is made the same size as available memory (at
install time), which can be huge. This just extends swap thrashing time.
On the one hand, we want this resource hungry job to complete. On the other
hand, we want our system to be responsive while that other work is going
on. But once the GUI stutters or even comes to an apparent stand still
(hang), we're really wishing the kernel oom-killer would kick in and free
up memory, so we can start over (maybe using memory or thread limiting
options - which arguably should be more intelligently figured out, and that
too is a work in progress but beyond the scope of this feature).
However, once in a heavy swap scenario, it's relatively common the system
gets stuck in it, where GUI interactivity is terrible to non-existent, and
also the kernel oom-killer doesn't trigger. From a certain point of view,
this is working as intended. The kernel oom-killer is concerned about
keeping the kernel running. It's not at all concerned about user space
responsiveness.
Instead of the system becoming completely unresponsive for tens of minutes,
hours or days, this feature expects that an offending process (determined
by oom_score, same as the kernel oom-killer) will be killed off within
seconds or a few minutes.
== Benefit to Fedora ==
KDE users will be able to take advantage of the benefits Workstation users
got from enabling earlyOOM in Fedora 32:
* improved user experience by more quickly regaining control over one's
system, rather than having to force power off in low-memory situations
where there's aggressive swapping. Once a system becomes unresponsive, it's
completely reasonable for the user to assume the system is lost, but that
includes high potential for data loss.
* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how to
handle them better
* earlyoom first sends SIGTERM to the chosen process, so it has a chance of
a proper shutdown, unlike the kernel's oom-killer
== Scope ==
* Proposal owners:
** Modify {{code|
https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in}} to include
earlyoom package for in {{code|kde-desktop}} section.
** Add {{code|
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-kde.pr...
to include:
<pre>
# enable earlyoom by default on KDE
enable earlyoom.service
</pre>
* Other developers: None, unless KDE-based Spins/Labs want to opt out
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a newly-installed system.
== How To Test ==
* Fedora 31/32 KDE users can test today:
** {{code|sudo dnf install earlyoom}}
** {{code|sudo systemctl enable --now earlyoom}}
And then attempt to cause an out of memory situation. Examples:
** {{code|tail /dev/zero}}
** https://lkml.org/lkml/2019/8/4/15
== User Experience ==
earlyoom sends SIGTERM to processes based on oom_score when both memory and
swap have less than 10% free and SIGKILL when below 5%.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Owner reverts
changes
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
* {{code|man earlyoom}}
* https://github.com/rfjakob/earlyoom
* https://www.kernel.org/doc/gorman/html/understand/understand016.html
== Release Notes ==
The earlyoom service is now enabled by default in Fedora KDE.
The earlyoom service monitors system memory usage. If free memory falls
below a set limit, earlyoom terminates an appropriate process to free up
memory. As a result, the system does not become unresponsive for long
periods of time in low-memory situations.
The following is the default earlyoom configuration:
* If both RAM and swap go below 10% free, earlyoom sends the SIGTERM signal
to the process with the largest oom_score.
* If both RAM and swap go below 5% free, earlyoom sends the SIGKILL signal
to the process with the largest oom_score.
For more information, see the earlyoom man page.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
11 hours, 12 minutes
Fedora 33 System-Wide Change proposal: Make btrfs the default file
system for desktop variants
by Ben Cotton
https://fedoraproject.org/wiki/Changes/BtrfsByDefault
== Summary ==
For laptop and workstation installs of Fedora, we want to provide file
system features to users in a transparent fashion. We want to add new
features, while reducing the amount of expertise needed to deal with
situations like [https://pagure.io/fedora-workstation/issue/152
running out of disk space.] Btrfs is well adapted to this role by
design philosophy, let's make it the default.
== Owners ==
* Names: [[User:Chrismurphy|Chris Murphy]], [[User:Ngompa|Neal
Gompa]], [[User:Josef|Josef Bacik]], [[User:Salimma|Michel Alexandre
Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:eeickmeyer|Erich
Eickmeyer]], [[User:ignatenkobrain|Igor Raits]],
[[User:Raveit65|Wolfgang Ulbrich]], [[User:Zsun|Zamir SUN]],
[[User:rdieter|Rex Dieter]], [[User:grinnz|Dan Book]],
[[User:nonamedotc|Mukundan Ragavan]]
* Emails: chrismurphy(a)fedoraproject.org, ngompa13(a)gmail.com,
josef(a)toxicpanda.com, michel(a)michel-slm.name, dcavalca(a)fb.com,
erich(a)ericheickmeyer.com, ignatenkobrain(a)fedoraproject.org,
fedora(a)raveit.de, zsun(a)fedoraproject.org, rdieter(a)gmail.com,
grinnz(a)gmail.com, nonamedotc(a)gmail.com
* Products: All desktop editions, spins, and labs
* Responsible WGs: Workstation Working Group, KDE Special Interest Group
== Detailed Description ==
Fedora desktop edition/spin variants will switch to using Btrfs as the
filesystem by default for new installs. Labs derived from these
variants inherit this change, and other editions may opt into this
change.
The change is based on the installer's custom partitioning Btrfs
preset. It's been well tested for 7 years.
'''''Current partitioning'''''<br />
<span style="color: tomato">vg/root</span> LV mounted at <span
style="color: tomato">/</span> and a <span style="color:
tomato">vg/home</span> LV mounted at <span style="color:
tomato">/home</span>. These are separate file system volumes, with
separate free/used space.
'''''Proposed partitioning'''''<br />
<span style="color: tomato">root</span> subvolume mounted at <span
style="color: tomato">/</span> and <span style="color:
tomato">home</span> subvolume mounted at <span style="color:
tomato">/home</span>. Subvolumes don't have size, they act mostly like
directories, space is shared.
'''''Unchanged'''''<br />
<span style="color: tomato">/boot</span> will be a small ext4 volume.
A separate boot is needed to boot dm-crypt sysroot installations; it's
less complicated to keep the layout the same, regardless of whether
sysroot is encrypted. There will be no automatic snapshots/rollbacks.
If you select to encrypt your data, LUKS (dm-crypt) will be still used
as it is today (with the small difference that Btrfs is used instead
of LVM+Ext4). There is upstream work on getting native encryption for
Btrfs that will be considered once ready and is subject of a different
change proposal in a future Fedora release.
=== Optimizations (Optional) ===
The detailed description above is the proposal. It's intended to be a
minimalist and transparent switch. It's also the same as was
[[Features/F16BtrfsDefaultFs|proposed]] (and
[https://lwn.net/Articles/446925/ accepted]) for Fedora 16. The
following optimizations improve on the proposal, but are not critical.
They are also transparent to most users. The general idea is agree to
the base proposal first, and then consider these as enhancements.
==== Boot on Btrfs ====
* Instead of a 1G ext4 boot, create a 1G Btrfs boot.
* Advantage: Makes it possible to include in a snapshot and rollback
regime. GRUB has stable support for Btrfs for 10+ years.
* Scope: Contingent on bootloader and installer team review and
approval. blivet should use <code>mkfs.btrfs --mixed</code>.
==== Compression ====
* Enable transparent compression using zstd on select directories:
<span style="color: tomato">/usr</span> <span style="color:
tomato">/var/lib/flatpak</span> <span style="color:
tomato">~/.local/share/flatpak</span>
* Advantage: Saves space and significantly increase the lifespan of
flash-based media by reducing write amplification. It may improve
performance in some instances.
* Scope: Contingent on installer team review and approval to enhance
anaconda to perform the installation using <code>mount -o
compress=zstd</code>, then set the proper XATTR for each directory.
The XATTR can't be set until after the directories are created via:
rsync, rpm, or unsquashfs based installation.
==== Additional subvolumes ====
* <span style="color: tomato">/var/log/</span> <span style="color:
tomato">/var/lib/libvirt/images</span> and <span style="color:
tomato">~/.local/share/gnome-boxes/images/</span> will use separate
subvolumes.
* Advantage: Makes it easier to excluded them from snapshots,
rollbacks, and send/receive. (Btrfs snapshotting is not recursive, it
stops at a nested subvolume.)
* Scope: Anaconda knows how to do this already, just change the
kickstart to add additional subvolumes (minus the subvolume in <span
style="color: tomato">~/</span>. GNOME Boxes will need enhancement to
detect that the user home is on Btrfs and create <span style="color:
tomato">~/.local/share/gnome-boxes/images/</span> as a subvolume.
== Feedback ==
==== Red Hat doesn't support Btrfs? Can Fedora do this? ====
Red Hat supports Fedora well, in many ways. But Fedora already works
closely with, and depends on, upstreams. And this will be one of them.
That's an important consideration for this proposal. The community has
a stake in ensuring it is supported. Red Hat will never support Btrfs
if Fedora rejects it. Fedora necessarily needs to be first, and make
the persuasive case that it solves more problems than alternatives.
Feature owners believe it does, hands down.
The Btrfs community has users that have been using it for most of the
past decade at scale. It's been the default on openSUSE (and SUSE
Linux Enterprise) since 2014, and Facebook has been using it for all
their OS and data volumes, in their data centers, for almost as long.
Btrfs is a mature, well-understood, and battle-tested file system,
used on both desktop/container and server/cloud use-cases. We do have
developers of the Btrfs filesystem maintaining and supporting the code
in Fedora, one is a Change owner, so issues that are pinned to Btrfs
can be addressed quickly.
==== What about device-mapper alternatives? ====
dm-thin (thin provisioning):
[[https://pagure.io/fedora-workstation/issue/152 Issue #152] still
happens, because the installer won't over provision by default. It
still requires manual intervention by the user to identify and resolve
the problem. Upon growing a file system on dm-thin, the pool is over
committed, and file system sizes become a fantasy: they don't add up
to the total physical storage available. The truth of used and free
space is only known by the thin pool, and CLI and GUI programs are
unprepared for this. Integration points like rpm free space checks or
GNOME disk-space warnings would have to be adapted as well.
dm-vdo: is not yet merged, and isn't as straightforward to selectively
enable per directory and per file, as is the case on Btrfs using
<code>chattr +c</code> on <span style="color:
tomato">/var/lib/flatpaks/</span>.
Btrfs solves the problems that need solving, with few side effects or
pitfalls for users. It has more features we can take advantage of
immediately and transparently: compression, integrity, and IO
isolation. Many Btrfs features and optimizations can be opted into
selectively per directory or file, such as compression and nodatacow,
rather than as a layer that's either on or off.
==== What about UI/UX and integration in the desktop? ====
If Btrfs isn't the default file system, there's no commitment, nor
reason to work on any UI/UX integration. There are ideas to make
certain features discoverable: selective compression; systemd-homed
may take advantage of either Btrfs online resize, or near-term planned
native encryption, which could make it possible to live convert
non-encrypted homes to encrypted; and system snapshot and rollbacks.
Anaconda already has sophisticated Btrfs integration.
==== What Btrfs features are recommended and supported? ====
The primary goal of this feature is to be largely transparent to the
user. It does not require or expect users to learn new commands, or to
engage in peculiar maintenance rituals.
The full set of Btrfs features that is considered stable and enabled
by default upstream will be enabled in Fedora. Fedora is a community
project. What is supported within Fedora depends on what the community
decides to put forward in terms of resources.
The upstream [https://btrfs.wiki.kernel.org/index.php/Status Btrfs
feature status page].
==== Are subvolumes really mostly like directories? ====
Subvolumes behave like directories in terms of navigation in both the
GUI and CLI, e.g. <code>cp</code>, <code>mv</code>, <code>du</code>,
owner/permissions, and SELinux labels. They also share space, just
like a directory.
But it is an incomplete answer.
A subvolume is an independent file tree, with its own POSIX namespace,
and has its own pool of inodes. This means inode numbers repeat
themselves on a Btrfs volume. Inodes are only unique within a given
subvolume. A subvolume has its own st_dev, so if you use <code>stat
FILE</code> it reports a device value referring to the subvolume the
file is in. And it also means hard links can't be created between
subvolumes. From this perspective, subvolumes start looking more like
a separate file system. But subvolumes share most of the other trees,
so they're not truly independent file systems. They're also not block
devices.
== Benefit to Fedora ==
Problems Btrfs helps solve:
* Users running out of free space on either <span style="color:
tomato">/</span> or <span style="color: tomato">/home</span>
[https://pagure.io/fedora-workstation/issue/152 Workstation issue
#152]
** "one big file system": no hard barriers like partitions or logical volumes
** transparent compression: significantly reduces write amplification,
improves lifespan of storage hardware
** reflinks and snapshots are more efficient for use cases like
containers (Podman supports both)
* Storage devices can be flaky, resulting in data corruption
** Everything is checksummed and verified on every read
** Corrupt data results in EIO (input/output error), instead of
resulting in application confusion, and isn't replicated into backups
and archives
* Poor desktop responsiveness when under pressure
[https://pagure.io/fedora-workstation/issue/154 Workstation issue
#154]
** Currently only Btrfs has proper IO isolation capability via cgroups2
** Completes the resource control picture: memory, cpu, IO isolation
* File system resize
** Online shrink and grow are fundamental to the design
* Complex storage setups are... complicated
** Simple and comprehensive command interface. One master command
** Simpler to boot, all code is in the kernel, no initramfs complexities
** Simple and efficient file system replication, including incremental
backups, with <code>btrfs send</code> and <code>btrfs receive</code>
== Scope ==
* Proposal owners:
** Submit PR's for Anaconda to change <code>default_scheme =
BTRFS</code> to the proper product files.
** Multiple test days: build community support network
** Aid with documentation
* Other developers:
** Anaconda, review PRs and merge
** Bootloader team, review PRs and merge
** Recommended optimization <code>chattr +C</code> set on the
containing directory for virt-manager and GNOME Boxes.
* Release engineering: [https://pagure.io/releng/issue/9545 #9545]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Change will not affect upgrades.
Documentation will be provided for existing Btrfs users to "retrofit"
their setups to that of a default Btrfs installation (base plus any
approved options).
== How To Test ==
'''''Today'''''<br />
Do a custom partitioning installation; change the scheme drop-down
menu to Btrfs; click the blue "automatically create partitions"; and
install.<br />
Fedora 31, 32, Rawhide, on x86_64 and ARM.
'''''Once change lands'''''<br />
It should be simple enough to test, just do a normal install.
== User Experience ==
==== Pros ====
* Mostly transparent
* Space savings from compression
* Longer lifespan of hardware, also from compression.
* Utilities for used and free space, CLI and GUI, are expected to
behave the same. No special commands are required.
* More detailed information can be revealed by <code>btrfs</code>
specific commands.
==== Enhancement opportunities ====
[https://bugzilla.redhat.com/show_bug.cgi?id=906591 updatedb does not
index /home when /home is a bind mount] Also can affected rpm-ostree
installations, including Silverblue.
[https://gitlab.gnome.org/GNOME/gnome-usage/-/issues/49 GNOME Usage:
Incorrect numbers when using multiple btrfs subvolumes] This isn't
Btrfs specific, happens with "one big ext4" volume as well.
[https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/88 GNOME Boxes,
RFE: create qcow2 with 'nocow' option when on btrfs /home] This is
Btrfs specific, and is a recommended optimization for both GNOME Boxes
and virt-manager.
[https://github.com/containers/libpod/issues/6563 containers/libpod:
automatically use btrfs driver if on btrfs]
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Owner will revert changes back to LVM+ext4
* Contingency deadline: Beta freeze
* Blocks release? Yes
* Blocks product? Workstation and KDE
== Documentation ==
Strictly speaking no documentation is required reading for users. But
there will be some Fedora documentation to help get the ball rolling.
For those who want to know more:
[https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki main
page and full feature list.]
<code>man 5 btrfs</code> contains: mount options, features, swapfile
support, checksum algorithms, and more<br />
<code>man btrfs</code> contains an overview of the btrfs subcommands<br />
<code>man btrfs <nowiki><subcommand></nowiki></code> will show the man
page for that subcommand
NOTE: The btrfs command will accept partial subcommands, as long as
it's not ambiguous. These are equivalent commands:<br />
<code>btrfs subvolume snapshot</code><br />
<code>btrfs sub snap</code><br />
<code>btrfs su sn</code>
You'll discover your own convention. It might be preferable to write
out the full command on forums and lists, but then maybe some folks
don't learn about this useful shortcut?
For those who want to know a lot more:
[https://btrfs.wiki.kernel.org/index.php/Main_Page#Developer_documentation
Btrfs developer documentation]<br />
[https://github.com/btrfs/btrfs-dev-docs/blob/master/trees.txt Btrfs trees]
== Release Notes ==
The default file system on the desktop is Btrfs.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
12 hours, 39 minutes
RPM-level auto release and changelog bumping - Fedora 33 System-Wide
Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel...
== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
technical level
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-aut...
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
accordingly.
To get beautiful changelogs, you also need to add
<pre>
%buildsys_name Your name
%buildsys_email Your email
</pre>
in ~/.rpmmacros
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac...
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
19 hours, 15 minutes
Fedora 33 Self-Contained Change proposal: NSS dbm support removal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
== Summary ==
Network Security Services (NSS) historically supports 2 different
database backends, based on SQLite and dbm. Since Fedora 28, the
SQLite backend has been used by default and the dbm backend has been
deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format
SQL]]). This Change is about removing the support for the dbm backend
entirely.
== Owner ==
* Name: [[User:ueno| Daiki Ueno]]
* Email: dueno(a)redhat.com
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different storage
formats, one is based on SQLite and another one is based on dbm files.
Today's default file format used by NSS, used when applications omit
the type parameter, is the SQLite file format, and the older dbm
format has been considered as deprecated since Fedora 28, because it
has several drawbacks such as lack of support for parallel access to
the storage.
As the default change was made 2 years ago, and NSS provides a
transparent migration mechanism from the dbm format to the SQLite
format, the suggestion is to completely disable the dbm backend.
== Benefit to Fedora ==
There are a few benefits:
* By disabling the dbm database, the size of the library binary will
be slightly smaller
* The NSS developers will be able to focus on the new file format
== Scope ==
* Proposal owners:
A build time environment variable (NSS_DISABLE_DBM) needs to be set.
* Other developers: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The impact should be limited, as long as the users always update from
the previous version. That would ensure the existing databases on the
system are properly migrated. Therefore, we propose this as a Self
Contained Change, rather than a System Wide Change.
In the discussion on the fedora-devel list, it was pointed that pesign
package embedded the dbm format database. It has now been resolved in
[https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902].
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No user visible changes.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
1 day, 16 hours
Packagers with no corresponding valid bugzilla accounts
by Pierre-Yves Chibon
Good Morning Everyone,
If you are a packagers or are watching tickets on dist-git (ie: asked to be
cc'ed on tickets on bugzilla for a given package), you must have a valid
bugzilla account associated with the email address you have set in FAS.
There are currently 66 users and groups who do not satisfy this requirement.
This has a direct impact as the script syncing from dist-git to bugzilla the
information about the default assignee and the CC list updates components in
bugzilla in a single request to reduce the load on the server.
So if someone in the CC list does not have a valid bugzilla account, the
entire request will fail to update both the CC list and the default assignee.
Accounts in this state may at some point be removed from packages/cc, so it's
important to correct your account soon!
So, if your name is listed here, please take a minute and create a bugzilla
for the email you have associated with your FAS account:
aarondmarasco
adsllc
affix
ajeetdsouza
alen
amitshah
andreyma
avesh
bpereto
@certbot-sig
csomh
darkdragon001
dcantrel
digimer
dmsimard
doug1
edwintorok
etingof
fepitre
gnikandrov
@graphics-sig
ignotusp
itsbill
jefferson2z
jkratoch
jkreuzer
karsten
kir
klausdevwalker
labbott
lamm
luismartingil
marcdeop
mathstuf
mbartos
mhabrnal
mildew
mmahut
moisesguimaraes
mzidek
nguzman
njohnston
omejzlik
pgibson
portante
proski
rbtr
robled
romal
rpitonak
rspanton
sakalosj
squallbayu
sspreitz
sturivnyi
svahl
tnorth
trasher
tstclair
usercont
vbatts
vicodan
vpolasek
@weldr-sig
yuwata
zmc
If you really to have two distinct email addresses, we keep a mapping of FAS
emails to bugzilla account in [1], which you can update via a pull-request if
you wish to use this.
Thanks for your help,
Pierre
[1]
https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps...
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
2 days, 17 hours
Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
by Ben Cotton
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
== Summary ==
<code>%cmake</code> macro will be adjusted (<code>-B</code> parameter)
to use separate build folder (already standardized
<code>%{_vpath_builddir}</code> macro). Additionally,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro will be created (and backported to the older
supported Fedora releases) to perform various operations that are
commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
etc.) way.
Packages that will stop building are trivial to fix and will be
adjusted either by maintainers or change owners.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
Esser]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain(a)fedoraproject.org, besser82(a)fedoraproject.org,
ngompa13(a)gmail.com
== Detailed Description ==
Historically, software builds had a singular build configuration and
required running the build within the project root. Nowadays, there
are many build modes and options that can be configured in projects,
different build settings (e.g. compiler flags) / types (release,
debug) that can be applied and different tools that can be used to
actually execute builds (compilers like gcc/clang, build job
schedulers like make/ninja, and so on). Thus, CMake upstream strongly
discourages users of doing in-source builds and recommends doing
out-of-source builds.
From <code>cmake.1</code>:
<pre>
To maintain a pristine source tree, perform an out-of-source build by
using a separate dedicated build tree. An in-source build in which the
build tree is placed in the same directory as the source tree is also
supported, but discouraged.
</pre>
The other part of the change is introduction of additional macros is
creation of set of macro that can build, install and run tests in a
backend-agnostic, vpath-aware (out-of-source, in-source) way.
=== Migration ===
==== <code>%cmake</code> + <code>%(make|ninja)_(build|install)</code> ====
There are multiple paths to complete the migration:
* Add <code>-C "%{_vpath_builddir}"</code> to the <code>%(make|ninja)_*</code>
* Replace <code>%(make|ninja)_build</code> and
<code>%(make|ninja)_install</code> with <code>%cmake_build</code> and
<code>%cmake_install</code> respectively
* Redefine vpath builddir <code>%global _vpath_builddir .</code> to
continue performing in-source builds (and optionally converting to the
<code>%cmake_*</code>)
Depending on the package, one of these options may be used to adapt to
this change.
==== <code>%cmake -B builddir</code> +
<code>%(make|ninja)_(build|install) -C builddir</code> ====
No changes are needed.
== Benefit to Fedora ==
* Follow CMake upstream recommendations when building packages
* Brings Fedora package builds more in-line with how upstream projects
expect them to be built
* Improve compatibility with other RPM distributions that already do this
* Support backend-agnostic way of building CMake projects
== Scope ==
* Proposal owners: Implement necessary macros, try to build packages
that <code>BuildRequires: cmake</code> in a side tag, analyze failures
and fix the relevant ones (introduced by this change).
* Other developers: While proposal owners will try to fix all affected
packages, there might be some cases where package is already FTBFS so
the fix can't be performed. Other package maintainers will have to fix
the issue themselves after they fix FTBFS.
* Release engineering: [https://pagure.io/releng/issue/9524 #9524]
* Policies and guidelines: CMake page will be adjusted to mention
newly created macros and the documentation about relevant VPATH macros
needs to be restructured a bit (they are already documented on the
Meson page, they need to be moved to the separate page and referenced
both from CMake and Meson page).
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Existing packages can (and most likely will) become FTBFS, but
proposal owners will fix as many Fedora packages as possible. However
fixing third-party packages is not possible and out of scope.
Third-party packagers will need to adapt based on the recommendations
noted in this Change.
== How To Test ==
# Grab the new cmake RPM from the Koji sidetag (TBC)
# Try to build package that uses <code>%cmake</code>,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro
== User Experience ==
The end-users (non-packagers) will not notice any changes.
== Dependencies ==
There are around 1100 RPMs in Fedora that depend on CMake at
build-time. All proposal owners are provenpackagers so they are able
to commit necessary fixes. No external dependencies.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will adjust macros to not do
out-of-source builds by default, but will preserve newly created macro
(essentially to bring them to the targeted state of older supported
Fedora releases).
* Contingency deadline: Beta freeze.
* Blocks release? No
== Documentation ==
The only place that needs to be adjusted is packaging guidelines.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 days, 19 hours
Questions on an update to javamail in ursine
by Jie Kang
Hi all,
javamail ursine is using version 1.5.2 while there are some module
streams at 1.6.x
The upstream project also moved to the eclipse foundation and these
1.6.x releases have different exports for OSGi, making an update to
them potentially breaking for users.
I'd like to update ursine to 1.6.x, but I understand packages
depending on them should be notified or some such. However I realized
I don't know what commands to run to get a list of such and then where
to send it. Could anyone advise?
Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail
so maybe a new package 'mail' can be introduced to use it? Any
thoughts there?
Thanks,
Jie Kang
2 days, 21 hours
