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 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
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 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)
