bug#71421: system info in test-suite.log
Hi Bruno,
You said:
> The problem with this is that
> - It's not immediately clear to everyone what this information is.
> - It can get in the way, for example when I want to search for "Linux"
> among the test logs:
> grep '^Linux' test-suite.log
>
> I would therefore suggest to mark them in some way:
I agree. Someone might not know the 'uname -a' output of their
machine. Solaris/SunOS comes to mind.
I've attached a patch that I think handles that and the extra space
you mentioned.
Here is what I see:
System information: Linux 6.8.11-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May
27 14:53:33 UTC 2024 x86_64
Distribution:
NAME="Fedora Linux"
VERSION="40 (Workstation Edition)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
CollinFrom d22f43b965cb5dcfa2c536802e3d3644bb80a25b Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Mon, 17 Jun 2024 00:32:07 -0700
Subject: [PATCH] test: Improve output of system information in test-suite.log.
Fixes https://bugs.gnu.org/71421.
* lib/am/check.am ($(TEST_SUITE_LOG): Use $(AWK) instead of 'awk'. Remove an
extra space in uname output. Start the line with "System information:".
---
lib/am/check.am | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/lib/am/check.am b/lib/am/check.am
index a506d1c79..04af927a1 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -366,10 +366,20 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
{ \
## Omit the hostname for privacy. In practice it's a single word?
echo;\
- (uname -a | awk '{$$2=""; print}') 2>&1; \
+ { uname -a | $(AWK) '{ \
+ printf "System information:";\
+ for (i = 1; i < NF; ++i) \
+{ \
+ if (i != 2) \
+printf " %s", $$i; \
+} \
+ printf "\n"; \
+}'; } 2>&1;\
if test -r /etc/os-release; then \
+ echo "Distribution:"; \
sed 8q /etc/os-release;\
elif test -r /etc/issue; then\
+ echo "Distribution:"; \
cat /etc/issue;\
fi; \
}; \
--
2.45.2
bug#71421: system info in test-suite.log
Karl Berry wrote: > Thanks Collin. I installed it (with minor wording tweaks). Looks good, thanks. > I had thought the extra space was useful rather than confusing, > indicating that a word had been omitted from the output. But I'm fine > with leaving it out. -k I didn't mind it much but I do think it looks better without. Collin
bug#74453: running make failed when perl is installed in the very long path
Hi, "Li, Changqing" via Bug reports for Automake writes: > I met an issue when try to compile automake with the perl installed in a > very long path which larger then max length of shebang , here is the > reproduce steps What shell cut off the path? Seems like a bug in that shell. As Bruno Haible said in a Gnulib thread [1]: > "#!/usr/bin/env perl" does not work on GuixSD (where the only program > that has a hardcoded file name is /bin/sh; there is no /usr and no > /bin/env on this distro). So I don't think it would work in this case. Collin [1] https://lists.gnu.org/archive/html/bug-gnulib/2019-06/msg00022.html
bug#74661: [PATCH] Make time-stamp after-save-hooks buffer-local.
Hi, I applied a similar patch like this to Gnulib a while ago. Basically, the use of this in files: # eval: (add-hook 'before-save-hook 'time-stamp) modifies the global before-save-hook for Emacs, i.e. even after closing the file. This caused some annoyance because it wouldn't work with this in your Emacs init file: (setq enable-local-variables :safe) The solution to this is to use: # eval: (add-hook 'before-save-hook 'time-stamp nil t) so it only enables it on the current buffer. Collin >From f09fb67eff602dc0b78ddeca3d14c54d0e355771 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 2 Dec 2024 19:11:40 -0800 Subject: [PATCH] Make time-stamp after-save-hooks buffer-local. * contrib/tap-driver.pl: Add time-stamp-line-limit so Emacs updates the timestamp. Pass optional arguments to 'add-hook'. * lib/tap-driver.sh: Likewise. * lib/compile: Pass optional arguments to 'add-hook'. * lib/depcomp: Likewise. * lib/install-sh: Likewise. * lib/mdate-sh: Likewise. * lib/missing: Likewise. * lib/mkinstalldirs: Likewise. * lib/py-compile: Likewise. * lib/test-driver: Likewise. * lib/ylwrap: Likewise. --- contrib/tap-driver.pl | 5 +++-- lib/compile | 4 ++-- lib/depcomp | 4 ++-- lib/install-sh| 4 ++-- lib/mdate-sh | 4 ++-- lib/missing | 4 ++-- lib/mkinstalldirs | 4 ++-- lib/py-compile| 4 ++-- lib/tap-driver.sh | 5 +++-- lib/test-driver | 4 ++-- lib/ylwrap| 4 ++-- 11 files changed, 24 insertions(+), 22 deletions(-) diff --git a/contrib/tap-driver.pl b/contrib/tap-driver.pl index 6a57bb080..5fdf38b0a 100755 --- a/contrib/tap-driver.pl +++ b/contrib/tap-driver.pl @@ -32,7 +32,7 @@ use strict; use Getopt::Long (); use TAP::Parser; -my $VERSION = '2013-12-24.15'; # UTC +my $VERSION = '2024-12-03.03'; # UTC my $ME = "tap-driver.pl"; @@ -555,7 +555,8 @@ main @ARGV; # cperl-extra-newline-before-brace: t # cperl-merge-trailing-else: nil # cperl-continued-statement-offset: 2 -# eval: (add-hook 'before-save-hook 'time-stamp) +# eval: (add-hook 'before-save-hook 'time-stamp nil t) +# time-stamp-line-limit: 50 # time-stamp-start: "my $VERSION = " # time-stamp-format: "'%:y-%02m-%02d.%02H'" # time-stamp-time-zone: "UTC0" diff --git a/lib/compile b/lib/compile index 49b3d05fd..c3e8760e9 100755 --- a/lib/compile +++ b/lib/compile @@ -1,7 +1,7 @@ #! /bin/sh # Wrapper for compilers which do not understand '-c -o'. -scriptversion=2024-06-19.01; # UTC +scriptversion=2024-12-03.03; # UTC # Copyright (C) 1999-2024 Free Software Foundation, Inc. # Written by Tom Tromey . @@ -343,7 +343,7 @@ exit $ret # Local Variables: # mode: shell-script # sh-indentation: 2 -# eval: (add-hook 'before-save-hook 'time-stamp) +# eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-start: "scriptversion=" # time-stamp-format: "%:y-%02m-%02d.%02H" # time-stamp-time-zone: "UTC0" diff --git a/lib/depcomp b/lib/depcomp index 1f0aa972c..87974bf3e 100755 --- a/lib/depcomp +++ b/lib/depcomp @@ -1,7 +1,7 @@ #! /bin/sh # depcomp - compile a program generating dependencies as side-effects -scriptversion=2024-06-19.01; # UTC +scriptversion=2024-12-03.03; # UTC # Copyright (C) 1999-2024 Free Software Foundation, Inc. @@ -784,7 +784,7 @@ exit 0 # Local Variables: # mode: shell-script # sh-indentation: 2 -# eval: (add-hook 'before-save-hook 'time-stamp) +# eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-start: "scriptversion=" # time-stamp-format: "%:y-%02m-%02d.%02H" # time-stamp-time-zone: "UTC0" diff --git a/lib/install-sh b/lib/install-sh index b1d7a6f67..8a76989bb 100755 --- a/lib/install-sh +++ b/lib/install-sh @@ -1,7 +1,7 @@ #!/bin/sh # install - install a program, script, or datafile -scriptversion=2024-06-19.01; # UTC +scriptversion=2024-12-03.03; # UTC # This originates from X11R5 (mit/util/scripts/install.sh), which was # later released in X11R6 (xc/config/util/install.sh) with the @@ -533,7 +533,7 @@ do done # Local variables: -# eval: (add-hook 'before-save-hook 'time-stamp) +# eval: (add-hook 'before-save-hook 'time-stamp nil t) # time-stamp-start: "scriptversion=" # time-stamp-format: "%:y-%02m-%02d.%02H" # time-stamp-time-zone: "UTC0" diff --git a/lib/mdate-sh b/lib/mdate-sh index 764e142ee..da9c9f7d4 100755 --- a/lib/mdate-sh +++ b/lib/mdate-sh @@ -1,7 +1,7 @@ #!/bin/sh # Get modification time of a file or directory and pretty-print it. -scriptversion=2024-06-19.01; # UTC +scriptversion=2024-12-03.03; # UTC # Copyright (C) 1995-2024 Free Software Foundation, Inc. # written by Ulrich Drepper , June 1995 @@ -222,7 +222,7 @@ echo $day $month $year
bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Karl Berry writes: > As far as I can tell, the date command on Solaris 10 (cfarm210) and 11 > (cfarm211) does not support any way to print a specified date value. So > I inserted a fallback to perl -e 'print scalar > gmtime($SOURCE_DATE_EPOCH)' if the date commands fail. > > If Perl isn't available either, mdate-sh gives a warning and falls back > to using the mtime of the given file. That sounds like a good solution to me. > I don't mind just ignorning that platform. > > Not supporting gnulib-tool is one thing, but a lot of people still build > and use Solaris 10. We still get bug reports for Automake from people > running it there. Might as well keep mdate-sh working there, since it > was easy to do. > > Below is the important part of the patch, and the new file. > I also threw in a warning if more than one file is specified on the > command line, instead of silently ignoring anything after the first. > Hopefully no one's build actually passes multiple files. > > Anyway ... closing this bug, with fingers crossed. This was the last > change I intended to make before the release. Just have to finalize the > Algol 68 naming. --thanks, karl. Sounds good to me. I had assumed most people use Solaris 11, but I didn't notice that 'date' doesn't work there too. Thanks, Collin
bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Hi Karl, Karl Berry writes: > Does anyone have a BSD system (any flavor) I could get access to? > > Alternatively, attached is my unreleased version of mdate-sh which tries > to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied > the BSD date command (date -u -r ...) from > https://reproducible-builds.org/docs/source-date-epoch/ but have no way > to test. E.g.: > SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp > should output > 2 January 1970 > > I also don't know if there are other date commands that must be > supported, or if it's worth falling back to Perl, or what. > > Suggestions, advice, testing? You can sign-up for the GCC Compile Farm and get access to many different BSD systems [1]. The list of platforms is here [2]. Usually I do that, or just create a virtual machine which works well for most things. I'll have a look at running your test in the meantime. Collin [1] https://portal.cfarm.net/users/new/ [2] https://portal.cfarm.net/machines/list/
bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Hi Karl, Collin Funk writes: >> Alternatively, attached is my unreleased version of mdate-sh which tries >> to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied >> the BSD date command (date -u -r ...) from >> https://reproducible-builds.org/docs/source-date-epoch/ but have no way >> to test. E.g.: >> SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp >> should output >> 2 January 1970 >> >> I also don't know if there are other date commands that must be >> supported, or if it's worth falling back to Perl, or what. >> >> Suggestions, advice, testing? > [...] > > I'll have a look at running your test in the meantime. I did some testing on the latest BSD releases and 2 older systems (MacOS 12 and Solaris 10). Here are the results: * OpenBSD 7.7, NetBSD 10.0, FreeBSD 15.0, MacOS 12.6: $ SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp 2 January 1970 * Solaris 10: $ SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp ./mdate-sh: SOURCE_DATE_EPOCH was set, but can't convert: 123456 The Solaris failure is because their date does not support the '--date' or '-r' option. I don't mind just ignorning that platform. We do for Gnulib since it has an old unsupported Python version. In DEPENDENCIES there: Note: Solaris 10 is no longer supported as maintainer environment. <https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00076.html> Collin
