Re: [bug #31646] grep fails to build on Solaris 10, because it lacks grep

Florin Iucha wrote: > URL: > > > Summary: grep fails to build on Solaris 10, because it lacks > grep > Project: grep > Submitted by: themage > Submitted on: Sat 13 Nov 2010 08:45:37 PM GMT >

Re: [PATCH] bootstrap: avoid broken Solaris sed

On 11/13/2010 08:30 PM, Bruno Haible wrote: > Paul Eggert wrote: >> > I suggest rewriting 'bootstrap' so that it >> > works even with standard 'sed' on Solaris. > Is this really worth the effort? In general, no; but in this particular case, the sed script is easier to understand that way. If it's

Re: [PATCH] bootstrap: avoid broken Solaris sed

Paul Eggert wrote: > I suggest rewriting 'bootstrap' so that it > works even with standard 'sed' on Solaris. Is this really worth the effort? For three years already, we have been documenting in gnulib/DEPENDENCIES that GNU sed is a "recommended" prerequisite for running gnulib-tool. Hence also a

Re: [PATCH] bootstrap: avoid broken Solaris sed

On 11/13/2010 03:18 PM, Eric Blake wrote: > +if test -x /usr/xpg4/bin/sed; then I'm leery about using XPG4 sed on Solaris. That has its own set of bugs, which in practice can bite just as often as the standard 'sed', maybe more often. One classic example: it can't handle scripts containing mo

Re: rename() over NFS

Eric Blake wrote: > For now, I'm okay with weakening the testsuite to ignore the NFS bug; > please apply this patch, but let's also document the bug. OK. Done like this: 2010-11-13 Bruno Haible rename, renameat: Document Linux bug with NFS

Re: [PATCH] bootstrap: avoid broken Solaris sed

On 11/13/2010 04:40 PM, Bruno Haible wrote: > Instead of changing every use of sed to $SED, why don't you define 'sed' > as a function? Like this: > > if test "$SED" != sed; then > sed () > { > $SED "$@" > } > fi > > This will > 1. follow the gnulib philosophy of separatio

[PATCHv2] bootstrap: avoid broken Solaris sed

* build-aux/bootstrap (SED): Filter out bad sed. (sed): New function if $SED is needed. Reported by Ralf Wildenhues, and using idea from Bruno Haible. Signed-off-by: Eric Blake --- > Instead of changing every use of sed to $SED, why don't you define 'sed' > as a function? Nice idea; here's v2 o

Re: [PATCH] bootstrap: avoid broken Solaris sed

Eric Blake wrote: > -package=`sed -n "$extract_package_name" configure.ac` || exit > +package=`$SED -n "$extract_package_name" configure.ac` || exit Instead of changing every use of sed to $SED, why don't you define 'sed' as a function? Like this: if test "$SED" != sed; then sed () {

[PATCH] bootstrap: avoid broken Solaris sed

* build-aux/bootstrap (SED): Filter out bad sed. Reported by Ralf Wildenhues. Signed-off-by: Eric Blake --- Any objections to this? I figured it was faster to do a quick filter and hard-code a working path for Solaris than to try and port the full-blown PATH search done by autoconf script in AC

Re: rename() over NFS

On 11/13/2010 07:13 AM, Bruno Haible wrote: > So, assuming Eric also agrees with approach (a), here's a proposal for > fixing the testsuite: > > > 2010-11-13 Bruno Haible > > rename, renameat: Avoid test failures at NFS mounted locations. > * tests/test-rename.h (dentry_exists, as

Re: rename() over NFS

On 11/13/2010 07:30 AM, Jim Meyering wrote: > Bruno Haible wrote: >> Jim Meyering wrote: >>> if you see ways to improve things without impacting performance >>> or maintainability, I'm all for it. >> >> Maintainability wouldn't be impacted, because the fix would be to use >> lib/rename.c, with >>

Re: [libvirt] boostrap: gzip version check problem on FreeBSD

On 11/12/2010 11:58 PM, Ralf Wildenhues wrote: > Hello, > > * Eric Blake wrote on Fri, Nov 12, 2010 at 10:40:25PM CET: >> On 11/12/2010 02:35 PM, Paul Eggert wrote: >>> On 11/12/2010 12:50 PM, Eric Blake wrote: + s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/ >>> >>> Surely that is a typ

Re: [PATCH] maint.mk: tighten "test a == b" check

On 11/13/2010 11:31 AM, Paolo Bonzini wrote: > On 11/13/2010 07:10 PM, Eric Blake wrote: >> Maybe a compromise would be to revert this, but to tighten the prohibit >> regex: >> >> prohibit='(\ variable (defaulting to ^#! */bin/sh but overridable by libvirt). Hmm; that particular libvirt file inclu

Re: rename, renameat test

On 11/12/2010 04:48 PM, Bruno Haible wrote: > Hi Eric, > > On a RHEL 5 system I was seeing these test failures: > > test-rename.h:119: assertion failed > FAIL: test-rename > test-rename.h:119: assertion failed > FAIL: test-renameat > > In the way the test case is currently written, I hav

Re: [PATCH] maint.mk: tighten "test a == b" check

On 11/13/2010 07:10 PM, Eric Blake wrote: Maybe a compromise would be to revert this, but to tighten the prohibit regex: prohibit='(\variable (defaulting to ^#! */bin/sh but overridable by libvirt). Paolo

Re: [PATCH] maint.mk: tighten "test a == b" check

On 11/13/2010 02:45 AM, Jim Meyering wrote: > I tried the latest gnulib in coreutils and saw these two > false positives: > > src/copy.c:730: test below (*wp++ == 0) would read some > uninitialized bytes > src/stty.c:1339: test would have been (ts_lines > 64k || ts_col

Re: rename() over NFS

Bruno Haible wrote: > Jim Meyering wrote: >> if you see ways to improve things without impacting performance >> or maintainability, I'm all for it. > > Maintainability wouldn't be impacted, because the fix would be to use > lib/rename.c, with > #define RENAME_DEST_EXISTS_BUG 1 > #define RENAME_

Re: libposix build logs

Jim Meyering wrote: > > 2010-11-12 Bruno Haible > > > > openat: Work around glibc bug with fchownat() and empty file names. > > * m4/openat.m4 (gl_FUNC_FCHOWNAT_EMPTY_FILENAME_BUG): New macro. > > (gl_FUNC_FCHOWNAT): Invoke it. > > * lib/fchownat.c (rpl_fchownat): Handle the empt

Re: rename() over NFS

Jim Meyering wrote: > if you see ways to improve things without impacting performance > or maintainability, I'm all for it. Maintainability wouldn't be impacted, because the fix would be to use lib/rename.c, with #define RENAME_DEST_EXISTS_BUG 1 #define RENAME_HARD_LINK_BUG 1 But performance

Re: libposix build logs

Bruno Haible wrote: > Gary V. Vaughan wrote: >>>ix86 SLED 10 gcc 4.1.2 (fchownat, rename, renameat) > > I'm seeing this failure on a Linux/x86 machine (SUSE Linux Enterprise Server > 10, > Linux 2.6.16.60, glibc 2.4): > > test-chown.h:79: assertion failed > FAIL: test-fchownat >

Re: m4/openat.m4 robustness

Bruno Haible wrote: > Hi Jim, > > The macros in m4/openat.m4 could be made a little more reliable: > - Before running a test program that invokes fchownat(), make sure that > glibc will declare fchownat(). > - Ensure that REPLACE_FCHOWNAT at is not set to 0 accidentally after it > has a

Re: libposix build logs

Gary V. Vaughan wrote: >>ix86 SLED 10 gcc 4.1.2 (fchownat, rename, renameat) I'm seeing this failure on a Linux/x86 machine (SUSE Linux Enterprise Server 10, Linux 2.6.16.60, glibc 2.4): test-chown.h:79: assertion failed FAIL: test-fchownat The call that fails is ASSERT (fun

m4/openat.m4 robustness

Hi Jim, The macros in m4/openat.m4 could be made a little more reliable: - Before running a test program that invokes fchownat(), make sure that glibc will declare fchownat(). - Ensure that REPLACE_FCHOWNAT at is not set to 0 accidentally after it has already been determined that its c

Re: rename() over NFS

Bruno Haible wrote: > [bug-coreutils readers: This is a reply to > ]. > > Paul Eggert wrote: >> > What should we do? >> > a) Patch the test so that it uses a readdir() loop to detect the absence >> > of >> > the file even

Re: rename() over NFS

[bug-coreutils readers: This is a reply to ]. Paul Eggert wrote: > > What should we do? > > a) Patch the test so that it uses a readdir() loop to detect the absence > > of > > the file even when stat() pretends it's still

[PATCH] tests: avoid test failure on Solaris 10 due to lack of PATH export

This was the sole gnulib-test failure for coreutils on Solaris 10: --- - 2010-11-13 04:49:33.563680600 -0700 +++ update-copyright.test-ex-stderr 2010-11-13 04:49:33.544805400 -0700 @@ -1,2 +1 @@ -update-copyright.test-ex.4: warning: FSF copyright statement not found -upda

Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f

Ralf Wildenhues wrote: > * Jim Meyering wrote on Sun, Nov 07, 2010 at 12:22:13PM CET: >> Ralf Wildenhues wrote: >> > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: >> >> Ralf Wildenhues wrote: >> >> > - Posix does not require IFS to be set upon script startup. It >> >> > only require

[PATCH] maint.mk: tighten "test a == b" check

I tried the latest gnulib in coreutils and saw these two false positives: src/copy.c:730: test below (*wp++ == 0) would read some uninitialized bytes src/stty.c:1339: test would have been (ts_lines > 64k || ts_cols > 64k || ts_cols == 0). maint.mk: use "test x = x