Bug#1070950: Processed: pysph: FTBFS in bullseye

[Santiago Vila]

[ adding 1070950 at 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.