fetchpatch is fetchurl that determinizes the patch.
Some parts of generated patches change from time to time, e.g. see #1983 and
http://comments.gmane.org/gmane.linux.distributions.nixos/12815
Using fetchpatch should prevent the hash from changing.
Conflicts (auto-solved):
pkgs/development/libraries/haskell/gitit/default.nix
1) Packages formerly called haskell-haskell-platform-ghcXYZ-VVVV.X.Y.Z are
now called haskell-platform-VVVV.X.Y.Z. The latest version can be
installed by running "nix-env -i haskell-platform".
2) The attributes haskellPackages_ghcXYZ.haskellPlatform no longer exist.
Instead, we have attributes like haskellPlatformPackages."2012_4_0_0".
(The last numeric bit must be quoted when used in a Nix file, but not on
the command line to nix-env, nix-build, etc.) The latest Platform has a
top-level alias called simply haskellPlatform.
3) The haskellPackages_ghcXYZ package sets offer the latest version of every
library that GHC x.y.z can compile. For example, if 2.7 is the latest
version of QuickCheck and if GHC 7.0.4 can compile that version, then
haskellPackages_ghc704.QuickCheck refers to version 2.7.
4) All intermediate GHC releases were dropped from all-packages.nix to
simplify our configuration. What remains is a haskellPackages_ghcXYZ set
for the latest version of every major release branch, i.e. GHC 6.10.4,
6.12.3, 7.0.4, 7.2.2, 7.4.2, 7.6.3, 7.8.2, and 7.9.x (HEAD snapshot).
5) The ghcXYZPrefs functions in haskell-defaults.nix now inherit overrides
from newer to older compilers, i.e. an override configured for GHC 7.0.4
will automatically apply to GHC 6.12.3 and 6.10.4, too. This change has
reduced the redundancy in those configuration functions. The downside is
that overriding an attribute for only one particular GHC version has become
more difficult. In practice, this case doesn't occur much, though.
6) The 'cabal' builder has a brand-new argument called 'extension'. That
function is "self : super : {}" by default and users can override it to
mess with the attribute set passed to cabal.mkDerivation. An example use
would be the definition of darcs in all-packages.nix:
| darcs = haskellPackages.darcs.override {
| cabal = haskellPackages.cabal.override {
| extension = self : super : {
| isLibrary = false;
| configureFlags = "-f-library " + super.configureFlags or "";
| };
| };
| };
In this case, extension disables building the library part of the package
to give us an executable-only version that has no dependencies on GHC or
any other Haskell packages.
The 'self' argument refers to the final version of the attribute set and
'super' refers to the original attribute set.
Note that ...
- Haskell Platform packages always provide the Haddock binary that came with
the compiler.
- Haskell Platform 2009.2.0.2 is broken because of build failures in cgi and
cabal-install.
- Haskell Platform 2010.1.0.0 is broken becasue of build failures in cgi.
Without this it'll complain and abort when clicking "Take Screenshot" or
"Browse Local" when creating a new VM and looking for an CD-ROM image to boot
from:
GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' is not installed
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>
These packages come with R, but if we install them as part of this build, then
we cannot update them without re-building R as well. Instead, we add those
packages to the R environment through the r-wrapper. This means that
recommended packages can be updated in cran-packgaes.nix, and those updates
have an effect on the installation without re-building R itself.
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 packaging splices off the unfree faac library and forces handbrake
to use the (more recent/patched) versions of libraries in Nixpkgs.
Produces the CLI HandbrakeCLI and optionally the GTK+ version ghb.
This also tweaks the version number to just use the SVN revision (rather
than date), since it's unambiguous and increasing anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
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.
The real path of the schemas is:
$out/share/gsettings-schemas/gsettings-desktop-schemas-3.10.1/glib-2.0/schemas
While the previous approach was to load schemas from:
$out/share/glib-2.0/schemas
So, we're now relying on the setup hook of glib to find the right schema
path.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
If dmenu isn't installed in the user environment, dmenu_run will fail
because it searches $PATH for its own binaries.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Youtube feeds now don't append a "sig" query string argument anymore, so
all those feeds would fail without this patch. For the latter, a pull
request already exists on upstream at pculture/miro#428, so I guess we
can drop our patch upon release of the next new upstream bugfix release.
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>
