Neal and I are looking at getting ButterManager packaged, and it
depends on sip and PyQt5-sip:
Now, this is where things get a bit odd:
- the current sip (4.19.24) does not have autogenerated Python
provides, but sip5 does:
$ sudo dnf repoquery --provides sip
Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53
sip = 4.19.24-1.fc33
sip(x86-64) = 4.19.24-1.fc33
sip-macros = 4.19.24-1.fc33
$ sudo dnf repoquery --provides sip5
Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53
python-sip5 = 5.5.0-1.fc33
python3-sip5 = 5.5.0-1.fc33
python3.9-sip5 = 5.5.0-1.fc33
python3.9dist(sip) = 5.5
python3dist(sip) = 5.5
sip5 = 5.5.0-1.fc33
sip5(x86-64) = 5.5.0-1.fc33
- sip ships PyQt5 bindings with matching version, but sip 5 seems to no
longer do so
$ sudo dnf info python3-pyqt5-sip
Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53
Name : python3-pyqt5-sip
Version : 4.19.24
Release : 1.fc33
Architecture : x86_64
Size : 244 k
Source : sip-4.19.24-1.fc33.src.rpm
Repository : @System
From repo : fedora
Summary : SIP - Python 3/C++ Bindings Generator for pyqt5
URL : https://riverbankcomputing.com/software/sip/intro
License : GPLv2 or GPLv3 and (GPLv3+ with exceptions)
Description : This is the Python 3 build of pyqt5-SIP.
- https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but
https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in
Fedora (available since last month)
- there's a lot of packages that depend on python3-pyqt5-sip (though
none use the canonical python3dist(pyqt5-sip) unfortunately)
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020
04:28:29 PM PST.
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020
04:28:29 PM PST.
Any idea what's the best way to handle this? and/or why PyQt5-sip's
versioning get so far ahead of sip?
Michel Alexandre Salim
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
As we start a new year, I'm thinking about data retention in general. :)
In my experience, it's pretty rare on an end-user laptop or desktop system for
logs from much more than the previous boot to be interesting. Maybe I
occasionally want to look back a little while to see if a problem just
started. It's exceedingly rare that I need (or want) to look back more than
Right now, we don't set MaxRetentionSec, so journal expiry on Workstation is
entirely based on disk usage.
Logs can accidentally contain sensitive data, and it's just plain faster to
work with them when there's less. I propose we set this to something like
six months by default.
Fedora Project Leader
Recently I've reported some Big Endian related test failures to an
upstream project .
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI 
Any better tips? Thanks
== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally
based on PipeWire. This means that all existing clients using the
PulseAudio client library
will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.
== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.
== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
* PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
closer to the experience of other operating systems.
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
and the management into separate processes. This makes it possible
to better integrate with
the other system components or swap out the default policy for a
highly customized one (such as
for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience
and configuration of the
audio infrastructure with better integration throughout the system.
PipeWire was designed for high performance and low-latency, using
much of the same design as
JACK. JACK application should run with comparable performance even
in low-latency situations.
PipeWire enforces per client security. Object visibility and the
actions on them can be
configured independently per client. This makes it possible to
enforce a security policy for
sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
block them from interfering with other applications.
Both PulseAudio and JACK have very slow development cycles with few
new features. The more
flexible and distributed nature of the design of PipeWire should
encourage more new features
== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.
* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34
* avahi network discovery and audio routing. This is not enabled by
default but can be activated
with paprefs. this includes TCP and RTP transport of audio.
* make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
* easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the
pulseaudio daemon will not be used
Most of the JACK workflow of managing the JACK daemon is not going to
be needed anymore as things
will work out-of-the-box. As of this writing, these things are missing
from the JACK implementation,
we hope to implement them before fedora 34:
* latency reporting: useful to align streams
* freewheeling: used when rendering a project
* jackdbus: used by some tools to manage the graph
== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which
removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which
removes the original
JACK client and server.
After these changes, a restart is needed to make sure the new
pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
- pavucontrol: check volumes in the input devices tabs and check the
- firefox: check out a website with audio/video such as youtube and
verify that audio works as
usual. Check out a website with a video chat test page
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
== User Experience ==
In general, users should not be able to see any change when using
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices will
be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies ==
Other packages might need to have their requirements fixed to work
with the replacement packages
but this is under our control.
== Contingency Plan ==
* Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
When we work on rebuilding Python packages with new Python version and when
other provenpackagers rebuild multiple packages at once, I've seen several
problems with packages failing to build from source and/or creating unexpected
breakage in rawhide when built. Usually, some of the following happens:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for now.
Or they submit a build but never check if it actually built. Provenpackagers who
need to rebuild the package need to figure this out and fix the problem if it is
trivial, or revert the recent commit, when the failure blocks them.
IMHO Provenpackagers should not need to worry about this. Changes should be at
least smoke tested by a mock/scratch build and installation check before
2. Changes that work but are waiting on external factors
Packager pushes a breaking change to dist git (such as a soname bump) before
coordinating the change with the dependent packages, not intending to
immediately build it. A provenpackager rebuilds the package for a different
reason (such as a different soname bump), accidentally shipping the
not-yet-wanted upgrade to rawhide.
IMHO Provenpackagers should not need to worry about this. Commits should land in
dist git only when they are intended to be built (close to) immediately. The
only reasonable exception is when building the pushed changes in a side tag and
even then, packagers should communicate their intentions.
3. Work-in-progress changes
Packager works on a package. They have a work in progress solution to their
problem, but no time to finish. They push a "WIP" commit that either breaks the
build or produces a broken package. The symptoms are similar to (1) or (2). I've
heard packagers saying "but this is rawhide, this is where development happens,
so this is expected" - I disagree.
I'd like to explicitly say that neither of this is considered a good behavior.
I'd like to have a policy that more or less says:
1. Packagers MUST NOT push changes that are not considered ready to be built and
shipped at the time of the push. Using Pull Requests (clearly marked as not
ready to be merged) is a better place to present/save changes that are not ready
2. Packagers SHOULD preemptively check if the changes they intend to push work.
At least checking if the intended change builds and the package installs with it
is strongly recommended. In cases where the check is skipped for time reasons
(e.g. when a testing build takes several hours and the changes are urgent),
packagers SHOULD be ready to fix the build/installation failure in timely manner
after it is discovered by the actual build.
Before I try to word it more carefully I'd like to hear some feedback on this.
What do you think?
Over the course of the past few months, I have become employed by a
company to provide their user software experience. This has limited the
time that I have, and, unfortunately, my involvement in Fedora has, and
needs to, decrease.
I currently maintain the Fedora Jam lab, and would like some help with
that. Just last night, while I was trying to relax after my day, I was
CC'd on two bug reports only because I'm Jam's maintainer, when really
the responsibility for the issues in question (pipewire related in
Rawhide) lie on the change owner(s) for the Pipewire-By-Default change.
I fixed a couple of packages only as a courtesy that were related to
the issue (unable to install the @audio group), but that responsibility
lies with the change owner(s), of which I'm not a part due to time
restrictions. I removed myself from the bug report after that and had
explained that they needed to add the change owner(s).
This same person that CC'd me on that decided to then file a bug report
against Jam 34 which is currently FTBFS due to the aforementioned issue
with the @audio group. Since we (spin/lab maintainers) get automated
emails about these things, I told them not to file bug reports against
spins/labs in the future and closed it as errata. I realize this person
was only trying to help, but it caused me some undo stress.
This made me realize that I need to take a step back. Not only have I
gained employment with a company that is using Ubuntu as their base
(specifically Kubuntu with Ubuntu Studio partnership), but I've also
become a MOTU with Ubuntu ("Master Of The Universe [repository]", much
like a proven packager here). As such, Fedora isn't exactly integral to
what I do, but I'd like to keep my rpm packaging skills somewhat
sharpened, which is why I'll be keeping certain packages that I have
direct involvement upstream with (e.g. studio-controls).
So, here's what I'm looking for:
* Someone to help me maintain Jam
* Including fedora-jam-backgrounds and fedora-jam-kde-theme packages
* Co-maintainers and/or new maintainers for the following packages:
Simply let me know which package you'd like and if you'd like to
maintain or co-maintain along with your fas username.
Thanks in advance,
This topic was brought up several times already, but I don't think there has
been a satisfactory answer to it yet. So let's try again.
We have recently updated python-elementpath-2.1.1-2.fc34 and
python-xmlschema-1.4.1-1.fc34 -- it requires a very simple bootstrapping that
can be seen in the git history.
I know that the ELN rebuild tooling cannot handle bootstrapping and I know it
has been told this will eventually be solved. I appreciate that it is planned.
But in the meantime, is it really necessary to build the packages 100/111 times?
Could you please not do that? I realize that sometimes dependency issues are
transient. I sometimes beat packages with a stick until they build as well, but
more than 100 builds in less than two weeks feels a little far fetched.
Please, make the automation stop and inspect the problem by a human after a
reasonable amount of trials (I'd say 3, possibly 12, but not 100+).
Alternatively at least slow down the firing rate with time. After two weeks of
failures it might make sense to give it a try every other day, but not every
it seems that both fakeroot and fakechroot fail to build in Fedora
rawhide (at least partially) because _STAT_VER is no longer declared
in the current glibc (or rather, its headers):
The bugzillas are filed against their respective components but
I wonder if we have any guidance from the glibc point of view about
how these components should proceed. Or is the loss of _STAT_VER an
omission and will it come back?
Product Owner, Platform Security Readiness, Red Hat