[ adding 1070...@bugs.debian.org to the loop ]
El 12/5/24 a las 7:42, Antonio Valentino escribió:
Dear Santiago,
Il 11/05/24 21:55, Debian Bug Tracking System ha scritto:
Processing control commands:
close -1 1.0~b1-5
Bug #1070950 [src:pysph] pysph: FTBFS in bullseye
Marked as fixed in versions pysph/1.0~b1-5.
Bug #1070950 [src:pysph] pysph: FTBFS in bullseye
Marked Bug as done
From a very quick look to the log excerpt IMHO it could be enough to set
`NPROCS=1` in d/rules.
But I understand that you have already solved the issue, right?
Thanks a lot for your interest.
Here is the "long explanation":
The issue happens in bullseye but not in bookworm, that's why I marked it
as closed in the bookmorm version. I've done it that way because Release
Managers
usually ask that we are strict with version tracking. This is counter-intuitive
for me, but I don't want it to be a reason for dispute.
This error is a little bit strange. I used a machine of type m6a.large
(which has 2 vCPUs) in both bullseye and bookworm, and the line NPROCS=2
is present in both bullseye and bookworm.
But it fails in bullseye and it builds ok in bookworm.
I suspect it must be an MPI artifact of some sort, but I don't know
enough about MPI to tell. If somebody helps me to debug it,
I'll gladly take care of everything else, since I joined Debian Science
precisely to deal with the bureaucracy of fixing ftbfs bugs in
oldstable and stable.
(If you volunteer, contact me privately and I can create a VM for you)
Another option is that I simply change NPROCS to 1 as you point out,
verify that it works, including machines with a single cpu, and do the
proposed-updates upload (but in this case the mystery of mpi would
remain being a mystery).
Thanks.
