Release 0.8.1

[NikolaosPapailiou]

No description provided.

[jdblischak]

I don't think this is the problem, but just wanted to give the heads up that it looks like the image version isn't stable.

• The py310 build passed with 20240908.1.0
• The py39 build failed with 20240901.1.0
• The py311 build passed with 20240901.1.0
• The restarted py39 builds continue to fail with 20240901.1.0

Looking at the docs PR for Ubuntu 22.04 20240908 actions/runner-images#10574, the only relevant change I see is that Vcpkg was updated

[teo-tsirpanis]

Vector search does not use vcpkg (yet).

[NikolaosPapailiou]

I think this is related to a bug in pybind11 pybind/pybind11#5224

This proposes to add -Wno-array-bounds and -Wno-stringop-overread @jdblischak @dudoslav do you know what is the best way to pass these from the feedstock repo? We can also add it in the vector search cmake file but we might need to invalidate the already released pip version 0.8.1

[dudoslav]

Depending if we want to only add it to this feedstock, then I would suggest appending CXX_FLAGS and CC_FLAGS with these options. I am not sure about a best way to do it in meta.yaml, perhaps @jdblischak knows?

Otherwise if we want to have this in every build, even pypi builds we need to add it to CMakeLists as target_compile_options to the correct target. I am not sure if this is needed though. I can see that pypi wheels were produced correctly.

[jdblischak]

I think this is related to a bug in pybind11 pybind/pybind11#5224

I'm surprised this is only affecting the py39 build. The error seems related to GCC 12, and the py310 and py311 builds are also using GCC 12. Do we have any idea why this would be?

If it truly is a GCC 12 error, we can avoid this by rerendering the feedstock (conda smithy rerender --commit auto). The conda-forge pin for GCC has been migrated from 12 to 13

https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/0f5763cc337431d378201f4cf97c36d3b0696dc6/recipe/conda_build_config.yaml#L29

[NikolaosPapailiou]

This still fails both after passing the extra compiler flags and switching to GCC 13.

With GCC 13, I don't see the pybind warning, so this was not the problem.

From the logs, it seems that the worker dies unexpectedly during [ 99%] Building CXX object python/CMakeFiles/_tiledbvspy.dir/src/tiledb/vector_search/type_erased_module.cc.o

[NikolaosPapailiou]

I don't think this is the problem, but just wanted to give the heads up that it looks like the image version isn't stable.

• The py310 build passed with 20240908.1.0
• The py39 build failed with 20240901.1.0
• The py311 build passed with 20240901.1.0
• The restarted py39 builds continue to fail with 20240901.1.0

Looking at the docs PR for Ubuntu 22.04 20240908 actions/runner-images#10574, the only relevant change I see is that Vcpkg was updated

@jdblischak do you know if we can select another image for the py39 build?

Also could this be related to the docker image https://quay.io/repository/condaforge/linux-anvil-cos7-x86_64 we are using? This was updated 9 days ago

[jdblischak]

Also could this be related to the docker image https://quay.io/repository/condaforge/linux-anvil-cos7-x86_64 we are using? This was updated 9 days ago

That update from 9 days ago was from this PR conda-forge/docker-images#276

I don't see why that PR would cause only our py39 build to fail but not the others. The CUDA version was upgraded, but I don't think we are even using the CUDA-enabled images, so this should have no effect.

[jdblischak]

do you know if we can select another image for the py39 build?

I think we could specify the exact tag we want by defining docker_image in conda_build_config.yaml and then rerendering

[jdblischak]

I remembered the difference between the py39 build and the py310/py311 builds! The py39 build includes all the debug info (since it is deployed to TileDB Cloud), but py310/py311 are release builds (#50)

[NikolaosPapailiou]

I remembered the difference between the py39 build and the py310/py311 builds! The py39 build includes all the debug info (since it is deployed to TileDB Cloud), but py310/py311 are release builds (#50)

Thanks @jdblischak! Generating the debug symbols was what caused the problem. I will disable this for now and we will follow up in sc-55001 to try to re-enable the debug symbols build.