Undeclared function 'is_pad' on macos-13 GitHub runners #115383
Comments
|
Theory: those failures are both using version 20240114.1 of the runner image, passing builds are using newer 20240204.1 (visible in the logs under Set up job > Runner Image). Perhaps some tools/compilers have changed and we're restoring some caches for the wrong ones? |
|
@sobolevn: oh, do you recall that issue? |
|
Docs: https://manpages.debian.org/experimental/ncurses-doc/is_pad.3ncurses.en.html { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_curses_is_pad" >&5
printf "%s\n" "$ac_cv_lib_curses_is_pad" >&6; }
if test "x$ac_cv_lib_curses_is_pad" = xyes
then :
printf "%s\n" "#define HAVE_CURSES_IS_PAD 1" >>confdefs.h
fiAnd then we use this macro: cpython/Modules/_cursesmodule.c Lines 1157 to 1163 in 0a6e1a4 Refs 8bc7d63 Interesting that the
I think that the only thing that can change here is the |
|
Let's try to |
|
Ok, it didn't work. The second idea: we can try to delete the builder cache: https://github.com/python/cpython/actions/caches?query=macos (@hugovk?) |
|
We could try that, but it might re-occur as new caches are saved. It could at least help isolate the problem. If this is only a problem with the older 20240114.1 images, I expect they're currently rolling out the newer 20240204.1 across the builders, so the problem would eventually go away. But it could potentially re-occur. Perhaps we also need to add an extra key to the cache. Comparing failing/passing logs: 
The failure is with Xcode 14.3.1: The passing build is with Xcode 15.0.1, we don't get an error, but we do get a warning: |
|
Related? #109617 "Refresh Screen Provided By curses.wrapper Causes Seg Fault (macOS, xcode 15 Apple supplied ncurses 6.0 breakage)" |
|
This looks like a fix #111258 |
|
That looks good: #111258 (comment) |
|
Note that #111258 applies only to builds that use Apple-provided ncurses. If I remember correctly, official macOS builds ship a specific ncurses and are not affected by either issue. So this is one way that GitHub runners are not aligned with official builds, in a way that is not well documented. |
|
Do you think that there is also a configure caching bug? The passing builds that @hugovk linked to did not restore |
Our GitHub actions build caches the results of "configure" on macOS and Linux. Periodically, GitHub releases new images for their actions runners. This incorporates the runner's OS and image version to compute the config cache key to avoid using a stale configure cache.
Our GitHub actions build caches the results of "configure" on macOS and Linux. Periodically, GitHub releases new images for their actions runners. This incorporates the runner's OS and image version to compute the config.cache restore key to avoid using a stale configure cache.
|
These both restored the same cache: Both macos-13, but different Xcode versions. It sounds plausible a cache from one Xcode version is problematic when restored for another Xcode version? Caching the image version like in #115409 sounds promising! |
|
From #111258 (comment):
Both ran with no cache restored: |
Yeah, my comment wasn't accurate. I should have said the failing builds appear to be both running image |
…onGH-115409) (cherry picked from commit 4deb705) Co-authored-by: Sam Gross <colesbury@gmail.com>
pythonGH-115409) (cherry picked from commit 4deb705) Co-authored-by: Sam Gross <colesbury@gmail.com>
|
anything left to do here? |
|
CI is green, let's close. Thanks everyone for the investigation! |
|
We're hitting this again with the pyrepl PR. The image now is at 20240421.1 so way past the versions discussed above. I'm leaning towards landing GH-111258 to address this properly. |
|
The PR landed and fixed the issue on our PR, too. This can be closed again :D |
Bug report
It looks like it's only on the macos-13 runner. I'm not sure what changed. The failures look to be on unrelated commits and PRs.
Seen in:
Linked PRs
ncursesin reusable macos workflow #115389The text was updated successfully, but these errors were encountered: