Bug 1830380
Summary: | pipewire jack/pulseaudio replacements have issues with library file layout and automatic library provides | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | pipewire | Assignee: | Wim Taymans <wtaymans> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 33 | CC: | brunovern.a, goeran, jmaibaum, mcatanza, robatino, wtaymans |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | openqa | ||
Fixed In Version: | pipewire-0.3.19-2.fc33 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-01-12 01:32:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Adam Williamson
2020-05-01 19:25:37 UTC
Oh, forgot to note, I think this may be breaking KDE too as the KDE live isn't reaching a desktop either, but I haven't yet booted that locally to confirm it's the same problem. Proposing as an F33 Beta blocker, obviously failing to load GNOME is a blocker, criterion "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." - https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior OK, so looking at the package build, it seems like the idea is that the underlying packages pipewire-libpulse and pipewire-libjack ship the library files in the subdirectory, and then there are 'pipewire-jack-audio-connection-kit' and 'pipewire-pulseaudio' packages that are intended as replacements for jack-audio-connection-kit and pulseaudio-libs{-glib2} respectively, and which ship *symlinks* to those files in %{_libdir}. But because the underlying library packages wind up with Provides: for the libraries (even though they aren't shipping them in the library path), this system is breaking down a bit, dependencies are pulling in the underlying packages but not the ones with the symlinks in %{_libdir}. I'm not sure it's actually allowed to ship libraries as symlinks like this, or if it works, but if it is, the package at least needs to munge the provides so the pipewire-jack-audio-connection-kit and pipewire-pulseaudio subpackages have the library provides rather than pipewire-libjack and pipewire-libpulse. I've done a -2 build which suppresses the automatic library provides/requires for everything under %{_libdir}/pipewire-%{apiversion} . That should get Rawhide working again at least as it'll mean no pipewire package provides the library dependencies any more, and Rawhide installs should get the original pulseaudio-libs-glib2 package instead and things should work. I was not able to get the automatic library provides to appear in the pipewire-jack-audio-connection-kit and pipewire-pulseaudio packages instead, yet. Note they do not appear in these packages even *without* the exclusions I added, so I didn't make anything worse. I'm assuming the dependency generator either ignores symlinks, or follows them and applies the Provides to the package containing the real file; either way, it's not adding the Provides to the packages that have the symlinks in %{_libdir}. I'm not sure how to fix this, again, I'm not sure if this layout is actually allowed/workable/a good idea. Now it somewhat breaks the original idea (libjackserver.so.0()(64bit) and libjacknet.so.0()(64bit) are no longer provided and so the JACK examples/devel don't want to install anymore) What I want to achieve is this: 1) pipewire-libpulse * installs compatible replacement libraries in separate directory, not in library path * doesn't Provides: any of the libpulse.so * has script to put compat libraries in library path in order to run them with new libraries. The idea is to have a complete regular pulseaudio install and have all apps use regular pulseaudio. Only with the script can you try out the new stuff. In no way are the PipeWire libraries supposed to interfere with existing PulseAudio or install. Your fix to the .spec achieves this. 2) pipewire-pulseaudio * brings to compat libraries into the library path * provides libpulse.so etc * all pulseaudio apps run on PipeWire This package is in no way ready for general use. It should be completely opt-in, disabled by default and should in no way ever be added to the default install. The same setup for libjack, except that the JACK replacement will generally work ok. With the removal of the Provides: the second option to bring the libraries in the search path with symlinks doesn't work anymore. Maybe what can be done is: - leave the removal of Provides: in the libpulse/libjack package. - don't use symlinks but put a copy of the same libs in the library path, this should then add them back to Provides for the pipewire-pulseaudio and pipewire-jack-audio-connection-kit - Make sure pipewire-jack-audio-connection-kit and pipewire-pulseaudio are never added to the default install, they should only ever be installed manually. Not sure how to do the last bit or if it even can be done.. Are there other ideas? "Now it somewhat breaks the original idea (libjackserver.so.0()(64bit) and libjacknet.so.0()(64bit) are no longer provided and so the JACK examples/devel don't want to install anymore)" They should never have been provided by the pipewire-libjack package at all, because it doesn't provide them anywhere anything else can rely on finding them. It literally contains the files, but they're in a directory that is not in the loader path. So any external app that is built against those libraries is not going to find them when it tries to run, if only pipewire-libjack is installed. They should have been provided by pipewire-jack-audio-connection-kit, since that's the package which included the symlinks in %_libdir. But they never were provided by this package, neither before nor after my change. Your 'copy' idea should work, at the cost of needlessly having two copies of the files, I guess. I don't have any great ideas off the top of my head for point #3, really. Well, for Pulseaudio at least, we could have the main pulseaudio package explicitly Recommends: or Suggests: its 'regular' library packages, I think dnf uses soft dependencies to break ties for provides like this, so that would help. But for jack since the daemon and libraries are in the same package, we can't really do that... (In reply to Adam Williamson from comment #5) > They should never have been provided by the pipewire-libjack package at all, > because it doesn't provide them anywhere anything else can rely on finding > them. It literally contains the files, but they're in a directory that is > not in the loader path. So any external app that is built against those > libraries is not going to find them when it tries to run, if only > pipewire-libjack is installed. I agree. I used to have these libraries with a different name but that was also awkward because the library path trick doesn't work unless I add symlinks with the proper library names again. Maybe that's not a bad idea after all and then we can remove the __provides_exclude_from lines. > > Your 'copy' idea should work, at the cost of needlessly having two copies of > the files, I guess. In fact, it does not make much sense to have both packages installed at the same time. It's either installed in the private directory with script or in the library path. > > I don't have any great ideas off the top of my head for point #3, really. > Well, for Pulseaudio at least, we could have the main pulseaudio package > explicitly Recommends: or Suggests: its 'regular' library packages, I think > dnf uses soft dependencies to break ties for provides like this, so that > would help. But for jack since the daemon and libraries are in the same > package, we can't really do that... Splitting jack-audio-connection-kit into a jack-audio-connection-kit-libs can also be done to resolve this. As we've at least made this stop breaking composes for now, adjusting the summary and dropping the release blocker proposal. *** Bug 1830447 has been marked as a duplicate of this bug. *** This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33. As of pipewire-0.3.18, the libjack*.so provides from pipewire-libjack/pipewire-jack-audio-connection-kit are missing. Currently (testing on Fedora Silverblue 33, where manually creating symlinks is not possible due to read-only /usr), trying to install any tool depending on JACK fails with output similar to: $ rpm-ostree install qjackctl Checking out tree aa6dd6b... done Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-modular updates-testing fedora-modular updates-testing-modular updates-archive rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2020-08-25T19:10:34Z rpm-md repo 'updates' (cached); generated: 2021-01-02T00:56:56Z rpm-md repo 'fedora' (cached); generated: 2020-10-19T23:27:19Z rpm-md repo 'updates-modular' (cached); generated: 2020-12-30T01:36:23Z rpm-md repo 'updates-testing' (cached); generated: 2021-01-02T01:41:41Z rpm-md repo 'fedora-modular' (cached); generated: 2020-10-19T23:04:43Z rpm-md repo 'updates-testing-modular' (cached); generated: 2020-12-30T01:59:29Z rpm-md repo 'updates-archive' (cached); generated: 2021-01-02T01:35:05Z Importing rpm-md... done Resolving dependencies... done error: Could not depsolve transaction; 1 problem detected: Problem: conflicting requests - package qjackctl-0.6.3-2.fc33.x86_64 requires libjack.so.0()(64bit), but none of the providers can be installed - package qjackctl-0.6.2-2.fc33.x86_64 requires libjack.so.0()(64bit), but none of the providers can be installed - package pipewire-jack-audio-connection-kit-0.3.18-1.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.18-1.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 requires pipewire-libjack(x86-32) = 0.3.13-4.fc33, but none of the providers can be installed - package pipewire-libjack-0.3.13-4.fc33.i686 requires pipewire-libs(x86-32) = 0.3.13-4.fc33, but none of the providers can be installed - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 requires pipewire-libjack(x86-64) = 0.3.13-4.fc33, but none of the providers can be installed - package pipewire-jack-audio-connection-kit-0.3.14-1.fc33.x86_64 requires pipewire-libjack(x86-64) = 0.3.14-1.fc33, but none of the providers can be installed - package pipewire-jack-audio-connection-kit-0.3.14-2.fc33.x86_64 requires pipewire-libjack(x86-64) = 0.3.14-2.fc33, but none of the providers can be installed - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 requires pipewire-libjack(x86-64) = 0.3.15-2.fc33, but none of the providers can be installed - pipewire-libs-0.3.13-4.fc33.i686 has inferior architecture - package pipewire-libjack-0.3.13-4.fc33.x86_64 requires pipewire-libs(x86-64) = 0.3.13-4.fc33, but none of the providers can be installed - package pipewire-libjack-0.3.14-1.fc33.x86_64 requires pipewire-libs(x86-64) = 0.3.14-1.fc33, but none of the providers can be installed - package pipewire-libjack-0.3.14-2.fc33.x86_64 requires pipewire-libs(x86-64) = 0.3.14-2.fc33, but none of the providers can be installed - package pipewire-libjack-0.3.15-2.fc33.x86_64 requires pipewire-libs(x86-64) = 0.3.15-2.fc33, but none of the providers can be installed - cannot install both pipewire-libs-0.3.13-4.fc33.x86_64 and pipewire-libs-0.3.18-1.fc33.x86_64 - cannot install both pipewire-libs-0.3.14-1.fc33.x86_64 and pipewire-libs-0.3.18-1.fc33.x86_64 - cannot install both pipewire-libs-0.3.14-2.fc33.x86_64 and pipewire-libs-0.3.18-1.fc33.x86_64 - cannot install both pipewire-libs-0.3.15-2.fc33.x86_64 and pipewire-libs-0.3.18-1.fc33.x86_64 $ cat /etc/ld.so.conf.d/pipewire-jack-x86_64.conf /usr/lib64/pipewire-0.3/jack/ $ sudo ldconfig -p | grep libjack libjackserver.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjackserver.so.0 libjackserver.so (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjackserver.so libjacknet.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjacknet.so.0 libjacknet.so (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjacknet.so libjack.so.0 (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjack.so.0 libjack.so (libc6,x86-64) => /usr/lib64/pipewire-0.3/jack/libjack.so On the bright side, after fighting the long dependency chain of pulseaudio (documented here: https://paste.sr.ht/~jmaibaum/8f9cc331078b14681077308e1b56ad34bb068aeb), I can report that the pulseaudio replacement looks, and works great so far! It's just the JACK replacement libraries which don't yet work as expected. FEDORA-2021-219c1b512a has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-219c1b512a FEDORA-2021-219c1b512a has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-219c1b512a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-219c1b512a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-219c1b512a has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |