Signing MacOS build: bundle format unrecognized

[unregistered]

I use the Renpy notarization tool to notarize my Mac Build with Apple but I just can't get the app signed and submitted.

When I try to sign it after unpacking with my Cert, this is the error I get:

Code: Select all

./notarize.sh {myapp} sign_app  
{myapp}.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: /mac-notarization-master/{myapp}/{myapp}.app/Contents/MacOS/lib/python2.7

The problem goes away as soon as I delete the python2.7 folder, which, of course, breaks the app.
Is there something in the python2.7 folder that renders signing impossible?

[unregistered]

According to this post, codesign doesn't want folders with periods in the MacOS folder, which Renpy has ("python2.7"). This is the same issue, I guess:

https://stackoverflow.com/questions/377 ... tory-names

[unregistered]

Sorry for triple posting:

I can confirm that the workaround from Stack Overflow works for the problematic directory structure of Renpy builds when codesigning isn't working:

- Move the folders within the .App Application folder from ./MacOS to ./Resources and symlink them back to ./MacOS
- This keeps the Renpy App working, but having a compatible directory structure for Apple's codesigning.
- To symlink, use the command line "ln -s {sourcedir} {targetdir}

Probably, Renpy should be updated to reflect that with future MacOS builds to avoid further codesigning issues because of invalid periods in directories.

[PyTom]

A quick look shows that this was fixed in Ren'Py 7.4.5. Are you on the latest version of Ren'Py?

[unregistered]

Ah, that might be it.

While I'm on Renpy 7.4.11 now, the build in question was compiled with 7.4.4.1439. So that might be it! Sorry for that and thanks for taking a look! My bad!

Are there any risks using the symlink workaround or should I recompile everything with the newest version just to be sure? I'm a little worried because the product has now been tested on 7.4.4. extensively.

[PyTom]

I don't have any advice about a symlink workaround - I haven't analyzed it.