| 24 May 2025 |
 leona | i think the inconsistency is what they meant | 08:37:42 |
 raf | * Looking at this now, I'm not sure appending .enable to the texts is strictly necessary. It seems to me like the motivation for using programs.foo for the text, but programs.foo.enable, is that it's not possible to link just programs.foo. It might also be inaccurate to write "available as programs.foo.enable" but I can open a PR now to switch all of them | 08:38:49 |
| raf | Checking right now which one of the links are valid right now | 08:39:38 |
| raf | * Checking right now which one of the links are valid | 08:39:44 |
| raf | Okay, interesting discovery: neither https://nixos.org/manual/nixos/stable/options#opt-services.kimai.enable nor https://nixos.org/manual/nixos/stable/options#opt-services.kimai link to the correct position for me. Tested on both Chromium and Firefox, could someone check if it links to the correct pos for them? | 08:43:25 |
| leona | probably it needs to be https://nixos.org/manual/nixos/stable/options#opt-services.kimai.sites, as services.kimai (nor .enable) doesn't exist | 08:43:33 |
| raf | I see, in that case do we want to use .enable for modules that have it, and the first available option for modules that don't? | 08:46:28 |
| leona | i think that is the best option, yes | 08:47:19 |
| raf | Got it, submitting a PR shortly | 08:48:57 |
| leona | thanks! | 08:48:22 |
| raf | Just to confirm, #opt-services, #opt-programs, etc. all lead to the options page automatically, correct? I've noticed that some links do options.html#opt-... but the options.html part is redundant if this is the case, unless there is a reason they are included in the links I'll be removing those | 09:01:39 |
 Arian | In reply to @hexa:lossy.network
cc Arian 👀 Yes just remove that reference. It's unused | 09:03:42 |
 hexa | It was removed during the release call. | 09:04:04 |
| Arian | Awesome | 09:04:10 |
| Arian | The AMIs for 25.05 are uploading now too | 09:04:57 |
| leona | i think this is right | 09:16:54 |
| raf | I've opened a PR that fixes those plus the aforementioned inconsistencies. Also fixes the redundant use of options.html. There are a few I've missed, but I'll fix those after lunch. In the meantime, could someone tell me where (if at all) a warning/guideline for adding new entries to the release notes would go? I think we'd like to avoid such usage in the future. | 09:20:18 |
 misuzu | Maybe here? https://github.com/NixOS/nixpkgs/blob/master/doc/README.md#documentation-conventions | 10:02:30 |
| raf | https://github.com/NixOS/nixpkgs/pull/410452 is complete, ready for a reeview | 10:12:45 |
|  leoperegrino joined the room. | 13:03:46 |
|  Alaa Elsamouly joined the room. | 17:12:22 |
| 25 May 2025 |
 lennart | hej, did not skim the backlog, so please excuse if this is already known: in 25.05's release notes, it says "NixOS" in the heading where it should read "Release", also the date (23rd) wasn't added to the title. https://nixos.org/manual/nixos/stable/release-notes#sec-release-25.05 | 06:13:41 |
 emily | I think the former is intentional | 09:55:38 |
| emily | we now have separate Nixpkgs release notes | 09:55:45 |
| lennart | ah I see | 11:07:22 |
| leona | The former is intentional, but was still changed. Also I updated the flake input for nixos-homepage, but the docs didn’t update. I don’t really know why | 11:47:32 |
 VladimÃr ÄŒunát | https://nixos.org/manual/* should follow channels, so that's why it's lagging? | 12:02:55 |
| emily | perhaps we should make the past release notes say NixOS/Nixpkgs … too? | 13:10:15 |
| emily | for clarity as to the difference | 13:10:18 |
| emily | (but it may not matter.) | 13:10:25 |
