xcbuild: 0.1.2-pre -> archived, fix build (x86_64-linux)

[futile]

Update to the last available version as the project has been archived, also fix the build.

Previous failure:

https://hydra.nixos.org/build/142008015/nixlog/2

[...]
FAILED: Libraries/plist/CMakeFiles/plist.dir/Sources/Format/Encoding.cpp.o 
/nix/store/zzvq5qwlm2xikawfqxb0q8gl2bw391a9-gcc-wrapper-10.2.0/bin/g++ -Dplist_EXPORTS -I/nix/store/pj89fimswl2c12dazdfy8cyka7037s6r-libxml2-2.9.10-dev/include/libxml2 -I../Libraries/plist/Headers -I../Libraries/plist/PrivateHeaders -I../Libraries/libutil/Headers -I../Libraries/ext/Headers -std=c++11 -fno-rtti -fno-exceptions -O3 -DNDEBUG -fPIC -Wall -Werror -Wno-multichar -Wno-sign-compare -fdiagnostics-color -MD -MT Libraries/plist/CMakeFiles/plist.dir/Sources/Format/Encoding.cpp.o -MF Libraries/plist/CMakeFiles/plist.dir/Sources/Format/Encoding.cpp.o.d -o Libraries/plist/CMakeFiles/plist.dir/Sources/Format/Encoding.cpp.o -c ../Libraries/plist/Sources/Format/Encoding.cpp
../Libraries/plist/Sources/Format/Encoding.cpp: In static member function 'static std::vector<unsigned char> plist::Format::Encodings::BOM(plist::Format::Encoding)':
../Libraries/plist/Sources/Format/Encoding.cpp:75:5: error: 'abort' was not declared in this scope
   75 |     abort();
      |     ^~~~~
../Libraries/plist/Sources/Format/Encoding.cpp: In function 'Endian EncodingEndian(plist::Format::Encoding)':
../Libraries/plist/Sources/Format/Encoding.cpp:105:5: error: 'abort' was not declared in this scope
  105 |     abort();
      |     ^~~~~
[...]

Motivation for this change

ZHF: #122042

@jonringer (ping meant for @NixOS/nixos-release-managers)

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

• xcbuild
• xcbuild6Hook
• xcbuildHook
• xcodebuild6

[futile]

@copumpkin @matthewbauer pinging you as you are listed as maintainers.

[futile]

Oof, looks like this causes a world-rebuild on darwin. Anything we can do to prevent this, or should I just target staging instead?

Maybe it makes sense to move the import into the #if defined(__linux__) block instead? But abort() is in <cstdlib>, that should also hold true for darwin. I guess it's included through another header on darwin, but not on linux.

Edit: Maybe it makes sense to split this into two (or more) packages, one for linux and one for darwin? That way we could fix the linux build (which doesn't have many reverse-dependencies) independent of the darwin build. Would only be a preventive fix for future issues, as it would still cause a darwin rebuild this time, but at least it would be that.

[r-rmcgibbo]

Result of nixpkgs-review pr 123106 at c70d6fb5 run on aarch64-linux 1

2 packages built successfully:

• xcbuild (xcodebuild)
• xcodebuild6

[veprbl]

Suggested change

	version = "archived";
	version = "unstable-2019-11-20";

[futile]

Is that how it's usually done when a git(hub)-repo is archived?

[veprbl]

I don't see the need to emphasize the archival status.

[SuperSandro2000]

Is that how it's usually done when a git(hub)-repo is archived?

Nothing special.

[futile]

As I just saw in aliases.nix, other archived projects have instead completely been removed from nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/aliases.nix#L362

Should we keep this alive, or remove it instead? Don't know what the policy here is.

[jonringer]

Since that was added a year ago, I would just remove it.

Thanks for doing this :)

[jonringer]

@veprbl the package just throws an error for users because of the alias. What would you rather have?

[veprbl]

@jonringer The original question was whether we should remove xcbuild because it may become abandonware, and IMO the general answer should be "it depends". And, in this case we can't remove xcbuild unless we find something to replace, as many things depend on this to build.

[jonringer]

@jonringer The original question was whether we should remove xcbuild because it may become abandonware, and IMO the general answer should be "it depends". And, in this case we can't remove xcbuild unless we find something to replace, as many things depend on this to build.

sure, but anyone on darwin trying to build one of those packages will be met with an error, and that error has been there for the past year

[veprbl]

@jonringer What error are you talking about? It builds just fine.

[jonringer]

apparently these PRs are bleeding together.... there's no error

[veprbl]

apparently these PRs are bleeding together.... there's no error

Actually there is probably still one mentioned in the OP https://hydra.nixos.org/build/142008015, but that is on x86_64-linux (likely because of the gcc10). If the version bump fixes it, we should do it. Otherwise, it's fine to mark xcbuild as broken on Linux.

[futile]

Actually there is probably still one mentioned in the OP https://hydra.nixos.org/build/142008015, but that is on x86_64-linux (likely because of the gcc10). If the version bump fixes it, we should do it. Otherwise, it's fine to mark xcbuild as broken on Linux.

Yes, the build I wanted to fix is the x86_64-linux build. The version bump alone does not fix the build, the small patch is also required. If we mark it as broken on linux and don't want to include a patch, we could instead also remove the x86_64-linux version, because the upstream repo is archived, so the build is not expected to be fixed upstream. Otherwise we fix the build for linux with the small patch, and keep the linux version around as well, then we just have to deal with the world-rebuild on darwin.

What's the preferred solution?

[SuperSandro2000]

/rebase staging

[github-actions]

Rebased, please reopen the pull request to restart CI

[stale]

I marked this as stale due to inactivity. → More info