Installing QDOAS 3.5 with latest Conda 2022.10 fails due to glibc dependency

QDOAS installations up to now worked like a charm, people just start qdoas and/or doas_cl out of the environment’s bin directory and everything runs well.

When the current Anaconda is taken (Anaconda3-2022.10-Linux-x86_64.sh),
installed fresh, a new environment is created, and, according to:
https://anaconda.org/stcorp-forge/qdoas
… qdoas is installed, it fails with a strange reason:

> ./anaconda3/bin/conda create --name stcorp
> ./anaconda3/bin/conda install -n stcorp -c stcorp-forge qdoas
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: - 
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.
failed                                                                                                                                                                                                                

UnsatisfiableError: The following specifications were found to be incompatible with your system:

  - feature:/linux-64::__glibc==2.31=0
  - qdoas -> __glibc[version='>=2.17,<3.0.a0']
  - qdoas -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']

Your installed version is: 2.31

So it seems to know the glibc version is 2.31, but apparently this is not considered newer than 2.17.
Maybe it’s confused by the “.a0” patchlevel for the “<3.0” version requirement?

After installing anaconda it asks to update conda from 22.9.0 to 23.1.0, but both produce the same error shown above.

Using Miniconda (what we prefer to use for an isolated qdoas install) shows the same results.

Installing Visan still works well (but that is coming via the conda-forge channel).

Thanks for any help!

Regards,
Walter Zimmer

We will at some point also move qdoas to conda-forge (as soon as we get the windows build working).

The current version of qdoas in the stcorp-forge channel is already using all its dependencies from conda-forge though. So the proper way to install qdoas in a conda environment at the moment is:

$ conda create -n qdoas
$ conda activate qdoas
$ conda install -c conda-forge -c stcorp-forge qdoas

Ok, good to know it makes a difference.

Tried it, on a different machine, with enabling the stcorp env first, but unfortunately same result:

<install of anaconda>
> conda init
<logging in again>
(base) > conda create -n stcorp
(base) > conda activate stcorp
(stcorp) > conda install -c stcorp-forge qdoas
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: - 
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.
failed                                                                                                                                                                                                                

UnsatisfiableError: The following specifications were found to be incompatible with your system:

  - feature:/linux-64::__glibc==2.31=0
  - qdoas -> __glibc[version='>=2.17,<3.0.a0']
  - qdoas -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']

Your installed version is: 2.31

Also applied the update of conda from 22.9.0 to 23.1.0, no change in results.
Is there any additional log I can provide?

Is there any other external dependency which could interfere?

I am not seeing you use -c conda-forge in addition to -c stcorp-forge. Note that you should not be using the default anaconda channel.
Maybe use miniforge or mambaforge if you would normally prefer miniconda over anaconda. That will automatically set conda-forge as the base channel.

Bingo - the missing specification of conda-forge was the problem!

Now I did:

./Anaconda3-2022.10-Linux-x86_64.sh 
../anaconda3/bin/conda create --name stcorp
../anaconda3/bin/conda install -c conda-forge -c stcorp-forge -n stcorp qdoas
../anaconda3/envs/stcorp/bin/qdoas 

… and got the latest qdoas.

While installing it also said for all packets that are coming from conda-forge, have to make this a habbit to look at this.

If I do the same with miniconda, it also works now. I noticed though that openssl is not coming from conda-forge, and the QDoas version is a slightly older one (3.4.5-0), which will probably be fixed anyway when the next step on your roadmap is implemented.

But we are happy with the anaconda install now, thanks for all the help (and your patience)!

Good that it works, but you shouldn’t be getting version 3.4.5.
The latest version that we published is 3.5.0. See also: Files :: Anaconda.org

Did you perform the miniconda based installation also in a separate environment? (you should not try to install qdoas in the conda base environment; not with anaconda and not with miniconda).

Yep, sorry, got greedy and did the miniconda test without own environment. Using it correctly provides QDoas 3.5.0, and all packages are coming from conda-forge. Will add this to my step-by-step mini-howto for the next time.

So now both really provide the same, with the miniconda install beeing considerable smaller than the anaconda one: 3G vs. 8G. And people can just call qdoas/doas_cl without activating the environment first, which makes it quite comfortable for them, thanks!