01:50 <derek_> hi

01:51 <derek_> i was wondering how i can install the arch version instead of fedora

02:01 <chadmed> derek_: you can but its deprecated and does not currently receive asahi package updates

02:02 <chadmed> you need to set EXPERT=1 on the installer. you will not get any support for broken stuff.

02:04 <Tramtrist> and things likely will be broke..

02:07 <derek_> chadmed this dude said hes running arch and all teh stuff is updated

02:10 <chadmed> asahi packages arent

02:10 <chadmed> last bump to the pkgbuilds was 4 months ago

02:10 <chadmed> the base ALARM packages are still updated of course

02:13 <derek_> so we won't get updated driverS?

02:14 <derek_> why dont they add arch to alternative distros or something

02:55 <derek_> quit

02:57 <Tramtrist> I think he was sad

06:05 <martin2020> Hi, I am having an issue on m2 Mac Mini, whenever the display goes to sleep or is powered off or is disconnected, I cannot get output to that display to resume again. Is there any workaround I can try? Like, a command I can run from ssh to power-cycle the hdmi daemon or something?

06:06 <martin2020> (I'm not saying there is such a thing as an hdmi daemon, that was just a fanciful idea... the point is, any suggestions of potential workarounds are welcome :)

08:29 <leio> martin2020: the workaround is unplugging the hdmi and replugging again and again until it comes back

08:30 <leio> with higher resolution a couple times for me it went to a state where it didn't work at all anymore, but that's hard to notice without SSH and kernel logs, hopefully for you a couple or a couple minutes of replugging HDMI will work

08:31 <leio> there's some 8 second timeouts on things, so you might want to give it a bit of time after each unplug and replug or you might be unplugging it again when it would have worked with a bit more time given to it

10:50 <Guest1563> Hi, I think I may found a bug. Where can I discuss about it or report it?

10:59 <janneg> Guest1563: Hej this channel or #asahi-dev will work for discussion. Where to report it depends on which component has the bug

12:55 <j2> janneg: It's about gnupg. My gpg may stop working if I change my wifi. There is gnupg_spawn_keyboxd_sentinel.lock - file on my $HOME/.gnupg - folder, that contains some sort of hostname that belongs to my ISP. If the .lock - file exists and I start using my (different) home-wifi, I get `gpg: waiting for lock (held by 13162)`. Changing back to the wifi, that was used when the .lock - file was created, fixes the issue.

12:57 <j2> ChatGPT suggested it could be more of my distro (asahi fedora 39 w/ KDE) related, than gnupg - related :D

13:02 <j2> The issue can be quite annoying, because first I thought that removing the .lock - file would fix the issue. First I tried that and kept getting `gpg: waiting for lock (held by XXXXX).` to output on loop, when calling gpg.

20:00 <martin2020> leio, thanks, I'll see if I can get that to work

20:15 <martin2020> I tried unplugging and re-plugging the hdmi cable 10 times, waiting 15 seconds each time, all with absolutely no response from the idling monitor

20:16 <leio> that is unfortunate. Here I have ended up just keeping it on and rebooting in evening or morning to get back - easier than the plugging tries which sometimes took 5 minutes to yield results

20:17 <leio> I thought it was just M2 Ultra where it's that bad

20:19 <martin2020> hmm yes, rebooting is the only fix I've seen work

20:20 <martin2020> I wish I knew a command that could make it try to detect the monitor again without rebooting

20:26 <leio> dmesg might be helpful to see if a case is happening that just can't recover with a replug

20:26 <leio> well, replug does that in practice

21:10 <martin2020> I guess whatever happens when it boots works to detect hdmi, so I guess in theory I should be able to re-do that?

21:14 <PaulFertser> Rebooting also resets the states of all the firmwares running on the numerous additional CPUs.