I'm currently attempting to get Docker set up (with Rocker) to debug a possible memory leak using rocker/r-devel-ubsan-clang. I used the following command to run docker:
docker run --name=r-devel-ubsan-clang -v (mydir):(mounteddir) --rm -ti rocker/r-devel-ubsan-clang /bin/bash
The version of Rdevel that results is: (2017-09-16 r73288) -- "Unsuffered Consequences". Any idea how I can upgrade to a newer Rdevel version? Thanks.
These containers are no longer build automatically, c.f. https://github.com/rocker-org/r-devel-san/issues/4. You can get the Dockerfile from github and build a newer version your self.
BTW, as noted in the Readme, you should add --cap-add SYS_PTRACE to the command line options.
Related
Turbo crashes when using any command (e.g. turbo build), even when a valid project and turbo.json exists. This doesn't seem to be a problem on Ubuntu, but only on Alpine (arm64).
I've tried all of the new versions but they have the same issue.
npm install --global turbo
npm install --global turbo#latest
npm install --global turbo#canary
error:
thread 'main' panicked at 'Failed to execute turbo.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', crates/turborepo/src/main.rs:23:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Because I was stuck on this for a few hours, I'll share solution here (which I also shared on Github):
If using a Dockerfile: add RUN apk add --no-cache libc6-compat to it
If using it on an Alpine machine, run apk add --no-cache libc6-compat
More explanation in:
Docker Node image docs
Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements.
One common issue that may arise is a missing shared library ... . To add the missing shared libraries to your image, adding the libc6-compat package in your Dockerfile is recommended: apk add --no-cache libc6-compat
https://github.com/vercel/turbo/issues/3373#issuecomment-1397080265
I am defining a Dockerfile where I install sqlite3 in a ubuntu based image, something very similar (I also install grpc and rust as well as all the necessary dependencies) to:
FROM ubuntu
RUN apt-get update && \
apt-get install -y sqlite3 libsqlite3-dev&& \
apt-get clean && \
apt-get autoremove
I use this image to built my Rust project within it. The issue that I am facing is that cargo build fails on my GitLab CI due to a linking issue:
Compiling migrations_macros v1.4.0
error: linking with `cc` failed: exit code: 1
...
= note: /usr/bin/ld: cannot find -lsqlite3
I found out that this is due to this symlink not being present on the Docker image that is running on CI:
libsqlite3.so -> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
while the file libsqlite3.so.0.8.6 exists. So if I create the symlink during the CI jobs I can have a working workaround. The weird thing is that if I pull the same exact image from my registry on my pc and run the container I can build without any issue and any change because the symlink is actually there.
What could be the cause of the problem and how to solve it?
After quite a bit of thinking the following ideas come to my mind which could help.
Docker history
Docker command has a build in feature to view the history of a built image. You have the option to identify the problematic command in the DockerFile.
docker history <image id or name>
For more visual filtering i do recommend dive tool but others are also available on google.
Correct docker version
Since in this scenario the two docker instances are different the question is trivial. Are they on the same version of docker daemon and docker file system driver?
I am trying to run a Qt app in docker. I have a very limited Linux experience. The OS is centos. Qt version is 5.9.1. The overall idea is to run it in Xvbf. (I have already run firefox in DISPLAY:1(Xvbf) inside docker under centos)
When I try "docker run -it myTestGuiApp", I get an error libGL.so.1: cannot open shared object file: No such file or directory.
What is missing here?
Thanks in advance.
You probably have a missing library. You might need to install this : yum install mesa-libGL
Just add this line in your dockerfile : RUN yum install mesa-libGL
If this doesn't work, copy here your dockerfile.
updated flow-bin with yarn global add flow-bin#latest. yarn global ls shows "flow-bin#0.38.0". flow version shows Flow, a static type checker for JavaScript, version 0.37.4. How update flow to latest version?
OS: Linux Ubuntu 16.04
Yarn: latest
P.S. I also did reboot several times...
Thanks for any help!
Fixed.
Check where is flow - whereis flow
Remove it - sudo rm -rf /usr/bin/flow
Add Flow - yarn global add flow-bin#latest
I don't remember if I installed Flow with NPM or no, even after deleting whole Node.js and NPM and reinstalling, it was always 0.37.4 version, but after that fix everything seems fine.
Same for Mac OS (Catalina)
Check where is flow - which flow
Remove it - sudo rm -rf /usr/local/bin/flow
Add Flow - yarn global add flow-bin#latest
Within my project (react-native) I had to match the target version of the .flowconfig-file to the corresponding version I get from flow version in Terminal.
I am having an issue with Travis CI - the commits that I push all fail with the same error:
0.06s$ curl -sSL "http://llvm.org/apt/llvm-snapshot.gpg.key" | sudo -E apt-key add -
gpg: no valid OpenPGP data found.
The command "curl -sSL "http://llvm.org/apt/llvm-snapshot.gpg.key" | sudo -E apt-key add -" failed and exited with 2 during .
Your build has been stopped.
I tried to rebuild a previous commit that built successfully and the same error occurs. Any suggestions as to how to troubleshoot the issue?
http://llvm.org/apt/llvm-snapshot.gpg.key is returning 404 since about 2 days ago. And http://llvm.org/apt/ which is linked from their homepage returns 404.
The topic in the #llvm channel on IRC mentions:
APT repo temporary switched off. Check ML for the latest updates.
The ML announcement:
TL;DR: APT repo switched off due to excessive load / traffic
Recently we realized that APT repo generates almost 95% of I/O on
llvm.org and more than 40% of network bandwidth alone. During last 2
weeks the main services on llvm.org (svn, git, bugzilla) had serious
problems with overall connectivity.
We decided to temporary switch APT repo off to see if this would help.
Stay tuned for updates.
Temp solution
Since the llvm server still down I'm using the clang provided in the Ubuntu package.
addons:
apt:
sources:
- ubuntu-toolchain-r-test
#- llvm-toolchain-precise-3.7
packages:
- libgnome-keyring-dev
#- clang-3.7
- clang
Full example: https://github.com/sqlectron/sqlectron-gui/blob/master/.travis.yml#L35
The only problem is that installs the version 3.4 or 3.5. Which looks be much slower than the latest one available on llvm package.
The llvm server is still down. However, a very good idea from the people behind rust (https://github.com/rust-lang/rust) is to solve this issue by using Docker.
See the .travis.yml file here:
https://github.com/rust-lang/rust/commit/b1651fb4d2c0349ccca108b8d24210d688507936
You can find the travis build here:
https://travis-ci.org/rust-lang/rust/builds/134924068
I incorporated Docker into my builds with excellent results, but it took me a couple of days to do so. You can find my approach here: https://github.com/fuzzylite/fuzzylite/tree/master in files /Dockerfile and /.travis.yml
and the results here: https://travis-ci.org/fuzzylite/fuzzylite/builds/137058927
here is an example how to currently solve this and use clang 3.7.
sudo: required
dist: trusty
env:
global:
- LLVM_VERSION=3.7.0
- LLVM_ARCHIVE_PATH=$HOME/clang+llvm.tar.xz
before_install:
- wget http://llvm.org/releases/$LLVM_VERSION/clang+llvm-$LLVM_VERSION-x86_64-linux-gnu-ubuntu-14.04.tar.xz -O $LLVM_ARCHIVE_PATH
- mkdir $HOME/clang+llvm
- tar xf $LLVM_ARCHIVE_PATH -C $HOME/clang+llvm --strip-components 1
- export PATH=$HOME/clang+llvm/bin:$PATH
I'm doing the same for clang 3.5/3.6/3.7/3.8 and it works.
I call clang++ and not clang++-3.7 or whatever - it is prepended to the PATH.