ryantm bot updates `psqlSchema` alongside with version: https://github.com/NixOS/nixpkgs/pull/50646, https://github.com/NixOS/nixpkgs/pull/55860
but `psqlSchema` is used to generate `stateDir`. It shouldn't be updated.
Ideally it should be equal to postgresql major version for pg versions,
but we already have deployments in /var/lib/postgresql/11.1. Strange why
nobody complained when it was changed from 11.0 -> 11.1.
I propose do correct naming for PG12+, but status quo for current versions.
Fixes https://github.com/NixOS/nixpkgs/issues/56134
bcf54ce5bb introduced a treewide change to
use ${stdenv.shell} where-ever possible. However, this broke a script
used by dockerTools, store-path-to-layer.sh, as it did not preserve the
+x mode bit. This meant the file got put into the store as mode 0444,
resulting in a build-time error later on that looked like:
xargs: /nix/store/jixivxhh3c8sncp9xlkc4ls3y5f2mmxh-store-path-to-layer.sh: Permission denied
However, in a twist of fate, bcf54ce5bb
not only introduced this regression but, in this particular instance,
didn't even fix the original bug: the store-path-to-layer.sh script
*still* uses /bin/sh as its shebang line, rather than an absolute path
to stdenv. (Fixing this can be done in a separate commit.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Fix a bug that ignores OMPI_MCA_rmaps_base_oversubscribe (upstream patch).
This bug breaks the test from libs, such as scalapack,
on machines with less than 4 cores.
To quote block/Kconfig:
> Builds Logic for interfacing with Opal enabled controllers.
> Enabling this option enables users to setup/unlock/lock
> Locking ranges for SED devices using the Opal protocol.
Without `BLK_SED_OPAL`, it is impossible to resume from sleep when using
a locked self-encrypting drive.
This configuration option appeared in earlier kernels, but only reached
maturity in 4.14 according to discussion at:
- https://github.com/Drive-Trust-Alliance/sedutil/issues/90 and
- https://github.com/Drive-Trust-Alliance/sedutil/pull/190
This kernel option is enabled in the default kernels shipped with
Fedora, Debian, and other mainstream Linux distributions.
The original change in #55372 was supposed to fix the case where a store
path which is a file should be placed into `buildEnv` which broke with a
fairly misleading Perl error.
Unfortunately this introduced a regression, `findFiles` can have targets
that are files if the file isn't a store path. Rather than adding more
obscure checks with probably further regressions, I figured that it's
better to replicate the behavior of `lib.isStorePath` and explicitly
check if the store path is a file and break in this case only.
This should also fix recent staging issues.
