Bug#1133134: haskell-concurrent-extra FTBFs on ppc64el

[Trupti]

Hi Adrian,

On 2026-04-15 15:55, Adrian Bunk wrote:
> 
> Confirmed on the porterbox.
> 

  Thank you for the confirmation.

> Either the issue got fixed, or this is due to buildd differences:
> https://buildd.debian.org/status/logs.php?pkg=haskell-concurrent-extra&arch=ppc64el
> 
> My guess (that could be wrong) would be buildd differences,
> but I do not know how the conova and osuosl buildd differ.
> 

I compared both buildd machine information and build environment. Both 
are having same P9 processor and
same build environment with kernel version ( Kernel: Linux 
6.12.74+deb13+1-powerpc64le).

The only failing test is `stressTest` in `ReadWriteLock`. It is also 
failing on hurd-amd64 and hurd-i386.
(https://buildd.debian.org/status/fetch.php?pkg=haskell-concurrent-extra&arch=hurd-amd64&ver=0.7.0.12-5%2Bb2&stamp=1775183916&raw=0
https://buildd.debian.org/status/fetch.php?pkg=haskell-concurrent-extra&arch=hurd-i386&ver=0.7.0.12-5&stamp=1768150785&raw=0 
)


Below is the stressTest code:

stressTest :: Assertion
stressTest = assert $ within (1000 * a_moment) $ do
   lock <- RWLock.new

   let randomDelay hi = randomRIO (0, hi) >>= threadDelay

       reader = replicateM_ 500 $ do
         randomDelay 100
         RWLock.withRead lock $ randomDelay 10

       writer = replicateM_ 500 $ do
         randomDelay 100
         RWLock.withWrite lock $ randomDelay 10

   runConcurrently $ sequenceA_ $ map Concurrently $
     replicate 10 reader ++ replicate 10 writer




I noticed the test has a hardcoded timeout value `within (1000 * 
a_moment)`.
This could be the reason for the failure on these architectures.

Would it make sense to relax the timeout or make it 
architecture-dependent, or do you have other suggestions?


Thanks
Trupti