Getting condor builds reproducible

[Holger Levsen]

Hi Tim,

On Fri, May 22, 2026 at 04:44:21PM -0500, Tim Theisen wrote:
> Now that reproducible builds are mandatory, I am working on getting condor
> to meet those requirements.
> I am new to this and slightly confused.

this *is* new indeed, so don't worry.
 
> I recently got condor to build reproducibly, as you can see on Salsa:
>     https://salsa.debian.org/hpc-team/condor/-/pipelines

nice.
 
> And on the package info page, in the  testing migrations section, it shows
> that the amd64 build is reproducible.
>     https://tracker.debian.org/pkg/condor
> 
> However, on the reproducible results page, it shows the same version is not
> reproducible.
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/condor.html
> 
> So, why is there this disagreement? Is there one that is the authoritative
> answer?

because tracker.debian.org (since recently) doesn't show the results from
tests.reproducible-builds.org/debian anymore, but instead those from reproduce.debian.net.

to quote from r.d.n:

The goal of https://reproduce.debian.net is to replicate the same build
process that is used by Debian during package publication -- not to seek
out additional sources of variance.

Variance testing, used to find factors that can prevent packages from
rebuilding reproducibly, will continue at https://tests.reproducible-builds.org/debian/reproducible.html.


IOW, t.r-b.o does CI tests (which may fail), while what r.d.n. does
affects testing migrations.
 
 
> The disagreement seems to be with the NT_GNU_BUILD_ID. I thought that the
> default rules would take care of that with -ffile-prefix-map. One suggestion
> that I was was to link with build_id is sha1. I don't know if that is
> warranted.

difference in NT_GNU_BUILD_IT usually indicates a difference in the binary
which got stripped away by dh_strip.

> Also, once a package is reproducible on one platform, I would expect it to
> be reproducible on other platforms/CPU architectures.

I also expect this and usually this is the case, but basically there are
exceptions to everything and there are bugs and other things too.
 
> It claims that there was a regression in reproducibility on i386 it that is
> blocking promotion. None of the recent changes should caused this.
> 
> What kinds of issues cause a package to not build reproducibly on arm64,
> when it build reproducibly on the amd64 platform.
> 
> Any hints are appreciated.

I've had a brief look but sadly couldnt see anthing immediatly.

ATM you can still request the release team to ignore this issue and let it
migrate to testing anyway.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The difference between 2C and 3C? Civilisation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260523/9cfc4c75/attachment.sig>