Linux/POWER support (was: Kubectl kui version command fails)

Describe the bug I have been trying to build kui using the instructions mentioned here All steps till npm install work. The kui binary gets generated in the build folder however executing it results in the following error.

Steps to reproduce the behavior

1. git clone [e-mail]:IBM/kui.git
2. export PATH=$PWD/kui/bin:$PATH
3. cd kui && npm install
4. kubectl kui version

Expected behavior If the kui binary has gotten built and no other dependency error seen, kui version command should work.

Screenshots

Code snippets All kui commands throw the following error:

kui
internal/modules/cjs/loader.js:628
    throw err;
    ^

Error: Cannot find module '@kui-shell/core/main/main'
Require stack:
- /root/kui/bin/kui
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:625:15)
    at Function.Module._load (internal/modules/cjs/loader.js:527:27)
    at Module.require (internal/modules/cjs/loader.js:683:19)
    at require (internal/modules/cjs/helpers.js:16:16)
    at Object.<anonymous> (/root/kui/bin/kui:8:1)
    at Module._compile (internal/modules/cjs/loader.js:777:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:788:10)
    at Module.load (internal/modules/cjs/loader.js:643:32)
    at Function.Module._load (internal/modules/cjs/loader.js:556:12)
    at Function.Module.runMain (internal/modules/cjs/loader.js:840:10) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ '/root/kui/bin/kui' ]
}

System

• Kui version: kui-shell@2.0.5
• Operating system: arch: ppc64le distribution: Ubuntu 18.04

[leo-lb]

You can see clearly here: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1242633/8#message-c5f3749688197d8af28a4ac7446cec4d928a11fc

Mark Mentovai:
Patch Set 2:

I appreciate the effort you’ve put in, but I’m not too keen to carry a substantial chunk of code that most of our developers have no way to validate, debug, or work on. The bare minimum to make me comfortable with this would be to either:

 - Clearly cordon off the new contribution as “contrib” and maintain it only on a best-effort basis. This would mean putting it in a separate directory, although at that point, a distinct overlay repository might make more sense.
 - Provide sufficient test infrastructure (try- and buildbots) to provide assurance that this port functions as intended and continues to work properly.
Note that I have the same concerns about MIPS: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1064594#message-6c0734640a0c8117a0a44302f340bd38a2d31296.

And for MIPS, it appears the only reason the merge happened is because that guy was on leave and wasnt here to interrupt it.

https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1064594/10#message-6c0734640a0c8117a0a44302f340bd38a2d31296

Mark Mentovai:
Patch Set 10:

I was on leave when this happened, so I couldn’t participate in the discussion at the time.

We don’t have any current MIPS consumers, and I’m not convinced that we should be supporting this in our tree.

So I think we should either wait until that guy is on leave again or discuss with him that Chromium is used downstream and it’s not only about their direct consumers.

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.