Been fighting the bug of the year last days. When bootstrapping 3.20 builders fakeroot test failed on all architectures. So a blocker for 3.20. Time sensitive. Analyze shows that the test verifies that owners of files in tarballs are what they should. They are not. Probably causing https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63669
So it is serious.
I find out that it happens with older (1.32) and newer (1.34) fakeroot. So not fakeroot. Some testing shows that it was triggered by coreutils 9.5. with 9.4 tests passes.
Nothing evident in coreutils git log, so I git bisect.
But I have to kill a dragon named gnulib on the way to the bad commit. `make` will not build coreutils without re-bootstrapping gnulib at times. I find the bad commit.
https://github.com/coreutils/coreutils/commit/193449b17334649a2abcbca589544d858fca92a1
But it has nothing to do with whatsoever. ripgrep tells me nothing should use `env` in any significant way.
So I suspect that the dragon wasn't really killed. it just pretended to be dead, and now it is rising again and attacking me from behind. What if the cause of this is in gnulib?
How do I bisect a such dragon? How do I build new coreutils from git with old gnulib?
This code is dark. very dark.
I could revert coreutils to 9.4 to get the 3.20 builders up, but 9.5 fixes a CVE so I don't want to do that either.
There is only one way to go, and it is forward.
I'm gonna try another bisect. here is how time will be spent on each rebuild cycle:
boostrap autoconf with gnulib:
real 4m 5.16s
running configure:
real 1m 0.53s
running full compile with make:
real 0m 3.57s
Alright the dragon is finally killed. Maybe not killed. just put to permanent sleep.
I have a new offending commit, and things start to make sense.