Hi, i was wondering what people generally do with this. It is not a huge problem; just like in another thread from mrbrklyn, when you get a package compiled with a wrong version of the library and get an error like:
mplayer: error while loading shared libraries: libcdio.so.18: cannot open shared object file: No such file or directory
artix is not a mainstream distribution, and it's repos probably don't get updated as much as the arch repos, which are still used as dependencies, therefore there is inevitable package breaking once in awhile. I don't mind having to do a little bit of manual version management; i wouldn't be in this forum if i wanted a system completely managed for me :P.
I was just wondering how people generally approach this. Notice a library file missing, downgrade the package, blacklist it in pacman.conf, and then wait a while to try it again? Is there a different, maybe more automated approach that people generally take?
Are you running Artix-testing or stable?
If you are on testing do you also have community-testing?
I don't know of an automated way to deal with this, I just mention it here that something broke and within 24hrs or less it is fixed.
Just don't expect too much explaining on how and when. It is like magic, you mention it, it gets fixed.
That's the artix way. It is also a mixed distribution, not because artix is slow in developing new pkgs, and the foundation is like quicksand. Arch does not warn artix on how things change, artix must always catch up to the changes and what they affect.
Ideally there should have been an unstable part running on arch testing, and testing running on stable arch. Maybe in reality that is how it is done.
I usually downgrade, and then use '--ignore' to not upgrade it, till Artix has updated the package.
I have the same error, but with mpv and libcdio. Only way I found to resolve it was downgrading mpv and libcdio.
Best regards.
@conky60 You don't have to downgrade 'libcdio'. The whole issue is that that package in Artix [stable] isn't up-to-date, w.r.t. Arch.
I am running Artix "testing" repos, and libcdio version in world-testing is the same as Arch "extra" (2.0.0-1). I downgraded to 0.94-2 from Artix "world".
Best regards.
I think I pulled the new version from testing. I am wrong about that?
The only two versions my search has revealed is 0.94-2 in Artix "world", and 2.0.0-1 in Artix "world-testing" and Arch "extra".
Best regards.
OK - I don't know how you ened up with a problem with that library. In my case, I had an updated version of lib264 and I let the library and updated mplayer from the arch testing which I downloaded from the web site and installed with pacman from the command line.
I use mplayer in my alarm clock - so it sucked when it was broken.
OK - I confirmed this on the last upgrade. For gods sake, why is a core app like mplayer have such problems :(
I reinesntalled the old version of mplayer that I had on the hard drive which came off of arch testing a few days back. Currently, mplayer is completely broken from the arch repos.
pacman -R /home/ruben/Downloads/mplayer-37998-2-x86_64.pkg.tar.xz
FWIW
https://archlinux.pkgs.org/rolling/archlinux-extra-x86_64/libcdio-2.0.0-1-x86_64.pkg.tar.xz.html
[flatbush ~]# locate libcdio.so
/usr/lib/libcdio.so
/usr/lib/libcdio.so.16
/usr/lib/libcdio.so.16.0.0
[flatbush ~]#
so the system is at least one step back on that lib
Doesn't 2.0.0.-1 have the rightr library?
Mpv (through smplayer) complains about not being able to find "libcdio.so.16". The only way I have been able to get mpv to work w/smplayer for me is to downgrade mpv to the previous release from Arch "community" (1:0.27.0-5), and downgrade "libcdio" to 0.94-2 from Artix "world".
I may be overlooking something....my head hurts. ???
Best regards.
weirdly, even if i install libcdio from extra insted of world. mpv complains about libcdio.so.18 when i have libcdio.so.16 and complains about libcdio.so.16 when i have libcdio.so.18.
stable
I have noted the exact same as well. ???
I have switched from mpv engine to mplayer engine in my smplayer....that works, except for a bit of a video glitch when switching to fullscreen. Once in fullscreen it's ok.
Best regards.
i wish i could add something constructive
I just ran an upgrade that included mplayer and it was again broken with libcdio.so.18 . I wish they would just fix it. They need a working mplayer forlibcdio.18 instead of cdio.16
pacman -Syu extra/libcdio-paranoia extra/libcdio
When you update, don't pacman -Syyuu because it will break, just re-issue the command above. Works for me (TM)
Thank you for this, it does indeed work in my situation with smplayer/mpv as well. Even though the Artix versions of these packages are the same as those in extra, there is obviously a difference....I wonder if it has to do with systemd?? ???
Best regards.
I don't have a list of packages that are actually systemd-dependent or have various levels of integration with it. If I understand it correctly, Artix started with the core packages stripped of systemd, used the rest of the packages from Arch extra, and as time goes by, more and more packages will be migrating to the actual Artix repos from the Arch extra. So there's systemd, there's the actual package migration process and there might be mirror sync lag (there was an x264 library issue a while ago). But it wouldn't surprise me one bit if I were to find out systemd needs media player access because it wants to sync the screensaver with the video frames per second (?~?!?!?)
I don't know about that, but, it seems strange to me that these packages have the exact same version numbers but only those from arch "extra" seem to work. I don't understand why. ???
Best regards.