During `8d6502f8ca9` `phonon-backend-vlc` uses QT5 by default.
Rather than fixing this it has been marked as broken as it's currently
unmaintained (see c76ad476b0245c474c057b451ba6fec18e7f81f1)
and broken since March (https://hydra.nixos.org/build/71873808).
For now I've marked it as broken as the last *stable* release is from
2015 (see https://github.com/tomahawk-player/tomahawk/releases/tag/0.8.4).
`minitube` is currently broken transitively due to the broken
`phonon-backend-qt4`: https://hydra.nixos.org/build/76523277
Although QT4 is fairly old, this package is still built with `qt4` ATM,
however QT5 is available as well. After this change, QT5 will be built
by default and in case anybody requires legacy QT4 it has to be enabled
explicitly like this:
```
with import <nixpkgs> { };
phonon-backend-vlc.override { withQt4 = true; }
```
Now the QT5-only build can be used (which fixes `minitube`) and there
are no confusions anymore with the build dependencies. Previously
`phonon-backend-vlc` and `libsForQt5.phonon-backend-vlc` used `qt4` by
default which was likely responsible for broken `minitube`.
Linux 4.16 introduces a stackprotector detection script that returns
different results for the kernel compilation run and the spl/zfs
compilation run, as the setting for hardening are different. This
results in a broken ABI between spl/zfs and the compiled kernel,
breaking ZFS. Also disabling the fortify and stackprotector hardening,
as we do for the kernel, fixes that.
* slurm: 17.11.5 -> 17.11.7, pyslurm: 20180427 -> 20180604
This commit also swaps to use the official repository's github release tags
instead of their download site, which only keeps the most recent version with no
historical archives.
* Document why we don't run tests
* Remove dead testing code
Bazel is a build tool, much like Make and many others. Like Make, it
should be agnostic to the compiler toolchains the user brings into
scope. Bazel has special rules that encode domain specific knowledge
for how to compile a C++ program, or indeed a Java program and a few
others. But that's not to say that at runtime Bazel should assume
a specific C++ compiler or Java compiler anymore than Make does.
The main impact of this change is that packages that build with Bazel
will have to list the compilers they want in their `buildInputs` or
similar, rather than relying on the `bazel` package pulling them in
transitively.
* rpcs3: 0.0.4-8032 -> 0.0.5-6884
* rpcs3: update hash
* rpcs3: 0.0.5-6884 -> 0.0.5-6925
* rpcs3: 0.0.5-6925 -> 0.0.5-6938
* rpcs3: 0.0.5-6938 -> 0.0.5-6980
Manually write version header instead of generating it with git, which required leaveDotGit to be enabled.
This caused some hash mismatches (see #8567) has thus been disabled.
