On Thu, 2025-11-20 at 19:40 +0800, Changqing Li via lists.openembedded.org wrote: > From: Changqing Li <[email protected]> > > Here is SRC_URI of jquery: > SRC_URI = "\ > https://code.jquery.com/${BP}.js;name=js;subdir=${BP} \ > https://code.jquery.com/${BP}.min.js;name=min;subdir=${BP} \ > https://code.jquery.com/${BP}.min.map;name=map;subdir=${BP} \ > " > When ${BP}.js/${BP}.min.js/${BP}.min.map are downloaded in a git repo, > and this git repo is cloned locally as a PREMIRRORS. In this case, mtime > of these files will be current time when checking out. For this recipe, > source_date_epoch will get by function > get_source_date_epoch_from_youngest_file, mtime of > ${BP}.js/${BP}.min.js/${BP}.min.map are not stable, so cause the > generated package not reproducible. > > A new variable FIXED_SOURCE_DATE_EPOCH is added to support this case. > By default, FIXED_SOURCE_DATE_EPOCH is 0, and source_date_epoch works > as before. If user build in above case, FIXED_SOURCE_DATE_EPOCH set to 1 > in recipe jquery can ensure fixed source date epoch used by this recipe > to support reproducible build. > > Signed-off-by: Changqing Li <[email protected]> > --- > meta/conf/bitbake.conf | 1 + > meta/lib/oe/reproducible.py | 13 ++++++++----- > 2 files changed, 9 insertions(+), 5 deletions(-)
We need to take a step back here and think about what is going on. The current design is that mtimes of files are clamped at an upper value which is determined by the the logic you're changing. There is an assumption that the mtimes don't affect the build, the build process will create files and therefore we will always have to have some kind of ignore threshold as the creation times of built components will vary. As you've pointed out, git can under some circumstances mean that files don't have the correct mtime ordering which causes components to rebuild, particularly around flex/bison. We need to find those cases and ensure the right mtime ordering as you've done in some patches. What I don't think is reasonable is changing the git fetcher to try and have stable mtimes, or adding new variables without a really strong explanation of why the existing code can't work. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#226616): https://lists.openembedded.org/g/openembedded-core/message/226616 Mute This Topic: https://lists.openembedded.org/mt/116389229/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
