Hello Ludo,

I ran the gnulib lock tests with the be95b17ae commit and the tests passed, then with the commit directly before and they failed; so I'm fairly confident.

Attached is an updated patch, which remove the *-gnulib-multi-core patches and disables the test on two more packages (augeas and gsasl).  I was able to build most of the packages on gnulib's "users" list (https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=users.txt;h=4ea176f2ef622b5c12843ba3d5aa35217c58502b;hb=HEAD) except for octave, because texlive-bin's luajit tests fail on this system.

Eric Bavier, Scientific Libraries, Cray Inc.

________________________________________
From: Ludovic Courtès <ludo@gnu.org>
Sent: Sunday, October 29, 2017 10:39
To: Eric Bavier
Cc: guix-devel@gnu.org
Subject: Re: Disable gnulib's test-lock test in packages?

Hi Eric,

Eric Bavier <bavier@cray.com> skribis:

> Several packages (libunistring, gettext, and libidn) in the guix bootstrap path hang on the "test-lock" test from gnulib while building on a aarch64 system I have access to.  Some of them already have a patch applied that is supposed to fix the hang on system's with large core-counts, but it seems ineffective on my system.  The findutils package is also affected, and there may be others, but I haven't discovered them yet.
>
> This commit in gnulib fixes the test-lock issue on my system, but doesn't help until our packages update their gnulib source:
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=be95b17ae933323cb757471f3d7c3f0617f9257e
>
> Not knowing any better, I created a dummy project to run the latest gnulib lock tests, attached for clarity.

So are you confident that the above commit fixes the issue?

As you might have seen, we already have
findutils-gnulib-multi-core.patch, gettext-gnulib-multi-core.patch, and
libunistring-gnulib-multi-core.patch, which turned out to be
insufficient to fix the problem.

> Until the updated lock module and tests make its way into these packages, I would like to ask if disabling these tests outright would be acceptable, similar to the attached patch.  Thoughts?

Your patch looks like the safest approach; you can also remove
*gnulib-multi-core.patch while you’re at it.  Then I think it’s OK for
‘core-updates’.

Thank you!

Ludo’.