fetchzip downloads the file from specified URL, renames it to basename
of that url, and then relies on unzip to do the unpacking.
The first consequence is that this requires URL to end with proper
extension—otherwise it will fail to unpack. This is not always the
case and input-fonts workarounds this by adding “&.zip” query
parameter (which is obviously a hack and is not guaranteed to work
with every URL).
The second consequence is that basename of the url must be a valid
filename. I’ve tried to build a custom configuration of input-fonts
and I get an error from mv that the filename is too long:
> trying https://input.djr.com/build/?fontSelection=fourStyleFamily®ular=InputMonoNarrow-Regular&italic=InputMonoNarrow-Italic&bold=InputMonoNarrow-Bold&boldItalic=InputMonoNarrow-BoldItalic&a=0&g=0&i=topserif&l=serifs_round&zero=0&asterisk=height&braces=straight&preset=default&line-height=1.2&accept=I+do&email=&.zip
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 100 406k 100 406k 0 0 230k 0 0:00:01 0:00:01 --:--:-- 230k
> mv: failed to access '/build/?fontSelection=fourStyleFamily®ular=InputMonoNarrow-Regular&italic=InputMonoNarrow-Italic&bold=InputMonoNarrow-Bold&boldItalic=InputMonoNarrow-BoldItalic&a=0&g=0&i=topserif&l=serifs_round&zero=0&asterisk=height&braces=straight&preset=default&line-height=1.2&accept=I+do&email=&.zip': File name too long
We could use “name” parameter as the filename (that’s how it is used
in fetchurl). However, the previous attempt to do
so (fc01353703) was
reverted (24b5eb61eb) because of the
introduced regression—many fetchzip invocations use names without
extension (also the default name is just “source”).
This commit adds an optional “extension” parameter. If it is set,
fetchzip renames the downloaded file to “download.${extension}”
effectively solving both problems above without introducing a massive
regression.
This is a no-op for all existing packages.
Tested by updating my NixOS setup + the extra inputs-fonts
configuration mentioned above + tons of unstable emacs packages after
a nix-collect-garbage (3Gb downloaded) with this patch applied.
Trying to reuse the update scripts used by kakoune/vim to provide the
user with an unified convergence. Some stuff doesn't work yet (parallel
download, caching) but I (anyone else welcome to try too) will improve
it in other PRs.
Analogous to 6325d15e90.
The test certificate expiration date was set to the default 30 days.
This certificate is generated through its own derivation. As with
every derivation, it gets cached by cache.nixos.org once we build it.
In practice, we rebuild this derivation only if one of its input
changes. The only inputs here being openssl and stdenv.
While it's not an issue on the unstable branches, it can be
problematic on a stable release: the test will fail after 30 days.
Extending the certificate lifespan from 1 month to 100 years to prevent
it from getting expired while being cached.
Eblurhash has been released to hex, we do not need to manually fetch
it from a git repository anymore.
The rest of the diffs have been generated by mix2nix.
A minor bug in mix2nix forced us to manually alter the base64url
dependency. The bug was already fixed upstream and should be resolved
for us once mix2nix branches off a new release. See
https://github.com/ydlr/mix2nix/issues/11 for more infos.
Release notes: https://pleroma.social/announcements/2021/08/08/pleroma-major-release-2-4-0/
This commit shows how to convert luarocks packages into (neo)vim ones.
The advantage for neovim lua plugins to register their rockspec (aka
package definition) is that the plugin can express its dependencies and
a few metadata through it.
