Arch Linux User Repository

In case of unknown PGP key run gpg --receive-keys 5A8ED9CFC0DB6C70

Due to widespread keyserver rot the use of keys.openpgp.org is encouraged, e.g. by adding keyserver keys.openpgp.org to your ~/.gnupg/gpg.conf.

@Δ: thanks for the notice. Since I'm short on time I can fix this tonight at earliest, unless you can propose a fix I can upload now.

Even if there is no new official release, an update to this package is needed, because this version bundles a SWT.jar that crashes under Arch Linux, and jamaica-nightly has fixed it.

Details can be read (in German) ↗ here and in the following post.

Regards!

Thanks for taking care of this. The question remains what to do in other cases where the developer might not be compliant, but this is not this pkgbases problem. I'll amend the pinned comment with the configured keyserver hint.

I've contacted the developer and owner of the PGP key. He instructed keys.openpgp.org to also disclose user ID information, so gpg --receive-keys 5A8ED9CFC0DB6C70 once again resolves this issue. As long as the correct keyserver is set in ~/.gnupg/gpg.conf that is.

@fumasu: This issue is indeed long open, and no sign of resolution in sight. One could either drop the signatures from the packages entirely, or use the skippgpcheck flag you mention. I'd like to see a discussion on this on aur-general, but don't have the time to initiate and lead it. Feel free to discuss there, and if a general consensus emerges I'll happliy implement it.

Install fails at PGP check because no key can be obtained. gpg --receive-keys 5A8ED9CFC0DB6C70 fails with no user ID as the de-facto new default keyserver keys.openpgp.org strips user IDs for privacy reasons if not instructed otherwise. Unfortunately that's the case for this key and I also could not find it on any other keyserver. This is a known problem with no solution in sight.

Only workaround for now: makepkg -s --skippgpcheck or yay -Sy jameica --mflags "--skippgpcheck"

Preferred solution: Instruct keys.openpgp.org to distribute user IDs with this key.

Edit: Issue resolved.

The preferred solution to the SecurityManager deprecation is not to circumvent it, but to stay with Java version 17 (see arch wiki on how to manage java versions). A version without SecurityManager is in preparation and for the very urgent is already available in the nightly build. See forum thread for more info.

EDIT: As of v2.10.2 java18 is now supported without workaround, it is safe to update java for jameica now.

Can confirm strubbisch's solution works.

#!/bin/sh

# Linux Start-Script fuer regulaeren Standalone-Betrieb.
# Jameica wird hierbei mit GUI gestartet.

cd /opt/jameica

_JLP="-Djava.security.manager=allow"

if uname -m |grep -q aarch64; then
    archsuffix="arm64"
    _JLP=" -Djava.library.path=lib/swt/linux-arm64"
elif uname -m |grep -q 64; then
    archsuffix="64"
else
    archsuffix=""
fi

# Zur Anpassung der Skalierung auf HiDPI-Displays kann der Parameter "-Dswt.autoScale" verwendet werden.
# Siehe https://www.willuhn.de/wiki/doku.php?id=develop:highdpi
LIBOVERLAY_SCROLLBAR=0 GDK_NATIVE_WINDOWS=1 SWT_GTK3=1 exec java $_JLP -Djava.net.preferIPv4Stack=true -Xmx512m -Xss64m $_JCONSOLE -jar jameica-linux${archsuffix}.jar $@

"I added the option "-Djava.security.manager=allow" in "/usr/bin/jameica" in the _JLP-String, then jameica starts."

This don't work for me, can you please post your changed /usr/bin/jameica?