I want to run tests of my Phoenix app on Travis-CI.
Log excerpt:
$ MIX_ENV=test mix do deps.get, compile, test
Could not find hex, which is needed to build dependency :phoenix
Shall I install hex? [Yn]
When it comes to fetching and installing dependencies, it asks if it should install hex. I was wondering if I can pass a --yes option to mix so that it doesn't ask but just installs?
You can add this command to your before_install section in .travis.yml
mix local.hex --force
After of course, you've already installed elixir in a previous command. I
cargo culted this .travis.yml from an existing elixir project on github.
language: erlang
env:
- ELIXIR="v1.0.0"
otp_release:
- 17.1
before_install:
- mkdir -p vendor/elixir
- wget -q https://github.com/elixir-lang/elixir/releases/download/$ELIXIR/Precompiled.zip && unzip -qq Precompiled.zip -d vendor/elixir
- export PATH="$PATH:$PWD/vendor/elixir/bin"
- mix local.hex --force
script: "MIX_ENV=test mix do deps.get, test"
As with any unix command, you could pipe yes into the mix command:
yes | MIX_ENV=test mix do deps.get, compile, test
But there are some warnings about this solution in the comments below. I recommend using the top voted solution!
Related
As sometime I am trying to compile a full version (with all options) of rsync on MacOS (please, do not ask why I want to do it - if you can help me clear and directly, thank you so much. Otherwise, do not waste your time).
I found a really helpful script made by "junsionzhang" (https://gist.github.com/junsionzhang), which in my option is simple and direct. Thank you junsionzhang!
Even being a good script, clear, step-by-step, there are some steps that does not work for me (and I tried a lot and for a while).
Here is the script (at Oct, 16, 2022):
#Compile rsync 3.0.7
#Follow these instructions in Terminal on both the client and server to download and compile rsync 3.0.7:
#Download and unarchive rsync and its patches
cd ~/Desktop
curl -O http://rsync.samba.org/ftp/rsync/src/rsync-3.1.2.tar.gz
tar -xzvf rsync-3.1.2.tar.gz
rm rsync-3.1.2.tar.gz
curl -O http://rsync.samba.org/ftp/rsync/src/rsync-patches-3.1.2.tar.gz
tar -xzvf rsync-patches-3.1.2.tar.gz
rm rsync-patches-3.1.2.tar.gz
cd rsync-3.1.2
#Apply patches relevant to preserving Mac OS X metadata
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
patch -p1 <patches/hfs-compression.diff
#Configure, make, install
./prepare-source
./configure
make
sudo make install
#Verify your installation
/usr/local/bin/rsync --version
#By default, rsync will be installed in /usr/local/bin.
#If that isn't in your path, you will need to call your new version of rsync by its absolute path (/usr/local/bin/rsync).
The three patches lines does not work for me. After patching the fileflags, the rsync patched can not me "prepared", and of course, not be configured. The others, crtimes.diff and hfs-compression.diff, does not exist on the TAR package.
So, questions:
Trying to compile the 3.2.6 version os MacOS Big Sur (11.7), what do I need and which is the right/correct way and steps to patch, update and have the "correct"version?
How do I (correctly) compile and install the all the libraries to have a real full rsync version, with all features available (ACL support, Xattr support, xxhash, zstd, lz4, openssl crypto, and so on...)?
I would like to update and contribute to a new "junsionzhang" script version, making options to install a simple/standard version (rsync only) and options to install the libraries and choose for a "more complete" version, and help another Mac users and the community. How can I make this bash script?
How to install gawk, mawk, nawk, awk ( and where from (what are the differences): gawk, mawk, nawk?
Some libraries I already have installed (which I do not know if I did them right) seems to be outdated. How to I update them?
When running "./prepare-source", i get this: "make: Nothing to be done for `conf'.". Does this is right?
Thank you all! I really appreciate for all help I can get!
Completely untested (I don't run MacOS).
URLs to access the source code:
Source Version Tarballs: https://rsync.samba.org/ftp/rsync/src/
Git repository: https://github.com/WayneD/rsync
might need these pre-requisites (from INSTALL.md):
brew install automake
brew install xxhash
brew install zstd
brew install lz4
brew install openssl
code to download and extract (to ~/Desktop/rsync-3.2.6):
# Download the relevant version of Rsync and the same version of
# Rsync patches, extract them and apply the "suggested"
# patches from the original script:
cd ~/Desktop
# Rsync
curl -O https://rsync.samba.org/ftp/rsync/src/rsync-3.2.6.tar.gz
tar -xzvf rsync-3.2.6.tar.gz
rm rsync-3.2.6.tar.gz
# Patches
curl -O https://rsync.samba.org/ftp/rsync/src/rsync-patches-3.2.6.tar.gz
tar -xzvf rsync-patches-3.2.6.tar.gz
rm rsync-patches-3.2.6.tar.gz
apply the "suggested" patches, light the blue touch paper and stand back:
cd ~/Desktop/rsync-3.2.6
# Apply patches relevant to preserving Mac OS X metadata
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
patch -p1 <patches/hfs-compression.diff
# Configure, make, install
./prepare-source
./configure
make
sudo make install
# Verify your installation
/usr/local/bin/rsync --version
I have a package that previously only targeted RPM based distros for which I am now building .deb packages for Debian based distros.
The aim is to simulate a test installation from user-space that is isolated from the system you are building on. It may be multi-user and you do not want to require root access just to build the software. Many of our tests simulate the installation directory structure already. This is for the next step up to simulate an actual installation using packages built.
For the RPM packages I was able to create test installations using:
WSDIR=/where/I/want/my/tests/to/run
rpmdb --initdb --dbpath "$WSDIR"/rpmdb
rpm --relocate /opt="$WSDIR"/opt --dbpath $WSDIR/rpmdb -i <package>.rpm
The equivalent in the Debian world is something like:
dpkg --force-not-root --admindir=$WSDIR/dpkg --root=$WSDIR/install --install "$DEB"
However, I am stuck over the equivalent to the rpmdb --initdb step.
Note that I can just unpack the archive using:
dpkg-deb -x "$DEB" $WSDIR/install
But I would prefer to be closer to how a real package is installed.
Also I don't think this will run preinstall and postinstall scripts.
Similar questions have suggested using deboostrap to create a chroot environment but this creates a complete new installation. As well as being overkill it is too slow for an automated test. I intend to use this for quick tests of the installation package prior to further testing in actual test environments.
My experiments so far:
(cd $WSDIR/dpkg && mkdir alternatives info parts triggers updates)
cp /var/lib/dpkg/status $WSDIR/dpkg/status
have at best resulted in:
dpkg: error: unable to access dpkg status area: No such file or directory
which does not indicate clear what is wrong.
So how do you create a dpkg admin directory?
Cross posted as https://superuser.com/questions/1271145/how-do-you-create-a-dpkg-admin-directory
Update 24/11/2017
I've tried copying using the dpkg dir from an environment created by [cowdancer][1] (which uses deboostrap under the hood) or copying the real one from /var/lib/dpkg but I still get the same error message so perhaps the error (and/or the --admindir option) doesn't mean quite what I think it means.
Note that:
sudo dpkg --force-not-root --root=$WSDIR/install --admindir=/var/lib/dpkg --install "$DEB"
does work. So it is something to do with the admin dir.
I've also retitled the question as "How do you create a dpkg admin directory" is interesting question but the answer is not necessarily the solution to my problem.
The minimal way to create a dpkg database is something like this:
$ mkdir -p db/{updates,info}
$ touch db/{status,diversions,statoverride}
If you want to use that as non-root, currently the best way is to use fakeroot.
$ mkdir -p fsys
$ PATH=/sbin:/usr/sbin:$PATH fakeroot dpkg --log=/dev/null --admindir=db --instdir=fsys -i pkg.deb
But take into account that passing --root after --admindir or --instdir will reset those paths, which is I think the problem you have been having here.
Also using sudo and --force-not-root does not make much sense? :) And is definitely less confined than using just fakeroot. In the near future it will be possible to run dpkg fully unprivileged in some local tree.
I eventually found an answer for this. Thanks to Guillem Jover for some of this.
Pasting a copy of it here:
mkdir fake
mkdir fake/install
mkdir -p fake/dpkg/info
mkdir -p fake/dpkg/updates
touch fake/dpkg/status
PATH=/sbin:/usr/sbin:$PATH fakeroot dpkg --force-script-chrootless --log=`pwd`/fake/dpkg.log --root=`pwd`/fake --instdir `pwd`/fake --admindir=`pwd`/fake/dpkg --install *.deb
Some points to note:
--force-not-root is not enough. fakeroot is required.
ldconfig and start-stop-daemon must be on the path.
(hence PATH=/sbin:/usr/sbin:$PATH)
The log file needs to be relocated from the default /var/log/dpkg.log
The order of arguments is significant. If used --root must be before --instdir and --admindir.
The admindir is supposed to have a the installation dir as a prefix.
If the package contains any pre or post installation scripts (preinst,postinst) then --force-script-chrootless is required as these scripts are normally run via chroot() which gives operation not permitted when attempted under fakeroot.
For a quick test of trivial dependencies, you can directly install on the system using 'dpkg -i' then 'dpkg -P' and 'apt-get autoremove' to purge the package and clean the dependencies.
An other more secure but slower solution could be to use the autopkgtest package:
https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
I am trying to automate an Aerospike database installation using saltstack version 2015.5.2 on an Ubuntu machine.
The following is the process of manual installation that I want to automate. (I'll only mention the key steps to keep it simple)
Download Aerospike
wget -O aerospike.tgz
http://aerospike.com/download/server/latest/artifact/ubuntu12
extract the contents of the package
tar -xvf aerospike.tgz
Install Aerospike Server & Tools
cd aerospike-server-community-3.5.15-ubuntu12.04
./asinstall
Start Aerospike
/etc/init.d/aerospike start
Step 3 performs the actual installation which includes installation of 2 packages: aerospike-server-community and aerospike-tools.
Now in the saltstack state file I want to check if both the packages are already present on server, and in that case do not execute the ./asinstall command in step 3.
How can I involve that condition in my automated process?
I recommend you read requisites in salt before going on because you can find many interesting things there.
Furthermore,what you really need, in my opinion is: UNLESS, because if you already have these packages on your system they should not be installed. Unless can be used together with the pkg keyword, but for you the rpm -q package_name might work just as well.
It should look something like this:
start_process:
cmd.run:
- name: 'write here your command'
- unless:
- rpm -q package1,package2
I would like to provide a small comment to the answer, but my reputation does not allow me, so I apologize in advance for this.
This line:
- rpm -q package1,package2
Should actually be:
- rpm -q package1 package2
I want to call ShellCheck, a Haskell program for linting shell scripts, from a Makefile.
When I install ShellCheck via cabal install, it is installed as ~/.cabal/bin/shellcheck. So, I have configured Bash accordingly:
$ cat ~/.bashrc
export PATH="$PATH:~/.cabal/bin"
$ source ~/.bashrc
$ shellcheck -V
ShellCheck - shell script analysis tool
version: 0.3.4
license: GNU Affero General Public License, version 3
website: http://www.shellcheck.net
This enables me to run shellcheck from any directory in Bash. However, when I try to call it from a Makefile, make cannot find shellcheck.
$ cat Makefile
shlint:
-shlint lib/
shellcheck:
-shellcheck lib/**
lint: shlint shellcheck
$ make shellcheck
shellcheck lib/**
/bin/sh: 1: shellcheck: not found
make: [shellcheck] Error 127 (ignored)
I think that make is not receiving the same PATH as my normal Bash shell. How can I fix this?
Try using $HOME, not ~:
export PATH="$PATH:$HOME/.cabal/bin"
The ~-means-home-directory feature is not supported in pathnames everywhere in all shells. When make runs a recipe it doesn't use the user's shell (that would be a disaster!) it uses /bin/sh always.
On some systems (particularly Debian/Ubuntu-based GNU/Linux distributions) the default /bin/sh is not bash, but rather dash. Dash doesn't support ~ being expanded in the PATH variable.
In general, you should reserve ~ for use on the command line as a shorthand. But in scripting, etc. you should always prefer to write out $HOME.
ETA:
Also, the double-star syntax lib/** is a non-standard feature of shells like bash and zsh and will not do anything special in make recipes. It is identical to writing lib/*.
You can force make to use a different shell than /bin/sh by adding:
SHELL := /bin/bash
to your makefile, for example, but this makes it less portable (if that's an issue).
I am trying to install ODBC driver for Debian arrording to these instructions: https://blog.afoolishmanifesto.com/posts/install-and-configure-the-ms-odbc-driver-on-debian/
However trying to run:
sqlcmd -S localhost
I get the error
libcrypto.so.10: cannot open shared object file: No such file or
directory
What could be the cause?
So far I have tried
1.
$ cd /usr/lib
$ sudo ln -s libssl.so.0.9.8 libssl.so.10
$ sudo ln -slibcrypto.so.0.9.8 libcrypto.so.10
2.
/usr/local/lib64 to the /etc/ld.so.conf.d/doubango.conf file
3.
sudo apt-get update
sudo apt-get install libssl1.0.0 libssl-dev
cd /lib/x86_64-linux-gnu
sudo ln -s libssl.so.1.0.0 libssl.so.10
sudo ln -s libcrypto.so.1.0.0 libcrypto.so.10
4. Sudo apt-get install libssl0.9.8:i386
None of these have helped.
As I'm quite familiar with Debian and programming, here is some advice:
if you have questions about setting up your system, ask on SuperUser and/or (if your question is specific to a Un*x flavour) on Unix&Linux
when fuddling around with symlinks to shared-libraries, you should have a thorough understanding of what you are doing. these files are named for a reason - and the reason is to protect you (the user of the system) from weird crashes, because an application is using a wrong/incompatible library.
a tutorial that tells you to do so, should give proper warning and explanation about what you are to do.
So, why are these instructions in the tutorial you are following?
The application you are trying to run, has been linked against libcrypto.so.
On the developer machine (that was used to produce the application binary), libcrypto.so was a symlink to libcrypto.so.10, but this is missing on Debian: maybe because the library has been removed (and replaced by a new and incompatible version), or because Debian uses a different naming scheme as compared to the system that was used to compile the application.
If it is the former, then you cannot solve the issue by using symlinks.
You have to get the right library (or the application linked against the correct libraries).
If it is the latter, you may get away with symlinking the expected library name with the correct library files found on your system. (This is assuming that the only difference between the two systems is indeed the so-naming scheme).
So, how to do it?
first of all, you should find out, against which libraries your application was really linked, and which of these libraries are missing.
$ ldd /path/to/my/app | grep -i "not found"
libfoo.so.10 => not found
then find out, whether you have a (hopefully compatible) library on your system. A good place to start is /usr/lib/. but not-so-recently, Debian has started moving the libraries to /usr/lib/<host-triplet>, with <host-triplet> describing a target architecture. You can find out the default value if your application was indeed built for the architecture you are running (e.g. for linux-amd64) you can get the string by running something like:
$ gcc -print-multiarch
Imagine you discover that you have /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0.
if you have good reason to believe that this can act as a replacement for libfoo.so.10, you can go make the found library available to your application by means of a symlink, e.g.
# cd /usr/local/lib/
# ln -s /usr/lib/x86_64-linux-gnu/libfoo.so.1.0.0 libfoo.so.10
Finally, you might need to refresh the cache of the dynamic linker so it starts using the new library, by running ldconfig as root/superuser.