| 24 May 2024 |
 SomeoneSerge (matrix works sometimes) | In reply to @philiptaron:matrix.org
https://wiki.archlinux.org/title/Bcachefs -- yeah, I live on the edge 🙈
They're the "SSD" in front of my actual SSDs I seeeeeeeeeeeeeee | 21:40:39 |
| SomeoneSerge (matrix works sometimes) | In reply to @connorbaker:matrix.org
SomeoneSerge (UTC+3): they're basically (slow) non-volatile RAM. Intel initially tried to position it in the datacenter as a tier between fast disks and RAM but it kind of flopped :l
the 4k random read/write is still the best on the market though Yes, conceptually this is clear. Putting this into practice is what sounds non-trivial | 21:41:53 |
 aidalgol | I don't understand what happened here: https://github.com/NixOS/nixpkgs/actions/runs/9230354336/job/25398415658 https://github.com/NixOS/nixpkgs/actions/runs/9230354050/job/25398414515#step:3:102 | 22:02:21 |
| 25 May 2024 |
| SomeoneSerge (matrix works sometimes) | In reply to @aidalgol:matrix.org
I don't understand what happened here: https://github.com/NixOS/nixpkgs/actions/runs/9230354336/job/25398415658 https://github.com/NixOS/nixpkgs/actions/runs/9230354050/job/25398414515#step:3:102 Hmmm, maybe we merged the previous PR unformatted, and the action is confused about the list split into lines in the backport? | 08:19:07 |
| SomeoneSerge (matrix works sometimes) |
Note this should not necessarily be treated as a hard fail, but a reviewer's attention should be drawn to it and github actions have no way of doing that but to raise a 'failure'
🤔 | 08:19:33 |
| SomeoneSerge (matrix works sometimes) | I've never encountered this | 08:19:36 |
| SomeoneSerge (matrix works sometimes) | https://github.com/NixOS/nixpkgs/blob/d091b7f681e8e5c21947e5de45b7f397a57011ae/maintainers/scripts/check-cherry-picks.sh#L52-L59
I still fail to understand what is it exactly that warrants inspection | 08:57:17 |
| SomeoneSerge (matrix works sometimes) | Oh mornings are hard | 08:57:29 |
| aidalgol | A comment for the conditional on line 52 would help a lot. | 09:15:25 |
| 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 (burnt/out) (UTC-8) | is it irritating to anyone else that nixpkgs-review uses allowBroken = true | 02:01:43 |
| connor (burnt/out) (UTC-8) | Similar to OfBorg, that means we can't guard broken evaluations behind meta.broken | 02:04:58 |
| connor (burnt/out) (UTC-8) | 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 (burnt/out) (UTC-8) | 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 (burnt/out) (UTC-8) | I rented a Hetzner server to host cantcache.me... their 7950x3D idles about 15C hotter than mine | 19:33:01 |
| connor (burnt/out) (UTC-8) | The alternative was Equinix, which was much more expensive | 19:34:14 |
 hexa (UTC+1) | ugh yeah, eqx mtl is prohibitively expensive 😄 | 19:54:00 |
| 30 May 2024 |
| connor (burnt/out) (UTC-8) | 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 (UTC+1) | 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 (burnt/out) (UTC-8) | 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 (burnt/out) (UTC-8) | 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 |
