Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tumbleweed-aarch64 .venv build fails on gevent wheel #2693

Closed
phillxnet opened this issue Oct 11, 2023 · 13 comments
Closed

Tumbleweed-aarch64 .venv build fails on gevent wheel #2693

phillxnet opened this issue Oct 11, 2023 · 13 comments
Milestone
Py3.11

Comments

@phillxnet
Copy link
Member

When building for all OS targets & architectures (Leap 15.4/15.5 & TW) for PR:"Update Python dependency to 3.9 #2691" #2692 we have a single rpmbuild failure in our % check only on aarch64.

From a manual source build of the same PR specific code branch we have the following partial .venv:

The currently activated Python version 3.10.13 is not supported by the project (~3.9).
Trying to find and use a compatible version. 
Using python3.9 (3.9.18)
Creating virtualenv rockstor in /opt/rockstor/.venv
Installing dependencies from lock file

Package operations: 31 installs, 0 updates, 0 removals

  • Installing certifi (2023.7.22)
  • Installing charset-normalizer (2.0.12)
  • Installing greenlet (3.0.0)
  • Installing idna (3.4)
  • Installing pytz (2023.3.post1)
  • Installing six (1.16.0)
  • Installing sqlparse (0.4.4)
  • Installing urllib3 (1.26.17)
  • Installing zope.event (5.0)
  • Installing zope.interface (6.1)
  • Installing django (2.2.28)
  • Installing gevent (23.9.1)
  • Installing oauthlib (3.1.0)
  • Installing requests (2.27.1)
  • Installing python-engineio (2.3.2)

  EnvCommandError

  Command ['/opt/rockstor/.venv/bin/pip', 'install', '--no-deps', 'file:///root/.cache/pypoetry/artifacts/a2/0a/a9/fdd317f6f3693a9c7e
f63669ea4d4133b4b5489d5f555a2ce0ce62218b/gevent-23.9.1.tar.gz'] errored with the following return code 1, and output: 
  Processing /root/.cache/pypoetry/artifacts/a2/0a/a9/fdd317f6f3693a9c7ef63669ea4d4133b4b5489d5f555a2ce0ce62218b/gevent-23.9.1.tar.gz
    Installing build dependencies: started
    Installing build dependencies: finished with status 'done'
    Getting requirements to build wheel: started
    Getting requirements to build wheel: finished with status 'done'
    Installing backend dependencies: started
    Installing backend dependencies: finished with status 'done'
    Preparing metadata (pyproject.toml): started
    Preparing metadata (pyproject.toml): finished with status 'done'
  Building wheels for collected packages: gevent
    Building wheel for gevent (pyproject.toml): started
    Building wheel for gevent (pyproject.toml): still running...
    Building wheel for gevent (pyproject.toml): finished with status 'error'
    error: subprocess-exited-with-error

× Building wheel for gevent (pyproject.toml) did not run successfully.
    │ exit code: 1
    ╰─> [1569 lines of output]
        running bdist_wheel
        running build
        running build_py
        creating build
        creating build/lib.linux-aarch64-cpython-39
        creating build/lib.linux-aarch64-cpython-39/gevent
        copying src/gevent/__init__.py -> build/lib.linux-aarch64-cpython-39/gevent
        copying src/gevent/_abstract_linkable.py -> build/lib.linux-aarch64-cpython-39/gevent
        copying src/gevent/_compat.py -> build/lib.linux-aarch64-cpython-39/gevent
...
copying src/gevent/tests/tests_that_dont_use_resolver.txt -> build/lib.linux-aarch64-cpython-39/gevent/tests
        copying src/gevent/tests/server.key -> build/lib.linux-aarch64-cpython-39/gevent/tests
        copying src/gevent/tests/test_server.key -> build/lib.linux-aarch64-cpython-39/gevent/tests
        running build_ext
        generating cffi module 'build/temp.linux-aarch64-cpython-39/gevent.libuv._corecffi.c'
        creating build/temp.linux-aarch64-cpython-39
        Running '(cd  "/tmp/pip-req-build-cik2krfd/deps/libev"  && sh ./configure -C > configure-output.txt )' in /tmp/pip-req-build-cik2krfd
        generating cffi module 'build/temp.linux-aarch64-cpython-39/gevent.libev._corecffi.c'
        Not configuring libev, 'config.h' already exists
        Not configuring libev, 'config.h' already exists
        building 'gevent.libev.corecext' extension
        creating build/temp.linux-aarch64-cpython-39/src
        creating build/temp.linux-aarch64-cpython-39/src/gevent
        creating build/temp.linux-aarch64-cpython-39/src/gevent/libev
        gcc -Wno-unused-result -Wsign-compare -DNDEBUG -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -DOPENSSL_LOAD_CONF -fwrapv -fno-semantic-interposition -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -fPIC -DLIBEV_EMBED=1 -DEV_COMMON= -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -DEV_USE_REALTIME=1 -DEV_USE_MONOTONIC=1 -DEV_USE_FLOOR=1 -Isrc/gevent/libev -I/usr/include/python3.9 -I/tmp/pip-req-build-cik2krfd/deps -I/tmp/pip-req-build-cik2krfd/src/gevent/libev -I/tmp/pip-req-build-cik2krfd/deps/libev -Isrc/gevent -Isrc/gevent/libev -Isrc/gevent/resolver -I. -I/opt/rockstor/.venv/include -I/usr/include/python3.9 -c src/gevent/libev/callbacks.c -o build/temp.linux-aarch64-cpython-39/src/gevent/libev/callbacks.o
        gcc -Wno-unused-result -Wsign-compare -DNDEBUG -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -DOPENSSL_LOAD_CONF -fwrapv -fno-semantic-interposition -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -IVendor/ -fPIC -DLIBEV_EMBED=1 -DEV_COMMON= -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -DEV_USE_REALTIME=1 -DEV_USE_MONOTONIC=1 -DEV_USE_FLOOR=1 -Isrc/gevent/libev -I/usr/include/python3.9 -I/tmp/pip-req-build-cik2krfd/deps -I/tmp/pip-req-build-cik2krfd/src/gevent/libev -I/tmp/pip-req-build-cik2krfd/deps/libev -Isrc/gevent -Isrc/gevent/libev -Isrc/gevent/resolver -I. -I/opt/rockstor/.venv/include -I/usr/include/python3.9 -c src/gevent/libev/corecext.c -o build/temp.linux-aarch64-cpython-39/src/gevent/libev/corecext.o
...

 In file included from src/gevent/libev/libev.h:9,
                         from src/gevent/libev/corecext.c:1272:
        /tmp/pip-req-build-cik2krfd/deps/libev/ev.c:580:48: warning: "/*" within comment [-Wcomment]
          580 | /*#define MIN_INTERVAL  0.00000095367431640625 /* 1/2**20, good till 2200 */
              |
        /tmp/pip-req-build-cik2krfd/deps/libev/ev.c: In function ‘ecb_binary32_to_binary16’:
        /tmp/pip-req-build-cik2krfd/deps/libev/ev.c:1517:13: warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare]
         1517 |       if (e < (14 - 24)) /* might not be sharp, but is good enough */
              |             ^
        /tmp/pip-req-build-cik2krfd/deps/libev/ev.c: At top level:

... yet more warnings

/tmp/pip-req-build-cik2krfd/deps/libev/ev_iouring.c:300:1: error: no return statement in function returning non-void [-Werror=return-type]
          300 | }
              | ^
        /tmp/pip-req-build-cik2krfd/deps/libev/ev_iouring.c: In function ‘iouring_internal_destroy’:
        /tmp/pip-req-build-cik2krfd/deps/libev/ev.h:727:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
          727 | #define ev_is_active(ev)                     (0 + ((ev_watcher *)(void *)(ev))->active) /* ro, true when the watcher has been started */
              |                                                   ~^~~~~~~~~~~~~~~~~~~~~~~~~~~
        /tmp/pip-req-build-cik2krfd/deps/libev/ev_iouring.c:326:7: note: in expansion of macro ‘ev_is_active’
          326 |   if (ev_is_active (&iouring_tfd_w))
              |       ^~~~~~~~~~~~
        /tmp/pip-req-build-cik2krfd/deps/libev/ev_iouring.c:331:1: error: no return statement in function returning non-void [-Werror=return-type]
          331 | }
              | ^

        src/gevent/libev/corecext.c:20148:3: note: in expansion of macro ‘ev_stat_init’
        20148 |   ev_stat_init((&__pyx_v_self->_watcher), ((void *)gevent_callback_stat), ((char *)__pyx_t_8), __pyx_v_interval);
              |   ^~~~~~~~~~~~
        cc1: some warnings being treated as errors
        error: command '/usr/bin/gcc' failed with exit code 1
        [end of output]
    
    note: This error originates from a subprocess, and is likely not a problem with pip.
    ERROR: Failed building wheel for gevent
  Failed to build gevent

We then have the following which is assumed to be from our Poetry running under our default system Python of Py3.10:

 ERROR: Could not build wheels for gevent, which is required to install pyproject.toml-based projects
  
  [notice] A new release of pip is available: 23.0.1 -> 23.2.1
  [notice] To update, run: pip install --upgrade pip
  

  at ~/.local/share/pypoetry/venv/lib64/python3.10/site-packages/poetry/utils/env.py:1195 in _run
      1191│                 output = subprocess.check_output(
      1192│                     cmd, stderr=subprocess.STDOUT, **kwargs
      1193│                 )
      1194│         except CalledProcessError as e:
    → 1195│             raise EnvCommandError(e, input=input_)
      1196│ 
      1197│         return decode(output)
      1198│ 
      1199│     def execute(self, bin, *args, **kwargs):
@phillxnet
Copy link
Member Author

It is assumed that pre-built wheels are available for all our other OS & arch targets; and so we do not see this same failure as not wheel build is then required.

@phillxnet
Copy link
Member Author

Pinning gevent in pyproject.toml to 23.9.0 and updating dependencies results in:

rtumbleweed-aarch64:/opt/rockstor # poetry update
Updating dependencies
Resolving dependencies... (15.7s)

Writing lock file

Package operations: 31 installs, 0 updates, 0 removals

  • Installing certifi (2023.7.22)
  • Installing charset-normalizer (2.0.12)
  • Installing greenlet (3.0.0)
  • Installing idna (3.4)
  • Installing pytz (2023.3.post1)
  • Installing six (1.16.0)
  • Installing sqlparse (0.4.4)
  • Installing urllib3 (1.26.17)
  • Installing zope.event (5.0)
  • Installing zope.interface (6.1)
  • Installing django (2.2.28)
  • Installing gevent (23.9.0): Failed

  RuntimeError

  Unable to find installation candidates for gevent (23.9.0)

  at ~/.local/share/pypoetry/venv/lib64/python3.10/site-packages/poetry/installation/chooser.py:72 in choose_for
       68│ 
       69│             links.append(link)
       70│ 
       71│         if not links:
    →  72│             raise RuntimeError(
       73│                 "Unable to find installation candidates for {}".format(package)
       74│             )
       75│ 
       76│         # Get the best link

  • Installing oauthlib (3.1.0)
  • Installing python-engineio (2.3.2)
  • Installing requests (2.27.1)

So there is no 23.9.0 released.

@phillxnet
Copy link
Member Author

Repeating last comment but for 23.9.0.post1 https://pypi.org/project/gevent/23.9.0.post1/ resulted in what looks like the same failure we had originally.

@phillxnet
Copy link
Member Author

Thanks to @FroggyFlox for assisting with this issue re:
https://pypi.org/project/gevent/ for both gevent 23.9.0.post1 & the very latest of gevent 23.9.1

This version of gevent is also tested on on PyPy 3.10 (7.3.12); it should run on PyPy 3.9 and above. On PyPy, there are no external dependencies.

But we also have:

This version of gevent runs on Python 3.8 and up, ...

And we have an embeded / vendored c library our our apparent failure so we may also just have availability of pre-build wheels variation per arch/Python version and are unable to build ourselves when one is not found due to TW compiler version or related.

The most recent attempt to poetry update with Py3.10 (in pyproject.toml) does manage to install the latest gevent:

poetry update
Creating virtualenv rockstor in /opt/rockstor/.venv
Updating dependencies
Resolving dependencies... (1.1s)

Writing lock file

Package operations: 31 installs, 0 updates, 0 removals

  • Installing certifi (2023.7.22)
  • Installing charset-normalizer (2.0.12)
  • Installing greenlet (3.0.0)
  • Installing idna (3.4)
  • Installing pytz (2023.3.post1)
  • Installing six (1.16.0)
  • Installing sqlparse (0.4.4)
  • Installing urllib3 (1.26.17)
  • Installing zope.event (5.0)
  • Installing zope.interface (6.1)
  • Installing django (2.2.28)
  • Installing gevent (23.9.1)
  • Installing oauthlib (3.1.0)
  • Installing python-engineio (2.3.2)
  • Installing requests (2.27.1)
  • Installing dbus-python (1.2.18)
  • Installing distro (1.8.0)
  • Installing django-braces (1.13.0)
  • Installing django-oauth-toolkit (1.1.2)
  • Installing django-pipeline (1.7.0)
  • Installing djangorestframework (3.9.3)
  • Installing gevent-websocket (0.10.1)
  • Installing gunicorn (19.10.0)
  • Installing huey (2.3.0)
  • Installing psutil (5.9.4)
  • Installing psycogreen (1.0)
  • Installing psycopg2 (2.8.6)
  • Installing python-socketio (1.6.0)
  • Installing pyzmq (19.0.2)
  • Installing supervisor (4.2.4)
  • Installing urlobject (2.1.1)

However we cant' change our pyproject.toml just for one arch and in just TW. So we may have to forgo the TW-aarch target for the time being: at least until we can do our next Python update which will likely be after we do our next Django update to 3.2 given Py3.9 is latest compatible with Django 2.2.

@phillxnet
Copy link
Member Author

N.B. the only difference in the resulting poetry.lock from our pyproject at (Py3.9), as per linked draft PR, and post (py3.10) experiment, was the Python version and checksum. So it does not look like any more wheels were created and made available in the interim.

@phillxnet phillxnet mentioned this issue Oct 11, 2023
Merged
@phillxnet
Copy link
Member Author

Linking to the Wheel info fro our successful Py3.10 experiment:

rtumbleweed-aarch64:/opt/rockstor #  cat /opt/rockstor/.venv/lib64/python3.10/site-packages/gevent-23.9.1.dist-info/WHEEL
Wheel-Version: 1.0
Generator: bdist_wheel (0.41.2)
Root-Is-Purelib: false
Tag: cp310-cp310-manylinux_2_17_aarch64
Tag: cp310-cp310-manylinux2014_aarch64

And by way of comparison with our amd64 arch where on Py3.9 we did not have the issue detailed here:

rtumbleweed:/opt/rockstor # cat /opt/rockstor/.venv/lib64/python3.9/site-packages/gevent-23.9.1.dist-info/WHEEL
Wheel-Version: 1.0
Generator: bdist_wheel (0.41.2)
Root-Is-Purelib: false
Tag: cp39-cp39-manylinux_2_28_x86_64

@Hooverdan96
Copy link
Member

Hooverdan96 commented Oct 11, 2023 •
edited
Loading

Do you have to worry about this note on the arm64 wheels/binaries for gevent in general?

https://pypi.org/project/gevent/ (highlight is mine)

Beginning with gevent 20.12.0, 64-bit ARM binaries are distributed on PyPI for aarch64 manylinux2014 compatible systems. Installing these needs a very recent version of pip. These wheels do not contain the c-ares resolver, are not tested, and are built with very low levels of optimizations. Serious production users of gevent on 64-bit ARM systems are encouraged to build their own binary wheels.

Beginning with gevent 22.10.0, ppc64le binaries are distributed on PyPI. The same caveats apply as for 64-bit ARM binaries. Using them for anything other than local development is discouraged.

Beginning with gevent 23, muslinux aarch64 and S390X binaries are distributed on PyPI. The same caveats apply as for 64-bit ARM binaries. Using them for anything other than local development is discouraged.

@phillxnet
Copy link
Member Author

@Hooverdan96 Thanks, nice find.
Re:

Do you have to worry about this note on the arm64 wheels/binaries for gevent in general?

We are to remove our dependency on gevent all-together in the mid term so I think we will be OK. But for the time being I'm just trying to nudge as many dependencies along as I can, wise to trying to keep our Py and Django mostly happy. Nearly there however.

Just a few stragglers to tend to and we can approach some simplification hopefully. And we also need to be moving towards the next stable fairly soon. Bit of a juggle however.

@phillxnet
Copy link
Member Author

@Hooverdan96 & @FroggyFlox
Re the following from the @Hooverdan96 find:

Beginning with gevent 20.12.0, 64-bit ARM binaries are distributed on PyPI for aarch64 manylinux2014 compatible systems. Installing these needs a very recent version of pip.

Maybe we are suffering for our now aeging Poetry here. Just noting for future reference as I'm not entirely sure of this detail as it goes; re the venv creation etc. But at least once we have our newer Python in-play we can look to a Poetry update: but that will have all of it's own challenges I suspect. And will likely have to be within our rpm scriptlets. But that is for another issue and repository.

@phillxnet phillxnet mentioned this issue Oct 11, 2023
Merged
@Hooverdan96
Copy link
Member

ok, sounds good. Then (while I asked in the other thread) for completeness sake, reading this:

https://www.gevent.org/install.html

There are a number of additional libraries that extend gevent’s functionality and will be used if they are available. All of these may be installed using setuptools extras, as named below, e.g., pip install gevent[events].

events
In versions of gevent up to and including 20.5.0, this provided configurable event support using zope.event and was highly recommended.

Since I don't think we've been using this "extra" anywhere in previous versions of gevent during the install., not sure whether it is indeed needed ... but probably no need to to question this further at this time, since, like you said we will likely remove a reliance on this entirely ... anyway that statement above in the documents does not make it clear to me whether that is included as a default requirement now or not.

@phillxnet
Copy link
Member Author

From our incoming poetry.lock file for the linked Py3.9 move we have the following available pre-compiled wheels:

    {file = "gevent-23.9.1-cp39-cp39-macosx_11_0_universal2.whl", hash = "sha256:bf456bd6b992eb0e1e869e2fd0caf817f0253e55ca7977fd0e72d0336a8c1c6a"},
    {file = "gevent-23.9.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:43daf68496c03a35287b8b617f9f91e0e7c0d042aebcc060cadc3f049aadd653"},
    {file = "gevent-23.9.1-cp39-cp39-manylinux_2_28_x86_64.whl", hash = "sha256:7c28e38dcde327c217fdafb9d5d17d3e772f636f35df15ffae2d933a5587addd"},
    {file = "gevent-23.9.1-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:fae8d5b5b8fa2a8f63b39f5447168b02db10c888a3e387ed7af2bd1b8612e543"},
    {file = "gevent-23.9.1-cp39-cp39-win32.whl", hash = "sha256:2c7b5c9912378e5f5ccf180d1fdb1e83f42b71823483066eddbe10ef1a2fcaa2"},
    {file = "gevent-23.9.1-cp39-cp39-win_amd64.whl", hash = "sha256:a2898b7048771917d85a1d548fd378e8a7b2ca963db8e17c6d90c76b495e0e2b"},

Hence having to build our own on this Py/linux/arch target - and failing for some compatibility reason.

Likewise the same incoming poetry.lock has what we end up getting in the above proof of concept Py3.10 experiment:

    {file = "gevent-23.9.1-cp310-cp310-macosx_11_0_universal2.whl", hash = "sha256:a3c5e9b1f766a7a64833334a18539a362fb563f6c4682f9634dea72cbe24f771"},
    {file = "gevent-23.9.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:b101086f109168b23fa3586fccd1133494bdb97f86920a24dc0b23984dc30b69"},
    {file = "gevent-23.9.1-cp310-cp310-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:36a549d632c14684bcbbd3014a6ce2666c5f2a500f34d58d32df6c9ea38b6535"},
    {file = "gevent-23.9.1-cp310-cp310-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:272cffdf535978d59c38ed837916dfd2b5d193be1e9e5dcc60a5f4d5025dd98a"},
    {file = "gevent-23.9.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:dcb8612787a7f4626aa881ff15ff25439561a429f5b303048f0fca8a1c781c39"},
    {file = "gevent-23.9.1-cp310-cp310-manylinux_2_28_x86_64.whl", hash = "sha256:d57737860bfc332b9b5aa438963986afe90f49645f6e053140cfa0fa1bdae1ae"},
    {file = "gevent-23.9.1-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:5f3c781c84794926d853d6fb58554dc0dcc800ba25c41d42f6959c344b4db5a6"},
    {file = "gevent-23.9.1-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:dbb22a9bbd6a13e925815ce70b940d1578dbe5d4013f20d23e8a11eddf8d14a7"},
    {file = "gevent-23.9.1-cp310-cp310-win_amd64.whl", hash = "sha256:707904027d7130ff3e59ea387dddceedb133cc742b00b3ffe696d567147a9c9e"},

So all-in this should be resolved in time as we progress with our dependency updates (technical dept).

@phillxnet phillxnet added this to the Py3.10 milestone Oct 12, 2023
@phillxnet phillxnet mentioned this issue Nov 8, 2023
Closed
@phillxnet
Copy link
Member Author

until we can do our next Python update which will likely be after we do our next Django update to 3.2 given Py3.9 is latest compatible with Django 2.2.

As per the last linked PR (a Django 3.2 LTS update) we are additionally now using Django 4.2 LTS (#2752), so the remaining issue to re-gain TW aarch64 target compatibility is a Python update to at least Py3.10 give a tentative experiment in the comments here indicated a wheel available for that Python version and up.

@phillxnet phillxnet mentioned this issue Nov 24, 2023
Merged
phillxnet added a commit that referenced this issue Nov 24, 2023
@phillxnet
Merge pull request #2755 from phillxnet/2703-Update-Poetry-build-system
281d270 
Update Poetry build system & normalise on Python 3.11 #2703 #2754 #2693
@phillxnet
Copy link
Member Author

Closing as:
Fixed by #2755

@phillxnet phillxnet mentioned this issue Nov 24, 2023
Closed
This was referenced Jan 22, 2024
Closed
Merged
@phillxnet phillxnet mentioned this issue Apr 18, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Py3.11
Development

No branches or pull requests
2 participants
@phillxnet @Hooverdan96