On Feb 2, 2026, at 04:35, Nicklas Larsson wrote: > > While adding py314 subport [1] to py-wxpython-4.0, we encountered some > strange failures to apply patches. Initially, the patches were old, and > needed to be updated to reflect upstream changes to the files. Before the > patch-updates the patches succeeded on CIs, and locally (macOS 26, ARM), but > failed on _all_ Intel botbuilds and on both architectures on macOS 12 and > older. However, after the patch updates, the problem persists, now with the > error message "No file to patch”. > > See for example the latest commit on macOS 13 [2]. > > I assume there are different version of ‘patch’, causing the various results.
Not different versions; different programs. In macOS 12 and earlier, Apple shipped GNU patch. In macOS 13 and later, they ship FreeBSD patch, I believe. They can behave differently for fuzzy patches. This is why it is important to de-fuzz your patches whenever you update a port, as you already did. > Does anyone have an idea what is going on here? Or did I miss something > obvious? The port's worksrcsir is wrong. The port is looking for a directory called wxpython-4.2.4 but it is actually capitalized wxPython-4.2.4 on disk. This should have failed on all buildbot systems because it is our intention to use case-sensitive filesystems on the buildbot. The fact that it succeeded on the arm64 buildbot machines suggests that I inadvertently set up those workers with case-insensitive filesystems.
