On Wed, Jul 23, 2008 at 7:42 AM, Xavier <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 23, 2008 at 2:01 PM, Dan McGee <[EMAIL PROTECTED]> wrote:
>>
>> It makes 'make check' (and with that, 'make distcheck', etc.) fail if
>> the pactest script returns anything but zero. I've had this change in
>> a local branch for ages, but we need something else- a way to indicate
>> known failure in pactest so we can (at least temporarily) continue on
>> when our 5 or 6 known failures happen.
>>
>
> Is it possible to just go ahead with that for now or not?
> Would it be a problem if make check failed, even if they are all known 
> failures?
> I am afraid I don't know much about make check / make distcheck / etc,
> so I am asking.
I'd really rather not break make distcheck- its one less thing for me
to worry about when packaging everything up if that works.

> I think it would be neat to be able to write a very simple bisect
> script checking for a specific pactest failure, that is, being able to
> just put pactest/pactest.py -p src/pacman/pacman -t /path/to/pactest
> in the bisect script, and it would simply work.

I was thinking of adding some kind of "self.knownoutcome" flag to
pactest, and have that basically suppress the return code incrementing
if it was set to "fail" or something. (or just
self.knownfailure=true.) Does that make sense to anyone? The problem
is right now we have no way of distinguishing from fails like
fileconflict 001 & 002 (which we know will fail from now until they
are fixed) from fails that pop up after a patch has been applied. The
second ones are the regressions and the ones we really care about; the
first are not quite as important in a normal run of pactest.

-Dan

_______________________________________________
pacman-dev mailing list
[email protected]
http://archlinux.org/mailman/listinfo/pacman-dev

Reply via email to