monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Imminent release...


From: Stephen Leake
Subject: Re: [Monotone-devel] Imminent release...
Date: Mon, 23 Jul 2007 08:23:55 -0400
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt)

Richard Levitte <address@hidden> writes:

> Hi,
>
> I've been pondering, and it seems like monotone works as it should on
> Linux and BSD's, but not on Solaris for some mysterious reason.  The
> Vista buildbot is a bit of a joker in the midst of it all.
>
> For Windows, has anyone else built the latest head successfully, be it
> with mingw, cygwin or whatever?

I've built it, on Windows XP with mingw. It reports the following
failures:

unit tests:
    paths:system                                  FAIL
    pipe:simple_pipe                              cat: write error: Bad file 
number FAIL

./run_lua_tests:
177 empty_environment                             FAIL (line -1)
362 revert_unchanged_file_preserves_mtime         FAIL (line 24)
445 ws_ops_with_wrong_node_type                   FAIL (line 12)


paths:system has #ifdef WIN32 that uses c:/ for the root directory;
MinGW wants /c/. What is the best way to fix that?

pipe:simple_pipe (in netxx_pipe.cc) also has an #ifdef WIN32 that may
be the problem.

empty_environment fails because it is looking for libintl-8.dll; I
have libintl-2.dll. I'll see if there's an upgrade for MinGW. Is there
a Lua function that distinguishes MinGW from Cygwin from vanilla Win32?

In revert_unchanged_file_preserves_mtime, the modified time is
apparently wrong. The tester.log isn't very helpful; I'll look into it.

ws_ops_with_wrong_node_type tester.log has a monotone bug report:

mtn: fatal: std::logic_error: ../monotone/roster.hh:132: invariant 
'I(static_cast<bool>(d))' violated

I've had a brief look at the debug log; I can't seem to match that
with the tester.log.

This is from the Lua line:

-- fail to move a dir under a file
check(mtn("rename", "--bookkeep-only", "dir", "file/subdir"), 1, false, false)

I assume this should produce a nice error message, not a mtn bug
report.


The first three failures probably don't indicate serious bugs; just
the tests need to be made aware of MinGW.

I don't think modified time is important? But it must be in some way,
or there wouldn't be a test for it.

The monotone bug is annoying and should be fixed, but since it doesn't
allow erroneous behavior, I don't think it needs to hold up a release.
(My priorities change when there's a branch I want to get merged :).
I also don't see why that should be MinGW specific. I'll work on that
first, but I may not get to it until next weekend.

-- 
-- Stephe




reply via email to

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