Hello,
Am Fri, 30 Sep 2016 14:55:26 +0200 schrieb Holger Levsen <hol...@layer-acht.org>: > from IRC: > > <h01ger> | > https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/munin.html > - fascinating. also how this cannot be seen on i386?!? > < ntyni> | race between ./plugins/node.d.linux/netstat.in and > ./plugins/node.d/netstat.in ? > <h01ger> | and "diff ./plugins/node.d.linux/netstat.in > ./plugins/node.d/netstat.in" confirms > > the HTML diffoscope output is attached, the txt output can be seen > at > https://tests.reproducible-builds.org/debian/dbdtxt/experimental/armhf/munin_2.999.3-1.diffoscope.txt > > So as a result, the shipped /usr/shar/munin/plugins/netstat sometimes is > the one from ./plugins/node.d and sometimes it's the one from > ./plugins/node.d.linux ! (Filing this bug only with severity "important" > as it just seems to affect one plugin…) what a mysterious behaviour! I went through the Makefile and failed to find an obvious source of the problem. Thus I started to look for the "barely imaginable" places and found the following ones: 1) The plugins are "compiled" individually by a perl script filter. There is a strict one-to-one mapping from input filenames to output filenames. Thus ordering cannot be an issue here. It _could_ be, that the filtering did not transfer all files (e.g. because the output of "find" was truncated). But this could not have happened without an error from "make". 2) The "OSTYPE" is determined (see debian/ostype_helper) by comparing the output of "uname" with "Linux" and "GNU/kFreeBSD". If there is no match (or "uname" fails silently - why should it?), the "OSTYPE" variable would end up empty. This could be an explanation for the generic plugin being installed instead of the linux-specific one. I added "set -e" to the "ostype_helper" script. In case this problem ever comes back again, we would know, that "ostype_helper" did not cause it. 3) The "compiled" files are copied within the following for loop: for p in build/plugins/node.d/* build/plugins/node.d.$(OSTYPE)/* ; do As far as I understand shell substitution (here: pathname expansion), the two tokens above are evaluated and substituted separately. Thus the resulting items are in proper order (first generic, second OS specific). This loop cannot be shorted, as far as I can tell. Thus it is hard to imagine, that the error happens here. Do you have any ideas? Should we just wait for the next reproducibility error? Cheers, Lars
