-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of chromium-source #12794
Comments
@aszlig didn't we do this because IO was too slow for unpacking in NixOS tests? |
I don't think the tests need the source code. |
Generally we shouldn't ship pre-release versions anyway, and we certainly don't want them to be release blockers. Also, chromium builds are just too slow to have them blocking the channel (see #12794).
Is there another way to avoid copying source derivations between machines? I think the source derivation is good to keep, I want to have QtWebEngine which uses chromium, would be nice to use chromium source and all patches that is used. Would this still be possible (in a easy way) if chromium-source is removed? |
The |
The reason I've done it that way was to separate bundled dependencies and the sandbox from the main source, so for example if we want to build just the sandbox, we don't need to extract the full Chromium source. But I'll look into it so we can find a better solution, right now it's not working as I had in mind back then, because the source is copied into the temporary build directory, but a better solution would be to not copy anything at all. |
I don't think you can re-use |
Great point. |
With S3 and decentralized hydra, we should really combine the source back. Currently this is blocking a channel update: http://hydra.nixos.org/build/33301631 |
Working on this right now. |
This addresses NixOS#12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see NixOS#8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <[email protected]>
This addresses #12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see #8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <[email protected]> (cherry picked from commit 4f981b4)
This addresses #12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see #8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <[email protected]> (cherry picked from commit 4f981b4)
I've also cherry-picked and backported the relevant changes to |
@aszlig There's reference to the old path of the update.nix file on line 33 of this file: |
Generally we shouldn't ship pre-release versions anyway, and we certainly don't want them to be release blockers. Also, chromium builds are just too slow to have them blocking the channel (see NixOS#12794). (cherry picked from commit 69ec09f)
This addresses NixOS#12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see NixOS#8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <[email protected]> (cherry picked from commit 4f981b4)
This addresses NixOS#12794 so that we now have only a single tarball where we base our build on instead of splitting the source into different outputs first and then reference the outputs. The reason I did this in the first place is that we previously built the sandbox as a different derivation and unpacking the whole source tree just for building the sandbox was a bit too much. As we now have namespaces sandbox built in by default we no longer have that derivation anymore. It still might come up however if we want to build NaCl as a separate derivation (see NixOS#8560), but splitting the source code into things only NaCl might require is already too much work and doesn't weight out the benefits. Another issue with the source splitup is that Hydra now has an output limit for non-fixed-output derivations which we're already hitting. Tested the build against the stable channel and it went well, but I haven't tested running the browser. Signed-off-by: aszlig <[email protected]> (cherry picked from commit 4f981b4)
Currently, we first build a
chromium-source
derivation containing the unpacked Chromium source code, which is then passed to the actual Chrome build. This is very inefficient: the unpacked source tree is 1.8 GB and ~85K files. Copying these between build machines can take a very long time: for instance, thenixos:release-15.09:tested
is currently showing twochromium-source
builds (in the copying state) which have already taken > 22 hours. So it would be better to do whateverchromium-source
does in thechromium
derivation.The text was updated successfully, but these errors were encountered: