The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
libexpat 2.6.0 introduced fix for performance issue on some of the
inputs along with tests that check the parsing performance.
Unfortunately, the first implementation of the test case relied on the
clock() function to check if the performance is good enough, resulting
in flakiness on some of the platforms (eg. aarch64-darwin).
https://github.com/libexpat/libexpat/pull/817 fixes tests, but it is not
released yet. This commit brings that PR as a patch.
The configure phase of `stdenv` now runs `patchShebangs` on
`configureScript`.
Did not remove `patchShebangs` in packages which override `configurePhase`
Header & library path constructions in CMake modules expect them to reside under the same prefix as the CMake files.
This assumption doesn't work with our multiple outputs so we patch the library path to the correct output.
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
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
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).
In anticipation of what I outline in #33599, I only simplify exactly those
`doCheck`s which are equal to `hostPlatform != buildPlatform`. I also stick a
comment next to them so I can grep for them later.
