You are not logged in.
When enabling staging update in pacman.conf
[staging]
Include = /etc/pacman.d/mirrorlist
Packages dependency seemed to be broken. Here's the error message:
:: Synchronizing package databases...
staging downloading...
core downloading...
extra downloading...
community downloading...
:: Starting full system upgrade...
resolving dependencies...
warning: cannot resolve "libicuuc.so=70-32", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=70-32", a dependency of "libphonenumber"
warning: cannot resolve "libicui18n.so=70-32", a dependency of "libphonenumber"
warning: cannot resolve "libicuuc.so=70-32", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=70-32", a dependency of "libphonenumber"
warning: cannot resolve "libicui18n.so=70-32", a dependency of "libphonenumber"
warning: cannot resolve "libicuuc.so=70-32", a dependency of "harfbuzz-icu"
:: The following packages cannot be upgraded due to unresolvable dependencies:
harfbuzz-icu libphonenumber
It seems that it is missing a critical package icu 70.1. Package icu 70.1 which is available in testing but updating from testing broke a critical package `shared-mime-info` which happened to be linked with stale icu69 libs.
Offline
I could push icu 70 to stable, but this could potentailly break a lot of software.
Well, let's do it. :-)
There is an icu69 package which makes software run that is still linked against old icu versions.
Offline
This day (4 dec) after a complete software update, SDDM is no longer available !!!!
The problem is icu-70.1 !
I get the error : error while loading share libraries : libicui18n.10.69
By chance i could reinstall icu69 !
And now it's ok for sddm ....
*****
@LEVI, moderator
yes, I apologize... there is a typo error....
it's libicui18n.so.69 ....
Last edited by jimarch (2021-12-05 16:10:34)
Offline
I've never seen that .10 before the version number on libraries before. The icu package in core contains libicui18n.so.69.1 for example. And it's not trying to load an .so as a shared library? Something's up with that, although I can't say exactly what. Perhaps just a typo with any luck.
So yes, if it actually wants libucui18n.so.69 that's in the icu package in core.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
@jimarch: icu69 is an intentionally drafted shim package for packages still relying on icu 69. This is due to failing rebuilds everywhere.
I pushed icu 70 to stable (also because of missing icu 70 dependencies), but there is usually a 50/50 chance that some package will
break, either because they require now the new icu or still using the old icu.
What would be an idea, is to always build those shim packages and install them automatically, but then nobody is uninstalling the old
icu67, icu68, icu69 packages and broken packages might remain unnoticed forever. This also deviates from upstream, so you have
packages on 32-bit which don't exist on 64-bit.
Offline
lddtree /usr/bin/sddm shows:
libQt5Core.so.5 => /usr/lib/libQt5Core.so.5
libdouble-conversion.so.3 => /usr/lib/libdouble-conversion.so.3
libicui18n.so.69 => None
libicuuc.so.69 => None
=> So, I'll rebuilt qt5-base and push it to stable..
Offline
webkit2gtk also requires rebuild for icu 70.1.
Offline
I wrote a script to scan /usr/lib for any lib.so that were still linked with icu69. There were quite a number of them and they were pretty bad. They seemed to be tainted with both icu70 and icu69. Many packages in staging and testing suffer the same flaw. Perhaps anything that link with webkit2gtk will be affected. Let me know if the script would help sorting things out or I will just include the list of flawed lib.so. This broke staging and testing in such a bad way that I need to boot with the ISO to revert back any changes with arch-chroot.
Offline
Here's the list of packages in stable that are tainted with icu69. I think all of them require a rebuild for icu 70.1 and if they have more recent version in staging and testing, they are probably bad, too.
tracker3 3.2.1-2.2
tracker3-miners 3.1.2-2.0
evolution-data-server 3.40.4-1.0
enchant 2.3.1-2.0
folks 0.14-5.1
chromium 90.0.4430.212-1.0
I don't know if the old chromium can be rebuilt with icu 70.1. I understand that latest chromium no longer supports 32-bit architecture. If it is too much hassle to rebuild last known good chromium for 32-bit architecture, then I think I will just drop it and use epiphany.
Offline
Thanks for the list. The problem currently is, that there are bugs everywhere, I have to patch first. tracker3 and libsoup3 have some "interesting"
problems with introspection for instance.
Quite some packages are not rebuildable. The problem with chromium is that they not only dropped 32-bit support for the browser, but also for the
webengine (which is the base of a lot of browsers). Epiphany, Midori are based on WebKit, so this might be a better option. I also had to blacklist
Vivaldi, as I can no longer find a 32-bit version. Chromium also still has a libsecomp issue, which nobody seems to bother to fix..
For firefox, thunderbird and seamonkey: they all need rust (which is currently broken). even then I cannot rebuild those packages due to
4GB issues. An old thunderbird still works with icu67, IIRC.
Offline
Testing repo config seems pretty borked right now too. I did an update before turning off on Friday and on Saturday neither firefox or sudo would run. Sudo was quite easy to get recovered, because it's crash reports were good, so I think I just downgraded icu back to the previous version and it worked, although that required booting off an install medium to get root access first. Firefox was more of a struggle to reload, but it seems to be working now. Apparently the only things I downgraded before the previous reboot was:
suitesparse
libical
libsoup
There's plenty of other stuff I've downgraded, because I really had little idea what I was doing, but everything else was tested and firefox was still not working. Since downgrading those it does work now.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
That happened for me automatically as part of whatever I did to get sudo working. Still didn't fix firefox though. I did downgrade libxml2 previously to the final reboot that fixed firefox, but that downgrade alone didn't seem to let firefox start after a reboot.
Early on, I recorded this error from firefox:
ExceptionHandler::GenerateDump cloned child 1041
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.Later on I just saw a lot of those 'exiting due to channel error' errors.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
evolution-data-server also requires rebuild for icu 70.1
Just install icu and icu69 in parallel, this is by far the easiest solution. :-)
I am observing the offending lib.so linked in both icu69 and icu70 such as below
ldd /usr/lib/lib.so
libicuuc.so.70 => (ok)
libicuuc.so.69 => (not found)
You're right about having icu and icu69 in parallel would be the easiest solution. But I am not sure if this was causing both libs to be linked if one was building packages. When I cross checked with official ArchLinux x86_64, the same lib.so would never have linked with both icu70 and icu69.
Offline
Yes, archlinux64 doesn't suffer so badly from non-compliant code that won't run on older hardware or alternative ISAs. They can rebuild everything with ease at the drop of a hat, almost certainly helped by having many more build servers each of which is more powerful than what we have, but that only speeds things up so just breaks quicker if the code is bad.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Unless the build system does something extremely funny, /usr/lib/libicu*.so should be taken (pointing to icu70).
That's exactly what I'm doing when I rebuild the packages, the shim icu69 makes sure the old software used for
building still works and the new binaries and libraries are linked against the new icu (70) shared libraries.
I pushed libxml2 because too many things required it. Now for firefox, I have first to fix rust again, and I'm not
positive that the new libsecomp-like security jailbox of firefox will actually work on 32-bit..
Offline
That makes me wonder what the firefox team do to produce their binary blob releases for 32-bit linux, but it might be more effort than it's worth to actually find out.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Unless the build system does something extremely funny, /usr/lib/libicu*.so should be taken (pointing to icu70).
That's exactly what I'm doing when I rebuild the packages, the shim icu69 makes sure the old software used for
building still works and the new binaries and libraries are linked against the new icu (70) shared libraries.
Yes, you're right. The shim icu69 wasn't picked up during packages rebuilding. I can confirm that by rebuilding evolution-data-server and trackers-miner3 with icu 70.1, the lib.so scanning for icu69 tainting is gone.
I pushed libxml2 because too many things required it. Now for firefox, I have first to fix rust again, and I'm not
positive that the new libsecomp-like security jailbox of firefox will actually work on 32-bit..
I don't use firefox. When I last used chromium I had to use '--no-sandbox' so libseccomp sandboxing was already broken. It is probably the only software on ArchLinux32 that I used that requires the shim icu69. If the same old version can be rebuilt with icu 70.1 without too much hassle, I think most will be fine with it.
Offline
Is sudo scheduled for a rebuild? I'm currently waiting for that to pop up in testing or stable so that I can try upgrading it and everything else at the same time. I expect I may still have icu69 installed after doing that.
I'll also note than mplayer starts up by saying this:
mplayer: /usr/lib/libldap.so.2: no version information available (required by /usr/lib/libsmbconf.so.0)
mplayer: /usr/lib/liblber.so.2: no version information available (required by /usr/lib/libsmbconf.so.0)
mplayer: /usr/lib/libldap.so.2: no version information available (required by /usr/lib/samba/libgse-samba4.so)And following on from that it's logs look good but it fails to play anything for me. But cvlc still works, as do ffmpeg and ffprobe, so I can mostly work around that.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Hah, we hit the magic number of >10'000 rebuilds on: https://archlinux32.org/buildmaster/ (the blue line) :-)
Offline
I pushed sudo, what was the problem again with sudo?
And I'm retriggering smbclient (because mplayer depends on it to play things from samba shares).
Probably is was just icu with sudo, because I think the only thing I downgraded was icu and dependencies when I was booting from the install DVD. But it makes sense to me to keep sudo working without any shims because at least then you've got a chance of recovering a system without the root password, and without having to dig out a boot disc.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline