On 2021-12-13, xiao sheng wen(肖盛文) wrote:
> 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.
Thanks for looking into this! Indeed, there appear to be more issues.
> 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] .
...
> [1] https://github.com/BYVoid/OpenCC/issues/649
...
> │ │ │ ├── ./usr/share/doc/opencc/html/index.html
> │ │ │ │ @@ -63,15 +63,15 @@
> │ │ │ │ </div>
> │ │ │ │
> │ │ │ │ <div class="PageDoc"><div class="header">
> │ │ │ │ <div class="headertitle">
> │ │ │ │ <div class="title">Open Chinese Convert 開放中文轉換 </div> </div>
> │ │ │ │ </div><!--header-->
> │ │ │ │ <div class="contents">
> │ │ │ │ -<div class="textblock"><p><a class="anchor" id="md__tmp_reprotest_qC7aP9_const_build_path_README"></a> [<a href="https://travis-ci.org/BYVoid/OpenCC";>Travis</a>] [<a href="https://ci.appveyor.com/project/Carbo/OpenCC";>AppVeyor</a>] [<a href="https://github.com/BYVoid/OpenCC/actions/workflows/cmake.yml";>C/C++ CI</a>] [<a href="https://github.com/BYVoid/OpenCC/actions/workflows/nodejs.yml";>Node.js CI</a>] [<a href="https://github.com/BYVoid/OpenCC/actions/workflows/python.yml";>Python CI</a>]</p>
> │ │ │ │ +<div class="textblock"><p><a class="anchor" id="md__tmp_reprotest_qC7aP9_build_experiment_1_README"></a> [<a href="https://travis-ci.org/BYVoid/OpenCC";>Travis</a>] [<a href="https://ci.appveyor.com/project/Carbo/OpenCC";>AppVeyor</a>] [<a href="https://github.com/BYVoid/OpenCC/actions/workflows/cmake.yml";>C/C++ CI</a>] [<a href="https://github.com/BYVoid/OpenCC/actions/workflows/nodejs.yml";>Node.js CI</a>] [<a href="https://github.com/BYVoid/OpenCC/actions/workflows/python.yml";>Python CI</a>]</p>
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...
> 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.
...
> │ │ │ ├── ./usr/bin/opencc
> │ │ │ │ ├── readelf --wide --program-header {}
> │ │ │ │ │ @@ -4,15 +4,15 @@
> │ │ │ │ │ There are 11 program headers, starting at offset 64
> │ │ │ │ │
> │ │ │ │ │ Program Headers:
> │ │ │ │ │ Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> │ │ │ │ │ PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000268 0x000268 R 0x8
> │ │ │ │ │ INTERP 0x0002a8 0x00000000000002a8 0x00000000000002a8 0x00001c 0x00001c R 0x1
> │ │ │ │ │ [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
> │ │ │ │ │ - LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x008568 0x008568 R 0x1000
> │ │ │ │ │ + LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x008570 0x008570 R 0x1000
> │ │ │ │ │ LOAD 0x009000 0x0000000000009000 0x0000000000009000 0x0100dd 0x0100dd R E 0x1000
> │ │ │ │ │ LOAD 0x01a000 0x000000000001a000 0x000000000001a000 0x0035af 0x0035af R 0x1000
> │ │ │ │ │ LOAD 0x01e0a8 0x000000000001f0a8 0x000000000001f0a8 0x000f98 0x0014d8 RW 0x1000
> │ │ │ │ │ DYNAMIC 0x01eaf0 0x000000000001faf0 0x000000000001faf0 0x000240 0x000240 RW 0x8
> │ │ │ │ │ NOTE 0x0002c4 0x00000000000002c4 0x00000000000002c4 0x000020 0x000020 R 0x4
> │ │ │ │ │ GNU_EH_FRAME 0x01aa90 0x000000000001aa90 0x000000000001aa90 0x00047c 0x00047c R 0x4
> │ │ │ │ │ GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
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
Attachment:
signature.asc
Description: PGP signature