Hello,
> The shift there is of 8 bits, which just so happen to be the extra > lenght of the second build (it has an extra '2/'). > > If it was embedding the path in many more places there would be many > extra shifts as well, there being only 8 bits is probably an indicator > that is saved only once, wherever that is. Hmm > > After the fix, the only diff we have is from "NT_GNU_BUILD_ID" and > > ".gnu_debuglink" which seems like a known issue[1] and I don't think > > there's anything I can do. > > Are you diffing also the dbgsym? From my experience, I'd say pretty > much all of those instanes are also cases where the build path is saved > somehow, even if later stripped. I wasn't, so here's the results: diff from the latest release's dbgsym (where the only diff on the regular package is the build id) has 493Mb If I apply the RPATH fix (CMAKE_BUILD_RPATH_USE_ORIGIN=ON), the dbgsym diff goes down to 38Kb https://salsa.debian.org/snippets/446 Though the output has "Too much input for diff" so with the information that I have there I can't spot the issue. So applying the RPATH fix reduces the diff by a considerable margin, but there's still something there in the debugsymbols. > > I just uploaded 3.4.3-2 with the fixes, so this means the diffoscope > > timeouts won't happen anymore for this package, though the issue will > > still be there and it might affect other packages. > > sigh, apparently it still timeouts :( Considering the diff of the dbgsym package has 493Mb, this could be the cause of the timeouts. Regards, -- Samuel Henrique <samueloph> _______________________________________________ Reproducible-builds mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
