Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
===============================================================================
VirtualGL gsgatlin Fedora 31
boo elsupergomez, orphan, tpokorra Fedora 31
gmpc orphan Fedora 31
jboss-servlet-2.5-api dmoluguw, orphan Fedora 31
js-html5shiv orphan Fedora 31
js-respond orphan Fedora 31
nodejs-info-symbol orphan Fedora 31
nodejs-interpret nodejs-sig, orphan Fedora 31
nodejs-net-browserify-alt orphan Fedora 31
nodejs-win-spawn nodejs-sig, orphan Fedora 31
rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-getiabooks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-infoslicer callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-visualmatch chimosky, orphan Fedora 31
sugar-yupana callkalpa, chimosky, orphan Fedora 31
The following packages require above mentioned packages:
Depending on: js-html5shiv (1)
copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup)
copr-frontend-1.171-1.fc34.noarch requires js-html5shiv
Depending on: nodejs-info-symbol (2)
nodejs-log-utils (maintained by: orphan)
nodejs-log-utils-0.2.1-6.fc32.noarch requires npm(info-symbol)
nodejs-time-diff (maintained by: orphan)
nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol)
Depending on: nodejs-interpret (1)
nodejs-shelljs (maintained by: fab, nodejs-sig, patches)
nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret)
Affected (co)maintainers (directly and indirectly):
callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks
chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart,
sugar-getiabooks
clime: js-html5shiv
copr-sig: js-html5shiv
dmoluguw: jboss-servlet-2.5-api
dturecek: js-html5shiv
elsupergomez: boo
fab: nodejs-interpret
frostyx: js-html5shiv
gsgatlin: VirtualGL
maxamillion: rubygem-net-ssh-multi
msuchy: js-html5shiv
nodejs-sig: nodejs-win-spawn, nodejs-interpret
patches: nodejs-interpret
pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides,
sugar-infoslicer, sugar-getiabooks
praiskup: js-html5shiv
tdawson: rubygem-net-ssh-multi
tpokorra: boo
tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, sugar-flipsticks
https://fedoraproject.org/wiki/Changes/Fedora_i3_Spin
== Summary ==
Create an official Fedora Spin shipping the popular i3 window manager.
This Spin would be the first Fedora Spin to feature a tiling/window
manager instead of a traditional desktop environment.
== Owner ==
* Names: [[User:Nasirhm|Nasir Hussain]], [[User:Jflory7|Justin W.
Flory]], [[User:X3mboy|Eduard Lucena]], [[User:Defolos| Dan
Čermák]],
== Detailed Description ==
The Fedora i3 SIG began in May 2020 with a goal of creating an
official Fedora Spin featuring the i3 tiling window manager. Since
then, a community of i3 enthusiasts around the Fedora community has
collaborated to define what an official Fedora i3 Spin would include,
how it might work, and how the Fedora community might differentiate
this Spin from other ready-to-use i3 implementations already in the
open source ecosystem.
The SIG has outlined the following design goals to guide construction
of the Spin (see
[https://docs.fedoraproject.org/en-US/i3/design-goals/ i3 SIG Design
Goals] for details):
# Simple is better than complex.
# Fast is better than features.
# There should be one—and preferably only one—obvious way to do it.
# Now is better than never.
These Design Goals inform and guide decisions regarding the Kickstart.
They are also the basis for the SIG's decisions about future changes
to the i3 Spin.
In summary, this Change is represents the realization of work that
began in May 2020. The goal is to create an official Fedora Spin based
on the i3 SIG's kickstart.
== Benefit to Fedora ==
This Change benefits end-users who run Fedora on a desktop or laptop,
particularly low-end consumer-grade hardware.
An i3 Spin would provide a better initial installation experience for
Fedora users installing i3 for the first time. Currently, end-users
who wish to use i3 on Fedora must install another Edition or Spin of
Fedora, then install the i3 window manager (and related packages)
separately (a process often requiring use of an external guide or
tutorial). Additionally, this "two-step" method adds unnecessary
packages to the user's system, particularly if the end-user does not
wish to use another desktop environment.
Moreover, the i3 SIG hypothesizes an official i3 Spin will have the
lightest footprint (memory and base install size) of any Fedora
Edition or Spin, but testing this hypothesis requires more data.
== Scope ==
* Proposal owners:
** '''Finalize kickstart composition'''. The i3 SIG is finalizing a
list of packages for an integrated i3 desktop.
** '''Work with RelEng to build'''. The i3 SIG needs to work with
Release Engineering to pick up the i3 Spin in regular composes.
** '''Test Day coordination'''. Work with the Fedora QA team to plan
and run a series of Test Days to solicit early feedback. An excited
group of users in our IRC/Telegram are ready to help.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/9864 #9864]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval:
[https://pagure.io/Fedora-Council/tickets/issue/343#comment-707009
#343]
== Upgrade/compatibility impact ==
Since the Fedora i3 Spin is a Spin, it assumes new installations only.
There is no upgrade/compatibility impact from the Spin.
Eventually, the i3 SIG will also create a package group (composition)
for `i3` and `i3-extended`. Fedora users can more easily switch from
another desktop environment by installing the package group.
== How To Test ==
1. Boot the Fedora i3 Spin ISO image either on bare-metal or in a
virtual machine (V.M.).
2. Confirm successful boot into a configured i3 environment with basic
packages available.
3. Launch Anaconda installer. The Anaconda installer can be launched
either from a terminal or via the application launcher `dmenu`.
4. Confirm no major issues with windows and display. The installed
system uses `lightdm` as the login manager and comes preinstalled with
i3 as the default desktop environment with default applications
present for most uses cases.
== User Experience ==
New Fedora users can install i3 from https://spins.fedoraproject.org
instead of installing another desktop, and then manually installing i3
after the initial install. This reduces the number of steps needed to
start using i3.
Additionally, the i3 Spin intends to be a ready-to-use, integrated i3
configuration. Often a new i3 user must find or set up other system
utilities for things like networking, profile management, and other
common desktop functions. The Fedora i3 Spin offers a ready-to-go
environment that aims to offer an integrated, lightweight environment
without pulling in larger dependency stacks from other desktops.
== Dependencies ==
See `%packages`
[https://pagure.io/i3-sig/Fedora-i3-Spin/blob/master/f/fedora-i3-common.ks#_…
in fedora-i3-common.ks].
== Contingency Plan ==
* Contingency mechanism: If a blocker bug comes up that breaks
composes of the i3 Spin in time for Fedora 34, the Change can be
bumped to a future Fedora release (e.g. F35).
* Contingency deadline: Change Checkpoint: 100% Code Complete Deadline
(Tue 2021-02-23)
* Blocks release? No
== Documentation ==
* https://docs.fedoraproject.org/en-US/i3/
* https://pagure.io/i3-sig/docs
== Release Notes ==
TBD.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ibus-m17n_as_default_Sinhala_IME
== Summary ==
The current default input method for Sinhala is ibus-sayura. This
should change to the ibus-m17n input method “m17n:si:sayura - sayura
(m17n)”
== Owner ==
* Name: [[User:Mfabian| Mike Fabian]]
* Email: <mfabian(a)redhat.com>
== Detailed Description ==
The current Fedora default input method ibus-sayura seems to be not
actively maintained.
Fixing bugs like this one
https://bugzilla.redhat.com/show_bug.cgi?id=1724759
is therefore difficult.
The ibus-m17n input method si-sayura.mim does exactly the same (I
developed this one to be an exact replacement for ibus-sayura).
As ibus-sayura offers no additional benefit, it is probably better to
use ibus-m17n with si-sayura as the default input method for Sinhala.
ibus-m17n has to be maintained anyway. Therefore, this saves the
effort of fixing the unmaintained ibus-sayura.
== Benefit to Fedora ==
Save maintenance cost in maintaining ibus-sayura. si-sayura from
m17n-db can be used both with ibus-m17n and with ibus-typing-booster,
so actually it is more useful than ibus-sayura.
== Scope ==
* Proposal owners:
** update default IME in comps @input methods
** update langpacks-vi to use ibus-m17n and m17n-db
** the langtable package has data about default input methods. Change this data.
* Other developers: gnome-desktop3 for default si_LK input method
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The package installed by default will change from ibus-sayura to the
packages ibus-m17n and m17n-db for an installation in Sinhala.
== How To Test ==
Install Fedora in Sinhala and check that the default input method is
si-sayura with ibus-m17n.
== User Experience ==
* There should be very little difference in typing Vietnamese as
ibus-sayura and ibus-m17n with si-sayura.mim behave the same.
* The setup tool looks a little different.
* Package sizes and dependent packages are different.
* Memory usage is different.
== Dependencies ==
ibus-m17n and m17n-db
* comps has to be updated
== Contingency Plan ==
Revert changes back to ibus-sayura
* Contingency mechanism: Revert comps and gnome-desktop3
* Contingency deadline: Beta release
* Blocks release? No
* Blocks product? None
== Documentation ==
https://github.com/ibus/ibus-m17n
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/RPMCoW
== Summary ==
RPM Copy on Write provides a better experience for Fedora Users as it
reduces the amount of I/O and offsets CPU cost of package
decompression. RPM Copy on Write uses reflinking capabilities in
btrfs, which is the default filesystem in Fedora 33.
== Owners ==
* Name: [[User:malmond|Matthew Almond]], [[User:dcavalca|Davide Cavalca]]
* Email: malmond(a)fb.com, dcavalca(a)fb.com
== Detailed description ==
Installing and upgrading software packages is a standard part of
managing the lifecycle of any operating system. For the entire
lifecycle of Fedora, all software is packaged and distributed using
the RPM file fomat. This proposal changes how software is downloaded
and installed, leaving the distribution process unmodified.
=== Current process ===
# Resolve packaging request into a list of packages and operations
# Download and verify new packages
# Install and/or upgrade packages sequentially using RPM files,
decompressing, and writing a copy of the new files to storage.
=== New process ===
# Resolve packaging request into a list of packages and operations
# Download and '''decompress''' packages into a '''locally optimized''' rpm file
# Install and/or upgrade packages sequentially using RPM files, using
'''reference linking''' (reflinking) to reuse data already on disk.
The outcome is intended to be the same, but the order of operations is
different.
# Decompression happens inline with download. This has a positive
effect on resource usage: downloads are typically limited by
bandwidth. Decompression and writing the full data into a single file
per rpm is essentially free. Additionally: if there is more than one
download at a time, a multi-CPU system can be better utilized. All
compression types supported in RPM work because this uses the rpm I/O
functions.
# RPMs are cached on local storage between downloading and
installation time as normal. This allows DNF to defer actual RPM
installation to when all the RPM are available. This is unchanged.
# The file format for RPMs is different with Copy on Write. The
headers are identical, but the payload is different. There is also a
footer.
## Files are converted (“transcoded”) locally during download using
<code>/usr/bin/rpm2extents</code> (part of rpm codebase). The format
is not intended to be “portable” - i.e. copying the files from the
cache is not supported.
## Regular RPMs use a compressed .cpio based payload. In contrast,
extent based RPMs contain uncompressed data aligned to the fundamental
page size of the architecture, e.g. 4KiB on x86_64. This alignment is
required for <code>FICLONERANGE</code> to work. Only files are
represented in the payload, other directory entries like symlinks,
device nodes etc are constructed entirely from rpm header information.
Files are referenced by their digest, so identical files are
de-duplicated.
## The footer currently has three sections
### Table of original (rpm) file digests, used to validate the
integrity of the download in dnf.
### Table of digest → offset used when actually installing files.
### Signature 8 bytes at the end of the file, used to differentiate
between traditional RPMs and extent based.
=== Notes ===
# The headers are preserved bit for bit during transcoding. This
preserves signatures. The signatures cover the main header blob, and
the main header blob ensures the integrity of data in two ways:
## Each file with content has a digest. Originally this was md5, but
today it’s usually sha256. In normal RPM this is only used to verify
the integrity of files, e.g. <code>rpm -V</code>. With CoW we use this
as a content key.
## There is/are one or two digests (<code>PAYLOADDIGEST</code> and
<code>PAYLOADDIGESTALT</code>) covering the payload archive
(compressed cpio). The header value is preserved, but transcoded RPMs
do not preserve the original structure so RPM’s pre-installation
verification (controlled by <code>%_pkgverify_level</code> will fail.
<code>dnf-plugin-cow</code> disables this check in dnf because it
verifies the whole file digest which is captured during
download/transcoding. The second one is likely used for delta rpm.
# This is untested, and possibly incompatible with delta RPM (drpm).
The process for reconstructing an rpm to install from a delta is
expensive from both a CPU and I/O perspective, while only providing
marginal benefits on download size. It is expected that having delta
rpm enabled (which is the default) will be handled gracefully.
# Disk space requirements are expected to be marginally higher than
before: all new packages or updates will consume their installed size
before installation instead of about half their size (regular rpms
with payloads still cost space).
# <code>rpm-plugin-reflink</code> will fall back to simple file
copying when the destination path is not on the same
filesystem/subvolume. A common example is <code>/boot</code> and/or
<code>/boot/efi</code>.
# The system will still work on other filesystem types, but will
''always'' fall back to simple copying. This is expected to be
slightly slower than not enabling CoW because the source for copying
will be the decompressed data.
# For systems that enable transparent filesystem compression: every
file will continue to be decompressed from the original rpm, and then
transparently re-compressed by the filesystem. There is no effective
change here. There is a future project to investigate alternate
distribution mechanics to provide parallel versions of file content
pre-compressed in a filesystem specific format, reducing both CPU
costs and I/O. It is expected that this will result in slightly higher
network utilization because filesystem compression is purposely
restricted to allow random I/O.
# Current implementation of <code>dnf-plugin-cow</code> is in Python,
but it looks possible to implement this in <code>libdnf</code> instead
which would make it work in <code>packagekit</code>.
=== Performance Metrics ===
Ballpark performance difference is about half the duration for file
download+install time. A lot of rpms are very small, so it’s difficult
to see/measure. Larger RPMs give much clearer signal.
(Actual numbers/charts will be supplied in Jan 2021)
=== Terminology ===
* '''Copy on Write (CoW)''' is a broad description of any technology
that reduces or eliminates data duplication by sharing the data behind
the scenes until one of the references makes changes. This has been a
cornerstone technology in memory management in Unix systems. Here we
are using it to specifically reference Copy on Write as supported in
modern filesystems, e.g. btrfs, xfs and potentially others.
* '''Reflink''' is the verb for duplicating stored data on a
filesystem. See
[https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html
ioctl_ficlonerange(2)] for the specific call we use on Linux
* '''Extent''' (based RPMs) refers to how payload file data is stored
in within an RPM. Normal RPMs simply contain a compressed CPIO
archive. Extent based RPMs contain the raw data uncompressed, which
can be referenced with reflink.
== Benefit to Fedora ==
Faster package installs and upgrades
== Scope ==
* Proposal owners:
** Merge changes to rpm, librepo to enable capabilities
** Add dnf-plugin-cow to available packages
** Test days
** Aid with documentation
* Other developers:
** rpm, librepo: review PRs as needed
* Release engineering: https://pagure.io/releng/issue/9914
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None, RPM with CoW is not enabled by default.
Upgrades with <code>keepcache</code> in dnf.conf will be able to use
existing packages, but it will not convert them. This only happens at
download time.
If a system is configured to keep packages in the cache
(<code>keepcache</code> in <code>dnf.conf</code>) and
<code>dnf-plugin-cow</code> is removed then the packages will be
unusable. Recommend <code>dnf clean packages</code> to resolve this.
== How to test ==
Enable RPM with CoW with
<pre>$ sudo dnf install dnf-plugin-cow
...
$ sudo dnf install hello
...
$ hello
Hello, world!</pre>
There should be no end user visible changes, except timing.
== User experience ==
No anticipated user visible changes in this change proposal. This
makes the feature available, but does not enable it by default.
== Dependencies ==
# A copy-on-write filesystem; this Change is primarily targeting
btrfs, but RPM with CoW should work with XFS as well (untested)
# Most package install paths and the dnf package cache on the same
filesystem / subvolume.
# <code>rpm</code> with Copy on Write patch set:
https://github.com/malmond77/rpm/tree/cow
# <code>librepo</code> with transcoding support:
https://github.com/malmond77/librepo/tree/transcode_cow
# dnf-plugin-reflink (a new package):
https://github.com/facebookincubator/dnf-plugin-cow/
== Contingency plan ==
* Contingency mechanism: will not include PR patches if not merged
upstream, skip <code>dnf-plugin-cow</code>
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
Documentation will be available at
https://github.com/facebookincubator/dnf-plugin-cow in the coming
weeks
== Release Notes ==
RPM with CoW is not enabled by default. To enable it:
<pre>$ sudo dnf install dnf-plugin-cow</pre>
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/EnableSystemdOomd
== Summary ==
Provide a better experience for Fedora users in out-of-memory (OOM)
situations by enabling
[https://www.freedesktop.org/software/systemd/man/systemd-oomd.html
systemd-oomd] by default. Actions taken by systemd-oomd operate on a
per-cgroup level, aligning well with the life cycle of systemd units.
systemd-oomd primarily uses [https://facebookmicrosites.github.io/psi/
Linux pressure stall information (PSI)] to make decisions based on
wasted productivity due to resource shortages; in addition to that, it
also supports swap based actions.
== Owners ==
* Name: [[User:anitazha|Anita Zhang]], [[User:Dcavalca|Davide
Cavalca]], [[User:Salimma|Michel Salim]], [[User:Htejun|Tejun Heo]],
[[User:3ki|Rik van Riel]]
* Email: the.anitazha(a)gmail.com, dcavalca(a)fb.com,
michel(a)michel-slm.name, htejun(a)fb.com, riel(a)fb.com
== Detailed description ==
The primary mechanism used by systemd-oomd for detecting when the
system is out of memory is memory pressure. Memory pressure measures
the percentage of time a cgroup has “wasted” due to lack of memory.
This includes time spent reclaiming free memory, faulting in recently
resident pages, and loading in anonymous pages from swap. When a
monitored cgroup’s memory pressure exceeds the specified thresholds,
systemd-oomd will perform action(s) on the targeted cgroup’s
descendants, starting from the cgroups with the most reclaim scans.
Reclaim activity is used here, rather than the largest consumer, as it
reflects values set in the cgroup memory controller for memory
protection (such as memory.low).
For memory pressure configuration, this will be
ManagedOOMMemoryPressure=kill and ManagedOOMMemoryPressureLimit=4% on
user@.service to have systemd-oomd send SIGKILLs to all processes
under a selected cgroup when total memory pressure on all tasks
exceeds 4% for 10 seconds.
For swap based actions, systemd-oomd will monitor the system-wide swap
space and act when available swap falls below the configured
threshold, starting with the cgroups with the highest swap usage to
the least. Keeping some amount of swap (if enabled) available will
prevent the kernel OOM killer from killing processes unpredictably and
spending an unbounded amount of time afterwards.
For swap configuration, this will be SwapUsedLimitPercent=90% in
oomd.conf and ManagedOOMSwap=kill on -.slice (root cgroup slice) to
have systemd-oomd send SIGKILLs to all processes under a cgroup when
swap used exceeds 90%.
== Benefit to Fedora ==
* Addressing the issue of improving user feedback in
https://pagure.io/fedora-workstation/issue/202, systemd-oomd currently
logs to the journal if pressure or swap action is about to occur.
There are also debug logs, for each process that is sent a SIGKILL,
that can be bumped up in priority. Further notification mechanisms
(i.e. over dbus) can also be implemented depending on feedback.
* While systemd-oomd is simpler in configuration to the oomd used at
Facebook, the algorithm is largely the same. As such, the following
case study can be used as an example of how PSI and cgroup killing can
release memory not normally resolved with process killing and lead to
better utilization:
https://facebookincubator.github.io/oomd/docs/oomd-casestudy.html
* OOM killing in userspace, before the kernel OOM killer kicks in, has
been shown to be effective at keeping a system functional. An OOM kill
in the kernel is slow, possibly leading to an unbounded amount of time
swapping in and out pages and evicting the page cache.
* PSI based actions, versus looking at raw memory consumption numbers,
better reflect memory protection policies set for cgroup resource
control limits (e.g. memory.low).
== Scope ==
* Proposal owners:
** Implement and land additional refinements to systemd-oomd
*** Remove swap as a hard requirement to running systemd-oomd
*** Expand ManagedOOM*= properties to user units (currently only
usable on system units)
*** Configurable memory pressure time window knob
** Enable oomd by default with sensible configuration
** Test days
** Aid with documentation
* Other developers:
** systemd: review PRs as needed
* Release engineering: https://pagure.io/releng/issue/9913
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Existing systems running earlyoom will not be modified. One can
transition to systemd-oomd via:
<pre>sudo systemctl disable --now earlyoom
sudo systemctl enable --now systemd-oomd</pre>
Systems that were previously not running earlyoom will have
systemd-oomd enabled by default.
== How to test ==
systemd 247 build for Fedora includes all the artifacts for
systemd-oomd. It is disabled by default but can be started with:
<pre>sudo systemctl enable --now systemd-oomd</pre>
At this point you can decide which units to set properties on. For
example, to enable swap-based killing on all units below the root
slice:
<pre>sudo systemctl edit --force -- -.slice
[Slice]
ManagedOOMSwap=kill
# save and exit</pre>
Note that the following memory pressure example requires the changes
listed in “Scope” to work as expected, as systemd-oomd shipped with
systemd v247 does not support changing the time window for memory
pressure. This example was run on a system with swap:
<pre>systemctl edit user@.service
[Service]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=4%
# save and exit
systemd-run --user tail /dev/zero # will lead to a lot of reclaim and
then OOM if not killed</pre>
== User experience ==
This should be a fully transparent change for users.
== Dependencies ==
None. If changes to oomd are required to address feedback to this
proposal, they will need to be merged in systemd.
== Contingency plan ==
* Contingency mechanism: For workstation, owner will revert all
changes and we’ll go back to using earlyoom instead
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
https://www.freedesktop.org/software/systemd/man/systemd-oomd.html<br />
https://www.freedesktop.org/software/systemd/man/oomctl.html<br />
https://www.freedesktop.org/software/systemd/man/oomd.conf.html
== Release Notes ==
systemd-oomd is enabled by default. Depending on which systemd units
have ManagedOOMSwap=kill or ManagedOOMMemoryPressure=kill,
systemd-oomd will SIGKILL all the processes under the appropriate
descendant cgroups when the configured limits are exceeded.
To revert back to earlyoom, run:
<pre>sudo systemctl disable --now systemd-oomd
sudo systemctl enable --now earlyoom</pre>
See man oomd.conf for configuration options.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
===============================================================================
VirtualGL gsgatlin Fedora 31
boo elsupergomez, tpokorra Fedora 31
gmpc orphan Fedora 31
jboss-servlet-2.5-api dmoluguw, orphan Fedora 31
js-html5shiv orphan Fedora 31
js-respond orphan Fedora 31
nodejs-info-symbol orphan Fedora 31
nodejs-interpret nodejs-sig, orphan Fedora 31
nodejs-net-browserify-alt orphan Fedora 31
nodejs-win-spawn nodejs-sig, orphan Fedora 31
rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-getiabooks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-infoslicer callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-visualmatch chimosky, orphan Fedora 31
sugar-yupana callkalpa, chimosky, orphan Fedora 31
The following packages require above mentioned packages:
Depending on: js-html5shiv (1)
copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup)
copr-frontend-1.171-1.fc34.noarch requires js-html5shiv
Depending on: nodejs-info-symbol (2)
nodejs-log-utils (maintained by: orphan)
nodejs-log-utils-0.2.1-6.fc32.noarch requires npm(info-symbol)
nodejs-time-diff (maintained by: orphan)
nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol)
Depending on: nodejs-interpret (1)
nodejs-shelljs (maintained by: fab, nodejs-sig, patches)
nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret)
Affected (co)maintainers (directly and indirectly):
callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks
chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart,
sugar-getiabooks
clime: js-html5shiv
copr-sig: js-html5shiv
dmoluguw: jboss-servlet-2.5-api
dturecek: js-html5shiv
elsupergomez: boo
fab: nodejs-interpret
frostyx: js-html5shiv
gsgatlin: VirtualGL
maxamillion: rubygem-net-ssh-multi
msuchy: js-html5shiv
nodejs-sig: nodejs-win-spawn, nodejs-interpret
patches: nodejs-interpret
pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides,
sugar-infoslicer, sugar-getiabooks
praiskup: js-html5shiv
tdawson: rubygem-net-ssh-multi
tpokorra: boo
tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, sugar-flipsticks
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_6.1
== Summary ==
Ruby on Rails 6.1 is the latest version of well known web framework
written in Ruby.
== Owner ==
* Name: [[User:pvalena| Pavel Valena]], [[User:vondruch| Vít
Ondruch]], [[User:jaruga| Jun Aruga]]
* Email: pvalena(a)redhat.com, vondruch(a)redhat.com, jaruga(a)redhat.com,
ruby-sig(a)lists.fedoraproject.org
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 6.0 in Fedora 33 to 6.1 (latest version) in Fedora 34.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.
== Benefit to Fedora ==
This update will keep Fedora up-to-date and will ensure that the
current Ruby on Rails developers stay with us as they will get support
for system-packaged Ruby on Rails of the latest version. Apart from
that, update to Rails 6.1 will bring Horizontal Sharding, Multi-DB
Improvements, Strict Loading, Destroy Associations in Background,
Error Objects and more. Update to Rails 6.1 contains hundreds of other
fixes and improvements across all the frameworks.
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated.
** Some dependencies of the Rails stack will need update.
=== Packages need to be created/updated ===
{|
! Package name
! Task
! Bug
! Pull Request
|-
|rubygem-actioncable
|Update to 6.1.x
|[https://bugzilla.redhat.com/show_bug.cgi?id=1906179 #1906179]
|[https://src.fedoraproject.org/rpms/rubygem-actioncable/pull-request/2 PR]
|-
|rubygem-actionmailbox
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionmailbox/pull-request/1 PR]
|-
|rubygem-actionmailer
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionmailer/pull-request/2 PR]
|-
|rubygem-actionpack
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionpack/pull-request/2 PR]
|-
|rubygem-actiontext
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actiontext/pull-request/1 PR]
|-
|rubygem-actionview
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionview/pull-request/2 PR]
|-
|rubygem-activejob
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activejob/pull-request/2 PR]
|-
|rubygem-activemodel
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activemodel/pull-request/2 PR]
|-
|rubygem-activerecord
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activerecord/pull-request/3 PR]
|-
|rubygem-activestorage
|Update to 6.1.x
|[https://bugzilla.redhat.com/show_bug.cgi?id=1906180 #1906180]
|[https://src.fedoraproject.org/rpms/rubygem-activestorage/pull-request/3 PR]
|-
|rubygem-activesupport
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activesupport/pull-request/3 PR]
|-
|rubygem-rails
|Update to 6.1.x
|[https://bugzilla.redhat.com/show_bug.cgi?id=1906183 #1906183]
|[https://src.fedoraproject.org/rpms/rubygem-rails/pull-request/2 PR]
|-
|rubygem-railties
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-railties/pull-request/2 PR]
|}
Current development state can be observed in
[https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/
pvalena/ruby-on-rails] COPR repository.
* Other developers: Update Rails dependent packages to be working with
Ruby on Rails 6.1
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Web applications build above Ruby on Rails framework might need to be
updated. Official upstream upgrade guide might come handy:
http://guides.rubyonrails.org/upgrading_ruby_on_rails.html
== How To Test ==
* No special hardware is needed.
=== To test Rails 6.1 from upstream ===
<pre>
gem install rails -v 6.1.x
rails new app
cd app && rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 6.1.x
=== To test only Rails itself ===
<pre>
dnf install rubygem-rails
rails new app
cd app && rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 6.1.x
=== To test the complete feature including generating a new Rails app
using RPM ===
<pre>
dnf group install 'Ruby on Rails'
rails new app --skip-bundle && cd app
rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 6.1.x
== User Experience ==
* New version of Ruby on Rails (6.1) available
* The most significant Rails 6.1 features:
** Multi-DB Improvements
** Horizontal Sharding
** Strict Loading Associations
** Delegated Types
** Destroy Associations Async
** Error Objects
** Active Storage Improvements
** Disallowed Deprecation Support
* Please also note:
** The classic Autoloader is Deprecated
== Dependencies ==
* There are several packages, which depends on Ruby on Rails framework.
* These needs to be surely updated:
** (none)
* Following gems don't support Rails 6.1 right now and would be broken
by the update:
** (none)
* As Rails requires Ruby >= 2.5, the platform less than the version
can not use Rails 6.1.
== Contingency Plan ==
* Contingency mechanism: None needed. Rails stack won't be updated
until all its dependencies are in Rawhide. After that, it will be a
simple matter of updating the core packages (and their dependencies).
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
* http://api.rubyonrails.org/
== Release Notes ==
* https://edgeguides.rubyonrails.org/6_1_release_notes.html
* https://weblog.rubyonrails.org/2020/12/9/Rails-6-1-0-release/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).
== Owner ==
* Name: [[User:clime| Michal Novotný]]
* Email: clime(a)fedoraproject.org
== Detailed Description ==
There is a recently added feature into mock:
[https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocess…
the rpkg preprocessor] which, if enabled, introduces an intermediate
step just before srpm building. This step consists of running the spec
file through a text preprocessing engine that includes an already
present library of macros designed specifically for rpm spec file
generation from git metadata. This library is called
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros]. The macros there allow packagers to have their
`%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
automatically generated from dist-git repository data and metadata.
The library can be easily extended in future to support more packager
use-cases or even a completely new library can be developed that
doesn't look at git metadata at all and instead, for example, analyses
already present tarball content to render spec file based on upstream
information. This doesn't mean it will happen but the framework is
generic enough to support that. There is also support for user-defined
macros that are loaded on-demand from a file placed alongside the
package sources, maintained by packager. This feature wouldn't be
enabled by this change from start but it's an example of freedom that
the preprocessing framework is able to provide. Enabling this change
should be very easy, basically adding:
<pre>
config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
</pre>
into mock configuration of Koji builders and using at least mock 2.7.
Some very minor change may be also needed in Koji regarding the spec
file lookup.
Even if the change is enabled on the infrastructure level like this,
the packager will still need to opt-in to use the preprocessor. The
opting-in is done by placing `rpkg.conf` file into the package
top-level directory with the following content:
<pre>
[rpkg]
preprocess_spec = True
</pre>
When this is done by a packager, the preprocessor will be finally
enabled for the given package.
Alongside, there is an ongoing work to add the preprocessor support
into the `rpkg` python library so that a packager can easily work with
the spec files containing the preprocessor (rpkg) macros:
https://pagure.io/rpkg/pull-request/530
The macros are supported since epel6 until the most latest Fedora
(preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
spec preprocessing step in mock happens in a target chroot just before
the srpm build.
== Benefit to Fedora ==
This change offers solution to some long-standing issues in Fedora
around packaging (i.e. automatic release and changelog generation)
while also offering some interesting future options (for example
unpacked dist-git repos). The big advantage of this approach is that
it is explicit. Spec file stays the source of truth and by looking
inside one, you will be able to determine how the text will expand for
a certain git repository state.
== Scope ==
* Proposal owners:
For the very basic support, probably a small patch in Koji is needed
to be able to lookup not only `.spec` files but also `.spec.rpkg`
files (the `.spec.rpkg` extension explicitly states that the spec file
is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
be tweaked to be compatible with spec files using the macros.
* Other developers:
Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be welcome.
* Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a
check of an impact with Release Engineering is needed)
Enabling the rpkg_preprocessor plugin in mock config for Koji builders.
* Policies and guidelines:
The new macro support should be mentioned or even described in the
packaging guidelines. We should decide if the full power of the
rpkg-macros library should be allowed from start (i.e. even unpacked
repos).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Because of the opt-in nature on packager side, there should be no
compatibility issues.
== How To Test ==
Once the feature is enabled, one can test it by providing the
`rpkg.conf` file with the required content in a package repository and
use some rpkg macro in the spec file: e.g.
<pre>
Name: {{{ git_dir_name }}}
</pre>
to generate the name of the package from the repository name (this
should actually produce the original text as package names should be
the same as the repository basenames).
To try it out first without committing to dist-git, one can use `rpkg`
command-line tool from
https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ or even
fedpkg's koji scratch build after
[https://pagure.io/rpkg/pull-request/530 the work in the pyrpkg]
library is finished.
One can also currently use Copr's SCM "rpkg" build method where the
macros are enabled but the rpkg-macros there are in version 2 whereas
this change is about introducing the
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html version 3
rpkg-macros]. However, while there are some differences between v2 and
v3, the idea and most of the working is the same.
== User Experience ==
This change is intended for packagers. It should help to make a bit of
their work easier and offer them some new interesting options.
== Dependencies ==
N/A
== Contingency Plan ==
Packagers can opt-out on individual basis by removing the `rpkg.conf`
file or just setting the `preproces_spec` property to `False`. On
infrastructure level, the rpkg_preprocessor plugin could be disabled
again.
== Documentation ==
- [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocess…
Mock's rpkg_preprocessor plugin]
- [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros reference (the library of macros ready to be used in spec
files)]
== Release Notes ==
Currently N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/golang1.16
== Summary ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jcajka(a)redhat.com, alexsaezm(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34. Golang
1.16 is scheduled to be released in February 2021.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.
== Benefit to Fedora ==
Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.16 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 34, help resolve
possible issues found
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking
issue.[https://pagure.io/releng/issue/9904]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
;0.
:a) Install golang 1.16 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.16 should work as expected.
== User Experience ==
None
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed ~1600.
</pre>
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.15.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.16
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis