Grep not actually reproducible on Arch but do we have a bigger issue?

[Pol Dellaiera]

Hi,


I think this is very similar to what happened in `NixOS/nixpkgs` with 
grub2: https://github.com/NixOS/nixpkgs/issues/245356

In that case, it was reported as unreproducible because localisation 
resources were coming from a nondeterministic translation source 
(network server). The fix by Arnout was to make those resources 
deterministic by taking only the localisations from the release tarball 
instead: https://github.com/NixOS/nixpkgs/pull/316655

The issue was definitely an issue, but it was gracefully fixed once the 
non-deterministic input path was identified.


Best regards

-- 
Pol Dellaiera

On 2026.05.02 01:15, cen wrote:
> On 02/05/2026 00:35, kpcyrd wrote:
>> repro-threshold only acts as a rebuilderd client, if you configure "I 
>> want two parties to confirm they could reproduce the build server 
>> output from the alleged source code", and two if the rebuilders you've 
>> configured as trusted could indeed reproduce the binaries immediately 
>> after they've been released, repro-threshold would accept the package 
>> as valid - unless there's a collusion, the security guarantees still 
>> hold.
>>
>> The package eventually becoming unreproducible is "only" a problem if 
>> you later want to prove this to an auditor (or yourself), but can't. 
> 
> That seems correct, I was wrongly thinking about a scenario where A and 
> B agree on a package but then the package would be rebuilt upstream 3 
> months later for some reason and become non-reproducible.  But in 
> reality that never happens because upstream never rebuilds the same 
> exact thing, there is a version bump involved.
> 
> 
>> I did this manually in the past using the *-repro-status[0][1] 
>> tools. :) Right now you need to run the tool multiple times, there's 
>> no flag (yet) to query multiple at the same time and compare results.
>>
>> [0]: https://github.com/archlinux/arch-repro-status
>> [1]: https://github.com/kpcyrd/debian-repro-status 
> 
>   Right, so some kind of a daily scheduler that basically does the same 
> thing and flags the differences. Then I can add a nice shiny badge to 
> each package either saying "This package has been confirmed by N 
> different rebuilders" or one that says "Rebuilders disagree about this 
> package" or something like that and that's a giant red flag to 
> investigate it.
> 
> It makes more sense to do it periodically and not live because the 
> agreement can change over time.
> 
> 
> As always, thank you for comprehensive response.
> 
> Best regards
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260502/2cf0fa0e/attachment.sig>