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.
This is a response to 1fdefd5562.
We are already using bundled protobuf for the beta and dev channels and
it also breaks regularly with about every new Chromium release, so let's
use bundled protobuf for all channels now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We now create Nix expressions within the plugin output path(s) which
then will be imported and incorporated into the wrapper. This makes it
easier for other plugins to provide configuration settings to the main
Chromium wrapper.
Of course, in order to allow for external plugins we need to allow
passing a list of plugins to the Chromium derivation, but right now we
keep it internal and only use it for things such as NaCl (as soon as we
support it, of course).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The Chromium PDF plugin is now available as open source software and is
already included in the Chromium source tree in current stable, so there
is no need to extract it from the Chrome binary package anymore.
See release announcement at http://blog.foxitsoftware.com/?p=641
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Introduces environment variables to set plugin base paths. The schema
for these is like NIX_CHROMIUM_PLUGIN_PATH_<N>. Where <N> is the path
type we want to change, the supported (full) variable names are:
* NIX_CHROMIUM_PLUGIN_PATH_ALL
* NIX_CHROMIUM_PLUGIN_PATH_PEPPERFLASH
* NIX_CHROMIUM_PLUGIN_PATH_FILEFLASH
* NIX_CHROMIUM_PLUGIN_PATH_PDF
* NIX_CHROMIUM_PLUGIN_PATH_FILE_EFFECTS
* NIX_CHROMIUM_PLUGIN_PATH_NACL
* NIX_CHROMIUM_PLUGIN_PATH_PNACL
* NIX_CHROMIUM_PLUGIN_PATH_WIDEVINE
Whereas NIX_CHROMIUM_PLUGIN_PATH_ALL is the plugin base path for every
path which is not set explicitly, so by setting ..._ALL and not setting
..._WIDEVINE, the widevine plugin will be searched in the directory
specified using ..._ALL.
Right now, the only plugin where this is used is widevine, and it still
doesn't properly work yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 38.0.2125.101 -> 39.0.2171.65
beta: 39.0.2171.19 -> 40.0.2214.10
dev: 40.0.2182.3 -> 41.0.2224.3
We can now remove missing_alg_import.patch, because version 39 is nom
stable and thus fixes the missing include directive upstream.
However, starting with version 40, we hit a few bugs with system
protobuf, so we're disabling it for every version >=40 to avoid
runtime/startup errors.
Here is the stable channel announcement for version 39 on the official
blog:
http://googlechromereleases.blogspot.de/2014/11/stable-channel-update_18.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Seems to be needed in order to view Netflix content, but this only pulls
in the proprietary plugin and doesn't yet compile Chromium with support
for it, so this is only in preparation for the bright and shiny future
(where we all have rootkits implanted in our body).
Of course, this plugin is disabled by default as well as all the other
proprietary plugins.
For the plugin derivation, we now do the checkPhase _after_ the
installPhase, to make sure we also detect RPATHs pointing to the plugin
directory itself, because the shared object files only exist after the
installPhase.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 37.0.2062.94 -> 37.0.2062.120
beta: 38.0.2125.24 -> 38.0.2125.101
dev: 39.0.2138.3 -> 39.0.2171.7
All channels built fine on my machine and were tested against a few
sites.
The missing_alg_import.patch now is no longer needed for version 39, so
we're not applying it there anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 36.0.1985.125 -> 37.0.2062.94
beta: 37.0.2062.58 -> 37.0.2062.94
dev: 38.0.2107.3 -> 38.0.2125.8
All channels built fine on my machine and were tested against a few
sites.
Stable and beta channel now contain the same release, because version
37 hit the stable channel. For release notes, please have a look at the
announcement:
http://googlechromereleases.blogspot.de/2014/08/stable-channel-update_26.html
Of course we're also dropping all version 36 specific crap, such as the
architecture-specific target suffix for builds, which now is no longer
needed.
The gyp flag use_mojo=0 is no longer needed, as it was a workaround
concerning version 37.0.2054.3 only.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We no longer need to supply compiler and binutils to the build process,
se we can safely remove them. In addition, we're now passing the new
options linux_use_gold_binary and linux_use_bundled_gold to gyp, for
details, see:
https://codereview.chromium.org/239163003
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
beta: 37.0.2062.44 -> 37.0.2062.58 (builds fine, tested)
dev: 38.0.2101.0 -> 38.0.2107.3 (builds fine, tested)
Drop patch for fixing angle build for the dev version, because it was
applied upstream already.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 35.0.1916.153 -> 36.0.1985.125
beta: 36.0.1985.84 -> 37.0.2062.44
dev: 37.0.2054.3 -> 38.0.2101.0
All builds were successfully tested on my machine, however in order to
update the beta and dev channels, a few additional modifications were
necessary:
* Don't update address_input_strings.grdp anymore because this has been
done/fixed upstream and was relevant in version 37.0.2054.3 _only_.
* No need to fix references to /usr/bin/gcc in version 38 anymore.
* Constrain patch for Angle (introduced in 4cbedd7) to version 37 only,
because it already has been applied upstream in version 38.
* Drop user namespaces patch for version 31 up until version 35,
because version 36 is already in stable.
* Don't try to build bundled Clang and/or even build using Clang.
* Remove obsolete patchPhase commands that are specific to version 35
and older.
While testing the dev version 38 I came accross a font rendering issue
which needs to be addressed ASAP (perhaps related to #3187), however the
browser works otherwise.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Verified working with Firefox, however it still doesn't work with
Chromium because of the NPAPI vs PPAPI thing.
Chrome's Pepper Plugin API doesn't seem to look for
plugins in the MOZ_PLUGIN_PATH, anyway I left them there for others to
find the solution :-)
This is because of a single file that symlinks to the source output
path:
libexec/chromium/resources/extension/demo/library.js
Target within source output path:
chrome/browser/resources/extension_resource/demo/library.js
So we just need to ensure that the cp command follows symlinks during
installPhase and we should no longer have this unnecessary dependency.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
After refactoring the updater we no longer did properly propagate the
exit code from the nix-prefetch-url call to the main script. So if the
newest version could not be fetched it didn't even bother to try the
previous release and we would end up with an empty hash.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 35.0.1916.114 -> 35.0.1916.153
beta: 35.0.1916.86 -> 36.0.1985.67
dev: 36.0.1964.2 -> 37.0.2054.3
All builds successfully tested on my machine, however in order to update
the beta and dev channels, a few additional modifications were
necessary:
* Update/rebase USER_NS sandbox patch for version 36 and higher.
* Create address_input_strings.grdp before running gyp in version 37.
* Remove an empty string leftover from 0517041.
* Add patch for building bundled Angle for version 37.
The patch for Angle is to remove reliance on git being present during
build and is from https://chromium-review.googlesource.com/202048 but
with own modifications to remove/fix Windows-specific parts within the
patch file.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's ensure we do all architecture-dependant stuff inside
mkChromiumDerivation and not pass archInfo around, so we can properly
decouple it from the main function.
This partially reverts 8d54dc6d13.
The main reason for doing this is because the architecture information
is no longer required in Chromium 37, so let's uglify and XXX it in
common.nix and remove it once version 37 hits the stable channel.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This fixes build for version 36, which i accidentally broke in commit
f6e31fadd8.
The reason this happened, was that my Hydra didn't pick up the latest
commit and I actually tested and built the parent commit instead of the
update commit.
So, this commit is the real "builds fine, tested" for all channels.
Also, the sandbox client initalization has moved into
setuid_sandbox_client.cc, so we need to move the lookup of the
CHROMIUM_SANDBOX_BINARY_PATH environment variable there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The system attribute was already there in the function head of the
shared update helper but it actually wasn't used and thus later the
import of <nixpkgs> was done using builtins.currentSystem instead of the
system attribute inherited from the source derivation.
Now we correctly propagate the attribute, so that even when running a
64bit kernel you can run a 32bit Chromium with binary plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This fixes the issue of Chromium not being able to load the pulseaudio
librarp
We could also propagate the build inputs, but it would end up being the
same as just directoly linking against the library.
Thanks to @aristidb for noticing this in #2421:
https://github.com/NixOS/nixpkgs/pull/2421#issuecomment-42113656
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should fix the desktop icon location for both desktop entries (the
one from the Chromium derivation itself and the wrapper) and renames the
name of the file so that it gets overridden by the wrappers desktop item
so we don't end up having two of them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This implements some longstanding work of getting the Chromium
derivation more modular. Unfortunately, I didn't manage to decrease the
compile time, which was one of the primary goal for doing the refactor.
A main reason this didn't work out well was the fact that most bundled
libraries are so heavily patched that it's not possible within a limited
time frame to decouple it from the main derivation.
However, it should now be easier to build other derivations that build
upon Chromium, like libcef. Also, it finally adds support for the
non-free PepperAPI Flash and PDF plugins and support for fetching the
corresponding versions through the updater.
The packageName attribute defines the output path and binary name of the
product that's going to be created, so we really want to have "chromium"
instead of "chromium-browser" here, especially for the resulting binary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already have a desktop icon from the browser wrapper, so this is only
for people who do not use the wrapper (for example if you don't want to
use Mozilla plugins).
Also, we someday might want to propagate the desktop item to the browser
wrapper as well.
Conflicts:
pkgs/applications/networking/browsers/chromium/default.nix
Yes, it's just a comment and yes, it's so insignificant that everyone
would make a "O_o" face. But I'm getting annoyed by things like this.
Obviously that means no feature changes :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is to ensure that nothing unexpected will be after the merge of the
refactoring branch, and also my own autoupdate machinery is expecting
this location, so there really is no reason to change it now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
beta: 34.0.1847.60 -> 35.0.1916.47 (builds fine, tested)
dev: 35.0.1883.0 -> 36.0.1941.0 (builds fine, tested)
For the new version 36, we needed to rebase our user namespaces sandbox
patch, because http://crbug.com/312380 is preparing for an upstream
implementation of the same functionality.
Also, we need to add ply and jinja2 to the depends on version 36. This
is done unconditionally, because I want to avoid cluttering up the
expressions with various versionOlder checks.
The sandbox binary had to be fixed as well and we no longer use system
zlib, as - who might have guessed it - it's a fast moving target at
Chromium as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The version of v8 to use for Chromium is heavily tied to the specific
version of Chromium and thus it doesn't really make sense to use v8 from
<nixpkgs>, as we would need to have 3 different versions of v8, one for
each Chromium channel.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It doesn't make sense to do the splitting of the source code on a remote
machine, so don't try to do it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This results in a new function called mkChromiumDerivation, which can be
used to easily build packages that are based on the Chromium source
tree.
We pass through this function as mkDerivation in the chromium wrappre,
so in the end if you want to create such a package, something like:
chromium.mkDerivation (base: {
name = "your-shiny-package-based-on-chromium";
...
})
will suffice.
Of course, this is only the first step towards this functionality,
because right now I'm not even sure the Chromium browser itself will
build.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This now uses the Debian package from the sources derivation instead of
hardcoding it, so we finally should have proper PepperAPI plugin support
without crashing plugins and whatnot.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This cases the Debian binaries to be fetched from Google's official APT
repository. If we aren't able to find a package from the APT repository,
it's very likely that it already got deleted upstream and we need to
fallback to mirrors instead.
Unfortunately, we can't use mirrors for updating, because Google doesn't
sign the Debian packages themselves and only the release files.
We're going to hook it into a Chromium updater soon, making the sha256
hashes publicly available, so if it is missing, we can still put the
sha256 manually into sources.nix, without risking anything by blindly
fetching from one of the provided mirrors.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The updater is now splitted between a shellscript and a Nix expression
file which contains helpers and lookup functions to reconstruct all
information needed in order to fetch the source tarballs.
This means, that the sources.nix now doesn't contain URLs and only
versions and the corresponding SHA256 hashes. Of course, right now this
sounds like it's unnecessary, but we're going to fetch binaries soon so
it's a good idea to not unnecessarily clutter up sources.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Next, we're going to refactor update.sh and the first step is to ensure
that we keep everything related to sources into its own subdirectory to
not clutter up the main directory too much.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We don't want ta have the source derivation in the runtime dependencies
of the browser itself. Also, we've broken the Firefox wrapper, because
we've no longer exposed the packageName attribute.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm giving up on this after several attempts to correctly unbundle the
largest part, namely Google's WebKit fork Blink. Right now it's so much
tied into the Chromium source it's going to be fairly hard to do if
you're not working full time on it.
Also, the intermediate steps needed to do this properly would introduce
uneccesary complexity on our side, so we really need to finish this
without leaving it in the "messy" state in order to not make Chromium
even more difficult to maintain than it is already.
However, anyone who wants to proceed on this messy step is free to
revert this commit and continue doing so. In my case I'm going to try
again once https://crbug.com/239107 and https://crbug.com/239181 are
fixed in _stable_ (I don't want to introduce *lots* of conditionals on
the version either).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We obviously don't want the Hydra job of nixpkgs to fail, so we need to
make sure that we have a proper meta attribute on the outermost
derivation.
For builds based on the Chromium source tree (like for example libcef),
we can still move the wrapper elsewhere when we need it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is because of our symlink mess, as Chromium's build support scripts
are trying to resolve everything based on absolute paths and we split
off the bundled sources from the main derivation.
Yes, I'm refering to this as a mess, because in the end, we're going to
patch up the gyp files and use references someday.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now, we no longer tie the sandbox directly to the browser derivation but
wrap everything together into one derivation at the entry point at
default.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far we just copied everything from source.* into the build directory
during the prePatch. This somewhat defeated the purpose of the source
splitup because it involved more I/O than just unpacking the entire
source tree.
Now, we're selectively *symlinking* the bundled sources into the build
directory. Even that isn't perfect because in the end we'd just
reference foreign derivations and we're done. But for now, this gets us
at least prepared for a massive reduction of compile time.
Unfortunately, gyp's behaviour when it comes to symlinks is quite
painful to come by, so we need to fix a few references to use absolute
paths.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We now no longer pass enablePepperFlash and enablePepperPDF to the
browser package itself and only use plugins.flagsEnabled from there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This currently only passes through the arguments and is nothing more
than the foundation of the new structure. In essence, I want to have a
really small default.nix which is then going down into the respective
subparts that are isolated from each other.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is hardcoded for the dev channel at the moment and we're going to
fetch it along with the main Chromium sources.
Also I'm putting this in default.nix at the moment, because we're going
to tear apart the whole Chromium package into several subparts soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We currently can't build the -lite package because beta and dev versions
aren't yet compatible with ICU version 52. But apart from that blocker,
this should get us ready for the switch.
Also, we're now correctly unbundling all dependencies which are used
from <nixpkgs>.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Starting with version 35, version 2 of libgnome_keyring is no longer
supported and it's probably pretty useless to do backports to version 2,
given the assumption that most users on Nix probably don't use it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Okay, now this time we really broke beta and dev, because python_arch no
longer is in build/common.gypi anymore.
This just adds chrome/chrome_tests.gypi to the list of files to be
changed by sed.
Also, this time I did test at least whether gyp is running fine and
interrupted after the first 1000 build targets, so all channels *should*
now build fine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Build failure on Hydra:
https://hydra.nixos.org/build/9823160
This was caused by the update of file in 5885709.
As file seems to be used for only one substition in the gyp files, we
can now drop the build dependency on file and patch out the substition
expression, as it is done before actually testing if the value has been
set by -D (gyp, y u no have lazy eval!?).
PS: Proudly untested against beta and dev channels, redeployed my own
Hydra and building on my workstation here really is ... annoying (lavg
41 on a system with nproc 8, less than 8 GB RAM and you probably will
have as much "fun" as I just had writing this commit mess...a....g
FUCK^H^H^H^H^H^H...e).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since version 34, ICU data files are now created separately and thus
need to be installed as well.
Closes#2016
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit f117341ff2de4b95d223b41b36942e2f60ada2a3)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This closes#1623, and updates _all_ channels to the corresponding
latest upstream versions.
Thanks to @wizeman for opening the pull request noted above and for
another update in between, @aristidb for fixing the patcheShebangs issue
and @shlevy for notifying me about the build failure in stdenv-updates
in the first place.
Sorry to everyone for my inactivity lately.
The following changes were needed in order to build those new releases:
* Patch out /bin/echo to allow building with all options enabled.
* Always use GN from the source tree.
* Remove import of depot_tools for version 34.
* Drop version 32 specific stuff.
With this commit, the following new upstream versions are introduced:
stable: 32.0.1700.77 -> 32.0.1700.102 (builds fine, tested)
beta: 32.0.1700.19 -> 33.0.1750.46 (builds fine, tested)
dev: 33.0.1712.4 -> 34.0.1809.0 (build broken with gnome_keyring)
The dev version requires a more recent version gnome_keyring and thus
won't build if gnomeKeyringSupport is set to true. I haven't tested this
build without gnomeKeyringSupport yet, so it might be broken and will be
fixed later.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>