Hi Drew, * Drew Parsons <[email protected]> [2026-07-31 15:45]:
Source: eccodes Version: 2.48.0-1 Severity: normaleccodes upstream has seen fit to make the library build date a part of their API via codes_get_build_date() The build date is set via src/eccodes/grib_api_version.cc.in https://github.com/ecmwf/eccodes/blob/develop/src/eccodes/grib_api_version.cc.in see also https://github.com/ecmwf/eccodes/blob/f923a68eb9ce626db79f54bfe118865c8d688977/src/eccodes/eccodes.h#L1257 https://github.com/ecmwf/eccodes/blob/f923a68eb9ce626db79f54bfe118865c8d688977/src/eccodes/eccodes_prototypes.h#L758 https://github.com/ecmwf/eccodes/blob/f923a68eb9ce626db79f54bfe118865c8d688977/tools/codes_info.cc#L59 https://github.com/ecmwf/eccodes/blob/f923a68eb9ce626db79f54bfe118865c8d688977/tests/unit_tests.cc#L79 Debian now has an enforced policy of reproducible builds, which is deliberately violated by eccodes through this codes_get_build_date() So we have a problem. What is the best way to resolve it? Hard code the "build date" to the tag release date? Or to the original first eccodes date, Mar 25, 2013? Or ask the release team for an exception to the reproducible builds policy?
Should be fixed by #1143169 or do I miss something? Cheers Jochen
signature.asc
Description: PGP signature
