ungoogled-chromium in AUR lacks libicui18n.so.65

AUR
https://aur.archlinux.org/packages/ungoogled-chromium-bin/


After installation

$ chromium
/usr/lib/chromium/chromium: error while loading shared libraries: libicui18n.so.65: cannot open shared object file: No such file or directory

No icu65 in official repo of `pacman`, even no in AUR. How to solve it?

it's the problem with updating AUR package without checking if manjaro is ready to accept this update
ICU 65 is on unstable. not yet in testing or stable repos.

AUR packages is updated to work on ARCH.. then there can be a delay before they work on manjaro stable

the best solution is to use an other browser until icu 65 reach stable repos.

on http://site.icu-project.org/home:

2019-10-03: ICU 65 released

maybe.. but arch only updated it recently, I got it on 14th november.
and ungoogled-chromium-bin has been rebuilt for icu 65 on 15th november. (and some other updates after that)

image

That really a long wait.
Even pacman got icu65, ungoogled-chromium may break after an update.
I think if ungoogled-chromium in AUR is for Manjaro, it's its problem.

when manjaro got icu on unstable.. all package depending on icu (manjaro packages) is rebuilt for icu 65. (manjaro-settings-manager, pacman, etc) and it will follow the normal cycle (unstable -> testing -> stable)

Manjaro is compatible with AUR. but not 100%. there is time when an AUR update may not work on manjaro as soon as it's updated on AUR.

if you're not happy.. use the source package https://aur.archlinux.org/packages/ungoogled-chromium and build it yourself it should work. (it will take a long time to build depending on your computer power.

I'm sorry.. it's how AUR works.. and it won't change.. AUR is for ARCH.. manjaro can use it.. but there is some hiccup like this.

pacman version on unstable is 5.2.1-2 for icu 65.. on testing and stable it's still 5.2.1-1

2 Likes

I think you seriously dont understand whats happening here.

what do you mean 'pacman got icu65' ? there is just one. the one in the repos.
[for your given branch]

ungoogled-chromium is not for manjaro .. notice it isnt in the repos, but is in the Arch User Repository ?

1 Like

That's ok, maybe I can try an old version of AUR package.
However it's better for an AUR package to tell whether it can run in the current environment, e.g. lack icu65, or else I need to try practically.

If you want to be closer to Arch then move to the Unstable branch or, you know, use Arch.
There is also no way for manjaro to 'control' the AUR. It isnt ours.

2 Likes

Alright, only one version of icu in pacman's repo, that's simple, I think it's fine.

arch's pacman's repo is not the same as manjaro's pacman's repo, right? So I know why, thanks.

with using AUR on manjaro stable.. yes.. it's always better to keep the old package somewhere in case of issue like that.

pacman isnt a repo. it is a package manager. it manages packages on your system. depending on how it is configured it will interact with any mirror/repo you want. In the case of manjaro, that is by default manjaro mirrors. on Arch it would be ... Arch repo/mirrors.

https://wiki.manjaro.org/index.php?title=Repositories_and_Servers

Then there is the AUR. Which pacman cannot interact with on either distro.
You interact with it manually or you use a helper (yay, pamac, or others).
Again - while manjaro mostly supports the AUR .. the AUR isnt made for manjaro. It is made for/by Arch Users. So if your branch is somewhat behind (like Stable at times) then you can find yourself in a situation like this.
You can wait, manually upgrade the package, switch branches, downgrade ungoogled.. or wait.

https://wiki.manjaro.org/index.php?title=AUR

4 Likes

No, I won't move to arch now.
Manjaro is well built on arch, even awesome.

I feel the people behind Manjaro are better than those behind arch :face_with_hand_over_mouth:, one clue: I can't update the comment in AUR web page today, and the Manjaro forum is very nice.

AUR is for arch, as candidates. And Manjaro makes its own decisions. So I think uncommon things like ungoogled-chromium should be done by myself.

BTW, openSUSE's obs is really good for trustable build.

Thanks

ORRR ... you can convince a manjaro team member here to add ungoogled to the repos so it will track with manjaro (and have the added bonus of not needing to be built).
Which I would be all for .. but it means extra work for someone. And I havent been able to convince anyone to do so (yet).

2 Likes

It did. You installed a binary package built with newer libraries than you have and it told you why it couldn't run.

Can PKGBUILD tell that it can't run in my current environment, because lack of icu65? So no need to download the pkg file, it's slow for me to download.

No, Pacman is only following the instructions in the PKGBUILD. The creator of the PKGBUILD could specify a minimum, maximum or specific version of a dependency that is required, but that would be redundant and unnecessary. To use the AUR, one is expected to be fully up to date with the latest Arch package updates. Either way, it's up to the user to manage his own AUR packages.

Understand, thanks.

Are you talking about this total unrelated person, wich is not to trust ?



https://aur.archlinux.org/packages/ungoogled-chromium-bin/

When using AUR and private repos, we should be able to read PKGBUILD instead of making random jokes.

There is a git source, including an 'arch' branch from the actual creator. Yes, I assume any pkgbuild that would be accepted into the repos would be predicated on that source.

(I dont get why you take this so personally .. but I also dont get why you dont understand this ... the actual project is here: https://github.com/Eloston/ungoogled-chromium
which also includes text like " NOTE: ungoogled-chromium-bin is not officially part of ungoogled-chromium. Please submit all issues to the maintainer of the PKGBUILD.")

..how do I make this more clear?

... I am OK with 'ublock:Origin' being in the repos, but I am not OK with the malware 'ublock' being in the repos. I am ok, again, with our packages being sourced from 'ublock:Origin' ... but I am not OK with sourcing that software from a random fork.

Does that make more sense now ?

Forum kindly sponsored by