The root cause of the problem is that the mirrors have an invalid qt5-es2-wayland-5.15.6+kde+r49-1-aarch64.pkg.tar.zst.sig file, so is there anything that can be done to fix that on the server end?
It also worries me that nobody knows how that has happened (rsync hash collision maybe?), since a package with no valid signature is a package whose authenticity cannot be verified.
An updated package is already in unstable branch. You can try using that one. If it doesn’t have any regressions (because regular qt5-wayland is only at r49), then I can forward the one from unstable.
The building and uploading of these packages are done by an automated system.
How can an automated system mess up in that particular way? I could see a human mixing up the file names with and without the .sig ending, but a program will not usually do that. So I have to wonder whether somebody messed with the package between when the automated system built in and when the mirrors rsynced it from the masters, and whether it may have been backdoored.
I don’t know what happened to this particular package.
In any case, I have just forwarded the r50 version from unstable to both testing and stable branch.
So it should be able to update it, as soon as the mirrors sync.
Thanks!
I have now updated and I was seeing the issue described here despite having qt5-es2-wayland-5.15.6+kde+r50-1 installed.
Thankfully, I was able to SSH in and run pacman -S qt5-wayland to switch to qt5-wayland-5.15.6+kde+r49-1. That fixed it.
But qt5-es2-wayland seems to be entirely broken, even the package that does not have a corrupt signature.
Sweet, running pacman -S qt5-wayland fixed it for me too.
Odd. Well it gives me a reason to do what I’ve been wanting to do for a while.
I’ll add an update that should replace all installs of qt5-es2-wayland with qt5-wayland. Will be done in manjaro-system package.
Maybe the build was somehow built against some libraries that are still stuck in unstable and are incompatible with the ones in stable?
But anyway, as you say, if qt5-es2-wayland is not or no longer needed, let’s just drop it.
Sounds good, be glad to test it, when ready
The fix should be in manjaro-system in all branches now.
Thanks to everyone contributing on this thread. This is fixed for me as well by pacman -S qt5-wayland.
I have seen it several times that pacman reported that a local package didn’t match the one from the repo (it’s different from this core issue but might cause the same issues). It seems like things get staged and pulled afterwards leading to that - or versions are getting posted which cannot be properly handled/detected by the tools.
Discover has also been reporting an available update (kpeoplevcard: 0.1-1 -> 0.1-1.7) for ages now which does not even exist. pacman is not reporting this at all. But I still consider Discover completely broken on PinePhone.
All of these warnings I fixed by re-installing the packages. They never caused any (visible) issues though.
It would also be really helpful if the error message would be recorded if something core dumps with SIGABRT. But that seems like a very upstream issue. It’s an extremely bad core shortcoming which I would consider essential when recording these issues.
I’m pretty sure I had the update with manjaro-system (and one ‘qt5 wayland’ related package, don’t know if it was the es2 variant or not from memory) upgrade 1-2 days ago.
$ pacman -Qi manjaro-system
Name : manjaro-system
Version : 20221004-1
Description : Automated Manjaro ARM system tweaks
Architecture : any
URL : https://www.manjaro.org
Licenses : GPL
Groups : None
Provides : onlykey-udev
Depends On : pacman>=4.2 coreutils util-linux systemd e2fsprogs uboot-tools sed awk grep libnotify
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : onlykey-udev
Replaces : None
Installed Size : 5.47 KiB
Packager : Manjaro Build Server <build@manjaro.org>
Build Date : Tue 04 Oct 2022 06:51:56 AM CEST
Install Date : Wed 05 Oct 2022 03:47:15 PM CEST
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature
I still had qt5-es2-wayland on my system after this (and no qt5-wayland):
$ pacman -Qi qt5-es2-wayland
Name : qt5-es2-wayland
Version : 5.15.6+kde+r50-1
Description : Provides APIs for Wayland - with OpenGL ES 2.0 support
Architecture : aarch64
URL : https://www.qt.io
Licenses : GPL3 LGPL3 FDL custom
Groups : qt qt5
Provides : qt5-wayland=5.15.6+kde+r50
Depends On : qt5-es2-declarative libxcomposite
Optional Deps : None
Required By : kguiaddons kwayland layer-shell-qt plasma-wayland-session
Optional For : maliit-framework qt5-es2-base
Conflicts With : qt5-wayland
Replaces : None
Installed Size : 6.51 MiB
Packager : Manjaro Build Server <build@manjaro.org>
Build Date : Sat 01 Oct 2022 10:24:54 PM CEST
Install Date : Wed 05 Oct 2022 03:47:26 PM CEST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
(I just did a pamac update -a, to be sure; no new packages)
Using pacman -S qt5-wayland and confirm it replacing qt5-es2-wayland fixed my issue as well but it seems the manjaro-system update didn’t fix it, at least not in my case.
Thanks @Firewave for the kpeoplevcard reinstall hint, had the same problem and this fixed it.
Damn, I thought I did it correctly.
Just uploaded manjaro-system 20221006, which should replace the package correctly. This time I tested it myself.
Oh - I didn’t think about doing that on the shell since only Discover reported it. It also just happened on my Desktop install.
This issue persists even after the latest updates. Just press the “lock” hardware button on the phone once too often and you will get the “loginctl” message.
That is not the same issue.
This thread is about the error coming up immediately on boot, making Plasma entirely unusable. That is due to incompatible ABIs between Qt shared libraries. The only fix then is to install a working qt5-wayland through SSH or using an USB keyboard.
What you are seeing is just general instability. It cannot be an ABI incompatibility, or Plasma would not start at all. What you are seeing appears to be a regression since September 4: [ARM Testing Update] 2022-09-04 - Phosh, Firefox, Thunderbird, Pipewire, Kernel, Python - #5 by Pak0st, and nobody knows what causes it. The discussion just stopped because a new testing update was pushed very soon afterwards, on September 9, and discussions on outdated testing updates are always closed. But that update did not fix the issue. Nor was it fixed in the updates that went stable.
I have Manjaro-Plasma on a Pinephone Pro. There have been recent issues with the latest upgrade. I believe this is due to a problem with the upgrade of the package kirigami-addons. I receive the following feeback when I upgrade:
sudo pacman -Syyu
[..]
:: Starting full system upgrade..
.
warning: kirigami-addons: local (1:0.3-1) is newer than extra (0.4-1)
there is nothing to do
Regarding the warning, I tested which version is installed:
sudo pacman -Q kirigami-addons
kirigami-addons 1:0.3-1
I speculate that changing the version number of the newer kirigami-addons from “0.4-1” to “1:0.4-1” would fix this. 1:0.4-1 is the version that should be installed.
I’ve tried to make developers of Manjaro-Plasma aware of this via posting a bug report on it, and also by posting a comment @ManjaroLinuxARM on Twitter. No acknowledgement so far.
Well, it partially stopped as I didn’t have the motivation or time to go through the logs so far 
Can’t comment for other people.
I will see what I can do over the weekend towards checking those (it’s on my ToDo)