On 2023-01-03, Diederik de Haas wrote: > On 14 Apr 2022 15:45:26 -0700 Vagrant Cascadian <vagrant@reproducible- > builds.org> wrote: >> On 2021-08-08, Sebastian Ramacher wrote: >> > On 2021-03-13 20:05:47 -0800, Vagrant Cascadian wrote: >> >> Source: ffmpeg >> >> Severity: normal >> >> Tags: patch >> >> User: reproducible-builds@lists.alioth.debian.org >> >> >> >> The build path is embedded in various files generated with tools/cl2c: >> >> >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ >> >> diffoscope-results/ffmpeg.html > > FWIW, in https://salsa.debian.org/diederik/ffmpeg/-/pipelines/478274 I added > your patch, but the 'reprotest' job still failed. > I don't know how to read diffoscope's result (and currently don't have time to > learn it), but it looks like more is needed to make it reproducible. > Happy to add more patches to my branch and if 'reprotest' then succeeds, > you're free to add a "Tested-By: " tag with my name+email Looks like some new source of non-determinism was added in 5.0.x, you can see bookworm (which does not test build paths) was reproducible until 5.0.x started getting tested in bookworm in June of 2022: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/ffmpeg.html Fixing the build path issue mentioned in this patch may dramatically reduce the size of the diffoscope output from ~71MB to ~29KB ... so might be nice to apply still even if it does not fix all the reproducibility issues. I'll take another stab at it... >> >> The attached patch fixes this by patching tools/cl2c to use a basename >> >> in the generated file rather than the full path. >> > >> > As this patch touches upstream's build system, please submit it >> > upstream: >> >> Did so, haven't really heard anything back: >> >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/87sfwyotmg.fsf@yucca/ >> >> Any suggestions? > > I have no particular knowledge wrt ffmpeg-devel, but with the kernel patches > sometimes fall through the cracks and the best way is just to resend them. > > I did notice that the patch itself looks better then the email I saw on the > 'Forwarded' link. I _think_ that with 'git send-email' it would look cleaner. > > I would suggest to slightly reword the commit message so that it doesn't > contain "Without this patch". Maybe it's just me, but if the secondary commit > message starts with "To make builds reproducible ..." that would heighten my > interest in the patch. 'But' I really like the reproducible builds effort :-) > > And possibly update the reference to ffmpeg-4.3.2 to point to 5.1 or something. > And I'd replace "Originally submitted to Debian as:\n\n https://b.d.o/985187"; > with a "Link:" tag. Thanks for the suggestions! live well, vagrant
Attachment:
signature.asc
Description: PGP signature