Source: eccodes Version: 2.48.0-1 Severity: normal eccodes 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?
