03:31 <chadmed> sam_: leio: https://github.com/gentoo/gentoo/pull/41546

03:31 <chadmed> only thing im not sure about is the splitting of the LLVM deps. should i ask in #gentoo-desktop?

08:57 <leio> chadmed: the REQUIRED_USE of vulkan looks wrong to me; does it fail to build something else when vulkan is disabled, like I assume is the case without opencl?

09:00 <maverick46> Is anyone online?

09:15 <jannau> vulkan is not required. neither is opencl but the driver needs the opencl dependencies as build deps

09:39 <chadmed> so REQUIRED_USE asahi? ( llvm ) and then replicate the opencl deps in the llvm_gen_dep thing like we do currently in the overlay

09:54 <mps> latest mesa-asahi still fails to build on my alpine system

10:05 <jannau> how is it handled for intel? does it simply dependen on externall build intel-clc for the build?

10:08 <jannau> mps: specifically the asahi driver? what is latest mesa asahi-20250221?

10:10 <chadmed> jannau: intel just pulls in libclc, but i thought we needed opencl at runtime too

10:15 <mps> jannau: yes, mesa asahi-20250221

10:18 <mps> error is

10:18 <mps> ninja: job terminated due to signal 5: /work/aports/testing/mesa-asahi/src/mesa-asahi-20250221/output/src/compiler/spirv/vtn_bindgen2 src/asahi/libagx/libagx.spv src/asahi/libagx/libagx.cpp src/asahi/libagx/libagx.h

10:49 <jannau> chadmed: I suspect we can add support to mesa_clc to build asahi_clc, not sure if it's worth adding asahi_clc as indepedent package

10:55 <chadmed> i dont think a separate package makes much sense. id rather not contribute to the fragmented state of opencl-related tooling

10:55 <chadmed> in the meantime ill just copy what we do in the overlay with the replicated llvm required use

10:55 <jannau> that's why I want to add it to mesa_clc

10:56 <chadmed> that requires changes to mesa upstream, yes?

10:57 <chadmed> i fully agree with you btw, i just mean we do the overlay thing until mesa_clc has what we need

10:57 <jannau> yes but minor ones

10:58 <jannau> I want to get this into mesa 25.1-rc1

11:01 <jannau> it might not need changes

11:02 <chadmed> did alyssa already do this with 3b1166da?

11:04 <jannau> that's not all. we still need asahi_clc

11:11 <chadmed> so what do we need to do to integrate it with mesa_clc? it seems quite bespoke

11:54 <flokli> chaos_princess: I added a few pr_info! statements, it fails at the `data.patch_bootargs` call

11:55 <chaos_princess> how old is your install

11:55 <flokli> chaos_princess: old, I recall having to manually do something to get webcam to work

11:55 <flokli> or you mean which version of MacOS is installed?

11:56 <chaos_princess> what firmware version is your install using

11:56 <flokli> is that printed somewhere?

11:57 <chaos_princess> it is somewhere in the device tree, probably under chosen

11:57 <flokli> asahi,system-fw-version ?

11:57 <chaos_princess> shuould be

11:57 <flokli> "unknown"

11:58 <chaos_princess> what other version-like things are there

11:59 <flokli> asahi.iboot1-version iBoot-11881.81.2 / asahi.iboot2-version iBoot-7459.121.3 / asahi,os-fw-version 12.4

12:00 <chaos_princess> asahi,os-fw-version 12.4 - the culprit

12:00 <chaos_princess> BOOTARGS_OFFSET and BOOTARGS_SIZE are different on 12.4

12:00 <chaos_princess> so, either update to 13.5 or patches welcome

12:01 <flokli> I'd prefer updating I think :-D

12:03 <flokli> so is this updating macos, or running asahi-fwextract?

12:03 <chaos_princess> this is re-installing the apfs stub

12:13 <Zeroine> Hi

12:20 <chadmed> Zeroine: folks typically dont respond to "hi" or "anyone there" on irc

12:22 <Zeroine> Eh, depends on who you're talking to.

12:23 <Zeroine> I wasn't born with IRC but I've been hanging out here for a few years now.

12:33 <flokli> chaos_princess: sorry for my stupidity, but I don't know how to do this, and looking around in the docs didn't help much. I ran the asahi-installer, and that upgraded m1n1 stage1 from 1.2.9 to 1.4.14, but didn't change asahi,os-fw-version

12:34 <jannau> chadmed: you're right, we need clc/llvm at runtime. sorry

12:34 <chaos_princess> you have to completely remove the apfs and efi paritions, do a completely new uefi-only install, and then re-create whatever bootloader files are needed on new esp

12:35 <jannau> copy the m1n1 and EFI folders from the old ESP

12:35 <jannau> and everything else which is not firmware

12:36 <jannau> the installation log from the initial install m,ight be interesting as well but is essentially useless now

12:37 <flokli> so backup contents from current apfs somewhere, use diskutil to delete that partition, run asahi linux installer, copy things back to new apfs partition

12:37 <jannau> chadmed: I noticed only after I had everything in place

12:38 <chaos_princess> from esp, apfs shouldn't contain anything of vault

12:38 <jannau> I don't think we keep anything interesting on the apfs, just the ESP

12:39 <flokli> ok, but I delete both ESP and NixOS APFS, gotcha

12:40 <jannau> if the nixos apfs has an customized volume icon that's could be saved. .Volume*.icns or so

12:42 <jannau> please do backups first, if you have enough space in the macos apfs partition you could resize that by 3GB and do a separate uefi-only install first

12:43 <chadmed> jannau: no stress at all. ill sort out the MR tomorrow to just do what we do in the overlay for now

13:18 <flokli> chaos_princess: hello from asahi,os-fw-version 13.5

13:35 <chadmed> flokli: mics should work now :)

13:36 <flokli> i still need to do the firmware dance, but working on it :-)

13:43 <flokli> yes, with the new firmware aop probes properly, and I now see a microphone. I'll test if it actually records proper sound later. Thanks :-)

14:16 <noisycoil[mds]> chadmed: Probably documenting the firmware requirements for mics is a good idea. Fedora was never affected, but the fw thing keeps happening to most who installed alt distros earlier than that

14:17 <noisycoil[mds]> We had 3 just in Debian

15:03 <Zeroine> Thanks for any answers in advance =)

15:03 <Zeroine> I've got several questions about OpenBSD on the M1 Air so I made a paste https://bpa.st/FJVQ

15:32 <flokli> Is there any hard-coding of esp partition uuids in the apfs stub?

15:33 <chaos_princess> yes, the installed m1n1 stage 1 has a reference to the esp

15:33 <jannau> not in the apfs stub but in the installed 1st stage m1n1

15:34 <flokli> I successfully deleted the old apfs container and esp, and now wanted to grow the "new" esp past the space freed by the old ones. But it seems fatresize crashes on Asahi (page size assumptions maybe?) and MacOS cannot grow vfat

15:34 <flokli> At least not the graphical disk utility app

15:35 <chaos_princess> try gparted

15:35 <flokli> It ranted about something and told me I can still try if I'm desperate

15:35 <flokli> I'm wasn't sure I wanted to be that desperate:-D

15:36 <jannau> do you have use for larger esp?

15:36 <flokli> Yes, NixOS stores different generations of initrd and kernels

15:36 <flokli> And it runs out of space very quickly

15:37 <jannau> ah, fedora uses a separate /boot partition

15:39 <flokli> "The information sector has the wrong signature (0). Select cancel for now, and send in a bug report. If you're desperate, it's probably safe to ignore"

15:40 <flokli> /nix/store/zysnblhy9yakqj6v3n85f9pg47pn8x2d-gparted-1.7.0/bin/.gparted-wrapped: line 231: 6478 Segmentation fault (core dumped) $BASE_CMD

15:40 <flokli> ah well

15:47 <tpw_rules> flokli: (been very busy with work sorry about the maintenance) you can set UUIDs with gdisk

15:47 <tpw_rules> m1n1 looks for the GPT one, not the FAT one

15:51 <flokli> tpw_rules: Ok, so I'll just copy things to a new vfat sized properly, and force the partuuid to the old one. Thanks.

15:51 <flokli> And no worries, we all have IRL stuff :-)

15:53 <tpw_rules> flokli: bingo. you can also regenerate the necessary-for-boot parts of the ESP completely with nixos-install and a flash drive, but of course the asahi installer writes logs and firmware it would be annoying to lose

15:53 <tpw_rules> also also you can limit the number of generations in your config and lessen the chance of filling it up

15:54 <flokli> True, though I cannot really reclaim the space properly for MacOS either. So might as well use it for ESP ;-)

15:56 <flokli> tpw_rules: now I have you here, I'm wondering if we can make the UX a bit nicer and get NixOS to "discover" the firmware without looping it into evaluation

15:57 <flokli> There's a cpio archive, sd-boot can probably concatenate it to the initrd and we pass it on from there, rather than being forced to set hardware.firmware to it

15:57 <flokli> I'll probably toy around with this a bit in the next few days. In addition to bumping some more PRs.

18:09 <flokli> Partition GUID surgery was successful, btw :-)

21:31 <jannau> chadmed: I'm using https://paste.centos.org/view/3b04f721 (running 6.14.2-1 with stable uapi patches on j314)

21:36 <chadmed> yep awesome thats pretty close to the overlay

21:36 <chadmed> ill have coffee and sort out the MR :)

21:41 <leio> https://github.com/gentoo/gentoo/pull/41203 is also pending, fwiw

21:47 <chadmed> still have to figure out this dist-kernel mess too

21:48 <chadmed> im kind of out of ideas apart from asahi profiles at this point but i really dont think thats a can of worms we want to open

21:58 <jannau> I should update that. I don't think the lower minimum in the overlay actually works. I certainly don't test anything but Fedora's stable rust (possible trailing by a few days)

22:12 <tpw_rules> flokli: it's been posited, but i never liked it cause you have to have python in the initrd to extract it

22:12 <tpw_rules> or figure out how to detect that the python version changed and re-execute the extractor

23:12 <Zeroine> Anybody know how to get the bwfm interface working in OpenBSD? OpenBSD's install script should take care of this but apparently it's broken so I think I'd have to get it from firmware.tar on the EFI partition. On the OpenBSD mailing list there's complaints of bwfm not working and not appearing in dmesg since around the 14.5 MacOS version update. I don't see anything in dmesg either but I thought this was because I don't have the

23:12 <Zeroine> firmware installed.

23:12 <Zeroine> I can give more details and links, just didn't wanna make the question too long.

23:13 <chadmed> you should have asahi-fwupdate or some analogue that installs the apple-specific firmware to wherever openbsd needs it to be

23:13 <chadmed> the firmware for the wifi/bt card comes from the system and is not redistributed in linux-firmware or anything like that

23:15 <Zeroine> chadmed: yeah, that'd be fw_update but it doesn't seem to install it, I tried installing with ethernet connected as well but it only got the apple-boot-firmware

23:16 <chadmed> not sure why kettenis isnt in #asahi-alt but he maintains the openbsd stuff afaik

23:17 <Zeroine> yea, I've seen him chat about OpenBSD a lot while looking through IRC logs

23:18 <Zeroine> I think the WiFi firmware is only installed once you're actually installing OpenBSD, there's a script that I think should do this https://raw.githubusercontent.com/openbsd/src/cb90b220d83d832a1df01974a385a7822a9a2fab/distrib/arm64/ramdisk/install.md

23:18 <Zeroine> Maybe fw_update doesn't deal with the WiFi firmware then, I don't know

23:26 <chadmed> jannau: dont we also need libclc at runtime, not just a BDEPEND?

23:46 <chadmed> aaa we cant do "if use" outside of functions anyway

23:52 <tobhe_> Zeroine: release or snapshot?

23:53 <Zeroine> the 6.7 release

23:53 <tobhe_> there was a bug in 6.7, let me see if I find some info

23:53 <tobhe_> I think snapshot works better

23:53 <tobhe_> s/6.7/7.6/

23:53 <tobhe_> or you wait a few days for 7.7 :)

23:54 <Zeroine> oh yeah, my bad =D

23:54 <Zeroine> I'll try a snapshot then

23:57 <tobhe_> since we are in freeze the current snapshot is pretty much 7.7 anyway

23:58 <Zeroine> ah

23:58 <tobhe_> https://ftp.openbsd.org/pub/OpenBSD/patches/7.6/common/004_aplsmc.patch.sig

23:58 <tobhe_> this was the issue

23:59 <tobhe_> something changed in the firmware, broke aplsmc and that broke the check in the installer to activate the asahi firmware extraction special sauce