| 28 Jun 2026 |
 Grimmauld (any/all) | I'd want:
a directory of contributing docs markdown, same format as our other docs nix code blocks are syntax-checked
- bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow
one file per common pattern, potentially with examples a list of useful tools and when to use them
- git-merge-base master staging
- tell people to STOP WASTING COMPUTE with nixpkgs-review without thinking
- tell people to think? XD
explicitly document what we expect from
- a new contributor
- a new package/module
- exiting packages/modules
- existing contributors/committers
- how to do (good) reviews that are useful, even if the reviewer is not a committer
- includes security considerations
where/how to find
- help
- examples
- "inspiration" from how other distros do things (and how that translates to nix)
a proper style guide
| 21:37:56 |
| Grimmauld (any/all) | okay formatting got butchered in my matrix client.... | 21:38:08 |
| Grimmauld (any/all) | I'd want:
- a directory of contributing docs
- markdown, same format as our other docs
- nix code blocks are syntax-checked
- bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow
- one file per common pattern, potentially with examples
- a list of useful tools *and when to use them*
- `git-merge-base master staging`
- tell people to STOP WASTING COMPUTE with `nixpkgs-review` without thinking
- tell people to think? XD
- explicitly document what we expect from
- a new contributor
- a new package/module
- exiting packages/modules
- existing contributors/committers
- how to do (good) reviews that are useful, even if the reviewer is not a committer
- includes security considerations
- where/how to find
- help
- examples
- "inspiration" from how other distros do things (and how that translates to nix)
- a proper style guide
| 21:38:19 |
| Grimmauld (any/all) | ther,e thats a bit less awful+ | 21:38:34 |
| Grimmauld (any/all) | * there, thats a bit less awful | 21:38:39 |
 emily | I somewhat like having the contributor docs "right there" on GitHub in a way but I also feel like it might be more discoverable if we just had a "Nixpkgs contributors manual" alongside the others | 21:38:58 |
| emily | I get the sense that people are often surprised that we have a bunch of relevant docs that don't appear in the manuals at all | 21:39:09 |
| Grimmauld (any/all) | manual is just markdown anyways | 21:39:15 |
| Grimmauld (any/all) | it'd be in github, in some sense | 21:39:22 |
| emily | I think these ideas are good, I honestly think the top challenge is just organizing things hierarchically in a way that's useful. you ideally want a top-level document that covers "if you only have 5 minutes to read things, here are the most important things to know", and then you can drill down from there to "if you only have 10 minutes to read about this specific task, …" and so on | 21:40:41 |
| Grimmauld (any/all) | I'd want:
- a directory of contributing docs
- markdown, same format as our other docs
- nix code blocks are syntax-checked
- bonus point if nix code blocks are reasonably easy to eval in a repl to poke somehow
- one file per common pattern, potentially with examples
- a list of useful tools *and when to use them*
- `git-merge-base master staging`
- tell people to STOP WASTING COMPUTE with `nixpkgs-review` without thinking
- tell people to think? XD
- common workflows
- staging
- backport
- bot update
- bot merge
- channel bumps?
- explicitly document what we expect from
- a new contributor
- a new package/module
- exiting packages/modules
- existing contributors/committers
- how to do (good) reviews that are useful, even if the reviewer is not a committer
- includes security considerations
- where/how to find
- help
- examples
- "inspiration" from how other distros do things (and how that translates to nix)
- a proper style guide
| 21:40:53 |
| emily | delivering the core principles upfront and then getting into rules-lawyering further down | 21:41:01 |
| Grimmauld (any/all) | i suspect if i start working on something like this, i'll just end up strongly suggesting my own preferences to everyone XD | 21:42:05 |
| emily | sounds like you have the drive and the vision, you're hired :p | 21:45:29 |
| Grimmauld (any/all) | In reply to @emilazy:matrix.org
sounds like you have the drive and the vision, you're hired :p If only it were that easy to actually do it | 21:48:35 |
 hexa | I mean, nixpkgs core has authority | 21:49:24 |
| hexa | and someone needs to make a proposal to get us startd | 21:49:34 |
| Grimmauld (any/all) | Okay that is a fair point. Getting started should just be the "5min version" with links going to stubs, and some ci on it. Doesn't sound that bad.... | 21:51:18 |
| Grimmauld (any/all) | But please don't hold me to that, its late and I haven't slept much in recent days, I am sure I'll regret my folly in due time | 21:52:09 |
| hexa | > -- Could NOT find Manette (missing: Manette_INCLUDE_DIR Manette_LIBRARY) (Required is at least version "0.2.4"
> CMake Error at Source/cmake/OptionsGTK.cmake:267 (message):
> libmanette is required for ENABLE_GAMEPAD
> Call Stack (most recent call first):
> Source/cmake/WebKitCommon.cmake:250 (include)
> CMakeLists.txt:16 (include)
| 21:59:02 |
| hexa | /nix/store/z625r15ydhwqx977cyfj4rmpz7l6mms7-webkitgtk-2.52.4+abi=4.1.drv | 21:59:27 |
| hexa | via networkmanager-openconnect | 21:59:41 |
| hexa | because yes, I need gamepad support for openconnect | 21:59:58 |
| 29 Jun 2026 |
 Myria | This seems worrying: https://hydra.nixos.org/build/333281431 | 01:14:23 |
| Myria | Would this be a gc problem? | 01:14:33 |
 Vladimír Čunát | Yes, there's been lots of these. | 05:50:57 |
 K900 | https://github.com/scipy/scipy/issues/25488 | 09:10:26 |
| K900 | Scipy has more weird float precision issues | 09:10:32 |
| K900 | Going to skip that test once I confirm it builds on my 3588 | 09:10:45 |
| K900 | Skipped that test, found another test that's also flaky | 09:31:43 |
