Regression introduced by 943592f698.
The lib attribute isn't in scope here, so we need to use pkgs.lib
instead for isFunction.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @shlevy
After effa9e4045, which switched to Meson,
the Vala bindings were not built which broke Shotwell. Enabling Vala
was not enough due to a bug, though, so we have to patch it.
Provides an app to view battery and power statistics. This app is badly
documented on the web, but is in the default Fedora install; hence to
motivation to add it to Nix.
Otherwise the build fails to detect libusb and doesn't build
the 'xpwn' and 'dfu-util' tools.
New tools run but I don't have any suitable devices to test :).
(I believe latest iGadgets need a newer version of xpwn anyway)
Since firefox 58.0.1 the google api key is now stored at an absolute
path ($TMPDIR/ga). Since variable expansion in `configureFlags` does not
really work (as expected) the build started failing when using the
legacy firefox build system. With the newer `./mach` based builds
firefox reads the configure flags from `.mozconfig` instead.
This commit moves the `with-google-api-keyfile=` setting into the
`preConfigure` phase where we can properly expand `$TMPDIR` into
whatever the path is.
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-346372756 we
have permission to use the official firefox branding.
Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
