| 20 Jan 2023 |
 Sandro 🐧 | In reply to @trofi:matrix.org
I use a similar hack locally to map .drv files back to attribute names and to repology package names: https://github.com/trofi/nix-olde/ btw there is not nix code in that repo. Unsettling a bit. | 14:06:21 |
 raboof | trofi: makes sense, thanks | 14:07:49 |
 @trofi:matrix.org | I used --arg config 'import <nixpkgs/pkgs/top-level/packages-config.nix>'. Might work for you as is. | 14:08:35 |
| @trofi:matrix.org | In reply to @sandro:supersandro.de
btw there is not nix code in that repo. Unsettling a bit. Heh. I'll probably add a Cargo.lock file soon and will add simple .nix derivation for it. I don't really know rust ecosystem and I'm afraid it will get stale (will needs bots to update it and so on). | 14:10:18 |
| raboof | In reply to @trofi:matrix.org
I used --arg config 'import <nixpkgs/pkgs/top-level/packages-config.nix>'. Might work for you as is. error: attribute 'nodePackages_latest' missing - I might not have nix-env set up correctly though, I never use it | 14:11:25 |
| @trofi:matrix.org | I think -I nixpkgs=$src (as a path to the nixpkgs tree) should do it. | 14:12:18 |
| raboof | doesn't seem like it... | 14:18:01 |
| Sandro 🐧 | In reply to @trofi:matrix.org
Heh. I'll probably add a Cargo.lock file soon and will add simple .nix derivation for it. I don't really know rust ecosystem and I'm afraid it will get stale (will needs bots to update it and so on). dependabot should be able to help you with that | 14:22:43 |
| 21 Jan 2023 |
|  Tobias Markus joined the room. | 00:45:34 |
| 23 Jan 2023 |
|  @tassilo.tanneberger:matrix.ifsr.de left the room. | 16:10:51 |
 @linus:schreibt.jetzt | grahamc (he/him): do you think you could update r13y.com, or maybe let someone else take it over? I'd like to link it in a discussion on Nix and reproducibility, but it's currently 6 months old ^^ | 18:23:45 |
 @rick:matrix.ciphernetics.nl | This one, I guess: https://news.ycombinator.com/item?id=34490376 | 18:28:30 |
| @linus:schreibt.jetzt | you got me :p | 18:29:44 |
| raboof | https://arnout.engelen.eu/nixos-iso-gnome-r13y/ / https://arnout.engelen.eu/nixos-iso-minimal-r13y/ are more recent (would be happy to work together on r13y.com) | 18:31:37 |
| 24 Jan 2023 |
| raboof | https://github.com/NixOS/nixos-org-configurations/pull/234 | 12:02:46 |
| 25 Jan 2023 |
 @rnhmjoj:maxwell.ydns.eu | In reply to @raboof:matrix.org
https://arnout.engelen.eu/nixos-iso-gnome-r13y/ / https://arnout.engelen.eu/nixos-iso-minimal-r13y/ are more recent (would be happy to work together on r13y.com) wow that's a lot of haskell libraries. I had forgotten that GHC object files are not reproducible. are there any recent developments about this? | 09:59:02 |
| @rnhmjoj:maxwell.ydns.eu | * wow, that's a lot of haskell libraries. I had forgotten that GHC object files are not reproducible. are there any recent developments about this? | 09:59:05 |
 Atemu | Perhaps you could ask nh2, they're into GHC stuff | 10:00:03 |
| raboof | I didn't notice much activity in https://github.com/NixOS/nixpkgs/issues/151347 / https://gitlab.haskell.org/ghc/ghc/-/issues/12935 | 10:06:54 |
| raboof | though it seems it doesn't necessarily impact all haskell builds? there's quite some green ones in https://reproducible.archlinux.org/ | 10:09:53 |
| raboof | quick experiment: haskellPackages.void seems reproducible for us as well | 10:10:58 |
| @rnhmjoj:maxwell.ydns.eu | could it be related to parallel builds/optimisation level? | 10:11:21 |
| raboof | yeah single threaded builds seem more reliable but also quite a price to pay (https://github.com/NixOS/nixpkgs/issues/151347#issuecomment-997817696, https://gitlab.haskell.org/ghc/ghc/-/issues/12935#note_373865) | 10:13:26 |
| raboof | perhaps an option for some small/fast modules that are currently unreproducible, but it might be good to put some energy in looking into the upstream ghc problem(s?) as well | 10:21:14 |
| Atemu | Perhaps we could make a haskellPackagesReproducible set where parallel builds are off and use that in the ISO | 10:45:22 |
| @rnhmjoj:maxwell.ydns.eu | I think the problem is that the most commonly used libraries are not particularly small (pandoc, lens, aeson, etc). ~100 modules is typical | 10:45:43 |
 baloo | In reply to @raboof:matrix.org
yeah single threaded builds seem more reliable but also quite a price to pay (https://github.com/NixOS/nixpkgs/issues/151347#issuecomment-997817696, https://gitlab.haskell.org/ghc/ghc/-/issues/12935#note_373865) could that be that the objects needs to be fed in a deterministic order to the linker? It looks like the linker just gets them in random order and slaps them together. | 17:31:02 |
| baloo | if I remember correctly there are ordering rules between some objects, but that doesn't mean they won't end up in different order at the end.
Like you could get A -> C and B -> C, but you could end up with A,B,C or B,A,C which would be valid calls to the linker. | 17:39:22 |
| baloo | but they would end up with placing object in A and B out of order. | 17:39:52 |
| baloo | anyway, something to "fix" in the build tool itself (cabal?) and not much we can do from a nix perspective? | 17:40:35 |
