Hi, Am Montag, den 17.06.2013, 00:44 +0100 schrieb Colin Watson: > * There are several build failures on s390x, generally presenting as a > hung build terminated after a timeout, such as ghc itself [1]. > These started when packages started building with ghc 7.6 as a > build-dependency rather than 7.4. This is quite easy to reproduce > on the porter box (zelenka), and it looks as though the runtime > occasionally deadlocks when a subprocess exits; the strace looks > like this: > > 7523 exit_group(0) = ? > 6680 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) > 6680 --- SIGCHLD (Child exited) @ 0 (0) --- > 6680 futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS (To be restarted) > 6680 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > 6680 sigreturn() = ? (mask now []) > 6680 futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS (To be restarted) > 6680 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > 6680 sigreturn() = ? (mask now []) > 6680 futex(0x84fa86ac, FUTEX_WAIT_PRIVATE, 1143, NULL) = ? ERESTARTSYS (To be restarted) > [repeats forever] > > ghc spawns enough subprocesses (gcc etc.) that it's essentially > bound to hit this sooner or later. I suspect perhaps a lack of > signal-safety somewhere - at an extremely wild guess, perhaps the > type of an important variable written in a signal handler happens to > exceed the size of sig_atomic_t on s390x and not elsewhere - but I > haven't yet been able to track this down in the time available to > me. It doesn't help that the nature of the bug is such that I can't > easily build any changes to ghc (and indeed even if we can fix this > bug we'll probably need to rebootstrap manually with 7.4), although > I'll try to build something in a wheezy chroot. > > The hashtables build failure [2] may be the same; I'm not sure. > > Perhaps somebody more fluent in Haskell than I could come up with a > test case that exercises this and is somewhat simpler than "build > ghc". If my analysis is at all close to the mark, then something > that sits in a loop forking and reaping a trivial child process on > each iteration should be enough to reproduce this. I think this should be escalated to GHC, they know their code better and maybe your analysis is enough to make them say „ah, right, that part of the code is fishy, try this patch“. (I guess I am overly optimistic.) > * hakyll requires QuickCheck < 2.6 for its test suite. Fixed; I was just waiting for some rebuilds. > * hxt-relaxng fails to build on mipsel [3] and s390 [4], with what > looks like an out-of-memory failure. There are no > reverse-dependencies; remove? I gave them back, just to confirm that this is reproducible (and hoping that another buildd can cope with it). If it does not work: Removing is the only option. > * lens fails to build on kfreebsd-i386 [5]; I filed an upstream bug > [6]. Should I just temporarily disable the tests on that > architecture along with hurd-i386 where it also fails, or perhaps > just disable that one test on all architectures since it's clearly > unreliable? Yes, removing the test is the easiest here. BTW, it fails on sparc due to -N missing: https://buildd.debian.org/status/fetch.php?pkg=haskell-lens&arch=sparc&ver=3.9.0.2-2&stamp=1371444377 I guess we can simply disable the tests here as well. > * openpgp-asciiarmor hits an ICE on mipsel [7]. Removal would take > out hopenpgp as well but is otherwise not too horrible. However, > since this succeeds on the porter box (with a slightly newer version > of GCC), I'm going to ask for a give-back first. It worked now. > * helium is broken across the board, and needs porting to the new > exception model [8]. This does not affect the transition. The file is already horribly patched: http://patch-tracker.debian.org/package/helium/1.7~pre20090428-4 I’ll ask upstream about the maintenance state, if they have no working (pre-)release in a reasonable time we should remove the package. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part