The build was failing on some machines because of a `find` command that
touched files in different orders on different machines.
That confused `make`s timestamp mechanism.
gnuradio-with-packages was not running makeWrapper on any of the
symlinked executables because `find $out/bin -type f -executable`
does not resolve symlinks. I don't understand how the old code
ever worked on any system.
Fixes build failure since recent merge of staging branch:
$ nix-build -A qmmp
[...]
AutoMoc error
-------------
Included moc files with the same name will be generated from different sources.
Consider to
- not include the "moc_<NAME>.cpp" file
- add a directory prefix to a "<NAME>.moc" include (e.g "sub/<NAME>.moc")
- rename the source file(s)
Include conflicts
-----------------
"moc_hotkeymanager.cpp" included in
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager_win.cpp"
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager_x11.cpp"
would be generated from
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager.h"
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager.h"
make[2]: *** [src/plugins/General/hotkey/CMakeFiles/hotkey_autogen.dir/build.make:58: src/plugins/General/hotkey/CMakeFiles/hotkey_autogen] Error 1
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.
Upstream changes without issue IDs:
* GUI: fixed occasional screen corruption when host screen resolution
is changed
* User interface: increase proposed disk size when creating new VMs for
Windows 7 and newer
* User interface: various improvements for high resolution screens
* VMM: Fixed problems using 256MB VRAM in raw-mode VMs
* Audio: implemented support for audio playback and recording for macOS
guests
* Audio: further timing improvements for Windows 10 guests
* Linux hosts: fixed problem accessing mini-toolbar under XFCE
The full changelog including issue IDs can be found at:
https://www.virtualbox.org/wiki/Changelog#v6
What was not mentioned in the changelog is that this release fixes
compiling the VirtualBox modules against kernel 4.15, which was added in
commit 61043ad4d1.
Tested this by running all of the tests in nixos/tests/virtualbox.nix.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @flokli, @svanderburg
