Whenever I try to create an application based on the Haskell cartridge, it results in the a variant of the following error:
The initial build for the application failed: Shell command '/sbin/runuser -s /bin/sh 55c67c940c1e6694ac000017 -c "exec /usr/bin/runcon 'unconfined_u:system_r:openshift_t:s0:c5,c753' /bin/sh -c \"gear postreceive --init >> /tmp/initial-build.log 2>&1\""' returned an error. rc=137 .Last 10 kB of build output: The server is not running, nothing to stop. Repairing links for 1 deployments Building git ref 'master', commit 6b8beb4 Downloading the latest package list from hackage.haskell.org
This happens for predefined cartridges in the Openshift hub, such as Snap, Yesod, Scotty, and for the cartridges defined in the wiki (https://wiki.haskell.org/Web/Cloud).
I'm requesting help because he application never gets created thus I can't check the logs, and I can't make much from the error message. I tried other cartridge types than Haskell, and they get created just fine.
This is caused by https://github.com/haskell/cabal/issues/2396, see https://wiki.haskell.org/Web/Cloud#OpenShift. May be fixed in cabal-install 1.24.
Related
Now the version of OCaml compiler in my ubuntu20.04 docker container is 4.08.1, however I need OCaml 3.12.1 to build a project. So I tried opam switch create 3.12.1 and get an error like this:
The compilation of ocaml-base-compiler failed at "/root/.opam/opam-init/hooks/sandbox.sh build
./configure -prefix /root/.opam/3.12.1".
...
bwrap: Creating new namespace failed: Operation not permitted
the docker container is running without --privilege option, I guess this may be the reason. However, I have been using this container for a long time, so it may be diffcult to commit it or migrate its content to another container. Is there any other approach to use a specific-version OCaml compiler?
You can disable sandboxing when initializing opam with
opam init --disable-sandboxing
With this configuration option, opam will not call bubblewrap when building package thus avoiding the issue with nested sandboxing.
I would like to emulate google fuchsia OS on my jetson nano (arm64) with qemu and kvm. This is guide that I'm reading from :
https://fuchsia.dev/fuchsia-src/get-started/get_fuchsia_source
below u can see the full log,with all the commands that I have issued and the replies that I've got,until the last one that's the error that I'm not able to fix :
/opt# python --version
Python 3.8.11
/opt# curl -sO https://storage.googleapis.com/fuchsia-ffx/ffx-linux-x64 && chmod +x ffx-linux-x64 && ./ffx-linux-x64 platform preflight
bash: ./ffx-linux-x64: cannot execute binary file: Exec format error
/opt# curl -s "https://fuchsia.googlesource.com/fuchsia/+/HEAD/scripts/bootstrap?format=TEXT" | base64 --decode | bash
WARNING: Jiri doesn't support timely updates for arch 'aarch64'. This or future binaries of Jiri might be out of date.
cipd bootstrapped to path:"/opt/fuchsia/.jiri_root/bin/cipd"
Please add /opt/fuchsia/.jiri_root/bin to your PATH
WARN: Please opt in or out of analytics collection. You will receive this warning until an option is selected.
To check what data we collect run: jiri init -show-analytics-data
To opt-in run: jiri init -analytics-opt=true "/opt/fuchsia"
To opt-out run: jiri init -analytics-opt=false "/opt/fuchsia"
Updating all projects
WARN: Some packages are skipped by cipd due to lack of access, you might want to run "/opt/fuchsia/.jiri_root/bin/cipd auth-login" and try again
Done creating a Platform Source Tree at "/opt/fuchsia".
Recommended: export PATH="/opt/fuchsia/.jiri_root/bin:$PATH"
/opt# nano ~/.bash_profile
export PATH=/opt/fuchsia/.jiri_root/bin:$PATH
source /opt/fuchsia/scripts/fx-env.sh
/opt# source ~/.bash_profile
/opt# jiri help
Command jiri is a multi-purpose tool for multi-repo development.
Usage:
jiri [flags] <command>
/opt/fuchsia# fx help
usage: fx [--dir BUILD_DIR] [-d DEVICE_NAME] [-i] [-x] COMMAND [...]
Run Fuchsia development commands. Must be run from a directory
that is contained in a Platform Source Tree.
/opt/fuchsia# fx set core.qemu-arm64
WARNING: Please opt in or out of fx metrics collection.
You will receive this warning until an option is selected.
To check what data we collect, run `fx metrics`
To opt in or out, run `fx metrics <enable|disable>
/opt/fuchsia/tools/devshell/go: line 21: /opt/fuchsia/prebuilt/third_party/go/linux-arm64/bin/go: cannot execute binary file: Exec format error
/opt/fuchsia/tools/devshell/go: line 21: /opt/fuchsia/prebuilt/third_party/go/linux-arm64/bin/go: Success
ERROR: Failed to build fx set.
ERROR: Please file a bug using `fx report-bug set` with the full error copy-pasted.
ERROR: Rerun your command using the uncompiled version:
ERROR: fx --enable=legacy_set set core.qemu-arm64
/opt/fuchsia# fx --enable=legacy_set set core.qemu-arm64
WARNING: Please opt in or out of fx metrics collection.
You will receive this warning until an option is selected.
To check what data we collect, run fx metrics
To opt in or out, run `fx metrics <enable|disable>
ERROR Could not execute Ninja. I was trying to execute "/opt/fuchsia/prebuilt/third_party/ninja/linux-arm64/ninja"
I'll begin by pointing this out from the source code guide:
At this time the preflight tool is only provided as an x64 prebuilt. Fuchsia is currently not guaranteed to build successfully on other host architectures.
So this isn't an officially supported path, and there may be sharp edges. Any time you see Exec format error popping up in your logs it relates to the fact that a prebuilt isn't running on the correct architecture. This may be because the arm64 prebuilt doesn't exist or perhaps it was improperly fetched.
For ffx platform preflight, there are currently no arm64 binaries uploaded (the command you copied pulled the x64 binary). However, this step only helps validate prerequisites...it's not required to complete the build. I have filed fxbug.dev/80517 related to possibly adding support for this.
The subsequent errors coming from fuchsia/prebuilt relate to issues with the linux-arm64 binaries downloaded during bootstrap. I would recommend filing an issue for this as a feature request in the public issue tracker.
I'm building a nodejs app from OSX and trying to deploy it to kubernetes using rules_k8s.
It almost works, except that the node doesn't start because of this error:
/app/examples/hellohttp/nodejs/nodejs-hellohttp_image.binary: line 147: /app/examples/hellohttp/nodejs/nodejs-hellohttp_image.binary.runfiles/com_github_yourbase_yourbase/external/nodejs/bin/node: cannot execute binary file: Exec format error
/app/examples/hellohttp/nodejs/nodejs-hellohttp_image.binary: line 147: /app/examples/hellohttp/nodejs/nodejs-hellohttp_image.binary.runfiles/com_github_yourbase_yourbase/external/nodejs/bin/node: Success
It looks like the node binary being deployed wasn't built for the right platform where k8s is running (linux with amd64, normal Google GKE nodes).
The command I'm using to make the deployment:
bazel run --cpu=k8 //examples/hellohttp/nodejs:nodejs-hellohttp_deploy.apply
I tried with other combinations of --platforms or --cpu but I couldn't get it to work.
The argument that felt like the closest was this:
$ bazel run --platforms=#bazel_tools//platforms:linux //examples/hellohttp/nodejs:nodejs-hellohttp_deploy.apply
ERROR: While resolving toolchains for target //examples/hellohttp/nodejs:nodejs-hellohttp_deploy.apply: Target constraint_value rule #bazel_tools//platforms:linux was found as the target platform, but does not provide PlatformInfo
ERROR: Analysis of target '//examples/hellohttp/nodejs:nodejs-hellohttp_deploy.apply' failed; build aborted: Target constraint_value rule #bazel_tools//platforms:linux was found as the target platform, but does not provide PlatformInfo
INFO: Elapsed time: 0.255s
FAILED: Build did NOT complete successfully (0 packages loaded)
ERROR: Build failed. Not running target
This says there was a toolchain problem, and says something about missing PlatformInfo, but it doesn't say anything about how do I fix it. :-(
For what is worth, with Go I had similar problems, and they were solved by passing --experimental_platforms=#io_bazel_rules_go//go/toolchain:linux_amd64 to the bazel run command.
How do I make something similar work for nodejs?
We installed Ubuntu 14.04.
We want to install fbthrift there.
We did the git clone of fbthrift.
We then did a git checkout of version v2017.06.05.00.
We followed the guidance in README.md, and ran the script called ./build/deps_ubuntu_14.04.sh
It dies trying to build fbthrift/thrift/build/deps/folly/folly/stats/test
saying "*** No rule to make target 'all'. Stop."
It just finished successfully building in .../folly/folly/io/test.
Interestingly, io/test has a Makefile.am, a Makefile.in, and a Makefile.
stats/test only has a Makefile.am.
I don't know where in this automated script the "autoconf" and "automakers" steps were supposed to be executed on stats/test.
Help?
Been running stack/ghc inside Debian 8.2 via vagrant for a while. This morning:
$ stack setup
Run from outside a project, using implicit global project config
Using resolver: lts-4.2 from implicit global project's config file: /home/vagrant/.stack/global-project/stack.yaml
Downloading lts-4.2 build plan ...TlsExceptionHostPort (HandshakeFailed (Error_Protocol ("certificate has expired",True,CertificateExpired))) "raw.githubusercontent.com" 443
$ stack --version
Version 1.0.2, Git revision fa09a980d8bb3df88b2a9193cd9bf84cc6c419b3 (3084 commits) x86_64
The same error remains even if I delete ~/.stack. Did I mess something up?
You might want to try running stack -v setup to be able to see which files are being downloaded.
Then identify which file(s) cannot be downloaded due to this TlsExceptionHostPort - hopefully there won't be too many of them - and run:
curl -0 https://raw.githubusercontent.com/path_to_your_file > your_file
Once your blocking file(s) have been downloaded, re-run stack setup.
This might not be a clean approach, but it worked for me.