| 18 Sep 2025 |
nim65s | Ok, then I can leave this part to you, as I'm pretty sure you'll be faster than me on all points, and keep working on random leaf things I already know a bit | 06:33:16 |
K900 | OK I think I just got hit with https://savannah.gnu.org/bugs/?66416 | 07:43:58 |
K900 | Somehow | 07:45:00 |
K900 | Are we doing GCC 15 this cycle btw | 07:45:55 |
K900 | (please say no) | 07:45:57 |
Yureka (she/her) | new llvm pls | 07:47:00 |
K900 | I think we already have that no | 07:47:43 |
Grimmauld (any/all) | In reply to @k900:0upti.me OK I think I just got hit with https://savannah.gnu.org/bugs/?66416 Can we just drop screen already, we do have tmux... | 07:50:06 |
ghpzin | Somebody disabled them for loongarch64 recently, and yes on top of gcc15 it fails on that test constantly. | 07:51:35 |
K900 | Also on 14.3.0 | 07:52:08 |
K900 | Seemingly | 07:52:08 |
ghpzin | * Somebody disabled them for loongarch64 recently
https://github.com/NixOS/nixpkgs/pull/426840
and yes on top of gcc15 it fails on that test constantly. | 07:53:07 |
ghpzin | I almost managed to build graphical iso with ~30 fixes of questionable quality. But then mesa fails with something strange. | 08:35:38 |
K900 | Mesa? | 08:43:48 |
K900 | That's interesting | 08:43:50 |
K900 | Do you have a log | 08:43:57 |
ghpzin | FAILED: [code=1] src/nouveau/compiler/nak_bindings.rs
/nix/store/rm899xgm82kanr814dk8siwyghyxwphg-rust-bindgen-0.72.0/bin/bindgen ../src/nouveau/compiler/nak_bindings.h
/build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
Unable to generate bindings: clang diagnosed error: /build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
| 08:44:16 |
ghpzin | FAILED: [code=1] src/nouveau/compiler/nak_bindings.rs
/nix/store/rm899xgm82kanr814dk8siwyghyxwphg-rust-bindgen-0.72.0/bin/bindgen ../src/nouveau/compiler/nak_bindings.h
/build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
Unable to generate bindings: clang diagnosed error: /build/source/src/nouveau/winsys/./nouveau_bo.h:41:4: error: unknown type name 'atomic_uint_fast32_t'
https://gist.github.com/ghpzin/35e5fb891645e02e5b2873761c593722 | 08:47:31 |
K900 | https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/winsys/nouveau_bo.h?ref_type=heads#L8 | 08:47:54 |
K900 | I wonder if GCC changed stuff around stdatomic.h | 08:49:32 |
K900 | https://github.com/gcc-mirror/gcc/commits/releases/gcc-15/gcc/ginclude/stdatomic.h | 08:50:59 |
K900 | Doesn't look like it at least | 08:51:03 |
ghpzin | There was an issue upstream with that exact error, but "solution" was seemingly to just juggle installed libraries on ubuntu:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/11869 | 08:53:25 |
K900 | Are you sure this is a GCC version thing then and not an LLVM version thing? | 08:55:37 |
ghpzin | If you mean staging related LLVM changes, then no, it fails on top of master too.
Maybe one of the fixes in the chain somehow affects it.
Will try to minimize reproducer on master later. | 09:01:38 |
ghpzin | * If you mean staging related LLVM changes, then no, it fails on top of master too.
Maybe one of the fixes in the gcc15 chain somehow affects it.
Will try to minimize reproducer on master later. | 09:03:23 |
emily | it would be fun but probably next cycle is the safe move. though I worry about freeze | 10:01:55 |
emily | actually if we're that close to the ISO then this cycle might work | 10:02:51 |
emily | ehh probably not | 10:03:39 |
K900 | Please do not this cycle | 10:31:03 |