#1143190 reproducibility: codes_get_build_date() returns library build date

Package:
src:eccodes
Source:
src:eccodes
Submitter:
Drew Parsons
Date:
2026-08-02 07:23:02 UTC
Severity:
normal
#1143190#5
Date:
2026-07-31 13:45:20 UTC
From:
To:
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?
#1143190#12
Date:
2026-07-31 13:58:55 UTC
From:
To:
Hi Drew,

* Drew Parsons <dparsons@debian.org> [2026-07-31 15:45]:

Should be fixed by #1143169 or do I miss something?

Cheers Jochen
#1143190#17
Date:
2026-07-31 14:53:35 UTC
From:
To:
* Drew Parsons <dparsons@emerall.com> [2026-07-31 16:12]:

Can you explain why? #1143169 explicitly says that Alastair will request
a binNMU of eccodes which will make it reproducible (according to my
tests) which will allow it to migrate.

I expect eccodes to migrate in 2-3 days, is there any urgency to do it
earlier? In that case we can ask the release team for a migration hint.
#1143190#22
Date:
2026-07-31 14:12:03 UTC
From:
To:
No, 1143169 does not address this bug directly.
The tracker information,
https://tracker.debian.org/pkg/eccodes
shows eccodes  2.48.0-1 has not migrated, declaring
Reproducibility regression on amd64

1143162 is a null bug.  It's not reporting anything other than the
observation that the package hasn't migrated yet.

This issue is blocking cfgrib,
which blocks a long chain of reverse dependencies.
#1143190#27
Date:
2026-07-31 15:28:42 UTC
From:
To:
Ah I see what you mean.  I was referring to 1143162 in eccodes, and
missing the fine print in the digits.  You mean 1143169 in ecbuild.
If ecbuild fixes the problem in eccodes and allows cfgrib to pass tests,
then all will be fine.

There is no grand urgency, only the desire to get pymatgen migrated back
to testing, which is affected by this bug.
If it does migrate in 2-3 days then fine, but it's been 10 days so far,
which is why I thought eccodes had gotten blocked by reproducibility.
But sounds like it's fixed by the ecbuild update.
#1143190#32
Date:
2026-08-02 07:19:48 UTC
From:
To:
Package migrated