Re: [commit] Fix fnchange.lst

[Joel Brobecker <brobecker@adacore.com>]

> There are only a few of files in libdecnumber and gnulib, so I didn't
> think it was justified to remove them.  They do present a real
> problem.

I know, but I am trying to qualify a release, and from my perspective,
this is a known issue that is not blocking the release. So they are
a visual distraction.

> As for .cvsignore, they shouldn't present a problem because they are
> not in the tarball.  If you are running the script on the CVS sandbox,
> then I guess we need to ignore them.  I will see what I can do.

Thanks. The reason why I'm running the script on a CVS sandbox, is that
I am trying to verify that things have not regressed in that department
before making the tarballs.

> > Should we also skip testsuite files?
> 
> I don't think so.  Any conflicts cause trouble when unpacking the
> tarball on 8+3 and some older Windows systems.

Hmmm, we may have some work to do. I remember seeing some entries
for the testsuite, except I can't remember whether they were in a
section that we care about or not.

> I agree that too much noise is bad, but do we really have a lot of
> noise?  How many positives are you willing to have before they are
> noise?
> 
> > What should we do with the entries in section called:
> > "The following resolve to the same SysV file names:"
> 
> Nothing.  We don't care about this part of doschk's output.  I thought
> I made that section disappear, but it sounds like I goofed.

At the time when I ran the program, I had several pages of output
(in a 65-line terminal). It will be better once we eliminate the
SysV errors from the list. But what I'm trying to do is to automate
the task of validating the source file names for DJGPP.  I suppose
I could parse the output and eliminate the known issues, but if
you can do this exclusion from the script itself (say using a switch
to control that), then it simplifies the release process. And it helps
avoiding a silly bug in my release scripts from missing something.

-- 
Joel