GNU sharutils generated archive license

[Bruce Korb]

if the person/entity most anxious about that far fetched fear of
infringement (my opinion) would provide a patch with such a disclaimer,
I would be happy to incorporate the thing.

I was going to try to suggest something, but ran into so many problems

So much history. Sorry. Cruft from before I started maintaining it and
still more by twisted interconnected dependencies that are probably not
needed but not worth digging into (mostly 'cuz it works for me).
If you are really curious, run bootstrap with xtrace set.

* There are seemingly-duplicate files README.git and README-GIT. Plus,
README-alpha. They are confusing. Surely just one such file is needed.

I'll look at that. However, all "foo.git" files are auto-edited and the
oritinals (e.g. README.git) should be stripped from the distro.

* './bootstrap' failed because the Fedora package 'autogen' wasn't
installed.
* './bootstrap' failed because the Fedora package
'autogen-libopts-devel' wasn't installed.

Fedora thinks it a good idea to keep them separate and not dependent.
Other distros add a dependency so "autogen" sucks up the libopts.

* './bootstrap' took a veerrrrryy long time, seemingly stuck in
gnulib-tool, without outputting anything. Eventually something happened,
but wow.

Autotool issue. "bootstrap" runs them all and the aforementioned
"twisted interconnected dependencies" produce this issue. Wow, indeed.

* Eventually './bootstrap' failed with the following diagnostics at the
end. At this point I got lost and gave up.
,,,
/usr/bin/autopoint (GNU gettext-tools) 0.19.8.1
Uses a versions archive in dirxz format.
autoreconf: Entering directory `.'
autoreconf: running: true --force
autoreconf: running: aclocal --force --warnings=all -I m4
configure.ac:13: warning: macro 'AM_GNU_GETTEXT' not found in library
configure.ac:14: warning: macro 'AM_GNU_GETTEXT_VERSION' not found in
library
configure.ac:110: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2729: _AC_RUN_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
../../lib/autoconf/general.m4:2748: AC_RUN_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
m4/libopts.m4:158: LIBOPTS_WITHLIB_REGEX is expanded from...
m4/libopts.m4:425: INVOKE_LIBOPTS_MACROS is expanded from...
configure.ac:110: the top level
configure.ac:110: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body

I have complained about this. I've never seen or heard a reasonable
solution. The recommendation: Ignore it. :(

make[2]: Entering directory '/u/gnu/proj/sharutils-bld/libopts'
make all-am
make[3]: Entering directory '/u/gnu/proj/sharutils-bld/libopts'
gcc -DHAVE_CONFIG_H -I. -I.. -I. -Wno-format-contains-nul -Wall -ggdb3 -gdwarf-2 -O0 -Wno-format-contains-nul -MT libopts_a-libopts.o -MD -MP -MF .deps/libopts_a-libopts.Tpo -c -o libopts_a-libopts.o `test -f 'libopts.c' || echo './'`libopts.c
In file included from parse-duration.c:30:0,
intprops.h:24:20: fatal error: verify.h: No such file or directory
#include <verify.h>
^
compilation terminated.
Makefile:1309: recipe for target 'libopts_a-libopts.o' failed
make[3]: *** [libopts_a-libopts.o] Error 1
make[3]: Leaving directory '/u/gnu/proj/sharutils-bld/libopts'
Makefile:1244: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/u/gnu/proj/sharutils-bld/libopts'
Makefile:1319: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/u/gnu/proj/sharutils-bld'
Makefile:1258: recipe for target 'all' failed
make: *** [all] Error 2

whatever "verify.h" is supposed to be. Because gnulib-tool automatically
triggers a bunch of header dependencies and I can never know which ones
or where, I have to parse the gnulib-tool output for a list of header

#include <alloca.h>\
#include <ctype.h>\
#include <getopt.h>\
#include <stddef.h>\
#include <stdio.h>\
#include <stdlib.h>\
#include <stdnoreturn.h>\
#include <string.h>\
#include <sys/utsname.h>\
#include <sys/wait.h>\
#include <time.h>\
#include <unistd.h>\
\
#include "base64.h"\
#include "dirname.h"\
#include "error.h"\
#include "idcache.h"\
#include "inttostr.h"\
#include "locale.h"\
#include "md5.h"\
#include "pathmax.h"\
#include "quotearg.h"\
#include "strftime.h"\
#include "unlocked-io.h"\
#include "xalloc.h"\
#include "xgetcwd.h"\

If I don't do that, I either have to maintain the list by hand or suffer
failures because some headers are not included. Rather than that, I
force feed that list. I'd prefer idempotent self-sufficient headers,
but instead I do this. Anyway, a long explanation for taking a long
time. And I guess I need to stuff "verify.h" into the list.

So I will make "bootstrap" complain more explicitly about missing tools.

<<<time passes>>>

I have to tell libopts about where to find that header.
I guess it has fallen off the include dir list somehow.

diff --git a/bootstrap b/bootstrap
index 874831e..ca3ba05 100755
--- a/bootstrap
+++ b/bootstrap
@@ -150,6 +150,7 @@ install_libopts() {
sed '/if INSTALL_LIBOPTS/inoinst_LIBRARIES = libopts.a
/if INSTALL_LIBOPTS/,/^endif$/d
/^libopts_la_LDFLAGS/d
s/libopts_la/libopts_a/g' Makefile.am > Makefile.X
mv -f Makefile.X Makefile.am
@@ -323,7 +324,7 @@ setup_configure() {
{
sed '/^# *INVOKE_LIBOPTS_MACROS/q' configure.ac
printf '['
- for f in $(egrep '#include *<' import-log.txt | \
+ for f in $(grep -E '#include *<' import-log.txt | \
sed 's/.*<//;s/>.*//')
do
f=$(echo "$f" | tr -- '-./' '___')

The other changes are all translation stuff.

[Eric Blake]

+ xoth woth roth xgrp wgrp rgrp xusr wusr rusr rwxo rwxg rwxu xall wall rall

Rather than inventing new option keywords, can you please share code
with 'chmod' by using the gnulib module 'modechange', so that we get a
consistent way to specify string-ized modes?

+ or an integer mask with any of the lower 9 bits set

Is this always interpreted in octal, even when a leading 0 is not present?

Again, using the gnulib module would take care of this.