@ofborg build bitwarden-cli epgstation joplin mastodon-bot theLoungePlugins.plugins.giphy

@ofborg build bitwarden-cli epgstation joplin mastodon-bot theLoungePlugins.plugins.giphy

Result of nixpkgs-review pr 193533 run on x86_64-darwin 1

FYI, we have a patch for Node 14 to disable the use of xcbuild (no clue why it wasn't applied to any future versions).

As part of my work on buildNpmPackage, I was going to port it to newer versions, which would (hopefully) mean that it's not required for these packages. If you'd like to do it instead, let me know -- no need to duplicate work :)

Result of nixpkgs-review pr 193533 run on x86_64-darwin 1

1 package failed to build:

• epgstation

4 packages built:

• bitwarden-cli
• joplin
• mastodon-bot
• theLoungePlugins.plugins.giphy

@veprbl, do you have logs for that epgstation failure? It works in OfBorg

FYI, we have a patch for Node 14 to disable the use of xcbuild (no clue why it wasn't applied to any future versions).

As part of my work on buildNpmPackage, I was going to port it to newer versions, which would (hopefully) mean that it's not required for these packages. If you'd like to do it instead, let me know -- no need to duplicate work :)

Ah, that would explain why it suddenly became required then! I was wondering but didn't really dive into it because I'm not too familiar with the Node.js ecosystem and just kinda wanted node2nix/nodePackages working again. I'll see if I can forward-port that patch real quick and test whether it fixes these builds as an alternative to adding xcbuild to stuff

(Also the buildNpmPackage stuff looks lovely and I can't wait for it to be available)

Result of nixpkgs-review pr 193533 run on x86_64-darwin 1

The failure was due to a known nix bug with sandboxing.

The failure was due to a known nix bug with sandboxing.

Just for posterity, logs/what bug? (I'd build myself but I can't at the moment and figure you have them on hand :)

Could either of you run nix build github:lilyinstarlight/nixpkgs/fix/nodepackages-darwin-v2#bitwarden-cli on darwin to see if nodejs and bitwarden-cli build with just the xcodebuild patch?

That branch is effectively @winterqt's suggestion above, but I don't have a Mac to test it on

The failure was due to a known nix bug with sandboxing.

Just for posterity, logs/what bug? (I'd build myself but I can't at the moment and figure you have them on hand :)

This one NixOS/nix#2311

@winterqt, I tested out my branch in the macOS runner in GitHub Actions and it does look like just forward-porting that patch will work to remove the need for xcbuild in these packages

It also looks like the buildNodejs function patches xcode_emulation.py in postPatch and postInstall to deal with lack of Xcode, but not in a way that seems to work with any recent Node.js versions. So I could instead update that to patch it in a somewhat interpreter agnostic way -- it could just be somewhat fragile and version-specific patches like the one for v14 may be better long-term

Also, I'm assuming a PR to patch Node.js to avoid the need for xcbuild would have to go to staging, since touching nodejs makes quite a few rebuilds (~1k on x86_64-linux alone) even if it is a low-risk change?

Edit: I also did not see any reason that patch was dropped for the v16 update in #120008

It also looks like the buildNodejs function patches xcode_emulation.py in postPatch and postInstall to deal with lack of Xcode, but not in a way that seems to work with any recent Node.js versions.

It looks like the patches you talk about are ancient (introduced in 822abc4), so that doesn't surprise me. We can definitely drop them in favor of version-specific patches, IMO.

Also, I'm assuming a PR to patch Node.js to avoid the need for xcbuild would have to go to staging, since touching nodejs makes quite a few rebuilds (~1k on x86_64-linux alone) even if it is a low-risk change?

The high amount of rebuilds was caused by your nodePackages change, I presume. I think that's a candidate for staging then, yes. (@vcunat can confirm, though.)

Edit: I also did not see any reason that patch was dropped for the v16 update in #120008

Yeah, I assume it was just forgotten about. 😔

Also, I'm assuming a PR to patch Node.js to avoid the need for xcbuild would have to go to staging, since touching nodejs makes quite a few rebuilds (~1k on x86_64-linux alone) even if it is a low-risk change?

Yes, sounds like staging to me. (Doesn't sound urgent, like security fixes.)

@lilyinstarlight Your nodePackages PR added, at most, 500 packages to this rebuild count -- any clue what the other 500+ packages that would be affected by the Node change would be? I'd really only think it would be nodePackages at the most (at least now, since it's not using Node 14), though we also have assorted web apps and such.

OfBorg lists all rebuilt packages if you click on "Details" on the "ofborg-eval" line.

OfBorg lists all rebuilt packages if you click on "Details" on the "ofborg-eval" line.

Somehow I forgot this... thanks.

I've opened #193759 targeting staging with the change to patch nodejs as before and reverted some of the changes from this PR that added xcbuild in overrides