| 29 Jan 2024 |
|  Sam Lehman set a profile picture. | 11:06:02 |
|  Finn Landweber joined the room. | 15:02:12 |
| Finn Landweber changed their display name from flandweber to Finn Landweber. | 18:20:07 |
| 30 Jan 2024 |
 infinisil | There is one remaining problem with the current pkgs/by-name check, and this fixes it: https://github.com/NixOS/nixpkgs/pull/285089
Quite a bit of Rust code there, would appreciate a review
| 20:49:34 |
| infinisil | I added tests and comments | 20:49:49 |
| infinisil | (actually just discovered another issue, but that one's pretty easy to fix) | 21:27:25 |
| infinisil | Easy and touching the same parts of the code, so I just included it in the above PR too as the last commit | 21:56:28 |
| 31 Jan 2024 |
|  @federicodschonborn:matrix.org changed their profile picture. | 03:36:13 |
| @federicodschonborn:matrix.org changed their profile picture. | 06:21:49 |
 Alexandros Liarokapis | Are there any documented requirements for what constitutes a valid stdenv? | 21:31:45 |
| infinisil | Pretty sure the answer is No and I personally don't have the knowledge to write that 😅 | 22:27:31 |
| Alexandros Liarokapis | Its kind of funny sincenit is so integral to the whole ecosystem | 22:38:52 |
 @qyriad:matrix.org | Most alternate stdenvs are derived from stdenv in someway anyway right? | 23:01:11 |
| Alexandros Liarokapis | I am not sure if that is the case with llvmPackages.stdenv and there are also some other stdenvs with other compilers both in stdenv and in various third party flakes. | 23:21:20 |
 tomberek | First question is what you mean by "valid". If you mean compatibility with mkDerivation and its semantics, then that will be complicated. Just making nix-shell/develop work is easy. | 23:36:50 |
| Alexandros Liarokapis | Yea I mean compatible with mkDerivation and other nixpkgs assumptions like the isPlatform checks and others | 23:43:15 |
| 1 Feb 2024 |
| @qyriad:matrix.org | In reply to @aliarokapis:matrix.org
I am not sure if that is the case with llvmPackages.stdenv and there are also some other stdenvs with other compilers both in stdenv and in various third party flakes. LLVM's stdenv's are overrideCCs on base stdenv: https://github.com/NixOS/nixpkgs/blob/e4f711a40e2124d11f84c3e67443d02fa413a634/pkgs/development/compilers/llvm/16/default.nix#L319 | 00:32:30 |
| @qyriad:matrix.org | I don't know about the others though | 00:32:35 |
 raitobezarius | I am aware of stdenv non derived by nixpkgs and those are completely different beast having their own semantics | 01:42:51 |
| raitobezarius | Before documenting what is a valid nixpkgs abiding stdenv, I think if we can document how to derive more complicated stdenv using combinators, that'd be great | 01:43:10 |
| raitobezarius | Documenting a valid nixpkgs abiding stdenv is bound to be very complicated notably due to splicing constraints, etc. which are not even totally clear for experts | 01:43:29 |
| @qyriad:matrix.org | In reply to @aliarokapis:matrix.org
I am not sure if that is the case with llvmPackages.stdenv and there are also some other stdenvs with other compilers both in stdenv and in various third party flakes. * LLVM's stdenvs are overrideCCs on base stdenv: https://github.com/NixOS/nixpkgs/blob/e4f711a40e2124d11f84c3e67443d02fa413a634/pkgs/development/compilers/llvm/16/default.nix#L319 | 02:05:09 |
 @jade_:matrix.org | In reply to @aliarokapis:matrix.org
Yea I mean compatible with mkDerivation and other nixpkgs assumptions like the isPlatform checks and others I'm very suspicious of if that's actually well defined at all, there's some extremely tight coupling, especially with respect to the (imo) pretty evil stuff stdenv does with security hardening flags | 02:41:41 |
| Alexandros Liarokapis | In reply to @raitobezarius:matrix.org
Documenting a valid nixpkgs abiding stdenv is bound to be very complicated notably due to splicing constraints, etc. which are not even totally clear for experts This is a very good note, my main usecase currently is to use standard industry toolchains for cross building so keeping derivations compatible with the cross building infra is important. | 12:47:25 |
| Alexandros Liarokapis | Using such external toolchains is sometimes required due to them being IEC 61508 qualified. | 12:53:33 |
| Alexandros Liarokapis | Which allows them to be used in automotive and similar sectors, so it is good to have an escape hatch to use your own stdenv. Nix would be a great pitch for such sectors due to facilitating reproducible builds but this is kind of a game breaker because verifying compilers is expensive. | 12:57:07 |
| raitobezarius | If this is your usecases, I'd build various checks to ascertain that no non IEC 61508 component is used and fail the evaluation if so | 12:59:20 |
| raitobezarius | Then you can build your compliant stdenv | 12:59:27 |
| Alexandros Liarokapis | My point is that it's kind of underspecified what consists of a valid stdenv. Ideally the custom stdenv is also compatible with the usual cross building infra which means proper splicing and derivations shouldn't need to change much at least for compatible components that are buildable with both stdenvs. But I know this whole thing is not trivial to even document. | 13:04:36 |
| 3 Feb 2024 |
|  raboof changed their display name from raboof to raboof @FOSDEM. | 07:38:34 |
