HDTenEightyP/NetNews huggingface dataset:
From: Derek_Clegg@next.com (Derek Clegg)
Subject: Confusing message with `tar -T' in tar-1.11.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 05:53:31 GMT

Using `-T' with an empty file causes tar version 1.11.1 to print a confusing message:
  % tar -T - -cf -
  ^D
  tar: can't add file (null pointer) : Bad address

							Derek B Clegg (dclegg@next.com)

Newsgroups: gnu.utils.bug
From: neal@ctd.COMsat.COM (Neal Becker)
Subject: rcs5.6 on hpux??
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 18:19:00 GMT

Has anyone got rcs5.6 working on hpux?  We have hp9000/7xx with
hpux8.07.  I tried using cc ( you need to add #define const and
#define volatile to config.h for this to work ), I tried using gcc,
and I tried using -g , -O , and also #define has_NFS 0.  No matter
what, I have a rather nasty problem.  When I tried ci -k with a file
that didn't have header info (and that was NFS mounted) I get KERNEL
panic!

As you can imagine, this is a painful experiment.  Anyone else tried
this?


You can have a winner [in a nuclear war].
                -- George Bush, 1980.  In 1984, he said, ``I never
                   said that.''  The original interview had been taped.

Newsgroups: gnu.utils.bug
From: root@cs.uwp.edu (System Account)
Subject: tar-1.11 used to un-tar libg++-2.2.tar
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 10 Oct 1992 10:29:35 GMT

I have installed tar-1.11 and tried to use it to un-tar the libg++.2.2.tar
distribution from prep.ai.mit.edu.  I used 'tar xf libg++.2.2.tar' and got
the following message:

tar: cannot chown file neral Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
< ...it goes on for many lines here... >

Apparently current_file_name gets munged in extract.c.  I have not had
any other problems with tar-1.11, with other archives.  (I ftp'ed libg++
again, just in case there was a problem with the transfer, and got the
same result.)  It MAY be a problem with the libg++-2.2.tar distribution;
however, tar does get through the table of contents for libg++ (using
tar tf libg++-2.2.tar).

I haven't tried to look for a fix.  Any ideas?  Am I the only one who has
had a problem with this?

Newsgroups: gnu.utils.bug
From: mtranle%paris@icmv.UUCP (Minh Tran-Le)
Subject: Re: finger-1.36 minor bug on hpux
Reply-To: icmv!tranle%caliph@uunet.uu.net
Organization: IntelliCorp Inc.
Distribution: gnu
Date: Wed, 14 Oct 1992 15:19:02 GMT

neal@ctd.COMsat.COM (Neal Becker) writes:

>On hpux 8.07 finger shows entries for terminal "co" (console, I guess)
>which all show idle time of 24 years!  Anyone know why?

There a bug a in lib/os.c when it does not find a "console" location
in the file TTYLOC and try to use a hostname.

Here is a diff of my changes (the line numbers may not match exactly
because I had other changes for aix in that file):

Minh Tran-Le.

---------------------------------------------------------------------------
*** os.c-	Thu Oct  1 11:56:57 1992
--- os.c	Tue Oct 13 10:42:00 1992
***************
*** 604,610 ****
        /* If console user, and there is no entry in the list for
  	 `console', then try the local host. */
  
!       if (!(hostname = xgethostname ()))
  	if (result = lookup_tty (hostname))
  	  return (result);
  #endif
--- 609,615 ----
        /* If console user, and there is no entry in the list for
  	 `console', then try the local host. */
  
!       if (hostname = xgethostname ())
  	if (result = lookup_tty (hostname))
  	  return (result);
  #endif

Xref: sparky gnu.utils.bug:1798 gnu.announce:130
From: bson@gnu.ai.mit.edu
Newsgroups: gnu.utils.bug,gnu.announce
Subject: GNU Finger 1.36 released
Date: 9 Oct 92 20:55:32 GMT
Followup-To: gnu.utils.bug
To: info-gnu@prep.ai.mit.edu

GNU Finger 1.36 is now available for anonymous FTP from
prep.ai.mit.edu [18.71.0.38], in the file pub/gnu/finger-1.36.tar.Z.

What's new in GNU Finger 1.36:

  o  Various minor bugs fixed

  o  Should now properly handle `./configure --srcdir ...'

  o  Fixed bug that caused fingerd to hang on Suns after SIGHUP

  o  Finger now gives correct information when a user has no logins
     recorded in the Finger database.

  o  New option ``--brief'': opposite to ``--info''. Finger client can
     be built to make either be the default (see config.h). ``--brief''
     is the default as delivered.

  o  Finger should now correctly list info about what a user is doing
     when the option ``--info'' is used.

  o  Finger now correctly tells you what processes a user is running
     on SVR4 by merging what it finds in /proc with utmpx.

  o  Finger can be installed on systems where there is no host data
     in utmp; the ``Console Location'' column will just be left blank.

  o  Security issues are addressed in the manual.

  o  The shell used to run a user's .fingerrc can be hard-coded by
     editing config.h.

  o  Should now install properly on Suns where only standard SunOS
     utilities (make, sed, etc) are used.

  o  The finger client now reduces all trailing CR/LFs to LFs in all
     output.

  o  Completely new protocol for gathering host data. It's not
     backwards compatible, so all clients should have version 1.36
     installed. The new protocol is designed to be both upwards and
     downwards compatible in the future so different versions can
     coexist. There is no longer any exchange of raw binary data. See
     `INSTALL.'

  o  The finger daemon can now be instructed to make connections to the
     client hosts on a specific port (or use a particular service).
     This avoids problems on systems where port 2003 is already in
     use.

  o  New fingerd option ``--interval'' sets the wait between polls. The
     default value is found in config.h.

  o  If finger doesn't recognize a user and a file
     `/usr/local/etc/fingerdir/forwardhost' exists, then the request
     if forwarded to finger on the host specified in this file.

  o  Improved user real name matching.
Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: grep 1.6 mishandles incomplete lines
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 02:43:04 GMT

grep 1.6 mishandles files that end in a non-newline character:
it silently pretends there was a trailing newline.  The following
shell scenario illustrates the problem.  `cat' and traditional `grep'
output the incomplete line as-is; but GNU grep outputs a newline at the end.

$ echo -n x >x
$ cat x
x$ grep x x # GNU grep
x
$ /bin/grep x x # traditional grep
x$ 

Newsgroups: gnu.utils.bug
From: djm@eng.umd.edu (David J. MacKenzie)
Subject: spurious blank line from indent 1.6
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 22:25:47 GMT

GNU indent 1.6 with args "-npro -gnu" gives for this input:

typedef struct PCB
{
  int pid;			/* Process ID.  */
  unsigned ss;		/* Current top of stack.  */
  unsigned sp;
  char *stackstart;	/* Start of stack, to free later.  */
  int argc;			/* Command line args, to free later.  */
  char **argv;
} PCB;

this output.  I don't think there's supposed to be a blank line before "PCB;".

typedef struct PCB
{
  int pid;			/* Process ID.  */
  unsigned ss;			/* Current top of stack.  */
  unsigned sp;
  char *stackstart;		/* Start of stack, to free later.  */
  int argc;			/* Command line args, to free later.  */
  char **argv;
}

PCB;

--David MacKenzie

Newsgroups: gnu.utils.bug
From: uddeborg@sisu.SE (Goeran Uddeborg)
Subject: Re: finger-1.36 install?
Organization: Swedish Institute of Systems Development
Distribution: gnu
Date: Tue, 13 Oct 1992 11:42:51 GMT

In article <m0meRjd-0003TdC@neal.ctd.comsat.com> neal@ctd.COMsat.COM (Neal Becker) writes:
>Who should run in.fingerd and in.cfingerd from /etc/inetd.conf?

I use "nobody", and it seems to be enough.

Newsgroups: gnu.utils.bug
From: tmcconne@sedona.intel.com (Tom McConnell)
Subject: parallel make-3.62
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 02:58:37 GMT

  I am confused about the number of jobs that can be run when running a make
with makefiles in the subdirectories.

  If I start make with this:

    % make -j4

and there are multiple makefiles in the target,  MFLAGS will be set to "1"
via the "update_goal_chain" command.

  This was intentionally done, so this is not technically a "bug", but it
removes the usefullness of having a parallel make. Running on a four CPU
Solbourne, the compile time drops linearly with the number of processors 
(1 CPU compile time = X, 2 CPU compile time - X/2). To get this, I need to
add:

  MFLAGS = -j4

by hand to the Makefile. Otherwise MFLAGS get set to "1".

 The comment for "update_goal_chain" in remake.c reads:

/* Remake all the goals in the `struct dep' chain GOALS.  Return -1 if nothing
   was done, 0 if all goals were updated successfully, or 1 if a goal failed.
   If MAKEFILES is nonzero, these goals are makefiles, so -t, -q, and -n should
   be disabled for them unless they were also command-line targets, and we
   should only make one goal at a time and return as soon as one goal whose
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   `changed' member is nonzero is successfully made.  */

  I don't understand why I should not be able to override this on the command
line (can I?). I can (almost) understand why I would only want to follow one
subdirectory, but the way it seems to work is that when I use the makefile in
the subdirectory, MFLAGS is still "-j1", so I am no longer parallel.

    Cheers,

    Tom McConnell

 Tom McConnell          |     Internet: tmcconne@sedona.intel.com
 Intel, Corp. C3-91     |     Phone: (602)-554-8229
 5000 W. Chandler Blvd. | The opinions expressed are my own. No one in 
 Chandler, AZ  85226    | their right mind would claim them.

Newsgroups: gnu.utils.bug
From: monty@proponent.COM (Monty Solomon)
Subject: textutils 1.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 13:17:41 GMT

I get the following warnings trying to compile textutils 1.3 on the NeXT (NeXTstep  
2.1).

regex.c:61: warning: bcopy redefined
regex.c:62: warning: bcmp redefined
regex.c:63: warning: bzero redefined

system.h:68: warning: index redefined
system.h:69: warning: rindex redefined
system.h:70: warning: bzero redefined

csplit.c: In function extract_regexp:
csplit.c:1141: warning: assignment of non-const * pointer from const *

nl.c: In function build_type_arg:
nl.c:519: warning: assignment of non-const * pointer from const *

tac.c: In function main:
tac.c:161: warning: assignment of non-const * pointer from const *

tr.c: In function look_up_char_class:
tr.c:497: warning: argument passing between incompatible pointer types

---
# Monty Solomon / PO Box 2486 / Framingham, MA  01701-0405
# monty%roscom@think.com

Newsgroups: gnu.utils.bug
From: trq@dionysos.thphys.ox.ac.uk
Subject: file writing bug in sed 1.09
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 09:40:01 GMT

The following sed command
sed -n -e "s|.*typedef  *\(.*\) X*clock_t *;.*|\1|w TMP" < dummy.out
with the following dummy.out:
typedef long  clock_t;  
typedef long  time_t;   

should create a "TMP" file that contains "long".  Instead, sed 1.09
creates an empty "TMP" file.

This is for sed version 1.09 compiled with GCC version 2.2.2 on a Sun
Sparcstation ELC running SunOS 4.1.1.

The problem is that sed never closes the files it opens, so buffered
writes don't get written.  Following is a sample patch to sed.c.

Tom Quinn        Theoretical Physics, University of Oxford
Internet: 	 trq@dionysos.thphys.ox.ac.uk
JANET:    	 trq@uk.ac.ox.astro
Phone:		 44-865-273956

===================================================================
RCS file: RCS/sed.c,v
retrieving revision 1.1
diff -c -r1.1 sed.c
*** 1.1	1992/10/07 07:51:06
--- sed.c	1992/10/07 09:22:07
***************
*** 181,186 ****
--- 181,187 ----
  # define P_(s) ()
  #endif
  
+ void close_files();
  void panic P_((char *str, ...));
  char *__fp_name P_((FILE *fp));
  FILE *ck_fopen P_((char *name, char *mode));
***************
*** 401,409 ****
--- 402,422 ----
  		if(quit_cmd)
  			break;
  	}
+ 	close_files();
  	if(bad_input)
  		exit(2);
  	exit(0);
+ }
+ 
+ void close_files()
+ {
+   int nf;
+   
+   for(nf = 0; nf < NUM_FPS; nf++)
+     {
+       if(file_ptrs[nf].phile)
+ 	fclose(file_ptrs[nf].phile);
+     }
  }
  
  /* 'str' is a string (from the command line) that contains a sed command.

Newsgroups: gnu.utils.bug
From: cal@aero.org
Subject: question about multiple uses of a bison parser
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 10 Oct 1992 01:35:13 GMT

i have two questions and a bug notification for version 1.10

i am trying to use a flex and bison parser to read several files in succession,
and finding a problem with the state in which the parser is left after the
first file is read

on the second file, i get a message
	unexpected token "" at line 1
(i initialize yylineno before each parse,
and the input file is closed after each parse)

so, my two questions are:
	is this the right forum for questions of this type?
	how can i get the parser to read a real token
		instead of remembering an old one
		(which is what i think is going on)?

separately,
there appears to be a bug in the implementation of the "-t" flag -
the generated C file has a line
#define YYDEBUG
but all the tests of YYDEBUG are of the form
#if YYDEBUG != 0
which gets a "parse error" from the GNU C compiler

either the definition should say
#define YYDEBUG 1
or the tests should read
#ifdef YYDEBUG
(the former is the better solution)

when i explicitly compile the generated file with -DDYYDEBUG,
it works as i expected it to

thanx much for any help

more later,
cal

Newsgroups: gnu.utils.bug
From: neal@ctd.COMsat.COM (Neal Becker)
Subject: finger-1.36 minor bug on hpux
Organization: COMSAT Labs
Distribution: gnu
Date: Tue, 13 Oct 1992 14:33:19 GMT

Thanks for finger-1.36!  Installation was a lot easier than 1.35.  One
minor problem:

On hpux 8.07 finger shows entries for terminal "co" (console, I guess)
which all show idle time of 24 years!  Anyone know why?

Another minor install problem.  make server or make client insists on
recompiling things.  This can cause nasty root NFS access problems, if
your source directory is NFS mounted, since installation may require
root privlege.  It would be nicer to use a more traditional approach,
so that make would build all sources, and make server would only
install without modifying the source directory.


BTW - everyone knows -lPW causes problems with HPUX (/lib/libPW.a
contains definitions of some stuff you don't want along with alloca).
Some gnu installs suggest extracting alloca and making a
/usr/local/lib/liballoca.a.  I have been using this approach.
Unfortunately, gnu configure doesn't know about this.  I suggest that
configure should look for liballoca.a first, then libPW.a.  The
alternative approach (used by finger-1.36) is:

	ld ... -lPW -lc -lPW

Unfortunately, my experience is that this is not only silly, it also
doesn't always work.  I vote for supporting liballoca instead.

Newsgroups: gnu.utils.bug
From: uddeborg@sisug.sisu.SE (Goeran Uddeborg)
Subject: Some small problems with GNU finger 1.36
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 14:14:20 GMT

Here are a few bugs I found when I built finger 1.36.  I got my copy
from isy.liu.se, am using Sun 4 running SunOS 4.1.2, compiled with gcc
2.2.2.

- When I tried to make the system using GNU make, it complained it
  detected a loop when expanding macro value $(INSTALL).

- The Makefile in src didn't include dependencies on ../maildir.o for
  the programs, nor on lib/libfinger.a.

- The file doc/finger.info looks strange on line 151:

     ` 0.000000inger --info bson@gnu.ai.mit.edu'

- I compiled with INFO_IS_DEFAULT defined in config.h.  As a result,
  the command

	finger .version

  complains that user .version is unknown.  Although this is the
  normal behaviour of

	finger --info .version

  and not a bug, it's a behaviour I didn't expect.  IMHO, these
  built-in special names ought to give the same answer both in long
  and short form.

Newsgroups: gnu.utils.bug
From: rob@essex.ecn.uoknor.edu (Robert K Shull)
Subject: Re: finger-1.36 minor bug on hpxu-id
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA
Distribution: gnu
Date: Wed, 14 Oct 1992 19:56:53 GMT

neal@ctd.COMsat.COM (Neal Becker) writes:

>Thanks for finger-1.36!  Installation was a lot easier than 1.35.  One
>minor problem:

>On hpux 8.07 finger shows entries for terminal "co" (console, I guess)
>which all show idle time of 24 years!  Anyone know why?

The client end converts the two times it keeps to network order, but
the server doesn't convert them back.
The following patch to fingerd.c appears to work ok.
	Robert

===================================================================
RCS file: RCS/fingerd.c,v
retrieving revision 1.1
diff -r1.1 fingerd.c
670a671,672
>         packets[i]->login_time = ntohl (packets[i]->login_time);
>         packets[i]->idle_time = ntohl (packets[i]->idle_time);

-- 
Robert K. Shull, Sr. Applications Programmer, Engineering Computer Network
rob@mailhost.ecn.uoknor.edu
Disclaimer: OU can't afford opinions, so these must be mine.


Newsgroups: gnu.utils.bug
From: dla@se05.wg2.waii.COM (Doug Acker)
Subject: Problem compiling gs-252 on AIX machine
Followup-To: gnu.utils.bug
Reply-To: acker@se01.wg2.waii.com
Organization: Western Geophysical Exploration Products
Distribution: gnu
Date: Thu, 15 Oct 1992 15:00:25 GMT

I am trying to compile ghostscript-2.5.2 under AIX 3.2.2 and have the
following error:
      c89  -O -DSYSV -D_POSIX_SOURCE -c iinit.c
"iinit.c", line 60.2: 1506-046 (S) Syntax error.
"iinit.c", line 60.14: 1506-045 (S) Undeclared identifier op_def_table.
The error code from the last failed command is 1.

.if I commented out the offending line, it compiles, but the link fails.

-- 
Douglas L. Acker

Western Geophysical Exploration Products
Systems Engineer

Email (internal):  acker                Phone:  713-964-6128
      (Internet):  acker@wg2.waii.com

Newsgroups: gnu.utils.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: does gnu linker make binaries with undefined externals
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Wed, 14 Oct 1992 18:43:40 GMT

SunOS 4.1.x linker is making binaries with undefined externals which is quite annoying.

I recall previous behavior didn't (I think) make undefined externals except with an
option to link with errors.  

Does Gnu link do this?  Or does it not make the executable with undefined externals,
meaning the next attempt has to make the executable in link.

--
marty
leisner.henr801c@xerox.com  
Member of the League for Programming Freedom

Newsgroups: gnu.utils.bug
From: uddeborg@sisug.sisu.SE (Goeran Uddeborg)
Subject: Non-intuitive behaviour of finger 1.36
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 11:36:29 GMT

The finger program behaves a little non-intuitive when the --info flag
is given but no user is specified.  The problem gets more obvious when
compiling with INFO_IS_DEFAULT defined.

The finger server gives no reply if asked for a long listing but no
user specified (given "/W " as input).  It is thus not very useful to
call it that way.  If finger is invoked as

	finger --info

i.e. without any user specified, the info-flag is
explicitly disabled in finger.c.  If it is invoked as

	finger --info @host

it is not disabled, however.  To me, it seems a brief listing ought to
be given in both these cases.  A possible way to achieve this is
suggested in the patch below

*** /usr/local/src/gnu/finger-1.36/src/finger.c~	Thu Oct  1 20:02:07 1992
--- /usr/local/src/gnu/finger-1.36/src/finger.c	Wed Oct 14 09:48:09 1992
***************
*** 170,180 ****
  #endif
  
    if (optind >= argc)
!     {
!       options &= FACE;
! 
!       call_finger ("", options, port);
!     }
    else
      for (arg_index = optind; arg_index < argc; arg_index++)
        call_finger (argv[arg_index], options, port);
--- 170,176 ----
  #endif
  
    if (optind >= argc)
!     call_finger ("", options, port);
    else
      for (arg_index = optind; arg_index < argc; arg_index++)
        call_finger (argv[arg_index], options, port);
***************
*** 266,272 ****
      }
    else
      {
!       if (info)
  	{
  	  char *new_username = (char *)xmalloc (4 + strlen (username));
  	  strcpy (new_username, "/W ");
--- 262,268 ----
      }
    else
      {
!       if (info && *username)
  	{
  	  char *new_username = (char *)xmalloc (4 + strlen (username));
  	  strcpy (new_username, "/W ");

Newsgroups: gnu.utils.bug
From: bson@gnu.ai.mit.edu (Jan Brittenson)
Subject: Re: finger-1.36 minor bug on hpux
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 19:33:58 GMT

 >> On 13 Oct 92 14:33:19 GMT, neal@ctd.COMsat.COM (Neal Becker) said:

 >> neal> On hpux 8.07 finger shows entries for terminal "co" (console, I
 >> neal> guess) which all show idle time of 24 years!  Anyone know why?

 > I had this problem on a number of tty's using Ultrix (not just console
 > ones).  It turned out to be in.cfingerd does the conversion htonl
 > before sending it but fingerd doesn't ntohl the value read in.  Adding
 > this in fixed the problem.

   No, no, no! This is utterly and completely wrong. No such thing
should be added to fingerd. Instead, the call to htonl() should be
removed from in.cfingerd. The poll protocol has changed from 1.35 --
the idle time is now passed in ASCII, as a decimal integer, no
conversion to or from network byte ordering should be done. I just
missed removing the call to htonl(); it didn't cause any problems at
FSF because all the machines I installed it on here happened to be
big-endian. This wart will be removed in the next release, along with
a few other (reasonably minor) bugs that crept in while I was making
major changes to the code.

						-- Jan Brittenson
						   bson@gnu.ai.mit.edu

Newsgroups: gnu.utils.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: tar.texinfo bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 19:52:15 GMT

The top node does not have an up pointer to (dir).

Newsgroups: gnu.utils.bug
From: metcalf@catfish.lcs.mit.edu (Chris Metcalf)
Subject: bison 1.19 install bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 20:35:49 GMT

The Makefile.in in bison-1.19 attempts to explicitly append an
absolute pathname to another pathname.  The right thing is to
either let install default to installing in the right directory,
or perhaps explicitly extract out the basename.

*** 1.2	1992/10/10 04:25:58
--- Makefile.in	1992/10/10 04:30:28
***************
*** 108,114 ****
  	-$(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  	-chmod a+r $(mandir)/bison.$(manext)
  	for file in $(srcdir)/bison.info*; \
! 	do $(INSTALL_DATA) $$file $(infodir)/$$file; \
  	done
  
  uninstall:
--- 108,114 ----
  	-$(INSTALL_DATA) $(srcdir)/bison.1 $(mandir)/bison.$(manext)
  	-chmod a+r $(mandir)/bison.$(manext)
  	for file in $(srcdir)/bison.info*; \
! 	do $(INSTALL_DATA) $$file $(infodir); \
  	done
  
  uninstall:

--
			Chris Metcalf, MIT Laboratory for Computer Science
			metcalf@cag.lcs.mit.edu   //   +1 (617) 253-7766

Newsgroups: gnu.utils.bug