After making cabal install of the darcsden code I get this message:
cabal: The following packages are likely to be broken by the reinstalls:
bin-package-db-0.0.0.0
ghc-7.4.1
Use --force-reinstalls if you want to install anyway.
How do I get around this? What does it mean?
Why does it happen?
If you look at the full output of cabal install darcsden, you will find several lines that look like this:
binary-0.5.1.0 -bytestring-in-base (reinstall) changes: array-0.4.0.0 ->
0.3.0.3, containers-0.4.2.1 -> 0.4.1.0
This means that cabal has found an install plan that involves (destructively) reinstalling packages that you already have on your system.
Now, GHC packages are rather sensitive when it comes to their (reflexive) dependencies, and generally only work if exactly the right version of all dependencies is available, compiled against the right versions of their dependencies and so on. Therefore, replacing an already installed package with a new version of changed dependencies can cause some packages on your system to become unusable. Since version 0.14.0, cabal warns you about such a situation in advance to prevent you from accidentally breaking your system.
In your case, ghc and bin-package-db are among the potentially broken packages, because they depend on binary which gets reinstalled. So you should not try to use the --force-reinstalls flag, because it might really break your GHC.
What can you do?
If you scan what is going to be reinstalled, you see that quite a few dependencies are downgraded. This hints at the fact that the package you are trying to install might not be properly updated to GHC 7.4.1 yet.
You can in general try to call cabal install darcsden --avoid-reinstalls to explicitly try to find an install plan that has no reinstalls. Unfortunately, in this case, it fails (for me).
I've briefly looked at the darcsden package description, but it looks like quite a few dependencies of darcsden need to be updated. So the remaining options are: Convince the author(s) of darcsden to release an updated version, or install darcsden using an older version of GHC (such as 7.0.4), which should just work.
Related
I realize that a requirements.txt file can be used to pin the versions used in pip install. Sometimes I don't want to go through all that- and just simply want to protect my installation from downgrades. Is there any way to instruct pip install to do that?
An example: I just installed librosa and it downgraded numpy from 1.24.1 to 1.23.5 . I don't want that behavior to happen unless I explicitly request. On the other hand if there are missing dependencies then please let's grab them.
For this installation of python it is acceptable to take the risk of occasionally ending up with a mismatch due to installing newer versions [ but I don't want older ones].
Just got started with Nix (version 2.2.1), and while installing darcs (version 2.14.1) i encountered my first problem: I get the following error message (preceded by the callstack):
Setup: Encountered missing dependencies:
base >=4.9 && <4.12,
network >=2.6 && <2.8,
stm >=2.1 && <2.5,
zip-archive ==0.3.*
I have the haskell tool stack installed as well as a global ghc (though both should not be needed to build darcs i think).
I also had no problem with installing darcs with 'apt'
Am i making a classic nix beginner mistake or whats going on here?
Nix is very different from package managers like 'apt'. Derivations (which are like packages) are designed to be built in an isolated environment, where the derivation is responsible for providing its own dependencies by referencing other derivations. Because of this, you do not need to explicitly install anything in order to build a package.
Note also that although Nixpkgs uses the Cabal library to build Haskell packages, installing a package via Nix is quite different from installing with cabal-install. In fact it is closer to Stack, because Nixpkgs defines its haskellPackages based on stackage and it avoids cabal-style dependency resolution. It does however let you use the Cabal solver to check whether the dependencies match the versions specified in the cabal files. This check can be disabled using the doJailbreak function in Nixpkgs.
I don't think we need to get into the details of Haskell packaging in Nixpkgs though, because you should be able to get a pre-built darcs from the nixos-18.09 channel. The Nix expression from the nixos-unstable produces exactly your error message.
I recommend you to use the latest release channel, nixos-18.09, because nixos-unstable will break regularly. See the Nix manual for changing your channel configuration.
How would I install things on Pepper, since I don't know what package manager it uses. I usually use apt on my Ubuntu machine and want to install some packages on Pepper. I'm not sure what package manager Pepper has (if any) and want to install some packages, but also only know the name of the package using apt (not sure if the package name is the same on other package managers). And if possible, would I be able to install apt on Pepper. Thanks.
Note: From the research I've done, Pepper is using NaoQi which is based off Gentoo which uses portage.
You don't have root access on Pepper, which limits what you can install (and apt isn't on the robot anyway).
Some possibilities:
Include your content in Choregraphe projects - when you install a package, the whole directory structure is installed (more exactly, what's listed in the .pml); so you can put arbitrary files on your robot, and you can usually include whatever dependencies your code needs.
Install python packages with pip.
In NAOqi 2.5, a slightly older version of pip is installed that will not always work out of the box; I recommend upgrading it:
pip install --user --upgrade pip
... you can then use the upgraded pip to install other packages, using the upgraded pip, and always --user:
/home/nao/.local/bin/pip install --user whatever-package-you-need
Note however that if you do this and use your packages in your code running on Pepper, that code won't work on other robots until you do pip on them, which is why I usually only do this for tests; for production code I prefer packaging all dependencies in my app's package.
As a workaround if you need to install software (or just newer versions of software) using Gentoo Prefix is an option.
Gentoo Prefix builds a Gentoo OS on any location (no need of root, can be any folder). It includes it's own portage (package manager) to install new software.
I maintain a few projects to work with Pepper and use "any" software I want. Note that they are built for 64b (amd64) and 32b (x86) even though for Pepper only the 32b matter.
gentoo_prefix_ci and gentoo_prefix_ci_32b Which builds nightly the bootstrap of the Gentoo Prefix system. This is a process that takes a while to compile (3-6h depending on your machine) and that breaks from time to time (as upstream packages are updated and bugs are found, Gentoo is a rolling release distribution). Every night updated binary images ready to use can be found in the Releases section.
For ROS users that want to run it on the robot, based on the previous work, I maintain also ros_overlay_on_gentoo_prefix and ros_overlay_on_gentoo_prefix_32b. They provide nightly builds with binary releases of ROS Kinetic and ROS Melodic over Gentoo Prefix using ros-overlay. You can find ready-to-use 'ros_base' and 'desktop' releases.
For purposes related to the RoboCup#Home Social Standard Platform League where the Pepper robot is used I also maintain a specific build that contains a lot of additional software. This project is called pepper_os and it builds 270+ ROS packages, a lot of Python packages (250+ including Theano, dlib, Tensorflow, numpy...) and all the necessary dependencies for these to build (750+ packages). Note that the base image (it's built with Docker) is the actual Pepper 2.5.5.5 image, so it can be used for debugging as it if it was in the real robot (although without sensors and such).
Maybe this approach, or these projects, are useful.
The package manager on pepper is disabled. But you can copy the files to the robot and write your own service that imports any package you might need.
As a supplement on importing:
http://www.about-robots.com/how-to-import-python-files-in-your-pepper-apps.html
To get rid of error :
" SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
".
If you use python and requests package, just add verify=False at the end of your parameters.
r=requests.get(URL,params,header,verify=False)
Works with my Pepper
To get rid of
InsecurePlatformWarning: A true SSLContext object is not available.
install
/home/nao/.local/bin/pip install --user requests[security]
To get rid of:
CryptographyDeprecationWarning: Support for your Python version is deprecated.
install
/home/nao/.local/bin/pip install --user cryptography==2.2.2
If it based on Gentoo maybe we could try to install portage with pip.
pip install portage
Just a thought.
I am using Coq (versions 8.5-6), installed w/ Nix. I want to install ssreflect, preferably also w/ Nix. The only information I found about this is here. However, this is not about installing ssreflect, merely trying it out. Nevertheless, I tried to try it out, but ended up w/ hundreds of warnings (about the contents of various .v and .ml4 files) and couldn't wait for the process to end. A fairly typical warning looked like this:
File "./algebra/ssralg.v", line 856, characters 0-39: Warning:
Implicit Arguments is deprecated; use Arguments instead
So the question: How on earth do I install ssreflect w/ Nix?
EDIT: After reading ejgallego's comments, it seems it may be impossible to install ssreflect w/ Nix -- esp. if one wants install only ssreflect w/out the other modules (fingroup, algebra, etc.). So I've also the following question:
Would the standard Opam or make install installation of ssreflect work w/ a Nix-installed Coq?
There are a few things that you need to be aware of:
Nix is a source-based package manager with a binary cache. A lot of packages are pre-built and available in the binary cache, thus their installation doesn't take long; some packages (in particular development libraries) are not pre-built and Nix, when installing them will take the time it needs to compile them. Please be patient: you will only need to wait for the full compilation the first time (and yes, math-comp emits lots of warning upon compilation); next times, the package will be already available in your local Nix store.
Since OPAM is also source-based, using OPAM instead of Nix won't make you save time. You can't mixup Nix-installed Coq with OPAM installed SSReflect because the latter will want the former as an OPAM dependency.
The Nix way to use libraries is not to install them but to load them with nix-shell instead. nix-shell will "install" the libraries and set some environment variables for you (e.g. $COQPATH in this case).
You can also compile the package from source yourself using a Nix-installed Coq but you cannot run make install because this would try to install SSReflect at the same place where Coq is installed but the Nix store is non-mutable. Instead you could skip this step, and set up $COQPATH manually.
Indeed, the compilation of the full math-comp takes very long. There is a Coq ssreflect package which is lighter. You can get it using:
nix-shell -p coqPackages_8_6.ssreflect
If there a relatively simple way to make go + libxml2 + gokogiri work on windows?
I mean that I may be can install it (but at the moment I can not, stuck with Package libxml-2.0 was not found in the pkg-config search path), but then I need to provide my utilite to other people, who will never be able (or would wish ) to install lall libxml2 dependencies, modify PATH etc on windows...
It work flawless on Ubuntu...
I found this https://github.com/moovweb/gokogiri/issues/49 thats funny with installation of Gimp 2 (what?!), but I still cannot make it run with such error, I guess might be issue with PATH, but all PATH are set
$ go get github.com/moovweb/gokogiri
# github.com/moovweb/gokogiri/help
Documents\go\src\github.com\moovweb\gokogiri\help\help.go:6:25: fatal error: lib
xml/tree.h: No such file or directory
#include <libxml/tree.h>
^
compilation terminated.
# github.com/moovweb/gokogiri/xpath
Documents\go\src\github.com\moovweb\gokogiri\xpath\expression.go:4:26: fatal err
or: libxml/xpath.h: No such file or directory
#include <libxml/xpath.h>
^
compilation terminated.
You are struggling because it is hard to combine packages that were built by different people for different purposes and get your environment set up correctly. I think it is best to use MSYS2, an environment for Windows that provides a consistent set of packages for things like gcc, go, libxml2, and iconv. MSYS2 has a package manager (pacman) that helps you easily install them and keep them updated.
I don't do much programming with Go, but I am familiar with MSYS2 and it seems like I was able to get gokogiri installed using MSYS2. You should open MSYS2's "MinGW-w64 Win64 Shell" from the Start menu (mingw64_shell.bat), and try running these commands:
pacman -S mingw-w64-x86_64-{gcc,go,libxml2,iconv}
export GOROOT=/mingw64/
export GOPATH=/c/Users/David/Documents/goproj/
mkdir -p $GOPATH
go get github.com/moovweb/gokogiri
I think GOPATH should be set to the directory of your project. If you run into an error, it might be because some pacman package is required that I didn't list here.
The string mingw-w64-x86_64-{gcc,go,libxml2,iconv} gets expanded by Bash into the following list of packages:
mingw-w64-x86_64-gcc
mingw-w64-x86_64-go
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-iconv
If you are actually using 32-bit Windows, replace x86_64 with i686 in the instructions above.
If you are curious, the scripts for building those packages are here: https://github.com/Alexpux/MINGW-packages
As a disclaimer, I haven't actually compiled any go programs in MSYS2, so there could be big problems I am unaware of.
Also, one of the main developers of MSYS2 (alexpux) said this in the #msys2 IRC chat on 2015-06-21:
We not build go for a long time.
This package in very WIP state
Also see
https://github.com/Alexpux/MINGW-packages/issues/421
So you might need to fix some issues with the MSYS2 Go package and recompile it yourself to really make this work. But you have the PKGBUILD script that was used to build it, so maybe that will be less hard than what you are trying to do right now, which involves compiling/collecting every dependency of gokogiri.
MSYS2 would make your other installation of go, libxml2, and iconv obsolete. You can delete those things once you get your MSYS2 environment working.
If you are using visual studio and want to add dependency to your project then just install it using NuGet Package Manager it's easiest method.
Install command: Install-Package libxml2