Linuxbrew-core: brew: Unable to use brewed gpatch

[tundratim]

Not sure if this should be a new issue, but the original is now closed ...

I have discovered the root cause but do not have a fix.

The version of "patch" that ships with brew is somehow incompatible with the patch set provided to build 'screen'. If I install the distro's version of patch (CentOS 7) everything works just fine.

I suspect, but have not proven, that there is some switch required to make brew's version of patch (is it gpatch?) compatible with the required patch file for screen.

It should be possible to duplicate this be ensuring that patch has been installed by brew and then removing the distro's version of patch and attempting to compile the screen program from formula.

The procedure I am following is described here:

https://gitbucket.tundraware.com/tundra/tools-builder

[close-issue-app[bot]]

From the issue template:

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

If you add the necessary information to this issue (don't create a new one, please) then this issue may be reopened.

[iMichka]

We tested this and could not reproduce it in a centos 7 docker image. So this is quite hard for us to debug.
We can not ask to uninstall the system’s patch, as some people may still need it for other things.

Not sure what the way forward is for this issue.

[tundratim]

The exact procedure I am using is here:

https://gitbucket.tundraware.com/tundra/tools-builder

Just spin up a couple docker containers as described and follow the procedure. The build of screen will fail even if gpatch is installed so long as system patch is not there.

The more I look at this, the more I think that something about the screen formula cannot find brew's own version of patch (gpatch) and that's why this is breaking.

[tundratim]

I have confirmed that the problem is that the screen formula cannot find the brew instance of patch even though it is in $PATH.

I did this by:

1) Installing gpatch in brew
2) Making sure system patch was not installed
3) Trying to install screen: FAIL
4) ln -s /my/copy/of/brew/bin/patch /bin/patch
5) Try to install screen: PASS

I suspect that the formula is ignoring $PATH and using a hard path to the patch utility (which is evil).

[sjackman]

Consider installing Linuxbrew in /home/linuxbrew/.linuxbrew/ if possible so that you can use precompiled binary packages (known as bottles) for non-relocatable formula like screen.
Another possible workaround for you is brew install --force-bottle screen, but no promises.

If it's an option for you, you could open a ticket with your information systems department to ask that they create a linuxbrew role account with home directory /home/linuxbrew.

The precompiled binary bottles of non-relocatable bottles can only be used if you install in /home/linuxbrew/.linuxbrew, otherwise they have to be built from source. See the documentation below. On macOS the default installation directory is /usr/local. On Linux the default installation directory is /home/linuxbrew/.linuxbrew.

• http://docs.brew.sh/Installation.html#alternative-installs
• http://docs.brew.sh/FAQ.html#why-do-you-compile-everything
• http://docs.brew.sh/Bottles.html#cellar-cellar

[sjackman]

Please report the output of…

brew install -s screen
brew gist-logs screen

(note that this information was requested by the issue template)

[tundratim]

@sjackman I am well aware of this default brew behaviour. The exact reason I developed the method described at https://gitbucket.tundraware.com/tundra/tools-builder was to enable me to relocate the install wherever I want.

I realize this means compilation - hence the makefile provided in that repo - because the binaries are not relocatable.

For the record, one of the (many) reasons I did all this was to make a relocatable and customized toolkit available in docker containers.

[tundratim]

brew install -s screen
==> Downloading https://ftp.gnu.org/gnu/screen/screen-4.6.2.tar.gz
Already downloaded: /home/test/.cache/Homebrew/downloads/31dbebcad80655ac1835de1e48582a82a29ff9effa7f3c3fb9b4ab4b0f45f3f0--screen-4.6.2.tar.gz
==> Downloading https://gist.githubusercontent.com/yujinakayama/4608863/raw/75669072f227b82777df25f99ffd9657bd113847/gistfile1.diff
Already downloaded: /home/test/.cache/Homebrew/downloads/4b52c981266437250af3c28ffe12c641eb1bc1654ad0cf6abde18c6c6590c891--gistfile1.diff
==> Patching
==> Applying gistfile1.diff
Error: Failure while executing; patch -g 0 -f -p2 -i /tmp/screen--patch-20190622-8049-18qft3w/gistfile1.diff exited with 1.
[test] dock2 ~/tools-builder>which patch
/opt/TundraWare/tools/bin/patch

[tundratim]

brew gist-logs screen
Error: No logs.

BUT ... if I symlink brew's patch ot /usr/bin ... everything works just swell

ISTR that this is not the first time I've run into this kind of problem. When I was first developing this whole business I found something else (autoconf? perl?) that was demanding stuff from specific locations instead of letting the environment figure it out.

With the exception of /bin/sh, absolute paths in scripts or other build toolchains are usually evil :)

[sjackman]

==> Patching
==> Applying gistfile1.diff
Error: Failure while executing; patch -g 0 -f -p2 -i /tmp/screen--patch-20190622-8049-18qft3w/gistfile1.diff exited with 1.

That sounds like a bug in Homebrew/brew to me.
Here's the relevant code:
https://github.com/Homebrew/brew/blob/3cef1088967291a27583b41c09c32a041b52b00e/Library/Homebrew/patch.rb#L156
https://github.com/Homebrew/brew/blob/3cef1088967291a27583b41c09c32a041b52b00e/Library/Homebrew/software_spec.rb#L211

Linuxbrew/brew used to have a patch to fix this issue, but it didn't make it into Homebrew/brew.
https://github.com/Linuxbrew/brew/blob/93389fde63974f096156344e281610acec44130c/Library/Homebrew/software_spec.rb#L205

If you're able to fix this issue, would you like to open a PR for Homebrew/brew?

[tundratim]

I can try to take a look at this. The problem is that I don't know Ruby at all but ...

[tundratim]

Linuxbrew/brew used to have a patch to fix this issue, but it didn't make it into Homebrew/brew.
https://github.com/Linuxbrew/brew/blob/93389fde63974f096156344e281610acec44130c/Library/Homebrew/software_spec.rb#L205

Yep, that fixes it.

I run my own personal git server, so forgive me if this question is really dumb but ...
Since I do not have write perms on this repo, what is your preferred way of doing PRs or patch submissions?

[iMichka]

You need to fork the repository.
There are plenty of tutorials out there which explain how to open a pull request:
https://help.github.com/en/articles/creating-a-pull-request-from-a-fork
https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request

[sjackman]

I'm glad to hear that this patch resolves your issue. I look forward to seeing your PR to Homebrew/brew. Please at (@) me in your PR, or request me as a reviewer.

[tundratim]

@sjackman Have been traveling. Will get to this once I get caught up again ...

[tundratim]

@sjackman PR submitted

[iMichka]

For further reference: https://github.com/Homebrew/brew/pull/6280