This update was generated by hackage2nix v20160406-9-g3afe33e using the following inputs:
- Hackage: f392208d72
- LTS Haskell: 4d628b7b7e
- Stackage Nightly: 7135a992a4
asciidoctor-latex: 1.5.0.6.dev -> 1.5.0.8.dev
See NixOS/nixpkgs/pull/15135#issuecomment-216984749
This optional dependency may be removed if this happens too often
Without this notify-osd fails to find dbus-binding-tool, since the
pkgconfig file would contain e.g.:
````
prefix=/nix/store/hxsbjbjn7g1j1cf60n228yi9wnzrl4yk-dbus-glib-0.104
exec_prefix=${prefix}
````
... and notify-osd is using `exec_prefix` to locate the binaries.
Set it to $dev to match the location of installed binaries (we have
`outputBin = "dev";`).
Issue #15074.
Regression introduced by f28b71023c.
Let's now expose and use the upstream-info attribute via the main
Chromium derivation, so that other packages like the google-chrome
package doesn't need to rely on internals of the Chromium
implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This effectively resets the attributes given at the point the main
<nixpkgs> is imported and thus for example is also reading in stuff like
~/.nixpkgs/config.nix again, which might lead to unexpected results.
We now only import <nixpkgs> now if the updater is auto-called (like in
update.sh), otherwise the required attributes are passed by callPackage
within the Chromium scope.
I remember noting about this a while ago either on IRC or on GitHub, but
I can't find it right now, so thanks to @obadz for reminding me about
this in #15225.
Tested this by running the updater and also using:
NIXPKGS_CONFIG=$(pwd)/broken.nix nix-instantiate --arg config {} -A chromium
The contents of broken.nix were:
EVALERR{
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #15225
Just removing the system argument because it doesn't exist (it's
actually config.nixpkgs.system, which we're already using). We won't get
an error anyway if we're not actually using it, so this is just an
aesthetics fix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Make sure that we always have everything available within the store of
the VM, so let's evaluate/build the test container fully on the host
system and propagate all dependencies to the VM.
This way, even if there are additional default dependencies that come
with containers in the future we should be on the safe side as these
dependencies should now be included for the test as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @kampfschlaefer, @edolstra
