| 10 Mar 2026 |
 Puna | yes, but if you pass i.e. "bla", it doesn't provide any suggestions anymore | 06:31:12 |
 amaan | oh yeah, that's a good point | 06:31:27 |
| Puna | oh, way to go is prolly
let
pageSizeMap = {
"4" = 12;
"16" = 14;
"64" = 16;
};
in
assert lib.asserts.assertOneOf "pageSizeKiB" (toString pageSizeKiB) (
builtins.attrNames pageSizeMap
);
| 06:32:23 |
| amaan | i guess this works?
assert lib.asserts.assertMsg (builtins.isInt pageSizeKiB)
"jemalloc: pageSizeKiB must be an integer (one of 4, 16, or 64), got: ${toString pageSizeKiB}";
| 06:32:41 |
| amaan | i guess this works?
assert lib.asserts.assertMsg (builtins.isInt pageSizeKiB)
"jemalloc: pageSizeKiB must be an integer (one of 4, 16, or 64), got: ${toString pageSizeKiB}";
| 06:32:45 |
| amaan | tho maybe yours is better | 06:32:54 |
| Puna | error: pageSizeKiB must be one of [
"16"
"4"
"64"
], but is: "bla"
| 06:33:02 |
| amaan | yea that is nice | 06:33:11 |
| amaan | though, not a fan of how it renders the list on multiple lines in this case | 06:35:27 |
| amaan | let
pageSizeMap = {
"4" = 12;
"16" = 14;
"64" = 16;
};
in
assert lib.asserts.assertMsg
(builtins.hasAttr (toString pageSizeKiB) pageSizeMap)
"jemalloc: pageSizeKiB must be one of 4, 16, or 64, but is: ${toString pageSizeKiB}";
error: jemalloc: pageSizeKiB must be one of 4, 16, or 64, but is: bla
thoughts on this? | 06:36:20 |
| Puna | requires manual updates of the supported values in the string | 06:37:16 |
| Puna | (if another supported size is ever added, that is) | 06:37:49 |
| amaan | yeah true;
let
pageSizeMap = {
"4" = 12;
"16" = 14;
"64" = 16;
};
in
assert lib.asserts.assertMsg (builtins.hasAttr (toString pageSizeKiB) pageSizeMap)
"jemalloc: pageSizeKiB must be one of ${lib.concatStringsSep ", " (builtins.attrNames pageSizeMap)}, but is: ${toString pageSizeKiB}";
is a bit better then | 06:38:14 |
| Puna | i think at that point you're just reinventing assertOneOf, but without the multi-line printing 😅 | 06:39:14 |
| amaan | true...then that's fine | 06:39:24 |
| amaan | (i do like the presentation a little bit more but it's nbd) | 06:40:02 |
| amaan | ok, just pushed that | 06:41:54 |
| Puna | seems fine to me, but it's not my package. maybe someone else here who has an opinion on exposing jemalloc's page size setting like this?
https://github.com/NixOS/nixpkgs/pull/498442 | 07:54:27 |
 Alyssa Ross | IMO we should always use the highest possible page size for jemalloc | 11:08:36 |
| Alyssa Ross | so this is a good change | 11:08:41 |
| Puna | kernel apparently also has a setting for 256k page size, CONFIG_PPC_256K_PAGES for POWER. says it needs patched binutils though. | 11:27:53 |
| Puna | not something i wanna test 😅 | 11:28:07 |
|  Aelin joined the room. | 16:11:19 |
| Aelin | I've never seen a 256k page size POWER system, 64k is the standard nowadays so that change is very reasonable | 16:12:34 |
| Aelin | so, ppc64 VMs are special because they basically scan all disks (which should use MBR, but SLOF can also handle GPT) for a ppc prep boot partition, which is the partition that GRUB is installed to | 16:14:24 |
| Aelin | the prep boot partition needs to be marked as bootable | 16:14:34 |
| Aelin | this is entirely unlike any physical ppc64 hardware which in OPAL just all use petitboot to my knowledge | 16:15:05 |
| 11 Mar 2026 |
|  @somasis:matrix.org left the room. | 03:49:38 |
| 23 May 2021 |
|  @grahamc:nixos.org set the history visibility to "world_readable". | 12:23:31 |
| @grahamc:nixos.org changed the room name to "" from "". | 12:23:31 |
