Since I'm planning to fork xcbuild to include the bits needed for swift-build, I wanted to ask about the fate of tools in xcbuild conflicting with better implementations. Specifically xcbuild right now ships with buggy actool and not-quite-compatible PlistBuddy/plutil. I've got those ready in separate packages - actool and re-plistbuddy respectively. I could:

• leave the broken versions in place (confusing)
• remove those from xcbuild
• include my reimplementations in xcbuild automatically
  I'm leaning towards option 2 and let projects include specific tools as needed, but could be convinced otherwise. Do people have strong opinions here?

Since I'm planning to fork xcbuild to include the bits needed for swift-build, I wanted to ask about the fate of tools in xcbuild conflicting with better implementations. Specifically xcbuild right now ships with buggy actool and not-quite-compatible PlistBuddy/plutil. I've got those ready in separate packages - actool and re-plistbuddy respectively. I could:

• leave the broken versions in place (confusing)
• remove those from xcbuild
• include my reimplementations in xcbuild automatically

I'm leaning towards option 2 and let projects include specific tools as needed, but could be convinced otherwise. Do people have strong opinions here?

Since I'm planning to fork xcbuild to include the bits needed for swift-build, I wanted to ask about the fate of tools in xcbuild conflicting with better implementations. Specifically xcbuild right now ships with buggy actool and not-quite-compatible PlistBuddy/plutil. I've got those in much better state and maintained in separate packages - actool and re-plistbuddy respectively. I could:

• leave the broken versions in place (confusing)
• remove those from xcbuild
• include my reimplementations in xcbuild automatically

I'm leaning towards option 2 and let projects include specific tools as needed, but could be convinced otherwise. Do people have strong opinions here?

direnv is failing on nixpkgs-unstable https://github.com/NixOS/nixpkgs/issues/513019
I note from the isuue that

Can Hydra reproduce this build failure?

The last build job was manually cancelled.

Does this mean that failure on direnv builds for darwin can be ignored and we get a broken nikpkgs - or is this just a one off manual error?
The error looks like a timeout

feels like i landed at a reasonable spot with https://github.com/NixOS/nixpkgs/pull/512100 so i opened it for review. i was able to remove the hackier patches for sqlcipher with flags found upstream/remove the hardcoded xcode path, as well as keep the original propagate-inputs.nix in the apple-sdk largely unchanged apart from a single ios-specific flag for tls. working on submitting a very small pr to gnulib to remove the patch for gnugrep. rerunning builds for darwin/ios platforms after rebasing on the latest staging, and also happy to wait for 'realLibiconv' to land so I can verify with that as well.

after actually looking at gnulib, it seems can simplify the gnugrep package for iOS as well, since the libc/nlist headers weren't used and the stackvma stuff is actually available

feels like i landed at a reasonable spot with https://github.com/NixOS/nixpkgs/pull/512100 so i opened it for review. i was able to remove the hackier patches for sqlcipher with flags found upstream/remove the hardcoded xcode path, as well as keep the original propagate-inputs.nix in the apple-sdk largely unchanged apart from a single ios-specific flag for tls. working on submitting a very small pr to gnulib to remove the patch for gnugrep. rerunning builds for darwin/ios platforms after rebasing on the latest staging, and also happy to wait for 'realLibiconv' to land so I can verify with that as well.

after actually looking at gnulib, it seems can simplify the gnugrep package for iOS as well, since the libc/nlist headers weren't used and the stackvma stuff is actually available on ios

feels like i landed at a reasonable spot with https://github.com/NixOS/nixpkgs/pull/512100 so i opened it for review. i was able to remove the hackier patches for sqlcipher with flags found upstream/remove the hardcoded xcode path, as well as keep the original propagate-inputs.nix in the apple-sdk largely unchanged apart from a single ios-specific flag for tls. working on submitting a very small pr to gnulib to remove the patch for gnugrep. rerunning builds for darwin/ios platforms after rebasing on the latest staging, and also happy to wait for 'realLibiconv' to land so I can verify with that as well.

edit: after actually looking at gnulib, it seems can simplify the gnugrep package for iOS as well, since the libc/nlist headers weren't used and the stackvma stuff is actually available on ios

how do i patch this perl snippet to behave on nix?

my $script_path =
  File::Spec->catfile($FindBin::Bin, '..', 'lib', 'media-control',
  'mediaremote-adapter.pl');
my $framework_path = File::Spec->rel2abs(
  File::Spec->catdir(
    $FindBin::Bin, '..', 'Frameworks', 'MediaRemoteAdapter.framework'
  )
);
my $test_client_path = File::Spec->rel2abs(
  File::Spec->catdir(
    $FindBin::Bin, '..', 'lib', 'media-control', 'MediaRemoteAdapterTestClient'
  )
);