Bugzilla – Bug 1112159
hawk2 rpms differ between builds
Last modified: 2020-09-19 09:08:17 UTC
While working on reproducible builds for openSUSE, I found that hawk2 rpms differ between builds even when trying to build it as similar as possible, I get such diffs: /var/lib/hawk/tmp/cache/assets/sprockets/v3.0/zi/ziNohlQ6aKL19UhK8SNna2ec3gzWMjn6i19aLaSMWbI.cache differs at offset '2973' (data) @@ -1,3 +1,3 @@ 00000b80 33 32 34 39 32 33 64 38 37 64 31 33 64 62 06 3b |324923d87d13db.;| -00000b90 06 46 3a 0a 6d 74 69 6d 65 6c 2b 07 da cb c2 5b |.F:.mtimel+....[| +00000b90 06 46 3a 0a 6d 74 69 6d 65 6c 2b 07 2c cc c2 5b |.F:.mtimel+.,..[| from embedded mtime values (likely of files updated during build) Additionally, there are files renamed or missing. All under the subdir of /var/lib/hawk/tmp/cache/assets/sprockets/v3.0/ Some of these files are identified as "zlib compressed data" so uncompressing could give further insight. These files are created by running in the /home/abuild/rpmbuild/BUILD/hawk2-2.1.0+git.1536166588.e5ab7e32/hawk/ dir: bin/rake assets:precompile The only other package, that has sprocket-related indeterminism is velum, but there it looks different.
*** Bug 1112158 has been marked as a duplicate of this bug. ***
ping. still as bad in current Factory.
I wonder if maybe we could just delete that sprockets cache file from the package and it would work fine anyway.
OK, so deleting the sprockets cache would suck as it would slow down the UI quite a bit. But maybe what we could do is set the mtime on all of the javascript assets manually before the sprockets cache is built, so that it's always the same. At least if that's the problem then things should work. Bernhard, what's the method you use to get those diffs, do you have a script or tool which makes that simple to do? Just so I could try a fix and see if it helped.
The recursive-diff tool is https://github.com/openSUSE/build-compare/blob/master/pkg-diff.sh and there is also "diffoscope" available in openSUSE. I doubt that adjusting mtimes alone will suffice. How about creating the cache in a %post script on the target system?