** Description changed: netsurf 3.11-4 fails to build from source (very often), even after several rebuild attempts. See https://launchpad.net/ubuntu/+source/netsurf/3.11-4build1 It looks like the root cause is a race condition that happens while building. + + The generated-source rules for the bison/flex grammars in libnslog and + nsgenbind write their output files directly into $(BUILDDIR), but unlike + every other rule in the netsurf-buildsystem (which is generated via the + build_c/build_cxx macros in Makefile.top) they do not depend on + $(BUILDDIR)/stamp, which is the target responsible for creating BUILDDIR + in the first place (via "mkdir -p $(BUILDDIR)"). + + Under a parallel build ("make -jN"), make is therefore free to start the + flex/bison job(s) concurrently with the job that creates BUILDDIR. If the + mkdir has not completed by the time flex (or bison) tries to fopen() its + output file, flex fails with "flex: could not create + <BUILDDIR>/filter-lexer.inc" (and analogous errors for bison), which then + cascades into "No rule to make target ... needed by ..." and a failed + build. + + This is a pre-existing race in the Makefiles that happens to be triggered + far more often on s390x buildds (likely due to different process/IO + scheduling latency under heavy parallel job load) than on other release + architectures, causing an intermittent FTBFS there. + + The fix simply adds $(BUILDDIR)/stamp as an extra prerequisite to the + flex/bison rules, exactly like every other generated-file rule already + does, guaranteeing BUILDDIR exists before flex/bison try to write into it.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166682 Title: netsurf 3.11-4 FTBFS in most cases due to a racy build To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2166682/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
