| 14 Oct 2021 |
 j-k | I'll go over a short explanation of Supply Chain (Security) in the discorse post so it clicks for people where nix already handles some of this | 15:48:13 |
| j-k | Also I've noticed most people are fine with the concept of Pipelines (specifically CI CD pipelines) now but they don't connect that with Supply Chains (e.g. any other supply chain such as food, silicon wafers, etc, Just a long chain of inputs and outputs). I was the same at the beginning but then it clicked | 15:51:20 |
 baloo | Those are hard problem to solve, and we can't expect everyone to understand it all. There are also a ton of bad examples out there. | 15:56:37 |
| j-k | Yep, they're hard problems to solve but on the other hand I'm finding them even harder to solve without nix š | 16:05:17 |
 tomberek | j-k: Iād be happy take those conversations and devote some time. | 20:47:08 |
| 15 Oct 2021 |
| j-k | For anyone who didn't join the channel but is interested in the post I promised yesterday:
https://discourse.nixos.org/t/over-10-million-donated-for-supply-chain-security-an-opertunity-for-growth-and-adoption/15508 | 10:40:48 |
 toonn | What's the new channel for, how does it differ from this one? | 10:51:03 |
 Jamie | sounds like someone's testing whether the channel is reproducible :P | 10:53:43 |
| j-k | It's to review how nix can solve supply chain security issues, specifically focused on comparing it against the SLSA framework requirements. It can also help us discuss suggestions to feed back to the SLSA framework for changes. Also it straddles Security and Reproducibility
https://matrix.to/#/#nix-slsa:matrix.org
And it's there so this channel doesn't get swamped | 11:43:50 |
| j-k | ok it finally sent... not sure why it was having issues | 11:44:17 |
|  Xe (xe/they) changed their profile picture. | 19:14:38 |
| 16 Oct 2021 |
 trofi | A bit of signal boost in hopes of getting a reviewer: https://github.com/NixOS/nixpkgs/pull/140179 | 15:15:21 |
| baloo | could we imagine a more generic approach? | 21:37:53 |
| baloo | nevermind | 21:38:21 |
| baloo | no | 21:38:22 |
| baloo | actually, that could maybe work | 22:47:27 |
| baloo | what if ... when doCheck==true, we added a "tests" output | 22:47:44 |
| baloo | before running tests, we just install everything like we should, then we run the tests and if they run successfuly, touch the test output | 22:48:31 |
| baloo | derivation would fail if not every output is created | 22:48:46 |
| baloo | output derivation does not get extraneous references. | 22:49:52 |
| baloo | I don't know how dumb that is | 22:49:59 |
| baloo | https://github.com/baloo/nixpkgs/tree/baloo/stdenv%2Flate-checks | 23:53:27 |
| baloo | (untested) | 23:53:31 |
| 17 Oct 2021 |
| baloo | https://github.com/NixOS/nixpkgs/pull/141933 | 00:42:53 |
| baloo | we don't even need the tests output | 01:08:24 |
| trofi | I don't know the invariants of the check phases. Are they forbidden to affect the final result? I can imagine a situation when result of test run would be useful to install. I assume it's not forbidden by nixpkgs's policy to create installable files in check phases (if such policy exists). I personally would not mind test bytecode to be installed if it were deterministic and it's what python ecosystem does. | 09:47:03 |
| baloo | that seems weird to me to rely on check phase to produce outputs, but I don't know | 20:07:42 |
| baloo | the suggestion to run that through an RFC first would make sense | 20:08:03 |
| baloo | but I have NO experience writing those | 20:08:12 |
