| 24 Oct 2025 |
Randy Eckenrode | They both are. I hope it’s not that change then. | 11:19:40 |
Ihar Hrachyshka | I have an alternative path to explore (adding a lot of debug messages in their png encoder to catch what happens there) but I'm lazy and want to bisect first. The crash is from access to an invalid memory address, and the code in question is:
void nsPNGEncoder::ConvertHostARGBRow(const uint8_t* aSrc, uint8_t* aDest,
uint32_t aPixelWidth,
bool aUseTransparency) {
uint32_t pixelStride = aUseTransparency ? 4 : 3;
for (uint32_t x = 0; x < aPixelWidth; x++) {
const uint32_t& pixelIn = ((const uint32_t*)(aSrc))[x];
uint8_t* pixelOut = &aDest[x * pixelStride];
uint8_t alpha = (pixelIn & 0xff000000) >> 24;
pixelOut[pixelStride - 1] = alpha; // overwritten below if pixelStride == 3
The last line crashes. Either pixelOut is null, or the caller passes a non-transparent buffer (3-bytes per pixel while also requesting transparency).
Initially thought it's the new 144 version but 1) their crash reporter database caught some failures on 140 and 2) no relevant changes in the PNG encoder code of theirs that I could spot.
| 11:33:41 |
alexfmpe | I wonder if rosetta 2 can/should be worked into stdenv.*Platform.{canExecute, selectEmulator} | 16:35:30 |
alexfmpe | or it's best called 'outside' for the whole nix-build process | 16:36:09 |
prince213 | I think it can | 16:47:50 |
prince213 | I saw an example before | 16:47:55 |
Randy Eckenrode | It is possible to set it up as an emulator in nixpkgs. I have started to do it a few times then stopped because it seems pointless. | 16:49:02 |
Randy Eckenrode | Not many things use emulators. canExecute is not about emulation, so it doesn’t help with tests when cross-compiling. | 16:50:01 |
Randy Eckenrode | Intel support in nixpkgs is (very probably) being dropped for 26.11, which likely means July next year. It doesn’t seem worth the effort to develop new features for Intel or Rosetta 2 just to remove them after 26.05 is released. | 16:52:54 |
alexfmpe | oh I thought it would last a couple more years | 16:55:38 |
alexfmpe | yeah not much point to add something after 25.11 that gets dropped by 26.05 lol | 16:56:07 |
Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/415566 | 16:56:40 |
Randy Eckenrode | macOS 27 is dropping hardware support. macOS 28 is dropping Rosetta 2 except for some unspecified compatibility intended for games. | 16:57:37 |
Randy Eckenrode | The ecosystem appears to be running away from it already. | 16:57:54 |
Randy Eckenrode | Rust demoted it to tier 2. The GitHub runner was pulled then restored, but it is limited to macOS 15. Who knows for how long. Once it’s gone, Intel support will probably start bitrotting. | 16:59:23 |
Randy Eckenrode | From the nixpkgs side, x86_64-darwin is the slowest platform to build. Being able to drop it will free up builders to build aarch64-darwin, which should make cycles go faster. | 17:00:23 |
| stderr joined the room. | 18:00:15 |
EsperLily [she/her] | the name looks right, although i suppose i didn't actually check to make sure there wasn't some hidden character or some typo i just didn't see. i really don't know why xcrun is printing a warning about that with the nixpkgs SDK when the Xcode SDK has what looks like the exact same key. Does Swift Build care about that particular key?
My bigger concern is what I mentioned in the Nixpkgs / NixOS contributions room, which is that when I try to use Xcode to build a project with the nixpkgs SDK (not Xcode-in-nixpkgs but /usr/bin/xcodebuild, though I don't know if it actually makes a difference), I end up with what looks like a neverending stream of these warnings, several per second, with no other output. I don't know if the warning itself is actually a problem here or if there's some other reason why Xcode doesn't seem to actually be doing anything except printing these warnings
| 20:08:59 |
emily | /usr/bin/xcodebuild will probably indirect through $DEVELOPER_DIR? | 20:18:41 |
emily | so is probably calling into xcbuild.xcrun etc. | 20:18:54 |
EsperLily [she/her] | /usr/bin/xcrun produces the same warning | 20:19:24 |
EsperLily [she/her] | oh wow what, /usr/bin/xcrun actually invokes xcbuild.xcrun? | 20:20:19 |
emily | everything in /usr/bin is just a stub that looks up the current developer directory | 20:20:33 |
EsperLily [she/her] | but xcrun -find xcrun doesn't find anything | 20:20:33 |
EsperLily [she/her] | yeah it's a stub that looks it up with the xcrun machinery. xcrun should be the one thing that isn't a stub | 20:20:46 |
emily | shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ mkdir -p usr/bin
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ cat >usr/bin/xcrun
#!/usr/bin/env bash
echo oops
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ chmod +x usr/bin/xcrun
shion:/v/f/1/j/T/tmp.KkX7NHuPxH
❭ DEVELOPER_DIR=(pwd) /usr/bin/xcrun
oops
| 20:21:50 |
emily | I think it recurses if there's another xcrun. | 20:22:08 |
emily | not even --help etc. do anything. | 20:22:16 |
EsperLily [she/her] | wow | 20:22:41 |
emily | I think /usr/bin/xcrun is exactly like /usr/bin/clang | 20:22:48 |