Re: really weird build problem on MacOSX/Tiger 10.4.11

2008-06-19 Thread Jim Meyering
> I'm attaching a shortened make warning showing a problem with ID vs
> id under the src subdir, along with an ls listing of that same
> subdir.  We're unable to get the final linked exe for id created
> there.  The HFS+ build volume is "case sensitive", as is the boot

Thanks for the report.  However, ...

You are using a case-INsensitive file system.
Because of that, the default rule generated by automake
for ID (created by mkid) is conflicting with coreutils'
rule for "id" the program.

I suggest you build using a case sensitive file system.
...
> $ make -w
> make: Entering directory 
> `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src'
> Makefile:2050: warning: overriding commands for target `ID'
> Makefile:1569: warning: ignoring old commands for target `ID'


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


Re: "\.1" entries in Makefile $MAN variable (Solaris 9)

2008-06-19 Thread Jim Meyering
"Poor Yorick" <[EMAIL PROTECTED]> wrote:
> installing coreutils-6.12 on SunOS 5.9, with gcc-4.2.2 and gnu ld, Makefile
> contains unexpected "\.1" entries in Makefile:
>
> MAN = uname.1
> chroot.1
...
Thanks for the report.

> for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
> | sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
> | tr -s '\\015\\012' '  '`; do
>   gl_ADD_PROG([optional_bin_progs], $gl_i)
> done
>
> With solaris "tr", the following command leaves the backslash in the output.
> It seems to have too many backslashes, and the number of spaces in the second
> argument of the "tr" command does not match the number of characters in the
> first argument:
>
> bash-2.05$ echo $'foo \\ \012 bar'  | tr -s '\\015\\012' '  '
> foo \
>  bar

That's not the same context as the above.
In the for loop above, the tr use is within a `...` context.
In *that* case, you'll find the extra backslashes are required.

> The following patch seems to work:
...
> -  | tr '\015\012' ' '; echo`
> +  | tr '\015\012' '  '; echo`

That is the part that was required.
Both tr-related problems were already fixed in git.

  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=5f47278372
  http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=8253a9aeb4

You might want to try the latest snapshot next time,

  http://meyering.net/cu/coreutils-ss.tar.gz
  http://meyering.net/cu/coreutils-ss.tar.lzma


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


Re: su operation on RHES V5.2

2008-06-19 Thread Jim Meyering
"Licause, Al" <[EMAIL PROTECTED]> wrote:
> A few days ago, I sent an e-mail regarding the behaviour of
> su - usernameas seen in Redhat enterprise edition v5 update 2.
>
> Briefly if you su - username and that user name is an ldap user,
> no action appears to be taken.   The log shows the user was accessed
> then immediately disconnected.
>
> We have since found that if the nscd daemon is running, the su - username
> command works for ldap users. But as soon as nscd is stopped, the command
> again fails to take any action.
>
> We also reported that if su is run with strace, the command also succeeds.
>
> Can you tell us if this is expected behaviour ?

Thanks for the report.
However, upstream coreutils is phasing out support for "su",
and in fact, with the latest version, coreutils-6.12, it
doesn't even install that program, by default.

Since strace appears not to be useful, the next step is usually
to run su via a debugger like gdb.


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


"\.1" entries in Makefile $MAN variable (Solaris 9)

2008-06-19 Thread Poor Yorick
installing coreutils-6.12 on SunOS 5.9, with gcc-4.2.2 and gnu ld, Makefile
contains unexpected "\.1" entries in Makefile:


MAN = uname.1
chroot.1
hostid.1
nice.1
who.1
users.1
pinky.1
uptime.1
stty.1
df.1

chcon.1
chgrp.1
chown.1
chmod.1
cp.1
dd.1
dircolors.1
du.1
\.1
install.1
link.1
ln.1
dir.1
vdir.1
ls.1
mkdir.1
\.1
mkfifo.1
etc...




It seems there is a chicken and egg problem with the tr command on line 261 of
configure.ac.  One might be installing coreutils on Solaris to get a working
version of "tr", but a working version of "tr" is needed to install coreutils:

for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
| sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
| tr -s '\\015\\012' '  '`; do
  gl_ADD_PROG([optional_bin_progs], $gl_i)
done

With solaris "tr", the following command leaves the backslash in the output.
It seems to have too many backslashes, and the number of spaces in the second
argument of the "tr" command does not match the number of characters in the
first argument:

bash-2.05$ echo $'foo \\ \012 bar'  | tr -s '\\015\\012' '  '
foo \
 bar

In fact, the example above does not even work with gnu tr 6.12:

bash-2.05b$ echo $'foo \\ \012 bar'  | tr -s '\\015\\012' '  '
foo
 bar

but at least it got rid of the backslash.

The following command produces the same usable output on Linux with gnu tr 6.12 
as well as on Solaris with Solaris tr:

bash-2.05b$ env 
PATH=/grid/gro/vol/gbl_statcomp_devel/x86-32-linux/bin:"$PATH" echo $'foo \\ 
\012 bar'  | tr -s '\015\012\\' '   '
foo bar

The following patch seems to work:


--- configure.ac2008-06-19 21:29:20 -04:00
+++ configure.ac.new2008-06-19 21:25:23 -04:00
@@ -258,7 +258,7 @@
 v=EXTRA_PROGRAMS
 for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
 | sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
-| tr -s '\\015\\012' '  '`; do
+| tr -s '\015\012\\' '   '`; do
   gl_ADD_PROG([optional_bin_progs], $gl_i)
 done

@@ -267,7 +267,7 @@
 v=no_install__progs
 t=`sed -n '/^'$v' =/,/[[^\]]$/p' $mk \
 | sed 's/^  *//;/^\$.*/d;/^'$v' =/d' \
-| tr -s '\\015\\012' '   '`
+| tr -s '\015\012\\' '   '`
 # Remove any trailing space.
 no_install_progs_default=`echo "$t"|sed 's/ $//'`

@@ -309,11 +309,11 @@
   *)INSTALL_SU=no ;;
 esac

-MAN=`echo "$optional_bin_progs "|sed 's/ /.1 /g;s/ $//'|tr -d '\\015\\012'`
+MAN=`echo "$optional_bin_progs "|sed 's/ /.1 /g;s/ $//'|tr -d '\015\012'`

 # Change ginstall.1 to "install.h" in $MAN.
 MAN=`for m in $MAN; do test $m = ginstall.1 && m=install.1; echo $m; done \
-  | tr '\015\012' ' '; echo`
+  | tr '\015\012' '  '; echo`

 # Remove [.1, since writing a portable rule for it in man/Makefile.am
 # is not practical.  The sed LHS below uses the autoconf quadrigraph


--
yorick


___
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

2008-06-19 Thread Sci_Fi

URL:
  

 Summary: 'id' not being built on OSX platforms
 Project: GNU Core Utilities
Submitted by: sci_fi
Submitted on: Friday 06/20/2008 at 01:31
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:


Hi,

I’m attaching a shortened make warning showing a problem with ID vs id
under the src subdir, along with an ls listing of that same subdir.  We’re
unable to get the final linked exe for id created there.  The HFS+ build
volume is “case sensitive”, as is the boot volume (where we’ll install
everything).  As you can see, this particular make is with
coreutils-6.12.29-a16be – I went back to ‘stable’ 6.12, 6.10, and 6.9,
to discover they are _all_ doing this.  I don’t know how much further back
this bug has been occurring.  Since id is not being newly built here, of
course our $PATH ends up finding Apple’s original id in /usr/bin dated
2006-08-19, a “universal binary”.  Apple’s id syntax does not accept the
--version and some other switches that are in coreutils test suites, so we end
up having at least four related failures there.

Please let me know what we can do to fix this.  Thank you very much.





___

File Attachments:


---
Date: Friday 06/20/2008 at 01:31  Name:
coreutils-6.12.29-a16be_Tiger_buildproblem.txt  Size: 21kB   By: sci_fi



___

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


Request for improving 'date' command

2008-06-19 Thread Ghassem Tofighi
Hi
I'm a Persian Linux user. I saw in date manual that you are the
developer of date.
As you know there are some other calendars in the world that are used vastly.
In Iran and some another country we use jalali calendar, in Israel
people use jewish calendar and in Arabic country people use hijri
calendar.

I want from you to add some options to the date command that we can
use them in our commands.
for example :

date -j for jalali date
and
date -h for hijri date

I attached two basic codes for jalali and hijri calendar, and you can
use them for that purpose.
Thanks

-- 
--
Ghassem Tofighi
http://ght.ir
I'm available with my Email...Trust me !
[EMAIL PROTECTED]
Don't break Hearts, Please !
---
--


hdate.c
Description: Binary data


jdate.c
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: error building coreutils on Solaris 9 - Makefile:541: *** missing separator

2008-06-19 Thread Eric Blake

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Poor Yorick on 6/19/2008 4:20 PM:
|
| The following patch eliminates the newlines:
| -  | tr '\015\012' ' '; echo`
| +  | tr '\015\012' '  '; echo`

Thanks for the report.  However, this has been previously reported, and
the same patch already exists in git.

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

Eric Blake [EMAIL PROTECTED]
-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

iEYEARECAAYFAkha+kwACgkQ84KuGfSFAYByeACfRnzB82BoXXm1gOrxjPjAwQQ9
N7IAn3wkjv7mzC+WBycomF/9mCf4pcl/
=FSNX
-END PGP SIGNATURE-


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


error building coreutils on Solaris 9 - Makefile:541: *** missing separator

2008-06-19 Thread Poor Yorick
installing coreutils-6.12 on SunOS 5.9, with gcc-4.2.2 and gnu ld, "make" fails
because there are newlines in the @MAN@ variable:

Makefile:541: *** missing separator.  Stop.

The following patch eliminates the newlines:


--- configure.ac2008-06-18 19:05:11 -04:00
+++ configure.ac.new2008-06-19 13:47:20 -04:00
@@ -313,7 +313,7 @@

 # Change ginstall.1 to "install.h" in $MAN.
 MAN=`for m in $MAN; do test $m = ginstall.1 && m=install.1; echo $m; done \
-  | tr '\015\012' ' '; echo`
+  | tr '\015\012' '  '; echo`

 # Remove [.1, since writing a portable rule for it in man/Makefile.am
 # is not practical.  The sed LHS below uses the autoconf quadrigraph
EOF


-- 
Yorick


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


sort --batch-size non-merge bug

2008-06-19 Thread Bo Borgerson
Hi,

I'm embarrassed to say that I've discovered a bug in the recently added
--batch-size option of sort.

If --batch-size is used with a non-merge sort (to govern the merge of
temp files), and there is no --buffer-size set in conjunction, then the
minimum SORT_SIZE will be enforced resulting in severe performance
degradation.

I've attached a fix for this bug, including a test that exercises it.
I've also pushed to repo.or.cz.

Sorry for introducing this.

Thanks,

Bo
>From 91aa3fb5a2636dc918bafa67f3a097d646cac075 Mon Sep 17 00:00:00 2001
From: Bo Borgerson <[EMAIL PROTECTED]>
Date: Thu, 19 Jun 2008 15:37:21 -0400
Subject: [PATCH] sort: Fix bug where --batch-size option shrank SORT_SIZE.

* src/sort.c (specify_nmerge, main): Only adjust SORT_SIZE if it's already set.
* tests/misc/sort-merge: Test bug fix.

Signed-off-by: Bo Borgerson <[EMAIL PROTECTED]>
---
 src/sort.c|   14 ++
 tests/misc/sort-merge |7 +++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/src/sort.c b/src/sort.c
index 1393521..2039dab 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1105,14 +1105,7 @@ specify_nmerge (int oi, char c, char const *s)
 	  e = LONGINT_OVERFLOW;
 	}
 	  else
-	{
-	  /* Need to re-check that we meet the minimum
-		 requirement for memory usage with the new,
-		 potentially larger, nmerge. */
-	  sort_size = MAX (sort_size, MIN_SORT_SIZE);
-
-	  return;
-	}
+	return;
 	}
 }
 
@@ -3320,6 +3313,11 @@ main (int argc, char **argv)
   files = −
 }
 
+  /* Need to re-check that we meet the minimum requirement for memory
+ usage with the final value for NMERGE. */
+  if (0 < sort_size)
+sort_size = MAX (sort_size, MIN_SORT_SIZE);
+
   if (checkonly)
 {
   if (nfiles > 1)
diff --git a/tests/misc/sort-merge b/tests/misc/sort-merge
index a2524c4..fb7c63c 100755
--- a/tests/misc/sort-merge
+++ b/tests/misc/sort-merge
@@ -27,6 +27,8 @@ my $prog = 'sort';
 # three empty files and one that says 'foo'
 my @inputs = (+(map{{IN=> {"empty$_"=> ''}}}1..3), {IN=> {foo=> "foo\n"}});
 
+my $big_input = "aaa\n" x 1024;
+
 # don't need to check for existence, since we're running in a temp dir
 my $badtmp = 'does/not/exist';
 
@@ -66,6 +68,11 @@ my @Tests =
  ['nmerge-no', "-m --batch-size=2 -T$badtmp", @inputs,
 {ERR_SUBST=>"s|: $badtmp/sort.+||"},
 {ERR=>"$prog: cannot create temporary file\n"}, {EXIT=>2}],
+
+ # This used to fail because setting batch-size without also setting
+ # buffer size would cause the buffer size to be set to the minimum.
+ ['batch-size', "--batch-size=16 -T$badtmp", {IN=> {big=> $big_input}},
+	{OUT=>$big_input}],
 );
 
 my $save_temps = $ENV{DEBUG};
-- 
1.5.4.3

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


Re: coreutils 6.12 test-suite failure

2008-06-19 Thread Jarod Wilson
On Thursday 19 June 2008 03:42:13 am Jim Meyering wrote:
[...]
> >> FAIL: misc/runcon-no-reorder.log (exit: 1)
> >> ==
> >> ...
> >
> > As expected, this one still triggers.
>
> I've changed the test to also accept that diagnostic.
> Patch below.

Patch verified, mock build doesn't fail on this test now.

[...]
> >> FAIL: cp/preserve-gid.log (exit: 1)
> >> ===
> >> ...
> >> This one was trickier.  I think it must be the case that
> >> root's primary group is 103.  The test requires that it be 0.
> >> Can you confirm?  (i.e., run id -g -- or better, id -a to get all of
> >> them) I'll either adapt the test or make it skip in that case.
> >
> > Ah, here we go... In this case, I'm doing a build in a mock chroot, as
> > the user 'mockbuild', who (within the chroot) has a uid of 0, gid of 101:
> >
> > mockbuild::0:101::/builddir:/bin/bash
>
> Good.  That's easy to accommodate.

This one also no longer triggers.

Excellent, now its time to back out the utimens{,at}() work-arounds and see 
what else we can see...

-- 
Jarod Wilson
[EMAIL PROTECTED]


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


really weird build problem on MacOSX/Tiger 10.4.11

2008-06-19 Thread sci-fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

I'm attaching a shortened make warning showing a problem with ID vs
id under the src subdir, along with an ls listing of that same
subdir.  We're unable to get the final linked exe for id created
there.  The HFS+ build volume is "case sensitive", as is the boot
volume (where we'll install everything).  As you can see, this
particular make is with coreutils-6.12.29-a16be -- I went back to
'stable' 6.12, 6.10, and 6.9, to discover they are _all_ doing
this.  I don't know how much further back this bug has been
occurring.  Since id is not being newly built here, of course our
$PATH ends up finding Apple's original id in /usr/bin dated 2006-08-
19, a "universal binary".  Apple's id syntax does not accept the --
version and some other switches that are in coreutils test suites,
so we end up having at least four related failures there.

I hope the file attachment will propagate thru here.  Please let me
know what we can do to fix this.  Thank you very much.

-BEGIN PGP SIGNATURE-
Charset: UTF8
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 3.0

wkYEARECAAYFAkhaOj4ACgkQZbt5KOxKrtRn/wCfdEdBdCS7t71qPr4Rn7J0A6ac0PUA
n32zg2Nt+RGzrXW1CF9D71EF9Wi0
=HrE4
-END PGP SIGNATURE-
$ pwd
/Users/scifi/Projects/coreutils-6.12.29-a16be/src

$ make -w
make: Entering directory `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src'
Makefile:2050: warning: overriding commands for target `ID'
Makefile:1569: warning: ignoring old commands for target `ID'
make  all-am
make[1]: Entering directory 
`/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src'
Makefile:2050: warning: overriding commands for target `ID'
Makefile:1569: warning: ignoring old commands for target `ID'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory 
`/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src'
make: Leaving directory `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src'

$ ls -alL
total 11940
drwxr-xr-x 347 scifi scifi  11798 2008-06-19 05:14 .
drwxr-xr-x  59 scifi scifi   2006 2008-06-19 00:13 ..
drwxr-xr-x 117 scifi scifi   3978 2008-06-19 00:15 .deps
-rw-r--r--   1 scifi scifi 148475 2008-06-19 05:12 ID
-rw-r--r--   1 scifi scifi 101598 2008-06-19 00:13 Makefile
-rw-r--r--   1 scifi scifi  16141 2008-06-09 03:49 Makefile.am
-rw-r--r--   1 scifi scifi 107381 2008-06-10 03:40 Makefile.in
-rwxr-xr-x   1 scifi scifi  71432 2008-06-19 00:15 [
-rwxr-xr-x   1 scifi scifi  66988 2008-06-19 00:15 base64
-rw-r--r--   1 scifi scifi   7864 2008-06-08 08:16 base64.c
-rw-r--r--   1 scifi scifi   7028 2008-06-19 00:15 base64.o
-rwxr-xr-x   1 scifi scifi  58652 2008-06-19 00:15 basename
-rw-r--r--   1 scifi scifi   3750 2008-06-08 08:16 basename.c
-rw-r--r--   1 scifi scifi   3460 2008-06-19 00:15 basename.o
-rw-r--r--   1 scifi scifi   4962 2008-06-08 08:16 c99-to-c89.diff
-rwxr-xr-x   1 scifi scifi  80332 2008-06-19 00:15 cat
-rw-r--r--   1 scifi scifi  19624 2008-06-08 08:16 cat.c
-rw-r--r--   1 scifi scifi   9768 2008-06-19 00:15 cat.o
-rwxr-xr-x   1 scifi scifi  81568 2008-06-19 00:15 chcon
-rw-r--r--   1 scifi scifi  15098 2008-06-08 17:06 chcon.c
-rw-r--r--   1 scifi scifi  10452 2008-06-19 00:15 chcon.o
-rwxr-xr-x   1 scifi scifi  85816 2008-06-19 00:15 chgrp
-rw-r--r--   1 scifi scifi   8301 2008-06-08 17:06 chgrp.c
-rw-r--r--   1 scifi scifi   7384 2008-06-19 00:15 chgrp.o
-rwxr-xr-x   1 scifi scifi  81604 2008-06-19 00:15 chmod
-rw-r--r--   1 scifi scifi  13744 2008-06-08 17:06 chmod.c
-rw-r--r--   1 scifi scifi  10256 2008-06-19 00:15 chmod.o
-rwxr-xr-x   1 scifi scifi  90132 2008-06-19 00:15 chown
-rw-r--r--   1 scifi scifi  14630 2008-06-08 17:06 chown-core.c
-rw-r--r--   1 scifi scifi   2219 2008-05-06 04:28 chown-core.h
-rw-r--r--   1 scifi scifi   6516 2008-06-19 00:15 chown-core.o
-rw-r--r--   1 scifi scifi   9998 2008-06-08 17:06 chown.c
-rw-r--r--   1 scifi scifi   8420 2008-06-19 00:15 chown.o
-rwxr-xr-x   1 scifi scifi  58500 2008-06-19 00:15 chroot
-rw-r--r--   1 scifi scifi   3103 2008-06-08 08:16 chroot.c
-rw-r--r--   1 scifi scifi   3760 2008-06-19 00:15 chroot.o
-rwxr-xr-x   1 scifi scifi  58520 2008-06-19 00:15 cksum
-rw-r--r--   1 scifi scifi   9567 2008-06-08 08:16 cksum.c
-rw-r--r--   1 scifi scifi   5612 2008-06-19 00:15 cksum.o
-rwxr-xr-x   1 scifi scifi  63016 2008-06-19 00:15 comm
-rw-r--r--   1 scifi scifi   7135 2008-06-08 08:16 comm.c
-rw-r--r--   1 scifi scifi   6144 2008-06-19 00:15 comm.o
-rw-r--r--   1 scifi scifi  67121 2008-06-08 08:16 copy.c
-rw-r--r--   1 scifi scifi   8878 2008-05-06 04:28 copy.h
-rw-r--r--   1 scifi scifi  22148 2008-06-19 00:15 copy.o
-rwxr-xr-x   1 scifi scifi 182532 2008-06-19 00:15 cp
-rw-r--r--   1 scifi scifi   4978 2008-06-03 01:50 cp-hash.c
-rw-r--r--   1 scifi scifi246 2008-03-07 10:05 cp-hash.h
-rw-r--r--   1 scifi scifi   2160 2008-06-19 00:15 cp-hash.o
-rw-r--r--   1 scifi scifi  31573 2008-06-08 09:42 cp.c
-rw-r--r--   1 scifi scifi  23680 2008-06-19 00:15 cp.o
-

Re: coreutils 6.12 test-suite failure

2008-06-19 Thread Jim Meyering
Jarod Wilson <[EMAIL PROTECTED]> wrote:
...
> Finally got around to running a new build with your follow-up patch.

Thanks for the feedback!

>> FAIL: misc/runcon-no-reorder.log (exit: 1)
>> ==
>> ...
> As expected, this one still triggers.

I've changed the test to also accept that diagnostic.
Patch below.

>> FAIL: cp/cp-a-selinux.log (exit: 1)
>> ===
...
> This one is indeed skipped.

Good!

>> FAIL: cp/preserve-gid.log (exit: 1)
>> ===
>> ...
>> This one was trickier.  I think it must be the case that
>> root's primary group is 103.  The test requires that it be 0.
>> Can you confirm?  (i.e., run id -g -- or better, id -a to get all of them)
>> I'll either adapt the test or make it skip in that case.
>
> Ah, here we go... In this case, I'm doing a build in a mock chroot, as the
> user 'mockbuild', who (within the chroot) has a uid of 0, gid of 101:
>
> mockbuild::0:101::/builddir:/bin/bash

Good.  That's easy to accommodate.

>> FAIL: rm/fail-2eperm.log (exit: 1)
>> ==
...
> But yeah, this one doesn't trigger anymore.

Thanks again.
These two just-pushed patches should solve those two remaining problems.

>From 2a113b5760306a611d4b7c9886eb13e7b521e889 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Thu, 19 Jun 2008 08:52:08 +0200
Subject: [PATCH] tests: avoid root-only test failure when run in a chroot

* tests/misc/runcon-no-reorder: Accept the diagnostic that is
produced when running in a chroot without /selinux/context.
Reported by Jarod Wilson.  Details in
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/13803/focus=13837
---
 tests/misc/runcon-no-reorder |   13 ++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/tests/misc/runcon-no-reorder b/tests/misc/runcon-no-reorder
index 07dd081..c1705e5 100755
--- a/tests/misc/runcon-no-reorder
+++ b/tests/misc/runcon-no-reorder
@@ -23,9 +23,8 @@ fi

 . $srcdir/test-lib.sh

-cat <<\EOF > exp || framework_failure
-runcon: runcon may be used only on a SELinux kernel
-EOF
+diag='runcon: runcon may be used only on a SELinux kernel'
+echo "$diag" > exp || framework_failure

 fail=0

@@ -35,6 +34,14 @@ fail=0
 # about -j being an invalid option.
 runcon $(id -Z) true -j 2> out && : > exp

+# When run on a system with no /selinux/context (i.e., in a chroot),
+# it chcon fails with this: "runcon: invalid context: \
+# root:system_r:unconfined_t:s0-s0:c0.c1023: No such file or directory"
+# That diagnostic is ok, too, so map it to the more common one.
+case `cat out` in
+  'runcon: invalid context: '*) echo "$diag" > out;;
+esac
+
 compare out exp || fail=1

 (exit $fail); exit $fail
--
1.5.6.rc3.22.g4b97c8


>From f236d5e355e23dabad7c4ef412d099b1e6f405d8 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Thu, 19 Jun 2008 09:03:41 +0200
Subject: [PATCH] tests: avoid test failure when root's primary group-ID is not 0

* tests/cp/preserve-gid: Expect a cp-without-`-p'-created file to
have a group ID of $(id -g).  Reported by Jarod Wilson.  Details in
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/13803/focus=13837
---
 tests/cp/preserve-gid |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tests/cp/preserve-gid b/tests/cp/preserve-gid
index a999322..d7f86e0 100755
--- a/tests/cp/preserve-gid
+++ b/tests/cp/preserve-gid
@@ -19,6 +19,10 @@
 . $srcdir/test-lib.sh
 require_root_

+# Record primary group number, usually 0.
+# This is the group ID used when cp (without -p) creates a new file.
+primary_group_num=$(id -g)
+
 create() {
   echo "$1" > "$1" || exit 1
   chown "+$2:+$3" "$1" || exit 1
@@ -34,7 +38,7 @@ t0() {
   if test "x$s" != "x$u $g"; then
 # Allow the actual group to match that of the parent directory
 # (it was set to 0 above).
-if test "x$s" = "x$u 0"; then
+if test "x$s" = "x$u $primary_group_num"; then
   :
 else
   echo "$0: $* $f b: $u $g != $s" 1>&2
--
1.5.6.rc3.22.g4b97c8


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