In https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencc.html say:"The Build ID differs, but there are no other differences." In fact, there are two root cases cause FTBR at least. One is /usr/share/doc/opencc/html/index.html diff. This also can find from: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/opencc.html I had forwrded to upsteam[1] . The another is not has relation to build-id. I do the following debug: 1.add the --build-id=none to LDFLAGS in debian/rules: export DEB_LDFLAGS_MAINT_APPEND = -Wl,--build-id=none 2. run reprotest 3. still get fails to build reproducibly The errors output please see attachment. It has not the build-id diff in it. IMHO, It's other reason to cause the FTBR, need to investigate more. [1] https://github.com/BYVoid/OpenCC/issues/649
Thanks for looking into this! Indeed, there appear to be more issues. ... ... This is an embedded build path; reprotest builds in /tmp/reprotest-XXXXX/const_build_path/ and /tmp/reprotest-XXXXX/build-experiment-1/ between two builds. If you pass the argument to reprotest --vary=-build_path, does it build reproducibly? Looking at the history on amd64, it seems to build reproducibly except when building unstable (e.g. bookworm and bullseye seem to build reproducibly): https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencc.html Build paths are only varied when building unstable or experimental, so this would suggest the issues are related to build paths. Although, on i386 and armhf, there are still outstanding issues even in bookworm: https://tests.reproducible-builds.org/debian/history/i386/opencc.html https://tests.reproducible-builds.org/debian/history/armhf/opencc.html These architectures also systematically run one build with a 32-bit kernel and one build with a 64-bit kernel. The build may be inappropriately capturing the kernel architecture: $ git grep os.uname setup.py: _, _, _, _, machine = os.uname() setup.py: _, _, _, _, machine = os.uname() Either there, or somewhere else... ... This and the rest of the differences looks like a small offset that is possibly related to the build path being a different length (e.g. const_build_path vs. build_experiment-1). If you do two builds with a build-path of the same length, but different (e.g. /build/1/2 and /build/3/4 instead of /build/1/2 and /build/3/4/5) you might get the same result. By passing build-id=none, it may just drop the build-id, but the effect that triggers the change of build-id is still there. My educated guess here is probably build path related. live well, vagrant
When talking to upstream, please keep in mind that we have a Debian patch which alters the related part of README.md: https://salsa.debian.org/debian/opencc/-/blob/master/debian/patches/0004-no-remote-images-when-reading-docs-on-disk.patch
Hi Vagrant, 在 2021/12/14 上午1:31, Vagrant Cascadian 写道: Thanks for your instant reply. Yes, it build reproducibly ! Thanks for add Identifier: captures_build_arch [1]. Thanks for add Identifier: build_path_identifiers_in_documentation_generated_by_doxygen [2] [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencc.html [2] https://tests.reproducible-builds.org/debian/issues/unstable/build_path_identifiers_in_documentation_generated_by_doxygen_issue.html live well,
Hi Gunnar, 在 2021/12/14 上午2:17, Gunnar Hjalmarsson 写道: Thanks for your remind. I disable this patch and run reprotest agian, still get error. The detail info please see the attachment. The doxygen default add the id in html code. <a class="anchor" id="md__tmp_reprotest_ilsJd0_build_experiment_1_README"></a> I also discuss it whit upstream use telegram group https://t.me/open_chinese_convert, one of group admin feedback that it is the bug of doxygen. The config file of doxygen in opencc is doc/opencc.doxy.in, it has: wc -l opencc.doxy.in 1841 opencc.doxy.in It's so many config item, I don't know whether if exist one config item can fix this question. Regards,
Hi, The simple describe about #1001682 is: doxygen use current build path as id value in html code for README.md. <a class="anchor" id="md__tmp_reprotest_ilsJd0_build_experiment_1_README"></a> The "tmp_reprotest_ilsJd0_build_experiment_1" string is an embedded build path /tmp/reprotest-XXXXX/build-experiment-1/ This cause the FTBR[1]. The id value keep the consistent in different build path will fix this bug. [1] https://tests.reproducible-builds.org/debian/reproducible.html Thanks!