Hi there,

I'm using darcs 1.0.9rc2 on my home PC (WinXP) and on a server (SunOS 5.9  
x86).
When I try to push patches from my home PC to the server over SSH, I get  
the
error message:

darcs failed:  Malformed patch bundle: '[Initial revision.' is not  
'Context:'

where "Initial revision." is the name of the patch I am trying to push.  
I've
tried google, but all I can find are messages regarding "darcs send", not
"darcs push".

cheers,
Rob

I also tried pushing the patch an Ubuntu box running darcs 1.0.8, which  
worked.

> Hi there,
>I'm using darcs 1.0.9rc2 on my home PC (WinXP) and on a server (SunOS  
> 5.9 x86).
> When I try to push patches from my home PC to the server over SSH, I get  
> the
> error message:
>darcs failed:  Malformed patch bundle: '[Initial revision.' is not  
> 'Context:'
>where "Initial revision." is the name of the patch I am trying to push.  
> I've
> tried google, but all I can find are messages regarding "darcs send", not
>  "darcs push".
>cheers,
> Rob

Hi Rob,

On Mon, Apr 16, 2007 at 14:21:09 +0000, Rob Moss wrote:
> I also tried pushing the patch an Ubuntu box running darcs 1.0.8, which  
> worked.

Could you try it with 1.0.9rc2 on Ubuntu?

Everything works fine with 1.0.9rc2 on Ubuntu.

On SunOS, even if I copy over a patch bundle that works when using
"darcs apply" on Ubuntu (1.0.8 and 1.0.9rc2) and WinXP (1.0.9rc2),
it fails.

> Eric Kow <eric.kow@gmail.com> added the comment:
>
> Hi Rob,
>
> On Mon, Apr 16, 2007 at 14:21:09 +0000, Rob Moss wrote:
>> I also tried pushing the patch an Ubuntu box running darcs 1.0.8, which
>> worked.
>
> Could you try it with 1.0.9rc2 on Ubuntu?
>
> ____________________________________
> Darcs issue tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue435>
> ____________________________________

This looks as though it may be related to Issue432 "test failures on  
Solaris".
I have compiled 1.0.8, 1.0.9rc2 and the latest source (as of Apr-17) under
Solaris using GHC 6.4.1, and none have successfully parsed patch bundles  
that
work for me using 1.0.8 and 1.0.9rc2 on Ubuntu and WinXP.

On Wed, Apr 18, 2007 at 07:48:14AM +0000, Rob Moss wrote:
> This looks as though it may be related to Issue432 "test failures on
> Solaris".  I have compiled 1.0.8, 1.0.9rc2 and the latest source (as of
> Apr-17) under Solaris using GHC 6.4.1, and none have successfully parsed
> patch bundles that work for me using 1.0.8 and 1.0.9rc2 on Ubuntu and
> WinXP.

Just to be sure, could you take an md5sum (or other good hash) of the patch
bundles on ubuntu and solaris? I'd like to know for certain that it's darcs
that is misbehaving, and not scp.  You could also try removing the "hash:"
line and see what happens when you apply--as a test.  My guess is that this
will "fix" the problem, but it might also lead to a corrup repository, so
please, only do this as a test.
-- 
David Roundy
http://www.darcs.net

I created a patch bundle using "darcs send -a -o BUNDLE" and also saved the
'mailed_patch' created by "darcs send -a" (MAPISendMail fails on my WinXP
box, because I don't have the necessary DLLs). The difference is that  
BUNDLE
does not include the email headers/footers, etc.

Here are the results:

Ubuntu
------
darcs apply BUNDLE --> success
darcs apply mailed_patch --> success

SunOS
-----
darcs apply BUNDLE -->
   darcs failed:  Patch bundle failed hash!
   This probably means that the patch has been corrupted by a mailer.
   The most likely culprit is CRLF newlines.

darcs apply mailed_patch -->
   darcs failed:  Malformed patch bundle: '[Initial revision.' is not  
'Context:'

md5sum on SunOS
---------------
b235f99645e1578b389afcc68fc9a100  BUNDLE
8871da5a34aaf3e93b08970ffa3f82e8  mailed_patch

md5sum on Ubuntu
----------------
b235f99645e1578b389afcc68fc9a100  OUTPUT
8871da5a34aaf3e93b08970ffa3f82e8  mailed_patch

I then removed the "Patch bundle hash:" line and hash from both files.
The results on SunOS (starting from an empty repository) were:

darcs apply BUNDLE --> success
  according to "darcs check --complete", the repository was consistent

darcs apply mailed_patch --> success
  according to "darcs check --complete", the repository was consistent

I hope this helps.

> Just to be sure, could you take an md5sum (or other good hash) of the  
> patch
> bundles on ubuntu and solaris? I'd like to know for certain that it's  
> darcs
> that is misbehaving, and not scp.  You could also try removing the  
> "hash:"
> line and see what happens when you apply--as a test.  My guess is that  
> this
> will "fix" the problem, but it might also lead to a corrup repository, so
> please, only do this as a test.

I've managed to get darcs 1.0.9 to successfully pull a repository from my 
Ubuntu box, using the following steps:

./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
  > failed on manpage (test -d /man/man1) -- the man path is invalid (is this 
because i chose not to make the documentation?)

And now darcs can now successfully pull a repository from my ubuntu machine!

Rob, that's great to hear!

By the way, the man page issue *should* now be fixed in unstable (see issue493).

Darcs, should we forward this to GHC people?

Damn! On my Ubuntu machine, I can pull down the unstable repository, but on the 
Solaris box I get the following error:

darcs failed:  Not a repository: http://darcs.net/repos/unstable (Failed to 
download URL http://darcs.net/repos/unstable/_darcs/hashed_inventory : HTTP 
error (404?))

I can pull and push changes over SSH to and from my Ubuntu box, so perhaps the 
problem has something to do with libcurl and Solaris...

> Damn! On my Ubuntu machine, I can pull down the unstable repository, but on the
> Solaris box I get the following error:
>
> darcs failed:  Not a repository: http://darcs.net/repos/unstable (Failed to
> download URL http://darcs.net/repos/unstable/_darcs/hashed_inventory : HTTP
> error (404?))

You can also tell darcs to use the curl or wget command (see manual).
It may be worth trying that just to see  what happens.

> Eric Kow <eric.kow@gmail.com> added the comment:
>
>> Damn! On my Ubuntu machine, I can pull down the unstable repository,  
>> but on the
>> Solaris box I get the following error:
>>
>> darcs failed:  Not a repository: http://darcs.net/repos/unstable  
>> (Failed to
>> download URL http://darcs.net/repos/unstable/_darcs/hashed_inventory :  
>> HTTP
>> error (404?))
>
> You can also tell darcs to use the curl or wget command (see manual).
> It may be worth trying that just to see  what happens.

None of wget, curl and fetch work:

darcs failed:  Not a repository: http://darcs.net/repos/unstable ((wget -q  
-O -) failed to fetch:  
http://darcs.net/repos/unstable/_darcs/hashed_inventory)
darcs failed:  Not a repository: http://darcs.net/repos/unstable ((curl -s  
-f) failed to fetch:  
http://darcs.net/repos/unstable/_darcs/hashed_inventory)
darcs failed:  Not a repository: http://darcs.net/repos/unstable ((fetch  
-q -o -) failed to fetch:  
http://darcs.net/repos/unstable/_darcs/hashed_inventory)

However, lynx provides a more detailed error message:

darcs failed:  Can't understand repository format: <!DOCTYPE HTML PUBLIC  
"-//IETF//DTD HTML 2.0//EN">
Can't understand repository format: <html><head>
Can't understand repository format: <title>404 Not Found</title>
Can't understand repository format: </head><body>
Can't understand repository format: <h1>Not Found</h1>
Can't understand repository format: <p>The requested URL  
/repos/unstable/_darcs/format was not found on this server.</p>
Can't understand repository format: <hr>
Can't understand repository format: <address>Apache/2.2.3 (Debian)  
mod_python/3.2.10 Python/2.4.4 Server at darcs.net Port 80</address>
Can't understand repository format: </body></html>

Is this a problem with darcs, or the darcs.net server?

Here's what I think happens:

in RepoFormat.lhs : identifyRepoFormat
  the first attempt to read a darcs format file with fetchFilePS
  succeeds, but the repo format file content it returns is instead
  an HTML 404 page (that darcs fail to parse).

  identifyRepoFormat => fetchFilePS => copyFileOrUrl => copyRemote

  It would be somewhere in copyRemote or its sub commands that the
  404 return is not detected.

Creating a _darcs/format file containing "darcs-1.0" in the
darcs-unstable (and stable) repo would avoid the 404 and thus
the problem, although the bug is still there.

I don't have time to investigate this any further right now, but
I've created this format file in the stable repo (Eric, you
might want to do the same in darcs-unstable).

On Wed, Jul 25, 2007 at 11:41:30 -0000, Tommy Pettersson wrote:
> I don't have time to investigate this any further right now, but
> I've created this format file in the stable repo (Eric, you
> might want to do the same in darcs-unstable).

Done.  Any better, Rob?

On Wed, Jul 25, 2007 at 11:41:30AM -0000, Tommy Pettersson wrote:
> Here's what I think happens:
> 
> in RepoFormat.lhs : identifyRepoFormat
>   the first attempt to read a darcs format file with fetchFilePS
>   succeeds, but the repo format file content it returns is instead
>   an HTML 404 page (that darcs fail to parse).
> 
>   identifyRepoFormat => fetchFilePS => copyFileOrUrl => copyRemote
> 
>   It would be somewhere in copyRemote or its sub commands that the
>   404 return is not detected.

That sounds like a good diagnosis! We naively assume that if copyFileOrUrl
succeeds, then the file is actually there, which is incorrect in this
case.  :( I wonder if there's a good way to cause 404 messages to trigger
fetchFilePS to throw an exception?

We could delay identification until these files have successfully been
parsed, but I'd rather fix fetchFilePS to fail on receipt of a 404, so that
the entire code would be safe from darcs mistakenly thinking it has
downloaded a file...

> Creating a _darcs/format file containing "darcs-1.0" in the
> darcs-unstable (and stable) repo would avoid the 404 and thus
> the problem, although the bug is still there.

Right, that'd be a sort of workaround, but we really need to fix the bug.
-- 
David Roundy
Department of Physics
Oregon State University

> Eric Kow <eric.kow@gmail.com> added the comment:
>
> On Wed, Jul 25, 2007 at 11:41:30 -0000, Tommy Pettersson wrote:
>> I don't have time to investigate this any further right now, but
>> I've created this format file in the stable repo (Eric, you
>> might want to do the same in darcs-unstable).
>
> Done.  Any better, Rob?

Using vanilla darcs pull, wget, fetch and curl returns:
     darcs failed:  Not a repository: http://darcs.net/repos/unstable
     failed to fetch:  
http://darcs.net/repos/unstable/_darcs/hashed_inventory)

Using lynx returns:
     Pulling from "http://darcs.net/repos/unstable"...
     No remote changes to pull in!

So it seems as though lynx works, but every other method complains
about a missing hashed_inventory.

On Wed, Jul 25, 2007 at 11:41:54PM -0000, Rob Moss wrote:
> Using vanilla darcs pull, wget, fetch and curl returns:
>      darcs failed:  Not a repository: http://darcs.net/repos/unstable
>      failed to fetch:  
> http://darcs.net/repos/unstable/_darcs/hashed_inventory)

This is not darcs 1.0.9, but the latest build from darcs-stable
or darcs-unstable, right?

Then the problem is that darcs fails to fetch _darcs/inventory,
although the error message says it fails to fetch
_darcs/hashed_inventory. It actually tries to fetch three types
of inventories, and fail on all three.

It's curious that lynx worked but no other method, and that lynx
also caused another error about the repo format file...

> Then the problem is that darcs fails to fetch _darcs/inventory,
> although the error message says it fails to fetch
> _darcs/hashed_inventory. It actually tries to fetch three types
> of inventories, and fail on all three.

That never fails to confuse me.  We really ought to catch this and say
something more generic, like 'Couldn't retrieve darcs metadata.  If
you are sure this is really is a darcs repository, blah blah blah'...
just anything but 'oh, I failed to get file X'

Not sure how to write the error message though.

On Thu, Jul 26, 2007 at 02:10:10PM -0000, Eric Kow wrote:
> > Then the problem is that darcs fails to fetch _darcs/inventory,
> > although the error message says it fails to fetch
> > _darcs/hashed_inventory. It actually tries to fetch three types
> > of inventories, and fail on all three.
> 
> That never fails to confuse me.  We really ought to catch this and say
> something more generic, like 'Couldn't retrieve darcs metadata.  If
> you are sure this is really is a darcs repository, blah blah blah'...
> just anything but 'oh, I failed to get file X'

We could print just "not a repository" as default, but dump
everything we got if the verbose flag is on. If the options are
passed to identifyRepoFormat it would be a trivial change. I
could probably do that tonight.

I found out why wget, fetch and curl failed -- fetch is not actually installed 
on the solaris server (I can't believe I didn't check this!), while wget and 
curl needed a username and password for proxy authentication. This would also 
explain why the vanilla "darcs pull" failes -- it doesn't have my username and 
password.

So, with darcs 1.1.0pre1 (compiled on July 9, 2007) I can successfully check 
out repositories on Solaris. As an aside, compilation of the current unstable 
branch fails, however, with the following message:

src/Darcs/Patch/Ordered.lhs:67:15:
    Malformed constructor signature: a1 :\./: a2
    In the signature of a data constructor: a1 -> a2 -> (a1 :\./: a2)
    In the data type declaration for `:\./:'

I don't know nearly enough Haskell to know what the problem is here -- could it 
be due to GHC (6.4.1), or is it a genuine error?

I'd also like to thank you all for being so helpful and friendly :)
This is a really nice community.

Hi Rob, 

I think the compilation errors are normal.  The unstable branch uses some new
Haskell features, the implementation of which was slightly buggy in 6.4.1.  This
is mildly ironic, because the features in question are meant to help us avoid
some silly and dangerous bugs in our code :-)  Anyway, I think we are supporting
6.4.1 for one more release, but after that, we're going to ask for 6.6.

As you seem to be all set, and as we have worked out the lousy error messages
problem (I hope), I'm resolving this issue.  Many thanks!