Kong/homebrew-kong

kong 3.1.1 installation fails due to kong/kong/openresty

orelmaliach opened this issue · 8 comments

orelmaliach commented

I'm trying to run brew install kong/kong/kong
(latest version is 3.1.1 at this time).
It installs successfully libyaml, coreutils, gmp, pkg-config, rust, openssl@1.1, but fails when installing openresty@1.21.4.1.

I'm running on an M1 Mac (arm64 arch), running OS13.1.
I asked my colleague to try installing the same (using M1, with Monterey OS), and kong was installed successfully for him.

There's a warning during the installation attempt (I don't think it's related since my colleague had it as well):
/opt/homebrew/Library/Taps/kong/homebrew-kong/Formula/openresty@1.21.4.1.rb:58: warning: conflicting chdir during another chdir block

I've already tried:

  1. Reinstalling/removing all dependencies.
  2. Cleaning homebrew cache.
  3. Installing openresty from openresty/brew - it was successful, but later when trying to install kong, it asked me to remove it:
    Error: openresty@1.21.4.1 is already installed from openresty/brew!
    Please brew uninstall openresty@1.21.4.1 first."
  4. Editing the formula to use KONG_BUILD_TOOLS_VERSION 4.40.1 (as looks to be required by https://github.com/Kong/kong/blob/3.1.1/.requirements).
  5. Running with/without VPN.

None of these worked.

In terminal, this is the output:
➜ ~ brew install openresty@1.21.4.1
==> Fetching kong/kong/openresty@1.21.4.1
==> Downloading https://github.com/Kong/kong-build-tools/archive/4.33.22.tar.gz
Already downloaded: /Users/oelmaliach/Library/Caches/Homebrew/downloads/8c26686f439ddceab9e9adaebceacf2b41b9a360a9c5d531755d9e9a05506837--kong-build-tools-4.33.22.tar.gz
==> Installing openresty@1.21.4.1 from kong/kong
/opt/homebrew/Library/Taps/kong/homebrew-kong/Formula/openresty@1.21.4.1.rb:58: warning: conflicting chdir during another chdir block
==> ./kong-ngx-build --prefix /opt/homebrew/Cellar/openresty@1.21.4.1/1.21.4.1 --openresty 1.21.4.1 --openssl 1.1.1q --luarocks 3.9.1 --pcre 8.45 --ssl-provider openssl --atc-router 1.0.1 --resty-events 0.1.3 --resty-lmdb 1.0.0 --resty-websocket 0
Last 15 lines from /Users/oelmaliach/Library/Logs/Homebrew/openresty@1.21.4.1/01.kong-ngx-build:
2023-01-15 16:34:17 +0000

./kong-ngx-build
--prefix /opt/homebrew/Cellar/openresty@1.21.4.1/1.21.4.1
--openresty 1.21.4.1
--openssl 1.1.1q
--luarocks 3.9.1
--pcre 8.45
--ssl-provider openssl
--atc-router 1.0.1
--resty-events 0.1.3
--resty-lmdb 1.0.0
--resty-websocket 0.3.0
-j 10

Do not report this issue to Homebrew/brew or Homebrew/core!

There's no further information in the log file: https://pastebin.com/z4gWxAHq
Your assistance would be appreciated.

orelmaliach commented

After further investigation, and running brew install openresty@1.21.4.1 --debug --verbose,
I managed to isolate the issue to this script that fails during invocation of canon_path function, on multiple occasions.
One example was with the following line:
DOWNLOAD_CACHE=`canon_path $DOWNLOAD_CACHE`
It failed due to the directory passed as argument (work) not existing, making both realpath and readlink fail.

Should I move the issue to https://github.com/Kong/kong-build-tools ?
Openresty installation was successful when not from the kong/kong cask, so I'm not sure how it's related.

mikehf7 commented

Same error

Error: kong/kong/openresty@1.21.4.1 1.21.4.1 did not build
Logs:
/Users/mike/Library/Logs/Homebrew/openresty@1.21.4.1/00.options.out
/Users/mike/Library/Logs/Homebrew/openresty@1.21.4.1/01.kong-ngx-build
Do not report this issue to Homebrew/brew or Homebrew/core!

kikito commented

@carlwangx step 2 (remove comment from diff) is done.

kikito commented

@orelmaliach regarding this:

It failed due to the directory passed as argument (work) not existing, making both realpath and readlink fail.

Are you sure this is the problem? realpath -m -- foo/bar/baz never fails for me locally, even when given non-existing files or folders.

@carlwangx regarding step 1 on your list, we cannot add that change to kong-build-tools, it is used for other tasks besides homebrew, in Linux environments. If we are going to make any changes to kbt it must be platform-agnostic.

orelmaliach commented

Hi @kikito , thanks for the reply.
You can find more updates on this issue in Kong/kong-build-tools#635, where I managed to employ a workaround which seems to work for everyone else who tried it as well.
I haven't opened a PR since I suspect it might not work for other platforms + I'm not sure if it works for every directory structure either.
Important to note that it seems to only happen in Mac OS 13.1 (Ventura).

Below is my output when running the commands:
➜ ~ sw_vers
ProductName: macOS
ProductVersion: 13.1
BuildVersion: 22C65
➜ ~ ls work
ls: work: No such file or directory
➜ ~ realpath -m -- work
realpath: illegal option -- m
usage: realpath [-q] [path ...]
➜ ~ readlink -f -- work
➜ ~ echo $?
1

orelmaliach commented

I'm not sure what's the difference, but I found greadlink and grealpath in coreutils, which is a dependency of openresty anyway- they might be useful:
➜ ~ grealpath -m -- work
/Users/oelmaliach/work
➜ ~ greadlink -f work
/Users/oelmaliach/work

orelmaliach commented

https://apple.stackexchange.com/questions/450035/is-the-unix-realpath-command-distributed-with-macos-ventura suggests that previous Mac OS versions did not contain realpath executable to begin with.
It looks to be also contained in coreutils, though. So now I understand @carlwangx's fix.