| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
| |
| |
| | |
hydra.nixos.org/build/3154247
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| | |
stable: 22.0.1229.79 (build tested)
beta: 22.0.1229.94 (build and usage tested)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | | |
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
http://hydra.nixos.org/build/3151653
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 949afcc0f2d82cb00a7f0ca9c0dc4b45f8fe273f.
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>
|
| | | |
|
| | |
| |
| |
| | |
This is a significant update with loads of new features, plugins and GUIs
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This prevented Flash from working after the last update.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems the resulting output path has no reference to libxine, so it
does not get used. Probably it needs some hard-coded link-paths as
eaglemode wants to use dlopen for some things.
If anyone wants to use eaglemode's xine support and fix this issue,
please make it optional.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- big cleanup of optional dependency handling
I hope I didn't miss any cases.
- XVID
xvid support seams broken, both built-in as external.
I didn't notice any issues playing xvid video's though, as ffmpeg's
default mpeg4 decoder handles xvid-encoded files just fine.
It seems the only users affected by this are users who still encode
xvid with mencoder (instead of plain ffmpeg). If this really is an
issue to anyone, please let me know, so I can look into it some more,
or retain an older mplayer version next to this one.
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Though upstream clearly recommends to not deactivate Pango, we currently can't
use Pango right now, as we are stuck at cairo-1.10.2. This version only has
experimental support for XCB which became stable in 1.12.x.
So we need to wait for 21bf5ef509dcadebab10de0ba142d55776a961f1 to be merged
into master before we can enable Pango.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | |
| |
| |
| |
| |
| | |
Tested with a bunch of charon VirtualBox machines.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
New major upstream version, changes can be found here:
https://www.virtualbox.org/wiki/Changelog
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | | |
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
for download. Although, it does not work correctly on my system.
|
| | | |
|