coreutils-7.1: make check fails under RHEL4

2009-03-18 Thread Christophe LYON 

Hi all,

I have just tried to build coreutils-7.1 on a RHEL4 (32bits) machine 
(building with GCC-4.1.2).


"make check" fails on mv/part-symlink.log
The end of the log contains:
===
+ diff -u expected-7010 actual-7010
--- expected-7010   2009-03-16 15:33:22.0 +0100
+++ actual-7010 2009-03-16 15:33:22.0 +0100
@@ -30,8 +30,8 @@
 0 cp -bd rem_reg loc_sl (loc_sl loc_sl~ -> rem_reg) (rem_reg)
 1 cp -d rem_reg loc_sl [cp: `rem_reg' and `loc_sl' are the same file 
](loc_sl -> rem_reg) (rem_reg)


-0 mv loc_reg rem_sl () (rem_sl)
-0 mv -b loc_reg rem_sl () (rem_sl rem_sl~ -> dir/loc_reg)
+0 mv loc_reg rem_sl [mv: setting attribute `security.selinux' for 
`security.selinux': Operation not supported ]() (rem_sl)
+0 mv -b loc_reg rem_sl [mv: setting attribute `security.selinux' for 
`security.selinux': Operation not supported ]() (rem_sl rem_sl~ -> 
dir/loc_reg)


 1 mv rem_sl loc_reg [mv: `rem_sl' and `loc_reg' are the same file 
](loc_reg) (rem_sl -> dir/loc_reg)

 0 mv -b rem_sl loc_reg (loc_reg -> dir/loc_reg loc_reg~) ()
===

so it seems the problem has to do with selinux, but I am not familiar 
with this. How can I figure out for sure what is wrong?


Thanks,
Christophe.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-7.1: make check fails under RHEL4

2009-03-18 Thread Jim Meyering 
Christophe LYON wrote:

> Hi all,
>
> I have just tried to build coreutils-7.1 on a RHEL4 (32bits) machine
> (building with GCC-4.1.2).
>
> "make check" fails on mv/part-symlink.log
> The end of the log contains:
> ===
> + diff -u expected-7010 actual-7010
> --- expected-7010 2009-03-16 15:33:22.0 +0100
> +++ actual-7010   2009-03-16 15:33:22.0 +0100
> @@ -30,8 +30,8 @@
>  0 cp -bd rem_reg loc_sl (loc_sl loc_sl~ -> rem_reg) (rem_reg)
>  1 cp -d rem_reg loc_sl [cp: `rem_reg' and `loc_sl' are the same file
> ](loc_sl -> rem_reg) (rem_reg)
>
> -0 mv loc_reg rem_sl () (rem_sl)
> -0 mv -b loc_reg rem_sl () (rem_sl rem_sl~ -> dir/loc_reg)
> +0 mv loc_reg rem_sl [mv: setting attribute `security.selinux' for
> security.selinux': Operation not supported ]() (rem_sl)
> +0 mv -b loc_reg rem_sl [mv: setting attribute `security.selinux' for
> security.selinux': Operation not supported ]() (rem_sl rem_sl~ ->
> dir/loc_reg)
>
>  1 mv rem_sl loc_reg [mv: `rem_sl' and `loc_reg' are the same file
> ](loc_reg) (rem_sl -> dir/loc_reg)
>  0 mv -b rem_sl loc_reg (loc_reg -> dir/loc_reg loc_reg~) ()
> ===
>
> so it seems the problem has to do with selinux, but I am not familiar
> with this. How can I figure out for sure what is wrong?

Thanks for the report.
You may safely ignore that failure.
It's saying that when moving a local regular file to a remote (different
partition) symlink, with or without -b, you get an unexpected diagnostic
(about the selinux attribute-setting failure).  If you choose a partition
for which selinux support works, the test will pass.

You can do that by setting this envvar

   export CANDIDATE_TMP_DIRS=/some/other/partition/tmp

and rerunning the test.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-7.1: make check fails under RHEL4

2009-03-18 Thread Christophe LYON 



You can do that by setting this envvar

   export CANDIDATE_TMP_DIRS=/some/other/partition/tmp

and rerunning the test.



Thanks for your prompt answer.
Indeed it made the test pass.
Thanks.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: root check failed for install-C-root

2009-03-18 Thread Kamil Dudka 
I've installed Ubuntu Studio into Xen using following image:
 
http://cdimage.ubuntu.com/ubuntustudio/releases/jaunty/alpha-6/jaunty-alternate-amd64.iso

kdu...@xen92:~/coreutils$ dpkg -l libc6\*| egrep -v "^un"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
uppercase=bad)
||/ Name  Version   
Description
+++-=-=-
ii  libc6 2.9-4ubuntu2  
GNU C Library: Shared libraries
ii  libc6-dev 2.9-4ubuntu2  
GNU C Library: Development Libraries and Hea

kdu...@xen92:~/coreutils$ uname -a
Linux xen92 2.6.28-9-generic #31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 
x86_64 GNU/Linux

But the test still passes:

kdu...@xen92:~/coreutils$ sudo make -C tests check 
TESTS=install/install-C-root
make: Entering directory `/home/kdudka/coreutils/tests'
make  check-TESTS
make[1]: Entering directory `/home/kdudka/coreutils/tests'
make[2]: Entering directory `/home/kdudka/coreutils/tests'
PASS: install/install-C-root.log


 All 1 tests passed


make[2]: Leaving directory `/home/kdudka/coreutils/tests'
make[1]: Leaving directory `/home/kdudka/coreutils/tests'
make: Leaving directory `/home/kdudka/coreutils/tests'


Any idea how to reproduce the test failure?

Kamil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] maint: normalize leading-TAB indentation in Makefiles

2009-03-18 Thread Jim Meyering 
No big deal, but slightly more consistent this way...

>From e6d2d9479495dff8520e577c221d5195eb9bb48b Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Wed, 18 Mar 2009 12:20:32 +0100
Subject: [PATCH] maint: normalize leading-TAB indentation in Makefiles

* maint.mk (sc_makefile_TAB_only_indentation): New rule.
Replace each TAB+8-space sequence with two TABs.
* man/Makefile.am: Likewise.
* build-aux/check.mk: Likewise.
I used this command (run it more than once, if needed):
t=$'\t'; git grep -l -E "$t {8}"|grep -E 'Makefile|\.mk$' \
| xargs perl -pi -e 's/\t {8}/\t\t/'
---
 build-aux/check.mk |4 ++--
 maint.mk   |   12 +---
 man/Makefile.am|   14 +++---
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/build-aux/check.mk b/build-aux/check.mk
index 92935d9..5bfcc90 100644
--- a/build-aux/check.mk
+++ b/build-aux/check.mk
@@ -213,8 +213,8 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
for f in $(TEST_LOGS);  \
do  \
  case $$(sed 1q $$f) in\
-   SKIP:*|PASS:*|XFAIL:*);;\
-   *) echo; cat $$f;;  \
+   SKIP:*|PASS:*|XFAIL:*);;\
+   *) echo; cat $$f;;  \
  esac; \
done;   \
  } >$(TEST_SUITE_LOG).tmp; \
diff --git a/maint.mk b/maint.mk
index 31d75f4..0c1ad24 100644
--- a/maint.mk
+++ b/maint.mk
@@ -537,6 +537,12 @@ changelog-check:
  exit 1;   \
fi

+sc_makefile_TAB_only_indentation:
+   @grep -nE '^[ ]{8}' \
+   $$($(VC_LIST_EXCEPT) | grep -E 'akefile|\.mk$$')\
+ && { echo '$(ME): found TAB-8-space indentation' 1>&2;\
+  exit 1; } || :
+
 sc_m4_quote_check:
@grep -nE '(AC_DEFINE(_UNQUOTED)?|AC_DEFUN)\([^[]'  \
$$($(VC_LIST_EXCEPT) | grep -E '(^configure\.ac|\.m4)$$')   \
@@ -588,7 +594,7 @@ sc_makefile_path_separator_check:
 writable-files:
if test -d $(release_archive_dir); then :; else \
  for file in $(distdir).tar.gz \
- $(release_archive_dir)/$(distdir).tar.gz; do  \
+ $(release_archive_dir)/$(distdir).tar.gz; do  \
test -e $$file || continue; \
test -w $$file  \
  || { echo ERROR: $$file is not writable; fail=1; };   \
@@ -740,8 +746,8 @@ define coreutils-path-check
  && ln -sf ../src/true $(bin)/false\
  && PATH=`pwd`/$(bin):$$PATH $(MAKE) -C tests check \
  && { test -d gnulib-tests \
-&& $(MAKE) -C gnulib-tests check   \
-|| :; }\
+&& $(MAKE) -C gnulib-tests check   \
+|| :; }\
  && rm -rf $(bin)  \
  && fail=0;\
 else   \
diff --git a/man/Makefile.am b/man/Makefile.am
index 2b28052..ec5284b 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -156,13 +156,13 @@ mapped_name = `echo $*|sed 's/^install$$/ginstall/; 
s/^test$$/[/'`
  *)\
rm -f $@\
&& { echo "Updating man page $@";   \
-rm -rf $t; \
-mkdir $t;  \
-(cd $t && $(LN_S) ../../src/$(mapped_name) $*); \
-   $(PERL) -- $(srcdir)/help2man   \
---source='$(PACKAGE_STRING)'   \
---include=$(srcdir)/$*.x   \
---output=$t/$@ $t/$*;  \
+rm -rf $t; \
+mkdir $t;  \
+(cd $t && $(LN_S) ../../src/$(mapped_name) $*); \
+   $(PERL) -- $(srcdir)/help2man   \
+--source='$(PACKAGE_STRING)'   \
+--include=$(srcdir)/$*.x   \
+--output=$t/$@ $t/$*;  \
   }\
&& sed 's|$*\.td/

must use cp && rm as mv has no --no-preserve

2009-03-18 Thread jidanni 
Gentlemen, I have discovered I must use cp && rm as mv has no --no-preserve.

# touch k; mv k /cf
mv: failed to preserve ownership for `/cf/k': Operation not permitted
# touch k; cp -a --no-preserve=owner k /cf && rm k

You see, moving to VFAT, one will get that message under different
mount owners.

And the only way to avoid it is my workaround.

So do mention on the mv Info page this workaround for if you don't
like 2>&-, and don't like warnings, but like -a.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] Change 'sort' to handle fd exhaustion better.

2009-03-18 Thread Jim Meyering 
Jim Meyering wrote:
> Pádraig Brady wrote:
...
> Thanks Pádraig,
> And thanks to Paul and students.
>
> I've taken Paul's advice from the log about adding the test
> from the other patch (and then removed that sentence from the log).
>
> I left the original patch intact for now.
>
> Of the following,
>   Subject: [PATCH 2/4] tweak test
>   Subject: [PATCH 3/4] tests: add another sort/nmerge test
>   Subject: [PATCH 4/4] tests: adjust sort-continue not to fail under valgrind
>
> I expect to merge 2/4 into the original and leave 3 and 4 separate.
>
> Patch 3/4 is derived from the earlier patch.
> I removed the sort.c and tests/misc/sort-merge changes, but kept
> the new test and documentation improvements.  Also, I've added the
> five names to THANKS and changed the log to list Alexander Nguyen's
> last name.
>
> I'll wait a day or so, in case there are comments.

No comments, so I've pushed it.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ready for a bug-fix coreutils-7.2?

2009-03-18 Thread Matthew Woehlke 

Jim Meyering wrote:

I want to make a coreutils-7.2 release soon.

There are still a few minor problems we haven't been able
to reproduce (like the install-related test failure), and
some portability problems, but there have been enough real
bug fixes,

  http://git.sv.gnu.org/cgit/coreutils.git/plain/NEWS

that I don't want to wait much longer.

If you know of a bug or portability problem that hasn't
yet been addressed, please reply here.


I just fired off builds of 7.1.49-ebb9 on ten platforms. Given that I 
think there is at least one non-c99 compiler in that mix, the results 
will probably be... interesting :-). (More-so because I expect failures 
due to 'make check' being run on a known-flaky NFS volume.)


How badly do you want problems fixed before release? ;-) (And how would 
you like me to submit failure reports? One per platform?)


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

coreutils 7.1.49-ebb9 FTB x86/Solaris

2009-03-18 Thread Matthew Woehlke 

Tail of the build log below; what else would you like?

make[3]: Entering directory 
`/home/install/gnu/build/i86_solaris/coreutils-7.1.49-ebb9/src'

source='version.c' object='version.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \
cc -xc99=all  -I. -I../lib  -I../lib 
-I/home/install/gnu/i86_solaris/include   -g -c version.c

rm -f libver.a
ar cru libver.a version.o
ranlib libver.a
source='uname.c' object='uname.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \
cc -xc99=all  -I. -I../lib  -I../lib 
-I/home/install/gnu/i86_solaris/include   -g -c uname.c

"system.h", line 266: warning: implicit function declaration: MAX
source='uname-uname.c' object='uname-uname.o' libtool=no \
DEPDIR=.deps depmode=none /bin/bash ../build-aux/depcomp \
cc -xc99=all  -I. -I../lib  -I../lib 
-I/home/install/gnu/i86_solaris/include   -g -c uname-uname.c
cc -xc99=all   -g  -Wl,-z,ignore -o uname uname.o uname-uname.o libver.a 
../lib/libcoreutils.a /home/install/gnu/i86_solaris/lib/libintl.so -lc 
-R/home/install/gnu/i86_solaris/lib ../lib/libcoreutils.a

Undefined   first referenced
 symbol in file
MAX uname.o
ld: fatal: Symbol referencing errors. No output written to uname
make[3]: *** [uname] Error 1
make[3]: Leaving directory 
`/home/install/gnu/build/i86_solaris/coreutils-7.1.49-ebb9/src'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/home/install/gnu/build/i86_solaris/coreutils-7.1.49-ebb9/src'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/install/gnu/build/i86_solaris/coreutils-7.1.49-ebb9'

make: *** [all] Error 2

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

2009-03-18 Thread Matthew Woehlke 

Tail of the build log below; what else would you like?

(I'm retrying the sparc build with the Sun compiler; you /don't/ want to 
know what version of gcc this is ;-). But I don't expect success due to 
AIX having what looks like the same problem.)


 sparc/Solaris 

source='fsusage.c' object='fsusage.o' libtool=no \
DEPDIR=.deps depmode=gcc /bin/bash ../build-aux/depcomp \
gcc  -I.   -I/home/install/gnu/sun4_solaris/include   -g -O2 -c 
-o fsusage.o fsusage.c

fsusage.c: In function `get_fs_usage':
fsusage.c:100: parse error before `struct'
fsusage.c:102: `fsd' undeclared (first use in this function)
fsusage.c:102: (Each undeclared identifier is reported only once
fsusage.c:102: for each function it appears in.)
make[4]: *** [fsusage.o] Error 1
make[4]: Leaving directory 
`/home/install/gnu/build/sun4_solaris/coreutils-7.1.49-ebb9/lib'

make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/home/install/gnu/build/sun4_solaris/coreutils-7.1.49-ebb9/lib'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/home/install/gnu/build/sun4_solaris/coreutils-7.1.49-ebb9/lib'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/install/gnu/build/sun4_solaris/coreutils-7.1.49-ebb9'

make: *** [all] Error 2

 AIX 

source='fsusage.c' object='fsusage.o' libtool=no \
DEPDIR=.deps depmode=aix /bin/sh ../build-aux/depcomp \
cc -qlanglvl=ansi -qlanglvl=ansi  -I. 
-I/home/install/gnu/rs6000_aix/include   -g -c -o fsusage.o fsusage.c

"fsusage.c", line 100.3: 1506-275 (S) Unexpected text 'struct' encountered.
make[4]: *** [fsusage.o] Error 1
make[4]: Leaving directory 
`/home/install/gnu/build/rs6000_aix/coreutils-7.1.49-ebb9/lib'

make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/home/install/gnu/build/rs6000_aix/coreutils-7.1.49-ebb9/lib'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/home/install/gnu/build/rs6000_aix/coreutils-7.1.49-ebb9/lib'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/install/gnu/build/rs6000_aix/coreutils-7.1.49-ebb9'

make: *** [all] Error 2

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

coreutils 7.1.49-ebb9 FTB risc/HP-UX

2009-03-18 Thread Matthew Woehlke 

Tail of the build log below; what else would you like?

(I've *no* idea how to pass options from cc to cpp :-(. I had a similar 
problem with ncurses and was unable to figure it out; I ended up having 
to break up what cpp was seeing to get past it.)


cc   -g   -o cp cp.o copy.o cp-hash.o libver.a ../lib/libcoreutils.a 
/home/install/gnu/hp700_hpux/lib/libintl.sl ../lib/libcoreutils.a  -lsec

source='dd.c' object='dd.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc  -I. -I../lib  -I../lib 
-I/home/install/gnu/hp700_hpux/include   -g -c dd.c
cpp: "dd.c", line 281: error 4018: Macro param too large after 
substitution - use -H option.
cpp: "dd.c", line 281: error 4018: Macro param too large after 
substitution - use -H option.
cpp: "dd.c", line 281: error 4018: Macro param too large after 
substitution - use -H option.
cpp: "dd.c", line 281: error 4018: Macro param too large after 
substitution - use -H option.
cpp: "dd.c", line 281: error 4018: Macro param too large after 
substitution - use -H option.

make[3]: *** [dd.o] Error 1
make[3]: Leaving directory 
`/tmp_mnt/home/install/gnu/build/hp700_hpux/coreutils-7.1.49-ebb9/src'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/tmp_mnt/home/install/gnu/build/hp700_hpux/coreutils-7.1.49-ebb9/src'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/tmp_mnt/home/install/gnu/build/hp700_hpux/coreutils-7.1.49-ebb9'

make: *** [all] Error 2

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 7.1.49-ebb9 FTB x86/Solaris

2009-03-18 Thread Matthew Woehlke 

Matthew Woehlke wrote:

Undefined   first referenced
 symbol in file
MAX uname.o


Ah, I just found 
 which 
is probably this issue. Any chance for an updated snapshot to try out?


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ready for a bug-fix coreutils-7.2?

2009-03-18 Thread Matthew Woehlke 

Matthew Woehlke wrote:
I just fired off builds of 7.1.49-ebb9 on ten platforms. Given that I 
think there is at least one non-c99 compiler in that mix, the results 
will probably be... interesting :-). (More-so because I expect failures 
due to 'make check' being run on a known-flaky NFS volume.)


Huh. I *know* some of these boxes used to be missing c99 compilers, but 
unless it's the OSF box (which is down ATM, and therefore I am not 
building on it) I'm not seeing which. (And yes, I did finally give up on 
the OSS dinosaur ;-).) I wonder if someone's been upgrading my compilers 
without telling me...


I'm also impressed by the test suite, there seem to have been not nearly 
as many problems as I was expecting :-D. I'm waiting on FreeBSD to 
finish its run so I can post results for all platforms together (likely 
tomorrow, at which point I'll also know how Irix went).


--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"I like to think of it as 'unplanned dissonance'" -- A fellow chorister



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: misalignment in ls -l in fr_FR locale

2009-03-18 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Samuel Thibault on 3/17/2009 3:36 PM:
> Hello,
> 
> $ ls -l
> drwxr-xr-x  5 samy samy 4,0K mars 17 22:33 tmp/
> drwx--  5 samy samy 4,0K févr. 12 18:20 u/
> 
> Because in the fr_FR locale abmon does not have a constant width, the
> content of ls -l is misaligned.  Locale standards require abday to have
> a constant width, but that does not apply to abmon, so coreutils should
> take that into account.

Sounds like you are repeating the contents of this thread:

http://lists.gnu.org/archive/html/bug-coreutils/2009-03/msg00198.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknBshIACgkQ84KuGfSFAYCg2wCfd8k+YERGs64uczsPswsG+jNi
i0YAnjnGQZ847H+2oktp1lcYj3O08qc4
=n9uw
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ls - French translation of N_("%b %e %Y")

2009-03-18 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[adding bug-gnulib]

According to Stéphane Raimbault on 3/15/2009 5:09 AM:
> Yes, it's a nice and easy solution but I've already tried to use %5b
> without success on my system:
> gcc 4.3.2
> glibc 2.8 (may 2008)
> 
> gcc complains
> warning: field width used with ‘%b’ strftime format

This warning should be reported as a gcc QoI issue, now that POSIX 2008
has added field width as mandatory to strftime.  But on further reading, I
see that:

http://www.opengroup.org/onlinepubs/9699919799/functions/strftime.html

"The results are unspecified if more than one flag character is specified,
a flag character is specified without a minimum field width; a minimum
field width is specified without a flag character; a modifier is specified
with a flag or with a minimum field width; or if a minimum field width is
specified for any conversion specifier other than C , F , G , or Y ."

So I guess the gcc warning is nice if you are being portable to non-GNU
strftime; it is only a bug if gcc also issues the warning on one of the
four required specifiers.

> And the output doesn't have extra spacing when the string contains a
> French accent (bug spotted?):
> LC_TIME in french:
> Month:|juil.|
> Month:|août|

Hmm. POSIX talks about field width being interpreted as byte spacing, not
character spacing ("If the converted value... has fewer bytes than the
minimum field width..., the output shall be padded on the left").  But on
the other hand, it only talks about field width for four fields that are
solely numeric, which means it is implementation- (and locale-) defined
how width behaves on other specifiers.  So yes, I think it would be a nice
patch to teach GNU strftime to honor LC_CTYPE string width, and do
character padding rather than byte padding.  But, since gnulib shares its
strftime implementation with glibc, you may want to file an upstream bug
with glibc first to gauge whether this has a chance of being accepted.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknBtSkACgkQ84KuGfSFAYCeZQCgmSZj3QwqxkGgbTKh7fA4jO8Q
b5IAnjl9U+Gbi0T4oHmNYev/Zd0v4idm
=S5g8
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[bug #23647] 'id' not being built on OSX platforms

2009-03-18 Thread Sci_Fi 

Follow-up Comment #2, bug #23647 (project coreutils):


As I have said, both the bootvol and the pwd where things are built are both
case-SENsitive, opposite to what you have been inferring all thru-out this
bugreport.

But I think I know what happened.

On Tiger I did build GNU 'make' from CVS so we could get some updates that
Apple never did include.  It seems we used
--enable-case-insensitive-file-system for that build because Apple did,
supposedly because Apple clones INsensitive bootvols as a manufacturing
default.

Even tho we subsequently re-cloned everything using Apple System Restore
and/or their version of ditto, the HFS+-to-HFSX process should have dealt with
casing conversions as well.  Indeed I remember seeing extra processing steps
being done for that very purpose (B-records, HFS catalogs, & such).

But we never re-built 'make' afterwards to remove that flag.

That flag doesn't seem to care about the filesystem itself.  If building
'make' disturbs your makefiles like this, I would take it VERY Seriously if I
were you.  There is a reason for that flag, and if you are not directly
dealing with it inside all projects you handle…

At any rate, we are on Leopard here now, Apple's 'make' is sufficiently
current here, etc.  I think we can close this ticket, so long as it stays
archived somehow for future reference -- I do fear since Apple continues to
manufacture bootvols as INsensitive it will come up again, as will other
systems designed/installed this way.

But I strongly urge your projects be designed to deal with this casing
situation.  GNU-make has that flag for a purpose.

Thank you.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[bug #23647] 'id' not being built on OSX platforms

2009-03-18 Thread Eric Blake 

Follow-up Comment #3, bug #23647 (project coreutils):

There have been several bug reports about the behavior of GNU make's
--enable-case-insensitive-file-system configure option.  This also affects
MSYS, and was the cause of severe headaches for Autoconf, when make couldn't
tell the difference between the real file INSTALL vs. the .PHONY target
install, such that 'make install' entered an infinite loop, but ONLY if you
did an in-tree (rather than VPATH) build.  Search the bug-make and autoconf
lists for more details on why this should be reported to the make folks, and
dealt with there before deciding to even bother worrying about it on
coreutils.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils