Discourse via Email

Meta Moderation
1

Hello!

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?

Thanks!

roni

1 Like
2

Hi roni,

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

3

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!

roni

4

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

5

replying to a specific message

6

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.

7

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

Thanks for testing!

roni

8

Iā€™ve sent in a reply via mail like 10 minutes ago ā€¦ it still doesnā€™t show up anywhere.

9

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 .

10

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.

11

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

roni

12

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.

1 Like
14

Wow those 480 linesā€¦ make my eyes bleed. Excluding the meta attrset (which I make a point of filling out completely) thatā€™s almost four times as long as my implementation. And itā€™ll drop to half that length if the upstream devs give us a compile-time flag to set static paths for monerod and tor.

Milahu did seem to figure out how to use pkgs.protobuf instead of the downloaded binary, though. I couldnā€™t figure out how to make that work.

@KRYREN I donā€™t think you did, but I can imagine it has something to do with the difference between this and this.