A recent upgrade of cargo-vendor changed its output slightly, which
broke all cargoSha256 hashes in nixpkgs.
See https://github.com/NixOS/nixpkgs/issues/60668 for more information.
Since then, a few hashes have been fixed in master by hand, but there
were a lot still to do, so I did all of the ones left over with some
scripts I wrote.
The one hash I wasn’t able to update was habitat's, because it’s
currently broken and the build doesn’t get far enough to produce a
hash anyway.
Remove UnicodeCollate dependency, which is part of Perl 5.28 and
does not exist separately anymore.
Add PerlIO::utf8_strict, which lack thereof Biber complains about
during build.
texlive attribute was accidentally added in attrset wrapped with
stdenv.lib.optionalAttrs (!stdenv.isDarwin)
Fixes: dbc2c1c4b8 ('texlive: add missing perl dependencies for latexindent')
Initial language.{dat,def} configuration files provided by
`texlive.hyphen-base` may declare languages that were not part of the
combined packages. Those are filtered out by a sed script that had few
problems:
1) The sed script was generated from a list of potentially non-unique
packages. Every repetition of a select and print clause would produce a
copy of a language declaration in the output file. This became a problem
for update to the 2018-final, the fmtutil would crash from too much
German hyphenation.
2) The select clauses were ambiguous: both '^% from hyphen' and
'^% from hyphen-welsh' will match a line 'from hyphen-welsh'.
mkUniqueOutPaths used to produce empty paths for dummy packages, this
version strips those out. This does not affect `pkgList.bin` at all, but
`pkgList.nonbin` is affected, so this is not exactly a refactoring. It
should not harm to have a cleaner `paths`.
Also, original comment said "here we deal with those dummy packages
needed for hyphenation filtering". This doesn't seem to be true, the
packages that were really filtered are actually metapackages that
represent collections. I also could not find any dummy packages even in
the originally committed version.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
