| 13 Sep 2025 |
|  oak 🏳️🌈♥️ changed their profile picture. | 09:46:03 |
| 14 Sep 2025 |
|  @emma:rory.gay joined the room. | 08:39:56 |
 connor (burnt/out) (UTC-8) | Duncan Gammiethanks for the PR! I’ll try to review it soon, things have just been | 18:22:54 |
| 15 Sep 2025 |
| connor (burnt/out) (UTC-8) | Gaétan Lepage: as someone who has contributed to nixpkgs-review previously, how difficult do you think it would be to add functionality which tells you if packages were broken on the base commit? As an example, working on foundational CUDA packaging changes the store output paths of basically everything which relies (transitively) on CUDA. That includes a whole bunch of Python packages which are just usually broken but we're unaware of.
I'd like to be able to run nixpkgs-review and have it tell me, in addition to the number of packages which failed to build as a result of the PR, which ones were already broken on the base commit.
Would that involve a secondary stage of builds wherein all the packages which failed to build and already exist on the base commit are tried? | 02:57:42 |
 Gaétan Lepage | This would be an amazingly useful feature. Every maintainer is facing the same issue all the time.
I have certainly already thought about it.
However, this is not too simple. At least, we cannot induce this information from the raw information we have.
nixpkgs-review currently works like this:
- Compute (or fetch) which outPaths have been changed between the base commit and the new one. -> Deduct the set of packages that need to be rebuilt.
- Rebuild those (which are not marked as broken/unsupported) and report the successes/failures.
There is no notion of previous brokenness in what nixpkgs-review knows.
What would be a solution, would be to fetch hydra and gather the latest status of each target package. This would be the easiest way to do it. | 09:52:30 |
| connor (burnt/out) (UTC-8) | Rather than querying Hydra, do you think it would be enough to query all the substitutes the system has configured to see if it’s already cached (indicating success)? That way if it’s something the user has already built on a different machine or has in a different cache, that would be searched. | 14:55:32 |
| connor (burnt/out) (UTC-8) | Lastly, I was looking at the way the list of attributes are generated yesterday. I think I can greatly speed that up and have us benefit from caching.
For example, I was working on an eval-devs CLI addition for Nix based on the parallel evaluator Eelco was working on which also uses the evaluation cache. The idea being that all the evaluation happens in parallel, and the results are cached in the evaluation cache, so if you’re working on your PR and running nixpkgs-review multiple times as you fix things, so long as you keep the same base commit (and use —merge commit or whatever the flag is for nixpkgs-review) you can re-use the evaluation you’ve already compute for the base every time you re-run the review. | 14:58:35 |
| connor (burnt/out) (UTC-8) | Of course, that’s using DetSys Nix, so I’d probably just keep that in my fork to see if it’s worthwhile, but 🤷♂️ | 14:59:22 |
| connor (burnt/out) (UTC-8) | I have so many other un-fun things I have to do 😖 | 15:00:14 |
| Gaétan Lepage | Maybe we should keep discussing this in https://matrix.to/#/#nixpkgs-review:matrix.org. | 15:31:11 |
| connor (burnt/out) (UTC-8) | SomeoneSerge (back on matrix)what are we going to use for video calls for our weekly? Signal was fine when it was just us, but my work blocks Jitsi and video calls over matrix. | 15:55:39 |
| Gaétan Lepage | Signal should work just fine with a handful people. | 19:33:45 |
| Gaétan Lepage | When is the next meeting btw? | 19:33:54 |
| Gaétan Lepage | If I understand you correctly, you want to build a local "cache" of build successes/failures? | 19:34:34 |
| Gaétan Lepage | For the second part of your message, you are talking about the "local" evaluation right? We already fetch the eval results from the GHA runs. | 19:35:13 |
 SomeoneSerge (back on matrix) | Should we try eight tomorrow? | 22:40:34 |
| SomeoneSerge (back on matrix) | ^ | 22:40:44 |
| Gaétan Lepage | Sure, which timezone? AM or PM? | 22:43:55 |
| SomeoneSerge (back on matrix) | am, pacific, iirc | 23:03:24 |
| 16 Sep 2025 |
| connor (burnt/out) (UTC-8) | Pacific, AM | 00:35:16 |
| connor (burnt/out) (UTC-8) | 8am would be nice | 00:35:46 |
| Gaétan Lepage | OK, should be fine! | 08:09:35 |
| SomeoneSerge (back on matrix) | In reply to @connorbaker:matrix.org
8am would be nice @justbrowsing:matrix.org: if you're around? | 10:54:05 |
|  Kevin Mittman (UTC-7) changed their display name from Kevin Mittman to Kevin Mittman (UTC+9). | 11:11:43 |
| Kevin Mittman (UTC-7) | sorry it's 8pm and trying to go to sleep to shake off the jet lag | 11:13:09 |
 ysndr | In reply to @glepage:matrix.org
Signal should work just fine with a handful people. Is there a separate signal group to join, or how would one get into the call? | 12:12:40 |
| Gaétan Lepage | https://signal.group/#CjQKIK7-VLKtqJFT25O_L_5KG1ITydK2Of0zZRau1SPGjuAHEhDIdWbcfVXKTI_ByFI1lY1L | 12:20:32 |
| 17 Sep 2025 |
|  BerriJ joined the room. | 16:08:43 |
| 18 Sep 2025 |
| connor (burnt/out) (UTC-8) | I’ve got a long day ahead of me, but SomeoneSerge (back on matrix)to follow back up on earlier, in https://github.com/NixOS/nixpkgs/pull/437723 I made changes to config to allow NVIDIA’s licenses when cudaSupport is true. That means users can build CUDA packages without using the impure flag and providing a custom config with allowUnfree, allowUnfreePredicate, or allowlistedLicenses, just by building off of pkgsCuda or pkgsForCudaArch. I think that’s important for the UX. Also, since we don’t need the impure flag we can benefit from evaluation caching.
Like all Nixpkgs “variants” (the term I’ve seen used to describe different instantiations of Nixpkgs within Nixpkgs, like pkgsLLVM), there is an evaluation cost to using those attributes, but it beats repeatedly editing a config.nix file.
Of course, for out-of-tree consumers (like user flakes) configuring Nixpkgs exactly once when it is imported is preferred, but not everyone can or wants to do that. | 16:13:20 |
| connor (burnt/out) (UTC-8) | In further iterations I’ll try to move the licenses into lib.licenses so they’re available there instead of in _cuda.lib.licenses; we should be using those licenses instead of ad-hoc ones anyway. | 16:15:14 |
