MSM and ICU

#1

Warning

If you are using KDE - uninstalling manjaro-settings-manager - and updating again will result in a broken KDE as the version of qt5-core in Manjaro repo is not the Arch version but a placeholder until some Manjaro specific issue is solved.

The problem is not ICU

We just started there.

Temporary fix

Might not work for everyone (xfce has been mentioned)

It is called unstable for a reason. Download and install qt5-base from this link

https://www.archlinux.org/packages/extra/x86_64/qt5-base/download/

then modify your pacman.conf and add qt5-base the the IgnorePkg= list

It is a temporary fix - please keep an eye on the forum for updates.


Last packages arrived in unstable requires MSM to be rebuild.

The MSM package has a dependency icu<63.0 and ICU is now at version 63.1-2.

This requires MSM to be uninstalled.

sudo pacman -R manjaro-settings-manager

The update after removal of manjaro-settings-manager is - I have to say it - oh no - here it comes - auch - a partial update - qt5-core 5.11.2-2.1 in official repo is not the right version it is a placeholder.


I have absolute no idea of why this is necessary - there must be a very good reason for this @philm?

3 Likes

Icu 63.1-2 upgrade breaks dependency with Manjaro-settings-manager
Cannot update due to icu can't update due to breaking dependency with Manjaro-Settings-manager
Latest update breaks desktop and applications
[Testing Update i686] 2018-10-25 to 11-24 - The Pretty Much Everything™ Update
Unstable update breaks KDE
#2

Just wanted to mention this, now i will just confirm it. Only had time to check on Gnome unstable.

0 Likes

#3

Yes, this is a rather serious error, because ignoring the update of icu leaves most applications, for example the browser, unusable.

On the other hand, if MSM ist uninstalled, then the desktop (KDE) does no longer start.

When can I expect that a modified MSM is available or is there an easy way to recompile it myself?

0 Likes

#4

how come??

it will certainly be updated soon… as soon as a dev have the time to build it and if there is no modification to be done because of ICU.

and it seems phil did not committed his change on gitlab after building it 2 days ago

0 Likes

#5

It is called unstable for a reason - we are here to catch these things.

I have tried building MSM but I am not a C++ dev and the build fails due to missing icu 62 lib.

So there is a reference somewhere but I don’t know where to start :slight_smile:

1 Like

#6

To be more precise: Uninstalling MSM alone works OK. The problem occurs after the installation of the updated icu package. The computer then hangs during reboot. I have now downgraded to stable.

0 Likes

#7

You were mentioning KDE and the build error I got was related to a KDE component which requires icu 63.

So this issue of icu might be bigger than just the partial update. It seems to reflect an issue with KDE it self.

I am on openbox - will try a reboot as I have not done so - yet.

Added: reboot fine - no problem.

0 Likes

#8

I’m updating now on a VM of plasma… will try to reboot… and build MSM

it will take some times… connection pretty slow… and will have a meeting… :wink:

EDIT: reboot… black screen… :thinking: wondering if it comes from plasma workspace or wt… as I don’t even have sddm.

0 Likes

#9

I confirm this on gnome unstable

error: failed to prepare transaction (could not satisfy dependencies)
:: installing icu (63.1-2) breaks dependency 'icu<63.0' required by manjaro-settings-manager
0 Likes

#10

I confirm that ICU break something with plasma…
with ICU 63.1 sddm doesn’t show up… trying to inverstigate

0 Likes

#11

I have cloned MSM and using the test PKGBUILD in the source folder the build fails with

-- Build files have been written to: /home/fh/Data/projects/manjaro-project/manjaro-settings-manager/build
[  0%] Automatic MOC for target msm_kernel_authhelper
[  1%] Generating org.manjaro.msm.keyboard.policy
[  1%] Automatic MOC for target msm
[  1%] Generating org.manjaro.msm.kernel.policy
/usr/lib/kauth/kauth-policy-gen: error while loading shared libraries: libicui18n.so.62: cannot open shared object file: No such file or directory
make[2]: *** [src/modules/keyboard/CMakeFiles/org.manjaro.msm.keyboard.policy-customtarget.dir/build.make:62: src/modules/keyboard/org.manjaro.msm.keyboard.policy] Error 127
make[1]: *** [CMakeFiles/Makefile2:1020: src/modules/keyboard/CMakeFiles/org.manjaro.msm.keyboard.policy-customtarget.dir/all] Error 2
make[1]: *** Waiting for unfinished job....
/usr/lib/kauth/kauth-policy-gen: error while loading shared libraries: libicui18n.so.62: cannot open shared object file: No such file or directory
make[2]: *** [src/modules/kernel/CMakeFiles/org.manjaro.msm.kernel.policy-customtarget.dir/build.make:62: src/modules/kernel/org.manjaro.msm.kernel.policy] Error 127
make[1]: *** [CMakeFiles/Makefile2:747: src/modules/kernel/CMakeFiles/org.manjaro.msm.kernel.policy-customtarget.dir/all] Error 2
[  1%] Built target msm_kernel_authhelper_autogen
[  1%] Built target msm_autogen
make: *** [Makefile:141: all] Error 2

I looks like the kauth-policy-gen component of KDE is hardcoded to expect icu 62.

0 Likes

#12

I confirm:

in my logs (I can’t copy past as I’m in TTY in VM)

sddm: error while loading shared libraries: libucu18n.so.62 connot etc etc..

love the “not a bug” here
https://bugs.archlinux.org/task/60637
if someone could explain where is really the problem :thinking:

seems it’s libQt5Core that still want old icu… then I guess Qt5base need a rebuild

on arch it’s qt5-base 5.11.2-2 (build on 22th)
icu 63.1 / poppler 0.70.0 rebuild
on my machine it’s qt5-base 5.11.2-2.1
seems we have a version from @philm buit on 27th (without the new ICU I guess)

0 Likes

#13
  • So sddm is not linked to icu.

It appears that setting the locale to en_US.UTF-8 solves the issue?

kauth-policy-gen seems to be linked to icu.

0 Likes

#14

I’m not investigating MSM right now… as I can’t start SDDM with the new ICU.

@linux-aarhus and your error is certainly related about to qt5-base package…

0 Likes

#15

I have downloaded and installed the qt5-base from Arch and I am in the process of building msm - which no longer fails and is installable, and runable with no errors.

But bear in mind - I am on Openbox - which might affect the outcome.

So it seems there must be a specific manjaro issue which needs solving as @philm is holding the Arch package back.

1 Like

#16

Will try to “downgrade” with the arch package to see if i see any side effect…
And will try to see why philm rebuild it if it’s somewhere on gitlab maybe there was error’s when he tried to rebuild msm as it was around the same time if I’m not wrong

EDIT: I lost the transluancy when moving window… but I’m not sure it’s related… i’m on VM and I had some problems… maybe it’s plasma-desktop

0 Likes

#17

XFCE and LightDM…

Removing MSM allowed update to be installed normally, but I think I can also confirm the qt5-base problem.

I run radeon-profile-git from the AUR, and it depends on qt5-base. After the update, I also get:

radeon-profile: error while loading shared libraries: libicui18n.so.62: cannot open shared object file: No such file or directory

As an aside, my locale is already en_US.UTF-8

ETA: reboot after upgrade with no problems, other than above.

0 Likes

#18

Has anybody tried the old trick to create a symlink to the new version, using the expected lib filename?

0 Likes

#19

https://wiki.manjaro.org/System_Maintenance

If a partial upgrade scenario has been created, and binaries are broken because they cannot find the libraries they are linked against, do not “fix” the problem simply by symlinking. Libraries receive soname bumps when they are not backwards compatible.

2 Likes

#20

I meant for troubleshooting only. Try, not use. :sweat_smile:

2 Likes