|
Bugzilla – Full Text Bug Listing |
| Summary: | Missing system libjack.so.0 with the recent update of pipewire | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Jimis Hol <hol.jimis> |
| Component: | Sound | Assignee: | Antonio Larrosa <alarrosa> |
| Status: | NEW --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dimstar, dleuenberger, martin.jakl, mrmazda, samcon, stefan.bruens, suse.junky, tiwai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: | https://bugzilla.opensuse.org/show_bug.cgi?id=1188870 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Jimis Hol
2023-06-01 15:01:58 UTC
Tossed to pipewire package maintainer for now. I'm afraid that certain people still prefer the genuine JACK. That's another side of the whole pipewire-jack vs jack story, in addition to the package dependency of libjack. *** Bug 1211992 has been marked as a duplicate of this bug. *** (In reply to Takashi Iwai from comment #2) > *** Bug 1211992 has been marked as a duplicate of this bug. *** Just for the record: My "workaround" (mentioned in Bug 1211992) was not to install libjack0. I created a symlink /usr/lib64/libjack.so.0 (pointing to /usr/lib64/pipewire-0.3/jack/libjack.so.0). I guess the path of /usr/lib*/pipewire/libjack.so.0 is intentional, so that the genuine libjack.so.0 can be co-installed on the system. But, somehow we messed up to drag only pipewire-libjack as if it were a system library. (In reply to Takashi Iwai from comment #4) > I guess the path of /usr/lib*/pipewire/libjack.so.0 is intentional, so that > the genuine libjack.so.0 can be co-installed on the system. But, somehow we > messed up to drag only pipewire-libjack as if it were a system library. The main issue is the advertising of libjack.so.0 into the rpm metadata, but then being hidden away into a private location (/usr/lib*/pipewire/...) anything that lins libjack.so.0 would consider this pipewire flavor as 'good enough to satisfy the deps' As for parallel installation: that is avoided by rpm tags: Problem: the to be installed pipewire-libjack-0_3-0.3.71-3.1.x86_64 conflicts with 'libjack0' provided by the installed libjack0-1.9.22-2.1.x86_64 Solution 1: deinstallation of libjack0-1.9.22-2.1.x86_64 Solution 2: do not install pipewire-libjack-0_3-0.3.71-3.1.x86_64 > zypper info --conflicts pipewire-libjack-0_3 Information for package pipewire-libjack-0_3: --------------------------------------------- Repository : Main Repository (OSS) Name : pipewire-libjack-0_3 Version : 0.3.71-3.1 Arch : x86_64 Vendor : openSUSE … Conflicts : [3] libjack0 libjacknet0 libjackserver0 So we should filter the provides of libjack0 from pipewire-libjack package? (In reply to Takashi Iwai from comment #6) > So we should filter the provides of libjack0 from pipewire-libjack package? 'It depends' - if pipewire's libjack.so.0 is meant to be a compatible replacement, then the question would be why is it in a private directory. The way it looks now, filtering the provides for the libs sounds like the right thing (and then removing the conflict, as they seem not to be real) the provides currently are: > zypper info --provides pipewire-libjack-0_3 Loading repository data... Reading installed packages... Information for package pipewire-libjack-0_3: --------------------------------------------- Repository : Main Repository (OSS) Name : pipewire-libjack-0_3 Version : 0.3.71-3.1 Provides : [5] libjack.so.0()(64bit) libjackserver.so.0()(64bit) libjacknet.so.0()(64bit) pipewire-libjack-0_3 = 0.3.71-3.1 pipewire-libjack-0_3(x86-64) = 0.3.71-3.1 for reference: the error appeared due to https://build.opensuse.org/request/show/1089545 before that, the /usr/lib*/pipewire private directory was configured as a public one for ldconfig - which made consumers find the library. /etc/ld.so.conf.d/pipewire-jack-%{_arch}.conf has moved from pipewire-libjack-0_3 (providing the libs) to pipewire-jack Jimis, can you try the following to see if that works for you too? 1) Remove the symlinks you created in /usr/lib64 (would that be only libjack0? or also some other jack library?) 2) Install the pipewire-jack package That should be enough to make pipewire replace jack . Please confirm if that works for you. I'll try to make the packaging more robust so wireplumber-audio conflicts with jack (just as it conflicts with pulseaudio) so pipewire-jack is used instead if wireplumber-audio is installed. (In reply to Antonio Larrosa from comment #9) > 1) Remove the symlinks you created in /usr/lib64 (would that be only > libjack0? or also some other jack library?) I did rm /usr/lib64/libjack.so.0 Which was the only symlink (pointing to /usr/lib64/pipewire-0.3/jack/libjack.so.0) which I had created to make digikam starting again. > 2) Install the pipewire-jack package I did zypper in -f pipewire-libjack-0_3 > That should be enough to make pipewire replace jack . Please confirm if that > works for you. I'll try to make the packaging more robust so > wireplumber-audio conflicts with jack (just as it conflicts with pulseaudio) > so pipewire-jack is used instead if wireplumber-audio is installed. Now digikam fails again with "digikam: error while loading shared libraries: libjack.so.0: cannot open shared object file: No such file or directory" I had commented in dup bug 1911992: I found that using pipewire to the exclusion of pulseaudio, without pipewire-libjack-0_3 installed, KDE3 system sounds cannot be made to work in 15.5. I have yet to determine if this applies also in TW. (In reply to Bit Juggler from comment #10) > > I did > > rm /usr/lib64/libjack.so.0 > > Which was the only symlink (pointing to > /usr/lib64/pipewire-0.3/jack/libjack.so.0) which I had created to make > digikam starting again. Perfect, > > 2) Install the pipewire-jack package > > I did > > zypper in -f pipewire-libjack-0_3 > Please try with: zypper in pipewire-jack (In reply to Felix Miata from comment #11) > I had commented in dup bug 1911992: > I found that using pipewire to the exclusion of pulseaudio, without > pipewire-libjack-0_3 installed, KDE3 system sounds cannot be made to work in > 15.5. I have yet to determine if this applies also in TW. Are you using the pipewire package from multimedia:libs or from 15.5? If you're using the package from 15.5 please file a separate bug describing your issue and assign it to me directly as this bug (and 1211992) are related to a change that was recently made in the package but that's not included in Leap. (In reply to Antonio Larrosa from comment #12) > > > 2) Install the pipewire-jack package > > > > I did > > > > zypper in -f pipewire-libjack-0_3 > > > > Please try with: > > zypper in pipewire-jack I tried and it works i.e. digikam now starts again without problems. Just in case it helps here a list of all pipewire packages installed in my system now: # zypper se -si pipe* Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+--------------------------+---------+--------------------+--------+---------------------------- i+ | pipewire | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i+ | pipewire-alsa | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i+ | pipewire-aptx | package | 0.3.71-1699.1.pm.1 | x86_64 | Packman openSUSE Tumbleweed i+ | pipewire-doc | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i+ | pipewire-jack | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i | pipewire-lang | package | 0.3.71-3.1 | noarch | openSUSE Tumbleweed Oss i+ | pipewire-libjack-0_3 | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i | pipewire-modules-0_3 | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i+ | pipewire-pulseaudio | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i | pipewire-spa-plugins-0_2 | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i | pipewire-spa-tools | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss i | pipewire-tools | package | 0.3.71-3.1 | x86_64 | openSUSE Tumbleweed Oss It would be nice if somebody could briefly explain what has gone wrong. Why is it necessary to install pipewire-jack? Why does pipewire-libjack not pull in pipewire-jack when the system will get messed up with only pipewire-libjack installed? Thank you. (In reply to Antonio Larrosa from comment #9) > Jimis, can you try the following to see if that works for you too? > > 1) Remove the symlinks you created in /usr/lib64 (would that be only > libjack0? or also some other jack library?) > 2) Install the pipewire-jack package I didn't created manually an symlink for libjack0. So, i just tried step 2. Sorry, i hesitate to install pipewire-jack It wants deinstallation of libjack0-1.9.22-2.1.x86_64 deinstallation of pulseaudio-16.1-3.1.x86_64 deinstallation of pulseaudio-gdm-hooks-16.1-3.1.x86_64 deinstallation of pulseaudio-lang-16.1-3.1.noarch deinstallation of pulseaudio-module-bluetooth-16.1-3.1.x86_64 deinstallation of pulseaudio-module-gsettings-16.1-3.1.x86_64 deinstallation of pulseaudio-module-x11-16.1-3.1.x86_64 deinstallation of pulseaudio-module-zeroconf-16.1-3.1.x86_64 Having a working pulseaudio, seems too much for me to risk on my sound system. I can recall that i tried to move from pulseaudio to pipewire but could not make rosegarden to play midi sounds through "timidity -iA" with it. I always had hard time to make rosegrden to play midi files, so sorry, I do not want to risk that functionality again. (In reply to Jimis Hol from comment #16) > (In reply to Antonio Larrosa from comment #9) > > I didn't created manually an symlink for libjack0. So, i just tried step 2. > Sorry, i hesitate to install pipewire-jack > It wants > deinstallation of libjack0-1.9.22-2.1.x86_64 > deinstallation of pulseaudio-16.1-3.1.x86_64 > deinstallation of pulseaudio-gdm-hooks-16.1-3.1.x86_64 > deinstallation of pulseaudio-lang-16.1-3.1.noarch > deinstallation of pulseaudio-module-bluetooth-16.1-3.1.x86_64 > deinstallation of pulseaudio-module-gsettings-16.1-3.1.x86_64 > deinstallation of pulseaudio-module-x11-16.1-3.1.x86_64 > deinstallation of pulseaudio-module-zeroconf-16.1-3.1.x86_64 > > Having a working pulseaudio, seems too much for me to risk on my sound > system. I see. That's understandable. So I guess you don't have wireplumber-audio installed, right? Since that also would remove pulseaudio. A couple of days ago I started preparing a better fix for this after talking with the Pipewire developers but I got busy with something else and tomorrow I'll be at a conference, so I'll try to finish the fix and submit it next Monday/Tuesday. Sorry for the delay. Yes, wireplumber-audio is NOT installed. Though, wireplumber is installed automatically. Antonio Larrosa, thank you very much for your detailed information to me and your tries. Due to the above, I decided to migrate to pipewire at once. I uninstalled the libjack0. pipewire were already installed, so i added wireplumber-audio and pipewire-jack pipewire-libjack-0_3 was not enough, without pipewire-jack, for mpd to work. Of course, I set mpd.conf for pipewire, instead of pulseaudio. My midi works too. Minor problems, that deserve different issues, are: 1) output to pipewire wants more than 5 minutes to be established. If I want immediate sound, i have to restart mpd service. (systemctl --user restart mpd.service - Initially it is started through socket in user space). In later case, it takes about 5 seconds for pipewire output to be established. 2) webcamera and cheese is not working anymore. (I cannot tell for sure if pipewire is the cause). I get cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed actually, /dev/video0 stopped to exist. "systemctl --user status pipewire" is up and running, even if I did not enabled the service. Thank you all. (Correcting comment #19) > 2) webcamera and cheese is not working anymore. (I cannot tell for sure if > pipewire is the cause). I get > cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' > failed > actually, /dev/video0 stopped to exist. Moving to a new house, I connected my screen by hdmi only. I had to connect it by usb cable too, in order for the build in camera to work. Nothing to do with pipewire. Sorry, i should be more careful. It seems the problem is the following: The rpm package of apps linking to libjack.so.0 have a dependency on libjack.so.0()(64bit). That library is provided in the original jack library package (libjack0) and also in pipewire-libjack-0_3 . So zypper/rpm think any of them are good providers of the library. The problem is that in the pipewire package the library is installed to a non-standard directory, /usr/lib64/pipewire-0.3/jack/ (so it can be co-installed with the original jack libraries and only be used when the user uses pw-jack) and only when pipewire-jack is installed, it's used automatically. So one can get their system to a state in which libjack0 is not installed, pipewire-libjack-0_3 is installed making zypper/rpm think the libjack.so.0 library is in the system but apps requiring it fail to run because pipewire-jack is not installed so the library can't be found. I'll try to find a good solution to this The primary question is, as stated in comment 7, whether libjack.so.0 in pipewire-libjack* is considered to be used by other programs, or it's only for internal uses by pipewire-related programs. In the former case -- that is, the library is a proper replacement of the official libjack.so.0 -- it should be installed in /usr/lib64 instead. In the latter case, we need to add filtering as mentioned in comment 6 and 7. IIRC, the filter is to define %__provides_exclude or %__provides_exclude_from. (Hmm, I could find only Fedora's document: https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ ) But I haven't touched this for long time, so my information might be outdated. (In reply to Takashi Iwai from comment #22) > The primary question is, as stated in comment 7, whether libjack.so.0 in > pipewire-libjack* is considered to be used by other programs, or it's only > for internal uses by pipewire-related programs. At least with pipewire 1.0 (release 2023-11-26), pipewires libjack.so.0 should be considered a full replacement of the original libjack.so.0. Though, for some exotic cases users may still choose to run the original jack server instead of the pipewire implementation. In the end, all three of the following are valid installations: 1. Use pipewire as jack server. This should be the default, as most installation s (all with Wayland) already have pipewire installed, pipewire has better bluetooth audio support (more codecs) than pulseaudio, and provides also a good jack implementation. 2. Use the original jack server (optionally with pipewire used only for pipewire/pulseaudio clients). 3. Use the original jack server, and run pipewire as a jack client (i.e. working as a bridge between pipewire/pulseaudio and jack). The easiest is (2.), as libjack.so.0 is automatically found in /usr/lib[64]/. (1.) is already more complicated, as its implementation also affects (3.). For it to work, the library must be in the search path, and should be without any additional user intervention (i.e. installing pipewire-jack manually). This can use either update-alternatives, or by using a ld.so.conf.d snippet. Most notably, programs may refuse to start, silently, when linking libjack.so.0 fails. (3.) is the most complicated. This is a setup which may be used only occasionaly, even by the same users. When jack is running, jack clients (including pipewire) should use the original libjack.so.0 to connect to the jack server. In case a user wants to use pipewire as jack server, "pw-jack" can be used. I think the easiest would be to require (jack OR pipewire-jack) from the pipewire-libjack-0_3 package. On TW version 20240412, I was able to get MPD to run by installing libjack0 |