Skip to content
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

Closed
edolstra opened this issue Feb 3, 2016 · 11 comments
Closed

Get rid of chromium-source #12794

edolstra opened this issue Feb 3, 2016 · 11 comments
Assignees
Labels
0.kind: enhancement Add something new
Milestone

Comments

@edolstra
Copy link
Member

edolstra commented Feb 3, 2016

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, the nixos:release-15.09:tested is currently showing two chromium-source builds (in the copying state) which have already taken > 22 hours. So it would be better to do whatever chromium-source does in the chromium derivation.

@edolstra edolstra added the 0.kind: enhancement Add something new label Feb 3, 2016
@domenkozar
Copy link
Member

@aszlig didn't we do this because IO was too slow for unpacking in NixOS tests?

@edolstra
Copy link
Member Author

edolstra commented Feb 3, 2016

I don't think the tests need the source code.

edolstra added a commit that referenced this issue Feb 3, 2016
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).
@joelmo
Copy link
Contributor

joelmo commented Feb 3, 2016

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?

@edolstra
Copy link
Member Author

edolstra commented Feb 3, 2016

The chromium-source derivation could create a (compressed) tarball. That would help a lot since then Hydra won't have to do a huge amount of random access I/O reading/writing lots of small files.

@aszlig
Copy link
Member

aszlig commented Feb 3, 2016

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.

edolstra added a commit that referenced this issue Feb 5, 2016
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).

(cherry picked from commit 69ec09f)
@ttuegel
Copy link
Member

ttuegel commented Feb 12, 2016

I want to have QtWebEngine which uses chromium

I don't think you can re-use chromium-source for this, as Qt uses a rather heavily modified version of the source.

@heydojo
Copy link
Contributor

heydojo commented Feb 12, 2016

I don't think you can re-use chromium-source for this, as Qt uses a rather heavily modified version of the source.

Great point.
I will add too that even if it was vanilla, chrome source moves far too quickly to be a dependency of a qt component.
QtWebEngine is; I suspect using their own fork of the blink fork of webcore (webkit.) https://en.wikipedia.org/wiki/Blink_(web_engine)
If we look at the chromium release schedule https://www.chromium.org/developers/calendar they are trying to hit a release almost every month.
If someone is quick (Before 19th of this month) they could apply for a gsoc https://summerofcode.withgoogle.com/ to possibly get this chromium work done (worth a try?)

@domenkozar
Copy link
Member

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

@domenkozar domenkozar added this to the 16.03 milestone Mar 17, 2016
@aszlig
Copy link
Member

aszlig commented Mar 20, 2016

Working on this right now.

@aszlig aszlig self-assigned this Mar 20, 2016
aszlig added a commit to aszlig/nixpkgs that referenced this issue Mar 20, 2016
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]>
@aszlig aszlig closed this as completed in 96a9c23 Mar 21, 2016
aszlig added a commit that referenced this issue Mar 21, 2016
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)
aszlig added a commit that referenced this issue Mar 21, 2016
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)
@aszlig
Copy link
Member

aszlig commented Mar 21, 2016

I've also cherry-picked and backported the relevant changes to release-15.09.

@aszlig aszlig modified the milestones: 16.09, 16.03 Mar 21, 2016
@seanstrom
Copy link

@aszlig There's reference to the old path of the update.nix file on line 33 of this file:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/google-chrome/default.nix

adrianpk added a commit to adrianpk/nixpkgs that referenced this issue May 31, 2024
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)
adrianpk added a commit to adrianpk/nixpkgs that referenced this issue May 31, 2024
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)
adrianpk added a commit to adrianpk/nixpkgs that referenced this issue May 31, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: enhancement Add something new
Projects
None yet
Development

No branches or pull requests

7 participants