Discourse via Email


This looks pretty cool. Question: can we still use email to mediate this Discourse instance? What email address to we use to create a post here via email?



1 Like

Hi roni,

I’m not quite sure to be honest. Are you getting my reply by email?

Nope! But I did just turn on “mailing list mode”, and set it to email me for every post besides my own. If you reply to this maybe I will receive it by email!


I just found it as well. The config is at https://discourse.nixos.org/u/USER/preferences/emails where USER is your nickname.

replying to a specific message

I found this link that explains how to set it up. Unfortunately the post to topic by email thing is missing on our instance. To be investigated.

Receiving replies by email now… but in different threads (even though you replied on the same topic). That’s… not great.

Thanks for testing!


I’ve sent in a reply via mail like 10 minutes ago … it still doesn’t show up anywhere.

So it looks like the email setting can be tuned for each topic. I enabled the inbox settings on meta and it seems to be working. See https://nixos.trydiscourse.com/t/testing-the-email-inbox/43?u=zimbatm . There is also a “mailing-list mode” which might help with the threading issues that you were having @roni .

I created a new category that acts as an email inbox: About the Inbox category . That should help email-only users to create new discussion threads.

Thanks @zimbatm! I have been using the mailing list mode, and it seems to be working for me.


Replying to

If @amjoseph-nixpkgs were around, they might be able to help understand how these lines ended up in the patch. My best guess is some path dependent reason that went away with a change to the implementation.

Short answer: LGTM

Medium answer: I’m on the road right now and monkeying around with git history is a bit awkward at the moment. Briefly, any time you can remove an __attrsFailEvaluation = true from nixpkgs without breaking CI, you should do so.

There was a PR (possibly even the last one of mine that was merged) which significantly tightened up CI, so that every top-level attribute had to evaluate when wrapped in builtins.tryEval (there are many Nix failures, like abort and typechecking errors inside C++ code which implements builtins, which result in “untriable failures” – failures which will cause eval to fail even when you wrap them with builtins.tryEval).

I fixed about half of the situations where this happened (the “shallow bugs”) and added __attrsFailEvaluation as a “cheat code” to basically disable that CI check for the other half. The hope is that at some point all of the __attrsFailEvaluation=trues can be eliminated from nixpkgs, and then we can remove the cheat code itself and rg __attrsFailEvaluation nixpkgs will produce zero matches. This will be immediately followed by world peace and flying pigs, of course.

Long answer: if needed (probably not) will have to wait a few days for me to get back to the office.