Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== 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
compatible implementation
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
PipeWire.
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.
* Flexibility/Integration
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.
* Performance
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.
* Security
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.
* Maintainability
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
and use-cases.
== 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
anymore.
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
switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- 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
(bluejeans.com/111).
- 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
PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes
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://pipewire.org](PipeWire website)
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md...
guide)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md]...
to use/test)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
1 week, 3 days
Fedora 34 Change proposal: Remove make from BuildRoot (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
===== Phase 1: Analysis =====
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build. Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.
[1] https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_...
===== Phase 2: Package Updates =====
Once we have the list of packages that need to be updated, we will
proceed with adding BuildRequires: make to all spec files that require
it. This new BuildRequires will be added to the line after the last
BuildRequires in the spec file. The release number for packages will
'''*not*''' be incremented for this change.
The spec file updates will be automated and changes will be pushed
directly to dist-git once they are ready.
===== Phase 3: Update Buildroot =====
Once package spec files have been updated, then we can proceed with
removing make from the BuildRoot. This will be done by removing make
from the build group in Koji and by removing make from the
buildsys-build group in comps (fedora-comps). In order to avoid
issues with Koschei, this change will need to be made as close as
possible to the start of the mass rebuild. If possible, we will try
to first remove make from the mass rebuild side-tag and then remove it
from rawhide after the rebuild completes.
===== Phase 4: Monitor Failures =====
Once all the changes are in place, we will continue to monitor koji
builds to see if there are any failures related to this change. We
expect that the analysis done in Phase 1 would give us the complete
list of packages that need to be updated, but it is always possible
that something will be missed.
== Feedback ==
* Removing make from the Buildroot without rebuilding the packages
first has the potential to cause mass failures in Koschei. This is
because Koschei builds from the latest SRPM and not from dist-git. We
can minimize this problem by removing make from the buildroot as close
as possible to the mass rebuild. The proposal has been updated now to
account for this issue.
== Benefit to Fedora ==
Based on my research[1], Fedora Rawhide has 22,309 packages, and there
are approximately 10,378 packages that either use make explicitly or
fail to build when make is removed form the buildroot. This means
that there are around 11,931 packages that don't need make. Removing
make from the BuildRoot will reduce the network traffic, download
times, and disk usage for these builds in Koji and also for users
doing builds with mock.
Removing make (and its dependencies) will:
* Reduce the BuildRoot download size by: 7.3 MB [2]:
** make: 539k
** gc: 104k
** guile22: 6.6M
** libtool-ltdl: 36k
* Reduce the BuildRoot install size by; 46 MB [2]:
** make: 1.6M
** gc: 229k
** guile22: 44M
** libtool-ltdl: 71k
[1] https://github.com/tstellar/fedora-change-make-buildroot
[2] Package sizes are from the x86_64 packages.
== Scope ==
* '''Proposal owners:''' Tom Stellard
* '''Package Maintainers:''' Fedora package maintainers should report
bugs if they think there is a problem caused by this change, but
otherwise there will be no action required by them.
* '''Proven Packager:''' The proposal owner will need to either apply
for provenpackager status or get the help of someone with
provenpackager status in order to make the spec file changes that are
required.
* '''Release engineering:''' [https://pagure.io/releng/issue/9829
#9829] (a check of an impact with Release Engineering is needed)
* '''Policies and guidelines:''' The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make.
* '''Trademark approval:''' N/A (not needed for this Change)
* '''Alignment with Objectives:''' This aligns with the Fedora
Minimization [https://pagure.io/minimization/issue/12 objective].
== Upgrade/compatibility impact ==
This should not impact upgrades.
== How To Test ==
This change can be tested by rebuilding affected packages. The goal
is to complete this before the mass rebuild to ensure maximum testing
coverage.
== User Experience ==
Fedora users will not notice any difference with this change. This
will only impact Fedora package maintainers.
== Dependencies ==
gcc < 11 will fail if the -flto=auto option is used when make is not
installed. Phase 3 cannot be completed until gcc 11 lands in rawhide,
but Phase 1 and Phase 2 are not blocked by this.
== Contingency Plan ==
* '''Contingency mechanism:''' If we discover critical issues during
phase 4, then Fedora Release Engineering will need to re-add make into
the buildroot.
* '''Contingency deadline:''' 2021-02-23 (F34 Beta Freeze)
* '''Blocks release?''' No
* '''Blocks product?''' No
== Documentation ==
The packager guidelines will need to be updated to mention that
BuildRequires: make is now required for all packages that need make.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 weeks, 5 days
our containers with alias vim=vi
by clime
Hello,
could Fedora and CentOS containers for docker and podman come with
`alias vim=vi` in ~/.bashrc?
I would very much welcome it as I am used to type vim everywhere but
if vi starts instead I am happy too. I know that the solution is to
create a customized container but often I want to try something on
vanilla containers from the whole range.
Didn't want to write about this first but maybe there are more people
with the same problem.
clime
3 weeks
Server Side Public License (SSPL) v1
by Tom Callaway
After review, Fedora has determined that the Server Side Public License
v1 (SSPL) is not a Free Software License.
It is the belief of Fedora that the SSPL is intentionally crafted to be
aggressively discriminatory towards a specific class of users.
Additionally, it seems clear that the intent of the license author is to
cause Fear, Uncertainty, and Doubt towards commercial users of software
under that license. To consider the SSPL to be "Free" or "Open Source"
causes that shadow to be cast across all other licenses in the FOSS
ecosystem, even though none of them carry that risk.
It is also worth nothing that while there is a draft for a "v2" of the SSPL:
A) It is not final.
B) It is not in use anywhere at this time (as far as we know).
C) The intent of the v2 draft text is not changed from the v1 license
currently in use.
We have updated our "Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
Thanks,
Tom Callaway
Fedora Legal
1 month, 1 week
Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
1 month, 2 weeks
Mass spec file change: Adding BuildRequires: make
by Tom Stellard
Hi,
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages
on your own, please do so before Dec 14, which is when I will begin
doing the mass update.
I will be doing the updates in batches, so that if there is a mistake
the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4: Next 1000.
Jan 5: Next 1000.
Jan 6: Next 1000.
Jan 7: Next 1000.
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass
rebuild (Jan 20).
Thanks,
Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
1 month, 3 weeks
