| 10 Nov 2024 |
 Mic92 | emily: you can just throw a syserror and the error message is taken care off: https://github.com/NixOS/nix/blob/aa9c0bc1ee03f0fedebc4a6367fcf5bbecb4ef5c/src/libfetchers/git-utils.cc#L227 | 17:18:28 |
 emily | right | 17:19:34 |
| emily | although, where is that getting the code from? | 17:19:48 |
| Mic92 | errno | 17:20:04 |
| emily | is it guaranteed that errno corresponds to e.code() there? | 17:20:08 |
| Mic92 | Unless something has overridden the errno in the meantime, yes | 17:20:30 |
| emily | hmm, does the spec actually guarantee that or is it just a common side effect of implementations being written in terms of the C API? I didn't see it mentioned on cppreference anywhere, at least | 17:21:37 |
| Mic92 | Ah. no. Actually I don't know what e.code() is. | 17:22:30 |
| Mic92 | Ok. It seems there is a table? https://en.cppreference.com/w/cpp/error/errc | 17:23:07 |
| 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 |
