Hi,
it is now the 4th time this bad designed unicode library is breaking my system.
EVERY time libicui18n.so gets updated lots of programs break.
So there is nothing that can be done to avoid the 3-4 times a year breaking of all sorts of programs because they are linked to
the wrong version of libicui18n.so ?
Is it impossible to stabilize a unicode library to provide the same API longer than 3 month ? mod: no swearing in official sections please.
I found the problem.
The base library files in icu-73.2-1-x86_64.pkg.tar.zst are
libicudata.so.73.2 but they should be libicudata.so.73
If I rename the libicudata.so.73.2 to libicudata.so.73 and adjust the symlinks to
libicudata.so -> libicudata.so.73
libicudata.so.73.2 libicudata.so.73
Than Chromium can find the libicudata.so.73 lib.
So I have renamed all .73.2 to .73 and adjusted all symlinks.
That makes Chromium and LibreOffice-still working again.
libicudata.so.73.2 is the correct .so and libicudata.so.73 and libicudata.so are symlinks to it. I just tried Chromium from the arch repos and it worked fine here. I'm not sure what exactly you changed with those library files but I would not recommend that.
> pacman -Q chromium
chromium 114.0.5735.198-2
> pacman -Q icu
icu 72.1-2
> grep -Eve '^#' /etc/pacman.conf | tail -n 32
[system]
Include = /etc/pacman.d/mirrorlist
[world]
Include = /etc/pacman.d/mirrorlist
[galaxy]
Include = /etc/pacman.d/mirrorlist
[lib32]
Include = /etc/pacman.d/mirrorlist
[universe]
Server = https://universe.artixlinux.org/$arch
Server = https://mirror1.artixlinux.org/universe/$arch
Server = https://mirror.pascalpuffke.de/artix-universe/$arch
Server = https://artixlinux.qontinuum.space/artixlinux/universe/os/$arch
Server = https://mirror1.cl.netactuate.com/artix/universe/$arch
Server = https://ftp.crifo.org/artix-universe/
[extra]
Include = /etc/pacman.d/mirrorlist-arch
[community]
Include = /etc/pacman.d/mirrorlist-arch
[multilib]
Include = /etc/pacman.d/mirrorlist-arch
> ldd /usr/lib/chromium/chromium
libicui18n.so.73 => not found
libicuuc.so.73 => not found
.73.3 => .73> ldd /usr/lib/chromium/chromium
libicui18n.so.73 => /usr/local/lib/libicui18n.so.73 (0x00007f004f800000)
libicuuc.so.73 => /usr/local/lib/libicuuc.so.73 (0x00007f004f400000)
so what's the solution for user, when faced by following error during system upgrade.
error: failed to prepare transaction (could not satisfy dependencies)
:: installing icu (73.2-1) breaks dependency 'libicuuc.so=72-64' required by brltty
:: installing icu (73.2-1) breaks dependency 'libicuuc.so=72-64' required by gspell
:: installing icu (73.2-1) breaks dependency 'libicuuc.so=72-64' required by harfbuzz-icu
:: installing icu (73.2-1) breaks dependency 'libicui18n.so=72-64' required by mpd
:: installing icu (73.2-1) breaks dependency 'libicuuc.so=72-64' required by mpd
:: installing icu (73.2-1) breaks dependency 'libicuuc.so=72-64' required by raptor
-> error installing repo packages
can I just do a `nodeps check` upgrade of package `icu` by doing:
pacman -Ud icu
Is your mirror actually up to date? All these packages were moved within like 5 minutes of each other.
Hi suren,
the hotfix that is working for me:
* Updated icu to 73.2-1
* Downloaded wget https://archive.artixlinux.org/repos/month/system/os/x86_64/icu-72.1-2-x86_64.pkg.tar.zst
* Installed the files and symlinks in icu-72.1-2-x86_64.pkg.tar.zst usr/lib/* to /usr/local/lib/ (with mc)
* Added /usr/local/lib to /etc/ld.so.conf.d/local.conf (with echo "/usr/local/lib" >>/etc/ld.so.conf.d/local.conf)
* Activated the libs (sudo ldconfig)
you are correct my mirrors where not synced.
I use a cron job that activates at 00:00 UTC. Is there a better time to sync and upgrade? I think that's exactly the time a server normally syncs.
[EDIT]: I will be more patient if any problems happens during system upgrade. Thank you artix dev team.
thank you for your response, It may help with some of my other problems (^_^)
I'm not sure if there's necessarily a good time per se. This just seems like some bad luck.
Again a clean notice, all our icu rebuilds are fine.
If you use archlinux packages, please refrain from complaining here about breakage.
We do not support arch repos.
So you not support arch repos.
Where is the Artix LibreOffice package located ?
Or do I have to do without libreoffice because you don't support arch repos ?
The libreoffice I have is still linked to the old libicu and need the old libs installed.
It is in the universe repo.
For your tone, you don't deserve to know the reason, but its somewhere on the forum.
> It is in the universe repo.
No its not.
I checked Thu Jun 29 11:09:30 AM with
sudo pacman -S universe/libreoffice-still
And still got a version of libreoffice-still from the universe repo.
ldd /usr/lib/libreoffice/program/soffice.bin | grep /usr/local/lib
libicuuc.so.72 => /usr/local/lib/libicuuc.so.72 (0x00007fb28c800000)
libicudata.so.72 => /usr/local/lib/libicudata.so.72 (0x00007fb287200000)
libicui18n.so.72 => /usr/local/lib/libicui18n.so.72 (0x00007fb286600000)
> For your tone, you don't deserve to know the reason, but its somewhere on the forum.
What next ?
Do I get banned for justified criticism ?
libreoffice-fresh had already been rebuild and replaced.
The build of libroffice-still just completed, so should be fixed now.
artist
Hi,
I can confirm
sudo pacman -R libreoffice-still ; sudo pacman -Syy universe/libreoffice-still=7.4.7-4
fixes
now the problem with the wrong libicu in libreoffice-still.
For me the icu update was held up by a few packages (atm it's ncmcpp) so glad i avoided the drama :)
@Andy No one forces you to update constantly, yes even on a rolling distro, I am repeating myself from a previous thread but you need to "feel" the update and postpone it until more stuff gathers up. Of course drivers, kernel and stuff are an exception.
@suren The solution is patience :) No i am not sarcastic.
Hi Hitman,
I don't update constantly, I have octopi-notifier running

with set to 'check once a day'.
Artix has to find a way to cluster updates in a way together that prevent this update drama.
Allow me a rant now, all team members work in their precious free time on artix.
It is rather annoying, some people take everything for granted, while they would never ever consider to work on anything without payment.
It seems to me that most of this "drama" comes from (new) users.
I never understood updating an Arch/Artix system automatically periodically. It causes problems. I've witnessed it cause problems for some 12 years now. I'd never update even once without checking what's happening. Whenever I've had problems myself, it has turned out to be careless negligence in updating, perhaps combined with bad luck in timing. Automatic periodic updating is the ultimate careless negligence, by choice, repeated forever.
But if checking what's happening in an update is too much for you, I totally get that; go and try another distro, then.
Maintaining a distro is not an easy task. These people do it for free. You might think you are giving "justified criticism", but it is not very constructive (I don't see concrete, technical suggestions, let alone offers to help), and at least to me it comes off as rudely complaining when things turn out to be not exactly the way you mistakenly expected.
Not only to you. I suspect the rudeness stems from the favorite game not starting or so.
A consequence might be, we gonna remove arch support entirely, it has no benefit at all keeping it.
I can't say I'd blame you.
Thanks for the work you all do.
We unfortunately live in a very 'entitled' society.
Okay, understood, the little red icon will bug you once a day. What happened now is that you probably don't have all those packages that would've held up the update, and thought something is wrong because it went through early. No one's to blame here.
Check above, that's why rolling distros are for more advanced use generally. Manjaro tries to stop the rolling with pretty bad consequences. Alpine holds updates sometimes but it's basically for embedded systems, mainly due to lack of glibc.
Artix has went through some massive repo changes recently so until things settle down expect some of this stuff.
The direct cause of modern social media of the past 10 years.
We don't have magic powers that can predict when Arch decides to move major library updates. So if you use a mix of Arch + Artix repos, it is possible that Arch will move a package that depends on a major library before we move ours. That's all this is and it's just something you should know how to deal with as a user (deal with in this case usually just means "wait a couple of hours"). The best solution is to just add more of this stuff into Artix repos, but there are some packages out there that are monsters to build.
I totally agree, and personally I am very appreciative for all the work the devs do to provide such a wonderful OS, and also all the support that is in these forums from both the devs and some very knowledgable users who are extremely patient in the face of some (few) very demanding users.
If people want a stable distro without any update problems, why on earth are they using a rolling distro?
I updated this evening and icu went through, seems every issue reported here has already been solved.
I would remove you from the forum immediately.
I'm getting some libicuuc.so.72 errors after updating on gremlins earlier today, for example the window decoration in Mate looks odd and mate-appearance -properties won't start, I haven't determined exactly why yet. But on stable repos it seems OK so far, if it was helpful to add.
Edit: I fixed it simply by running -Syuu (allows downgrades if version in repo is lower) which did this on a system which was fully updated according to -Syu:
downgraded libxml2 (2.11.0-1 -> 2.10.4-6)
downgraded python2-psutil (5.9.4-1 -> 5.9.0-1)
installed python2-appdirs (1.4.4-6)
installed python2-pyparsing (2.4.7-6)
installed python2-six (1.16.0-5)
installed python2-packaging (20.9-7)
installed python2-ordered-set (3.1.1-4)
downgraded python2-setuptools (2:44.1.1-2 -> 2:44.1.1-1)
Probably it was libxml2, as that came up as missing the libicuuc.so.72 according to check-link-consistency. For some reason a newer version had appeared in April but then disappeared again.
Maybe that's due to that that to find a good fixed distro with all needed packages and without systemd plague is pretty challenging if possible at all?
You're pretty much right, there is Devuan but it's a complete mess, no software, still loads sysvinit first, takes a lot of work to be properly up to speed.
I mean you can make it work, but it's further expert level IMO than pampering a rolling distro sometimes.
The best "rolling release" without systemd : Artix Linux.
I've been using it on different machines since 2019.
The best "fixed release" on which systemd is not enabled by default : MX Linux.
I install it for people who don't want/know how to "put their fingers in the engine".
There is also AntiX, on which MX is partly based.
MX and related will still also load sysvinit first->rc like Devuan does, and they have some bigger weirdnesses of their own.
Alpine, the other nonsystemd rolling distro (where on it's stable channel isn't rolling that much), loads busybox-init by default then rc via inittab, it can be changed but it's lack of glibc makes it weird to use on the desktop. Other embedded distros have the same "problem", cause they save every bit of memory possible.
I came from Debian, so I tried that, naturally. But somehow I found out that their team leader is a politically engaged person, and that is the red flag for me. Other than that, MX looked usable but had some quirks that I didn't like then.
Gentoo gave me the best experience regarding the stability and available packages. But it is too heavy on resources for maintaining the system. Especially for a desktop scenario - when you use lots of bulky office software and have only a laptop.
Artix is not perfect also. But as for me, it is the best option available now. My kudos to developers!
Gee, I wonder why would people think that. </sarcasm>
The Debian team leader doesn't seem to publicly offer much in the way of political opinion that I could find from a quick search:
https://jonathancarter.org/ (https://jonathancarter.org/)
So what did you discover ? :o
Oh, I see:
https://pleroma.debian.social/highvoltage (https://pleroma.debian.social/highvoltage)
"highvoltage
3d
So the mayor of Neuilly-sur-Marne wants to increase policing instead of addressing any actual root causes of the rioting. What a f??kw?t."
Quite an out of character post though - hackery or another Debian dev going off the rails?
Politics is the dirty thing, software development is much, much cleaner. Also, both need lots of time and dedication if someone wants to achieve anything. And mixing them does not look good to me.