Re: Darcs evaluation

I could not find verification that I replied back to you so, this is to thank you for your help. The data will be
used in the evaluation process.

Steven Siegel
Telophase Corporation
http://www.telophase.com
ssiegel <at> telophase.com
 
Cell (301) 452-2352
NASA Phone:  (301) 614-5409  or  x45409
NASA e-mail:  steven.n.siegel <at> nasa.gov

-----Original Message-----
From: Eric Kow [mailto:eric.kow <at> gmail.com] On Behalf Of Eric Kow
Sent: Thursday, September 29, 2011 10:30 AM
To: Siegel, Steven N. (GSFC-585.0)[TELOPHASE CORP]
Cc: darcs-users <at> darcs.net
Subject: Re: [darcs-users] Darcs evaluation

Steven,

Thanks for considering Darcs.

> I have a small questioner that I have
> attached and would like to evaluate your responses.

Two general notes:

1. Darcs is a revision/version control system (VCS), so I'm not sure
   how well it would fit your seemingly more general needs for a CM

Current state of darcs 2.8 release?

Hello,

I'm looking forward to using the "packs" feature of darcs 2.8. The last
details about I can find about it on the blog and wiki indicate a
release sometime this past this summer.  What's the updated release status?

In related news, I opened a bug report regarding missing docs about
packs, and suggested what some improved docs might look like:

http://bugs.darcs.net/issue2102

   Mark

darcs 2.8 fails to build on FreeBSD 8.1

Hello,

I just tried "cabal install darcs-beta" on FreeBSD 8.1.
It started to compile darcs-beta-2.7.98.1. Ultimately, it failed like this:

src/HTTP.hs:11:42:
    Module `Network.Browser' does not export `setCheckForProxy

Perhaps darcs needs to declare that needs a newer version of HTTP.hs?

    Mark

Re: darcs build slave

Hello Ganesh,

On Tue, Oct 11, 2011 at 09:18:43PM +0100, Ganesh Sittampalam wrote:
> ...
> Could you cabal install hashed-storage ( >=0.5.5 && <0.6 ) on the 6.10.4
> and 6.12.2 GHC installs?

Oh my, that was complex. And not finished yet. And, interestingly, none
of the problems that I encountered had anything to do with
hashed-storage.

The ghc-6.10 builder presently succeeds. The ghc-6.12 builder fails and
it probably doesn't makes sense to attempt to fix it with the ghc-6.12
that I have installed at

> /Library/Frameworks/GHC.framework/Versions/612/usr/bin/ghc-6.12.2

Instead, I suggest that ghc-6.12 building on tn23 uses

> /Users/thorkilnaur/tn/install/ghc-6.12.3/bin/ghc

In addition, I raise the possibility of using

> /Users/thorkilnaur/tn/install/ghc-7.2.1/bin/ghc

for ghc-7.* builds, at your convenience.

> ...

Best regards

Report after triaging 2.8 release blocker: what remains to be done

With a nod from Heffalump on IRC, I momentarily stepped into my old rule
of bug tracker czar and reviewed all the bugs tagged with the 2.8
milestone to see what could be done to move the release along.

Mostly I found things which weren't regressions from 2.5.1.
That is, we can push off addressing them until 2.10, and our quality
will be no worse than it was before, and all the fixes and features in
2.8 will actually get released. Indeed, many of the issues were things
that I had been pushed from the 2.4 release to the 2.5 milestone
previously. :)

In they end, there are less than 10 items left marked with the 2.8
release goal. They can be easily moved into 2 categories:

-- probably related to packs
-- probably not regressions since 2.5.1.

http://goo.gl/im3iE

It seemed clear from the review that --packs are not ready for
prime-time yet. They are barely documented and cause a number of
documented problems in the bug tracker.

Either this feature should be removed (which may be difficult, I
imagine), or the default should be --nopacks for 2.8 (probably fairly
easy). If the feature remains, it should be clearly marked as
experimental, perhaps with a link to related open tickets in the bug
tracker.

Re: Report after triaging 2.8 release blocker: what remains to be done

Here's a list of changes which a couple or 10 of us could summarise down to release notes, which would help
release 
planning: http://wiki.darcs.net/changes%20since%202.5

Re: darcs build slave

On 12/10/2011 21:09, Thorkil Naur wrote:

> On Tue, Oct 11, 2011 at 09:18:43PM +0100, Ganesh Sittampalam wrote:
>> ...
>> Could you cabal install hashed-storage ( >=0.5.5 && <0.6 ) on the 6.10.4
>> and 6.12.2 GHC installs?
> 
> Oh my, that was complex. And not finished yet.

Oh dear! Thanks very much for your efforts.

> Instead, I suggest that ghc-6.12 building on tn23 uses
> 
>> /Users/thorkilnaur/tn/install/ghc-6.12.3/bin/ghc
> 
> In addition, I raise the possibility of using
> 
>> /Users/thorkilnaur/tn/install/ghc-7.2.1/bin/ghc
> 
> for ghc-7.* builds, at your convenience.

Sounds good, as soon as we deal with an issue with non-ASCII filenames
triggered by GHC 7.2 (issue2095).

Petr, is reconfiguring buildbot as above something only you can do? I
can't find any instructions on the wiki.

Cheers,

Ganesh

Re: Report after triaging 2.8 release blocker: what remains to be done

On 10/13/2011 06:19 PM, Simon Michael wrote:
> Here's a list of changes which a couple or 10 of us could summarise down
> to release notes, which would help release planning:
> http://wiki.darcs.net/changes%20since%202.5

Thanks for starting on this Simon!

One item I see on the list looks related to the build failure I'm
getting on FreeBSD 8.1 is this:

"bumped network and HTTP dependency upper version bounds"

My build failure with 6.10.4 was this:

"src/HTTP.hs:11:42:
    Module `Network.Browser' does not export `setCheckForProxy"

I looked into this further. The setCheckForProxy change seems to have
appeared in version 4000.0.8.

Darcs appears to correctly reflect this in setup.cabal:

    HTTP    >= 4000.0.8 && < 4000.2

In my ".cabal" directory, I see that 4000.0.4 has been downloaded,
unpacked and built. Yet, darcs/cabal didn't throw an error that that the
dependency was too low, and Cabal appears to have downloaded of
the HTTP library that is too old.

I'm using:

Re: darcs build slave

Hello,

On Fri, Oct 14, 2011 at 06:34:20AM +0100, Ganesh Sittampalam wrote:
> ...
> Oh dear! Thanks very much for your efforts.

The trouble is not specifically related to darcs, but is part of an
ongoing fight with macports to set up a suitable environment for GHC
buildbotting.  Lately, I have been more successful than earlier, as a
result of using a more recent curl, but everything seems interlocked and
one part of the installation often affects other parts in unexpected and
undesirable manners. Ian (igloo) has suggested using "homebrew", another
packaging system for Mac OS X, but I haven't decided to take that plunge
so far.

In any case, darcs is not to blame, but thanks for your concern.

> ...

Concerning the building GHC version: I have earlier installed 6.10,
6.12, and also 7.0 via Mac OS X binaries supplied by the GHC HQ. The
6.10 version continues to work, but both the 6.12 and 7.0 GHCs fail, if
I also have the libiconv library from macports installed. See, for
example:

> http://darcs.haskell.org/ghcBuilder/builders/tn23/448/7.html

Since the macports libiconv seems needed to make the git installation
work, I have decided to attempt to rely on GHCs built from source.
Presently, I have working

Re: darcs build slave

On Mon, Oct 17, 2011 at 14:14:12 +0200, Thorkil Naur wrote:
> The trouble is not specifically related to darcs, but is part of an
> ongoing fight with macports to set up a suitable environment for GHC
> buildbotting.

At the risk of being unhelpful, I found my Haskell life less frustrating
when I abandoned MacPorts in favour of HomeBrew

--

-- 
Eric Kow <http://erickow.com>

_______________________________________________
darcs-users mailing list
darcs-users <at> darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users