bug#15403: https://bugzilla.gnome.org/show_bug.cgi?id=701638 automake 1.13 changes causing regressions tests
tags 15403 notabug close 15403 thanks On 09/17/2013 07:39 PM, Stefan Sauer wrote: > hi, > Hi Stefan, sorry for the delay. > https://bugzilla.gnome.org/show_bug.cgi?id=701638 has the details. > """ > Since Automake 1.13 (which is entering many distributions), tests are > executed in parallel by default. For tests run in parallel, Automake > grabs the output and results of the test and outputs it to two new > files, with a .log and .trs extension. It creates the > filenames based on the test name, which in the case of GTKDOC_CHECK is > the absolute path to the gtkdoc-check binary. This is generally > $(prefix)/bin and not writable by the user. This leads to errors when > running the gtk-doc check when using Automake 1.13 or above: > fatal: making test-suite.log: failed to create > /some-path/bin/gtkdoc-check.trs > fatal: making test-suite.log: failed to create > /some-path/bin/gtkdoc-check.log > """ > We have a generic sanity check that we run over the data files in the > project. The data files are passed via TESTS_ENVIRONMENT: > https://git.gnome.org/browse/gtk-doc/tree/examples/Makefile.am#n99 > > We'll probably go with the hack proposed in the patch. Please let us > know it there is a better way to handle this. > FWIW, I personally would have proposed the exact workaround you ended up using. Simple and painless. I hope it is working well for you now. I'm closing this bug report to avoid keeping our tracker overly cluttered. Regards, Stefano
bug#15518: rm test
tags 15518 wontfix close 15518 thanks On 09/30/2013 02:49 AM, Tim Rice wrote:> > Reporting as requested. > > checking for a BSD-compatible install... > /opt/src/gnu/m4-1.4.17/build-aux/install-sh -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... > /opt/src/gnu/m4-1.4.17/build-aux/install-sh -c -d > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... no > UX:rm: ERROR: Incorrect usage > UX:rm: TO FIX: Usage: rm [-fiRr] file ... > Oops! > > Your 'rm' program seems unable to run without file operands specified > on the command line, even when the '-f' option is present. This is contrary > [snip] > configure: error: Your 'rm' program is bad, sorry. >^^^ > Bad? I don't think so. Old? Sure. > > PATH=/usr/bin:/opt/bin:/usr/ccs/bin:/usr/ucb:/usr/gnu/bin:/usr/java/bin:/usr/local/bin:/homes/tim/bin/UnixWare > > config.guess says i686-unknown-sysv5UnixWare7.1.4 > > My suggestion: install GNU rm, or adjust your PATH in case you have already another better (errm, younger :-) 'rm' installed . Future versions of automake (ETA still undetermined) will require an 'rm' program that doesn't choke when invoked with the "-f" option and no arguments. Also, the next version of POSIX will mandate such a behaviour. For more information and background, see: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10828 I'm closing the bug because the plan of requiring argumentless "rm -f" to just work remains in place; the request for a report that is issued by the script (and that prompted you to open this bug report) is more to allow us to have some gauge of how many systems we are going to affect with that change (yours is the first one so far), rather than to decide whether to go along with it. Thanks, Stefano
