| 25 May 2024 |
 aidalgol | Header comment:
# Find alleged cherry-picks
But... why?
| 09:16:13 |
| aidalgol | What is the purpose of this check?? | 09:16:25 |
| 29 May 2024 |
 connor (he/him) | is it irritating to anyone else that nixpkgs-review uses allowBroken = true | 02:01:43 |
| connor (he/him) | Similar to OfBorg, that means we can't guard broken evaluations behind meta.broken | 02:04:58 |
| connor (he/him) | I only mention that because I just ran into evaluation errors which should be prevented by https://github.com/NixOS/nixpkgs/commit/e8dbfc07e54c5b477e95dac72b8153e381b0f840 where I'm using a newer version of CUDA and the attribute set doesn't have a binary release for that version so the lookup fails. | 02:05:48 |
 Gaétan Lepage | I am not sure to get that connor (he/him) (UTC-5).
For me, nixpkgs-review is not attempting to build packages marked as broken. Is that what you meant ? | 05:55:45 |
| Gaétan Lepage | tf2onnx> Found duplicated packages in closure for dependency 'protobuf':
tf2onnx> protobuf 4.24.4 (/nix/store/8g2k3idj2f4kbvra98clakdlcvsy6f2y-python3.11-protobuf-4.24.4)
tf2onnx> dependency chain:
tf2onnx> this derivation: /nix/store/r9fq9spwzn87ad0k4npbw487q2zbgryx-python3.11-tf2onnx-1.16.1
tf2onnx> ...depending on: /nix/store/73g093ny57lfgnrbx6lmvphj8y7j5826-python3.11-onnx-1.15.0
tf2onnx> ...depending on: /nix/store/8g2k3idj2f4kbvra98clakdlcvsy6f2y-python3.11-protobuf-4.24.4
tf2onnx> protobuf 4.21.12 (/nix/store/2lk63v57qnqp8n3ydvx0ja61ij2bxv35-python3.11-protobuf-4.21.12)
tf2onnx> dependency chain:
tf2onnx> this derivation: /nix/store/r9fq9spwzn87ad0k4npbw487q2zbgryx-python3.11-tf2onnx-1.16.1
tf2onnx> ...depending on: /nix/store/kngclwr5xpl63vwccpj05drfg60nfh5b-python3.11-tensorflow-2.13.0
tf2onnx> ...depending on: /nix/store/2lk63v57qnqp8n3ydvx0ja61ij2bxv35-python3.11-protobuf-4.21.12
🫠🫠🫠 | 09:12:29 |
| Gaétan Lepage | -> https://github.com/NixOS/nixpkgs/pull/315568 | 09:17:46 |
|  @nscnt:matrix.org joined the room. | 15:12:56 |
| connor (he/him) | In reply to @glepage:matrix.org
I am not sure to get that connor (he/him) (UTC-5).
For me, nixpkgs-review is not attempting to build packages marked as broken. Is that what you meant ? https://github.com/Mic92/nixpkgs-review/blob/14339add462bfb5f3181979899debe62d97325ce/nixpkgs_review/buildenv.py#L23-L46 | 17:54:37 |
| connor (he/him) | I rented a Hetzner server to host cantcache.me... their 7950x3D idles about 15C hotter than mine | 19:33:01 |
| connor (he/him) | The alternative was Equinix, which was much more expensive | 19:34:14 |
 hexa | ugh yeah, eqx mtl is prohibitively expensive 😄 | 19:54:00 |
| 30 May 2024 |
| connor (he/him) | I didn't realize that after Equinix bought Packet they started charging egrees fees of 5 cents a GB lmao | 00:27:07 |
| Gaétan Lepage | In reply to @connorbaker:matrix.org
https://github.com/Mic92/nixpkgs-review/blob/14339add462bfb5f3181979899debe62d97325ce/nixpkgs_review/buildenv.py#L23-L46 Ok, that is very suprising for me, because in my experiene, it doesn't attempt at building them.
I am running the version currently shipped in nixpkgs | 06:59:18 |
| hexa | In reply to @connorbaker:matrix.org
I didn't realize that after Equinix bought Packet they started charging egrees fees of 5 cents a GB lmao which is funny, because equinix is a really big player owning all kinds of datacenters around the world, and packet was comparably small | 11:12:45 |
| 31 May 2024 |
|  @maxwell325:matrix.org joined the room. | 12:15:35 |
 zopieux | is the Cachix occasionally pruned of older derivations? I pinned nixpkgs to github:NixOS/nixpkgs/2748d22b45a99fb2deafa5f11c7531c212b2cefa a few weeks ago, so that it would build to cuda-maintainers cached outputs, but launching this today it builds from source :( | 20:52:48 |
| aidalgol | I think the free plan provides fairly limited space, so as new derivations get pushed, the oldest ones get purged. | 23:32:00 |
| connor (he/him) | IIRC all of the plans use something like LRU eviction
Ours is sponsored by Domen so it’s not the entry-level cache, but I don’t have visibility into the entries | 23:34:39 |
| 1 Jun 2024 |
| connor (he/him) | I’m noticing that the CMake config file generated by OpenCV and used by downstream dependencies requires they use the same version of CUDA. Is that expected?
I’m also noticing some package build failures when they depend on OpenCV because that same OpenCV CMake config file requires CUDA_TOOLKIT_ROOT_DIR be specified, which isn’t set by our hooks. I understand it’s the legacy variable and that the FindCUDA module is deprecated, but how bad would it be to set that variable for the redist packages? We do it currently for the legacy runfile installer. https://github.com/NixOS/nixpkgs/blob/50b636da4a71664532583c800209e7a9e88c9e36/pkgs/development/cuda-modules/cudatoolkit/default.nix#L336 | 20:34:31 |
| connor (he/him) | I’m not by a computer atm but if I can remember I’ll try to post some examples of failures later | 20:34:53 |
