This requires a bit of fiddling with the ldflags patches and reworking a few
things about how the SCM info is configured. Ideally, not much more will change
before the 6.0 release, I think...
This also upgrades all FoundationDB packages to use the ordinary libressl
expression (which is now at 2.7.x), and changes around a few other things,
which will require a rebuild.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
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 772eef91686974b7710081a9a77e5c0e287c25e8, 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 772eef91686974b7710081a9a77e5c0e287c25e8, 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 772eef91686974b7710081a9a77e5c0e287c25e8 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
892a0e8ff40e8282fb09ee6c8a132979c5539191, 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
