| 14 Oct 2025 |
 raitobezarius | no, 6666 is one of the AFNix macOS builder | 10:08:55 |
 delroth | (the DNS zone only has the v4 for that host so I don't know if we're talking about the same one) | 10:09:01 |
| raitobezarius | we didn't setup yet access to these mac for interactive remote building | 10:09:14 |
| delroth | ahh, thanks | 10:09:36 |
| raitobezarius | nw | 10:09:39 |
| delroth | I got confused since the whois resolves to scaleway | 10:09:42 |
| raitobezarius | 2001:bc8:38ee::/48 is par01 | 10:10:01 |
| delroth | but wait | 10:10:49 |
| delroth | the afnix macos builders don't have v6? | 10:10:53 |
| raitobezarius | not yet | 10:10:59 |
| raitobezarius | the initial setup had v6 | 10:11:02 |
| delroth | where's that IP from then? | 10:11:11 |
| raitobezarius | then we switched them over v4 because we needed to complete the MDM process | 10:11:12 |
| raitobezarius | it's from the initial setup before MDM | 10:11:19 |
| raitobezarius | i can reintroduce the IPv6 once I have some time | 10:11:33 |
| delroth | I'm just confused how aloisw ended up with it then :p | 10:11:37 |
| delroth | ok | 10:11:37 |
| delroth | I guess I don't need the full history lesson to accept current facts | 10:11:47 |
| raitobezarius | before MDM, I gave aloisw access to one of the box so they could do some testing | 10:11:52 |
| delroth | makes sense, thanks | 10:12:01 |
| raitobezarius | we can move this over AFNix discussion | 10:12:10 |
| raitobezarius | (https://zulip.afnix.fr/#narrow/channel/4-infra/topic/macOS.20remote.20building.20access for those who wants to follow) | 10:13:03 |
 emily | has there been any more thought given re: builtins.convertHash / https://git.lix.systems/lix-project/lix/issues/602? I know making it a more general radix conversion function was discussed, but IMO the Base32 and Base64/SRI hash formats are quirky enough that they really don't fit elegantly into a radix conversion model, especially since they are too large to round-trip via Nix integers, which would otherwise be the natural way to express radix conversion functions.
not saying it has to have the exact same interface but I am not convinced that the full general base conversion mechanism is necessary/desirable for it, and the -2 review on https://gerrit.lix.systems/c/lix/+/2585 shows that it would require a lot of contortions to make it useful for the actual hash conversion use case, which seems to have been useful both in third-party repos and has caused a hash mismatch in Nixpkgs even with an attempt to do feature detection https://github.com/NixOS/nixpkgs/pull/451929.
| 15:38:52 |
| emily | given it has to deal with >128-bit values and the formats are quirky, I am not sure there is a builtin that is significantly more scoped than builtins.convertHash that would make it possible to implement this efficiently and non-horribly given Nix's anaemic facilities for such processing | 15:40:17 |
| emily | I think the most you could reasonably scope it down is just omitting handling of the SRI stuff and making it do inter-conversion of strings between Base16/Base32/Base64 | 15:41:27 |
| emily | and then handle the <alg>:<digest> and <alg>-<digest> formats in Nix code | 15:41:44 |
| emily | but even then it's not like you'll get something terribly general because e.g. you are still encoding quirks like Nix's Base32 endianness | 15:42:14 |
| emily | so I expect that in ~100% of cases people are just going to be using it for exactly what builtins.convertHash does | 15:42:50 |
| emily | I suppose I can imagine someone trying to convert Base64 binary data to a hex dump or something… and if NUL bytes are going to be allowed in strings then it could be split into two separate encode/decode built-ins that go through binary blobs at a penalty of more allocations etc. | 15:43:44 |
| emily | but the general radix conversion thing seems like a total detour | 15:44:00 |
