fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

Natanael Copa

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 gitlab.alpinelinux.org/alpine/

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.

GitLabmain/alpine-baselayout: fix group of /etc/shadow- (!63669) · Merge requests · alpine / aports · GitLabI had cases where /etc/shadow- didn't have the correct group while creating rootfs. I am not 100% sure what caused it but this should fix it.

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.
github.com/coreutils/coreutils

But it has nothing to do with whatsoever. ripgrep tells me nothing should use `env` in any significant way.

GitHubenv: add -a,--argv0 to set the first argument passed to exec · coreutils/coreutils@193449bUsing the shell's exec -a feature can be awkward so add support for setting overriding argv[0]. This gives env full control over the arguments it passes. * src/env.c: Accept -a,--argv0 and set...

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.