`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.
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
In 724e833ea2, I was a little too aggressive in enabling these flags.
Many don’t work in gcc, and we should probably avoid settings them
widely. This makes those flags optional on isclang
A few months ago I moved these patches to the new debian alsa instance [1], but
it looks like their `sha256`s on the tag at the remote have changed again.
It doesn't appear that debian's source remote is stable in the way we need it to
be; let's just vendor the patches to avoid future issues.
[1] https://github.com/NixOS/nixpkgs/pull/41769
Another broken URL related to: https://github.com/NixOS/nixpkgs/issues/39927
Note that the patch file has legitimately changed, because ~4 months ago Debian
replaced their CVE security fix with a newer version that fixes some additional
bugs: d6fd3b3734
We still do mirror the patch (I think), as `nix-build -Q -A p7zip.patches`
downloaded it on my machine. I verified that only the diff headers differ;
it's still better to have another working download and Fedora's URLs are
less likely to disappear than Debian's.
/cc #27075.
The debian source for this patch file has gone away, rendering this derivation
unbuildable from scratch.
This change updates the URL to a src.fedoraproject.org location that is still
serving a p7zip patch. This file is not the same bytewise, so I'm also updating
the hash; I didn't manage to find a location still serving a file with the
original hash, and my best guess is that this one is functionally equivalent.
