openjdk team mailing list archive

[tony mancill <tmancill@xxxxxxxxxx>]

On Mon, Sep 21, 2020 at 10:01:35AM +0100, Julian Gilbey wrote:
> On Sun, Sep 20, 2020 at 09:59:22PM -0700, tony mancill wrote:
> > Hi Tiago, hi Julian,
> > [...]
> > Julian, I applied the patch and built the package successfully, but
> > jlink still fails with the "expected hash" error.  It's (perhaps)
> > interesting that the expected hash does differ between the patched build
> > and the unpatched build.
> 
> That's really bizarre.  I checked running strip-nondeterminism on the
> resulting jmods and it seemed to be OK.  But if so, then I've clearly
> overlooked something.

I'm wondering if we just need more of it sprinkled about earlier in the
build.  I didn't believe it at first and so rebuilt (more than once) to
be sure.

> > Disabling the invocation of 'dh_strip_nondeterminism -a' in
> > debian/rules *does* address the problem with jlink, either with or
> > without the jmod patch applied.  Also, I had to add strip-determinism to
> > the build-deps to build with the patch.
> 
> You should be able to make do with just adding -Xjmods to the
> dh_strip_nondeterminism invocation.  Removing it entirely also
> resolves this bug, but moves further away from the reproducible builds
> target.

Agreed.

> So I think there may be something weird going on in your build.  If
> you go into the build directory with the patch applied and
> dh_strip_nondeterminism -a still present, what is the result of
> running the following command after doing a build (perhaps with
> DEB_BUILD_OPTIONS=notest to save running the whole test suite)?
> 
> sha256sum `find . -name jdk.management.jfr.jmod`
> 
> You should find that all of the files found have identical SHA256
> sums.

Good suggestion - I will follow-up with this soon.
 
> And yes, I did say that you needed to add strip-determinism to the
> build-deps ;-)

Indeed you did.  :) 

> > Given that the package doesn't build reproducibly anyway, my inclination
> > is to make the change in debian/rules to address this long-standing bug.
> 
> Could we see if we can figure out why my patch is not working first?

For sure!  Thank you for the response.

Cheers,
tony