Below is this week's CPE weekly for week ending 2020-11-22 for both
Fedora & CentOS, and if you want to visit the hackmd link
https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view you can then use the
header bar on your left to skip to Fedora or CentOS updates that
## General Project Updates
Final project submission date for consideration in Q1 is Friday 27th
November. If you have an initiative that may take weeks/months and
multiple people to work on and want to request it to CPE, please
follow the steps outlined in our initiatives repo and create your
issue before 27th November https://pagure.io/cpe/initiatives-proposal
Our updated initative timetable can be viewed here for 2021
Below are the projects the CPE team are currently working on for the
months of October, November & December:
* CentOS Stream Phase 4 - Build system services
* Noggin Phase 4 - Data Migration of Fedora & CentOS Accounts, Community testing
* OSBS for aarch64 - this will begin in November
* Fedora Messaging Schemas - this work is continuing from Q3 and is
being worked on part-time
New GitLab topic sent to devel-announce(a)lists.fedoraproject.org &
centos-devel(a)centos.org on Message Bus is out. See email in hackmd
## Project Updates
*The below updates are pulled directly from our CPE team call we have
### Staging Environment
* Completed - any issues you find please report them in fedora infra
* Testing team owned apps in staging with Noggin
* We will be requesting community member testing before December so
keep an eye out for an announcement!
* The teams kanban board where they track their work can be found here
* And we have a project tracker available to be viewed here
### OSBS for aarch64
* Basic OKD 3.11 working on aarm64 with F31
* Working on repeating that install with F33
* Next step will be to
### Fedora Messaging Schemas
* This project is worked on on a part time basis as we are
prioritizing completing Noggin first before fully committing to its
* There is a list of applications that require messaging schemas can
be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit
* There is a readme which contains documentation on messaging schemas,
a cookie-cutter template to create the schema and a definition of Done
for writing a schemas
* The board they are working from can be viewed here
## CentOS Updates
* CentOS 6 is EOL 30th November
* CFP for FOSDEM Dojo - https://wiki.centos.org/Events/Dojo/FOSDEM2021
* Updated CentOS CI Openshift staging cluster to latest 4.6.4, Waiting
for stable release in the 4.6 branch before rolling out to production.
* CentOS 7.9.2009 is released! (for x86_64, i386, ppc64, ppc64le,
armhfp and aarch64 architectures)
* Lot of work done for Noggin/AAA
### CentOS Stream
* Use centos-stream-release package to convert from CentOS 6 to CentOS
Stream before 30th November
* Working on integrating ODCS in Stream
* Curating out t_functional suite
* Refining our testing for finding issues at distro-level
## Team Info
### CPE Product Owner Office Hours
IRC office hours are now once per month.Below are the logs from the
most recent meetings and dates for the next ones.
* Next Meeting: 2020-12-17 @ 1300 UTC on #fedora-meeting-1
* Next Meeting: 2020-12-15 @ 1500 UTC on #centos-meeting
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.
See our wiki page here for more
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great week!
Community Platform Engineering Team
Red Hat EMEA
== 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
I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for
example), but I'm having trouble getting all of the build dependencies
right. I ran dnf to download the SRPMS with the --resolve option, but I'm
still missing dependencies when I submit the builds to copr.
My current workflow is to download an RPM from Fedora 33, then submit it to
copr to build on the EPEL8 image in my personal COPR projects, waiting for
any library errors, then download those and build, repeat as needed.
That workflow is tedious and I feel like there must be a better way, but I
don't know what that is. How can I recursively find all of the builddeps
Ideally, I would like some type of (semi-)automated way to track packages
on Fedora and automatically build them on EL8, but I'm at a loss for how to
I hope you enjoyed the F33 release party this weekend! Getting back to
the GitLab topic mail threads, this weeks topic from the GitLab AMA
session on September 10th is on Message Bus. As always, here are some
links to the resources I have been pulling content from as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
* AMA Blog post
* Here is this email in hackmd if you wish to view it there:
## Topic: Message Bus
- Question: Fedora uses a message bus to integrate different parts of
its infrastructure. How should we onboard GitLab into this message
- Answer: Currently we would need to have a service that proxies
GitLab’s events to fedora-messaging something similar to
There were some concerns raised about the order of events sent by
GitLab’s webhooks, these will need to be looked after during a Proof
of Concept stage.
- Question: How would git push over http work with GitLab? (assuming
gitlab does not have Fedora's password since they are stored in FAS)
- Answer: GitLab has a good number of authentication options and
integrations where the "best" solution usually depends on a team's
specific needs and use case. As such, the best way to know and meet
Fedora's needs and use cases is to have a conversation and discuss the
options with GitLab. How does git push over HTTP work with FAS right
now, and what git push (over HTTP) auth requirements/flow would you
like to have for your projects in GitLab?
These are the only two questions and answers I could gather relating
to message bus from the AMA question sheet, however I know there was a
lot of discussion regarding this topic during the AMA session itself,
so if you would like to resume/kick off that conversation again,
please feel free to use this email to discuss.
A personal note and for full transparency: the weeks seem to be
passing in the blink of an eye lately, I assume it's because I'm
busy(?) but it might be just the weird 2020 vibe the world is on
nowadays. I really don't know. Whatever the reason, there has been no
further discussion with GitLab since early October-ish, but we will be
returning to the conversation of how this migration could be
technically possible soon, so sincerely thank you all again for
engaging with us/me here as I found reading the discussion on
permission and access much easier to follow and have been taking notes
on your expectations to use that feedback in conversations with GitLab
when we pick the discussion back up.
I hope you all had a good weekend and will talk to you all next week
when the topic of Namespace & Issue Tracking is sent!
Community Platform Engineering Team
Red Hat EMEA
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://email@example.com...