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
This commit also swaps the build tool to use python3 internally (which waf fully
supports and prefers) and swaps the src to be downloaded from gitlab. The waf.io
site only keeps source tarballs of the latest version, so once a new waf comes
out we can no longer reproduce older versions.
We need the ensureNewerSources hook to avoid this error, in both `python2` and `python3`:
ValueError: ZIP does not support timestamps before 1980
It's not uncommon for enterprise environments to block FTP traffic to external
sites. Since `pcre` gives an official HTTPS download URL [1] alongside the
official FTP endpoint, let's use that instead.
[1] https://www.pcre.org/
This commit rebuilds texlive 2017 with the final release of 2017. As described
in these issues [1][2][3], the upstream CTAN mirrors are a continuously moving
rolling release without historical archives.
This particular FTP server is also a rolling release folling CTAN for the latest
version, but it has snapshots of the final texlive releases; it appears that the
2017 distribution has been unmodified since texlive-2018 was released earlier
this year.
Along the way, we needed to fix several issues:
- xindy: if $HOME is unset, it will try to mkdir /homeless-shelter, which fails
due to insufficient permissions.
- scheme-infraonly: this scheme had symlinks into other releases that were
read-only, so it couldn't patch and modify the scripts. This commit removes it
for now, but that's not a particularly satisfying solution. Ideas?
This also adds some documentation on the upgrade process to prepare for
texlive-2018 [4].
This commit also replaces the sha1 hashes with upstream's standard sha512 hashes.
It appears the motivation for the shorter hashes was to save disk space in the
derivations; in master, the size of this directory is 1012K; in this commit it
is 1600K. The difference is not particularly large, and the downsides to using
our own sha1 hashes are:
- More nix code to maintain
- Multi-step upgrade process for maintainers: the maintainer first has to
download all upstream tarballs by sha512 hash, then run the fix script, then
rebuild with sha1 hashes.
- Less transparent. If we use the upstream sha512 hashes, any user can
immediately verify that the hashes we're providing match upstream, or match
the snapshot in time.
- Easier to debug. Since upstream is rolling and packages may disappear or fail
to build, it's useful to be able to determine if the sha mismatch is because
of an update or not; if we have a sha1 mismatch and no tarball to pull, we
can't figure out which sha512sum would have produced that sha1.
- Less trust required. Due to the above, users don't have to trust the
content-addressed mirrors on IPFS and @veprbl's servers as much.
- Easier to cobble together a source distribution from a variety of sources. It
seems some FTP servers have more/less than others, or older/newer packages. If
we know what we're looking for beforehand and we're just missing a few
packages whose hashes match the advertised hashes upstream, it's easier to find.
[1] https://github.com/NixOS/nixpkgs/issues/24683
[2] https://github.com/NixOS/nixpkgs/issues/10026
[3] https://github.com/NixOS/nixpkgs/issues/34490
[4] https://github.com/NixOS/nixpkgs/issues/40232
* slurm: 17.11.5 -> 17.11.7, pyslurm: 20180427 -> 20180604
This commit also swaps to use the official repository's github release tags
instead of their download site, which only keeps the most recent version with no
historical archives.
* Document why we don't run tests
* Remove dead testing code
Both mariadb.com and mariadb.org appear to be canonical upstream sources, and
have identical sha256 hashes at these URLs.
For the third-party mirrors, if we are just going to provide one URL, it should
be an HTTPS url instead of FTP or SSH, which many users may not be able to
access due to network security configurations.
This swaps the fetchgit call to be more consistent with the majority of other
NixPkgs fetchgit calls. Moreover, almost every network will be able to do HTTPS,
while some enterprise networks may limit external SSH access.
The fftw download page provides both an HTTP and FTP endpoint for downloading release tarballs:
http://fftw.org/download.html
Since some users may have difficulty fetching via FTP through corporate
firewalls, we should provide the option to get it over HTTP as well.
This pin was added in 2014 during a lua upgrade, but it appears vim today builds
fine with lua 5.2, so we can have it just depend on the `lua` package.
The upstream src URL for the patch appears to no longer exist. Per discussion in
https://github.com/NixOS/nixpkgs/issues/39927, the upstream URL is not stable,
so this commit inlines the patch in the nixpkgs src tree.
This commit adds the python3 application truffleHog, which is a stand-alone tool
that scans a git repo for unencrypted passwords.
This depends on a newer GitPython, which depends on a new major version of
gitdb, which depends on a new major version of smmap, so I've packaged those
as well in the preceding commits.
This commit adds smmap2, which is a separate pypi package from the existing
smmap 0.9.0, though they both come from the same repo. It also moves smmap into
the new python modules location.
Upgrade to new version. According to the upstream documentation, this project is
only tested on python3, so I've upgraded the pkg's interpreter as well.
Tested with nix-build and ./result/bin/cryptop
This commit adds the CentOS 7.4 base image from the CentOS mirror, for use with
building RPMs or evaluating Nix expressions in a CentOS image.
When CentOS 7.5 comes out, I will swap this URL to the permanently vaulted image.
Benjamin Hipple