Bug 2341189 - python-pynn: FTBFS in Fedora rawhide/f42
Summary: python-pynn: FTBFS in Fedora rawhide/f42
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-pynn
Version: 42
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ankur Sinha (FranciscoD)
QA Contact:
URL:
Whiteboard:
Depends On: 2333833 2340926
Blocks: F42FTBFS 2343507
TreeView+ depends on / blocked
 
Reported: 2025-01-22 21:38 UTC by Fedora Release Engineering
Modified: 2025-04-13 04:17 UTC (History)
3 users (show)

Fixed In Version: python-pynn-0.12.4-2.fc42
Clone Of:
Environment:
Last Closed: 2025-04-13 04:17:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (32.00 KB, text/plain)
2025-01-22 21:38 UTC, Fedora Release Engineering
no flags Details
root.log (32.00 KB, text/plain)
2025-01-22 21:38 UTC, Fedora Release Engineering
no flags Details
state.log (1.66 KB, text/plain)
2025-01-22 21:38 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2025-01-22 21:38:04 UTC
python-pynn failed to build from source in Fedora rawhide/f42

https://koji.fedoraproject.org/koji/taskinfo?taskID=128089342


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild
Please fix python-pynn at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
python-pynn will be orphaned. Before branching of Fedora 43,
python-pynn will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Comment 1 Fedora Release Engineering 2025-01-22 21:38:07 UTC
Created attachment 2072087 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2025-01-22 21:38:08 UTC
Created attachment 2072088 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2025-01-22 21:38:10 UTC
Created attachment 2072089 [details]
state.log

Comment 4 Ben Beasley 2025-01-27 13:54:47 UTC
I see:

In file included from /usr/include/section.h:37,
                 from adexp.c:11:
adexp.c:42:25: error: conflicting types for ‘hoc_getarg’; have ‘double *(void)’
   42 |          extern double *getarg();
      |                         ^~~~~~
In file included from /usr/include/section.h:37,
                 from alphaisyn.c:11:
alphaisyn.c:41:25: error: conflicting types for ‘hoc_getarg’; have ‘double *(void)’
   41 |          extern double *getarg();
      |                         ^~~~~~
/usr/include/oc_ansi.h:49:16: note: previous declaration of ‘hoc_getarg’ with type ‘double *(int)’
   49 | extern double* getarg(int);
      |                ^~~~~~
/usr/include/oc_ansi.h:49:16: note: previous declaration of ‘hoc_getarg’ with type ‘double *(int)’
   49 | extern double* getarg(int);
      |                ^~~~~~
alphaisyn.c: In function ‘_hoc_update_queue’:
alphaisyn.c:260:50: error: too many arguments to function ‘hoc_getarg’; expected 0, have 1
  260 |  _r =  update_queue ( _p, _ppvar, _thread, _nt, *getarg(1) );
      |                                                  ^~~~~~
alphaisyn.c:41:25: note: declared here
   41 |          extern double *getarg();
      |                         ^~~~~~
alphaisyn.c: In function ‘_hoc_alpha’:
alphaisyn.c:283:43: error: too many arguments to function ‘hoc_getarg’; expected 0, have 1
  283 |  _r =  alpha ( _p, _ppvar, _thread, _nt, *getarg(1) );
      |                                           ^~~~~~
alphaisyn.c:41:25: note: declared here
   41 |          extern double *getarg();
      |                         ^~~~~~
alphaisyn.c: In function ‘_net_receive__AlphaISyn’:
alphaisyn.c:290:32: error: conflicting types for ‘hoc_object_name’; have ‘char *(void)’
  290 |   if (_tsav > t){ extern char* hoc_object_name(); hoc_execerror(hoc_object_name(_pnt->ob), ":Event arrived out of order. Must call ParallelContext.set_maxstep AFTER assigning minimum NetCon.delay");}
      |                                ^~~~~~~~~~~~~~~
In file included from /usr/include/hocdec.h:280:
/usr/include/oc_ansi.h:46:14: note: previous declaration of ‘hoc_object_name’ with type ‘char *(Object *)’
   46 | extern char* hoc_object_name(Object*);
      |              ^~~~~~~~~~~~~~~
adexp.c: In function ‘_hoc_exp_current’:
alphaisyn.c:290:65: error: too many arguments to function ‘hoc_object_name’; expected 0, have 1
  290 |   if (_tsav > t){ extern char* hoc_object_name(); hoc_execerror(hoc_object_name(_pnt->ob), ":Event arrived out of order. Must call ParallelContext.set_maxstep AFTER assigning minimum NetCon.delay");}
      |                                                                 ^~~~~~~~~~~~~~~ ~~~~~~~~
alphaisyn.c:290:32: note: declared here
  290 |   if (_tsav > t){ extern char* hoc_object_name(); hoc_execerror(hoc_object_name(_pnt->ob), ":Event arrived out of order. Must call ParallelContext.set_maxstep AFTER assigning minimum NetCon.delay");}
      |                                ^~~~~~~~~~~~~~~
adexp.c:408:49: error: too many arguments to function ‘hoc_getarg’; expected 0, have 1
  408 |  _r =  exp_current ( _p, _ppvar, _thread, _nt, *getarg(1) );
      |                                                 ^~~~~~
adexp.c:42:25: note: declared here
   42 |          extern double *getarg();
      |                         ^~~~~~

[… etc. etc. etc.]

These are GCC 15 / C23 issues, where pointers to functions-of-unspecified arguments are used interchangeably with pointers to functions-of-particular-arguments (and the same return type), but C23 treats "int foo()" as a nullary function like "int foo(void)". Most or all of the problems appear to be coming from neuron headers.

Comment 5 Aoife Moloney 2025-02-26 13:43:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

Comment 6 Fedora Update System 2025-04-08 17:04:58 UTC
FEDORA-2025-d1fa51e383 (neuron-8.2.6-2.fc42, python-netpyne-1.0.7-5.fc42, and 1 more) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1fa51e383

Comment 7 Fedora Update System 2025-04-09 02:39:45 UTC
FEDORA-2025-d1fa51e383 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-d1fa51e383`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1fa51e383

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2025-04-13 04:17:32 UTC
FEDORA-2025-d1fa51e383 (neuron-8.2.6-2.fc42, python-netpyne-1.0.7-5.fc42, and 1 more) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.