Discourse via Email

roni · April 23, 2018, 8:38pm

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

zimbatm · April 23, 2018, 9:49pm

Hi roni,

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

roni · April 23, 2018, 9:52pm

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

zimbatm · April 23, 2018, 9:54pm

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

zimbatm · April 23, 2018, 9:56pm

replying to a specific message

zimbatm · April 23, 2018, 10:06pm

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.

roni · April 23, 2018, 10:11pm

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

ciil · April 23, 2018, 10:12pm

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

zimbatm · April 23, 2018, 10:19pm

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 .

zimbatm · May 19, 2018, 5:16pm

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.

roni · May 20, 2018, 6:25pm

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

roni

amjoseph · July 10, 2024, 3:10am

Replying to

github.com/NixOS/nixpkgs

Comment by philiptaron to haskellPackages: remove __attrsFailEvaluation, buildHaskellPackages, and generateOptparseApplicativeCompletions special cases

NixOS:master ← philiptaron:__attrsFailEvaluation/haskell

> How come generateOptParseApplicativeCompletions no longer causes a failure? … I can't cause it to _ever_ generate a failure. ``` $ git checkout 5a0a700 HEAD is now at 5a0a700663ad Merge pull request #269356 from amjoseph-nixpkgs/pr/release-outpaths- ... editing snipped ... $ git diff diff --git a/pkgs/development/haskell-modules/make-package-set.nix b/pkgs/development/haskell-modules/make-package-set.nix index 294ca295f22b..c39c934bed64 100644 --- a/pkgs/development/haskell-modules/make-package-set.nix +++ b/pkgs/development/haskell-modules/make-package-set.nix @@ -614,7 +614,7 @@ in package-set { inherit pkgs lib callPackage; } self // { Type: [str] -> drv -> drv */ generateOptparseApplicativeCompletions = - (self.callPackage ( + self.callPackage ( { stdenv }: commands: @@ -623,7 +623,7 @@ in package-set { inherit pkgs lib callPackage; } self // { if stdenv.buildPlatform.canExecute stdenv.hostPlatform then lib.foldr haskellLib.__generateOptparseApplicativeCompletion pkg commands else pkg - ) { }) // { __attrsFailEvaluation = true; }; + ) { }; /* Modify given Haskell package to force GHC to employ the LLVM diff --git a/pkgs/top-level/release-attrpaths-superset.nix b/pkgs/top-level/release-attrpaths-superset.nix index 673b63a5ac34..fdfcda68f628 100644 --- a/pkgs/top-level/release-attrpaths-superset.nix +++ b/pkgs/top-level/release-attrpaths-superset.nix @@ -74,7 +74,6 @@ let buildHaskellPackages = true; buildPackages = true; - generateOptparseApplicativeCompletions = true; callPackage = true; mkDerivation = true; $ nix-build pkgs/test/release/default.nix ... test execution snipped ... /nix/store/a5hs2136icqxwi7d1y6yaqx1vvvsxkyc-all-attrs-eval-under-tryEval ``` 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.

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.