Although I couldn't test this because I'm not using a DE, nobody else
than the one submitting the pull request has commented on this. So if it
should break the icon for other people, nobody would probably start an
assassination because of this and the commit can be easily reverted if
it should break the icon.
wkennington@f6c1004 switched Firefox to GStreamer 1.0 by changing its
buildInput *only*, but that is not enough. We need to fix Firefox
wrappers by changing their buildInputs and set GST_PLUGIN_SYSTEM_PATH_1_0
instead of GST_PLUGIN_SYSTEM_PATH.
With above changes playing H.264/MP4 media works in firefoxWrapper and
conkerorWrapper as tested with
http://www.quirksmode.org/html5/tests/video.html and
https://soundcloud.com/immclovin33/synthetix-sundays-53-with-marko-maric-19715
It should help with peti#9247
Reviewed-by: kmicu <kmicu@protonmail.ch>
Tested-by: kmicu <kmicu@protonmail.ch>
Overview of the updated versions:
beta: 45.0.2454.15 -> 45.0.2454.26
dev: 45.0.2454.15 -> 46.0.2471.2
Changes for getting beta and dev channel to build:
* The reference for chrome::FILE_FLASH_PLUGIN doesn't exist anymore in
version 46, because it has been dropped upstream, see the following
review URL:
https://codereview.chromium.org/1255943002
We set the PPAPI Flash path using a command line flag anyway, so it
doesn't hurt us if we don't patch that path (which was an old
artifact from the NSAPI->PPAPI conversion anyway).
Changes for the dev channel only:
* It seems that in the SCM, chrome/test/data/webui/ contains a lot of
files, however they are missing in the tarball.
This has been reported upstream at: https://crbug.com/515917
Our fix is to just not include webui/i18n_process_css_test.html at
all, to avoid the configure (gyp) phase to fail, because we're not
building tests anyway.
All channels built and tested by my Hydra instance at:
https://headcounter.org/hydra/eval/218978
Test reports:
x86: https://headcounter.org/hydra/build/723341/download/1/log.html
x86_64: https://headcounter.org/hydra/build/723342/download/1/log.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Use system libpng with apng support.
Use the system icu which works fine in newer firefox builds.
Use jemalloc to speed up memory allocations and reduce fragmentation.
This reverts commit cd52c04456 and
others.
Managing certificates (including revoking certificates and adding
custom certificates) becomes extremely painful if every package in the
system potentially depends on a different copy of cacert. Also, it
makes updating cacert rather expensive.
The only mirror left which still has the .deb for 44.0.2403.89 is
http://mirror.pcbeta.com/, but that one doesn't seem to be reachable
from certain contries.
And according to @CestDiego, it doesn't seem to be reachable from within
the US.
Closes#9021, thanks to @CestDiego for reporting.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Diego Berrocal <cestdiego@gmail.com>
Tested-by: Diego Berrocal <cestdiego@gmail.com>
Overview of the updated versions:
stable: 43.0.2357.125 -> 43.0.2357.130
beta: 44.0.2403.52 -> 44.0.2403.61
For the beta channel the following changes were necessary:
* Drop all patches which were added in c290595 because they apply to
44.0.2403.52 only. The shipped version of Blink was older than the
one used for Chromium itself and thus contained just the
cherry-picked patches from upstream Blink.
* The ffmpegsumo library is now statically linked the same way as in
the dev version, so let's not try to put it into the output store
path.
All channels were built successfully on my Hydra at:
https://headcounter.org/hydra/eval/187176
VM tests did also pass and can be found at:
x86: https://headcounter.org/hydra/build/707636
x86_64: https://headcounter.org/hydra/build/707637
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just silencing the error will not prevent Chromium from trying to start
up the SUID sandbox anyway, thus flooding stderr with:
LaunchProcess: failed to execvp:
After digging a bit in the source code I found out that the SUID sandbox
binary is indeed used, but only for setting oom_score_adj within the
user namespace (as "root"). So let's build the sandbox binary and of
course don't set setuid bit.
These annoying error messages were originally introduced by 0aad4b7 and
I'm deeply sorry for annoying you guys out there with them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since 0aad4b7, we no longer need to have an external sandbox binary,
because the upstream implementation of the user namespace sandbox no
longer needs an external sandbox binary.
In our implementation of the user namespace sandbox, we (ab)used the
setuid sandbox to run non-setuid and set up user namespaces instead.
Because our implementation is no longer needed, we can safely drop the
external binary entirely.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There has been some recent news about that component extension on hacker
news:
https://news.ycombinator.com/item?id=9724409
Even though on our side it won't work, because we don't have NaCl
enabled by default or even working (I honestly haven't tested if it even
builds if enabled), we might get to the point where we can build with
NaCl enabled.
But until and even after that day, we want to have explicit control on
whether this extension is enabled.
Please also have a look at these two issues explaining the details
(about component extensions and the hotwording extension in particular):
https://crbug.com/491435https://crbug.com/500922
Fixes issue #8358.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There was the usual crashing and a few icons missing.
@lethalman: I think it's best to start putting $XDG_ICON_DIRS into suffix
instead of prefix (as here), so user-installed icons take precedence.
/cc #7743.
This also merges pull request #8290 plus a few other fixes from
@ambrop72 and me.
The summary of changes is:
* Update all channels to latest upstream.
* Update GYP package and drop gyp_svn1977.
* Remove ICU from buildInputs to prevent build failure.
* Switch back to using --depth . to GYP instead of patching in the
absolute store paths.
* Don't symlink source code anymore, which might introduce a
regression on high I/O load on Hydra. As this is only a temporary
build fix, let's cross fingers and hope we don't hit it. See
c92dbffeac for an explanation.
* Use HTTPS for the bucket URL.
* Fix nix_plugin_paths patch for version 44 and higher.
Tested at: https://headcounter.org/hydra/eval/169134
The pepper effects plugin has been removed and migrated to NaCl, so I'm
just dropping the hunk of that patch.
Upstream reviow URL: https://codereview.chromium.org/1085393003
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Changes included:
- Update versions.
- Use gyp package not gyp_svn1977.
- Remove icu from buildInputs, since this causes a build error due to inferference with use_system_icu=false.
- Remove the hack that inserts the absolute path into gyp files, and pass `--depth .` to gyp. This resolves the `third_party/angle` gyp error.
- Do a normal copy of the source code not a symlink copy. This resolves some link error where the symlinks interfere with relative paths (seems like because gyp resolves symlinks first). Note, this used to be worked around with the absolute path insertion hack.
- Change the bucketURL in update.nix to https (for more secure updates).
Many (less easily automatically converted) old-style strings
remain.
Where there was any possible ambiguity about the exact version or
variant intended, nothing was changed. IANAL, nor a search robot.
Use `with stdenv.lib` wherever it makes sense.
Works around regression from a305e6855d.
We're also marking it lowPrio to make sure nobody will accidentally
reference it using nix-env -i.
Until we have fixed#7402, we're going to build with the old gyp version
to prevent being affected by https://crbug.com/462153.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We shouldn't make assumptions on what is set by NIX_PATH in order to
make it easier to rename that Nix path reference.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
After the pulseaudio refactor in NixOS/nixpkgs@a2a3508, libcap is no
longer propagated to chromium anymore. And we need to have libcap for
the renderer sandbox.
Build log: https://hydra.nixos.org/build/21689759/nixlog/1/raw
What makes me wonder is that given that this was propagated by
pulseaudio noone either seemed to have disabled pulseaudio support for
Chromium or just didn't report the build failure.
Half-assed testing done against all channels, because it builds the
sandbox and we can't break an already broken build twice (or maybe we
can, who knows...).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 0696b0ef78.
Okay, now finally, let's get this straight. We actually *want*
preferLocalBuild, *because* we have improved the source splitup in
c92dbffeac.
The idea is to use local builds in order to prevent the source being
pushed to a remote machine, splitted up there (and thus copied again)
and then being copied *again* FROM the remote machine.
"DOH!" - as @edolstra or @rbvermaa would call it... and good d^Hnight.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 26f024626c.
I actually wasn't reading the "remove" in the commit message, so sorry
for the brainfart/noise.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit fdb5cf8107.
The reason I'm reverting this is that the implications this had on the
IO load of Hydra are fixed by c92dbffeac.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far we've done the source code split up by using the generic
unpackPhase and copying it all over into the different outputs.
However, this had the problem of generating the I/O load of about three
times the size of the source tree: First at fetchurl of the tarball
(although it's not as much because it's compressed), second at
unpackPhase and third at installPhase.
Now we don't use installPhase anymore and directly unpack into the
output paths, which unfortunately becomes quite a bit more complex
because we need to transform the paths of the tar file on the fly.
I've also tried using GNU Tar's --to-command option to even untar *and*
patch it at the same time, but forking for every single file in the
tarball gets REALLY slow and also gets even more complex than this two
stage approach because you need to make sure that the patch file is
applied correctly, for example for files that don't yet exist but are to
be created by the patch file.
We're using --anchored and --no-wildcards-match-slash here to prevent
accidentally excluding files we don't want to exclude. One example is
something like v8/tools/gyp/v8.gyp.
So the current approach is some compromise between complexity and speed
and should hopefully get rid of the Hydra build timeouts by lowering I/O
load.
See here for examples of builds having this issue:
http://hydra.nixos.org/build/19045023http://hydra.nixos.org/build/19044973http://hydra.nixos.org/build/19044968http://hydra.nixos.org/build/19045019
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of the updated versions:
stable: 40.0.2214.91 -> 40.0.2214.115
beta: 41.0.2272.16 -> 41.0.2272.64
dev: 41.0.2272.16 -> 42.0.2305.3
Introduces 42.0.2305.3 as the new dev version, which no longer requires
our user namespaces sandbox patch. Thanks to everyone participating in
https://crbug.com/312380 for finally having this upstream.
In the course of supporting the official namespace sandbox (that's what
the user namespace sandbox is called), a few things needed to be fixed
for version 42:
* Add an updated nix_plugin_paths.patch, because the old
one tries to patch the path for libpdf, which is now natively included
in Chromium.
* Don't copy libpdf.so to libexec path for version 42, it's no longer
needed as it's completely built-in now.
* Disable SUID sandbox directly in the source instead of going the easy
route of passing --disable-setuid-sandbox. The reason is that with
the command line flag a nasty nagbar will appear.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
