| 13 Nov 2025 |
 Grimmauld (any/all) | if vtk keeps building, i call the update worth | 11:27:09 |
| Grimmauld (any/all) | thats all i care about, though i guess the opencv people want opencv to work too | 11:27:23 |
 vcunat | Are you sure that the CVEs are serious? | 11:30:28 |
| vcunat | I mean, they seem to have been publicly open for months. | 11:30:39 |
| vcunat | And they're not even mentioned in the release announcement. | 11:30:48 |
| vcunat | So do we now need to patch them within days? | 11:31:08 |
 K900 | Well netcdf is immediately bork | 11:31:43 |
| K900 | configure: error: HDF5 was not built with zlib, which is required. Rebuild HDF5 with zlib | 11:31:53 |
| Grimmauld (any/all) | Its file (de-)serialization, it is potentially thinkable someone sends a specially crafted malicious cad file. I don't like having these vulnerabilities around. But there certainly are worse CVEs out there. | 11:32:38 |
| Grimmauld (any/all) | its all memory safety issues | 11:33:38 |
| vcunat | Alternate route is: lots of distros use hdf5 1.x. If it's serious, someone should have backports soon. | 11:34:16 |
| vcunat | (even if upstream didn't provide them now) | 11:34:30 |
| Grimmauld (any/all) | it probably is not that serious, other than all those 3d printing model bazaars you find | 11:34:48 |
| Grimmauld (any/all) | like, clearly some browser issue is worse, but i still don't like this | 11:35:31 |
| K900 | -DHDF5_ENABLE_ZLIB_SUPPORT=ON got that working | 11:36:09 |
| K900 | And then | 11:36:27 |
| K900 | > H5FDhttp.c:57:2: error: #error "Cannot determine version of H5FD_class_t"
┃ > 57 | #error "Cannot determine version of H5FD_class_t"
┃ > | ^~~~~
┃ > In file included from H5FDhttp.c:75:
┃ > H5FDhttp.c: In function 'H5Pset_fapl_http':
┃ > H5FDhttp.h:34:26: error: implicit declaration of function 'H5FDperform_init' [-Wimplicit-function-declaration]
┃ > 34 | #define H5FD_HTTP (H5FDperform_init(H5FD_http_init))
┃ > | ^~~~~~~~~~~~~~~~
| 11:36:30 |
| Grimmauld (any/all) | Amazing | 11:37:14 |
| K900 | OK yeah that's just gone from 2.0 | 11:39:02 |
| K900 | According to the changelog | 11:39:07 |
| K900 | I am out lol | 11:39:09 |
| vcunat | https://github.com/HDFGroup/hdf5/blob/develop/release_docs/CHANGELOG.md#%EF%B8%8F-breaking-changes | 11:42:46 |
| vcunat | * https://github.com/HDFGroup/hdf5/blob/hdf5_2_0_0/release_docs/CHANGELOG.md#%EF%B8%8F-breaking-changes | 11:43:43 |
 leona | I think most of the PRs to staging are merged now and trunk-combined will also be ready soon. So we can probably start tomorrow morning (CET side of the planet) with staging-next? | 23:16:29 |
 ivy | but cachix | 23:26:19 |
| leona | that might block trunk, but we don't have the time to wait for that to be fixed | 23:27:29 |
| leona | and also tbh if nobody of them cares so long for fixing it, I think about removing it as a blocker | 23:27:55 |
| leona | if we don't start staging-next within the next day, we probably won't have another cycle (I would need to talk with jopejoe1 about it), but we're already quite late right now. | 23:28:53 |
| 14 Nov 2025 |
 Fabián Heredia | Just as a consideration before staging-next begins this seems security related (out of bounds read is the only fix): https://github.com/NixOS/nixpkgs/pull/461446 | 05:27:52 |
 jopejoe1 (4094@39c3) | Yeah don't think we will be able to get another one in if don't start it today | 07:35:46 |
