| 10 Nov 2024 |
Mic92 | But I know that those filesystem exception have errno updated corectly | 17:23:42 |
emily | I think std::error_code's .value() just gives you an errno | 17:24:15 |
emily | so I believe that strerror(e.code().value()) or similar is the correct thing to do | 17:24:33 |
emily | if e.what() is not useful | 17:24:36 |
emily | not 100% sure though | 17:25:10 |
Mic92 | emily: https://github.com/NixOS/nix/blob/aa9c0bc1ee03f0fedebc4a6367fcf5bbecb4ef5c/src/libutil/error.hh#L235 | 17:30:06 |
| Daniel Fahey joined the room. | 17:48:53 |
emily | right | 17:52:55 |
| @sbc64:matrix.org left the room. | 20:01:59 |
| 11 Nov 2024 |
| @zxfsee:matrix.org left the room. | 02:53:23 |
Vladimír Čunát | Any idea: build input /nix/store/foo does not exist (link) That's... some Nix bug? | 06:24:10 |
Vladimír Čunát | I found this long-closed issue, but surely we don't have a very old Nix on Hydra builders:
https://github.com/NixOS/nix/issues/6572 | 06:29:12 |
Mic92 | vcunat: is it reproducible? | 09:01:03 |
Vladimír Čunát | Two different machines did this on this particular derivation. | 09:01:27 |
Vladimír Čunát | (same output, though as usual, on Hydra this got overwritten, but I remember) | 09:01:55 |
Vladimír Čunát | Mic92: now I tried the same derivation on a machine outside NixOS infra and there this issue won't reproduce. Hard to guess what's the key difference, though. | 09:08:50 |
Vladimír Čunát | * Mic92: now I tried the same-hashed derivation on a machine outside NixOS infra and there this issue won't reproduce. Hard to guess what's the key difference, though. | 09:09:12 |
Martin Schwaighofer | In reply to @joerg:thalheim.io Martin Schwaighofer: both would be fine. If it requires a lot of back and forth, meeting might work better. Checkout this: https://github.com/NixOS/nix/tree/master/maintainers#meeting-protocol Is the meeting link https://jitsi.lassul.us/nix-maintainers or something else? The link to the google calendar entry for the work meeting is a dead link. 😅 | 13:02:47 |
| gr_h_m joined the room. | 20:04:08 |
| 12 Nov 2024 |
John Ericson | In reply to @mschwaig:matrix.org
Hi 👋 my name is Martin, I'm new in this channel!
I have two things that I would like to discuss with someone from the Nix team.
* My comment on https://github.com/NixOS/nix/pull/11749#issuecomment-2462223730 and * my paper on Extending Cloud Build Systems to Eliminate Transitive Trust, also covered by my talk about that work at NixCon 2024.
Would one of the regular meetings be suitable to discuss this, or would some other way be better? 😊 Hi @mschwaig:matrix.org have you looked at CA derivations? From a lightening quick skim of your paper, sounds like we've had some similar ideas on how to retrofit the benefits of content addressed derivation outputs for input-addressed derivation outputs | 01:45:29 |
John Ericson | I would be happy to talk to you about this more | 01:45:55 |
Martin Schwaighofer | In reply to @Ericson2314:matrix.org Hi @mschwaig:matrix.org have you looked at CA derivations? From a lightening quick skim of your paper, sounds like we've had some similar ideas on how to retrofit the benefits of content addressed derivation outputs for input-addressed derivation outputs Yes I have looked at CA derivations! 😊 In fact they close T3 in my threat model. To make what I am proposing work with input addressed derivations as well, it would be necessary to retrofit some of their benefits in terms of trust onto input addressed derivations by making dependency resolution a bit more strict, which I think would be possible.
I'd be interested in you ideas on this topic and how similarly/differently we see those things!
If you're looking for specifics in the paper, I think besides T3/M3 the sections relevant to the content addressing vs input addressing issue are 6.3.2, the first half of 6.4.2, and 4.1.1. | 02:07:32 |
Martin Schwaighofer | In reply to @Ericson2314:matrix.org I would be happy to talk to you about this more Sounds great, let's do that. 😊 | 02:08:05 |
| pfhuh joined the room. | 05:53:47 |
jade_ | In reply to @vcunat:matrix.org Any idea: build input /nix/store/foo does not exist (link) That's... some Nix bug? can happen if the scheduler fucks up (we had this bug in lix HEAD recently because of a big scheduler refactor) | 09:47:49 |
jade_ | also maybe a remote builds GC related bug | 09:48:02 |
jade_ | since the remote build system does not keep paths live properly | 09:48:14 |
jade_ | * since the remote build system does not keep paths live properly often | 09:48:16 |
jade_ | https://git.lix.systems/lix-project/lix/issues/505 see | 09:50:48 |
hexa | I did run a full GC in the mac builders last night | 09:52:12 |