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,