<div><div dir="auto">Hi Daniel et al,</div><div dir="auto"><br></div><div dir="auto">If this is about the order of .rst files read by Sphinx during a docs build (and in turn the order they are output and/or listed in the contents), the command reference pages are detected by sphinx via globbing of /docs/source/cmd/*. If that is giving different orders depending on locale I imagine that would be a problem with Sphinx and not something we can solve without providing a complete list of source files, which isn’t really feasible.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Krystine</div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Jul 2024 at 9:37 PM, Emil Jiří Tywoniak <<a href="mailto:emil@yosyshq.com" target="_blank">emil@yosyshq.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Daniel,</div><div><br></div><div>Thank you for the extensive information. I have looked at the ordering of pass short_help strings and I find them to be ordered by iterating over std::map<std::string, Pass*> pass_register; which clearly is defined regardless of locale since std::map uses std::less for comparison which uses <span><span>operator<span>< which for std::string is given as std::</span></span></span>lexicographical_compare which is <a href="https://en.cppreference.com/w/cpp/algorithm/lexicographical_compare" target="_blank">described</a> as "If one range is a prefix of another, the shorter range is lexicographically <i>less</i> than the other."</div><div><br></div><div>Therefore synth_intel ought to always come before synth_intel_alm regardless of stability or locale. Would you mind sharing information about which locale was used and the commit this was tested at?</div><div><br></div><div>Cheers</div><div>Emil<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2024 at 6:16 PM Daniel Gröber <<a href="mailto:dxld@darkboxed.org" target="_blank">dxld@darkboxed.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Emil,<br>
Hi all (CC'ing rb-general to fact check my recomendation and incentives<br>
analysis below),<br>
<br>
On Mon, Jul 08, 2024 at 05:34:19PM +0200, Emil Jiří Tywoniak wrote:<br>
> Thanks for the reply. I saw that PR<br>
> <<a href="https://github.com/YosysHQ/yosys/pull/3951" rel="noreferrer" target="_blank">https://github.com/YosysHQ/yosys/pull/3951</a>> - so the blocker is related to<br>
> how Debian uses faketime in chroot, and triggered by yosys using faketime<br>
> on pdfs? Do you have some related links?<br>
<br>
That turned out to be a false-positive. Faketime was never really the<br>
problem, my assertion that graphviz supports SOURCE_DATE_EPOCH was also<br>
wrong see <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054170" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054170</a>.<br>
<br>
If you look at<br>
<a href="https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/yosys.html" rel="noreferrer" target="_blank">https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/yosys.html</a><br>
<br>
this still shows the old repro problems with CreationDate differing.<br>
<br>
<key>CreationDate</key><br>
- <value><string·size="22">D:20240629125837-12'00</string></value><br>
+ <value><string·size="22">D:20260905043016+14'00</string></value><br>
<br>
IIRC I was able to suppress that problem in the latest experimental<br>
upload. It turned out to be a makefile variable override fuckup on my part.<br>
<br>
Unfortunately the experimental package currently fails to build so the<br>
diffoscope output is not on the CI server anymore. Last I built it what I<br>
was seeing was (suspected) sort() reordering of help output depending on<br>
locale. This is incorporated into the docs build hence the repro problem.<br>
<br>
Looked something like this according to my notes:<br>
<br>
-synthesis for Intel (Altera) FPGAs.<br>
-synth_intel<br>
synthesis for ALM-based Intel (Altera) FPGAs.<br>
synth_intel_alm<br>
+synthesis for Intel (Altera) FPGAs.<br>
+synth_intel<br>
synthesis for Lattice FPGAs<br>
synth_lattice<br>
<bram_type><br>
<br>
The problem comes from me (quite intentionally) only overriding LC_*/TZ for<br>
the docs build, not the main yosys binary build. So my guess is the help<br>
texts are hardcoded into the binary at build time somehow and this depends<br>
on locale. This is where you it would help if you know or could ask your<br>
collegues if that hypothesis makes any sense or what :)<br>
<br>
I did an audit of all the sort()ish calls in yosys during mDebConf Berlin<br>
to find the culprit but alas I forgot to write down my suspect :] Note:<br>
keep in mind this could also be an unstable ordering rather than a local<br>
dependent sort() I have not yet proved the sort() hypothesis.<br>
<br>
An easy fix would be to override LC_* in Debian but we don't like to do<br>
that because ideally your upstream version shouldn't have this<br>
reproducibility hazard in the first place. This way other distros can<br>
benefit too.<br>
<br>
BTW: The reason overriding in our packaging is OK for latex/graphviz IMO is<br>
that the bugs are problems with those packages not yours so we'll either<br>
fix them upstream or in the corresponding Debian packages. If<br>
reproducibility is a concern you care about too you could opt to do this<br>
override in your build system but I would perhaps recommend against doing<br>
it in the released yosys Makefile as it would lessen the incentives for the<br>
root cause upstreams to fix their problems.<br>
<br>
The help text reordering does represent a problem in yosys though so it<br>
should be fixed there.<br>
<br>
Thanks,<br>
--Daniel<br>
</blockquote></div>
</blockquote></div></div>
</div>