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.
Related
When I enter "brew services start mariadb" on the command line I receive the following error -
Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.
Error: Failure while executing; /bin/launchctl bootstrap gui/501 /Users/jordanjohnston/Library/LaunchAgents/homebrew.mxcl.mariadb.plist exited with 5.
I've seen folks having the same error and have tried entering -
"launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.mariadb.plist"
followed by -
"launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mariadb.plist"
which does nothing for me, still receiving the same error. I have also entered "brew restart mariadb" which does not work either. I have also uninstalled and reinstalled mariadb which did not work. Thank you in advance for any help!
Also tried the same as you described with no luck. Finally ended up reinstalling Homebrew:
Make any pending updates for XCode. However, it might ask to also update the developer tools later on in step 4
Remove Homebrew. Make sure to have a backup of anything you want to save. For me, it was MariaDB and PostgreSQL databases. I also kept track of any important package I wanted to reinstall later:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"
Remove any other pending directory as Homebrew suggests:
sudo rm -r /opt/homebrew
Reinstall Homebrew:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Install MariaDB:
brew install mariadb
Start MariaDB:
brew services start mariadb
Check that is all good:
brew services list
You should see something like this:
I wanted to try learn things in DPDK in Debian 10 buster VM.
I have taken DPDK 20.08 as source.
I followed steps as mentioned in Compiling the DPDK Target from Source https://doc.dpdk.org/guides/linux_gsg/build_dpdk.html#uncompress-dpdk-and-browse-sources
I have tried to follow the below steps
tar xJf dpdk-<version>.tar.xz
cd dpdk-<version>
meson build
cd build
ninja
ninja install
ldconfig
On the above when I tried
ninja
it works. Then I went for next command
If I try with
sudo ninja install
from dpdk build directory
it says sudo: ninja: command not found
If I try
ninja install with out sudo
it gets terminated with error.
It asks for sudo password then shows
ModuleNotFoundError: No module named mesonbuild
Failed Meson-install
ninja:build stopped:subcommand failed
Would appreciate your help to resolve this step.
Edit
Repeated steps with root account. Problem didn't occur. Initially it was looking in /home/vijay/.local/bin folder. Then I used from /usr/local/bin/meson
The error information ninja: command not found could be 1 of the 2 things
either NINJA utility is not installed
or PATH for NINJA Binary is incorrect
As recommended in the comment, ensure 'ninja' is installed and you have the right path like /usr/bin/ for the same.
[EDIT] #Vijay has updated it is indeed the path related issue.
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?
Very nooby question, but I'm trying to install Atom text editor on Raspbian Stretch. Is it possible? I've heard because it runs on Electron, it's quite slow for Raspbian. I keep getting an error saying:
E: Unable to locate package atom
I'm following the official instructions for Debian. How can I fix this?
As of today you can't install the official package provided for Debian for its mismatching the hardware platform. Provided binary is for running on x86 hardware, but RPi doesn't come with an Intel/AMD processor, but ARM. So, you most probably need to build it from source yourself.
Primer
So, if you really want to build this from source, you should be aware of the waste of disk space caused by the IMHO poorly implemented build tool which is downloading tons of deps and copying and transpiling code around so you'll end up with 2GB+ of files with 80% accounting to dependencies, only. Since my RPi works with 8GB smartcard, only, I couldn't ever meet the need for disk space even though I was bleeding out Linux by manually removing docs, manpages, locales, ton's of outdated and mostly unused apps etc. The build also requires a whole build tooling chain, tons of dev packages for libraries, so there is a limit to milk the system ... 8GB disk drive simply isn't enough for this.
Eventually I tried moving all the files to a USB pen drive. But that drive must be formatted using a filesystem capable of symlinking. So you can't use vfat or FAT32. I didn't succeed to get a 16GB stick formatted with either version of extfs. The mkfs always ended up in a deadlock on trying to write its superblocks. Astonishingly, I couldn't even kill the mkfs with -KILL, but unplugging the drive did help in that case.
So, as a conclusion: here is a short list of steps I passed in expectation to get this working, but in the end I didn't finish due to the memory issues above. And frankly, I stopped caring ... I'd rather work with nano/vi in a terminal than using this ridiculous lego-like built software. I guess, atom is today's version of emacs with regards to the latter's acronym. Maybe you succeed with this, but I won't ...
Build from Source
Inspired by https://discuss.atom.io/t/atom-on-the-raspberry-pi/33332
Install toolchain for building native stuff
sudo apt-get install build-essential git libgnome-keyring-dev fakeroot gconf2 gconf-service libgtk2.0-0 libudev1 libgcrypt20 python rpm libsecret-1-dev xorg-dev
This set of tools was sufficient to build core files without error. Since I didn't start with a fresh installation of Raspbian there might have been some tool I have been using before, so maybe in your case there are more tools to be installed here. Look out for error messages in early stage of building and try to see if some library or header file isn't found. This mostly indicates lack of some package with name ending in -dev to be installed, too. Start by searching for the package using apt search <name-of-mentioned-library> and look for a package combining the missing library's name with suffix -dev. Then install it the usual way by invoking sudo apt-get install <package-name>.
Install up-to-date nodejs
Raspbian Stretch comes with support for NodeJS 8.11 which is basically okay. Install it and its package manager npm using this command:
sudo apt-get install node-js npm
Check installed versions with
node -v
npm -v
This should display 8.x.x on behalf of NodeJs. Use n afterwards if you want to step up:
sudo npm i -g n
sudo n lts
This will switch NodeJS to latest LTS release, which is 10.x as of now. Upgrading NodeJS is optional, but feel advised to always use latest version of npm:
sudo npm i -g npm
Check if upgrades succeeded:
node -v
npm -v
Adjust configuration of npm and install some essential dep:
sudo npm config set -g python /usr/bin/python2
sudo npm i -g node-gyp
Build Atom
Get the source. One option is to pull latest code from its repository:
git clone https://github.com/atom/atom.git
This is creating subfolder atom containing all source files. You might want to download sources of a recent release instead. But this tutorial was made with the sources fetched from Github. So make sure there is subfolder called atom containing sources similar to the ones fetched above.
It's time to start the beast:
cd atom
./script/build
This process will take a while. And it is the culprit that never finished on success in my case due to eating up all disk space over and over again.
Whenever the script fails on error, try to analyze the error, find the cause, fix it, then start the script by repeating the last command above again. If you don't remove any file in subfolder atom in between, the build script keeps passing steps of building atom it has passed successfully before.
Install atom
According to the original tutorial linked before the script should finish on success eventually. Then it's time to install with:
./script/grunt install
I guess this is causing atom to be available as a command from CLI. So, try it out. If everything looks fine you are finally ready to remove the waste of files in subfolder atom.
Feel free to report if this was working in your case.
From what I recall Atom runs 64-bit architecture; need the latest raspberry Pi.
run the following
wget https://atom.io/download/deb && dpkg -i deb
I successfully created an example .travis.yml file and the build passes. However, it is a bit slow. The main cause is composer install and it takes up to 40 seconds.
Since my experience with Travis CI is 2 days old, I need someone with experience to tell me what is the better practise when it comes to using composer install in Travis environment? Under what block I should call it and what should be the command itself?
Note: I use Symfony projects so if there is something specific to this framework, please let me know.
I read some blog posts and went through example files in some open source projects and ended up confusing myself. Some use under before_script: and some install: etc. Also some use composer install, composer install --prefer-source --no-interaction --dev, travis_retry composer install --ignore-platform-reqs --no-interaction --prefer-source so on. My aim is to speed up the build time.
What's wrong with composer and your .travis.yml?
Composer update without PHP environment checking
PHP and Continuous Integration with Travis CI
so on
My own .travis.yml.
language: php
php:
- 5.6
env:
global:
- SOURCE_DIR=src
install:
- sudo apt-get update > /dev/null
- sudo apt-get install apache2 libapache2-mod-fastcgi > /dev/null
before_script:
- ...
- ...
- composer self-update
- composer install
- ...
- ...
script:
- bin/phpspec run --no-ansi --format=dot
- bin/behat --profile=default -f progress
- ...
- ...
There's no one right answer for which section the composer install belongs to IMO. Use what makes sense for you. I would put it in install.
Prefixing it with travis_retry is also a good idea if the command is prone to fail due to network issues. for example. It'll retry the same command a default number of 3 times. The command is only considered a failure if after all retry attempts the wrapped command still did not exit 0.
As for speeding up you build, I wouldn't bother for eliminating 40s from the build time. That said, you can have a look at caching the composer install directory. This would save a tarball of that dir after the builder finishes and try to get it from network storage at the beginning of the next build. That way only new.changed dependencies would be needed to install. Since that archive lives on network storage and not inside the container however, this might just not give you any actual speedup. Docs for caching