That's great news. Thank you

FWIW, even though qemu64 is the default CPU, practically everyone would be better off choosing one of the other CPU models explicitly to better suit their desired use case. There is some guidance here https://qemu.weilnetz.de/doc/qemu-doc.html#cpu_005fmodels

It's a QEMU bug

Downstream bug report

[build@build /usr/home/build]$ cat hello.c
int main(int argc, char **argv) {
	return 0;
}
[build@build /usr/home/build]$ clang -c hello.c -march=native
error: unknown target CPU 'athlon-xp'
note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont,
      goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i,
      haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cannonlake,
      icelake-client, icelake-server, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3,
      athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4,
      znver1, x86-64

This is happening because the environment has the CPU name incorrect. It is reporting athlon-xp which is a 32-bit CPU, however the system is 64-bit.

This is causing many tests from Zig's test suite to fail, because it passes -march=native for the native target when importing .h files and compiling C code.

Here's an example. sr.ht is setting the TERM=xterm-256color, but not being able to support all of the things that implies:

https://builds.sr.ht/~andrewrk/job/116323

You can see that it's not honoring the escape codes to move the cursor, but it is honoring the escape codes to render color. I believe the TERM environment variable is incorrect; in this case it should either set TERM=dumb, indicating no escape codes are possible, or find or invent some new standard value for this which indicates colors are possible but moving the cursor is not possible.

Another solution would be to implement cursor movement terminal escape codes in builds.sr.ht.

Perhaps via an environment variable such as $SRHT_GIT_BRANCH.

For example I want to know if this is master branch so that I can update a download page with uploaded binaries. Or if it's a non-master branch I want to create an alias from that branch name to a download link.

Here's how I do this with Azure Dev Pipelines today:

https://github.com/ziglang/zig/blob/9801a1df6a6a55bb98cb4141d7e8f7340f324de2/ci/azure/linux_script#L33

The issue is that this is a poor user experience:

• fill in a valid looking git URL into the sources field
• enable the "pull request" dispatch
• things appear to be working, but find out several weeks later that the "pull request -> build" dispatch hook is actually building master branch and not pull requests

Must I have a solution in mind for this to be an open todo item?

Thanks - that fixed it. I'll leave this issue open with the feature request that if this mistake is made, the CI fails with an error message telling how to fix the yml

See downstream issue for details: https://github.com/ziglang/zig/issues/1960