| Commit message (Collapse) | Author | Age |
|
|
|
| |
(cherry picked from commit 48e6a3f1f16f29a30e34331a101ea40b535a784f)
|
|
|
|
|
|
| |
# Conflicts:
# nixpkgs/pkgs/build-support/rust/default.nix
# nixpkgs/pkgs/development/go-modules/generic/default.nix
|
| |
|
|
|
|
|
|
| |
Fixes #76927 (second try)
(cherry picked from commit 664c02c89bdafd21e9d0cf4d16baceeb70003185)
|
|
|
|
|
|
|
|
| |
This enables to compile rls and rustc
See also https://github.com/rust-lang/rust/pull/64823
(cherry picked from commit 47681d7c5c9529615e9f481f02d945a2c3cfe599)
|
| |
|
|
|
|
| |
Warns about loaOf deprecation warning.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The previously propagated build inputs are optional, and so are
included in checkInputs so the tests can run, but not propagated so
they aren't included if unneeded.
|
| |
|
|
|
|
|
| |
This is propagated by Hyperkitty, but it should really only be a
checkInput there.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a1eacb900e1b705678b2c199cb97baafc9b77f86.
Adding dev outputs to python packages means they can't be included in
a Python environment created with python3.withPackages, because
makePythonPath will include the dev output, which is empty apart from
nix-support, rather than the out output, which contains all the Python
code.
|
| |
|
|
|
|
|
| |
This caused the service to fail because it couldn't find its
gpghomedir.
|
|
|
|
|
|
| |
This patch has not been necessary since
5425867bfa3e4ba83a3d67aa50b811b5f70d6fe5, and has in fact broken the
build since then.
|
| |
|
| |
|
|
|
|
| |
This package is a dependency of GNU Mailman 3.3.x.
|
|
|
|
|
|
| |
This fixes some two-digit year rounding bugs that started triggering
because 2020 is closer to 2070 than 1970. Apparently two digits years
are still a thing.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They modified the release tarballs to fix a bug with the dictionary
generation. From their website:
> Re-release of all dictionary exports: Due to a bug in the IPA
> generation, some dictionaries had incorrect IPA transcriptions for
> headwords. This has been fixed for all dictionaries now.
I sent them mail requesting that they don't do this again without
calling it a new release:
https://www.freelists.org/post/freedict/Hash-changes-for-dictionary-releases
|
|
|
|
|
|
|
|
|
| |
This module encapsulates pretty much all of public-inbox's
functionality. While there are a lot of options, they're only exposed
for things that either I think have a high chance of being something a
large proportion of users need to set, or if the module needs to do
some special setup to accomodate them. All other public-inbox
configuration can be set through the `config' options.
|
|
|
|
|
| |
This will allow users to provide other archiver plugins than the
default mailman-hyperkitty.
|
|
|
|
|
|
| |
Mailman will read its config file from either location, but
mailman-web will only read its config from /etc/mailman3/settings.py.
So, use /etc/mailman3 for mailman.cfg as well, for symmetry.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, some files were copied into the Nixpkgs tree, which meant
we wouldn't easily be able to update them, and was also just messy.
The reason it was done that way before was so that a few NixOS
options could be substituted in. Some problems with doing it this way
were that the _package_ changed depending on the values of the
settings, which is pretty strange, and also that it only allowed those
few settings to be set.
In the new model, mailman-web is a usable package without needing to
override, and I've implemented the NixOS options in a much more
flexible way. NixOS' mailman-web config file first reads the
mailman-web settings to use as defaults, but then it loads another
configuration file generated from the new services.mailman.webSettings
option, so _any_ mailman-web Django setting can be customised by the
user, rather than just the three that were supported before. I've
kept the old options, but there might not really be any good reason to
keep them.
It also meant that one hard-coded SECRET_KEY was included in the Nix
store, AND SHARED BETWEEN ALL NIXOS USERS! As part of this change,
the secret key will now be generated along with the Hyperkitty API key
the first time the service is run, and it will never be stored in the
Nix store.
|
|
|
|
|
| |
Also, mailman looks in /etc/mailman.cfg by default, so setting
MAILMAN_CONFIG_FILE isn't required either.
|
|
|
|
|
|
|
| |
We already had python3Packages.mailman, but that's only really usable
as a library. The only other option was to create a whole Python
environment, which was undesirable to install as a system-wide
package.
|
|
|
|
| |
I used this to set up ARC. I'm sure there are other usecases too.
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's likely that a user might want to set multiple values for
relay_domains, transport_maps, and local_recipient_maps, and the order
is significant. This means that there's no good way to set these
across multiple NixOS modules, and they should probably all be set
together in the user's Postfix configuration.
So, rather than setting these in the Mailman module, just make the
Mailman module check that the values it needs to occur somewhere, and
advise the user on what to set if not.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Supporting a path here is important because it allows e.g. fetching a
configuration from a URL. To do this and provide the configuration as
a string, IFD would be necessary. It's just written into a path
anyway.
|
|
|
|
| |
The Net::CIDR::Lite package was missing.
|
|
|
|
|
|
| |
Using a custom path in the Nix store meant that users of the module
couldn't add their own config files, which is a desirable feature. I
don't think avoiding /etc buys us anything.
|
| |
|
|
|
|
|
|
| |
This is basically an alias for a special case of postqueue, which
already has a setgid wrapper. Would be silly to allow postqueue -p
but not mailq.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes
nix-shell -p 'ruby.withPackages (const [])' ruby.devdoc
which otherwise wouldn't find documentation, unlike
nix-shell -p ruby ruby.devdoc
which would, because ruby has setup hooks to accomodate for this, that
were being masked by the withPackages wrapper.
|
|
|
|
|
|
| |
I noticed while strace-ing that Git was trying to open
/etc//gitconfig. Not a big deal, but it is definitely more correct
without the trailing slash.
|
| |
|