You are not logged in.
Yesterday, I ran pacman system update which included, among other things, libidn 1.34-2.0 -> 1.35-1.0 .
This immediately broke rhythmbox, which was unable to open:
rhythmbox: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory
Offline
Have you tried building the aur package yet?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Hello again, Levi.
I'm afraid I don't follow you. In general, I just run "pacman -Syu" and things work.
Has rhythmbox been kicked out of the main repo's into AUR?
Offline
No, the package I linked is one based on its git repo, rather than a named released source tarball. Those AUR packages exist in case someone wants something newer than the repo version, but in your case it might work around the versioning problem you have. There's still a bug on the repo, but it might get you working while others work on a fix. I myself have a few git-based projects cloned for a few things that have external dependencies that have a habit of breaking (I'm mainly looking at you, youtube), so that I can get a working version in the interim while a proper release is inbound. In this case though, it's not an external dependency, it's a dependency on an old version of a library, but building your own version from the git source should work around that.
Once this issue does get resolved, you can get back on the official release channel by installing rhythmbox from the repos again.
Perhaps also rhythmbox should declare a versioned dependency on libidn (it doesn't, I checked). That would allow this kind of dropout to be noticed before things hit the release channel.
Edit: libidn, not libicu. That's the other defect raised in the past week here, d'oh!
Last edited by levi (2018-10-28 00:48:10)
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Wow. Thank you for the explanation.
Offline
rhythmbox isn't the only package that is missing libidn.so.11 - lynx and elinks are also broken (same error). On my system, I have extracted libidn.so.11 from /var/cache/pacman/pkg/libidn-1.33-2-i686.pkg.tar.xz (i.e. the old version still in cache) and manually copied it to /usr/lib. Of course, this is only a stop-gap workaround and I will remove that file as soon as the other packages have been updated.
Offline
lynx is ok in testing (linked against libidn.so.12), but I cannot move it.
elinks and rhythmbox are not rebuild yet, so I priorized them.
Offline
lynx and elinks are working in stable. rhythmbox doesn't build currently upstream.
Offline
So should I monitor and wait until pacman shows an update is available?
Offline
lynx and elinks are working in stable. rhythmbox doesn't build currently upstream.
What does upstream mean in this context? The testing or staging repos, or x64 or something else?
rogerthat: I suspect you might be in for a longish wait if you're waiting for a new build. But if andreas can't build it it might also suggest you're likely to have trouble building the git aur on your machine, I guess.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
upstream means original software breaks. so the -git version might have been fixed already.
Offline
vlc also will no longer run on my machine after recent system update, giving libidn error
[tim@oldlaptop ~]$ vlc
vlc: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory
Offline
We should regress here and see what packages are using libidn. The list at https://packages.archlinux32.org/core/i686/libidn/
shows me that many of those packages are on the build-list. So I reckon the current problem is the speed the buildmaster
is handling and rebuilding packages.
Offline
abaumann: not only the speed of the buildmaster is lacking - some packages are blocked due to only-fixed-in-trunk-or-staging upstream packages (e.g. libxml2 blocks vlc)
Offline
Yeah. This is unfortunate. Then we have to patch downstream only to have it break later on when it's fixed upstream.
Offline
Earlier, Levi said:
> Perhaps also rhythmbox should declare a versioned dependency on libidn (it doesn't, I checked).
Given the new discoveries, is that still considered a bug? And would I need to report that to archlinux upstream, or who?
Offline
well, versioned dependencies is really optional candy - as far as upstream archlinux is involved.
And I'm afraid, we lack the manpower to add versioned dependencies to everything
Offline
upstream(rhythmbox)=https://bugs.archlinux.org/task/60620?p … =rhythmbox
Offline
I haven't seen any changes on the repos regarding rhythmbox or other libidn dependencies. Is there any news?
Is this problem already reported upstream in arch?
Offline
The link above is a report in upstream arch 64. It includes hopeful instructions on how to build it, but it's a bit hacky, so unlikely to be built automatically like that, and especially not if it's not been tested on our configurations. We're a little short of manpower to test it, and I personally have no interest in rhythmbox.
There's discussion above on rolling back libidn to version 11, and anything else using version 12 of it, but it seems that's not the only problem in the build dependencies. It's going to take longer than a week and a bit to sort this out, I reckon.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Thanks for the update. Running rhythmbox is nearly my entire use case for this old machine. I'm having pacman ignore libidn for now. I'm just not sure how I will know it's safe to reenable?
Last edited by rogerthat (2018-11-08 16:52:07)
Offline