We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
Years ago I thought I might use it for something, but anything like that
seems very unlikely to ever materialize, so let me focus on packages
that I consider more important.
I made a mistake merge. Reverting it in c778945806b 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: 4effe769e2b
- `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 (803ca85c209)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
I'm sorry; I didn't notice it contained staging commits.
This reverts commit 17f5305b6c20df795c365368d2d868266519599e, reversing
changes made to a8a018ddc0a8b5c3d4fa94c94b672c37356bc075.
bzip2 has been unmaintained for a long time. For a while now, there has
been maintainership, resulting in the release of 1.0.8. At the same
time, there is now a master branch (version 1.1.x) which supports meson
and cmake as build systems.
This commit adds the current HEAD of the master branch (1.1.x). In the
future we may want to use this one instead of the older and patched
1.0.6 we currently have.
Related:
- https://github.com/NixOS/nixpkgs/pull/65029
- https://github.com/NixOS/nixpkgs/pull/94969
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).
The PR was accidentally merged into master instead of staging and thus reverted. Now, in staging, we can re-revert it.
This reverts commit 4df2f78ec72f6a8d2fe286cd34eb3acdfcac81f3.
Should go to staging instead.
This reverts commit f8d9f59abe02ce97f621da24723156934a54611e, reversing
changes made to b27a19d5bf799f581a8afc2b554f178e58c1f524.
The previous CMake version did not run any tests, the current version
tries to run all tests (I could not await their completion), and the
last GNU Make version ran `make -C tests shortest` which ran only
playTests.sh, so I've enabled only the playTests test.
without this fix, binaries report their version number as "vnone"
which for example stops `image_optim` from using `advpng` (refuses
to use it not being able to tell what version number it has)
The release tarball is no longer available at the specified URL, so
building from git. Also, the gnulib in the release tarball was too old
for our recent glibc version.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299