Hi Vagrant, On 6/8/21 3:40 AM, Vagrant Cascadian wrote: > On 2021-06-08, Nilesh Patra wrote: >> I was trying to make "brian" package reproducible. To my understanding it >> has two problems: >> >> * use datetime.date.today() and similar stuff for build documentation - I >> suppose I fixed these with using SOURCE_DATE_EPOCH > > Your fixes look reasonable; just be sure the way you're passing the time > is independent of timezone (it might be fine as is).
Sure > >> * Only _some_ files in the documentation it vendors has stuff (like tags, >> examples, links) in random order across different builds. >> By the looks of it, it seems this randomness is due to the way data is being >> inserted into files with the brian2/sphinxext/generate_examples.py script, >> but I am having trouble figuring it out beyond this point. > > Wild hunch, can you trying forcing the locale in debian/rules... > > export LANG=C.UTF-8 LC_ALL=C.UTF-8 That does not fix it unfortunately :-/ CI here: https://salsa.debian.org/med-team/brian/-/jobs/1689434 The diffoscope output remains same. As far as I tweaked around, it looks like either an issue with how the docs are generated via code, more specifically via brian2/sphinxext/generate_examples.py script or it is a central problem with sphinx docs itself. Admittely, I did not find anything unusual with the code anywhere, but for sure, I _might've_ overlooked something important there. > > There are a long list of issues related to sphinx, none of which look > exactly like what you have based on the descriptions, but might be close > enough to be worth tagging your package with > randomness_in_documentation_generated_by_sphinx: > > > https://salsa.debian.org/reproducible-builds/reproducible-notes/-/blob/b0211037be80220ff0941475846840e8dc796fbf/issues.yml#L470 > > Or maybe one of the others. > > > I think sphinx is one of the documentation generation toolchains that if > we fixed some reproducibility issues in, it would fix quite a few of the > remaining unreproducible packages! Absolutely! > >> I'd really appreciate any help here. > > Try running reprotest with the --auto-build flag, which tries a build > varying only one thing at a time. It performs two normalized builds, and > if they are reproducible, it can usually identify what variations > trigger the problem... on a good day. :) Yeah, I've always run it with this option applied. The exact command I'm using is: $ sudo reprotest --vary=-build_path,domain_host.use_sudo=1 --auto-build ../brian_2.4.2-6.dsc -- schroot unstable-amd64-sbuild But this doesn't give any sensible hints (atleast to me, it doesn't look very useful) - its almost the same as in salsa CI reprotest logs. If you have some free cycles, would you mind taking in a look? And if we find out that this is due to some problem with sphinx itself, do you think it is worthwhile to file a bug report with the SOURCE_DATE_EPOCH thingy fixed? That'd be a partial patch though. Nilesh
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds