On Sat, Dec 31, 2016 at 10:19:53AM +1100, Carlo Zancanaro wrote:
> On Fri, Dec 30 2016, Leo Famulari wrote
> >> diff --git a/gnu/packages/patches/kakoune-fix-bash-path.patch b/gnu/packages/patches/kakoune-fix-bash-path.patch
> >> diff --git a/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch b/gnu/packages/patches/kakoune-leave-manpages-uncompressed.patch

> > In this case, we need to explain why upstream's approach of finding a
> > POSIX shell doesn't work.
> 
> Perhaps you can give me a hint on this. I've patched it myself because
> the original code uses confstr with _CS_PATH, but within the build
> environment (and presumably outside of it, too) it gives back
> "/bin:/usr/bin". Within the build environment this is invalid (as
> neither directory exists), so the tests all fail. There is a bug[1]
> about this already, but it was closed without fixing the issue (due to
> some complexity/ambiguity in doing so, and no immediate need to fix it).

How about this?

(add-before 'configure 'patch-bash-path
  (lambda* (#:key inputs #:allow-other-keys)
    (substitute* "src/shell_manager.cc"
      (("if \\(m_shell.empty\\(\\)\\)" line)
       (string-append "m_shell = \"" (assoc-ref %build-inputs "bash")
                      "/bin/sh\";\n        " line)))
    #t))

It's crude but it seems to work (the tests pass) and it avoids this
issue:

> > Also, using a patch to get half-way there will cause the source code
> > given by `guix build --source` to be unbuildable, right? So, I think we
> > should find another way to fix whatever is wrong with the shell-finding
> > logic. Perhaps it will require cooperation with the upstream
> > maintainers, I don't know.
> 
> I hadn't thought about the effect this would have on `guix build
> --source`. That's a fairly big problem.

Sorry for the slooooow response!