Re: bootstrapping fails with git v1.4.4.4

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Steven Schubiger on 1/10/2008 6:33 AM:
| 228  git clone --depth 2 git://git.sv.gnu.org/gnulib ||
|
| causes trouble here.

git-clone --depth was not added until git 1.5.0.  Either upgrade git (now
at 1.5.3.8 upstream), or you must clone the entire repository by deleting
the '--depth 2' from that command.

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

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHhiA684KuGfSFAYARAgeTAJ9bGqG6T/DTC0LGtfm9+fg877ly+gCgvP0Q
HdP4NcddvX6gpmTSQMef88Q=
=sZIe
-END PGP SIGNATURE-


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

Re: bootstrapping fails with git v1.4.4.4

[Jim Meyering]

Steven Schubiger <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:~/code/foreign/coreutils$ ./bootstrap
> ./bootstrap: Bootstrapping from checked-out coreutils sources...
> ./bootstrap: getting gnulib files...
> Usage: /usr/bin/git-clone [--template=] 
> [--use-separate-remote] [--reference ] [--bare] [-l [-s]] 
> [-q] [-u ] [--origin ] [-n]  []
>
> I removed "dist-lzma" from configure.ac (as mentioned in README-hacking)
> before bootstrapping. I suspect that within 'bootstrap' the invocation of
> git-clone with the --depth parameter, i.e.
>
> 228  git clone --depth 2 git://git.sv.gnu.org/gnulib ||
>
> causes trouble here. I'm not sure whether I should update git or if this
> feature has been deprecated and removed from the git toolsuite.

Yes, do get the latest.  It's a useful feature.

There's already an implicit requirement, but that's not enough.
I've just added git to the list of tools required when building from source:

2008-01-10  Jim Meyering  <[EMAIL PROTECTED]>

* README-hacking: Add Git to the list of required tools.

diff --git a/README-hacking b/README-hacking
index 4998bb1..06d97bf 100644
--- a/README-hacking
+++ b/README-hacking
@@ -15,6 +15,7 @@ tools we depend upon, including:
 - Autoconf 
 - Bison 
 - Gettext 
+- Git 
 - Gperf 
 - Gzip 
 - Perl 
--
1.5.4.rc2.85.g71fd


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

bootstrapping fails with git v1.4.4.4

[Steven Schubiger]

[EMAIL PROTECTED]:~/code/foreign/coreutils$ ./bootstrap
./bootstrap: Bootstrapping from checked-out coreutils sources...
./bootstrap: getting gnulib files...
Usage: /usr/bin/git-clone [--template=] 
[--use-separate-remote] [--reference ] [--bare] [-l [-s]] [-q] 
[-u ] [--origin ] [-n]  []

I removed "dist-lzma" from configure.ac (as mentioned in README-hacking)
before bootstrapping. I suspect that within 'bootstrap' the invocation of
git-clone with the --depth parameter, i.e.

228  git clone --depth 2 git://git.sv.gnu.org/gnulib ||

causes trouble here. I'm not sure whether I should update git or if this
feature has been deprecated and removed from the git toolsuite.

Steven Schubiger


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

Re: tr '[:upper:]' '[:lower:]' -- misaligned construct

[Jim Meyering]

"James Youngman" <[EMAIL PROTECTED]> wrote:

> On Jan 5, 2008 11:34 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
>> diff --git a/NEWS b/NEWS
>> index 5285d51..5b1b366 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -2,6 +2,12 @@ GNU coreutils NEWS-*- 
>> outline -*-
>>
>>  * Noteworthy changes in release 6.? (-??-??) [?]
>>
>> +** Bug fixes
>> +
>> +  tr's case conversion would fail in a locale with differing numbers
>> +  of lower case and upper case characters.  E.g., this would fail:
>> +  env LC_CTYPE=en_US.iso88591 tr '[:upper:]' '[:lower:]'
>
> AIUI, that should be en_US.iso8859-1.

Thanks for mentioning that.
Can you point to a reference, or do you know of a system on which that
works but the other doesn't?  I chose the name from the output of
"locales -a".


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

Re: tr '[:upper:]' '[:lower:]' -- misaligned construct

[Pádraig Brady]

Jim Meyering wrote:
> "James Youngman" <[EMAIL PROTECTED]> wrote:
> 
>> On Jan 5, 2008 11:34 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
>>> diff --git a/NEWS b/NEWS
>>> index 5285d51..5b1b366 100644
>>> --- a/NEWS
>>> +++ b/NEWS
>>> @@ -2,6 +2,12 @@ GNU coreutils NEWS-*- 
>>> outline -*-
>>>
>>>  * Noteworthy changes in release 6.? (-??-??) [?]
>>>
>>> +** Bug fixes
>>> +
>>> +  tr's case conversion would fail in a locale with differing numbers
>>> +  of lower case and upper case characters.  E.g., this would fail:
>>> +  env LC_CTYPE=en_US.iso88591 tr '[:upper:]' '[:lower:]'
>> AIUI, that should be en_US.iso8859-1.
> 
> Thanks for mentioning that.
> Can you point to a reference, or do you know of a system on which that
> works but the other doesn't?  I chose the name from the output of
> "locales -a".

en_US.iso88591 looks to be the canonicalized internal name.
I.E. lower-cased and with all '-' stripped.
For example the following does not generate errors:

LANG=en_US.iSo-8-859-1 locale >/dev/null

I would suggest using the format as specified in locale.alias,
i.e. en_US.ISO-8859-1

Pádraig.


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

[bug #21999] rm fails completely on systems that don't have dirfd()

[anonymous]

URL:
  

 Summary: rm fails completely on systems that don't have
dirfd()
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Thursday 01/10/08 at 16:04 UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Due to the hard requirements in remove.c, rm completely fails to work on
systems that don't implement dirfd().






___

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 #21999] rm fails completely on systems that don't have dirfd()

[Paul Eggert]

Follow-up Comment #1, bug #21999 (project coreutils):

There's a dirfd substitute for systems that lack it, so it shouldn't be a
problem. Which version of coreutils are you using, exactly? And which system
is failing? Can you please try the latest snapshot of coreutils, at
?

___

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 #21999] rm fails completely on systems that don't have dirfd()

[Alan Hourihane]

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

Oh, I'm using coreutils-6.9 currently.

___

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 #21999] rm fails completely on systems that don't have dirfd()

[Alan Hourihane]

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

In config.h I see this

/* the name of the file descriptor member of DIR */
/* #undef DIR_FD_MEMBER_NAME */

#ifdef DIR_FD_MEMBER_NAME
# define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME)
#else
# define DIR_TO_FD(Dir_p) -1
#endif

And therefore dirfd() is implemented with returning DIR_TO_FD(Dir_p) -1.

Doing that and remove.c fails completely.


___

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

Re: [bug #21999] rm fails completely on systems that don't have dirfd()

[Jim Meyering]

Alan Hourihane <[EMAIL PROTECTED]> wrote:
> And therefore dirfd() is implemented with returning DIR_TO_FD(Dir_p) -1.

Thanks.
We need to know why it ends up using that value.
Please post your config.log file and tell us what type of
system you're using.


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

[bug #21999] rm fails completely on systems that don't have dirfd()

[Alan Hourihane]

Follow-up Comment #4, bug #21999 (project coreutils):

I guess if DIR_TO_FD() is -1 and dirfd() is not available, then configure
should really abort.

The system I'm using is a little obscure, so it's not mainstream, so i guess
I'll have to fix it's libc instead.

___

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

Re: [bug #21999] rm fails completely on systems that don't have dirfd()

[Jim Meyering]

Alan Hourihane <[EMAIL PROTECTED]> wrote:
> I guess if DIR_TO_FD() is -1 and dirfd() is not available, then configure
> should really abort.
>
> The system I'm using is a little obscure, so it's not mainstream, so i guess
> I'll have to fix it's libc instead.

Look at coreutils' m4/fpending.m4.
If your  has a non-opaque FILE type,
then it should be easy to add a line or two
to make that gl_FUNC_FPENDING macro work on your system.


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

[PATCH] df: add `--total' option

[Steven Schubiger]

Given that the attached patch works, except that the SIZE argument 
specified to -B/--block-size parameter doesn't currently make it 
into the totals, I'd like to hear some opinions how you would make it
happen (I have some ideas, but I'd certainly prefer to have some peer-
driven effort).

Steven Schubiger

diff --git a/src/df.c b/src/df.c
index f0fdcd7..e010f87 100644
--- a/src/df.c
+++ b/src/df.c
@@ -46,6 +46,20 @@ char *program_name;
 /* If true, show inode information. */
 static bool inode_format;
 
+/* If true, output disk "usage" summary. */
+static bool summarize_total;
+
+/* The summary container. */
+struct summary_total
+{
+  unsigned long blocks;
+  unsigned long used;
+  unsigned long avail;
+  int spacing;
+  int width;
+  int adjustment;
+} summary;
+
 /* If true, show even file systems with zero size or
uninteresting types. */
 static bool show_all_fs;
@@ -122,6 +136,7 @@ static struct option const long_options[] =
 {
   {"all", no_argument, NULL, 'a'},
   {"block-size", required_argument, NULL, 'B'},
+  {"total", no_argument, NULL, 'c' },
   {"inodes", no_argument, NULL, 'i'},
   {"human-readable", no_argument, NULL, 'h'},
   {"si", no_argument, NULL, 'H'},
@@ -226,6 +241,17 @@ excluded_fstype (const char *fstype)
   return false;
 }
 
+static int
+integer_length (unsigned long num)
+{
+  int length = 1;
+  while ((num /= 10) >= 1) 
+{
+  length++;
+}
+  return length;
+}
+
 /* Like human_readable (N, BUF, human_output_opts, INPUT_UNITS, OUTPUT_UNITS),
except:
 
@@ -265,7 +291,7 @@ df_readable (bool negative, uintmax_t n, char *buf,
 static void
 show_dev (char const *disk, char const *mount_point,
  char const *stat_file, char const *fstype,
- bool me_dummy, bool me_remote)
+ bool me_dummy, bool me_remote, bool show_summary)
 {
   struct fs_usage fsu;
   char buf[3][LONGEST_HUMAN_READABLE + 2];
@@ -281,6 +307,10 @@ show_dev (char const *disk, char const *mount_point,
   uintmax_t used;
   bool negate_used;
   double pct = -1;
+  char *buf_readable[3];
+
+  if (show_summary)
+goto output_numbers;
 
   if (me_remote & show_local_fs)
 return;
@@ -326,18 +356,33 @@ show_dev (char const *disk, char const *mount_point,
   size_t disk_name_len = strlen (disk);
   size_t fstype_len = strlen (fstype);
   if (disk_name_len + fstype_len < 18)
-   printf ("%s%*s  ", disk, 18 - (int) disk_name_len, fstype);
+{
+  printf ("%s%*s  ", disk, 18 - (int) disk_name_len, fstype);
+  summary.spacing = disk_name_len + (18 - (int) disk_name_len + 2);
+}
   else if (!posix_format)
-   printf ("%s\n%18s  ", disk, fstype);
+{
+ printf ("%s\n%18s  ", disk, fstype);
+  summary.spacing = 20;
+}
   else
-   printf ("%s %s", disk, fstype);
+{
+ printf ("%s %s", disk, fstype);
+  summary.spacing = disk_name_len + 1 + fstype_len;
+}
 }
   else
 {
   if (strlen (disk) > 20 && !posix_format)
-   printf ("%s\n%20s", disk, "");
+{
+ printf ("%s\n%20s", disk, "");
+  summary.spacing = 20;
+}
   else
-   printf ("%-20s", disk);
+   {
+  printf ("%-20s", disk);
+  summary.spacing = 20;
+   }
 }
 
   if (inode_format)
@@ -375,6 +420,7 @@ show_dev (char const *disk, char const *mount_point,
   negate_available = (fsu.fsu_bavail_top_bit_set
  & (available != UINTMAX_MAX));
   available_to_root = fsu.fsu_bfree;
+ 
 }
 
   used = UINTMAX_MAX;
@@ -384,15 +430,33 @@ show_dev (char const *disk, char const *mount_point,
   used = total - available_to_root;
   negate_used = (total < available_to_root);
 }
-
-  printf (" %*s %*s %*s ",
- width + col1_adjustment,
- df_readable (false, total,
-  buf[0], input_units, output_units),
- width, df_readable (negate_used, used,
- buf[1], input_units, output_units),
- width, df_readable (negate_available, available,
- buf[2], input_units, output_units));
+  
+  output_numbers:
+  if (!show_summary)
+{
+  buf_readable[0] = (char *) df_readable (false, total, buf[0], 
input_units, output_units);
+  buf_readable[1] = (char *) df_readable (negate_used, used, buf[1], 
input_units, output_units);
+  buf_readable[2] = (char *) df_readable (negate_available, available, 
buf[2], input_units, output_units);
+  printf (" %*s %*s %*s ",
+ width + col1_adjustment, buf_readable[0],
+ width, buf_readable[1],
+ width, buf_readable[2]);
+  summary.blocks += atol (buf_readable[0]);
+  summary.used += atol (buf_readable[1]);
+  summary.avail += atol (buf_readable[2]);
+  summary.width = width;
+  summary.adjustment = col1_adjustment;
+}
+  else
+{
+  printf ("%*s %*s%lu %*s%lu %*s%lu ",
+ summary.spacing, "",
+ (su

[bug #21999] rm fails completely on systems that don't have dirfd()

[Alan Hourihane]

Follow-up Comment #5, bug #21999 (project coreutils):

Just checked other programs, and ls.c deals with dirfd() returning -1 and
falls back to using an alternative.

It seems to me that remove.c doesn't check the return status of dirfd() ever
failing and tries to do bad things...

For example, remove.c does this...

AD_push (dirfd (dirp), ds, dir, dir_st);

and then later it would try to fstat the file descriptor returned by dirfd()
being -1 gets bogus results.

Anyway, not to worry. I'll fix libc and implement dirfd() instead.



___

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