How do I install Mendeley to use Anaconda python - anaconda

I've freshly installed Ubuntu 18.04 and have decided to try Anaconda. However, when I then try to install Mendeley, I get the following error:
mendeleydesktop depends on python; however:
Package python is not installed.
I assume the issue here is that python is now in ~\anaconda2\bin, instead of \usr\bin. I'm not certain what I should do. As I see it, I have 3 options:
Install a system python into \usr\bin, but this seems sloppy/messy
Put a softlink in \usr\bin along the lines of ln -s python ~\anaconda2\bin\python, but I'm worried that there might be implications to that, which I don't understand
Somehow tell the mendeley.deb file where the python I'm using is, but I don't know how to do this.
Are either 1 or 2 reasonable options? If not how do I implement my 3rd option, or what else should I do?
Empirically found option 2 does not work. dpkg is still looking for the installation of the python package

You can use the method given here to remove the system python dependency in the .deb file; I tried this and mendeley seems to install as normal. Assuming your conda environment is set up correctly, it will work. I had to modify the instructions on that page slightly:
Unpack deb: $ ar x mendeleydesktop_1.19.4-stable_amd64.deb (will create i.e. three files: debian-binary control.tar.gz data.tar.gz)
Unpack control archive: $ tar xzf control.tar.gz (will create: postinst control)
Fix dependencies in control (use a text editor)
Repack control.tar.gz: $ tar c postinst control | gzip -c > control.tar.gz
Repack deb: $ ar rcs mendeleydesktop_1.19.4-stable_amd64_nopythondep.deb debian-binary control.tar.gz data.tar.gz (order important! dpkg wouldn't be able to read the metadata of a package quickly if it had to search for where the data section ended!)

Related

Building Linux perf from source: how to modify the install directory?

I am following this wiki page to build perf from source as below:
PYTHON=python3 make -C tools/perf install
where ~/bin will be the default build directory.
How can I change the build directory to let's say ~/bin/test? I already have another perf build in ~/bin, and I want to have the new build in a different directory.
I have tried to modify the Makefile (if that is how to do it), but I could not figure it out.
One last silly question: Can I just move my current perf build to another directory or it will screw up its links?
You should be able to easily install into a different directory by specifying prefix=... or DESTDIR=... when running make. You will see this and other info if you run make -C tools/perf help:
$ make -C tools/perf help
...
Perf install targets:
NOTE: documentation build requires asciidoc, xmlto packages to be installed
HINT: use "prefix" or "DESTDIR" to install to a particular
path like "make prefix=/usr/local install install-doc"
install - install compiled binaries
...
Make sure to pass an absolute path to avoid problems (you can use realpath for that):
PYTHON=python3 make -C tools/perf prefix=$(realpath ~/bin/test) install

list all downloaded packages - repotrack / rpm

I am downloading packages using repotrack, doing something like this -
repotrack -a x86_64 -p $PACKAGE_LOCATION/Packages $pckg
where it gets $pckg from a text file. Now I want to verify signatures of all packages (and dependencies) before installing.
rpm --checksig <package_name>
Here I need package_name of all packages and dependencies downloaded. One way to do this will be ls over $PACKAGE_LOCATION/Packages location. But I am using bash script and looping over ls content is fragile. Other mechanism I thought of trying is using rpm -qa but this queries all installed (and not downloaded) packages.
Is there anything I can do to get list of all downloaded packages.
Hope if you are looking for what package you have installed that use below command.
rpm -qa | grep packagename
As well as you can use rpm --help to get more flags info.
hope it will help...!!!

Advice on using unless requisite in a salt state file

As part of a salt state file I am installing nghttp2.
So far I have the following code in my .sls
install_nghttp2:
cmd.run:
- name: |
cd /tmp
wget https://github.com/nghttp2/nghttp2/releases/download/v1.16.0/nghttp2-1.16.0.tar.gz
tar -xf nghttp2-1.16.0.tar.gz
cd ./nghttp2-1.16.0
./configure
make
make install
- shell: /bin/bash
- require:
- pkg: install_nghttp2_deps
- unless: test -x /tmp/nghttp2-1.16.0
I'm a little wary of the - unless requisite and was wondering if anyone had a better way to check nghttp2 hasn't already been installed? I'd rather do something to check it hasn't been installed rather than just check whether it's been downloaded - unless (pun intended...kinda) anyone has a better suggestion?
Since you compile specific version and you do not install it with package manager, I think you are doing it right.
Maybe better option to check if the program is installed would be to use different command in unless requisite.
For example you can use nghttpd --version or with full path, where the binary is stored /usr/sbin/nghttpd --version.
Other good option is to use which nghttpd.

GNU Octave: Build a package from a directory instead of a tarball

I currently developing an interface for a library as a GNU Octave package. Normally packages in GNU Octave are installed via
pkg install tarball_of_the_package.tar.gz
But compressing the package for each test is more or less time consuming. Now my question is if it is possible to call somehow the pkg install mechanism from a directory which has a valid package structure like in the tarball? Running
pkg install .
from inside this directory yields an error:
unpack: FILETYPE must be "gunzip" for a directory
Even specifying the whole path as
pkg install /path/to/the/package/source
results in the same problem.
At the moment I am using GNU Octave 4.0.0 for my developments.
What most packages have is a Makefile at the root of the package with targets such as install that will handle that for you. See for example the Makefile for the statistics package which allow you to do:
$ hg clone http://hg.code.sf.net/p/octave/statistics
destination directory: statistics
requesting all changes
adding changesets
adding manifests
adding file changes
added 401 changesets with 996 changes to 172 files
updating to branch default
133 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd statistics/
$ make install
Creating package version 1.2.4 release ...
rm -rf "statistics-1.2.4"
hg archive --exclude ".hg*" --exclude "Makefile" --type files "statistics-1.2.4"
chmod -R a+rX,u+w,go-w "statistics-1.2.4"
tar cf - --posix "statistics-1.2.4" | gzip -9n > "statistics-1.2.4.tar.gz"
Installing package locally ...
octave --silent --eval 'pkg ("install", "statistics-1.2.4.tar.gz")'
For information about changes from previous versions of the statistics package, run 'news statistics'.
And of course, there's nothing stopping you from calling make install from the Octave session itself. The statistics package example is nicer because it only has m files. If your package also has code to be compiled, the image package has a more complex, but not by much, Makefile for that.

What files did `make install` copy, and where?

Is there a way to get a list of filenames/paths that make install copies to the filesystem? Some packages come with a MANIFEST file, but not the ones that I am working with.
I was just investigating this myself while compiling a custom version of QEMU. I used the following method to work out what was installed and where (as well as using it as a basis for a .deb file):
mkdir /tmp/installer
./configure --target-list=i386-softmmu
make
sudo make install DESTDIR=/tmp/installer
cd /tmp/installer
tree .
Tree is a utility that recursively displays the contents of a directory in a visually appealing manner - sudo apt-get install tree for Debian / Ubuntu users
Hope that helps someone... it took me a bit of poking around to nut it out, but I found it quite a useful way of visualising what was going on.
The most fool-proof way is to use chroot: have "make install" run inside a chroot jail; compute a list of the files that you had before the installation, and compare that to the list of files after the installation.
Many installations will support either a --prefix configuration option, and/or a DESTDIR environment variable. You can use those for a lighter-wait version of chroot (trusting that the installation will fail if it tries to write to a location outside these if you run installation as a fairly unprivileged user).
Another approach is to replace the install program. Many packages support an INSTALL environment variable that, well, is the install program to use; there are tracing versions of install around.
make uninstall might show the files as it removes them if the author of the compiling instructions provides the information to allow an uninstall (it has been awhile since I have done one so I can't say for sure).
Also make -n install will do a "dry run" of the install process and it may be reasonable to extract the information from its results.
It differs for every project that you run 'make install' on. The files which are installed are controlled by the install target in the Makefile being used. Your best bet is to open the Makefile and search for 'install:' - from there you can see what files will be copied out to your system.
Take a snapshot of the contents of the install location before installing
Install
Compare the current contents with the old contents.
Example:
./configure --prefix /usr/local
make -j`nproc`
find /usr/local | sort -u > /tmp/snapshot1
make install
find /usr/local | sort -u > /tmp/snapshot2
comm -3 /tmp/snapshot{1,2} # this prints the files added by `make install` to stdout
If the install program you're using doesn't support DESTDIR or --prefix (or an equivalent), I have found that it may be possible to identify new files as follows:
Start with as clean a system as possible (a fresh VM image is preferable)
Compile the software, wait a few minutes.
Install the software package.
Find files modified within the past 5 minutes: sudo find / -mmin -5 -type f (the find command has a ton of parameters for querying based on file modification / creation times, but this worked pretty well for me; you just need to narrow the time span so that you pick up the files created by the installer but nothing else).

Resources