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

The 3.20 repositories for all architectures, including RISC-V, are now uploaded.

The first release candidate will be tagged soonish.

The #alpinelinux 3.20 packages are now built and uploaded for all the architectures except for riscv64, which has 115 packages left to build.

This means you can now start use and test the v3.20 repos.

@jbzfn @cnxsoft

> Unfortunately, the laptop I have on hand cannot be turned on

😂

Maybe we should run it in disk-less mode. You cannot run out of disk space if you have no disks!

Huston, we have a problem.

#alpinelinux 32bit x86 builder ran out of disk space.

Who would have guessed that /usr/bin is a weird location? Thankfully it was allowed.

GNUmakefile.llvm:228: ld.lld found in a weird location (/usr/bin/ld.lld), but its the same version as LLVM so we will allow it

Now I'm fighting circular deps.
cmake -> nghttp2 -> c-ares -> gtest -> cmake.

How do solve that kind of circular deps? easy! You vendor! cmake has vendored nghttp2. Problem solved.

But what do you do if the dependency you need is already vendoring you?

You vendor them back!

..and you end up like this:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/third_party/dawn/third_party/angle/third_party/dawn/third_party/angle/third_party/dawn/third_party/angle/

Explanation with links on what happens:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/16016#note_396726

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.

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