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

-----

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

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.

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

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.

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

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

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

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

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

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

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