From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4610 invoked by alias); 2 Oct 2009 15:25:33 -0000 Received: (qmail 4593 invoked by uid 22791); 2 Oct 2009 15:25:33 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Oct 2009 15:25:28 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A12DE2BAB52; Fri, 2 Oct 2009 11:25:26 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zJaiUqp0KGMg; Fri, 2 Oct 2009 11:25:26 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 666AA2BAB3D; Fri, 2 Oct 2009 11:25:26 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 904CFF5906; Fri, 2 Oct 2009 08:25:21 -0700 (PDT) Date: Fri, 02 Oct 2009 15:25:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [commit] Fix fnchange.lst Message-ID: <20091002152521.GX10338@adacore.com> References: <831vm3w9ic.fsf@gnu.org> <20090919155750.GU8910@adacore.com> <83ws3uvney.fsf@gnu.org> <20090920161048.GX8910@adacore.com> <83my4pv78y.fsf@gnu.org> <83ljk9v1qa.fsf@gnu.org> <20091001170107.GN10338@adacore.com> <83ske2ow90.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ske2ow90.fsf@gnu.org> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00056.txt.bz2 > 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