There is already a pull request from @colemickens, who has just reversed
the variable references $flash and $flashVersion but the fix is kinda
fragile as he points out himself in #12713.
The reason the wrong substition was made is that both variables begin
with the same name and we do a simple replace instead of a more
complicated one using builtins.match.
So staying simple but to still not raising issues with other variables
that begin with the same name I'm now using @var@ instead, like we use
in substituteAll and other substituters (like the ones in CMake or
autotools) deal with it.
Note that I'm not using $var$ here to make sure it doesn't get confused
with real shell variables.
So with this fix in place, the wrapper now has the following flags:
--ppapi-flash-path=/nix/store/.../lib/libpepflashplayer.so
--ppapi-flash-version=20.0.0.294
Previously we had (#12710):
--ppapi-flash-path=/nix/store/.../lib/libpepflashplayer.so
--ppapi-flash-version=/nix/store/...-binary-plugins-flashVersion
Thanks to @colemickens for reporting and putting up a pull request.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #12710Fixes: #12713
This reverts commit f7af2272a2.
We're going to fix#12710 properly by reintroducing 38c77bb and fixing
the shell variable substitution.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Fixes CVE-2016-1612 CVE-2016-1613 CVE-2016-1614 CVE-2016-1615
CVE-2016-1616 CVE-2016-1617 CVE-2016-1618 CVE-2016-1619 CVE-2016-1620.
- Moves chromium stable and beta channels up one version major.
vcunat made dev channel stay for now, as it wouldn't download otherwise.
This is most of PR #12717.
This package is deprecated and superseeded by links2 which also provides the
links binary this maintaining backwards-compatibility.
Debian removed links back in 2008:
https://packages.qa.debian.org/l/links.htmlFixes#12623.
Working on Chromium really drives me nuts due to its build time, also I
really don't have quite a lot of time these days to properly maintain it
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has been introduced by me in 690a845 and discovered by @vcunat in
his comment over at:
690a845de9 (commitcomment-14209868)
It's really a bit ugly to have builds running during evaluation, but
back when I made that commit the reason was to avoid having to shell
quote the hell out of it (see the comment in mkPluginInfo for the
reason).
Now we propagate plugin flags and environment variables as a list of
arguments in a plain file that's appended verbatim to makeWrapper, so
it shouldn't do any builds anymore during instantiation.
I have tested this with both just WideVine and just Flash enabled as
well as both in combination and none of the plugins and the output seems
correct. However I didn't test to run Chromium with the new
implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Vladimír Čunát <vcunat@gmail.com>
I'm not certain about this, so I'm trying for firefox only.
Rationale: it might be confusing to see two firefox-${version} instances
in logs or paths, so I wanted to differentiate them.
- I chose to keep `browser-unwrapped` attributes so that it's much
easier to override parameters for the browser (through `packageOverrides`).
- Aliases `browserWrapper` are retained for now, as usual.
The official repository has last been updated in 2013,
meanwhile there are a lot of issues like non-existant
certificate verification. The debian repository is actively
maintained and already includes most of our custom patches,
so we use it instead.
Fixes#12257, closes#12259.
vcunat appended commit date to version.
- I don't think that amount of code belonged into all-packages.nix.
- Now the default name of the wrapped package is identical
with the command that runs the browser.
- Other defaults were changed according to how the wrapper is
(almost always) used.
- `meta` is improved: mostly inherited with priority above
the unwrapped package.
http://hydra.nixos.org/eval/1234895
The mass errors on Hydra seem transient; I verified ghc on i686-linux.
Only darwin jobs are queued ATM. There's a libpng security update
included in this merge, so I don't want to wait too long.
