CI cannot support Ubuntu 26.04 due to broken build-essential package

[oech3]

CI needs build-essential and GNU coreutils as system binary for testing. However, Ubuntu 26.04's build-essential strongly depends on uutils and rejects GNU as system binary.
If Ubuntu decided to not fix the broken dependency, we need to build our own custom build-essential, or just abandon supporting one of the most common target.

cc @julian-klode @Ecordonnier

[BAMF0]

Hmm yes this is a problem indeed. Where does the CI break?

Naively, a quick (hacky) fix is to append gnu to the calls where the GNU alternatives are wanted, e.g. gnuls. Both uutils and GNU are co-installable, it's just that the symlinks are forced to point to uutils in this scenario. However this "fix" is problematic if one does not have direct control of the code.

Judging by the changelog, the build-essential dependency on uutils should be a temporary hack though and I would not expect it to remain.

[oech3]

I know fuzzer only. I guess it is used much more, but I forgot...
The name gnuls is Ubuntu specific, so using the name disallows running fuzzer locally.

[BAMF0]

Good point. There is an associated bug report on Launchpad for Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/build-essential/+bug/2148691. One rationale for the strict dependency on uutils seems to be to not allow building in an unsupported environment (i.e. uutils is the coreutils provider on Ubuntu -> building with GNU is unsupported). Still, I would think that it should be possible for the user to decide this. Let me investigate and see what the best solution could be on the Ubuntu side.

Another solution I see is separating the build and test job such that the test uses the build artifact without any explicit dependencies on the build environment. In this case, the GNU alternative can be forced using the following command:

sudo apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential

Would this work?

[oech3]

I guess cargo build -> apt-get -> cargo test works if uutils itself does not break cargo.
I previously tried to replace CI's coreutils with uutils which caused CI's failure...

[BAMF0]

Intuitively I would expect cargo to be agnostic of the coreutils provider. We should be able to share build artifacts using actions/upload-artifact@v4.

If uutils breaks CI however, that should definitely be looked into. Do you have any logs available that I could investigate?

[oech3]

Maybe, I am missing something. I just tried to install uutils on the system which removes cargo. https://github.com/uutils/coreutils/actions/runs/26641664722/job/78516087799?pr=9634#step:10:35

[oech3]

No issue with uutils as system binary now.

[BAMF0]

Awesome! Glad it got fixed.

[oech3]

GNU coreutils on https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2604-Readme.md is too old for us...

[BAMF0]

GNU coreutils on https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2604-Readme.md is too old for us...

Weird, 26.04 Resolute Racoon has GNU coreutils version 9.7 (ref: https://launchpad.net/ubuntu/+source/coreutils), not sure how they could be using 9.5 in their runner image. Is 9.7 still too old?

[oech3]

I know it is difficult to do that (until GitHub provide Arch runner), but I want to use latest GNU since it is goal of this project.

[BAMF0]

Thanks for bringing it up! My 26.04 system also has 9.5 installed for some reason... this is odd. Let me have a look.

[oech3]

#13200

[BAMF0]

I know it is difficult to do that (until GitHub provide Arch runner), but I want to use latest GNU since it is goal of this project.

Yeah I understand, that's reasonable IMO. Would it work if we provided a PPA for this purpose? Then you could add that as a repository and explicitly install the latest available version.