The fish completion checks the plugin directory for supported file types
to complete. However the plugin dir checked was the one of the
zathura_core derivation which of course has no plugin dir. We now patch
up the referenced path in the wrapper derivation.
By default in Nginx, if you want to override a single fastcgi_param,
you have to override all of them. This is less of a big deal if
you're editing the Nginx configuration directly, but when you're
generating the Nginx configuration with Nix it can be very annoying to
bloat your configuration repeating the default values of FastCGI
parameters every time.
This patch adds a fastcgiParams option to Nginx locations. If any
parameters are set through this, all the default values will be
included as well, so only the ones that are changing need to be
supplied. There's no way to use fastcgiParams to actually override
all parameters if that's what you want, but I think that's a niche use
case and it's still possible using extraConfig, which up until now was
the only option
Nginx allows the fastcgi_param directive in http and server scopes as
well as location, but here I only support location. It would be
possible to support the others, but I don't think it's worth it. It
would be a possible future enhancement if somebody has a need for it.
Failing build: https://hydra.nixos.org/build/134175791
ChangeLog: https://github.com/racer-rust/racer/blob/v2.1.40/CHANGELOG.md
A few more things are worth noting:
* It's not possible to update to latest version (2.1.42) at the time of
committing since this requires a newer `rustc` (1.51 to be precise) to
compile.
* For proper completion, `rustLibSrc` rather than `rustcSrc` must be
used now. The two were separated here previously[1].
* Dropped the `checkPhase` and replaced it with a list of `checkFlags`.
This has the benefit that the default `checkPhase` from
`buildRustPackage` can be used which properly configures parallelism
and which target to use (i.e. `release` in this case which reduces
build time).
[1] 68060f6f6f
This plugin is used commonly enough that we should ensure it still
builds (and dovecot works) after loading it.
This is not yet perfect as we aren't testing any of it's functionality
but at least we ensure that dovecot continues to do the regular job.
This updates to the latest version. According to the changelog 0.5.12
was skipped. The changes in this release are required to be compatible
with the latest dovecot release.
Changes:
- duplicate: The test was handled badly in a multiscript (sieve_before,
sieve_after) scenario in which an earlier script in the sequence with
a duplicate test succeeded, while a later script caused a runtime
failure. In that case, the message is recorded for duplicate tracking,
while the message may not actually have been delivered in the end.
- editheader: Sieve interpreter entered infinite loop at startup when
the "editheader" configuration listed an invalid header name. This
problem can only be triggered by the administrator.
- relational: The Sieve relational extension can cause a segfault at
compile time. This is triggered by invalid script syntax. The segfault
happens when this match type is the last argument of the test command.
This situation is not possible in a valid script; positional arguments
are normally present after that, which would prevent the segfault.
- sieve: For some Sieve commands the provided mailbox name is not
properly checked for UTF-8 validity, which can cause assert crashes at
runtime when an invalid mailbox name is encountered. This can be
caused by the user by writing a bad Sieve script involving the
affected commands ("mailboxexists", "specialuse_exists").
This can be triggered by the remote sender only when the user has
written a Sieve script that passes message content to one of the
affected commands.
- sieve: Large sequences of 8-bit octets passed to certain Sieve
commands that create or modify message headers that allow UTF-8 text
(vacation, notify and addheader) can cause the delivery or IMAP
process (when IMAPSieve is used) to enter a memory-consuming
semi-infinite loop that ends when the process exceeds its memory
limits. Logged in users can cause these hangs only for their own
processes.
While we already had some test we might as well add the test for that
exact package to the tests attribute set. After all that should be what
(primarily) tests dovecot.
