NetBSD Problem Report #45143

From jruohone@gmail.com  Thu Jul 14 10:41:32 2011
Return-Path: <jruohone@gmail.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 8EBFE63C9B4
	for <gnats-bugs@gnats.netbsd.org>; Thu, 14 Jul 2011 10:41:32 +0000 (UTC)
Message-Id: <20110714104125.D862856C5@marx.bitnet>
Date: Thu, 14 Jul 2011 13:41:25 +0300 (EEST)
From: Jukka Ruohonen <jruohonen@iki.fi>
Sender: a b <jruohone@gmail.com>
Reply-To: jruohonen@iki.fi
To: gnats-bugs@gnats.NetBSD.org
Subject: add -f to atf-run(1)
X-Send-Pr-Version: 3.95

>Number:         45143
>Category:       lib
>Synopsis:       add -f to atf-run(1)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          suspended
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 14 10:45:00 +0000 2011
>Closed-Date:    
>Last-Modified:  Thu Jul 24 15:11:53 +0000 2014
>Originator:     Jukka Ruohonen
>Release:        5.99.x
>Organization:
none
>Environment:

>Description:

A "-f" (or "force") option could be an useful addition to atf-run(1).
For instance, there are situations when one wants to run a test case
manually (without recompilation), regardless whether e.g. atf_tc_skip()
is used.

>How-To-Repeat:

man atf-run

>Fix:

NA.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: lib-bug-people->jmmv
Responsible-Changed-By: jruoho@NetBSD.org
Responsible-Changed-When: Thu, 14 Jul 2011 21:13:29 +0000
Responsible-Changed-Why:

Assign to jmmv@.



From: Julio Merino <jmmv@NetBSD.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: jruoho@NetBSD.org
Subject: Re: lib/45143 (add -f to atf-run(1))
Date: Sun, 14 Aug 2011 19:21:47 -0400

 This sounds interesting.  Could you provide a specific use case please?
  Is this only for debugging purposes?

 -- 
 Julio Merino / @jmmv

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45143 (add -f to atf-run(1))
Date: Mon, 15 Aug 2011 02:56:45 +0000

 On Sun, Aug 14, 2011 at 11:25:01PM +0000, Julio Merino wrote:
  >  This sounds interesting.  Could you provide a specific use case please?
  >   Is this only for debugging purposes?

 If you have tests that are skipped because they don't work, the
 necessary first step toward making them start working is to run them
 anyway and see what happens.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Julio Merino <jmmv@julipedia.org>
To: gnats-bugs@NetBSD.org
Cc: David Holland <dholland-bugs@netbsd.org>, jruohonen@iki.fi
Subject: Re: lib/45143 (add -f to atf-run(1))
Date: Mon, 15 Aug 2011 08:45:15 -0400

 On 8/14/11 11:00 PM, David Holland wrote:
 > The following reply was made to PR lib/45143; it has been noted by GNATS.
 >
 > From: David Holland<dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: lib/45143 (add -f to atf-run(1))
 > Date: Mon, 15 Aug 2011 02:56:45 +0000
 >
 >   On Sun, Aug 14, 2011 at 11:25:01PM +0000, Julio Merino wrote:
 >    >   This sounds interesting.  Could you provide a specific use case please?
 >    >    Is this only for debugging purposes?
 >
 >   If you have tests that are skipped because they don't work, the
 >   necessary first step toward making them start working is to run them
 >   anyway and see what happens.

 Uh... of course.  But if you are already attempting to debug a failing 
 test case, it's equally easy for you to edit the code and remove what 
 you think is faulty.  Using a "force flag" in this scenario provides 
 zero value.

 And, "are skipped because they don't work" ?  Can you provide an example 
 of that?  What kind of "don't work" are you referring to?

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: jmmv@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
	jruohonen@iki.fi
Subject: Re: lib/45143 (add -f to atf-run(1))
Date: Thu, 18 Aug 2011 11:32:43 +0300

 On Mon, Aug 15, 2011 at 12:50:03PM +0000, Julio Merino wrote:
 >  >   If you have tests that are skipped because they don't work, the
 >  >   necessary first step toward making them start working is to run them
 >  >   anyway and see what happens.
 >  
 >  Uh... of course.  But if you are already attempting to debug a failing 
 >  test case, it's equally easy for you to edit the code and remove what 
 >  you think is faulty.  Using a "force flag" in this scenario provides 
 >  zero value.
 >  
 >  And, "are skipped because they don't work" ?  Can you provide an example 
 >  of that?  What kind of "don't work" are you referring to?

 This has nothing to do with "broken tests".

 But consider an example: tests can be skipped on purpose because these cause
 a panic.  Perhaps this occurs on some emulator but not on real hardware, or
 perhaps it occurs on arch-X but not on arch-Y.  You don't always have the
 sources ready (cf.  dedicated test infrastructure systems or end-user
 systems, as advertised in tests(7)). But you still want to see whether you
 are affected.  Comparable case: if it is known that a test causes a panic on
 some, largely unknown, set of machines, you don't even want to go and try to
 "fix" the test in the source tree.

 - Jukka.

State-Changed-From-To: open->suspended
State-Changed-By: jmmv@NetBSD.org
State-Changed-When: Sat, 14 Jul 2012 19:46:54 +0000
State-Changed-Why:
Wow, I had forgotten about this trivial request.  Tracking in:

http://code.google.com/p/kyua/issues/detail?id=38

And hopefully will be part of the next ATF release.


Responsible-Changed-From-To: jmmv->lib-bug-people
Responsible-Changed-By: jmmv@NetBSD.org
Responsible-Changed-When: Thu, 24 Jul 2014 15:11:53 +0000
Responsible-Changed-Why:


>Unformatted:

Home	PR Database Search