This patch adds the luakit browser. It has to be build using lua5.1, I
tried 5.2 but I couldn't run luakit due to a runtime error with it.
It also uses gtk3 here, override to use gtk2, which should also work.
Suggested-by: Benno Fünfstück <benno.fuenfstueck@gmail.com>
We're propagating the plugin flags by importing from another Nix
expression file, which in turn exports the Nix path to the wrapper. This
causes that the store path isn't referenced in the wrapper and the path
isn't recognized by scanning the wrapper script (only those already
referenced at build time are).
So let's add the activated plugins to the buildInputs of the wrapper.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This brings a new stable version 40.0.2214.91 along with a beta update
to version 41.0.2272.16, the dev channel is still stuck at version
41.0.2272.12 and within the next days will jump to version 42.
For this reason, I've done some cheating here and brought the beta
channel in par with the dev channel, because dev is older than beta on
OmahaProxy.
Here's an overview of the channel upgrades:
stable: 39.0.2171.65 -> 40.0.2214.91 [1]
beta: 40.0.2214.10 -> 41.0.2272.16 [1] [2] [3]
dev: 41.0.2224.3 -> 41.0.2272.16 [1] [2] [3]
[1]: We needed to patch in locations of lib{pci,udev}.so, because
Chromium tries to load them at runtime. For version 41 startup will
fail if it is unable to load libudev, but it also has the advantage
that this fixes GPU detection using libpci in the stable version,
which in turn could fix a few bugs on NixOS.
[2]: The upstream Debian package for the binary plugins now uses XZ
compression for the enclosed data tarball.
[3]: Chromium 41 needs {shapshot,natives}_blob.bin in order to start up,
so let's cp it among with the .pak files to avoid adding a
conditional for version 40.
The release annoucement of the stable channel update can be found here:
http://googlechromereleases.blogspot.de/2015/01/stable-update.html
Note that this release contains 62 security fixes(!) and I'm hereby
apologizing for the delay of this update.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Writing the gid_map is already non-fatal, but the actual sandbox process
still tries to setresgid() to nogroup (usually 65534). This however
fails, because if user namespace sandboxing is present, the namespace
doesn't have CAP_SETGID at this point.
Fortunately, the effective GID is already 65534, so we just need to
check whether the target gid matches and only(!) setresgid() if it
doesn't.
So if someone would run a SUID version of the sandbox, it would still
work nonetheless without a negative impact on security.
Fixes#5730, thanks to @wizeman for reporting and initial debugging.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is more of an attempt rather than a real fix (or maybe it is? let's
see) for the corrupted .pyc files during build. I believe the reason we
get these are likely due to several instances of the Python interpreter
that run in parallel and one of these processes might still be writing
the .pyc file.
So, rather than deleting all .pyc files, we now precompile then in order
to avoid any build process trying to generate any .pyc file.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Also, in case of collectd, the -lgcc_s shouldn't be needed anymore,
as the library is in ${glibc}/lib/ now, which is practically always on RPATH.
In case of seyren it was some stdenv change uncovering the mistake of
putting src into buildInputs.
Thanks to @iElectric for the notification, although I'm not really sure
whether this will fix the following failed Hydra build:
http://hydra.nixos.org/build/17609086/nixlog/1/raw
The reason is that this failure doesn't happen on every build, but let's
see whether it will happen again now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Says: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
CC: #4803. There will likely appear more of these errors on Hydra in time.
