CONDA_VERBOSITY=3
and explore the logs, but that's going to be time consuming
intel
and defaults
channels. Does intel have a special agreement with Anaconda or is the use of the defaults channel still subject to Anaconda repository Terms of Service ? (i.e no commercial of gvt use)
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
and AttributeError: module 'torch.jit' has no attribute 'unused'
this is the current repo conda-forge/staged-recipes#16916
meta.yaml
to show a new license and description for our package. However, on conda-forge, the license and description of our package are still in their outdated version, even though this meta.yaml
file on the feedstock contains the proper information. Does anyone know what is going on? Thanks in advance for your help!
The following specifications were found to be incompatible with your system:
- feature:/linux-64::__glibc==2.17=0
- feature:|@/linux-64::__glibc==2.17=0
- coverage -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- cython -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- h5py -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- mypy -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- numpy -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- opencv -> libgcc-ng[version='>=7.3.0'] -> __glibc[version='>=2.17']
- psutil -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- python=3.10 -> libgcc-ng[version='>=7.5.0'] -> __glibc[version='>=2.17']
- scikit-image -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- scikit-learn -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
- scipy -> libgfortran-ng -> __glibc[version='>=2.17']
- tensorflow -> __glibc[version='>=2.17']
- tensorflow -> cudatoolkit[version='>=11.2,<12'] -> __glibc[version='>=2.17,<3.0.a0']
- tifffile -> libgcc-ng[version='>=7.3.0'] -> __glibc[version='>=2.17']
- tk -> libgcc-ng[version='>=7.5.0'] -> __glibc[version='>=2.17']
Your installed version is: 2.17
scclin009(1):~/src/caiman_dev-clean$ rpm -qa glibc
glibc-2.17-324.el7_9.i686
glibc-2.17-324.el7_9.x86_64
I'm running into an issue where I cannot create a new environment with conda create ...
with an existing conda install (with a lot of other environments), but I can make the same environment with a completely fresh install of conda. Any idea what might cause this?
(I'm actually trying to help out a user with this problem; there may be some turnaround in poking around)
Can anybody help me understand how to read this solving config error?
Package cudnn conflicts for:
pytorch-lightning=1.4.5 -> pytorch[version='>=1.6'] -> cudnn[version='>=7.6,<8.0a0|>=7.6.5.32,<8.0a0|>=8.2.1.32,<9.0a0|>=8.1.0.77,<9.0a0']
pytorch::torchvision=0.10.0 -> pytorch==1.9.0 -> cudnn[version='>=7.6.5.32,<8.0a0|>=8.2.1.32,<9.0a0']The following specifications were found to be incompatible with your system:
- feature:/linux-64::__glibc==2.27=0
- nvidia::cudatoolkit=11.1.1 -> __glibc[version='>=2.17,<3.0.a0']
- pytorch-lightning=1.4.5 -> pytorch[version='>=1.6'] -> __glibc[version='>=2.17|>=2.17,<3.0.a0']
- pytorch::pytorch=1.9.0 -> cudatoolkit[version='>=11.1,<11.2'] -> __glibc[version='>=2.17,<3.0.a0']
- pytorch::torchvision=0.10.0 -> cudatoolkit[version='>=11.1,<11.2'] -> __glibc[version='>=2.17|>=2.17,<3.0.a0']
Your installed version is: 2.27
Why would __glibc==2.27
conflict with __glibc[version='>=2.17|>=2.17,<3.0.a0']
? What am I overlooking here?
Hi all,
I'm trying to build a package which includes h5py
. When using conda build
, it seems to install the wrong version of the dependency. It installs 3.2.1-py37h6c542dc_0
, which includes hdf5: 1.10.6-nompi_h6a2412b_1114
. The problem is that this hdf5
lib, seems to have these setting:(Read-Only) S3 VFD: yes
This causes an error for me. When just running conda install h5py==3.2.1
, it does install the right version.
/etc/profile.d
on Linux so that users can use that env directly. For command line tools, another solution I used is to create simple wrappers under /usr/local/bin. Users can launch a tool without knowing it's installed in a conda env.
conda update conda
(currently running 4.11.0) -- using --debug
the problem seems to be [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate
-- is this just me or is there some kind of server-side issue? If it is just me can someone suggest what I need to do to correct this?
time docker run --platform linux/amd64 --rm -v ${PWD}:/opt/conda-src -e TEST_SPLITS=3 -e TEST_GROUP=1 ghcr.io/conda/conda-ci:master-linux-python3.9 /opt/conda-src/dev/linux/unit.sh
needs 9:17.24time docker run --platform linux/arm64 --rm -v ${PWD}:/opt/conda-src -e TEST_SPLITS=3 -e TEST_GROUP=1 ghcr.io/conda/conda-ci:master-linux-python3.9 /opt/conda-src/dev/linux/unit.sh
needs 2:41.42 -> factor 3.4 faster :) - nothing provides openssl >=1.1.1,<1.1.2.0a0 needed by python-3.7.1-h0371630_3
python==3.8.*
(also tried it with a single =
in my yaml
file.yaml
file is responsible for this chain of events?conda install -c bioconda checkv
. Is there something I did wrong when I updated the recipe?