emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#16941: closed ([PATCH] tests/mb-non-UTF8-performan


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#16941: closed ([PATCH] tests/mb-non-UTF8-performance: increase timeout)
Date: Mon, 10 Mar 2014 17:35:03 +0000

Your message dated Mon, 10 Mar 2014 10:34:11 -0700
with message-id <address@hidden>
and subject line Re: bug#16941: [PATCH] tests/mb-non-UTF8-performance: increase 
timeout
has caused the debbugs.gnu.org bug report #16941,
regarding [PATCH] tests/mb-non-UTF8-performance: increase timeout
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
16941: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16941
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH] tests/mb-non-UTF8-performance: increase timeout Date: Wed, 05 Mar 2014 17:09:06 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
---
 tests/mb-non-UTF8-performance | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/mb-non-UTF8-performance b/tests/mb-non-UTF8-performance
index 282f0c4..9b581a3 100755
--- a/tests/mb-non-UTF8-performance
+++ b/tests/mb-non-UTF8-performance
@@ -26,7 +26,7 @@ require_JP_EUC_locale_
 yes $(printf '%078d' 0) | head -50000 > in || framework_failure_
 
 # Expect no match, i.e., exit status of 1.  Anything else is an error.
-timeout 4 grep -i foobar in; st=$?
+timeout 50 grep -i foobar in; st=$?
 test $st = 1 || fail=1
 
 Exit $fail
-- 
1.9.0

-- 
Andreas Schwab, SUSE Labs, address@hidden
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



--- End Message ---
--- Begin Message --- Subject: Re: bug#16941: [PATCH] tests/mb-non-UTF8-performance: increase timeout Date: Mon, 10 Mar 2014 10:34:11 -0700
On Sun, Mar 9, 2014 at 10:12 PM, Jim Meyering <address@hidden> wrote:
> Thanks again for the patch, but if I were to use it, the timeout
> would be so long that the test would mistakenly pass
> (the timeout would not trigger) even if the bug were reintroduced.
> Instead, I've rewritten the test to make it less sensitive to the
> actual hardware used to run it.  Please let me know if this works
> for you:

I've pushed that change.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]