darcs

Issue 432 don't rely on OS giving correct error message.

Title don't rely on OS giving correct error message.
Priority bug Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, fx, kowey, markstos, thorkilnaur, tommy, zooko
Assigned To fx
Topics Darcs2, SunOS

Created on 2007-04-15.14:46:12 by fx, last changed 2009-10-24.09:09:48 by admin.

Messages
msg1586 (view) Author: fx Date: 2007-04-15.14:46:09
There are still test failures with the current source.  This is on
Solaris 10 with ghc 6.4.1.  I spent a bit of time on this but haven't
been able to debug it.  Could whoever did the tests offer suggestions?

-----
rmdir.....................NOK 14#     Failed test (rmdir.pl at line 88)      
#                   '
# darcs failed:  user error (Error applying patch to working dir:
# ./foo: removeDirectory: already exists (File exists))
# This may have left your working directory an inconsistent
# but recoverable state. If you had no un-recorded changes
# by using 'darcs revert' you should be able to make your
# working directory consistent again.
# 
# 
# Pulling from "/home/fx/darcs-unstable/tests/temp1"...
# '
#     doesn't match '(?-xism:non-empty)'
rmdir.....................ok 19/0                                            
#     Failed test (rmdir.pl at line 93)
#                   '
rmdir.....................NOK 24# darcs failed:  user error (Error applying patch to working dir:
# ./foo: removeDirectory: already exists (File exists))
# This may have left your working directory an inconsistent
# but recoverable state. If you had no un-recorded changes
# by using 'darcs revert' you should be able to make your
# working directory consistent again.
# 
# 
# '
#           matches '(?-xism:.+)'
rmdir.....................ok 34/0# Looks like you failed 2 tests of 34.      
rmdir.....................dubious                                            
        Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 14, 24
        Failed 2/34 tests, 94.12% okay

-----
Output from failed query_manifest.sh:

check_manifest () {
    : > files.tmp
    echo . > dirs.tmp
    echo . > files-dirs.tmp
    for x in $1 ; do
        echo "./$x" >> files.tmp
        echo "./$x" >> files-dirs.tmp
    done
    for x in $2 ; do
        echo "./$x" >> dirs.tmp
        echo "./$x" >> files-dirs.tmp
    done
    $DARCS query manifest $3 --files --no-directories | sort > darcs-files.tmp
    $DARCS query manifest $3 --no-files --directories | sort > darcs-dirs.tmp
    $DARCS query manifest $3 --files --directories | sort > darcs-files-dirs.tmp
    for x in files dirs files-dirs ; do
        sort -o sorted-$x.tmp $x.tmp
        diff sorted-$x.tmp darcs-$x.tmp
    done
}

test $DARCS || DARCS=$PWD/../darcs

rm -rf temp
mkdir temp
cd temp
$DARCS init

check_manifest "" "" "--no-pending"
check_manifest "" "" "--pending"
touch a b
$DARCS add a
check_manifest "" "" "--no-pending"
check_manifest "a" "" "--pending"
$DARCS add b
mkdir c
check_manifest "" "" "--no-pending"
1d0
< ./a

-----
msg1923 (view) Author: kowey Date: 2007-07-23.14:47:37
Is it any better with Rob Moss's build procedure (issue435)?

./configure --prefix=/home/pgrad/rgm/local --disable-optimize --disable-mmap --
without-docs

pico autoconf.mk
  > removed -02 and -O2 flags (the -02 flags result in errors -- they aren't 
accepted as valid arguments)

make

make install
msg1937 (view) Author: fx Date: 2007-07-24.11:09:16
Eric Kow <bugs@darcs.net> writes:

> Eric Kow <eric.kow@gmail.com> added the comment:
>
> Is it any better with Rob Moss's build procedure (issue435)?

No.

I suspect this bug is actually an issue with arguments of a system
call or command on Solaris v. GNU/Linux.  I should be able to debug
it, but the Perl test stuff is rather a hurdle.

> ./configure --prefix=/home/pgrad/rgm/local --disable-optimize --disable-mmap --
> without-docs
>
> pico autoconf.mk
>   > removed -02 and -O2 flags (the -02 flags result in errors -- they aren't 
> accepted as valid arguments)

That looks pretty odd.  It looks as if the x86 haskell is broken, but
I only have sparc solaris to try.  Surely it should accept -O2 as an
arg.  Perhaps it would be instructive to run ghc -v and also figure
out whether both --disable-optimize and --disable-mmap are necessary.
msg3275 (view) Author: markstos Date: 2008-02-09.18:49:42
Fx,

Any better luck testing with a recent check-out of the darcs-unstable
repository? I've made various updates to the test suite infrastructure there,
sometimes with the goal of being more portable. 

   Mark
msg3640 (view) Author: fx Date: 2008-02-22.19:07:44
Mark Stosberg <bugs@darcs.net> writes:

> Fx,
>
> Any better luck testing with a recent check-out of the darcs-unstable
> repository? I've made various updates to the test suite infrastructure there,
> sometimes with the goal of being more portable. 

Last I tried, one of the two (?) Solaris test failures had gone in the
then-current development source.  I wonder if the remaining one is due
to Solaris being able to read directories as files, i.e. you can `cat
/tmp'.

I didn't have time/enthusiasm to debug it before I left the job with a
Solaris system on which I'd installed GHC.  I don't know whether I can
get GHC installed on the Solaris SPARC systems here to try sometime, or
get a package that I can run from ~.  I may get round to installing an
x86 Solaris virtual machine for other purposes, but presumably others
can do that if it's of interest.  Sorry I can't devote significant time
to it now.
msg3770 (view) Author: markstos Date: 2008-03-05.16:57:15
I looked at this a little last night. There does appear to be a single
Solaris-specific issue triggered by the tests. 

I couldn't pin it down to a test-issue or a darcs-issue in my initial pass. 

How about resolving this for now by marking the failing test as TODO on Solaris? 

Otherwise the tests will fail every time on Solaris, and the buildbot results to
be useful, we'll have to constantly check whether it's failing for this known
reason, or for some new unknown reason. 

    Mark
msg3772 (view) Author: droundy Date: 2008-03-05.17:25:12
On Wed, Mar 05, 2008 at 04:57:18PM -0000, Mark Stosberg wrote:
> I looked at this a little last night. There does appear to be a single
> Solaris-specific issue triggered by the tests. 
> 
> I couldn't pin it down to a test-issue or a darcs-issue in my initial pass. 
> 
> How about resolving this for now by marking the failing test as TODO on Solaris? 

I'd rather not do that without resolving what the problem is.  It sort of
defeats the purpose of having such a test.

> Otherwise the tests will fail every time on Solaris, and the buildbot results to
> be useful, we'll have to constantly check whether it's failing for this known
> reason, or for some new unknown reason. 

I'd say that unless we've got someone who's able and willing to track down
problems on Solaris, the buildbot results are unuseful, and leave it at
that.  What do we gain by todoing this test, only so that the next time an
unportable test is introduced we have to todo it as well?
-- 
David Roundy
Department of Physics
Oregon State University
msg3790 (view) Author: markstos Date: 2008-03-06.22:54:17
David Roundy wrote:
> 
> I'd say that unless we've got someone who's able and willing to track down
> problems on Solaris, the buildbot results are unuseful, and leave it at
> that.  What do we gain by todoing this test, only so that the next time an
> unportable test is introduced we have to todo it as well?

That's a legitimate question.

If we TODO test, then we have one known issue on Solaris, and any 
additional issue would come on our radar as a new issue. I can't say I'd 
take the same approach the next around. Hopefully we'll be able to pin 
down the next issue as a real bug, or even fix it.

If we do nothing, then all we know that is "Solaris is broken" from 
buildbot, whether only this test keeps failing or new tests keep failing.

Considering all the other tests pass, I believe darcs is useable on 
Solaris, but I know that if "make test" fails for any reason, that's 
enough for many users to give up on installing some software.

I also agree that it would great if a Solaris user/developer would step 
up, look into this and resolve it properly.

    Mark
msg3794 (view) Author: droundy Date: 2008-03-06.23:05:44
On Thu, Mar 06, 2008 at 10:54:18PM -0000, Mark Stosberg wrote:
> David Roundy wrote:
> > I'd say that unless we've got someone who's able and willing to track down
> > problems on Solaris, the buildbot results are unuseful, and leave it at
> > that.  What do we gain by todoing this test, only so that the next time an
> > unportable test is introduced we have to todo it as well?
> 
> That's a legitimate question.
> 
> If we TODO test, then we have one known issue on Solaris, and any 
> additional issue would come on our radar as a new issue. I can't say I'd 
> take the same approach the next around. Hopefully we'll be able to pin 
> down the next issue as a real bug, or even fix it.
> 
> If we do nothing, then all we know that is "Solaris is broken" from 
> buildbot, whether only this test keeps failing or new tests keep failing.

I'd say that this is the correct approach.  

> Considering all the other tests pass, I believe darcs is useable on 
> Solaris, but I know that if "make test" fails for any reason, that's 
> enough for many users to give up on installing some software.

Maybe.  But then again, we don't know whether make test will fail for a
user running solaris... unless you've got a solaris system and have run
make test on it.  So far, the buildbot has failed on two of two non-linux
systems.  In one of those two cases, we know that it's the buildbot's
fault, since make test succeeds when run on the system.  In the other case,
we don't know anything.  I'm not going to start a sisyphan task of todoing
all solaris test failures so as to be able to detect other test failures.

If noone is able or willing to convert the buildbot test failure into a
real bug report (and just reporting the buildbot failure does *not* count),
then I'd rather let the buildbot languish or disappear.

If noone, including the buildbot maintainer is able or willing to find out
what is going wrong, I think we're better off without the buildbot.  It
just informs us of situations where we might or might not have a bug, but
doesn't give us any ability to do anything about the situation--including
determining whether or not a bug is present.  This is just a waste of
time.

Perhaps I should also point out that there is another option:  perhaps the
test is sufficiently poorly written that noone is able to figure out what
is happening on any platform.  If that is the case, then the test should be
removed (or maybe translated into shell).  Tests that can fail without
telling us whether or not there is a bug going on are less than useful.

David
msg3797 (view) Author: zooko Date: 2008-03-07.00:40:11
I think you should distinguish, David, between you spending time on  
Red buildslaves and removing or hiding such buildslaves.

Also, I think I will work on darcs this weekend, because it now takes  
almost 2 minutes to do a normal push on the allmydata.org project,  
and this is probably too much for others to tolerate, so we might  
need to switch away from darcs-1 soon, and I would like to make  
darcs-2 as attractive of an alternative as possible.

--Z
msg3812 (view) Author: droundy Date: 2008-03-07.14:54:29
Okay, I've translated the relevant part of rmdir.pl into shell.  This should
make this easier to debug, and just plain easier to see what's happening.

David
msg3840 (view) Author: droundy Date: 2008-03-07.22:54:58
The following patch updated the status of issue432 to be resolved in the unstable branch:

* resolve issue432: don't rely on OS giving correct error message. 

You can view the patch details online here: 
http://darcs.net/cgi-bin/darcs.cgi/unstable/?c=annotate&p=20080307223559-72aca-aff1482b98ffc79dfa87a8280bf3e9d586a37c1c.gz
History
Date User Action Args
2007-04-15 14:46:12fxcreate
2007-07-16 10:56:46koweysettopic: + SunOS
nosy: droundy, tommy, beschmi, kowey, fx
title: test failures on Solaris -> test failures on Solaris (rmdir/query manifest)
2007-07-23 14:47:38koweysetstatus: unread -> unknown
messages: + msg1923
2007-07-24 11:09:18fxsetmessages: + msg1937
2008-02-09 18:49:43markstossetstatus: unknown -> testing
nosy: + markstos
messages: + msg3275
assignedto: fx
2008-02-22 19:07:46fxsetnosy: droundy, tommy, beschmi, kowey, markstos, fx
messages: + msg3640
2008-02-22 19:09:08markstossetstatus: testing -> deferred
nosy: droundy, tommy, beschmi, kowey, markstos, fx
2008-03-05 16:57:18markstossetstatus: deferred -> unknown
nosy: droundy, tommy, beschmi, kowey, markstos, fx
topic: + Darcs2
messages: + msg3770
title: test failures on Solaris (rmdir/query manifest) -> test failure on Solaris in rmdir.pl
2008-03-05 17:25:13droundysetnosy: droundy, tommy, beschmi, kowey, markstos, fx
messages: + msg3772
2008-03-06 22:54:18systemsetnosy: + system
messages: + msg3790
2008-03-06 23:05:47droundysetnosy: + zooko
messages: + msg3794
2008-03-07 00:40:13zookosetnosy: droundy, tommy, beschmi, kowey, markstos, fx, zooko, system
messages: + msg3797
2008-03-07 14:54:31droundysetnosy: droundy, tommy, beschmi, kowey, markstos, fx, zooko, system
messages: + msg3812
2008-03-07 22:54:59droundysetstatus: unknown -> resolved-in-unstable
nosy: droundy, tommy, beschmi, kowey, markstos, fx, zooko, system
messages: + msg3840
title: test failure on Solaris in rmdir.pl -> don't rely on OS giving correct error message.
2008-09-04 21:30:45adminsetstatus: resolved-in-unstable -> resolved
nosy: + dagit
2009-08-06 17:36:41adminsetnosy: + jast, Serware, dmitry.kurochkin, darcs-devel, mornfall, simon, thorkilnaur, - droundy, fx, system
2009-08-06 20:33:44adminsetnosy: - beschmi
2009-08-10 22:02:53adminsetnosy: + fx, system, - darcs-devel, jast, Serware, mornfall
2009-08-11 00:00:02adminsetnosy: - dagit
2009-08-25 17:50:35adminsetnosy: + darcs-devel, - simon
2009-08-27 14:06:32adminsetnosy: tommy, kowey, markstos, fx, darcs-devel, zooko, system, thorkilnaur, dmitry.kurochkin
2009-10-24 09:09:48adminsetnosy: - system