Update ncurses to 5.9-20141206

[certik]

Upstream only distributes the 5.9 version plus the 20141206 patch in a form
that is not easy to apply, so I pushed it into a git repository.

The clang-fix.patch, even though it applies, actually makes clang fail to build
it and removing the patch fixes it. The package now builds on OS X 10.10 both
with the native clang as well as with Hashstack's gcc.

Fixes #777.

Build status:

• OS X 10.10 native clang
• OS X 10.10 Hashstack's gcc
• RHEL6 Hashstack's gcc
• RHEL6 native gcc (4.4.7)
• Ubuntu 14.04 native gcc (4.8.2)

[certik]

CC @ahmadia, you added the original patch in 1530e7b.

[certik]

@cekees, @ahmadia, @dagss ---- I wonder if we should create a new github organization, perhaps hashstack-packages (or such) and put all these git repositories in there, so that we can say that those are Hashstack's official packages. I think simple patches are best maintained in the Hashstack repository, but this is a huge patch (see https://github.com/certik/ncurses/commit/2031c7bde2dfb2189b9c724946f19c089596eac4), and that's applied on top of a previous huge patch. At the same time, by having a separate organization, the hashdist organization will not be cluttered by such packages, which are really unrelated to Hashdist or Hashstack --- we are essentially supplementing the missing upstream git repository.

[cekees]

My initial reaction is to hold off on creating a new organization, but I
don't feel that strongly about it. I would be in favor of creating
mirror/tracking repositories within the hashdist organization for cases
where the upstream repository is missing, unreliable, or otherwise doesn't
play nicely with hashstack. That's what we're doing inside erdc-cm for
certain legacy codes. This patch seems like a pathological case.

Also, just FYI, the git Large File Storage is available now and git-fat
also works reliably. I think we'll soon be in a position withing git where
we can seamlessly handle large blobs that we don't really want to track
through time or store inside the repository but rather just want to attach
to commits.

On Fri, May 15, 2015 at 5:34 PM, Ondřej Čertík notifications@github.com
wrote:

@cekees https://github.com/cekees, @ahmadia https://github.com/ahmadia,
@dagss https://github.com/dagss ---- I wonder if we should create a new
github organisation, perhaps hashstack-packages (or such) and put all
these git repositories in there, so that we can say that those are
Hashstack's official packages. I think simple patches are best maintained
in the Hashstack repository, but this is a huge patch (see
certik/ncurses@2031c7b
https://github.com/certik/ncurses/commit/2031c7bde2dfb2189b9c724946f19c089596eac4),
and that's applied on top of a previous huge patch. At the same time, by
having a separate organization, the hashdist organization will not be
cluttered by such packages, which are really unrelated to Hashdist or
Hashstack --- we are essentially supplementing the missing upstream git
repository.

—
Reply to this email directly or view it on GitHub
#778 (comment).

[certik]

@cekees I agree with regards to the large git files. Do you propose to put the ncurses repo into https://github.com/hashdist? I still think that having it separate is the best --- this is not part of Hashdist, we just need a collaborative place to hold a reliable upstream repository.

PETSc does something similar for lots of upstream packages here: https://bitbucket.org/petsc, e.g. https://bitbucket.org/petsc/pkg-mumps/commits/all

[cekees]

Yes, I was thinking of something similar to petsc,
https://github.com/hashdist/pkg-ncurses. I just don't think we'll need a
lot of these. The combination of 1) reliable hosting for the "origin" of
most packages and 2) remote source caches for hashstack should make it
unnecessary to create a pkg- repository for all but a few packages.
Namely, the ones that require inordinately large patches or where our
community finds they have to essentially fork and maintain a modified
source tree to make our stacks robust.

On Fri, May 15, 2015 at 6:58 PM, Ondřej Čertík notifications@github.com
wrote:

@cekees https://github.com/cekees I agree with regards to the large git
files. Do you propose to put the ncurses repo into
https://github.com/hashdist? I still think that having it separate is the
best --- this is not part of Hashdist, we just need a collaborative place
to hold a reliable upstream repository.

PETSc does something similar for lots of upstream packages here:
https://bitbucket.org/petsc, e.g.
https://bitbucket.org/petsc/pkg-mumps/commits/all

—
Reply to this email directly or view it on GitHub
#778 (comment).

[certik]

Ok. Should I move certik/ncurses to hashdist/pkg-ncurses?

[cekees]

+1

On Fri, May 15, 2015 at 8:33 PM, Ondřej Čertík notifications@github.com
wrote:

Ok. Should I move certik/ncurses to hashdist/pkg-ncurses?

—
Reply to this email directly or view it on GitHub
#778 (comment).

[certik]

Done (f8b50d1). I moved the repository to https://github.com/hashdist/pkg-ncurses.

[certik]

This is ready to be merged as far as I am concerned. It builds on all platforms that I tried.

[certik]

@cekees, @ahmadia are you ok with me merging this? I depend on this for my work.

[cekees]

Yes, sorry, meant to +1 this a while ago.

On Tue, May 19, 2015 at 1:53 PM, Ondřej Čertík notifications@github.com
wrote:

@cekees https://github.com/cekees, @ahmadia https://github.com/ahmadia
are you ok with me merging this? I depend on this for my work.

—
Reply to this email directly or view it on GitHub
#778 (comment).