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.
We will update bash-4.4 in a separate PR (but that one has a bigger rebuild
impact so will have to target staging)
Refs #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
The script assumed that `wget` was available in the environment
along with common CA certificates.
Replaced the detection of GPG, which is not necessary anymore.
Added pulling the public key bash releases and patches are signed with,
without which we cannot verify signatures.
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
This reverts commit a85b07cbcb as
executing the tests in parallel makes them flaky. This can be seen very
easily on armv7l machines (and probably other machines that are slower
than common x86_64 machines as well), but is also reproducible on
x86_64.
This fixes#91706.
Currently the tests take an eternity and are also sometimes flaky. By
following upstream in using xdist for parallel test execution we at
least get the feedback cycle down. On my machine that means instead of
running this for ~25min it runs in 1 minute and 10 seconds.
Since 2.9 bash-completion hardcodes paths in pkgconfig file. We want to
be able to override certain paths, so this commit restores the original
behaviour.
https://github.com/NixOS/nixpkgs/issues/71662
