Previously idris used the C compiler from PATH for the C backend, which
means that the results and whether it even succeeds can vary between
systems (e.g. if a Nix-built Idris was used on a super old Linux system,
the cc installed there might not even work for Idris' C).
To make this more predictable, this commit sets the IDRIS_CC env var,
which Idris will prefer over searching in PATH, to a Nix-provided gcc
executable, given that it is not already set, so it's still possible to
override.
The order of sudoers entries is significant. The man page for sudoers(5)
notes:
Where there are multiple matches, the last match is used (which is not
necessarily the most specific match).
This module adds a rule for group "wheel" matching all commands. If you
wanted to add a more specific rule allowing members of the "wheel" group
to run command `foo` without a password, you'd need to use mkAfter to
ensure your rule comes after the more general rule.
extraRules = lib.mkAfter [
{
groups = [ "wheel" ];
commands = [
{
command = "${pkgs.foo}/bin/foo";
options = [ "NOPASSWD" "SETENV" ];
}
]
}
];
Otherwise, when configuration options are merged, if the general rule
ends up after the specific rule, it will dictate the behavior even when
running the `foo` command.
Since 772eef9168, the Boost package
doesn't support Python by default anymore, so we need to override it
with Python support because --enable-python-binding is enabled by
default in libtorrent-rasterbar.
The build of the package now succeeds again on my x86_64-linux machine.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @phreedom
Since 772eef9168, Boost by default doesn't
support Python anymore, so we need to override it with Python support.
Signed-off-by: aszlig <aszlig@nix.build>
Since 772eef9168 Boost no longer has
Python support enabled by default, so depending on whether Ledger has
Python support built in we also use either Boost with Python support or
without.
Tested building with and without Python support and both builds now
succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @the-kenny, @jwiegley
Since the exposure of the version attribute done in
892a0e8ff4, the OpenBLAS build fails for
i686-linux:
https://nix-cache.s3.amazonaws.com/log/wi79zyfmwdpwx7bm29dzqh4vglx3x550-openblas-0.3.0.drv
According to @edolstra the build slaves of Hydra updated to a new
kernel, which seems to be the real cause for this issue. The latter is
already tracked upstream[1] and a fix[2] is already included in version
0.3.1.
This very update cases 4795 rebuilds across all architectures we
support, so it's still not significant enough to go through staging. In
addition the number of rebuilds doesn't include the amount of builds
that are currently failing.
My original idea was to add a patch just for fixing this on i686-linux
and do the real update via staging, but the amount of rebuilds still is
in an acceptable range IMO and @edolstra agreed on that on IRC.
[1]: https://github.com/xianyi/OpenBLAS/issues/1575
[2]: https://github.com/xianyi/OpenBLAS/pull/1583
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
Silvan Mosberger