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>
- To fix build problems, I refactored the build process
according to Mozilla recommendations.
- 31.0 should become the next ESR branch (31 released today).
CC @nbp @edolstra
(cherry picked from commit adc2edd5cf524239690b5cf49779a11fd2eb061b)
This reverts commit bdb77826d98544ab37741f740dd3516023924b27.
Jack1 is not obsolete and neither jack1 nor jack2 is called 'jackaudio'.
Q: What's the difference between Jack1 and Jack2?
A: http://trac.jackaudio.org/wiki/Q_differenc_jack1_jack2
Unfortunately they've changed their build system to be makefile-only and
they don't seem to include test cases in the CLI anymore, so we needed
to adapt accordingly. Also added freealut and openal to the buildInputs,
in order to allow audio support.
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>
Currently, we have a 'jack' package with attrname 'jack1d' and a
'jackdbus' package with attrname 'jackaudio'. Make it consistent 'jack1'
and 'jack2' in both package name and attrname.
This aligns the naming with what can be found on the JACK homepage.
Q: what's the difference between jack1 and jack2?
A: http://trac.jackaudio.org/wiki/Q_differenc_jack1_jack2
- To fix build problems, I refactored the build process
according to Mozilla recommendations.
- 31.0 should become the next ESR branch (31 released today).
CC @nbp @edolstra
This includes another source-only derivation for the web interface (and
patches the path into the twister binary), so there shouldn't be a need
to move it into ~/.twister/html separately.
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 :-)
The following warning was shown when I clicked on links:
'GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.'
This commit rewrites the expression somewhat:
- it tries to simplify the expression.
- it changes from fetchurl to fetchhg.
- a patch to configure.ac is added in order to enable configuring the
source on NixOS.
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 8d54dc6d13ac3b42e45d95a2cfb971e7c01ad39c.
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>
The "Application.ini" provided with Thunderbird does not correctly set the path to the icon location. Visa vi it refers to '$out/lib/thunderbird-17.0.11esr', which doesn't exist, but '$out/lib/thunderbird-17.0.11' does. To remedy this problem I added a new variable called 'verName" which adds 'esr' after the variable '$version'. Then change the variables necessary so that the build process sets working references.
Fuuzetsu suggested putting the verName variable inside of mkDerivation. I cannot surmise.
HipChat (or rather its copy of Qt) expects to find keyboard data in
/usr/share/X11/xkb. So use a LD_PRELOAD library to intercept and
rewrite the Glibc calls that access those paths. We've been doing the
same thing with packages like Spotify, but now this functionality has
been abstracted into a reusable library, libredirect.so. It uses an
environment variable $NIX_REDIRECTS containing a colon-separated list
of path prefixes to be rewritten, e.g. "/foo=bar:/xyzzy=/fnord".
This fixes build for version 36, which i accidentally broke in commit
f6e31fadd80486cdd68e3ad3d7ae888aa81400b9.
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>
What this allows us to do is define a "dumpcap" setuid wrapper in NixOS
and have wireshark use that instead of the non-setuid dumpcap binary
that it normally uses.
As far as I can tell, the code that is changed to do lookup in PATH is
only used by wireshark/tshark to find dumpcap. dumpcap, the thing that's
typically setuid, is not affected by this patch. wireshark and tshark
should *not* be installed setuid, so the fact that they now do lookup in
PATH is not a security concern.
With this commit, and the following config, only "root" and users in the
"wireshark" group will have access to capturing network traffic with
wireshark/dumpcap:
environment.systemPackages = [ pkgs.wireshark ];
security.setuidOwners = [
{ program = "dumpcap";
owner = "root";
group = "wireshark";
setuid = true;
setgid = false;
permissions = "u+rx,g+x";
}
];
users.extraGroups.wireshark.gid = 500;
(This wouldn't have worked before, because then wireshark would not use
our setuid dumpcap binary.)
This makes running wireshark (or more specifically, dumpcap) as root a
bit more secure. From <wireshark-1.11.2>/doc/README.packaging:
The "--with-libcap" option is only useful when dumpcap is installed
setuid. If it is enabled dumpcap will try to drop any setuid privileges
it may have while retaining the CAP_NET_ADMIN and CAP_NET_RAW
capabilities. It is enabled by default, if the Linux capabilities
library (on which it depends) is found.
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>
