#263 freebsd clang cannot build "hello world" C application with -march=native because the CPU id is incorrect 5 months ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

That's great news. Thank you

#263 freebsd clang cannot build "hello world" C application with -march=native because the CPU id is incorrect 5 months ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

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

#263 freebsd clang cannot build "hello world" C application with -march=native because the CPU id is incorrect 5 months ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

It's a QEMU bug

#263 freebsd clang cannot build "hello world" C application with -march=native because the CPU id is incorrect 5 months ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

#263 freebsd clang cannot build "hello world" C application with -march=native because the CPU id is incorrect 5 months ago

Ticket created by ~andrewrk on ~sircmpwn/builds.sr.ht

[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.

#252 Choose a better TERM environment variable value, or implement cursor movement escape codes 8 months ago

Ticket created by ~andrewrk on ~sircmpwn/builds.sr.ht

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.

#207 ability for builds to know the name of the associated git branch 1 year, 4 months ago

Ticket created by ~andrewrk on ~sircmpwn/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

#24 Handle .git postfix on source URLs when doing source replacement 1 year, 5 months ago

Comment by ~andrewrk on ~sircmpwn/dispatch.sr.ht

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?

#24 Handle .git postfix on source URLs when doing source replacement 1 year, 5 months ago

Comment by ~andrewrk on ~sircmpwn/dispatch.sr.ht

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

#24 Handle .git postfix on source URLs when doing source replacement 1 year, 5 months ago

Ticket created by ~andrewrk on ~sircmpwn/dispatch.sr.ht

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