Try xdg-open fireflyluciferin: (with the comma, without the path).
Usually your desktop file needs to specify which parameters it can accept, which in this case you haven’t (and there likely aren’t any), so there’s no need to pass what’s considered parameters there, but you can also add parameter support like:
MimeType=x-scheme-handler/fireflyluciferin %U
Unfortunately it’s really rare this needs to be done but I have had someone do it before and the effect does work as intended, so hopefully it’s just fiddling with the command, which you can do in snap run --shell and probably also quickly iterate on the .desktop file itself if you used snap try on a raw snap directory (i.e having run unsquashfs fireflyluciferin.snap)
> I tried attaching gdb, but it’s clear that jvm doesn’t like debuggers attached. Right from the start it got sigstop handlers invoked, and then a segfault in libjvm.
I can't comment on the rest of your message, but I might be able to help with
this. The JVM sometimes executes code that may trigger signals that are
expected to be handled by the JVM's signal handler. In particular, I know
there are a couple of these early in startup. Just try continuing in the
debugger, and let the JVM's signal handler have a crack at them. If it's one
of the expected ones, things will proceed normally.
Does SNAP detect a sigfault and block the process to continue normally?
no, “Snap” does nothing, gdb watches the jspawnhelper execution and detects a segfault… not related to snaps or the snap env at all …
If I read the log correctly this happens when it tries to spawn dpkg and rpm in a hardcoded way (which both are indeed not available unless you pull them into your snap) for an obscure reason it falls flat on its face after which it then segfaults …
You would probably get more info/output if the invocation of these two commands wouldnt have been artificially quietened with their stdout redirected to /dev/null …
I staged dpkg and rpm but the results does not change so it should not be that the breaking part.
even considering that I don’t have rpm and dpkg in flatpak and native,
and it works well without that packages when using flatpak/native.
just staging them might not be enough for them to work correctly, you will likely need to make them functional too …
you can not really compare to flatpak here where security is optional and apps have access to outside the sandbox by default, you’d have to lock it down the same way there …
either way i dont think this is going anywhere since you would need quite some changes to jpackage/jspawnhelper which you apparently wont be able to even identify in the current state, i think jpackage is simply not suited to be used in conjunction with snaps and strictly confined containers…
