bug#12820: gnulib testsuite failure in latest master
On 11/08/2012 08:44 AM, Paul Eggert wrote: > Ouch, I read your strace output incorrectly: it was napping > for 20 ms, not 2 s. Still, there should be no need to nap > for that long; 1 ms should suffice on your platform. > > I installed the following patch to cause the test > to take shorter naps. This might affect your original > problem, and might not (hey! it's a timing problem) > but at least it should make the test run faster. > I'll re-run the affected test case as soon as coreutils updates its version of gnulib then, and see what happens. Thanks, Stefano
bug#12730: bug #12730: patch attached
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Nov 2012 08:05:30 +0100 Jim Meyering wrote: > > Hmm trying the latest from gnulib, I saw a compilation failure. > And it was my fault for omitting a hunk of your patch when > I adjusted it. Sorry about that. > > Here's the fix. > > From ab7a2b67b48deb4c253b3b6bd983690d71515265 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Wed, 7 Nov 2012 22:59:21 -0800 > Subject: [PATCH] mountlist.c: fix a compilation failure > > * lib/mountlist.c (read_file_system_list): Fix a compilation failure > I introduced while transforming commit v0.0-7683-g613bcb6 > --- > ChangeLog | 6 ++ > lib/mountlist.c | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/ChangeLog b/ChangeLog > index adcb8d1..1a1e8b7 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,9 @@ > +2012-11-07 Jim Meyering > + > + mountlist.c: fix a compilation failure > + * lib/mountlist.c (read_file_system_list): Fix a compilation > failure > + I introduced while transforming commit v0.0-7683-g613bcb6 > + > 2012-11-05 Paul Eggert > > errno: port to LynxOS 178 2.2.2 > diff --git a/lib/mountlist.c b/lib/mountlist.c > index a9a9f2c..d0fe1b2 100644 > --- a/lib/mountlist.c > +++ b/lib/mountlist.c > @@ -430,7 +430,7 @@ read_file_system_list (bool need_fs_type) > me->me_mountdir = xstrdup (mnt->mnt_dir); > me->me_type = xstrdup (mnt->mnt_type); > me->me_type_malloced = 1; > -me->me_dummy = ME_DUMMY (me->me_devname, me->me_type); > +me->me_dummy = ME_DUMMY (me->me_devname, me->me_type, mnt); > me->me_remote = ME_REMOTE (me->me_devname, me->me_type); > me->me_dev = dev_from_mount_options (mnt->mnt_opts); > > -- > 1.8.0 > I'm sorry I didn't catch it before; thanks for fixing it, in any event. -Andrew Warshall -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJQm6lDAAoJEESPRWh79T7twWkH/3GsVTPt5stmE4pWNpxJ9vYb ufjI4TnuTZUFPnM4xyFeZkulSsKKj+L5/GtRyaUE6O2qSk50ZGWx43jtL8PDHfMU tu1sCT2m+4YH1JIqs6hmQMCSZpoqtXaPvIsH1nLS2mQAOLWO1KD7DvqNIrZiqrAp UIiRcPc9bjDn0HwKLjjT2WjOhEpLf8qN/KT6gPbdtnkxl54VLPsPKzA3vm3WNWJ7 xTnWV3781vuTrsnCJ/5Hb/xGK4gQb3JK9dJlzCnQHNzepQyOT1UbxY7EH/GaSkQk dSzXCm/vbHzWCdJ2SXc7MOVz9nNWqkhuH8by650xajzBTFr4Ssr/F84lu/BZ5Wg= =5YA/ -END PGP SIGNATURE-
bug#12658: [patches] some undocumented options in chcon
On 11/07/2012 08:56 PM, Benno Schulenberg wrote:
On Fri, Oct 19, 2012, at 11:17, Jim Meyering wrote:
Please ping us if they're not applied soon after 8.20.
I've adjusted the 2 remaining patches a little.
First to use the doc: prefix on the summary to
indicate they're not logic changes.
I've adjusted the chcon.c change a little to
keep the alphabetical ordering for the options,
and to reuse text (translations) from existing
--help documentation in chgrp etc.
I'll push the attached in a while.
Thanks for following up!
Pádraig.
>From 85df3124edea493b85d9497754922ee0860c04ba Mon Sep 17 00:00:00 2001
From: Benno Schulenberg
Date: Mon, 15 Oct 2012 13:06:37 +0200
Subject: [PATCH 1/2] doc: with cp -n, option -f is not redundant but ignored
* src/cp.c (usage): Replace "redundant" with "ignored".
* doc/coreutils.texi (cp invocation): Likewise.
---
doc/coreutils.texi |4 ++--
src/cp.c |5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index b251b3d..f126f49 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7734,8 +7734,8 @@ description of @option{--remove-destination}.
This option is independent of the @option{--interactive} or
@option{-i} option: neither cancels the effect of the other.
-This option is redundant if the @option{--no-clobber} or @option{-n} option is
-used.
+This option is ignored when the @option{--no-clobber} or @option{-n} option
+is also used.
@item -H
@opindex -H
diff --git a/src/cp.c b/src/cp.c
index 61b31af..231d6a3 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -177,9 +177,8 @@ Mandatory arguments to long options are mandatory for short options too.\n\
"), stdout);
fputs (_("\
-f, --force if an existing destination file cannot be\n\
- opened, remove it and try again (redundant if\
-\n\
- the -n option is used)\n\
+ opened, remove it and try again (this option\n\
+ is ignored when the -n option is also used)\n\
-i, --interactiveprompt before overwrite (overrides a previous -n\
\n\
option)\n\
--
1.7.6.4
>From 64b8a1729e62cfe2cc8f62c3a0231e4475c53f78 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg
Date: Mon, 15 Oct 2012 19:37:34 +0200
Subject: [PATCH 2/2] doc: chcon: add descriptions for three undocumented
options
These were missed in this related change v8.14-104-g44e20cd
* src/chcon.c (usage): Mention the two --preserve-root options.
* doc/coreutils.texi (chcon invocation): Plus the --dereferece option.
---
doc/coreutils.texi | 20 ++--
src/chcon.c|4
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f126f49..7f8c0d1 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -1384,7 +1384,7 @@ legitimate uses for such a command,
that resolves to @file{/}. If you really want to try to remove all
the files on your system, you can use the @option{--no-preserve-root}
option, but the default behavior, specified by the
-@option{--preserve-option}, is safer for most purposes.
+@option{--preserve-root} option, is safer for most purposes.
The commands @command{chgrp}, @command{chmod} and @command{chown}
can also operate destructively on entire hierarchies, so they too
@@ -15256,12 +15256,16 @@ The program accepts the following options. Also see @ref{Common options}.
@table @samp
+@item --dereference
+@opindex --dereference
+Do not affect symbolic links but what they refer to; this is the default.
+
@item -h
@itemx --no-dereference
@opindex -h
@opindex --no-dereference
@cindex no dereference
-Affect symbolic links instead of any referenced file.
+Affect the symbolic links themselves instead of any referenced file.
@item --reference=@var{rfile}
@opindex --reference
@@ -15274,6 +15278,18 @@ Use @var{rfile}'s security context rather than specifying a @var{context} value.
@opindex --recursive
Operate on files and directories recursively.
+@item --preserve-root
+@opindex --preserve-root
+Refuse to operate recursively on the root directory, @file{/},
+when used together with the @option{--recursive} option.
+@xref{Treating / specially}.
+
+@item --no-preserve-root
+@opindex --no-preserve-root
+Do not treat the root directory, @file{/}, specially when operating
+recursively; this is the default.
+@xref{Treating / specially}.
+
@choptH
@xref{Traversing symlinks}.
diff --git a/src/chcon.c b/src/chcon.c
index 34e92e4..66075f5 100644
--- a/src/chcon.c
+++ b/src/chcon.c
@@ -371,6 +371,10 @@ With --reference, change the security context of each FILE to that of RFILE.\n\
-l, --range=RANGE set range RANGE in the target security context\n\
"), stdout);
fputs (_("\
+ --no-preserve-root do not treat '/' specially (the default)\n\
+ --preserve-rootfail t
bug#12794: Bug in dd: it sends wrong messages to stderr
I'm wanting to clarify two issues about this exchange. One issue is regarding personal interactions, and the other issues is about the nature of the POSIX standard. These are observations -- not a call to action. Bob Proulx wrote: Ganton wrote: Sorry, but dd is older than POSIX Paul Eggert wrote "dd is [...] part of the POSIX standard" and I wrote consequently, if the dd specification is broken, then the POSIX standard is broken, too. The task of the POSIX standard was to document existing behavior and standardize it so that there wouldn't be even more differences between systems. Of course lately it has become a design-by-committee. It is hard for people to resist these temptations. But standardizing on the behavior that is already in existence is a good thing because it allows people to write programs that not only run on their own system but ones that stand a chance of running on another person's system too. You're 40 years too late on this one. This kind of condescending attitudes do not improve matters. Please no ad-hominem attacks. Thanks. What is an ad-hominem attack? Isn't that an attack against the person? Clearly, the poster was talking about an attitude that came across as condescending. I've been told on this list, that using "you" was considered attacking, even though in my writing I'd specifically stayed away from any name-calling or ad-hominem attacks, the simple use of "you" was considered enough to make my message "attacking". Clearly, one can see certain messages colored in different ways, regardless of intent. However, there are two issues I would like to point out here. First, the original statement talked about an attitude that appeared indicated in a specific statement and didn't talk about a person, it doesn't seem possible that "ad hominem" would apply. Second, during a conversation that became heated, when I asked if I had called the other person any names, or engaged, in any personal attacks, I was told 'not', but that I had used the word "you" -- thus making it "attacking". If "you" is sufficient to judge writing as being "attacking" (on some or any level), then calling the recipient of such language "out of line" for describing such language as "attacking, (specifically, condescending), seems as though a double standard is being used. This isn't NOT meant to be a judgment, as 'you', is a standard part of speech, mean to direct one's speaking to another. Calling it an attack is certainly a subjective call. I'm not wanting a argument or discussion about this -- I'm only wanting to point out the inconsistencies in how judgments are being applied and a trend to seeing them applied is specific directions. I presume this is unconscious, but in both cases it did involve POSIX, which is being used on a subtle level to control the Open source community -- even though the standard was purchased by Corporate wealth. That something appears "open" to contributing, means nothing by itself. I've seen more than one open source projects that claimed to be "open", only to see patches to correct design problems, persistently ignored for personal or political reasons -- even when such flaws clearly couldn't be justified on objective, sound, engineering principles. --===-- Also some have said POSIX was "descriptive" and such is stated in their initial mission statement. ... To use MS-lingo, this was the "Embrace" phase. POSIX has moved beyond that phase and now is in the "Extend" phase, where it has become prescriptive -- not describing existing practice, but dictating new and incompatible behaviors. Besides the shift from descriptive to prescriptive, POSIX has also shifted from being a program-portability standard -- a description of features programs could rely on being there in order to aid portability, it has also expanded into prescribing User Interface behaviors that NOT ONLY, exceed it's purpose in providing a base for program portability, but actually harm program portability. Prioritizing user-interface design on the command line over program portability goes against the core-purpose of the standard, yet this is what has happened, approximately after the 2001 POSIX updates. The POSIX standard, 'now', no longer follows it's initial mission statement, and is is now a corporate tool for controlling the open source community. Whether or not POSIX is being moved into the extinguish phase is arguable while it is in process, but it must be noted, that Microsoft, which supported POSIX in its earliest forms in the late 90's with it's POSIX subsystem, now feels they have no more need to support or provide POSIX compatibility, since starting with Windows 8, their POSIX subsystem is dead. Buying into POSIX changes that reduce functionality and break previous program compatibility would seem to be a good way to accelerate the last phase, but ironical
bug#12794: Bug in dd: it sends wrong messages to stderr
Dear Linda, On 11/07/2012 10:06 AM, Linda Walsh wrote: > That something appears "open" to > contributing, means nothing by itself. yes, it does (see below). > I've seen more than one open > source projects that claimed to be "open", only to see patches to > correct design problems, persistently ignored for personal or political > reasons -- even when such flaws clearly couldn't be justified on > objective, sound, engineering principles. That's the idea behind "open source" - if you don't like what a program is doing, or when you have a special reason for the tool behaving different in your personal, political, or even commercial environment, then take the sources, modify them to your needs and use the changed tool. Even spread it around if you like (with the changed sources of course ...). Everybody knows there are other tools with other licenses where you don't get this chance. [hey, now I also avoid using 'you', funny. So let's use that *BAD* word again. ;-) ] The problem comes when you want to have your change in *that* package everyone is using, e.g. coreutils. As there are *many* users, these tools have to do the right thing for them all. And if the change would break what many users are expecting from that tool, or even what they are used to, then there must be very good reasons to do the change. Going back to #12794: there were several misunderstanding in the discussion, which IMO are all clear now: Bob referred to a mail of Padraig which never reached Ganton. Well ... let's move on. Re. dd's output: comparing that little glitch regarding output behavior we are used from newer tools with the power of dd, I must say I'm very happy how it is. And if somebody does't like that, then [s]he is free to use the new "status=none" (unless using a non-GNU dd, of course). Have a nice day, Berny
bug#12830: charset.alias incorrect path
Matias A. fonzo wrote: > El Thu, 08 Nov 2012 08:11:37 +0100 > Jim Meyering escribió: >> [..] >> >> +from the "lib/" prefix-adding heuristic. Reported by Matias >> A. fonzo >> +in http://bugs.gnu.org/12206. >> + >> [...] > > Reported here in http://bugs.gnu.org/12830 Good catch. I've corrected both the log and ChangeLog locally. Testing momentarily...
bug#12841: Make for AIX 8.20 fails with undefined symbol .rpl_malloc
root@x104:[/data/prj/gnu/coreutils/coreutils-8.20]export FORCE_UNSAFE_CONFIGURE=1 root@x104:[/data/prj/gnu/coreutils/coreutils-8.20]CFLAGS=-O2 -qcpluscmt ./configure \ --prefix=/opt \ --sysconfdir=/var/coreutils/etc \ --sharedstatedir=/var/coreutils/com \ --localstatedir=/var/coreutils \ --mandir=/usr/share/man \ > build/aix/configure.out configure: WARNING: libattr development library was not found or not usable. configure: WARNING: GNU coreutils will be built without xattr support. configure: WARNING: libcap library was not found or not usable. configure: WARNING: GNU coreutils will be built without capability support. configure: WARNING: libgmp development library was not found or not usable. configure: WARNING: GNU coreutils will be built without GMP support. + make > build/aix/make.out ld: 0711-317 ERROR: Undefined symbol: .rpl_malloc ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: *** [src/make-prime-list] Error 8 + make install DESTDIR=/var/tmp/root/coreutils-8.20.0.0 > build/aix/install.out ld: 0711-317 ERROR: Undefined symbol: .rpl_malloc ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: *** [src/make-prime-list] Error 8 make install returned an error root@x104:[/data/prj/gnu/coreutils/coreutils-8.20] root@x104:[/data/prj/gnu/coreutils/coreutils-8.20] root@x104:[/data/prj/gnu/coreutils/coreutils-8.20] Version 8.15 is the last one I packaged, and build went fine. I have also tested the build of 8.17. This completed (make install) without any noteable errors. p.s. Thought I had submitted this days ago - but it has been sitting in my Drafts folder. :(
bug#12830: charset.alias incorrect path
Jim Meyering wrote:
> Matias A. fonzo wrote:
>> El Thu, 08 Nov 2012 08:11:37 +0100
>> Jim Meyering escribió:
>>> [..]
>>>
>>> + from the "lib/" prefix-adding heuristic. Reported by Matias
>>> A. fonzo
>>> + in http://bugs.gnu.org/12206.
>>> +
>>> [...]
>>
>> Reported here in http://bugs.gnu.org/12830
>
> Good catch. I've corrected both the log and ChangeLog locally.
> Testing momentarily...
Glad I tested. That patch had no effect.
The one below does what I want.
It induces this sole difference in coreutils' Makefile.in:
-charset_alias = $(DESTDIR)$(libdir)/lib/charset.alias
+charset_alias = $(DESTDIR)$(libdir)/charset.alias
>From 86b0eb58273181fc4ef484f19b8ab835f7f392ea Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 7 Nov 2012 22:37:39 -0800
Subject: [PATCH] prefix-gnulib-mk: avoid overzealous "lib/"-prefix addition
* build-aux/prefix-gnulib-mk (prefix): Tighten a regexp to require
white space before each of the special-cased file names, to avoid
adding "lib/" after $(libdir)/. Reported by Matias A. fonzo
in http://bugs.gnu.org/12830.
---
ChangeLog | 8
build-aux/prefix-gnulib-mk | 6 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 9817769..a742d0a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2012-11-08 Jim Meyering
+
+ prefix-gnulib-mk: avoid overzealous "lib/"-prefix addition
+ * build-aux/prefix-gnulib-mk (prefix): Tighten a regexp to require
+ white space before each of the special-cased file names, to avoid
+ adding "lib/" after $(libdir)/. Reported by Matias A. fonzo
+ in http://bugs.gnu.org/12830.
+
2012-11-08 Paul Eggert
fcntl-h: default O_SEARCH, O_EXEC back to O_RDONLY
diff --git a/build-aux/prefix-gnulib-mk b/build-aux/prefix-gnulib-mk
index 9b23245..7553f65 100755
--- a/build-aux/prefix-gnulib-mk
+++ b/build-aux/prefix-gnulib-mk
@@ -147,7 +147,11 @@ sub prefix ($)
{prefix_assignment($1, $2)}gem;
# These three guys escape all the other regular rules.
- s{(charset\.alias|ref-add\.sed|ref-del\.sed)}{$prefix$1}g;
+ # Require the leading white space to avoid inserting the prefix
+ # on a line like this:
+ # charset_alias = $(DESTDIR)$(libdir)/charset.alias
+ # With $(libdir), it would be erroneous.
+ s{(\s)(charset\.alias|ref-add\.sed|ref-del\.sed)}{$1$prefix$2}g;
# Unfortunately, as a result we sometimes have lib/lib.
s{($prefix){2}}{$1}g;
--
1.8.0
