| 7 Mar 2026 |
 Alyssa Ross | uhh, Clang bug? | 17:51:25 |
| Alyssa Ross | oh never mind that's g-ir-scanner | 17:52:33 |
| Alyssa Ross | not Clang | 17:52:39 |
 matthewcroughan | Only happens in this one context, and not in the other contexts | 18:00:42 |
| matthewcroughan | So native, native-musl native-llvm-musl all fine | 18:01:11 |
| matthewcroughan | gnu-musl I think is fine too, so must be the llvm | 18:01:39 |
| Alyssa Ross | I would:
- Check with glib that this is definitely not a glib bug (doesn't look like it)
- Report to LLVM
hardeningDisable = [ "stackprotecter" ]; in glib with a link to the LLVM bug report
| 18:02:55 |
| matthewcroughan | 
Download image.png | 18:03:03 |
| matthewcroughan | asdjfhasdjfhgsadfjkg | 18:03:05 |
|  Lotte (it/its)/Cinny (she/her) θΔ& changed their profile picture. | 21:27:51 |
| 8 Mar 2026 |
| matthewcroughan | Hmm, I added hardeningDisable to an overlay, it didn't seem to work exactly | 17:21:47 |
| matthewcroughan | Is this another case where you can't overlay it, and you have to fix it in nixpkgs because of bootstrap stuff? | 17:22:01 |
| matthewcroughan | like with bash | 17:22:04 |
| matthewcroughan | I notice the build graph starts off with a glib that does get fixed, and then ends on another glib which is not fixed | 17:22:22 |
| matthewcroughan | 
Download image.png | 17:22:43 |
| Alyssa Ross | hmm, maybe it's from some library glib links or something, then? maybe you can catch it in a debugger | 18:49:00 |
| 10 Mar 2026 |
|  amaan joined the room. | 05:34:54 |
 Puna | 👋 | 05:35:11 |
| amaan | hey 👋 | 05:35:51 |
| Puna | so ArchPOWER's ppc64 build has a 64k page size? have you run into any issues with that, or know of any patches they're applying for that to work? | 05:36:53 |
| Puna | i've only ever tested 4K, cus that's what Debian uses | 05:37:21 |
| amaan | yeah i ran into issues building jemalloc which is why i submitted that patch, tho it seems to vary by distro i guess, tbf I just got access to this machine today and figured I'd build a nix iso on it to try it out | 05:37:33 |
| Puna | ahhh oki! | 05:37:48 |
| Puna | do you know how the machine's firmware looks for bootable media? i have some PRs and a branch in my fork that works for making a PowerMac (and maybe CHRP?) compatible ISO, but i don't have access to anything newer than ~ POWER4. | 05:38:57 |
| Puna | the branch in question, if you wanna give that a try: https://github.com/OPNA2608/nixpkgs/tree/wip/ppc64-installer | 05:42:12 |
| amaan | i guess gentoo, suse, and fedora also use 64kb page sizes:
https://github.com/gentoo/genkernel/blob/master/arch/ppc64/arch-config#L26
https://github.com/openSUSE/kernel-source/blob/master/config/ppc64le/default#L559
https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel-ppc64le-fedora.config#_5366
also in the ppc kconfig it defaults to 64kb in certain scenarios interestingly - https://github.com/torvalds/linux/blob/master/arch/powerpc/Kconfig#L853 | 05:42:52 |
| amaan | i am not sure tbh, i just found a zulip that offers free machines to ssh to and dev on tho...they are power8 btw | 05:43:24 |
| amaan | my plan was to build the iso then ask the owner to install it in a dedicated vm to play around on | 05:43:41 |
| Puna | hmm… prolly makes sense to default to the 64K-compatible setting for jemalloc then, just to cover more systems. as said, the 64K setting should work on 4K systems? it might just not be optimal (at least according to an upstream issue on raising the aarch64 default from 4K to 64K).
a function argument to override that would prolly still be nice though - could be interesting for someone measuring the performance impact and deciding to optimise for their system via an overlay.
| 05:52:16 |
| amaan | yeah i think providing a function argument makes sense | 05:53:10 |
