[pkg-go] Bug#902467: Bug#902467: golang-github-kardianos-osext: FTBFS in buster/sid (failing tests)

[Anthony Fok]

HI Shengjing,

On Thu, Aug 2, 2018 at 8:49 AM, Shengjing Zhu <i at zhsj.me> wrote:
> Hi Go team,
>
> On Tue, Jun 26, 2018 at 10:52:52PM +0000, Santiago Vila wrote:
>> === RUN   TestExecutableDelete
>> --- FAIL: TestExecutableDelete (0.00s)
>>       osext_test.go:135: Child returned "/tmp/go-build962600465/b001/osext.test (deleted)", not the same file as "/tmp/go-build962600465/b001/osext.test"
>> FAIL
>> FAIL  github.com/kardianos/osext      0.004s
>>
>
> I think this test doesn't make any sense, we should just skip this test.

That would be the _pragmatic_ thing to do, especially when several
packages still depends on this package, but...

> Reading this test logic, it first reads its self executable path, then
> start it self, then remove original file. It of cause prints the
> "/tmp/go-buildnnn/b001/osext.test (deleted)".
>                                   ^^^^^^^^^

Well, yes and no... this error is intermittent (random?), and on
Debian CI and Ubuntu Autopkgtest, the test _usually_ passes:

* https://ci.debian.net/packages/g/golang-github-kardianos-osext/unstable/amd64/
* https://autopkgtest.ubuntu.com/packages/golang-github-kardianos-osext

The corresponding GitHub issue at
https://github.com/kardianos/osext/issues/21 hints at a possible race
condition in the test.

For some reasons, however, I have been unable to reproduce this test
FAIL on my own machine.

> Besides in go >= 1.8, this package's Executable function just fallback
> to go system os package.

So, yes, skipping TestExecutableDelete is the entirely pragmatic thing
to do, but there is this little voice in my gut urging me to learn to
diagnose what exactly triggers this intermittent test failure, and if
it is indeed a race condition, how to fix it?  :-)

Cheers,
Anthony