| 12 Mar 2026 |
 Puna | https://github.com/OPNA2608/nixpkgs/tree/wip/ppc64-installer | 13:11:45 |
| Puna | trying to always push my last tested states with all patches to that branch | 13:12:15 |
 Stas | thanks! Will do that | 13:13:22 |
| Stas | found a 1T barracuda, will screw it in too | 13:28:05 |
| Stas | as the poor old Samsung sounds too busy :D | 13:28:53 |
| Stas | I can also get iSCSI to it over both of the 1G ethernets. I have a TGT running with 2 modern HDDs in stripe | 13:29:49 |
| Stas | might be faster than a single local 1T HDD | 13:29:58 |
| Puna | K900: anything that can be done to get the mesa opencl thing closer to a merge? been ~ a month
https://github.com/NixOS/nixpkgs/pull/456839 | 14:04:29 |
 K900 | Honestly | 14:06:58 |
| K900 | It's mostly the fact that I don't like it | 14:07:02 |
| K900 | It's extremely non-specific | 14:07:09 |
| Puna | mmh… | 14:09:17 |
| Puna | the alternative is to figure out & fix all of the endianness issues in glslang, spirv-tools, and spirv-llvm-translator, and then check if mesa's mesa_clc tool still has any parsing issues. which sadly takes alot more spoons than i can allocate to this rn | 14:18:25 |
| Puna | i'll see if i can get https://github.com/NixOS/nixpkgs/pull/480841 ready this week - that'll at least further document in one of these packages that parsing on non-LE is just messed up | 14:22:02 |
| K900 | I mean that's not my concern really | 14:33:46 |
| K900 | I just really don't like the nixpkgs side implementation | 14:33:51 |
| K900 | At least I think we should flag every package that's known broken on BE as such | 14:34:08 |
| K900 | And then maybe hoist the conditionals somehow | 14:34:18 |
| K900 | Which sucks | 14:34:21 |
| Puna | can mark those packages as broken, but i think we had smth (at the very least a preference maybe?) against making features of thing depend on whether other things are marked broken, cus it'd randomly flip stuff on n off? so the condition in mesa would still p much be platformOpenCLWorks = stdenv.buildPlatform.isLittleEndian or smth like that | 14:43:02 |
| 13 Mar 2026 |
| Stas | the G5 was compiling all through the night. Managed to bootstrap gcc, and is now on python | 09:19:31 |
| Stas | I need to put a power meter on it, to see how much power it guzzles. Exhaust is not as hot as I expected, though | 14:17:15 |
 Artemis Tosini (NixOS) | I suppose that's what happens on old machines, a full FreeBSD bootstrap to stdenv takes only a few hours on my VM | 14:24:07 |
| Puna | dunno how accurate this is, but apparently the windfarm module exposes current & voltage data of the cpus
https://github.com/techflashYT/g5-power-draw-linux | 14:25:07 |
| Puna | puna@Yubel ~> ./g5-power-draw.sh
Your PowerMac G5's CPUs are currently drawing: 226.088W
Calculated using the following equation: ((5.358 + 4.663) * 12) + (45.532 * 1.247) + (39.184 * 1.252)
| 14:25:28 |
| Puna | which checks out compared to this blob post where someone put an external watt-meter on their g5
https://lowendmac.com/2025/so-how-much-power-does-a-power-mac-g5-really-use/ | 14:26:37 |
| Puna | * puna@Yubel ~> ./g5-power-draw.sh
Your PowerMac G5's CPUs are currently drawing: 226.088W
Calculated using the following equation: ((5.358 + 4.663) * 12) + (45.532 * 1.247) + (39.184 * 1.252)
building protobuf-c with 2/2 cores rn
| 14:27:11 |
| Puna | * puna@Yubel ~> ./g5-power-draw.sh
Your PowerMac G5's CPUs are currently drawing: 226.088W
Calculated using the following equation: ((5.358 + 4.663) * 12) + (45.532 * 1.247) + (39.184 * 1.252)
building protobufc with 2/2 cores rn
| 14:27:24 |
| Puna | "blob post" lol, blog* | 14:46:38 |
| Stas | interesting | 14:55:57 |
