Update to the latest c-code template

[mgedmin]

Add a regression test for CFLAGS not having -Ofast, which is known to break things. See https://github.com/zopefoundation/meta/pull/155 for reference.

For some reason I was unable to verify that the CFLAGS problem actually affects persistent. Running the new regression test with

$ CFLAGS=-Ofast tox -re py38 -- -pvc -m test_compile_flags

did not cause a failure.

[mgedmin]

Well, the new test has failed on CI, so that's good news.

I wonder if it's the same deal we had with BTrees, and some package in the pip cache had the bug? But does persistent depend on any other packages containing C code?

Ah, yes, zope.interface.

Will clear the cache and retry the job.

[mgedmin]

Cache is cleared with

gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/persistent/actions/caches?key=Linux-pip-3.11.0-rc.1

I can't retry failed jobs while there are jobs still running. Manylinux build on aarch64 is taking a long time...

[mgedmin]

Wiping the cache didn't help. Well, it used a different cache instead (the one for Linux-pypy-3.7) and failed again. So I wiped that cache too:

gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/persistent/actions/caches?key=Linux-pip-pypy-3.7

retried again, and now it used Linux-pip-3.8 cache, failed, so I wiped that one, and I don't know if this is the right approach...

[mgedmin]

Is there any way Linux-pip-pypy-2.7 caches could poison Python 3.11.0-rc.1 builds? I don't see how.

What is going on? Somebody help!

[d-maurer]

Marius Gedminas wrote at 2022-9-9 08:17 -0700:

Is there any way Linux-pip-pypy-2.7 caches could poison Python 3.11.0-rc.1 builds? I don't see how.

The cache content for some implementation (such as pypy, Cpython) should not affect other implementations -- at least not regarding extensions.

[mgedmin]

Hm, I see the build step used a different cache: Linux-pip-3.11.0-beta.3. Maybe that one had a tainted zope.interface .so? Let's go:

$ gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/persistent/actions/caches?key=Linux-pip-3.11.0-beta.3

and then, let's see, a retry with debug info enabled shows that 3.11 builds try to fetch caches using Linux-pip-3.11.0-rc.1 as the cache key, instead get a compatible cache Linux-pip-3.6, unpack it, and then find files like

../../../.cache/pip/wheels/26/eb/0c/413ef3f3b51eac5046ef623fab8d71f429297aefda870af4f8/zope.interface-5.4.0-cp311-cp311-linux_x86_64.whl

Why the heck does a Python 3.6 cache contain 3.11 binary wheels??? Anyway

gh api --method DELETE -H "Accept: application/vnd.github+json" /repos/zopefoundation/persistent/actions/caches?key=Linux-pip-3.6
{
  "total_count": 2,
  "actions_caches": [
    {
      "id": 310,
      "ref": "refs/heads/master",
      "key": "Linux-pip-3.6",
      "version": "bceda5fc9790311ca62ca27a213556fe42fbb764a6135a3ce6521f9e2ab44b90",
      "last_accessed_at": "2022-09-09T14:35:19.720000000Z",
      "created_at": "2022-03-07T07:57:56.790000000Z",
      "size_in_bytes": 9015617
    },
    {
      "id": 400,
      "ref": "refs/heads/config-with-c-code",
      "key": "Linux-pip-3.6",
      "version": "bceda5fc9790311ca62ca27a213556fe42fbb764a6135a3ce6521f9e2ab44b90",
      "last_accessed_at": "2022-09-10T09:24:43.236666700Z",
      "created_at": "2022-09-09T14:38:16.660000000Z",
      "size_in_bytes": 35578473
    }
  ]
}

oh, isn't this nice -- the caches are shared between master builds (with -Ofast) and this branch (no -Ofast).

[mgedmin]

The Linux-pip-3.5 cache also has a

../../../.cache/pip/wheels/26/eb/0c/413ef3f3b51eac5046ef623fab8d71f429297aefda870af4f8/zope.interface-5.4.0-cp311-cp311-linux_x86_64.whl

How do these 3.11 wheels get into the wrong caches? Does anyone have any ideas?

[mgedmin]

Linux-pip-3.7 has

../../../.cache/pip/wheels/26/eb/0c/413ef3f3b51eac5046ef623fab8d71f429297aefda870af4f8/zope.interface-5.4.0-cp311-cp311-linux_x86_64.whl

[mgedmin]

I wiped all the caches from Linux-pip-3.5 through Linux-pip-3.10, just in case. I now expect to find more CPython 3.11 wheels inside pypy caches. I would clear them too, if I remembered how the names are constructed, or if I could be bothered to look up the GitHub API for listing available cache keys.

[mgedmin]

Yay the 2.7 cache also has a

../../../.cache/pip/wheels/26/eb/0c/413ef3f3b51eac5046ef623fab8d71f429297aefda870af4f8/zope.interface-5.4.0-cp311-cp311-linux_x86_64.whl

[mgedmin]

Yay it ran out of caches and finally built without poison.

[icemac]

@mgedmin Should this PR get a change log entry?

[mgedmin]

@mgedmin Should this PR get a change log entry?

Why not? I'll add one.