checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
See https://github.com/hedning/nix-bash-completions/issues/20.
Even with the low priority on this package, completing `nix-build` will
load the nix-bash-completion for the `nix` command, which is undesirable
since Nix provides its own completion since 2.4.
The maintainer seems unresponsive.
If bash is executed within an environment where PATH is not set, it uses
the DEFAULT_PATH_VALUE compiled into bash to set PATH. In nixpkgs we set
this to /no-such-path by default. This makes sense in a nixpkgs/NixOS
environment since paths like /bin or /usr/bin should not be used.
However, when bash is used inside an FHS environment, this produces
results that differ from distributions which follow the FHS standard.
Before this change:
$ steam-run env -i /bin/bash -c 'echo $PATH'
/no-such-path
After this change:
$ steam-run env -i /bin/bash -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
- make the script runnable from any directory
- add missing nix dependency to run nix-hash
- make padding non implicit
- small shellcheck fixes (variable quoting...)
Readline 8.1 is required for bash-5.1 to work properly.
From bash-5.1 release message[1]:
> Bash can be linked against an already-installed Readline library
> rather than the private version in lib/readline if desired. Only
> readline-8.1 and later versions are able to provide all of the symbols
> that bash-5.1 requires; earlier versions of the Readline library will
> not work correctly.
[1] https://lists.gnu.org/archive/html/info-gnu/2020-12/msg00003.html
When, after patching, `configure.ac` is newer than `configure`, the
Makefile will try to regenerate `configure` from `configure.ac`.
While that might usually be desirable, in this case we want to keep
bootstrapping simple and directly use the `configure` from the package
so we can avoid a dependency on automake.
Previously, we used the `-T` parameter to automake to make sure the
timestamps were okay. However, this is brittle when we update: when the
timestamp of the original file changes, and no longer matches the
timestamp of the original file in the patch, `patch` will show a warning
but otherwise continue without updating the timestamp.
This PR changes things so we only patch `configure`, so that will always
have a newer timestamp.
Refs https://github.com/NixOS/nixpkgs/issues/115177
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
