<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 13-01-14 11:07 AM, Alan Coopersmith wrote: </div> <blockquote cite="mid:50F42D32.4000407@oracle.com" type="cite"> <pre wrap="">On 01/13/13 11:52 PM, Jeremy Huddleston Sequoia wrote: </pre> <blockquote type="cite"> <pre wrap="">While it's good to prepare for 1.14, we're still not working with 1.13 yet. libX11 is failing with: nls/Makefile.am:41: error: using '$(srcdir)' in TESTS is currently broken: '$(srcdir)/compose-check.pl' (see <a class="moz-txt-link-freetext" href="http://tinderbox.x.org/builds/2013-01-14-0001/logs/libX11/#configure">http://tinderbox.x.org/builds/2013-01-14-0001/logs/libX11/#configure</a>) and I'm not really sure what to do about that… any thoughts? </pre> </blockquote> <pre wrap=""> Didn't someone send a patch for that recently? Unfortunately, I don't see it on patchwork. </pre> </blockquote> Perhaps this would be the one: <a class="moz-txt-link-freetext" href="http://patches.openembedded.org/patch/41927/">http://patches.openembedded.org/patch/41927/</a> It simply disables the tests altogether. In <a class="moz-txt-link-freetext" href="http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites">http://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites</a>: <blockquote>Test programs that need data files should look for them in <big><code>srcdir</code></big> (which is both a make variable and an environment variable made available to the tests), so that they work when building in a separate directory (see <a href="http://www.gnu.org/software/automake/manual/autoconf.html#Build-Directories">Build Directories</a>), and in particular for the <code>distcheck</code> rule (see <a href="http://www.gnu.org/software/automake/manual/automake.html#Checking-the-Distribution">Checking the Distribution</a>). </blockquote> Could it be that the perl script returns an error? Does it complete successfully when run manually? Any of the other 32 or so tools in the tool chain has also been upgraded (if this error occurs on a system where a wholesale upgrade has been done? Anyone else has reproduced the problem or claims success? </body> </html>