Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path. Unfortunately the mkDerivation attributes of signon override
the whole configurePhase, so this hook isn't run at all.
This fixes the build of signon and it now successfully compiles on my
machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path. Unfortunately the mkDerivation attributes of libkeyfinder
override the whole configurePhase, so this hook isn't run at all.
This fixes the build of libkeyfinder and it now successfully compiles on
my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path. Unfortunately the mkDerivation attributes of accounts-qt
override the whole configurePhase, so this hook isn't run at all.
This fixes the build of accounts-qt and it now successfully compiles on
my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path.
As the configurePhase is replaced by a qmake path directly from qtbase,
it won't work because the setup-hook from qtbase needs to do some setup
in order for qmake to find its own data files.
So instead of hardcoding that path, we just go for setting the
configureFlags attribute and replacing which with "type -P" so that the
configure script can figure out the right path to qmake on its own.
This fixes the build of libcommuni and it now successfully compiles on
my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path. Unfortunately the mkDerivation attributes of qmltermwidget
override the whole configurePhase, so this hook isn't run at all.
This fixes the build of qmltermwidget and it now successfully compiles
on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path. Unfortunately the mkDerivation attributes of qwt override
the whole configurePhase, so this hook isn't run at all.
This fixes the build of qwt and it now successfully compiles on my
machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 0055c6a introduced a new preConfigure hook that sets the right
qmake path. Unfortunately the mkDerivation attributes of quazip override
the whole configurePhase, so this hook isn't run at all.
This fixes the build of quazip and it now successfully compiles on my
machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Mainly done because of this in all-packages.nix:
````
cipherscan = callPackage ../tools/security/cipherscan {
openssl = if stdenv.system == "x86_64-linux"
then openssl-chacha
else openssl;
};
````
... and inside cipherscan we want to refer to `openssl.bin`
This fixes CVE-2016-1283, which allows remote attackers to cause
a denial of service (heap-based buffer overflow) or possibly
have unspecified other impact via a crafted regular expression.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1283
From https://lists.freedesktop.org/archives/wayland-devel/2015-November/025486.html
The purpose of this repository is to decouple Wayland
protocol development from the implementation in weston. wayland-protocols will
have its own releases not coupled with with wayland/weston releases and
will not carry any implementations.
This one particular cmake directory seems not created by the build.
Skimming Hydra's status, this probably never worked since 35f33b438c.
/cc @ttuegel.
One can build pcl with vtk, qt4, and libXt set to null iff libpng is
explicitly listed as a dependency.
pcl's build system is happy to proceed without those GUI-related
packages as long as libpng is available.
The hand-rolled iterator declaration is incompatible with libc++'s, and
clang > 3.5 is stricter about this.
See
<https://lists.freebsd.org/pipermail/freebsd-ports-bugs/2014-December/298242.html>
for another reference to this issue.
The errors that occur are of the form:
reference to 'random_access_iterator_tag' is ambiguous
skalibs:
execline:
s6-dns:
s6-networking:
s6-portable-utils:
s6-rc:
s6:
The above software uses the target triplet from `cc -dumpmachine` as a
binary compatibility check. However, on darwin, the output includes the
darwin version number, which leads to build failures against a binary
skalibs package built a different version of darwin than the current
system.
Explicitly setting target ensures code can be compiled against a skalibs
binary built on a different version of darwin.
See http://www.skarnet.org/cgi-bin/archive.cgi?1:mss:623:heiodchokfjdkonfhdph
