Conflicts:
- pkgs/development/python-modules/pathspec/default.nix
The hashes are equivalent, so it's not a real conflict.
- pkgs/top-level/static.nix
I can't see a solution, deffered redoing this to the later PR:
https://github.com/NixOS/nixpkgs/pull/136849
- boost 167 removed on staging-next (7915d1e03f) × boost attributes are inherited on staging (d20aa4955d)
- linux kernels were moved to linux-kernels.nix on staging-next (c62f911507) × hardened kernels are versioned on staging (a5341beb78) + removed linux_5_12 (e55554491d)
- conflict in node-packages – I regenerated it using node2nix from nixos-unstable (does not build on staging)
Since version 0.5.4.11, Xarchiver supports using either unrar or unar to
unpack .rar files. The former being released under an unfree license,
using the latter by default is preferable.
This avoids indirectly guarding the xarchiver package under
`nixpkgs.config.allowUnfree` due to the dependency on unrar.
Users who would like to use the unfree implementation may do so by
adding the unrar package to the environment from which they are calling
xarchiver.
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).
`chmod +x install.sh` was only being executed when enableUnfree was
false. Therefore, building p7zip with enableUnfree set to true would fail
because install.sh was not an executable file.
Related:
- 9fc5e7e473
- 593e11fd94
- 508ae42a0f
Since the last time I ran this script, the Repology API changed, so I had to
adapt the script used in the previous PR. The new API should be more robust, so
overall this is a positive (no more grepping the error messages for our relevant
data but just a nice json structure).
Here's the new script I used:
```sh
curl https://repology.org/api/v1/repository/nix_unstable/problems \
| jq -r '.[] | select(.type == "homepage_permanent_https_redirect") | .data | "s@\(.url)@\(.target)@"' \
| sort | uniq | tee script.sed
find -name '*.nix' | xargs -P4 -- sed -f script.sed -i
```
I will also add this script to `maintainers/scripts`.
The old homepage and src URLs no longer exist. The author of the package
confirms on GitHub that GitHub is now the official homepage (see
kholtman/afio#12).
7-Zip's RAR implementation is built on the non-free UnRAR source code;
DOC/License.txt says:
Licenses for files are:
1) CPP/7zip/Compress/Rar* files: GNU LGPL + unRAR restriction
2) All other files: GNU LGPL
The GNU LGPL + unRAR restriction means that you must follow both
GNU LGPL rules and unRAR restriction rules.
...
unRAR restriction
-----------------
The decompression engine for RAR archives was developed using source
code of unRAR program.
All copyrights to original unRAR code are owned by Alexander Roshal.
The license for original unRAR code has the following restriction:
The unRAR sources cannot be used to re-create the RAR compression algorithm,
which is proprietary. Distribution of modified unRAR sources in separate form
or as a part of other software is permitted, provided that it is clearly
stated in the documentation and source comments that the code may
not be used to develop a RAR (WinRAR) compatible archiver.
The unrar licensing is [infamously restrictive and non-free][fedora];
it's inappropriate for us to keep the RAR support while labelling the
package as free software (and indeed there's a commented-out line
pointing out that the current `meta.license` is false). Unfortunately,
the 7-Zip upstream seems uninterested in replacing the code with a
freely-licensed alternative (see [7-Zip ticket #1229][7zip]).
[fedora]: https://fedoraproject.org/wiki/Licensing:Unrar
[7zip]: https://sourceforge.net/p/sevenzip/feature-requests/1229/
An alternative solution would be to mark the p7zip package as non-free
instead; I decided not to because its other functionality (especially
`.7z` support) is freely-licensed and useful, and there are free
software alternatives for extracting RAR files (e.g. in nixpkgs there's
`archiver`, which is written in a memory-safe language, and `unar`,
which at least doesn't have two patches for CVEs that haven't been
addressed upstream...).
I checked that `7z(1)` fails gracefully on `.rar` files now:
emily@renko ~/tmp> curl -L -O https://www.philippwinterberg.com/download/example.rar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5715k 100 5715k 0 0 6716k 0 --:--:-- --:--:-- --:--:-- 6716k
emily@renko ~/tmp> 7z x example.rar
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_CA.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs x64)
Scanning the drive for archives:
1 file, 5853119 bytes (5716 KiB)
Extracting archive: example.rar
ERROR: example.rar
Can not open the file as archive
Can't open as archive: 1
Files: 0
Size: 0
Compressed: 0
