The new version is the one already committed in trunk as revision 160697.
In order to get into beta and stable this could take some while so we're going
need to carry around that patch for some time.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This dependency has recently been added to chromium while we didn't notice it,
so let's avoid to use the bundled version.
It might make sense to remove the unneeded files in third_party/ based on a
whitelist, so that we notice future changes like this earlier.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
While libexif has been bundled with chromium for some months already, they only
recently added the GYP option to switch to using the system library. So, let's
enable it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Version 22 is the current version of the stable channel, so we don't need to
carry around a patch for earlier versions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This removes the patch introduced in 949afcc0f2.
The reason behind this is because even though we patch in the legacy seccomp
sandbox by default, it won't be used anyway as both cannot coexist anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is just a temporary fix and will only thrown away as soon as a proper fix
is included upstream, see http://crbug.com/149834 for more details about this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
dev: 23.0.1271.10 -> 24.0.1284.2 (not tested, probably won't build?)
beta: 22.0.1229.91 -> 23.0.1271.17 (issues, see below)
While testing the beta release, I've been bitten by http://crbug.com/149834, so
as this is a beta release, I'm not sure if we should patch again to disable the
BPF seccomp sandbox.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The BPF renderer sandbox is now the default in 23. But still, it is not regarded
as "adequately sandboxed" from Google so we still need the legacy seccomp
sandbox.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Well, after looking a bit more thoroughly through the zlib patch from the
Chromium team, it seams, that this really fix an issue that hasn't yet been
applied upstream. Unfortunately neither Chromium nor Zlib give more information
about that issue. Maybe they're waiting until its resolved upstream and thus the
temporary patch?
The bad news is, that the fix for the vulnerability is incomplete in Chromium
and covers only the use cases of Chromium itself, so we can't include that
patched version in nixpkgs zlib derivation.
Until the issue is fixed upstream we're hereby safer off turning it off in
Chromium and thus use the bundled and patched version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
dev: 23.0.1271.10
beta: 22.0.1229.91
stable: 22.0.1229.79
The revert for SVN revision 151720 is now obsolete in the current beta release
and is only needed for the stable version. So let's hope that >= 22.0.1229.91
will get stable soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 22.0.1229.56
dev: 23.0.1262.0
Patch for http://crbug.com/143623 still applies and is still not fixed upstream.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This introduces the following changes:
* Fixes libPrefix in Tcl libraries I fucked up a few months ago and adds
missing meta attributes.
* Correctly set TKABBER_SITE_PLUGINS so Tkabber is able to find plugins, if
present.
* Rely on OPENSSL_X509_CERT_FILE instead of depending on cacert directly.
* Introduces a new license called "Tcl/Tk", which applies to some Tcl libraries
and is a variation of the BSD license with restrictions regarding
governmental use.
* New package tclgpg for GPG support in Tkabber.
SVN revision 151720 breaks the build with system zlib, see:
http://src.chromium.org/viewvc/chrome?view=rev&revision=151720
The issue here is, that r151720 introduces changes directly in zlib, which
aren't upstream and unfortunately there is no more information stating the exact
reasons for this change, as all references to it are not publicly available:
http://crbug.com/139744https://chromiumcodereview.appspot.com/10837057
So for the moment, we're going to add a patch, which applies to v22 and higher,
which essentially reverts r151720, until either more information on the issue is
available or it is resolved upstream.
As someone has already reported the issue, we just need to track the following
issue:
http://crbug.com/143623
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm personally not using mouse/gpm support for w3m, because I find it somewhat
too awkward when copy/pasting text. But maybe there are users out there who want
to have it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This builds the w3m image helper with fbcon support if the derivation is called
with graphicsSupport set to true. This change shouldn't break anything as
graphicsSupport is disabled by default, so in any case it could only break
things for users explicitly passing the attribute.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This gets rid of the dependency on cacert and ensures that Tkabber will read
OPENSSL_X509_CERT_FILE whenever the sslcacertstore is not set by the user in
Tkabber's options.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should now point to the path for the tkabber plugins package, which will be
used as soon as the tkabber-plugins derivation is available as a symlink in the
user's environment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
