Help with Mroonga to finally get all of MariaDB Server reproducible

[Vagrant Cascadian]

On 2021-07-23, Chris Lamb wrote:
> Otto, thank you for your enthusiasm towards getting this package
> reproducible. It's clear from re-reading the issue on the GitHub issue
> for Mroonga how much you want to solve this.
...
>> Pretty sure this is the zeroed-out build path length getting embedded
>> (e.g. /build/path/1 vs. /build/path/1/2 have a different number of
>> characters).
>
> Interesting theory. So to test that, I built the version using
> differing build paths of the *same* length, and there was
> unfortunately still a diff between the ha_mroonga.so files. However,
> the 'amount' of differences were significantly reduced compared to the
> version currently on tests.reproducible-builds.org. Here is what I
> got:
>
>   https://people.debian.org/~lamby/EiquoKi5.html

Ah, perhaps it is not zeroed out after all... :/


> Focusing on the varying-length zeroed-out build path for a moment: I'd
> dearly love diffoscope to be able to display that clearly. The current
> output does not communicate that effectively, assuming that is the
> problem.

Maybe zeroed-out is a bit overly specific or even a red herring... or
there are more complexities to the issue...


> That that end, Vagrant do you have a more info for exactly what tool
> is doing this? Any GCC (??) documentation that you can reference? And
> perhaps a tool or utility that can show precisely this? I'd like to at
> least get a reliable testcase that we can incorporate into diffoscope.

I don't have a good suggestion for diffoscope, really.

It is unfortunately difficult as the compiler flag -ffile-prefix-map
strips out the human-readable bits. Sometimes I've disabled it just to
be able to see where the build paths are embedded, but that obviously
does not help diffoscope much.


>> Once your package with the timestamp patches applied migrates to
>> "testing" where we don't test build paths, it should be reproducible.
>
> (Just to clarify that the timestamp patches are in the experimental
> branch and not the version of the package in unstable. They therefore
> will not automatically migrate.)

I did think about the complexities of explaining this particular nuance
and decided to leave it as a bit of an excersize for the reader... :)


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20210723/0ba13822/attachment.sig>