Source: ncurses Version: 6.1+20180210-4 User: helm...@debian.org Usertags: rebootstrap Tags: unreproducible
Hi Sven, Since very recently, I see a weird build failure for ncurses. I guess that it is related to Ben's make-dfsg upload, but I cannot tell for sure yet. Unfortunately, I lost the relevant build logs, but let me try to give you as much data as I still have. Thus far, I've seen the failure twice. The linker complains about a truncated libmenuw.so. Presumably it happens during the objdir-test build and linking libmenuw.so appears to happen concurrently. Settings that reproduced the issue: * cross build for m68k * DEB_BUILD_OPTIONS="nocheck noddebs parallel=9" * DEB_BUILD_PROFILES=nobiarch (shouldn't matter for m68k) * Everything on tmpfs. * SCHED_BATCH If I set parallel=1 in the very same (rebootstrap) setting, I cannot reproduce it. Since jenkins.d.n sets parallel=1, you cannot see it there at all. I then tried reproducing it outside rebootstrap using sbuild, but no matter what I tried, I couldn't reproduce it there. Turning parallel up or down didn't help, but I don't know how reliable the issue is. During my testing, I once ran into a native, parallel build that hung. In the hung state, there were two make processes each consuming CPU indefinitely. Attaching to them with strace indicated that they weren't doing any syscalls. I somewhat suspect that there is no failure on ncurses' side, but the make-dfsg side is broken, but I cannot prove that suspicion. So what can I do? I think documenting the symptoms with this bug is vaguely useful. I suggest leaving the bug open for maybe two weeks to accumulate more detail (if any). If it turns out that nobody else can reproduce parallel build failures, the bug should be closed. Hope this vague report helps. If not, please do close it. Helmut
