Fix cycle detected in Darwin->Linux cross GCC #96404
Conversation
They can be caught with `nixos-option -r` on an empty ({...}:{}) NixOS
configuration.
This reverts d9feea5 with some slight modifications to work with other changes since then. Fixes NixOS#88213.
This doesn’t work with latest nccl anymore.
This appears to avoid requiring KVM when it’s not available. This is what I originally though -cpu host did. Unfortunately not much documentation available from the QEMU side on this, but this appears to square with help: $ qemu-system-x86 -cpu help ... x86 host KVM processor with all supported host features x86 max Enables all features supported by the accelerator in the current host ... Whether we actually want to support this not clear, since this only happens when your CPU doesn’t have full KVM support. Some Nix builders are lying about kvm support though. Things aren’t too slow without it though. Fixes NixOS#85394 Alternative to NixOS#83920
This way we not accidentally use introduce/use global variables. Also it explictly mark the code for the mypy type checker.
- Less code - more thread-safe according to @flokli
Appearantly this is used in tests
https://chromereleases.googleblog.com/2020/08/stable-channel-update-for-desktop_25.html This update includes 20 security fixes. CVEs: CVE-2020-6558 CVE-2020-6559 CVE-2020-6560 CVE-2020-6561 CVE-2020-6562 CVE-2020-6563 CVE-2020-6564 CVE-2020-6565 CVE-2020-6566 CVE-2020-6567 CVE-2020-6568 CVE-2020-6569 CVE-2020-6570 CVE-2020-6571
This is more robust than depending on the channel, though the version should only matter if the configuration phase fails. This also switches to the intended version for `chromium` which should be higher since M85 is in the stable channel. Thanks `@volth` for pointing this out.
chromium: 84.0.4147.135 -> 85.0.4183.83
same as 459c60d but for gcc10
matthewbauer
requested review from
FRidh,
joachifm,
jonringer,
Mic92,
mmahut,
tfc and
zowoq
as code owners
|
@matthewbauer thanks for picking this up |
|
umm, was the right branch pushed @matthewbauer ? |
|
The commit you pushed contains a lot more than just your changes 25ac498 |
|
I think he merged master into staging. |
|
Which should be fine. |
|
it will still make git history awkward, and might cause some issues with git bisect |
|
plus, you generally want to push the changes from master to staging-next, then staging-next into staging, if you're trying to update the staging branches. |
|
I thought stuff goes to staging first before it goes to staging-next. |
|
if you want changes from master to be pushed to staging, generally you push them first to staging-next, then push staging-next into staging EDIT: if you want the changes from staging to be in master, then you push it to staging-next, do some stabilization, and let hydra build up the cache, then merge into master |
|
I can't find the original post, @FRidh would know better |
|
Oh ok, so origin/master should merge into origin/staging-next first then origin/staging? Usually I think it went the other way where origin/master merges into origin/staging which eventually merges back into origin/staging-next. |
|
it does both staging -> staging-next -> master: to bring changes from staging to master, but allowing for stabilization master -> staging-next -> staging: to prevent staging and staging-next from diverging from master significantly (this is usually done after staging-next PR is completed, because it should have changes in master already in it) master -> staging-next: done frequently in |
|
Like I said before, this probably won't affect "derivations" too much, but it could cause some awkwardness with |
|
at the very least, the PR should have been open longer than 100s before getting merged |
| @@ -241,7 +241,7 @@ postInstall() { | |||
| # More dependencies with the previous gcc or some libs (gccbug stores the build command line) | |||
| rm -rf $out/bin/gccbug | |||
|
|
|||
| if type "patchelf"; then | |||
| if [[ buildConfig == *"linux"* ]]; then | |||
There was a problem hiding this comment.
[[ buildConfig == *"linux"* ]] is always false since linux is not a substring of the literal string buildConfig. Did you mean for this to be a variable or something?
Fixes #88213