I had successfully installed frama-c-Silicon using opam by the instructions, but when I want to upgrade to Phosphorus, opam does not work.
I used the command:
opam pin add frama-c Downloads/frama-c-Phosphorus20170501.tar.gz
it said that:
[NOTE] Package frama-c is already path-pinned to
/home/talos/Downloads/frama-c-Phosphorus-20170501.tar.gz.
This will erase any previous custom definition.
Proceed ? [Y/n] y
[frama-c] /home/talos/Downloads/frama-c-Phosphorus-20170501.tar.gz synchronized
frama-c needs to be installed.
The following actions will be performed:
∗ install frama-c-base 20161101* [required by frama-c]
Why3 can be used by the WP plug-in for running additional automatic solvers
Coq can be used with the WP plug-in for proving interactively proof obligations
∗ install frama-c 20161101*
Alt-Ergo Graphical Interface can be used by the WP plug-in
===== ∗ 2 =====
Do you want to continue ? [Y/n] y
=-=- Gathering sources =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[frama-c.20161101] /home/talos/Downloads/frama-c-Phosphorus-20170501.tar.gz already up-to-date
[frama-c-base.20161101] /home/talos/Downloads/frama-c-Phosphorus-20170501.tar.gz already up-to-date
=-=- Processing actions -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#=== ERROR while installing frama-c-base.20161101 =============================#
These patches didn't apply at /home/talos/.opam/system/build/frama-c-base.20161101:
- 4.05-support.patch
=-=- Error report -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The following actions were aborted
∗ install frama-c 20161101
The following actions failed
∗ install frama-c-base 20161101
No changes have been performed
[NOTE] Pinning command successful, but your installed packages may be out of
sync.
I think your problem is related more to the usage of OPAM itself (opam pin in particular) than Frama-C.
This line in particular indicates that you have pinned a Frama-C package in your OPAM installation:
[NOTE] Package frama-c is already path-pinned to
/home/talos/Downloads/frama-c-Phosphorus-20170501.tar.gz.
This will erase any previous custom definition.
This was only necessary before the Phosphorus package was available in OPAM. You should revert to a default configuration by removing it and then installing it via the "standard" (non-pinned) way:
opam pin remove frama-c
# just in case, you may want to unpin the frama-c-base package, if it is pinned
opam pin remove frama-c-base
# then install the package normally; you may need to update OPAM to make
# sure the package is available in your repository
opam update
opam install frama-c
Note that, if you still have a message displayed such as:
The following actions will be performed:
∗ install frama-c-base 20161101* [required by frama-c]
That might indicate an issue with OPAM's constraints.
The version number of the Phosphorus release is 20170501. Anything other than that means you won't get Phosphorus, but an older version. It is not worth continuing: the issue must be fixed beforehand.
Related
On Ubuntu in a Conda environment with Python 3.7.3, when I run
conda install -c conda-forge opencv
I get OpenCV 3.4.2 (checked with import cv2 and then cv2._version__) even though https://anaconda.org/conda-forge/opencv indicates version 4.11. Why?
Note that I didn't have OpenCV installed previously (I ran conda uninstall opencv and it got completely removed)
tl;dr You likely have previously installed dependencies that need updating. If you require a specific version, say 4.1, then express this to Conda:
conda install -c conda-forge opencv=4.1
Explanation
How Conda Interprets Specifications
A literal translation of the command
conda install -c conda-forge opencv
would go something like
With the conda-forge channel included, ensure that some version of the package opencv is installed in the currently active environment.
The logic here implies that any version it can install would be a valid solution. It also doesn't tell it that it must come from Conda Forge, only that that channel should be included.1
Two-Stage Solve Strategy
Starting with v4.7, Conda uses a two-stage dependency solving strategy. The two stages are
Solve with an implicit --freeze-installed|--no-update-deps flag. This attempts to find the newest version of the requested package that has no conflicts with installed packages. That is, it considers any installation of the package, no matter the version, to be a satisfactory solution. If it works, then it's done. Otherwise, move on to...
An unrestricted solve (what used to be default in Conda < 4.7). This frees up dependencies to be updated and will often result in the latest versions being installed unless there are previous explicit specifications on those packages.2
This strategy aims to provide a faster solve and install experience, by avoiding having to change anything in your environment. It also helps keep the environment stable by avoiding unnecessary version changes.
Specific Failure in Question
What happened in OP's case? One of the dependencies requirements of OpenCV was likely newer in v4.1.1 than what was already installed, but that dependency's version was compatible with installing OpenCV 3.4.2. Hence, the only thing that would change was adding opencv plus missing dependencies. Technically, this is a valid solution since one only asked for some version of opencv to be installed.
Getting the Latest Version
Option: Specifying the Version
If you know you want a specific version then you can always specify it
conda install -c conda-forge opencv=4.1.1
and since Conda can't install this without updating something in your env, the first round of solve will fail, and the full solve will get it for you.
Option: Skip the Freeze
Of course, you may not always know what the latest version number is and don't want to have to look this up on Anaconda Cloud every time. Fortunately, there is the --update-deps flag that essentially skips over the first solve stage and goes straight to the full solve. This will install the latest version for your system, as well as update any of the dependencies.
conda install --update-deps -c conda-forge opencv
Important Note: The --update-deps flag has a side-effect of converting dependencies to explicit specifications. While this is an internal environment state (managed through <env>/conda-meta/history), it does have some behavioral consequences (bugs!):
the result of the conda env export --from-history command will subsequently include all packages, instead of just the ones the user explicitly requested in the past
conda remove will not be able to prune dependencies; e.g., if scipy was installed, it would pull in numpy; if only scipy depended on numpy and scipy was removed, normally numpy would also get removed. This wouldn't work after using the --update-deps flag.
[1]: The behavior here depends on the channel_priority configuration option. With the strict setting, conda-forge would be prioritized over other channels; with the flexible setting, it is simply added to the list and the latest compatible version from any channel is selected.
[2]: One can check the explicit specifications of an environment with conda env export --from-history.
I'm trying to use install snowflake-connector-python to a Cloud Composer environment but keep receiving an error that pops up in the UI, "Failed to install PyPI Packages. Check the Cloud Build log for details". The build log doesn't seem overly helpful and is very long, so I'll just show some of the notable things here.
This is a warning that shows after installing snowflake-connector-python and its dependencies.
Installing collected packages: pycryptodomex, asn1crypto, oscrypto, jmespath, botocore, s3transfer, boto3, isodate, msrest, azure-core, azure-storage-blob, azure-common, snowflake-connector-python
Successfully installed asn1crypto-1.4.0 azure-common-1.1.25 azure-core-1.8.1 azure-storage-blob-12.5.0 boto3-1.14.63 botocore-1.17.63 isodate-0.6.0 jmespath-0.10.0 msrest-0.6.19 oscrypto-1.2.1 pycryptodomex-3.9.8 s3transfer-0.3.3 snowflake-connector-python-2.3.2
+ [[ -z fail ]]
+ python3 -m pipdeptree --warn fail
Warning!!! Possibly conflicting dependencies found:
* botocore==1.17.63
- docutils [required: >=0.10,<0.16, installed: 0.16]
This is the final error notification.
The command '/bin/sh -c bash installer.sh $COMPOSER_PYTHON_VERSION fail' returned a non-zero code: 1
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/docker" failed: step exited with non-zero status: 1
I'm running the image composer-1.12.1-airflow-1.10.10 in zone us-central1-c and is using python 3. I've tried installing different versions of the package with no luck, and have tried doing it via the UI and via gcloud. Any help as to the root of this problem would be much appreciated!
I tried trying to install older versions of snowflake-connector-python but that didn't work.
What did end up working was adding docutils==0.15 to the list of packages to install. This fixed the dependency conflict warning and led to a successful build.
Previously, I've received dependency conflict warnings that led to successful builds. But for this case, I actually needed to resolve that conflict.
The answer from nate did not work for me, the PyPi package install succeeds in CloudBuild but then the Web Server fails to update and rolls back installing the packages.
In order to get this working we had to downgrade our Composer to the September release which comes with docutils==0.15.2.
The image we used was composer-1.12.1-airflow-1.10.9, it seems that any image in airflow 1.10.10 or above has this issue as they come with docutils==0.16 as standard. You can see which version of docutils is in an image by using this link and expanding the PyPi packages column.
I use travis to check my R package, it's based on a virtual machine of ubuntu. One of my dependencies is rgdal from CRAN, which cannot be installed correctly on travis.
First it said:
ERROR: dependencies ‘rgdal’ is not available for package ‘my package’
I followed the instruction here, then comes the endless dependencies, I installed one by one, according to the instruction of every trial. Finally I installed packages is as below：
libproj-dev
libcurl4-gnutls-dev
libdap-dev
libgdal-dev
libgdal1h
libhdf5-dev
libhdf5-serial-dev
libgdal-dev
libgdal1-dev
It said I still need to install libhdf5-7 = 1.8.11-3ubuntu1~precise1~ppa1
But when I install package libhdf5-7 = 1.8.11-3ubuntu1~precise1~ppa1, it gives another error:
E: Unable to locate package
E: Unable to locate package 1.8.11-3ubuntu1~precise1~ppa1
E: Couldn't find any package by regex '1.8.11-3ubuntu1~precise1~ppa1'
And it seems no more solutions now.
I wonder how to fix this on travis? Is it a common issue on only travis virtual machine or it could happen on any ubuntu machine? Or the package rgdal has some problems with ubuntu?`
Background:
All my installation above used apt-packages of travis, which is explained as below by travis:
apt_packages: A list of packages to install via apt-get. Common examples here include entries in SystemRequirements. This option is ignored on non-linux builds
As of this week, you can opt into using Ubuntu 14.04 on Travis:
See this blog post from Travis for details
See this .travis.yml where I enable Trusty aka 14.04
Switching to 14.04 may be enough in this case. If not, also note that you can prepare your own .deb packages. I mention this in an blog post from this summer.
As the geospatial packages are a little involved that is probably your best. You would need to know how to build Debian packages, and how to use Launchpad to have them auto-built for you. Both topics have lots of tutorials.
I am installing a custom debian package on debian 6 machine.
This is my control file
Package: [[name]]
Version: 5.1
Section: hello/world
Priority: Optional
Architecture: all
Essential: no
Depends: my-dependent-package (>> 0.2.1)
Installed-Size: 1000
Maintainer: Test test#test.com
Description: _DESCRIPTION_
Here the my-dependent-package doesnt get auto upgraded when newer versions are released.
i always do sudo apt-get update before installing.
installing the debian from an internal mirror and using
sudo apt-get install mypackage
the dependent package "my-dependent-package" is also available in the same internal mirror.
the internal mirrors are defined in /etc/apt/sources.list
both the packages come from same mirror
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
my-package : Depends: my-dependent-package (>> 0.2.1) but it is not going to be installed
E: Broken packages
Installation succeeds when I manually install the "my-dependent-package". I was expecting it to be auto installed by the "my-package" as I have mentioned it in control file.
How can I enable it ?
Debian assigns priorities to suites and packages.
Most likely your local repository has a low priority, which results in being excluded from automatic updates.
Configure apt to assign a higher priority to your repository, so it get's automatically selected.
See the AptPreferences documentation for more information.
(It's really impossible to give you a walkthrough without more knowledge on your actual setup)
I have tried to run the Frama-C on windows 7, but it didn't work.
I have read all the tips and comments you wrote here, but still not working.
Can someone explain the installation process is a clear and simple way, and I will grateful?
The easiest install for Windows 7 is to use the Windows binary installer for the Boron release (http://frama-c.com/download/frama-c-Boron-20100401.exe). If you do install this version, you will still need to install the gcc-preprocessor in order for frama-c to build your source code.
Newer releases (i.e., Sodium) require you to build from the source code distribution, which means you will need to install several prerequisites as listed in the install instructions:
GNU make version >= 3.81
Objective Caml >= 3.12.1 (except 4.02.0);
a C compiler with standard C and POSIX headers and libraries
The Frama-C GUI also requires:
Gtk (>= 2.4)
GtkSourceView 2.x
GnomeCanvas 2.x
LablGtk >= 2.14.0 (and >= 2.18.2 if you use OCaml >= 4.02.1)
If you need to build from source, please comment and I will give you the steps to complete that.
fdopen's OCaml for Windows allows installing OPAM with a special repository.
Once you have it, installing Frama-C requires only a few steps:
# install depext, for external dependencies
opam install depext
# help Cygwin installing dependencies
opam install depext-cygwinports
# install Frama-C dependencies
opam depext frama-c
# install Frama-C itself
opam install frama-c
Frama-C on Windows installation instructions are periodically updated on Frama-C's wiki.