llvm_11: patch to recognize Genode platform triples

[ehmry]

Motivation for this change

Genode is a low-tier platform in Nixpkgs. This PR would make it possible to combine the standard Nixpkgs LLVM with a custom Clang and runtime libraries to build a Genode stdenv.

This is a low-priority patch and should only be merged if LLVM is going to be rebuilt anyway.

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" (some pkgs tested, not all)
• 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.

[SuperSandro2000]

This is a low-priority patch and should only be merged if LLVM is going to be rebuilt anyway.

Staging usually rebuilds stdenv anyway so as long as it does not break things it can be safely merged.

[7c6f434c]

Hm, this is a magic constant; what's its status? Is upstream considering adding it in 12 or 13 releases? Is it just a guess?

[ehmry]

Good catch. This is what I should submit to upstream, but I've changed patch to set a temporary constant of 63.

[ehmry]

Shit, I pushed my staging to origin when it should have been my fork.

[ehmry]

Well I can't reopen this PR now because the changes are already on staging, even if they sit ahead of a revert commit.

[primeos]

Shit, I pushed my staging to origin when it should have been my fork.

Thanks for the honesty and swift response! Such things can unfortunately happen very easily. But given that it wasn't a force-push and you've already reverted it everything should be fine now :)
(Btw: If you don't need to push directly to Nixpkgs you could e.g. use git remote set-url --push origin to set the push URL to your fork. There are also other tricks.)

Well I can't reopen this PR now because the changes are already on staging, even if they sit ahead of a revert commit.

The commit in ehmry:staging needs a new ID/hash now. You could e.g. cherry-pick your original commit (9ddb9c0) onto the current NixOS:staging or revert 35e12d8 in ehmry:staging. Then it should work again.

[SuperSandro2000]

Btw: If you don't need to push directly to Nixpkgs you could e.g. use git remote set-url --push origin to set the push URL to your fork

If you create you branches from upstream that does not work. Happened to me the last week but thankfully I have a wrapper around git push -f that replaces it with --force-with-lease.

[primeos]

If you create you branches from upstream that does not work.

Why? I think you used something else (in this case the remote named origin points to the upstream repository). If Git doesn't know a URL to push directly to Nixpkgs then there should be no way you'll accidentally push to it (in theory external tools could do strange things and you could have scripts/aliases that provide the URL directly but these would be super uncommon edge-cases). And --force-with-lease wouldn't've changed anything here (it only reduces the risks of using --force a bit).

[SuperSandro2000]

git checkout -b X upstream/master points for me to this repository and pushes to upstream.

[ehmry]

See #112990

[primeos]

git checkout -b X upstream/master points for me to this repository and pushes to upstream.

@SuperSandro2000 yeah, this is expected and that's exactly why it works! You're starting to drive me crazy thb... (excuse my directness but this is getting very annoying for me)

Here is proof for you that this does work (feel free to try to reproduce it):

$ git clone --depth=1 --sparse  https://github.com/NixOS/nixpkgs.git
Cloning into 'nixpkgs'...
remote: Enumerating objects: 40119, done.
remote: Counting objects: 100% (40119/40119), done.
remote: Compressing objects: 100% (26840/26840), done.
remote: Total 40119 (delta 916), reused 27151 (delta 566), pack-reused 0
Receiving objects: 100% (40119/40119), 25.97 MiB | 10.40 MiB/s, done.
Resolving deltas: 100% (916/916), done.

$ cd nixpkgs/

$ git remote rename origin upstream

$ git remote -v
upstream        https://github.com/NixOS/nixpkgs.git (fetch)
upstream        https://github.com/NixOS/nixpkgs.git (push)

$ git remote set-url --push upstream https://github.com/SuperSandro2000/nixpkgs.git

$ git remote -v
upstream        https://github.com/NixOS/nixpkgs.git (fetch)
upstream        https://github.com/SuperSandro2000/nixpkgs.git (push)

$ git checkout -b X upstream/master
Branch 'X' set up to track remote branch 'master' from 'upstream'.
Switched to a new branch 'X'

$ git status
On branch X
Your branch is up to date with 'upstream/master'.

nothing to commit, working tree clean

$ git commit --allow-empty -m test
[X 82e032ba] test

$ git push upstream HEAD:master
Username for 'https://github.com': X
Password for 'https://X@github.com':
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/SuperSandro2000/nixpkgs.git/'

As you can clearly see Git attempted to push to https://github.com/SuperSandro2000/nixpkgs.git/ and NOT https://github.com/NixOS/nixpkgs.git.

Please show me a reproducible (and realistic) case where this doesn't work or I take it as an acknowledgement that it does work.
Thanks!

[SuperSandro2000]

git remote set-url --push upstream https://github.com/SuperSandro2000/nixpkgs.git

I didn't know you can do that. I just always have two remotes and my git config is set up that I always push to the current branch to make first time pushes easier.