Build unreproducible on armhf

[PeterBBBBB]

It seems that on armhf the generated value of DUMA_MIN_ALIGNMENT in duma_config.h
can be 1 or 4, depending on the test system used. [edited]

See
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/armhf/diffoscope-results/duma.html

( No problems on amd64, 1386 or arm64)

[johnsonjh]

Thanks for the report. That's quite odd.

Are the test systems the same between each each run?

The alignment test is here, which should make it simpler to reproduce than compiling the whole package to track it down. I don't see anything that jumps out that would be causing this.

I can't promise a timeframe, but this is a good reason to get Debian/ARMHF running in QEMU for testing. I assume that a Raspberry Pi would also work well enough.

[PeterBBBBB]

It seems the builds intentionally use a different hardware node for each test build. For the build logs currently showing, results are

unstable 41 virt64a-armhf-rb cbxi4pro0-armhf-rb 4-1
bookworm 29 cbxi4pro0-armhf-rb virt64a-armhf-rb 1-4
bullseye 36 jtx1b-armhf-rb virt32c-armhf-rb 4-1

Nodes virt64a & jtx1b produce alignment 4
Nodes cbxi4pro0 & virt32c produce alignment 1

It seems to me that the architecture armhf includes hardware with different alignment requirements. I wondering whether hardwiring the value to 4 say, for armhf, would at least be a way to ensure consistent builds?

Cheers,
Peter

[johnsonjh]

Sorry again for the delay. I'm not sure why I wasn't receiving my e-mail notifications in a timely fashion.

Yes - setting the minimum alignment to 4 would be a safe workaround. Here is a good overview of the trade-offs of a larger alignment. RISC-V has some alignment oddities I haven't yet fully explored.

Using 4 should be a good way to go.