Maneage - Bugs: bug #61271, Python build bug with curses.h in...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61271: Python build bug with curses.h in commit 775fc03
Submitter: | Boud Roukema <boud> | ||
Submitted: | Sun 03 Oct 2021 08:22:43 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | Works For Me |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Wed 21 Sep 2022 05:05:38 PM UTC, comment #4: |
Boud Roukema <boud>![]() |
Sun 09 Jan 2022 01:38:58 PM UTC, comment #3:
|
Boud Roukema <boud>![]() |
Sat 08 Jan 2022 11:40:04 PM UTC, comment #2: Thanks for the good bug report Boud!
During your test builds of Python 3.10 (as part of
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sun 03 Oct 2021 08:22:43 PM UTC, comment #1: This item has been reassigned from the project Maneage task tracker to your tracker. The original report is still available at task #16051 Following are the information included in the original report: [field #0] Item ID: 16051 SYSTEM DETAILS:
LOG:
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:
The python management system itself seems to consider the build successful:
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:
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.
|
Boud Roukema <boud>![]() |
Sun 03 Oct 2021 08:22:43 PM UTC, original submission:
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:
LOG:
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:
The python management system itself seems to consider the build successful:
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:
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.
|
Boud Roukema <boud>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-09-21 | boud | Status | None | ![]() |
Works For Me |
2021-10-03 | boud | Reassign item | Maneage, task #16051 | ![]() |
Maneage, bug #61271 |
DESCRIPTION: ncurses header files are typically provided in several major systems (Debian) directly in /usr/include . The 'configure' of python-3.10.6, for commit 4318670 of core maneage, still had fatal errors because it couldn't find either ncurses.h or curses.h in either the Maneage include/ directory or the host OS /usr/include .
EXAMPLE LOG:
SUGGESTED FIX:
Commit 7286ad6 on branch 'fix_ncurses_for_python' [1] works for me. It adds the two lines
to the 'ncurses' build rules in 'basic.mk'.
[1] https://codeberg.org/boud/maneage_dev/commit/7286ad62014acaa8c46504493040c5acba7bd535