GNU bug report logs - #29638
RHEL7 'Getopt::Long' perl module provokes some test failures

Previous Next

Package: automake;

Reported by: Dennis Clarke <dclarke <at> blastwave.org>

Date: Sun, 10 Dec 2017 05:45:02 UTC

Severity: normal

Tags: fixed, patch

Done: Mathieu Lirzin <mthl <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29638 in the body.
You can then email your comments to 29638 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Sun, 10 Dec 2017 05:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis Clarke <dclarke <at> blastwave.org>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Sun, 10 Dec 2017 05:45:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: bug-automake <at> gnu.org
Subject: Five failed tests in automake 1.15.1 with RHEL 7.4
Date: Sun, 10 Dec 2017 00:43:32 -0500
[Message part 1 (text/plain, inline)]
This is on Red Hat Enterprise Linux 7.4 and a fairly trivial config.

============================================================================
Testsuite summary for GNU Automake 1.15.1
============================================================================
# TOTAL: 2695
# PASS:  2420
# SKIP:  230
# XFAIL: 40
# FAIL:  5
# XPASS: 0
# ERROR: 0
============================================================================


Failures were :

FAIL: t/aclocal.sh
FAIL: t/automake-cmdline.tap 4 - list of options terminated by '--' (stderr)
FAIL: t/automake-cmdline.tap 17 - unambiguous incomplete long option
FAIL: t/maken3.sh
FAIL: t/maken3-w.sh

The configure was trivial :

$ ./configure --libdir=/usr/local/lib64
checking whether /usr/local/bin/gmake supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether ln -s works... yes
checking for perl... /bin/perl
checking for tex... no
checking for yacc... no
checking for byacc... no
checking for bison... no
checking for lex... no
checking for flex... no
checking whether autoconf is installed... yes
checking whether autoconf works... yes
checking whether autoconf is recent enough... yes
checking whether ln works... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
configure: will now look for a sturdy POSIX shell, for our testsuite
checking for sh... /bin/sh
checking for sh5... no
checking for dash... no
checking for ash... no
checking for bash... /bin/bash
checking for zsh... no
checking for ksh... no
checking for pdksh... no
checking whether /bin/sh supports $(cmd)... yes
checking whether /bin/sh supports $((expr))... yes
checking whether /bin/sh supports ${#var}... yes
checking whether /bin/sh supports ${var#glob} and ${var%glob}... yes
checking whether /bin/sh preserves exit traps with "set -e"... yes
checking whether /bin/sh can define exit traps in a shell function... yes
checking whether /bin/sh corrupts stderr with "set -x"... no
checking whether /bin/sh can return early from "dot-sourced" files... yes
checking whether /bin/sh supports alias named like shell builtins... yes
checking whether /bin/sh supports "test -e"... yes
configure: shell /bin/sh is good enough, stop looking
configure: will use /bin/sh as the testsuite shell
configure: will now look for generic compilers
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking whether cc understands -c and -o together... yes
checking for aCC... no
checking for CC... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking for c++... c++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether c++ accepts -g... yes
checking for xlf95... no
checking for f95... f95
checking whether the Fortran compiler works... yes
checking for Fortran compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... yes
checking whether f95 accepts -g... yes
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for g77... no
checking for gfortran... gfortran
checking whether the Fortran 77 compiler works... yes
checking for Fortran 77 compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
configure: will now look for GNU compilers
configure: cc is already a GNU C compiler
configure: c++ is already a GNU C++ compiler
configure: f95 is already a GNU Fortran compiler
configure: gfortran is already a GNU Fortran 77 compiler
checking for gcj... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating t/wrap/aclocal-1.15
config.status: creating t/wrap/automake-1.15


See test-suite.log.xz attached.


Dennis Clarke

[test-suite.log.xz (application/x-xz, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Sun, 10 Dec 2017 16:02:01 GMT) Full text and rfc822 format available.

Message #8 received at 29638 <at> debbugs.gnu.org (full text, mbox):

From: Dennis Clarke <dclarke <at> blastwave.org>
To: 29638 <at> debbugs.gnu.org
Subject: Same five tests fail with 1.15 on RHEL 7.4
Date: Sun, 10 Dec 2017 11:01:05 -0500
[Message part 1 (text/plain, inline)]
The same five tests fail for automake 1.15 and 1.15.1 on RHEL 7.4. Also
the testsuite itself reports mysterious "Error 1" and "Error 2" upon
termination and that looks questionable :

============================================================================
Testsuite summary for GNU Automake 1.15
============================================================================
# TOTAL: 2693
# PASS:  2422
# SKIP:  226
# XFAIL: 40
# FAIL:  5
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to bug-automake <at> gnu.org
============================================================================
gmake[2]: *** [Makefile:3027: test-suite.log] Error 1
gmake[2]: Leaving directory 
'/usr/local/build/automake-1.15_3.10.0-693.11.1.el7.x86_64.001'
gmake[1]: *** [Makefile:3135: check-TESTS] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/automake-1.15_3.10.0-693.11.1.el7.x86_64.001'
gmake: *** [Makefile:3366: check-am] Error 2
admsys <at> sedna$


The five failed tests are :

FAIL: t/aclocal.sh
FAIL: t/automake-cmdline.tap 4 - list of options terminated by '--' (stderr)
FAIL: t/automake-cmdline.tap 17 - unambiguous incomplete long option
FAIL: t/maken3.sh
FAIL: t/maken3-w.sh

The test suite log is attached as 
test-suite_gnu_automake_1.15_rhel7.4_kern_3.10.0-693.11.1.el7.x86_64.log.xz

Dennis Clarke



[test-suite_gnu_automake_1.15_rhel7.4_kern_3.10.0-693.11.1.el7.x86_64.log.xz (application/x-xz, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Fri, 05 Jan 2018 01:50:02 GMT) Full text and rfc822 format available.

Message #11 received at 29638 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 29638 <at> debbugs.gnu.org
Subject: Re: bug#29638: Same five tests fail with 1.15 on RHEL 7.4
Date: Fri, 05 Jan 2018 02:49:35 +0100
Hello,

Dennis Clarke <dclarke <at> blastwave.org> writes:

> The same five tests fail for automake 1.15 and 1.15.1 on RHEL 7.4. Also
> the testsuite itself reports mysterious "Error 1" and "Error 2" upon
> termination and that looks questionable :
>
> ============================================================================
> Testsuite summary for GNU Automake 1.15
> ============================================================================
> # TOTAL: 2693
> # PASS:  2422
> # SKIP:  226
> # XFAIL: 40
> # FAIL:  5
> # XPASS: 0
> # ERROR: 0
> ============================================================================
> See ./test-suite.log
> Please report to bug-automake <at> gnu.org
> ============================================================================
> gmake[2]: *** [Makefile:3027: test-suite.log] Error 1
> gmake[2]: Leaving directory
> '/usr/local/build/automake-1.15_3.10.0-693.11.1.el7.x86_64.001'
> gmake[1]: *** [Makefile:3135: check-TESTS] Error 2
> gmake[1]: Leaving directory
> '/usr/local/build/automake-1.15_3.10.0-693.11.1.el7.x86_64.001'
> gmake: *** [Makefile:3366: check-am] Error 2
> admsys <at> sedna$
>
>
> The five failed tests are :
>
> FAIL: t/aclocal.sh
> FAIL: t/automake-cmdline.tap 4 - list of options terminated by '--' (stderr)
> FAIL: t/automake-cmdline.tap 17 - unambiguous incomplete long option
> FAIL: t/maken3.sh
> FAIL: t/maken3-w.sh

The common characteristic of those failures is the command line
handling.

Automake use Perl provided Getopt::Long module to parse the command line
arguments and the version you are using seems to behave differently than
usual.

for example from Automake 1.15.1 build directory the following command
is supposed to work:

--8<---------------cut here---------------start------------->8---
$ t/wrap/automake-1.15 --vers
automake (GNU automake) 1.15.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey <at> redhat.com>
       and Alexandre Duret-Lutz <adl <at> gnu.org>.
--8<---------------cut here---------------end--------------->8---

According to your logs this doesn't work on your system.  My impression
is that those failing tests are checking the edge cases of Getopt::Long
which is system dependent and not the functional behavior of Automake.
As a consequence it seems reasonable to narrow the tests to more
conservative Getopt::Long behaviors.

WDYT?

Sorry for the delay.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Fri, 05 Jan 2018 02:06:01 GMT) Full text and rfc822 format available.

Message #14 received at 29638 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Mathieu Lirzin <mthl <at> gnu.org>, Dennis Clarke <dclarke <at> blastwave.org>
Cc: 29638 <at> debbugs.gnu.org
Subject: Re: bug#29638: Same five tests fail with 1.15 on RHEL 7.4
Date: Thu, 4 Jan 2018 20:05:00 -0600
[Message part 1 (text/plain, inline)]
On 01/04/2018 07:49 PM, Mathieu Lirzin wrote:

> for example from Automake 1.15.1 build directory the following command
> is supposed to work:
> 
> --8<---------------cut here---------------start------------->8---
> $ t/wrap/automake-1.15 --vers
> automake (GNU automake) 1.15.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Tom Tromey <tromey <at> redhat.com>
>        and Alexandre Duret-Lutz <adl <at> gnu.org>.
> --8<---------------cut here---------------end--------------->8---
> 
> According to your logs this doesn't work on your system.  My impression
> is that those failing tests are checking the edge cases of Getopt::Long
> which is system dependent and not the functional behavior of Automake.
> As a consequence it seems reasonable to narrow the tests to more
> conservative Getopt::Long behaviors.
> 
> WDYT?

If I understand GNU Coding Standards, we really do want to make sure
unambiguous abbreviations of long options work.  I'd argue that if not
all versions of perl Getopt::Long are working the way the testsuite
currently expects, that we should instead keep the test unchanged and
find ways to work around the broken perl module versions (perhaps by
manually specifying all abbreviations as explicit options ourselves,
rather than relying on Getopt::Long to do it for us).  At the same time,
once we do ascertain which version of Getopt::Long you are using, it may
be worth reporting the flaw in that version to your distro vendor, as
Automake is not the only software that would have to work around that
particular weakness.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Fri, 05 Jan 2018 03:09:01 GMT) Full text and rfc822 format available.

Message #17 received at 29638 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 29638 <at> debbugs.gnu.org, Dennis Clarke <dclarke <at> blastwave.org>
Subject: Re: bug#29638: Same five tests fail with 1.15 on RHEL 7.4
Date: Fri, 05 Jan 2018 04:08:15 +0100
Eric Blake <eblake <at> redhat.com> writes:

> On 01/04/2018 07:49 PM, Mathieu Lirzin wrote:
>
>> for example from Automake 1.15.1 build directory the following command
>> is supposed to work:
>> 
>> --8<---------------cut here---------------start------------->8---
>> $ t/wrap/automake-1.15 --vers
>> automake (GNU automake) 1.15.1
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> 
>> Written by Tom Tromey <tromey <at> redhat.com>
>>        and Alexandre Duret-Lutz <adl <at> gnu.org>.
>> --8<---------------cut here---------------end--------------->8---
>> 
>> According to your logs this doesn't work on your system.  My impression
>> is that those failing tests are checking the edge cases of Getopt::Long
>> which is system dependent and not the functional behavior of Automake.
>> As a consequence it seems reasonable to narrow the tests to more
>> conservative Getopt::Long behaviors.
>> 
>> WDYT?
>
> If I understand GNU Coding Standards, we really do want to make sure
> unambiguous abbreviations of long options work.  

I am unaware of such GCS recommandation.  Do you have a pointer to the
part of the standards suggesting that?

> I'd argue that if not all versions of perl Getopt::Long are working
> the way the testsuite currently expects, that we should instead keep
> the test unchanged and find ways to work around the broken perl module
> versions (perhaps by manually specifying all abbreviations as explicit
> options ourselves, rather than relying on Getopt::Long to do it for
> us).

This could indeed be done, however I am not convinced by the usefulness
of such workaround.

> At the same time, once we do ascertain which version of
> Getopt::Long you are using, it may be worth reporting the flaw in that
> version to your distro vendor, as Automake is not the only software
> that would have to work around that particular weakness.

Agreed.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Fri, 05 Jan 2018 15:13:01 GMT) Full text and rfc822 format available.

Message #20 received at 29638 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 29638 <at> debbugs.gnu.org, Dennis Clarke <dclarke <at> blastwave.org>
Subject: Re: bug#29638: Same five tests fail with 1.15 on RHEL 7.4
Date: Fri, 5 Jan 2018 09:12:03 -0600
[Message part 1 (text/plain, inline)]
On 01/04/2018 09:08 PM, Mathieu Lirzin wrote:
>> If I understand GNU Coding Standards, we really do want to make sure
>> unambiguous abbreviations of long options work.  
> 
> I am unaware of such GCS recommandation.  Do you have a pointer to the
> part of the standards suggesting that?

Hmm. I just re-read
https://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces,
and all I can see is that it recommends:

"Please define long-named options that are equivalent to the
single-letter Unix-style options. We hope to make GNU more user friendly
this way. This is easy to do with the GNU function getopt_long."

and then I extrapolated that since getopt_long() recognizes unambiguous
abbreviations, anything else used instead of getopt_long() should do
likewise.  But you're right that it does not seem to be an explicit
requirement, so much as an ease-of-use and consistency issue.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#29638; Package automake. (Thu, 18 Jan 2018 15:23:01 GMT) Full text and rfc822 format available.

Message #23 received at 29638 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 29638 <at> debbugs.gnu.org
Subject: Re: bug#29638: Same five tests fail with 1.15 on RHEL 7.4
Date: Thu, 18 Jan 2018 16:22:24 +0100
[Message part 1 (text/plain, inline)]
Hello,

Mathieu Lirzin <mthl <at> gnu.org> writes:

> Dennis Clarke <dclarke <at> blastwave.org> writes:
>
>> The five failed tests are :
>>
>> FAIL: t/aclocal.sh
>> FAIL: t/automake-cmdline.tap 4 - list of options terminated by '--' (stderr)
>> FAIL: t/automake-cmdline.tap 17 - unambiguous incomplete long option
>> FAIL: t/maken3.sh
>> FAIL: t/maken3-w.sh
>
> My impression is that those failing tests are checking the edge cases
> of Getopt::Long which is system dependent and not the functional
> behavior of Automake.  As a consequence it seems reasonable to narrow
> the tests to more conservative Getopt::Long behaviors.

Here is a patch that should fix this issue.

[0001-tests-Don-t-check-Getopt-Long-corner-cases.patch (text/x-patch, inline)]
From 83d5d37bc8f0adb0e20a6fe7ab68029d2479dd32 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin <mthl <at> gnu.org>
Date: Thu, 18 Jan 2018 11:19:13 +0100
Subject: [PATCH] tests: Don't check 'Getopt::Long' corner cases

Depending on the installed 'Getopt::Long' perl module, command-line
handling may vary a bit.  As a consequence we prefer not to check
command-line corners cases.  This change fixes automake bug#29638.

* t/aclocal.sh (am_create_testdir): Don't expect "--versi" to be
interpreted as "--version".
* t/automake-cmdline.tap: Don't expect "--vers" to be interpreted as
"--version" and things after "--" to be interpreted as file arguments.
(do_check): Display the actual command output.
* t/maken3.sh (check_targets): "--force" is not a documented option, so
don't use it.
---
 t/aclocal.sh           |  2 --
 t/automake-cmdline.tap | 13 ++-----------
 t/maken3.sh            |  2 +-
 3 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/t/aclocal.sh b/t/aclocal.sh
index 8cc8d5cc3..008493d5d 100644
--- a/t/aclocal.sh
+++ b/t/aclocal.sh
@@ -58,6 +58,4 @@ cat stderr >&2
 grep 'unrecognized option.*--ver' stderr
 grep '[Tt]ry.*--help.*for more information' stderr
 
-$ACLOCAL --versi
-
 :
diff --git a/t/automake-cmdline.tap b/t/automake-cmdline.tap
index c4441efe6..306231faa 100644
--- a/t/automake-cmdline.tap
+++ b/t/automake-cmdline.tap
@@ -18,7 +18,7 @@
 
 . test-init.sh
 
-plan_ 17
+plan_ 14
 
 # Usage: bad_cmdline DESCRIPTION REGEX-FOR-STDERR [ARGS-FOR-AUTOMAKE...]
 do_check ()
@@ -28,18 +28,11 @@ do_check ()
   regex=$1; shift
   AUTOMAKE_fails -d "$desc (run)" -- "$@"
   command_ok_ "$desc (stderr)" grep "$regex" stderr
+  cat stderr
 }
 
 do_check 'invalid long option' 'unrecognized option.*--voo' --voo
 
-# Older perl has a buggy Getopt::Long which makes this fail.
-if $PERL -e 'require 5.8.2;'; then
-  do_check "list of options terminated by '--'" \
-           'input file.*--voo' -- --voo
-else
-  skip_row_ 2 -r "older perl with buggy Getopt::Long"
-fi
-
 do_check "empty argument" \
          'empty argument' ''
 
@@ -58,6 +51,4 @@ do_check "'--help' as option argument" \
 do_check "ambiguous incomplete option" \
          'unrecognized option.*--ver' --ver
 
-command_ok_ "unambiguous incomplete long option" $AUTOMAKE --vers
-
 :
diff --git a/t/maken3.sh b/t/maken3.sh
index c37743cb7..8fe1d3269 100644
--- a/t/maken3.sh
+++ b/t/maken3.sh
@@ -181,7 +181,7 @@ check_targets || exit 1
 # TODO: add BUILT_SOURCES to sub2, fix fallout.
 sed 's/##//' < Makefile.am > t
 mv -f t Makefile.am
-$AUTOMAKE -Wno-override --force Makefile
+$AUTOMAKE -Wno-override Makefile
 ./configure
 check_targets || exit 1
 
-- 
2.15.1

[Message part 3 (text/plain, inline)]
Can you confirm this works on your system?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Added tag(s) patch. Request was from Mathieu Lirzin <mthl <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 18 Jan 2018 19:28:02 GMT) Full text and rfc822 format available.

Changed bug title to 'RHEL7 'Getopt::Long' perl module provokes some test failures' from 'Five failed tests in automake 1.15.1 with RHEL 7.4' Request was from Mathieu Lirzin <mthl <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 18 Jan 2018 19:40:01 GMT) Full text and rfc822 format available.

Reply sent to Mathieu Lirzin <mthl <at> gnu.org>:
You have taken responsibility. (Sun, 18 Feb 2018 12:31:02 GMT) Full text and rfc822 format available.

Notification sent to Dennis Clarke <dclarke <at> blastwave.org>:
bug acknowledged by developer. (Sun, 18 Feb 2018 12:31:02 GMT) Full text and rfc822 format available.

Message #32 received at 29638-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: Dennis Clarke <dclarke <at> blastwave.org>
Cc: 29638-done <at> debbugs.gnu.org
Subject: Re: bug#29638: Same five tests fail with 1.15 on RHEL 7.4
Date: Sun, 18 Feb 2018 13:30:34 +0100
Hello,

Mathieu Lirzin <mthl <at> gnu.org> writes:

>>From 83d5d37bc8f0adb0e20a6fe7ab68029d2479dd32 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin <mthl <at> gnu.org>
> Date: Thu, 18 Jan 2018 11:19:13 +0100
> Subject: [PATCH] tests: Don't check 'Getopt::Long' corner cases
>
> Depending on the installed 'Getopt::Long' perl module, command-line
> handling may vary a bit.  As a consequence we prefer not to check
> command-line corners cases.  This change fixes automake bug#29638.
>
> * t/aclocal.sh (am_create_testdir): Don't expect "--versi" to be
> interpreted as "--version".
> * t/automake-cmdline.tap: Don't expect "--vers" to be interpreted as
> "--version" and things after "--" to be interpreted as file arguments.
> (do_check): Display the actual command output.
> * t/maken3.sh (check_targets): "--force" is not a documented option, so
> don't use it.
> ---

I have pushed this in commit 903a80e0def90b88c1e4eead353af126a31a5422.

Feel free to reopen this bug if the problem persists.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Added tag(s) fixed. Request was from Mathieu Lirzin <mthl <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 08 Mar 2018 21:44:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 06 Apr 2018 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 358 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.