| 9 Apr 2026 |
|  Lisanna changed their profile picture. | 22:02:08 |
| Lisanna changed their profile picture. | 22:12:31 |
| Lisanna changed their profile picture. | 23:14:54 |
| 11 Apr 2026 |
|  Aditya Gaurav changed their display name from gaurav_aditya to Aditya Gaurav. | 01:38:10 |
|  Robert Hensing (roberth) invited  kiara. | 09:43:17 |
| kiara joined the room. | 12:14:51 |
| 12 Apr 2026 |
 Jacobus Burger | How is everyone doing today? | 01:20:16 |
 Allan Dinakaran | Good how about you? | 02:24:52 |
| kiara | In reply to @sanskar-0day:matrix.org
Hey @roberthensing:matrix.org (and anyone else around), I'm looking into the Modular Services GSoC project and had a quick architecture question.
Since the project description explicitly requires keeping the user-facing options of the NixOS module the same, I’m curious about the intended migration strategy. Is the plan to manually wire up the legacy global options to the new modular backend for each service one-by-one? Or is the goal to build a standardized abstraction (like a mkModularService wrapper) that automatically bridges the legacy options to the new modular instances? this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db) or spin up a set of similar services | 07:55:28 |
| kiara | Redacted or Malformed Event | 07:56:29 |
| kiara | * this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db) or spin up [a set of similar services](https://github.com/NixOS/nixpkgs/pull/506645) | 08:21:36 |
| kiara | * this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db, example test at [contracts PR] (https://github.com/NixOS/nixpkgs/pull/506343)) or spin up [a set of similar services](https://github.com/NixOS/nixpkgs/pull/506645) | 08:24:14 |
| kiara | * this seems hard to automate since a nixos service module doesn't in a straight-forward manner map to a (systemd) service - they can span heterogeneous services (e.g. need a db, example test at [contracts PR](https://github.com/NixOS/nixpkgs/pull/506343)) or spin up [a set of similar services](https://github.com/NixOS/nixpkgs/pull/506645) | 08:24:38 |
| Aditya Gaurav left the room. | 10:42:34 |
|  Scrumplex joined the room. | 18:43:59 |
| 13 Apr 2026 |
|  Thiago Macedo left the room. | 05:16:49 |
| 18 Apr 2026 |
|  Saaid left the room. | 18:39:10 |
| Scrumplex left the room. | 20:32:23 |
| 19 Apr 2026 |
|  comonad joined the room. | 09:23:26 |
| 20 Apr 2026 |
|  @ninio_artillero:kde.org left the room. | 22:05:26 |
| 23 Apr 2026 |
|  天川理音 joined the room. | 07:41:40 |
|  not-jack left the room. | 12:27:31 |
| 24 Apr 2026 |
|  hytero joined the room. | 05:42:01 |
| hytero left the room. | 05:49:59 |
| 25 Apr 2026 |
|  kekser joined the room. | 23:12:39 |
| 27 Apr 2026 |
|  Ninja joined the room. | 14:57:14 |
| 29 Apr 2026 |
 Sanskar | kiara: Reading through the easyturn (#506645) and contracts (#506343) PRs more carefully, I think I get now why a generic wrapper doesn't work.
They're actually two different failure modes: easyturn breaks because a flat legacy option space can't map to named instances without knowing the cardinality upfront, while contracts breaks because the module spans a runtime dependency graph that has no single modular equivalent.
One thing I'm still not clear on: if the contracts PR lands, does migration for a dependent service become two separate steps? First map it to its modular shape, then manually audit and add the contract declarations? Or is there a way the contract requirements get derived from the existing config references?
| 11:01:22 |
| kiara | In reply to @sanskar-0day:matrix.org
kiara: Reading through the easyturn (#506645) and contracts (#506343) PRs more carefully, I think I get now why a generic wrapper doesn't work.
They're actually two different failure modes: easyturn breaks because a flat legacy option space can't map to named instances without knowing the cardinality upfront, while contracts breaks because the module spans a runtime dependency graph that has no single modular equivalent.
One thing I'm still not clear on: if the contracts PR lands, does migration for a dependent service become two separate steps? First map it to its modular shape, then manually audit and add the contract declarations? Or is there a way the contract requirements get derived from the existing config references?
one could imagine taking an submodule option shape as a request shape, tho the question might be what to take as the result if we wanna infer things: none? same submodule tree?
like the honest answer here is i haven't actually tried to do this yet. | 11:13:04 |
|  Swaraj set a profile picture. | 14:47:53 |
|  KangYu Peng joined the room. | 17:28:41 |
