quick announcement: we finally have statically linked builds of micromamba on Windows as well. And thanks to @isuruf we fixed a bug on linux-ppc64le. Now micromamba works fine on all platforms, and it's quite fast (e.g. check out this run on Windows: https://github.com/mamba-org/mamba/runs/1127789467 : 5s to set up micromamba, 9 secs for xtensor and repodata caching, 12 secs to install Python 3.7...)
For issues like what @nehaljwani mentioned, I need a way to make the correct python be first in PATH.
Hi team! A collaborator is asking some details about the compiler stack CF uses, and I have tried my best to explain the versions pinned in
conda-forge-pinning-feedstock and the glibc stuff. However, I am being asked if the conda compilers are compatible with a specific CentOS devtoolset version or not? This would be for Linux x64. Thanks!
Apparently any would work:
We're currently using devtoolset-3 on CentOS 7, but that doesn't seem to be available anymore. devtoolset-7-gcc is gcc 7.3.1, devtoolset-8-gcc is gcc 8.3.1, and devtoolset-9-gcc is gcc 9.1.1. All of those are layered on top of system version of gcc (4.8.5), so the ABI is still gcc 4.8.5.
Note that the libstdc++ library shipped in the
libstdcxx-ng package support both ABIs.
Over in the kubelogin-feedstock I'm seeing the below errors in the Windows CI:
Failed to upload due to [WinError 5] Access is denied: 'C:\\Users\\VSSADM~1\\AppData\\Local\\Temp\\tmp3j_7k78n\\binstar.token'. Trying again in 10 seconds
Using STAGING_BINSTAR_TOKEN for anaconda.org uploads to cf-staging.
This happens in a loop until the CI times out
:point_up_2: has anyone seen that before?
I'll give that a go...
@dhirschfeld, it's a harmless error. I don't know the reason for it, but the line https://github.com/conda-forge/conda-forge-ci-setup-feedstock/blob/5131da196ec424c74c0c02159bf64014cf1fd99f/recipe/conda_forge_ci_setup/upload_or_check_non_existence.py#L56 sometimes fails. PRs welcome to catch that error
Trying to delete stuff on Windows is a nightmare! :grimacing:
My next issue is that
target_goexe doesn't seem to be defined
I thought that was something defined by
conda-forge - is that not the case?
@dhirschfeld, conda-smithy takes all the values from the global conda-forge
conda_build_config.yaml and strips them down to only the values used so that the .ci_support/ are readable and relevant. For this it uses conda-build's find_used_variable function which looks at bld.bat, but doesn't look at build.sh on windows. Add a echo %target_goexe% in bld.bat and rerender
zipping all the
go related variables in https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml should fix this automatically though
ignore that last part. no, it wouldn't
that should be fixed in conda-smithy
PureOS is based on Debian and so far works just as well :)
@isuruf - I opened conda-forge/conda-forge-ci-setup-feedstock#122 to work around the Windows permission error
thanks @ocefpaf