I'm new to python and it was recommended that I use Canopy. I'm trying to follow along with this tutorial, but I get stuck at the mahotas.imread line. I get an error saying that ends with this:
Full error was: mahotas.freeimage: could not find libFreeImage in any
of the following directories:
'/Users/RJD/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/mahotas',
'/lib', '/usr/lib', '/usr/local/lib', '/opt/local/lib'
I've added the mahotas package via the package manager to no avail. Also tried the steps here, with no different result.
I am actually able to find 'freeimage.py' and 'freeimage.pyc' in '/Users/RJD/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/mahotas'. How do I go about telling Canopy that it is there?!
Any help would be very much appreciated.
Cheers,
R
Author of mahotas here:
Mahotas itself does not have the functionality to read in images. imread is just a wrapper around one of 3 backends:
mahotas-imread (i.e., https://pypi.python.org/pypi/imread)
FreeImage (this was the original version and if you have such an old version [0.7.1 is from Jan '12], it might still only support FreeImage)
matplotlib (which only supports PNG & JPEG)
Thus, you need to install one of the packages above.
To be clear, there is no "enthought mahotas". Mahotas is not in the Enthought package repository but in our "Community" (PyPi mirror) repo of 11,000 untested ("as is") packages, as you can see by the "PyPI" logo in the Package Manager (sorry, that's not at all obvious, we'll fix this!) We will be updating this repo later this year. The version of mahotas in that PyPI repo is 0.7.1, whereas the current version of mahotas on PyPI is 1.0.2. So that avenue is not useful for now.
When you say that you tried the steps in the cmu.edu document, was that after uninstalling the old PyPI version just mentioned and going through each step mentioned in that document?
Related
I am very new to embedded Linux and am working with buildroot. We have a DNP3 library that is very old and would like to upgrade from 2.3 to 3.1. I do not know where to even start.
Can someone point me to a tutorial or instructions on how to upgrade an existing library or package?
It's not explained explicitly in the Buildroot manual, but updating a package is:
finding the package directory (e.g. package/dnp3);
change the version number in the dnp3.mk file;
download the package with make dnp3-source;
this will give an error because of a missing hash: note the hash and update it in dnp3.hash.
Of course, often that is not enough because the updated package has new dependencies, or it has to be patched to be able to build it in cross-compilation, or various other issues.
I am trying to build some source code on ubuntu 16.04 where one of the classes relies hierarchy_simplify_point_set.h header file, which is part of CGAL's point set package. After following instruction on the installation page, I have installed libcgal-dev and libcgal-qt5-dev via apt-get. The package manager has installed libcgal-dev 4.7 which should include the point set library. However, the particular header file seems to be missing (it seems to have some files from the point set library and not others - I am looking in /usr/include/CGAL). Does anyone know what I am doing wrong?
ps: For good measure, I have already tried uninstalling and reinstalling both the packages, but no luck.
This header has been introduced in CGAL 4.8 while it seems you are using CGAL 4.7.
You can get the latest version of CGAL here. Since the latest versions can be used as a header-only library, simply extract the release archive somewhere and set CGAL_DIR to that location when calling cmake to configure your example and it should work directly.
How do I get the source code for the wiringPi library now that Gordon has pulled git.drogon.net?
I would like to pull the source using git but other options are possible.
Just pull it from https://github.com/WiringPi/WiringPi.
It seems to be an unofficial fork of the original repo by Gordon.
Just do:
git clone https://github.com/WiringPi/WiringPi.git
Or just install it using apt-get on raspian:
sudo apt-get install wiringpi
I don't believe there is any reason to build the source yourself if you are not actively developing the wiringPi library. Also if you really need a backup of the library:
sudo apt-get download wiringpi
This will download .deb for the raspberrypi and allows you to save it till perpetuity.
Downloading wiringpi will result in a .deb package. You can use any archive manager such as 7Zip, Ark and WinRar to open that file and open the data.tar.xz which contains all files you need to link against the library. Such as libwiringPi.so in the lib directory and all the .h files in the include directory needed.
Or download it from launchpad.net, under the Package information header there is an option to find the latest upload, this being 2.50-0ubuntu1 at the time of writing. This allows you to download the complete source by downloading wiringpi_2.50.orig.tar.gz`
Or here on packages.ubuntu.com (this one is for groovy but principle still stands). Just download the source package on the right hand side of the site.
And for the love of god stop bothering Gordon, the guy got burned out by the
community and bothering him about a downed repo is not really helping him getting better.
As far as I know the official copy of wiringPi is unavailable. When Gordon announced on Aug. 6th that he was no longer supporting wiringPi, he said he would continue to make the final release available (http://wiringpi.com/wiringpi-deprecated).
However, the download server is not responding: When you go to the download page (http://wiringpi.com/download-and-install/), it links to a server (git.drogon.net) that responds only
"git.drogon.net is temporarily unavailable. Please look for alternatives for wiringPi, etc. -Gordon"
I wrote to Gordon about this, but he hasn't replied yet. Since one of the reasons he said he quit offering wiringPi was because of too many emails from the community, I'm not holding my breath waiting for an answer.
This is why I said you can't get an official download. Gordon's announcement claimed that unofficial forks of the code can be found on github, but I haven't found any.
It may be that your best bet is to find someone who downloaded the official version before August, and would be willing to give you a copy of the tarball.
I have a package I just updated to use setuptools_scm and found the version number is wrong in readthedocs.
http://sshuttle.readthedocs.org/en/v0.77/ shows:
Version: 0.78.dev0+ng083293e.d20160304
however as version 083293e has the 0.77 tag, the version string should be just 0.77
It looks like readthedocs might be making changes to my source code before building.
I have looked at the readthedocs build logs, and it seems to have the correct version at one stage (0.77), however this is before it builds the documentation.
Processing dependencies for sshuttle==0.77
Finished processing dependencies for sshuttle==0.77
The build logs don't mention the version while building the documentation.
Is it possible to solve this?
Thanks
I see that you're building this project.
Clearly, something is mutating the repository state before the version is determined. You can replicate similar behavior by mutating one of the files prior to building the docs yourself:
(sshuttle) $ python setup.py --version
0.77
(sshuttle) $ cat >> setup.py
# a comment
(sshuttle) $ python setup.py --version
0.78.dev0+ng083293e.d20160403
In the read the docs docs, there's a description of the process.
There, you can see the steps RTD does, namely, (a) run setup.py install then (b) install requirements in requirements.txt.
I've confirmed that neither of those steps should be mutating the repo state.
What it doesn't explain, however, is where that 'version' comes from, or what update_imported_docs does. I suspect the issue lies in something subtle that read the docs is doing that modifies the repo.
Here's one place where the conf.py file gets modified.
Perhaps adding docs/conf.py to your .gitignore will allow those changes to be ignored and thus not dirty your working state when calculating the project version.
https://github.com/pypa/setuptools_scm/issues/84 has been updated to record this
we will be working with the sphinx team to provide a automated/painless version of this process
The documentation for setuptools_scm now has instructions on how to use with readthedocs:
It is discouraged to use setuptools_scm from sphinx itself, instead
use pkg_resources after editable/real installation:
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])
The underlying reason is, that
services like readthedocs sometimes change the workingdirectory for
good reasons and using the installed metadata prevents using needless
volatile data there.
This avoids the need to use kluges as per the other answer.
I'm unfortunately not very experienced in CentOS administration, and was hoping someone might be able to help me understand and get past a small hurdle. I was hoping to run yum update on the system, but ran into some Transaction Check Errors:
file /etc/php.ini from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/curl.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/fileinfo.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/phar.so from install of php55-common-5.5.11-1.el6.x86_64 conflicts with file from package php-common-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/pdo.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/pdo_sqlite.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
file /usr/lib64/php/modules/sqlite3.so from install of php55-pdo-5.5.11-1.el6.x86_64 conflicts with file from package php-pdo-5.3.3-40.el6_6.x86_64
It sort of looks like it's saying that some newer version files are conflicting with older version files. Is there a standard way to fix this? I was mainly just trying to update so that I could install Java later, but wasn't expecting to run into these errors. If it helps, the server is mainly being used for hosting a few websites with apache and mysql. Thanks so much for any help, it's greatly appreciated.
Edit: To add some more clarification, I had previously edited the baseurl variable in the /etc/yum.repos.d/centalt.repo file, which was originally set to
baseurl=centos.alt.ru/repository/centos/6/$basearch
The reason I changed the location was because I was previously getting an error when trying to run yum update, mentioned in this other stackoverflow question https://unix.stackexchange.com/questions/132674/repository-metadata-repomd-xml-for-repository-mratwork-centalt which had an answer recommending replacing the URL with
baseurl=mirror.sysadminguide.net/centalt/repository/centos/6/$basearch
Is there a different url I should be using instead?
You have a non-official repository which provides the php55-* packages which conflict with the official php-* packages.
You currently have the php-* versions installed.
If you want to switch you can try manually installing the matching php55-* package for every php-* package you have installed in one yum command (though that may not work).
If it doesn't, you might need to remove all the php packages you have installed first and then install the php55 versions after that.