fedbot spamming in #fedora
by Germano Massullo
Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times
per day about Fedora respins update?
[16:51] <fedbot> *** F32-20200715 updated lives available:
https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more
info #fedora-respins ***
3 years, 6 months
s390x builder issues
by kevin
Greetings.
As many of you know, the s390x builders have been very slow or failing
builds with intermittent i/o issues for a while now.
I've done what I can to mitigate this on the builder level, but the
problem is at a deeper level.
I've been asked to try and collect issues that package maintainers are
hitting on these builders and provide them to mainframe admins so they
can understand the impact on us and prioritize more resources or other
corrective measures.
To that end, if you are a maintainer and:
* A build on s390x being slow affects you (needed for another build,
important bug fix, etc) in a serious way
or
* a build on a s390x builder fails in some odd way that is NOT related
to your package (unable to download src.rpm, checksum mismatches, etc).
I'd love for you to note:
* the link to the failed/slow task
* The time (UTC preferred)
* which exact builder it was
* what the issue was
* how it impacted your fedora work
into: https://pagure.io/fedora-infrastructure/issue/9232
Please don't post to the list, mail me privately, etc.
Just add the info to the above issue.
Thanks for your help
kevin
_______________________________________________
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...
3 years, 6 months
PostgreSQL 13 - Fedora 33 Self-Contained Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PostgreSQL_13
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
== Owner ==
* Name: [[User:panovotn| Patrik Novotny]]
* Email: panovotn(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Benefit to Fedora ==
Latest stable software is used by Fedora users.
== Scope ==
* Proposal owners:
<!-- 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?-->
**Prepare PostgreSQL 13 as a module for Rawhide and at least one
stable Fedora release (done)
**Prepare PostgreSQL 12 as a module for Rawhide, so there would be a
failover in case of problems
**Build PostgreSQL 13 to Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible, so
there shouldn't be any issues, but rebuild of the depended components
is better to be sure. There is a
[https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
COPR build] available for testing.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.
== How To Test ==
Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.
Test that all other software runs well with PostgreSQL 13.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade`.
If users want to stick with PostgreSQL 12 for a little longer, there
should be PostgreSQL 12 module.
If users want to test it before it reaches Fedora 33, there is a
[https://copr.fedorainfracloud.org/coprs/panovotn/postgresql-13beta2/
COPR build] available.
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In both
the cases, rebuild should be done to make sure all potential binary
incompatibilities are handled.
== Contingency Plan ==
Modules will provide the functional version of PostgreSQL 12,
available to all users.
== Documentation ==
Upgrade startegy: https://www.postgresql.org/docs/13/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 13 release:
https://www.postgresql.org/docs/13/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/13/release-13.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 6 months
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
3 years, 7 months
Searching a new home for my packages
by Thomas Spura
Hi all,
unfortunately, I don't find much time anymore to look for my packages ..
Due to that, I would like to step down as the primary maintainer and
am searching for a new home for my packages!
On most of them, I am co-maintainer and the following are the ones, where I
am maintainer (and hope I didn't forget one, if so, please let me know):
- python-jupyter-client
- python-jupyter-core
- python-matplotlib
- python-tornado
- ipython
- mpi4py
- php-zmq
- pynac
Feel free to let me know, if you are interested in taking any of those
packages.
Best,
Thomas
--
Fedora: https://fedoraproject.org/wiki/User:Tomspur
3 years, 7 months
Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
by Stephan Bergmann
All,
The below question came up in the context of a LibreOffice unit test,
where LibreOffice writes out a PNG image (involving zlib for
compression) and the test checked the exact sequence of bytes, which
failed on aarch64 when using Fedora's zlib. (Though the resulting
images look rather identical. Full thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2020-August/085792.html>
"CppunitTest_sw_htmlexport failing due to zlib variation?")
Given the Fedora zlib aarch64 optimization patches quoted below: Does
anybody know whether it is indeed the case that the above scenario
(client code using zlib to generate a PNG image) can legitimately
generate varying output depending on zlib implementation details? Or
would that rather indicate a bug somewhere?
Thanks,
Stephan
-------- Forwarded Message --------
Subject: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
Date: Wed, 26 Aug 2020 08:37:15 +0200
From: Stephan Bergmann <sbergman(a)redhat.com>
To: libreoffice(a)lists.freedesktop.org
On 25/08/2020 11:07, Stephan Bergmann wrote:
> At least when building recent master on recent Fedora rawhide aarch64
> with (among others) --with-system-zlib, CppunitTest_sw_htmlexport fails
> with
[...]
> The base64-encoded payload apparently is a PNG image. And from what
> little I know about PNG, it looks plausible to me that there can be
> different (compressed) PNG content that decompress to identical raw
> data, and that the LibreOffice code would be allowed to generate
> differing (compressed) PNG content for the above data:image/png URL
> payload.
What supports the theory that "the LibreOffice code would be allowed to
generate differing (compressed) PNG content" is the Fedora zlib commit
<https://src.fedoraproject.org/rpms/zlib/c/25e9802713484882c27c1f979a6610a...>
"aarch64 optimizations", adding lots of code that presumably is only
relevant for aarch64 and presumably changes details of the compression
algorithm.
3 years, 7 months
services impact on startup times
by Chris Murphy
Hi,
These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso
in a VM. The numbers are different on bare metal but correlate.
The only standout is rngd.service. That's a pretty big single hit,
percentage wise. And I don't know if we even need it anymore. Among
the rest, perhaps atd.service and crond.service could be disabled by
default on new installations, in favor of systemd timers.
Startup finished in 1.320s (kernel) + 1.344s (initrd) + 7.727s
(userspace) = 10.392s
disable atd.service
Startup finished in 1.308s (kernel) + 1.310s (initrd) + 7.557s
(userspace) = 10.176s
disable dbxtool.service
Startup finished in 1.302s (kernel) + 1.291s (initrd) + 7.527s
(userspace) = 10.120s
disable import-state.service
Startup finished in 1.308s (kernel) + 1.326s (initrd) + 7.410s
(userspace) = 10.044s
disable iscsi.service
Startup finished in 1.316s (kernel) + 1.303s (initrd) + 7.177s
(userspace) = 9.797s
disable libvirtd.service
Startup finished in 1.316s (kernel) + 1.266s (initrd) + 6.779s
(userspace) = 9.361s
disable lvm2-monitor.service
Startup finished in 1.315s (kernel) + 1.323s (initrd) + 6.750s
(userspace) = 9.389s
disable mdmonitor.service
Startup finished in 1.316s (kernel) + 1.350s (initrd) + 6.675s
(userspace) = 9.342s
disable ModemManager.service
Startup finished in 1.270s (kernel) + 1.305s (initrd) + 7.052s
(userspace) = 9.629s
disable nfs-convert.service
Startup finished in 1.312s (kernel) + 1.343s (initrd) + 6.958s
(userspace) = 9.614s
disable rngd.service
Startup finished in 1.308s (kernel) + 1.277s (initrd) + 5.247s
(userspace) = 7.833s
disable switcheroo-control.service
Startup finished in 1.308s (kernel) + 1.334s (initrd) + 5.223s
(userspace) = 7.867s
disable vboxservice.service
Startup finished in 1.301s (kernel) + 1.302s (initrd) + 5.176s
(userspace) = 7.780s
disable crond.service
Startup finished in 1.310s (kernel) + 1.278s (initrd) + 5.076s
(userspace) = 7.665s
preset-all
Startup finished in 1.316s (kernel) + 1.312s (initrd) + 7.869s
(userspace) = 10.498s ##stopwatch 11.35
disable atd.service crond.service iscsi.service rngd.service vboxservice.service
Startup finished in 1.305s (kernel) + 1.294s (initrd) + 5.505s
(userspace) = 8.105s ##stopwatch 8.89
All of these times are based on 'systemd-analyze'. The stopwatch
method is less precise but still demonstrates the difference is real.
It may not be a big enough deal to do anything about it this cycle,
but could be something to look at for the next. Maybe more
opportunities are available.
--
Chris Murphy
3 years, 7 months
Switching package to fragmented default configuration
by Miroslav Lichvar
I'm considering to split the default configuration file in the chrony
package to make it easier for vendors, products, and configuration
tools to override some specific settings (like the default NTP
servers) by dropping a file into a directory, instead of having to
modify a packaged config file. It seems to be a modern trend, used
by many packages in Fedora, and I have received some RFEs to adopt
in chrony.
The default /etc/chrony.conf would just have a single directive
loading configuration fragments from /etc/chrony.d and
/var/lib/chrony.d (and maybe also /var/run/chrony.d).
My concern is that it will basically break all existing tools that
need to check and/or modify the configuration (e.g. anaconda). They
will need to know the naming of the files which have specific settings
in order to override them, or implement a parser duplicating the
chronyd logic to figure out which files are loaded from where. Also,
I'm not sure how user-friendly this is for regular users who modify
the configuration manually.
Are there any recommendations for switching an existing single-config
package to a fully fragmented configuration? Is it worth the trouble,
or do you have any other suggestions?
Thanks,
--
Miroslav Lichvar
3 years, 7 months
Fedora Jam 33 Beta - Possible Blocker?
by Erich Eickmeyer
HI all,
Since the release of Koji 1.22, there has been a bug [1] blocking any
Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine,
this is making me quite nervous. As it turns out, I'm waiting for Koji
1.22 to be released so that images can start building again. If this
isn't done in time for beta, then that means Fedora Jam will be unable
to participate in beta testing.
The issue in question is caused because Jam adds "threadirqs" as a boot
argument in addition to the normal boot arguments. This is a way to add
some low-latency characteristics to a kernel that isn't otherwise a
lowlatency kernel and is known to cut-down on xruns in audio production.
However, one question came up as to if threadirqs is a default in the
kernel configuration, but nobody could answer that. I was wondering if
anyone on this list knew?
I'm also going to be a little more intentional with working with the
pipewire developers on figuring out jack compatibility issues during the
F34 release cycle.
Thanks,
Erich
[1] https://pagure.io/koji/issue/2437
--
Erich Eickmeyer
Maintainer
Fedora Jam
3 years, 7 months
