bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpecte


From: Christopher Allan Webber
Subject: bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes
Date: Fri, 03 Mar 2017 18:38:07 -0600
User-agent: mu4e 0.9.18; emacs 25.1.1

Hello!  I'm getting this error while trying to compile latest guix
master on one of my machines (fortunately, not my main one).  I don't
know why I'm hitting this error, since I'm not hitting it on my main
machine.  I'm upgrading from a few months back.

I spoke on irc and found that Ricardo had the same issue:

  <rekado> paroneayea: I also got this error trying to run “make”
  <rekado> paroneayea: it happens on my recording machine (x86_64) that hadn’t
           been updated in a while, but not on my laptop (also x86_64), which is
           updated regularly.

Here's what I do.  I start at the commit I was at
(c2662820f359be19262cdd5d564e6a0dddc43281) and run "guix environment
guix".  Then I do a "git pull && make clean && make" and I get:

  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
  ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg):
  ;;; ERROR: missing interface for module (rsvg)
  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
  ;;; Failed to autoload rsvg-handle-new-from-file in (rsvg):
  ;;; ERROR: missing interface for module (rsvg)
  ;;; Failed to autoload cairo-image-surface-create in (cairo):
  ;;; ERROR: missing interface for module (cairo)
    LOAD     (gnu build vm)
    LOAD     (gnu tests)
    LOAD     (gnu tests base)
    LOAD     (gnu tests nfs)
    LOAD     (gnu tests install)
  warning: 'waitpid' -1 failed unexpectedly: No child processes
  Backtrace:
  In ice-9/boot-9.scm:
  3088: 19 [#<procedure 4226c30 at ice-9/boot-9.scm:3069:17 ()>]
  In unknown file:
     ?: 18 [primitive-load-path "gnu/tests/install" ...]
  In ice-9/eval.scm:
   453: 17 [eval # ()]
   411: 16 [eval # #]
   387: 15 [eval # #]
   373: 14 [run-install # #]
   387: 13 [eval # #]
   387: 12 [eval # #]
   387: 11 [eval # #]
   411: 10 [eval # #]
  In srfi/srfi-1.scm:
   573: 9 [map #<procedure 360a6c0 at ice-9/eval.scm:416:20 (a)> (# # # # ...)]
  In ice-9/eval.scm:
   387: 8 [eval # #]
   411: 7 [eval # #]
   411: 6 [eval # #]
   387: 5 [eval # #]
  In unknown file:
     ?: 4 [force #<promise #<procedure 5bbf150 at ice-9/eval.scm:416:20 ()>>]
  In ice-9/eval.scm:
   411: 3 [eval # #]
   411: 2 [eval # #]
  In ice-9/popen.scm:
    98: 1 [close-process #<closed: file 0> 28701]
  In unknown file:
     ?: 0 [waitpid 28701 #<undefined>]

  ERROR: In procedure waitpid:
  ERROR: In procedure waitpid: No child processes
  make[2]: *** [Makefile:4929: make-go] Error 1
  make[2]: Leaving directory '/home/cwebber/src/guix'
  make[1]: *** [Makefile:4072: all-recursive] Error 1
  make[1]: Leaving directory '/home/cwebber/src/guix'
  make: *** [Makefile:2728: all] Error 2

This is on commit 21abf092a49f0ce80cbfff5cccabb7dbf53abf96

If instead I switch back to c2662820f359be19262cdd5d564e6a0dddc43281 I
can compile Guix again.

I did a git-bisect to find what commit was breaking things.  According
to git-bisect, the perpetrator is:

  63302a4e55241a41eab4c21d7af9fbd0d5817459 is the first bad commit
  commit 63302a4e55241a41eab4c21d7af9fbd0d5817459
  Author: Ludovic Courtès <address@hidden>
  Date:   Mon Feb 6 23:47:09 2017 +0100

      Add (gnu build shepherd).

      * gnu/build/shepherd.scm: New file.
      * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

  :040000 040000 7a07b30ebec719aca2fba4c2776f7152e669a1ee 
63eb6bc3fa184fc42c3d469d594fc056f16b7892 M    gnu
  bisect run success

I've confirmed this by double-checking that I can build the commit
before but not this commit.

I don't really know why this fails, but it looks like it's somehow
triggering a remote process in some way related to tests and
shepherd... which is confusing, because I don't think this happening
during tests.

 - Chris





reply via email to

[Prev in Thread] Current Thread [Next in Thread]