[bug #61811] jinja2 and extension-helpers packages not found in Astropy installation

[Boud Roukema]

Follow-up Comment #2, bug #61811 (project reproduce):

I tried this in two separate builds (not completely from scratch, but partly
from scratch, and both python and the python libraries were rebuilt from
scratch). Both builds were on the same many-cpu machine.


The second build, which updated many programs including gcc, compiled commit
f9c8b81 (with 'astropy' enabled in TARGETS.conf) completely, without any
errors. => irreproducible error.


The first build had a similar problem to the jinja2 and extension-helpers
bugs. => reproducible error. Compiling 'astropy' failed with fatal compile
errors of 'pyyaml':


/BUILD/software/installed/include/yaml.h:636:55: note: expected 'const
yaml_char_t *' {aka 'const unsigned char *'} but argument is of type 'char *'
  636 |         const yaml_char_t *anchor, const yaml_char_t *tag, int
implicit,
      |                                    ~~~~~~~~~~~~~~~~~~~^~~
ext/_yaml.c: In function '__pyx_tp_dealloc_5_yaml_CParser':
ext/_yaml.c:23870:5: error: lvalue required as increment operand
23870 |     ++Py_REFCNT(o);
      |     ^~
ext/_yaml.c:23872:5: error: lvalue required as decrement operand
23872 |     --Py_REFCNT(o);
      |     ^~
ext/_yaml.c: In function '__pyx_tp_dealloc_5_yaml_CEmitter':
ext/_yaml.c:24040:5: error: lvalue required as increment operand
24040 |     ++Py_REFCNT(o);
      |     ^~
ext/_yaml.c:24042:5: error: lvalue required as decrement operand
24042 |     --Py_REFCNT(o);
      |     ^~
...


This seems to imply a missing cython dependency. But pyyaml *does* depend on
cython in python.mk.

A second 'configure' gave an immediate error for compiling pyerfa:


  File "/dev/shm/maneage-maneage_project_bis-boud/pyerfa-2.0.0.1/setup.py",
line 12, in <module>
    import packaging.version
ModuleNotFoundError: No module named 'packaging'


But 'packaging' was already installed, and pyyerfa depends on 'packaging' in
python.mk.

A third 'configure' successfully installed 'astropy'.

Possible clue, though probably not the explanation: Before and after the third
configure step, I did 'find .local/ -name "*packaging*"'. Here's the
difference:


$ diff -ub find.local.name.packaging.*
--- find.local.name.packaging.1 2022-01-13 17:50:27.652452401 +0100
+++ find.local.name.packaging.2 2022-01-13 17:51:48.575848367 +0100
@@ -1,4 +1,5 @@
 .local/version-info/python/packaging-21.3
+.local/version-info/.for-check-config/packaging-21.3
 .local/lib/python3.10/site-packages/packaging-21.3-py3.10.egg
 
.local/lib/python3.10/site-packages/setuptools-58.3.0-py3.10.egg/pkg_resources/_vendor/packaging
 
.local/lib/python3.10/site-packages/setuptools-58.3.0-py3.10.egg/setuptools/_vendor/packaging


The directory '.local/version-info/.for-check-config' is created by
'./project'. While that's useful for --check-config (I assume :)), I don't see
how it can affect the rules in 'python.mk'.


This seems to me to be a semi-reproducible bug.


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?61811>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/