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.

EDIT: This was NOT related to the SWT issue (at least not only to that) - in fact, jameica was still using Java 8 (as the java command referred to a Java 8 installation). As a workaround, I edited /usr/bin/jameica and replaced java in the last line by /usr/lib/jvm/java-11-openjdk/bin/java. Not a pretty solution, but I still to figure out whether I still need Java 8 for anything.

Original Comment: Unfortunately, rebuilding did not fix the SWT issue for me. I still get

java.lang.UnsupportedClassVersionError: org/eclipse/swt/widgets/Control has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Regardless, thanks a lot for maintaining this package!

@fordprefect: Works for me, although you forget to increment $pkgrel.
Thanks for maitaining,
regards!

I have pushed a quick fix for the SWT issue by just downloading the one from eclipse.com. This very quick fix has multiple expected side-effects:

• checksum of swt.zip fails for aarch

• i686 is disabled (no swt build upstream)

• untested, please report issues

Use with care, don't rebuild if the problem does not affect you!

@Δ: 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.