GNU bug report logs - #18642
preparing for a new release

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Norihiro Tanaka <noritnk <at> kcn.ne.jp>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#18642: closed (preparing for a new release)
Date: Tue, 07 Oct 2014 14:38:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 07 Oct 2014 23:37:33 +0900
with message-id <20141007233733.7DCF.27F6AC2D <at> kcn.ne.jp>
and subject line Re: bug#18642: preparing for a new release
has caused the debbugs.gnu.org bug report #18642,
regarding preparing for a new release
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
18642: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18642
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: bug-grep <at> gnu.org
Subject: preparing for a new release
Date: Sun, 5 Oct 2014 21:13:42 -0700

Norihiro's latest fix is for a bug that is significant enough
that I would feel remiss not to make a release soon.

Here is one patch that looks worth including:
  #17715 dfa: build struct dfamust on demand

Any other suggestions for changes to be included?

[Message part 3 (message/rfc822, inline)]

From: Norihiro Tanaka <noritnk <at> kcn.ne.jp>
To: Jim Meyering <jim <at> meyering.net>
Cc: 18642-done <at> debbugs.gnu.org
Subject: Re: bug#18642: preparing for a new release
Date: Tue, 07 Oct 2014 23:37:33 +0900

Jim Meyering <jim <at> meyering.net> wrote:
> As you know, for any bug fix, we try hard to provide the following:
> 
>   - test case
>   - NEWS entry describing the problem and identifying affected releases
>   - a commit log attributing the precise commit that introduced the bug
> 
> Can you provide at least a test case?
> 
> BTW, I still have not attributed the commit between 2.19 and 2.20
> for the most recently described (in NEWS) bug fix.

Sorry, I investigated many cases, but I couldn't find it.

When this bug is reproduced, must be s == 0 and s1 > 0 and
d->newlines[s] != d->newlines[s1].  In addition, they mustn't be
updated until reaches a next newline.

I believe that all of them is never filled at the same time.  So I think
once I close the bug without fix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.