Bug 15491 - libz-src is not reproducible
Summary: libz-src is not reproducible
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: High normal
Target Milestone: 5.2 M1
Assignee: Ross Burton
QA Contact:
URL:
Whiteboard: AB-INT
Depends on:
Blocks:
 
Reported: 2024-05-23 14:23 UTC by Alexandre Belloni
Modified: 2024-10-29 23:00 UTC (History)
8 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Randy MacLeod 2024-05-23 14:44:04 UTC
Likely a cache invalidation problem according to RP.
Not clear what to do about it.

Only seen in Alex's personal branches which don't have any libz  changes.
Zlib is not autoconf-based.

This may be to changes from gcc13 to gcc14.
Comment 2 Joshua Watt 2024-05-23 14:45:23 UTC
libz has it's own (non-autotools) configure script. You can see here where it changes the line in zconf.h: https://github.com/madler/zlib/blob/0f51fb4933fc9ce18199cb2554dacea8033e7fd3/configure#L580

I'm not sure why this simple compile test passes sometimes and doesn't other times
Comment 3 Ross Burton 2024-05-23 14:55:11 UTC
FWIW, with my current master my zconf.h has:

#ifdef HAVE_UNISTD_H    /* may be set to #if 1 by ./configure */
#  define Z_HAVE_UNISTD_H
#endif

#ifdef HAVE_STDARG_H    /* may be set to #if 1 by ./configure */
#  define Z_HAVE_STDARG_H
#endif
Comment 5 Randy MacLeod 2024-07-11 15:05:30 UTC
We may have changed something to fix this but no one on the YP bug review call could recall what the change may have been! ;-)
Comment 6 Randy MacLeod 2024-07-22 21:02:55 UTC
Not seen for two months and people suspect that the issue may have been fixed.
Re-open if seen again.
Comment 7 Mathieu Dubois-Briand 2024-10-16 08:56:24 UTC
Several failures on the reproducible autobuilder. Seems to happen quite often, but not on each build. Probably related to the switch to valkyrie.

AssertionError: The following rpm packages are different and not in exclusion list:
/srv/pokybuild/yocto-worker/reproducible/build/build-st/reproducibleB-extended/tmp/deploy/rpm/./core2_64/libz-src-1.3.1-r0.core2_64.rpm

https://valkyrie.yoctoproject.org/#/builders/37/builds/265
https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20241014-68a7dqot/packages/

https://valkyrie.yoctoproject.org/#/builders/37/builds/266
https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20241015-rnbypced/packages/

https://valkyrie.yoctoproject.org/#/builders/37/builds/274/steps/12/logs/stdio
https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20241016-gbk4py46/
Comment 9 Mathieu Dubois-Briand 2024-10-17 14:23:31 UTC
reproducible fedora39-vk-1
https://valkyrie.yoctoproject.org/#/builders/37/builds/281/steps/12/logs/stdio
Comment 10 Ross Burton 2024-10-17 14:55:51 UTC
So this is fun.

The change is zlib-src/usr/src/debug/zlib/zconf.h, which changes between the file in ${S} and the file in ${B}.  The problem is that do_package's sstate creation does a blanket utime() on the contents, but the source files are hardlinked from $S and $B.

This is bad, because we're stamping on timestamps in the source and build trees, which can cause problems with rebuilds.

The solution is to not utime() the files but ask tar to do the same when the archive is generated.
Comment 13 Mathieu Dubois-Briand 2024-10-23 08:45:00 UTC
reproducible rocky8-vk-1
https://valkyrie.yoctoproject.org/#/builders/37/builds/304/steps/13/logs/stdio
Comment 14 Richard Purdie 2024-10-29 23:00:39 UTC
Ross posted a good explanation of this here:

https://lists.openembedded.org/g/openembedded-core/message/206301

We ended up fixing this with:

https://git.yoctoproject.org/poky/commit/?id=a147293ed6d9c1387610f6cf9542ffa3aff50b61