Notices by Natanael Copa (ncopa@fosstodon.org), page 4

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.

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

except that arch linux ppl cannot reproduce it when they build fakeroot package on their systems. (kernel 6.9)

I was able to reproduce it in arch linux in docker. so maybe coreutils started to use a new syscall, not available in 6.6.y kernels, and the fallback triggers this?

New discovery. the fakeroot/coreutils bug manifests itself on archlinux as well. I'm pretty sure archlinux, debian and ubuntu will bump into this sooner or later.

maybe it is not related gnulib after all?

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.

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.

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.

#alpinelinux riscv64 package builds are progressing: ~690 packages left to build.

I think the real problem is the cases where the testsuite hangs. You always wonder if something deadlocked or if it is just slow. should you wait another day or just cancel it?

There are dark clouds hanging over riscv64 support for #alpinelinux 3.20. One of the donated pioneer machines are offline due to me messing up network config remotely (who would have guess that bridge works on one of the machines but not the other?)

The other machine is still trying catch up after the python 3.12 upgrade. 770 packages to go. It is the only CI and now it is also building toolchain for 3.20.

Number of packages left to build is increasing. Now it is over 800. New updates are pushed faster than the poor riscv64 machine is able to chew and swallow

@lanodan @dalias gettext-tiny rides proudly in and saves us all.

Seems like it works

@lanodan @dalias Then we also have xz autoreconf depending on po4a, which depends on docboox-xsl which depends on libxml2-utils (libxml2). Thats another circular dep right there.

Using pre-generated configure script would solve this (and likely many more circular deps lurking around)

circular dependencies are so painful. python depends on gettext which depends on libxml2 which depends on python.

So the "rebuild libxml2 against python 3.12" happened before python 3.12.

Docker says the riscv64 gitlab-runner has been up for 54 years. Impressive!

@pu @ariadne @alpinelinux same with any issue or MR with 3.20 milestone set

@pu @ariadne @alpinelinux thanks for asking. Right now, helping with reporting the llvm18 test failures upstream and add the links to the llvm18 draft MR would help. And so would reporting upstream *and fixing* python 3.12 issues

@pu @ariadne @alpinelinux or help with any of the many open issues or draft MR. Anything that help us close anything open rather that start new issues/projects that will need my attention

@pu @ariadne @alpinelinux coming back from weekend and find number of open merge requests cut in half would certainly be a nice surprise. Currently 520+ open

@ariadne @alpinelinux please let’s pay off the current technical debt before even start talking about this.
Multi init *will* burn me out

@ariadne Splitting systemd will not happen.

https://github.com/systemd/systemd/issues/32028#issuecomment-2029879291