Bug .exe (and .dmg?) builds don't work (anymore?)

heeheehee

Developer
Staff member
This is a tracking bug to make sure we don't forget about it.

We had hoped that the automatic exe / dmg builds would be helpful to users (so we could stop telling them to download a new version of Java), but they're apparently broken.

Some links to previous reports:

Common theme: Windows is generating two popups: "Failed to launch JVM" and "Child process exited with code 1". I would expect the former to be the one worth looking into, as the exe is presumably a JVM launcher, with the actual KoLmafia java application as the child process.

MCroft also reports that the macOS builds are broken.

(I haven't found time to troubleshoot the exe myself. But maybe I will make time.)
 

heeheehee

Developer
Staff member
https://kolmafia.us/threads/getting-mafia-started-help-please.27407/#post-167511 notes that the exe is apparently installing itself into Program Files where it doesn't have write access.

Supposedly we are setting --win-dir-chooser but that doesn't seem to be working. Instead, we could try setting --win-per-user-install which should install it into Users.

Separately, I'm not sure why several flags are specified as strings when the documentation indicates they should be booleans.

I've created a PR: https://github.com/kolmafia/kolmafia/pull/703
 

heeheehee

Developer
Staff member
My observed experience with r26341:

- Running the downloaded exe briefly opened up a dialog indicating that it was setting up stuff, and then exited without saying anything else.
- It then installed itself to C:\Users\<my username>\AppData\Local\KoLmafia-r26341, where there was a KoLmafia-r26341.exe. Launching this was successful.
- It also created a desktop shortcut pointing to the same executable, which also worked. I did not try logging in.

Comments:
- Obviously, it's good that it now installs and runs successfully.
- It's less good that the target directory is dependent on the revision number. I think this is based on appName (which is KoLmafia-rXXXXX).
- It's also less good that it doesn't launch the resulting executable.
 

heeheehee

Developer
Staff member
I forgot -- there were also some warnings re: this being an unsigned installer on Windows (and some scary click-through). This is because the exe is unsigned, and we'd traditionally need to purchase a cert ($XX / year), which we haven't done so historically due to the cost. Supposedly there's a path to do so for free via sigstore (gh actions integration; apparently cosign is used to sign its own windows binaries via gh actions). This may be worth investigating to get signed dmg builds as well.

r26343 should fix the issue re: target directory varying with each revision.

I looked around for ways to add auto-launch capabilities, and found some fix-up script for a MSI installer created by jpackage. I have not looked deeply into how that works.

Once I finish up the exe stuff, I'm going to need to punt the other half of this bug to someone with a Mac.
 

MCroft

Developer
Staff member
So, jpackage is a whiny little jerk about the version number format, but that's not a problem for our official builds, because we're never building dirty code.
Rich (BB code):
jpackage output:
Bundler Mac DMG Package skipped because of a configuration problem: "Version [22.04.26349M] contains invalid component [26349M]"
Advice to fix: Set a compatible 'app-version' value. Valid versions are one to three integers separated by dots.
:jpackage (Thread[Execution worker for ':' Thread 13,5,main]) completed. Took 0.179 secs.
Closing Git repo: /Users/mcroft/projects/kolmafia/.git
FAILURE: Build failed with an exception.

Once I gave it the version it wanted, I could build the executable locally with the jpackage task and run it. The one I built works fine. The one built by GitHub fails with the following error:
ASP: Security policy would not allow process: 21470, /Applications/KoLmafia.app/Contents/MacOS/KoLmafia

I think it's because it isn't signed, but I don't know why an unsigned app I built would work but one from GitHub wouldn't.
 

fronobulax

Developer
Staff member
I think it's because it isn't signed, but I don't know why an unsigned app I built would work but one from GitHub wouldn't.

Windows thinks some files from the internet are dangerous and inserts a confirmation check before access. Maybe the complaint is that the file came from elsewhere and not the signing status? Maybe you can tell MacOS you trust the origin before you try and run it?
 

MCroft

Developer
Staff member
Disabling SIP is remarkably difficult and isn't granular. They way to "bypass" it for a single app is to sign it.
 
Top