THIS ITEM WAS REASSIGNED TO BUG #61271
BUG: Maneage commit 775fc03 has fatal errors compiling some python modules. A second round of './project configure' leads to the Maneage system considering all packages to be compiled correctly, despite the errors declared as fatal. It is not known if the fatal errors cause problems when running python.


SYSTEM DETAILS:

• Debian GNU/Linux bullseye 11.0, i.e stable, x86_64 architecture
• Maneage commit 775fc03

LOG:
https://cosmo.torun.pl/~boud/log.20211003.1.775fc03.python.bug.bz2


EXTRACTS from the log:

This is a parallel compile, so the specific commands might be interleaved. [Using the '--debug' option doesn't seem to work fully in parallel, giving some lines printed in an interleaved way - probably some output is buffered and not rapidly synced.]

There are a few sections such as the following:

/BUILD/software/installed/bin/gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include/internal -I./Include -I. -I/BUILD/software/installed/include -I/usr/local/include -I/BUILD/software/build-tmp/Python-3.8.5/Include -I/BUILD/software/build-tmp/Python-3.8.5 -c /BUILD/software/build-tmp/Python-3.8.5/Modules/_blake2/blake2module.c -o build/temp.linux-x86_64-3.8/BUILD/software/build-tmp/Python-3.8.5/Modules/_blake2/blake2module.o
/BUILD/software/installed/bin/gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include/internal -I./Include -I. -I/BUILD/software/installed/include -I/usr/local/include -I/BUILD/software/build-tmp/Python-3.8.5/Include -I/BUILD/software/build-tmp/Python-3.8.5 -c /BUILD/software/build-tmp/Python-3.8.5/Modules/grpmodule.c -o build/temp.linux-x86_64-3.8/BUILD/software/build-tmp/Python-3.8.5/Modules/grpmodule.o
In file included from /BUILD/software/build-tmp/Python-3.8.5/Modules/_curses_panel.c:15:
./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory
   36 | #include <curses.h>
      |          ^~~~~~~~~~
compilation terminated.
In file included from /BUILD/software/build-tmp/Python-3.8.5/Modules/_cursesmodule.c:113:
./Include/py_curses.h:36:10: fatal error: curses.h: No such file or directory
   36 | #include <curses.h>
      |          ^~~~~~~~~~
compilation terminated.
building '_elementtree' extension

The python management system itself seems to consider the build successful:

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_dbm                  _gdbm                 _sqlite3
_tkinter
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd
time


Failed to build these modules:
_curses               _curses_panel


Following modules built successfully but were removed because they could not be imported:
_uuid                 nis

running build_scripts
creating build/scripts-3.8

Nevertheless, the first '.project configure' run fails. A second iteration of './project configure' runs without further interruption.

PRESENCE of curses.h:

All these are present:

.local/include/ncurses/cursesapp.h
.local/include/ncurses/cursesf.h
.local/include/ncurses/curses.h
.local/include/ncurses/cursesm.h
.local/include/ncurses/cursesp.h
.local/include/ncurses/cursesw.h
.local/include/ncurses/ncurses_dll.h
.local/include/ncurses/ncurses.h -> curses.h
.local/include/ncursesw/cursesapp.h
.local/include/ncursesw/cursesf.h
.local/include/ncursesw/curses.h
.local/include/ncursesw/cursesm.h
.local/include/ncursesw/cursesp.h
.local/include/ncursesw/cursesw.h
.local/include/ncursesw/ncurses_dll.h
.local/include/ncursesw/ncurses.h -> curses.h
.local/include/python3.8/py_curses.h

and the compilation path appears to be valid for finding 'curses.h', so the bug is puzzling.


STATUS as a bug:

So far I'm not aware of this having consequences in running python scripts. However, since we clearly have 'curses' installed as part of the basic.mk system, in principle it should be easy to solve the bug of not finding 'curses.h'.

Moreover, the build should compile in a single run, without needing a second configure round.

However, I've rated this as "3 = low" on the priority scale, since practical problems following from the bug are not (yet) known.

I see that the commented URL for python in 'reproduce/software/conf/urls.conf' is http://akhlaghi.org/src . This leads to a related issue: for URLs that have akhlaghi.org URLs alone, it would be better to include an example of the upstream URL as a comment just before/after, and any differences should be described. Even if the upstream URL risks being volatile and disappearing, in many cases these will survive in the long term so making the user's task easier would be better.