[Request for help] Making brian reproducible

[Nilesh Patra]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20210608/f309c248/attachment.sig>