It has been building on and off, more off than on:
https://ci.guix.gnu.org/build/22527477/details
Last release in 2018.
There are 35 dependents, mainly elm-*.
Removal, dropping of failing tests, or other repair? @guix/haskell
It has been building on and off, more off than on:
https://ci.guix.gnu.org/build/22527477/details
Last release in 2018.
There are 35 dependents, mainly elm-*.
Removal, dropping of failing tests, or other repair? @guix/haskell
Hm, I have it in my store... Maybe flaky tests? So I am just closing this.
guix weather finds it on CI, whereas the CI dashboard shows it as failed; a bit mysterious.
If the problem persists, we could disable the tests of its only dependent ghc-threads and remove its native inputs; this would unblock the 35 dependents (I had just tested this route).
I'm hitting it on misc-world-rebuild as well, and guix build --check ghc-concurrent-extra on master fails for me rather consistently.
I could just build it with --check on master!
Could it be microarch-dependent? I have yet to achieve a single successful build on neither Ryzen 3700X or 5600. Edit: it builds consistently on an EPYC 9754 however.
The issue is tracked here and has been around since 2015. It might be a good idea to skip ReadWriteLock.stressTest.
Last commit 8 years ago... Maybe we should indeed remove the package instead of repairing it?
Personally I'm indifferent to either decision.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?