| 27 Mar 2025 |
 Martin Schwaighofer | In reply to @fzakaria:one.ems.host
That's not bad but definitely a bit confusing; I think having to explain CA + input deriving makes it extra confusing.
I'm trying to better understand how inputDrvs (for input deriving) get replaced with some other hash recursively (hashModulo) I'm kind of in the process of implementing that for github.com/mschwaig/laut, except that the input hashes I generate for CA derivations are not based on the ATerm format (for now), but on a canonicalized version of the JSON representation of the derivation.
That implementation is also meant to be readable/understandable. | 16:48:48 |
| Martin Schwaighofer | * I'm kind of in the process of implementing that (meaning replacing inputDrvs to get to a hash that only includes resolved dependencies) for github.com/mschwaig/laut, except that the input hashes I generate for CA derivations are not based on the ATerm format (for now), but on a canonicalized version of the JSON representation of the derivation.
That implementation is also meant to be readable/understandable.
| 16:58:00 |
 John Ericson | https://github.com/nixos/nix/commit/11d853462925d0b57fe956962e07edf5751fd4c3 | 20:07:55 |
| John Ericson | I think this commit was a mistake | 20:07:58 |
 Philip Taron (UTC-8) | 2.27.1 and 2.24.13 were both tagged in the NixOS/nix repository. Is there someone on deck to open a PR against nixpkgs? | 21:29:38 |
| Philip Taron (UTC-8) | 
Download image.png | 21:34:12 |
| Philip Taron (UTC-8) | I can do the 2.24.13 one, but the PR to introduce 2.26 was pretty beefy with 2_26 specific code. | 21:34:26 |
| Philip Taron (UTC-8) | If that's the pattern, 2.27 is going to be equally beefy! | 21:35:21 |
| Philip Taron (UTC-8) | cc Robert Hensing (roberth) as the author of the previous big-lift PR, https://github.com/NixOS/nixpkgs/pull/375856. | 21:44:01 |
 emily | if 2.27 is as different from 2.26 as it was from 2.25, something went horribly wrong | 21:48:10 |
| emily | they're the same Meson build system | 21:48:15 |
| Philip Taron (UTC-8) | Yes -- what I mean is that all that code was checked in under pkgs/tools/package-management/nix/vendor/2_26/ -- so this is the version that figures out how to share it | 21:48:51 |
| Philip Taron (UTC-8) | (Since I assume that adding Nix 2.27 doesn't at the same time drop 2.26, which would be madness.) | 21:49:32 |
| Philip Taron (UTC-8) | * Yes -- what I mean is that all that code was checked in under pkgs/tools/package-management/nix/vendor/2_26/ -- so this is the version that figures out how to share it or copy it/ | 21:49:42 |
| emily | I guess it should, since the Nix team only support the latest version and the version in Nixpkgs stable. | 21:52:48 |
| emily | btw, there is a much more sensible packaging in https://github.com/NixOS/nixpkgs/pull/393509 but sadly I think it is not being pursued | 21:53:17 |
 SomeoneSerge (back on matrix) |
What on earth does "output" without method or hash or path or anything at all mean?
"name": > "bootstrap-stage0-binutils-wrapper-",
"outputs": {
"out": {}
},
CC Martin Schwaighofer
| 21:56:21 |
| emily | those are split outputs, no? | 22:12:07 |
| emily | the Nixpkgs outputs = … | 22:12:21 |
|  nishimara joined the room. | 22:21:49 |
| John Ericson | deferred input-addressed | 22:34:13 |
| John Ericson | i.e. it is an input-addressed that depends on content-addressed | 22:34:23 |
| John Ericson | we're waiting to building the content-addressed before we can input-address | 22:34:44 |
| John Ericson | this has the effect of doing an an end-run around hashDerivationModulo | 22:35:07 |
| John Ericson | the thing we will end up using for input-addressing is the resolved derivation, with no inputSrcs | 22:35:22 |
| John Ericson | * the thing we will end up using for input-addressing is the resolved derivation, with no inputDrvs only inputSrcs | 22:35:31 |
| 28 Mar 2025 |
 fzakaria | if I have an ATerm drv file; how can I add it to my store ? | 01:59:00 |
| fzakaria | (assuming "it's correct") | 01:59:05 |
| fzakaria | oh nix-store --add but the name has to end in .drv | 02:14:24 |
| Martin Schwaighofer | In reply to @Ericson2314:matrix.org
the thing we will end up using for input-addressing is the resolved derivation, with no inputDrvs only inputSrcs Ok, I understand, thanks | 13:14:30 |
