Repository navigation
Notarization fails for pygame-ce 2.5.4, but succeeds for 2.5.3 #3468
Description
Environment:
Platform: macOS-15.5-arm64-arm-64bit
System: Darwin
System Version: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:25 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6020
Processor: arm SSE2: No AVX2: No NEON: Yes
Architecture: Bits: 64bit Linkage:
Python: CPython 3.10.13 | packaged by conda-forge | (main, Dec 23 2023, 15:35:25) [Clang 16.0.6 ]
GIL Enabled: True
pygame version: 2.5.4
SDL versions: Linked: 2.32.6 Compiled: 2.32.6
SDL Mixer versions: Linked: 2.8.1 Compiled: 2.8.1
SDL Font versions: Linked: 2.24.0 Compiled: 2.24.0
SDL Image versions: Linked: 2.8.8 Compiled: 2.8.8
Freetype versions: Linked: 2.13.3 Compiled: 2.13.3
Display Driver: Display Not Initialized
Mixer Driver: Mixer Not Initialized
Current behavior:
I use Beeware's Briefcase to build an .app bundle, sign it, and submit it for notarization. I used the default minimal pygame template, so there is hardly any code. It just imports pygame and includes it in the binary. The notarization step fails and Apple's system gives the following unhelpful error message:
The signature of the binary is invalid.
The problem does not occur if I replace version 2.5.4 with 2.5.3.
Expected behavior:
The notarization step completes successfully when using pygame-ce 2.5.3.
Steps to reproduce:
Please explain the steps required to duplicate the issue, especially if you are able to provide a sample application.
if the bug is caused by a specific file (image, font, sound, level, please upload it as an attachment
- Install briefcase, make sure you have a code signing identity from Apple.
briefcase new, choose a pygame template- Replace
pygamewithpygame-ce==2.5.4orpygame-ce==2.5.3inpyproject.toml briefcase createbriefcase buildbriefcase package- Failure for 2.5.4, success for 2.5.3.
Activity
davidfokkema commentedon Jun 3, 2025
This is currently relevant for frescobaldi/frescobaldi#1987.
oddbookworm commentedon Jun 3, 2025
Suspect this is due to a dependency update funniness. Apple is weird about it and if your encodings aren't on point everywhere, it throws a fit
oddbookworm commentedon Jun 3, 2025
I'll try to investigate it soon
davidfokkema commentedon Jun 3, 2025
Thanks!
freakboy3742 commentedon Jun 3, 2025
These are definitely the hardest issues to debug - mostly because the feedback is minimal.
The comment about encodings is definitely worth exploring. The last time I saw this problem, the fix ended up being that we needed to use
dittorather thanzipto build the archive sent for notarization. If you're using Briefcase 0.3.23, you'll have that fix in place; but if PyGame-ce is doing anything... esoteric... with the filesystem, you could be hitting similar problems.There are a couple of ways to get slightly more information out of the notarization process. The
briefcaselog will show you the full return value from the commands that it issued, which may include a full JSON manifest of what has been packaged. If that doesn't help, if you runbriefcase packagewith -vv you'll get the full command line invocation of what is being run; if you poke around those commands (in particularxcrun notary tool logandxcrun notarytool history), there's a couple of ways to get more debugging information from the notarization process. However, it's not likely to be much more than "this specific file was a problem".oddbookworm commentedon Jun 4, 2025
@davidfokkema can you send the output of
python -c "import pygame; pygame.init(); pygame.print_debug_info()"?It seems to be working fine for me on an M4 macbook air
oddbookworm commentedon Jun 4, 2025
Oh, maybe I didn't do the certificate right
Something to look into tomorrow. It's already late...
Starbuck5 commentedon Jun 6, 2025
@freakboy3742 on the issue tracker 🤩
Is it possible this is the briefcase bundle not being updated for the new version? Like these are fresh builds right, it's not starting with 2.5.3 and then going to 2.5.4 with the same bundle?
@davidfokkema If this persists on totally fresh builds (which I think you've checked but would be nice if that was the issue), here are some GH actions runs you could try that contain wheels from between 2.5.3 and 2.5.4, to help us narrow down where this came from:
2/28 https://github.com/pygame-community/pygame-ce/actions/runs/13597292718expired artifact3/17 https://github.com/pygame-community/pygame-ce/actions/runs/13895057664
4/6 https://github.com/pygame-community/pygame-ce/actions/runs/14297840133
4/23 https://github.com/pygame-community/pygame-ce/actions/runs/14634784622
5/14 https://github.com/pygame-community/pygame-ce/actions/runs/15038303902
Instructions:
Download the arm wheel bundle
Install the correct wheel into your environment manually
pip install pygame_ce-2.5.4.dev1-cp310-cp310-macosx_11_0_arm64.whlfreakboy3742 commentedon Jun 6, 2025
I don't know, but I can't rule it out as a source of the problem.
I haven't done a lot of testing of "in place" upgrades like that; the assumption is usually that any release artefact will be built clean. It's entirely possible that there's something left over or stale from a previous build, or (more likely) that a new build hasn't picked up all the updated versions and requirements, and as a result the notarised artefact is internally inconsistent (and thus fails notarization).
fedelibre commentedon Jun 6, 2025
I think we can rule it out as a source of the problem, as this issue was opened after this Github Action failed. And I'm fairly sure it's a fresh build.
davidfokkema commentedon Jun 6, 2025
I agree with @fedelibre and tested clean builds on my machine. The previous version only came into play when it was found that 2.5.4 gave a notarization error. I've intervened in the build process and I'm now trying out the various builds.
davidfokkema commentedon Jun 6, 2025
I checked and double checked, and can confirm that run 14297840133 is the first one that fails.
https://github.com/pygame-community/pygame-ce/actions/runs/13895057664 (SUCCEEDS)
https://github.com/pygame-community/pygame-ce/actions/runs/14297840133 (FAILS)
https://github.com/pygame-community/pygame-ce/actions/runs/14634784622 (FAILS)
https://github.com/pygame-community/pygame-ce/actions/runs/15038303902 (FAILS)
ankith26 commentedon Jun 6, 2025
Thanks for narrowing down the range. Here are all the inbetween (your SUCCEEDS and the first FAILS) PRs ordered from least recent to most recent:
PR 1: SUCCEEDS
PR 2: #3380 (I kinda suspect this PR the most, but the thing is the CI didn't even run on it weirdly enough. This PR basically adds a whole bunch of tutorial files. Some of the tutorial files are in korean and we have already been bitten by encoding related issues here in the past)
PR 3: https://github.com/pygame-community/pygame-ce/actions/runs/14020552610
PR 4: https://github.com/pygame-community/pygame-ce/actions/runs/14024508125
PR 5: https://github.com/pygame-community/pygame-ce/actions/runs/14030818740
PR 6: #3374 (again CI didn't run on this PR, all it does is changes format of a few images. This could potentially also be problematic but IDK)
PR 7: https://github.com/pygame-community/pygame-ce/actions/runs/14188734802
PR 8: FAILS
You way want to bisect this list too. If you find out that one of 3380 or 3374 is the issue we can make a PR reverting that change and you can test that PR out.
2 remaining items
oddbookworm commentedon Jun 6, 2025
I seriously doubt that it's PR3, that's just code formatting using ruff
davidfokkema commentedon Jun 6, 2025
Sure, @ankith26 already suspected PR2 the most. But if there's no build I can test...
ankith26 commentedon Jun 6, 2025
I have made a PR reverting that PR. You can test that PR to see if that fixes the issue. The CI is still running but once its done, the wheels should be available at: https://github.com/pygame-community/pygame-ce/actions/runs/15488337078
davidfokkema commentedon Jun 6, 2025
Thanks, @ankith26, that build succeeds! I have only been testing the ARM wheels, but it certainly looks like the tutorials are the culprit!
ankith26 commentedon Jun 6, 2025
@davidfokkema I would appreciate if you can retest an updated version of my PR. I updated it to exclude only korean tutorials but added back the english and spanish ones https://github.com/pygame-community/pygame-ce/actions/runs/15489301095
Merging that PR as is would also cause a regression on another issue so I am trying to strike a middle ground here.
davidfokkema commentedon Jun 6, 2025
That latest run also works. I've been reading up a bit and it does seem that filenames with non-ascii characters can mess up the notarization process. And there doesn't really seem to be a way around it until Apple starts supporting this, as it has on its own filesystems.
freakboy3742 commentedon Jun 7, 2025
FWIW: Filesystem encodings sounds entirely plausible as a cause of notarization failure - Notarization involves zipping the app bundle, and if that zip process doesn't round trip 100% identical (including all filesystem properties), then notarization will fail. I'm not sure if Apple has any firm guidance on "no non-ascii filenames in apps", but if that's a problem (and, ideally, if you're able to generate an easy reproduction case), it would be worth catching (or at least warning) at the Briefcase level.
Starbuck5 commentedon Jun 7, 2025
Fix for this is included in pygame-ce 2.5.5, which has just been released.
davidfokkema commentedon Jun 7, 2025
@freakboy3742 That sounds like a great idea. In that case it would be possible to strip them out through Briefcase config.
oddbookworm commentedon Jun 7, 2025
@davidfokkema Just as a sanity check, can you verify for us one more time that our actual 2.5.5 release build works properly for you?
freakboy3742 commentedon Jun 8, 2025
@davidfokkema Could I request that you open this as a bug report on Briefcase? I haven't completely followed what file/filename was the cause of this problem (other than "non-ASCII"... possibly Korean Hangul is the problem?).
davidfokkema commentedon Jun 9, 2025
I’m traveling right now, and the bug surfaced in Frescobaldi. @fedelibre, could you check that Frescobaldi builds successfully with the latest version (2.5.5) of pygame-ce?
davidfokkema commentedon Jun 9, 2025
I will, when I’m back in a few days!
fedelibre commentedon Jun 9, 2025
I've just built a new release with version 2.5.5 and I confirm that the builds are all Ok now.
Thanks!