And also the following refactoring:
hare:
1. Replace `NIX_BUILD_TOP` usage with `mktemp`
2. Enable parallel building
3. Get rid of `config-template.mk`, by using `makeFlagsArray` instead
4. Move `wrapProgram` call to `postFixup`
5. Set the `LOCALVER` environment variable to `nix`, so that the `hare
version` command outputs `dev-nix`[1]
6. Set `meta` attribute `mainProgram`
7. Make the package accessible through `all-packages.nix` instead of
`aliases.nix`
8. Move package path from `pkgs/development/compilers/hare/hare` to
`pkgs/development/compilers/hare`, since the scope is now made at
`pkgs/top-level/hare-packages.nix`
harec:
1. Remove `hardeningDisable = [ "fortify" ];`, since both harec and hare
compile normally with it enabled
2. Enable parallel building
3. Set `meta` attribute `mainProgram`
4. Make the package accessible through `all-packages.nix` instead of
`aliases.nix`
5. Move package path from `pkgs/development/compilers/hare/harec` to
`pkgs/development/compilers/harec`, since the scope is now made at
`pkgs/top-level/hare-packages.nix`
harePackages:
1. Move hare packages scope from
`pkgs/development/compilers/hare/default.nix` to
`pkgs/top-level/hare-packages.nix`
2. Remove `hare` and `harec` from `aliases.nix`, moving them to
`all-packages.nix`
3. Change the `callPackage` argument in `all-packages.nix` from
`../development/compilers/hare` to `./hare-packages.nix`
[1]: 1048620a7a/item/scripts/version (L2)
Co-authored-by: starzation <nixpkgs@starzation.net>
Depends on EOL software and no maintenance has been attempted to change this after a ping
(https://github.com/NixOS/nixpkgs/issues/259178)
Feel free to adopt and re-introduce if you care about this software.
This will probably seriously hamper ELK usability in nixpkgs, but as it
receives no maintenance…
While using very old compilers is a fair usecase, it induces a maintenance churn as
we collect more and more LLVM versions for the LLVM maintainers.
Especially when we need to backport uniform changes to the whole tree,
furthermore, it consumes and waste CI resources.
Based on #257780, separated since it introduces significant changes.
bpycv: update passthru.tests.render
blender-with-packages: deprecated
it is still backwards compatible, but no longer preferred.
Related to #262907 (Django3 removal from nixpkgs).
This package already required an unreasonable amount of maintenance
regularly for a such small leaf-package. It has a few highly outdated
dependencies (e.g. flask 1, jinja2 2.11, sqlalchemy 1.3).
After at least each Python package-set update one had to fix up a lot of
dependencies to fix the package itself, so it was only useful on stable
branches. And having so much outdated software in a security-sensitive
piece of software seems questionable.
Finally, globin and I won't be available for maintaining this now that
Mayflower is migrating to another solution (and we'll do that as well)
and I'd expect this to bitrot extremely quick if we both bail out.
This is mainly due to the lack of maintenance in nixpkgs.
`google-chrome-{beta,dev}` depend on `chromium{Beta,Dev}`'s version
info.
`chromium{Beta,Dev}` are rarely updated and explicitly blocklisted by
`hydra.nixos.org`, meaning they are almost always outdated and not
cached in `cache.nixos.org`.
`chromium{Beta,Dev}` were intended to fix the build derivation of each
new major release (if something broke) *before* stable reached that
new major release.
Allowing for fast bumps in nixpkgs, especially if the stable bump
contains very important critical security fixes.
Something that can easily be replicated by using an early-stable release
or by manually entering a dev/beta version string in stable's
`upstream-info.nix`.
This resolves exposing end-users to outdated and vulnerable
`google-chrome-{beta,dev}` and `chromium{Beta,Dev}` versions.
