I think this patch breaks darcs for me at work, because the current version of
the HTTP library does not like our proxy server.  The result is that darcs, with
any command, just hangs... [as do helper programs like ./list_authors].

  * add phone-home capability to darcs on failure.
  The idea is to check for the status of the darcs version, and print an
  appropriate recommendation (e.g. please upgrade, this is a seriously old
  version of darcs rather than "please send in a bug report").
  
  This feature requires the http package be installed.  Perhaps we should
  require this.

    M ./configure.ac -2
    M ./src/Darcs/Bug.lhs -6 +19

Hah! I remember my prior zeal for switching to HTTP.  Payback!

On Mon, Mar 31, 2008 at 02:00:24PM -0000, Eric Kow wrote:
> I think this patch breaks darcs for me at work, because the current version of
> the HTTP library does not like our proxy server.  The result is that darcs, with
> any command, just hangs... [as do helper programs like ./list_authors].
> 
>   * add phone-home capability to darcs on failure.
>   The idea is to check for the status of the darcs version, and print an
>   appropriate recommendation (e.g. please upgrade, this is a seriously old
>   version of darcs rather than "please send in a bug report").
>   
>   This feature requires the http package be installed.  Perhaps we should
>   require this.
> 
>     M ./configure.ac -2
>     M ./src/Darcs/Bug.lhs -6 +19
> 
> Hah! I remember my prior zeal for switching to HTTP.  Payback!

I don't think it could be this patch, as this patch shouldn't have any
effect at all until a bug is reported.  Unless perhaps you've been
compiling with no http library at all, and relying on external calls to
curl or wget?

Can you send the output of any command run with debug output? (And ideally
consider adding more debug output if it you don't see what's triggering the
hang?)  Thanks!
-- 
David Roundy
Department of Physics
Oregon State University

It gets stuck after this...

$ ./darcs what --debug-verbose
Beginning identifying repository .
Done identifying repository .
Beginning reading pristine
Reading hash file 9794e683ce0102adb1438846cc77878b6dfcedce from pristine.hashed/
I'm doing copyFileUsingCache on
pristine.hashed/9794e683ce0102adb1438846cc77878b6dfcedce

Can you give me the output of configure?
-- 
David Roundy
Department of Physics
Oregon State University

> I don't think it could be this patch, as this patch shouldn't have any
>  effect at all until a bug is reported.  Unless perhaps you've been
>  compiling with no http library at all, and relying on external calls to
>  curl or wget?

Just to make sure, I have confirmed that unpulling this patch and
doing make maintainer-clean solves the hanging.  Likewise, pulling it
back in (make maintainer-clean) causes it to hang again.

I suspect it's not the meat of the patch that causes the problem, but
the mandatory use of HTTP, which affects non-phone-home-related parts
of darcs code, if I understand correctly.

Attached is my config.log

Attachments

• config.log

On Mon, Mar 31, 2008 at 02:27:26PM -0000, Eric Kow wrote:
> Just to make sure, I have confirmed that unpulling this patch and
> doing make maintainer-clean solves the hanging.  Likewise, pulling it
> back in (make maintainer-clean) causes it to hang again.
> 
> I suspect it's not the meat of the patch that causes the problem, but
> the mandatory use of HTTP, which affects non-phone-home-related parts
> of darcs code, if I understand correctly.

Right, which is why I'm wanting to see how your darcs was configured.

> Attached is my config.log

Could you just run ./configure >> configure-output and send me that? The
config.log is way too verbose for me to usefully parse (except when I've
already seen a configure error in the actual output).
-- 
David Roundy
Department of Physics
Oregon State University

> Could you just run ./configure >> configure-output and send me that? The
>  config.log is way too verbose for me to usefully parse (except when I've
>  already seen a configure error in the actual output).

Yep!

Attachments

• configure-output

On Mon, Mar 31, 2008 at 02:35:33PM -0000, Eric Kow wrote:
> > Could you just run ./configure >> configure-output and send me that? The
> >  config.log is way too verbose for me to usefully parse (except when I've
> >  already seen a configure error in the actual output).
> 
> Yep!

This is really weird.  According to this you do have libcurl, and configure
finds it.  So you should never be using HTTP unless you run into a bug.
I'm adding it more debug prints to the HTTP module, but for now could you
just add a little putStrLn "I'm here in HTTP" in HTTP.fetchFile and see if
it's actually called?

Also, if strace is available, could you try running your darcs what command
under strace, to see if that gives a hint as to what system commands are
being called? Thanks!
-- 
David Roundy
Department of Physics
Oregon State University

I've now uploaded patches which will give more debug output.  Can you try
running with the latest darcs-unstable, and see what debug output you get? (and
post it...)

>  I've now uploaded patches which will give more debug output.  Can you try
>  running with the latest darcs-unstable, and see what debug output you get? (and
>  post it...)

Before I do that, I might note that the putStrLns do indicate it's
trying to fetch http://darcs.net/maintainence

in darcs what

Right... compiling away
-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Also, in case anybody else suffers from this, unpulling this patch
from HTTP helps:

* Send abs_path as Request-URI to comply with HTTP 1.1 spec.
  RFC2616 Section 5.1.2 specifies that abs_path MUST be used to
identify a resource on a origin server or gateway, not absoluteURI
which is for use with proxies.

  Change Request's Show instance to use /path/to/resource rather than
  http://server/path/to/resource.

All right Eric, I've been able to track this down.  I'm investigating a bit more
(to figure out why bug is being called and then caught), but have a fix which
will be on its way soon.  So then your darcs will only hang when there's a bug.
 But it ought to actually print a message indicating there's a bug before
hanging (if my lazy IO is done right).

Ah, the problem was in Prefs where I threw an exception using bug, with the
intent to catch it.  So now I've fixed both bugs that allowed this to happen. 
Now when we call bug it won't check maintenance until we actually print the
message (or read the string, anyhow), and we don't abuse bug in this way in
Prefs, instead using "fail", which is somewhat more appropriate.

The following patch updated the status of issue771 to be resolved in the unstable branch:

* resolve issue771: make _bugDoc try to do IO in a lazier manner. 
This keeps us from downloading http://darcs.net/maintenance unless we
actually need to report an error message to our users.

You can view the patch details online here: 
http://darcs.net/cgi-bin/darcs.cgi/unstable/?c=annotate&p=20080331160119-72aca-72b05553c4ef2e4513ebc18f41568c015c600468.gz