What is the proper way to install bubblewrap for opam (ideally without admin priviledges)? - ocaml

I am getting this error:
(iit_synthesis) brando9~ $ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh)"
## Using already downloaded "/tmp/user/22003/opam-2.1.4-x86_64-linux"
## Where should it be installed ? [/lfs/ampere4/0/brando9/.local/bin] ~/.local/bin
## '~/.local/bin' resolves to '/lfs/ampere4/0/brando9/.local/bin', do you confirm [Y/n] Y
## opam 2.1.4 installed to /lfs/ampere4/0/brando9/.local/bin
## Converting the opam root format & updating
No configuration file found, using built-in defaults.
Checking for available remotes: rsync and local, git.
- you won't be able to use mercurial repositories unless you install the hg command on your system.
- you won't be able to use darcs repositories unless you install the darcs command on your system.
[WARNING] Missing dependencies -- the following commands are required for opam to operate:
- bwrap: Sandboxing tool bwrap was not found. You should install 'bubblewrap'. See https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap.
[ERROR] Sandboxing is not working on your platform ubuntu:
"~/.opam/opam-init/hooks/sandbox.sh build sh -c echo SUCCESS >$TMPDIR/opam-sandbox-check-out && cat $TMPDIR/opam-sandbox-check-out; rm -f
$TMPDIR/opam-sandbox-check-out" exited with code 10
Do you want to disable it? Note that this will result in less secure package builds, so please ensure that you have some other isolation mechanisms in
place (such as running within a container or virtual machine). [y/N]
but it doesn't link to a way to actually install it, link given https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap and also I thought this would mean I don't need to do that:
opam init --disable-sandboxing
opam update --all
eval $(opam env)
am I wrong? I'm confused.

To install bubblewrap on Ubuntu 18.04 or later just do
sudo apt-get install bubblewrap
If you have an older Ubuntu distribution or a distribution that doesn't package this program, then follow the instructions on the bubblewrap page to install it.
Of course, you can opt out of using bubblewrap, this is actually what the message is telling you. Just say, y for yes and it will continue without bubble-wrapping anything. For example, if you're building in a docker container, you don't need an extra layer of containerization that is provided by bubblewrap so you can drop it off.
also I thought this would mean I don't need to do that:
opam init --disable-sandboxing
...
Yes, once you install opam the binary, and if you opted out of using bubblewrap you need to initialize opam with this option (opam installation roughly consists of two steps, first you download and install the binary, next you need to run opam init so that it configures itself in your system).

Related

How to install the lustre client on Ubuntu nodes?

I am trying to install the lustre clients on Unbuntu 20.04 nodes I have in GCP. Im using linux kernel version 5.15.0-1021-gcp.
I'm trying to install the client with the following code:
cd /home/apps/
mkdir lustre
git clone git://git.whamcloud.com/fs/lustre-release.git
cd lustre-release
git checkout 2.15.0
sh autogen.sh
./configure --prefix=/home/apps/lustre --disable-server --enable-client ## doesnt run! Fails at ./configures with error message "error: Run make config in /lib/modules/5.15.0-1021-gcp/build"
make debs
The configure step fails with an error about running make config in /lib/modules/5.15.0-1021-gcp/build. I tried running make config in /lib/modules/5.15.0-1021-gcp/build but was asked to input some values that I was unsure of.
I also tried downloading the deb package of the client software at
https://downloads.whamcloud.com/public/lustre/lustre-2.15.0/ubuntu2004/client/lustre-client-modules-5.4.0-96-generic_2.15.0-1_amd64.deb. However this is for the wrong linux kernel and I'm not sure what env variables need to be set for this package.
Anyone know how to install the client modules for lustre on Ubuntu?
You need to have the kernel sources or kernel-devel package that exactly match the kernel that you are installing on. This should also include the .config file that describes all of the options used when building your kernel.
Alternately, you could try a pre-built package, but it isn't clear if this will install on your kernel or not.
https://build.whamcloud.com/job/lustre-b2_15/40/arch=x86_64,build_type=client,distro=ubuntu2204,ib_stack=inkernel/

no such option --system for pip install

I'm attempting to deploy a very basic trading system to AWS using serverless (following along with this link), but I have a bit of a problem.
Prior to running the deployment command, I'm supposed to run
pip3 install -r requirements.txt -t . --system
but I am getting an error message saying 'no such option: --system'
Initially, I just tried to install the packages without the --system option, but I think that's causing the cron lamda(??) function to fail when I execute it manually through the serverless console because it's not finding the requisite modules.
I'm assuming it's because they aren't being installed properly so my question is how then should I install them so this doesn't happen?
Running
pip3 install -r requirements.txt
alone (while in the trading system directory) does not suffice.
So, what should I do?
The original author was working on an older Debian-derived system, you aren't. You can safely omit this option if it's not supported.
I don't have an authoritative link available, although this came up in a Google search. But here's my summary:
With older Debian-derived systems (eg, Ubuntu 18.04), the --user flag was enabled by default and it overrode the -t flag, so all packages would be installed in the $HOME/.local. The --system flag was nominally intended to allow installation in the system package directory, but in practice it was needed to enable -t.
This is fixed for Debian-derived systems that default to Python 3 (eg, Ubuntu 20.04).
It was never an issue for non-Debian systems (eg, EC2 Linux).
Since you don't seem to be familiar with pip, the -r argument tells it to use a file containing dependencies, and the -t argument tells it to install those dependencies in the current directory (not a great habit, but I don't want to describe virtual environments).

rpm glibc Centos 7

How can I install both of them on CentOS 7? They both depend on each other. The machine is not connected to the internet.
[efe#localhost Desktop]$ sudo rpm -i glibc-2.17-317.el7.x86_64.rpm
warning: glibc-2.17-317.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
error: Failed dependencies:
glibc-common = 2.17-317.el7 is needed by glibc-2.17-317.el7.x86_64
[efe#localhost Desktop]$ sudo rpm -i glibc-common-2.17-317.el7.x86_64.rpm
warning: glibc-common-2.17-317.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
error: Failed dependencies:
glibc = 2.17-317.el7 is needed by glibc-common-2.17-317.el7.x86_64
EDIT1: I have installed 2.17-292 for everything on x86_64 and it is successful. However, for i686 (yes, I need both unfortunately) I have tried to combine all packages into single command, lots of other dependencies appeared. I have tried to install 2.17-292 like I did for x86_64, this is the final output with errors. Before this last command, dependency errors appeared all the time, this is the first different error.
[efe#localhost packages]$ sudo rpm -i glibc-2.17-292.el7.i686.rpm glibc-common-2.17-292.el7.i686.rpm glibc-headers-2.17-292.el7.i686.rpm glibc-devel-2.17-292.el7.i686.rpm nss-softokn-freebl-3.44.0-8.el7_7.i686.rpm nspr-4.25.0-2.el7_9.i686.rpm nss-util-3.53.1-1.el7_9.i686.rpm libselinux-2.5-15.el7.i686.rpm libsepol-2.5-10.el7.i686.rpm pcre-8.32-17.el7.i686.rpm libgcc-4.8.5-44.el7.i686.rpm libstdc++-4.8.5-44.el7.i686.rpm
warning: glibc-2.17-292.el7.i686.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
file /usr/bin/ldd from install of glibc-common-2.17-292.el7.i686 conflicts with file from package glibc-common-2.17-292.el7.x86_64
file /usr/lib/locale/locale-archive.tmpl from install of glibc-common-2.17-292.el7.i686 conflicts with file from package glibc-common-2.17-292.el7.x86_64
file /usr/share/gcc-4.8.2/python/libstdcxx/v6/printers.pyc from install of libstdc++-4.8.5-44.el7.i686 conflicts with file from package libstdc++-4.8.5-36.el7.x86_64
file /usr/share/gcc-4.8.2/python/libstdcxx/v6/printers.pyo from install of libstdc++-4.8.5-44.el7.i686 conflicts with file from package libstdc++-4.8.5-36.el7.x86_64
EDIT2: I have entered a command as suggested by Florian Weimer.
[efe#localhost i686]$ sudo yum update *.rpm
Loaded plugins: fastestmirror, langpacks
Examining glibc-2.17-292.el7.i686.rpm: glibc-2.17-292.el7.i686
Package glibc.i686 not installed, cannot update it. Run yum install to install it instead.
Examining glibc-common-2.17-292.el7.i686.rpm: glibc-common-2.17-292.el7.i686
Package glibc-common.i686 not installed, cannot update it. Run yum install to install it instead.
Examining glibc-devel-2.17-292.el7.i686.rpm: glibc-devel-2.17-292.el7.i686
Package glibc-devel.i686 not installed, cannot update it. Run yum install to install it instead.
Examining glibc-headers-2.17-292.el7.i686.rpm: glibc-headers-2.17-292.el7.i686
Package glibc-headers.i686 not installed, cannot update it. Run yum install to install it instead.
Examining libgcc-4.8.5-44.el7.i686.rpm: libgcc-4.8.5-44.el7.i686
Marking libgcc-4.8.5-44.el7.i686.rpm as an update to libgcc-4.8.5-36.el7.x86_64
Examining libselinux-2.5-15.el7.i686.rpm: libselinux-2.5-15.el7.i686
Marking libselinux-2.5-15.el7.i686.rpm as an update to libselinux-2.5-14.1.el7.x86_64
Examining libsepol-2.5-10.el7.i686.rpm: libsepol-2.5-10.el7.i686
Package libsepol.i686 not installed, cannot update it. Run yum install to install it instead.
Examining libstdc++-4.8.5-44.el7.i686.rpm: libstdc++-4.8.5-44.el7.i686
Marking libstdc++-4.8.5-44.el7.i686.rpm as an update to libstdc++-4.8.5-36.el7.x86_64
Examining nspr-4.25.0-2.el7_9.i686.rpm: nspr-4.25.0-2.el7_9.i686
Marking nspr-4.25.0-2.el7_9.i686.rpm as an update to nspr-4.19.0-1.el7_5.x86_64
Examining nss-softokn-freebl-3.44.0-8.el7_7.i686.rpm: nss-softokn-freebl-3.44.0-8.el7_7.i686
Marking nss-softokn-freebl-3.44.0-8.el7_7.i686.rpm as an update to nss-softokn-freebl-3.36.0-5.el7_5.x86_64
Examining nss-util-3.53.1-1.el7_9.i686.rpm: nss-util-3.53.1-1.el7_9.i686
Marking nss-util-3.53.1-1.el7_9.i686.rpm as an update to nss-util-3.36.0-1.el7_5.x86_64
Examining pcre-8.32-17.el7.i686.rpm: pcre-8.32-17.el7.i686
Package pcre.i686 not installed, cannot update it. Run yum install to install it instead.
Resolving Dependencies
--> Running transaction check
---> Package libgcc.x86_64 0:4.8.5-36.el7 will be updated
--> Processing Dependency: libgcc(x86-64) for package: redhat-lsb-core-4.1-27.el7.centos.1.x86_64
Loading mirror speeds from cached hostfile
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
subscription-manager repos --disable=<repoid>
5. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: base/7/x86_64
You can upgrade all the packages at the same time, using a command like this one:
sudo rpm -U glibc-2.17-317.el7.x86_64.rpm glibc-common-2.17-317.el7.x86_64.rpm
Or you can use yum update, like this:
sudo yum update --disablerepo="*" *.rpm
This has the advantage that packages not installed are not automatically installed by the upgrade (unless dependencies require it). --disablerepo="*" ensures that yum update does not try to download anything.
jlehtone in forums.centos.org solved my situation. I just needed to write
sudo rpm -i glibc-2.17-292.el7.i686.rpm nss-softokn-freebl-3.44.0-8.el7_7.i686.rpm nspr-4.25.0-2.el7_9.i686.rpm nss-util-3.53.1-1.el7_9.i686.rpm
Link to forums.centos.org

Why is desired version of libboost-all-dev not found when building Docker container?

I'm trying to build a basic Docker container based on a tutorial. I am on Windows 10 Home version 2004, and I am using the standard command line. I've created the following Docker file to facilitate this, with the only change from the tutorial's version being my older version of gcc:
FROM gcc:6.3.0
RUN apt-get -qq update
RUN apt-get -qq upgrade
RUN apt-get -qq install cmake
RUN apt-get install libboost-all-dev=1.62.0.1
RUN apt-get -qq install build-essential libtcmalloc-minimal4 && \
ln -s /usr/lib/libtcmalloc_minimal.so.4 /usr/lib/libtcmalloc_minimal.so
Once the script gets to the step where it tries to install libboost-all-dev I get the following output:
Reading package lists...
Building dependency tree...
Reading state information...
E: Version '1.62.0.1' for 'libboost-all-dev' was not found
The command '/bin/sh -c apt-get install libboost-all-dev=1.62.0.1' returned a non-zero code: 100
and the build stops.
I've tried updating the build script to use the current version of Boost (1.74.0) as well and get the same issue. I'm not really finding any solutions in my research online and the output is not very helpful in trying to figure out what the issue is. Could anyone with more experience with installing Boost as part of the Docker process point me in the right direction?
The package manager will only be able to install versions of Boost that it knows exist, based on the enabled package manager repositories. There is typically only one version of Boost in the default repositories. In my experience, this applies to any Linux OS that supplies Boost, not only those that are run within a Docker container.
The Docker image you started with, gcc:6.3.0, appears to have only Boost version 1.55.0.2, so requesting any other version will yield the same error.
If you want a different version of Boost in your image, you can follow the typical steps for installing a different version of Boost outside a Docker container. These steps are well-documented on Stack Overflow, or you might find a repository such as this to enable in your package manager to directly install it from apt-get.

How about manage system dependencies when using azk?

I'm using azk and my system depends on extra packages. I'd be able to install them using (since I'm using an Ubuntu-based image):
apt-get -yq update && apt-get install -y libqtwebkit-dev qt4-qmake
Can I add this steps to provision? In the Azkfile.js, it would look like:
// ...
provision: [
"apt-get -yq update",
"apt-get install -y libqtwebkit-dev qt4-qmake",
"bundle install --path /azk/bundler",
"bundle exec rake db:create",
"bundle exec rake db:migrate",
]
Or it's better to create a new Docker image?
Provision steps are run in a separated container, so all the data generated inside of it is lost after the provision step, unless you persist them. That's why you probably have bundle folders as persistent folders.
Since that, you should use a Dockerfile in this case. It'll look like this:
FROM azukiapp/ruby:2.2.2 # or the image you were using previously
RUN apt-get -yq update && \
apt-get install -y libqtwebkit-dev qt4-qmake && \
apt-get clean -qq && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* # Keeping the image as small as possible
After that, you should edit your Azkfile.js and replace the image property of your main system to use the created Dockerfile (you can check azk docs here):
image: { dockerfile: './PATH_TO_DOCKERFILE' },
Finally, when you run azk start, azk will build this Dockerfile and use it with all your dependencies installed.
Tip: If you want to force azk to rebuild your Dockerfile, just pass -B flag to azk start.
As it looks like you're using a Debian-based Linux distribution, you could create (https://wiki.debian.org/Packaging) your own Debian virtual package (https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-virtual) that lists all the packages it depends on. If you just do that one thing, you can dpkg -i (or apt-get install if you host a custom debian repository yourself) your custom package and it will install all the dependencies you need via apt.
You can then move on to learning about postinst and prerm scripts in Debian packages (https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-maintscripts). This will allow you to run commands like bundle and gem as the last step of the package installation and the first step of package removal.
There are a few advantages to doing it this way:
1. If you host a package repository somewhere you can use a pull method of dependency installation in a dynamic scaling environment by simply having the host apt-get update && apt-get install custom-dependencies-diego
2. Versioning your dependency list - Using dpkg -l you can tell what version everything is on a given host, including the version of your dependency virtual package.
3. With prerm scripts, you can ensure that removing your virtual package will also have the effect of removing the changes your installation scripts made so you can get a host back to a "clean" state".
The disadvantage of doing it this way is that it's debian/apt specific. If you wanted to deploy to Slack or RHEL you'd have to change things a bit. Changing to a new distro wouldn't be particularly hard, but it's definitely not as portable as using Bash, for example.