03:03 <lactose> Hello, I'm thinking of installing Void Linux and/or Slackware, but I don't know where to get started

03:04 <chadmed> you will notice that neither of those have maintainers

03:04 <chadmed> https://github.com/AsahiLinux/docs/wiki/SW%3AAlternative-Distros

03:06 <lactose> But could it be theoretically done?

03:06 <chadmed> yeah for sure

03:07 <lactose> Because at least for Void they offer rootfs images so maybe you could set it up to be bootable via chroot?

03:07 <chadmed> there are basically two ways you can implement support for alt distros: wire up an esp and roofs image for them into the official installer, or build uefi-bootable install media with our kernel

03:08 <chadmed> much of the actually useful functionality for this platform is not yet upstreamed, so canned arm64 images from ~all distros will not work properly

03:10 <lactose> even with an asahi distribution kernel?

03:19 <chadmed> well yeah if you add our kernel to the image

03:19 <chadmed> but that requires manual work is my point

03:19 <chadmed> https://github.com/Marek-Svoboda/slackahi-support this might be a good starting point

03:20 <chadmed> someone forked my gentoo stuff and rejigged it for slackware

03:22 <lactose> well i know it would be manual but i just want it to see it run

03:23 <lactose> anyway i will eat dinner and give that a read, thanks again

06:03 <lactose> chadmed: I took a look at asahi-gentoosupport and saw the grub entry. I've never seen the root command line parameter be anything other than a block device. How does that work?

06:06 <chadmed> lactose: it triggers a dracut module that mounts the specified squashfs image as a loopback device and pivots to it as the rootfs

07:04 <lactose> >there are basically two ways you can implement support for alt distros: wire up an esp and roofs image for them into the official installer, or build uefi-bootable install media with our kernel

07:04 <lactose> How would one go about the former? I can see that the Gentoo stuff does the latter

07:06 <lactose> Mainly looking at Debian as an example, it seems to have its own install script?

07:17 <chadmed> youd need to first basically build a fully configured rootfs in a ramdisk or similar and dump it out to an image

09:12 <leio> chadmed: the libkrun[-gpu] failure is from it still looking for virglrenderer.pc with it, and in that case it's not pulled in

09:12 <leio> oh, it's not pulled in with USE=gpu either

09:14 <chadmed> it happens from a clean build too so i think we just make gpu unconditional

09:14 <leio> doesn't matter, you don't have the dep even with USE=gpu

09:15 <chadmed> yeah i didnt get around to it

09:15 <chadmed> let me ssh into my studio to see if i started

09:15 <chadmed> (im kinda bedridden rn :p)

09:15 <leio> how do you have these things compile with clang as system compiler? All cbindgen stuff fails on cc calls for me

09:16 <leio> both gpu and -gpu fail for me in rust stuff, https://dpaste.com/45M56M7B3

09:16 <leio> (unrelated to the clang question, I'm forcing gcc now)

09:17 <chadmed> was cbindgen built with gcc?

09:17 <chadmed> i think its a perl/ruby situation there where the compile time settings are baked into it

09:17 <leio> that needs fixing at some point then, but that's a gentoo topic

09:18 <leio> and yes, it was built with gcc, because its own build calls cc and fails

09:18 <chadmed> yeah

09:18 <leio> when trying to build with clang

09:19 <chadmed> it builds fine for me even with my spicy *FLAGS

09:19 <chadmed> i only have a handful of packages set for gcc override

09:19 <leio> it doesn't honor linker choice there

09:19 <leio> so ld failure from calling it with cc

09:27 <j`ey> lactose: for void there's some stuff here https://github.com/void-linux/void-packages/pull/36390

09:33 <sam_> my feeling is there's something more to the cbindgen situation

09:33 <sam_> feel like this would've come up before

09:33 <sam_> then again, there is one element I never fully understood which gyakovlev mentioned every so often

09:33 <sam_> something like rust-bin having different behaviour to ruxt

09:33 <sam_> rust

09:34 <leio> I am on rust-bin

09:34 <leio> not quite sure why :D

09:35 <sam_> we can ask ionen about whatever the -bin thing is

09:35 <sam_> he may have more of a hint

09:41 <chadmed> leio: we also need to do the checks for kernel config options for virtio-net support in libkrun

09:41 <chadmed> im about to push the virglrenderer dep fix

09:41 <chadmed> but i am in no fit state to do the kernel config checks

09:41 <chadmed> PRs welcome

09:41 <chadmed> there is also interactions with the kernel config used to build libkrunfw so that will need some work too

09:41 <leio> no idea what options it needs, and can't compile the crates anyhow

09:42 <leio> (unrelated to cbindgen)

09:42 <chadmed> what error is it giving

09:43 <chadmed> i build this time and time again from the ebuild before pushing, on multiple systems

09:43 <leio> pastebin from above: https://dpaste.com/45M56M7B3

09:43 <sam_> can i teach you ansifilter leio

09:43 <sam_> please

09:43 <chadmed> oh you mean just with -gpu

09:43 <leio> use of undeclared crate or module `thiserror` and so forth

09:43 <sam_> install ansifilter, then PORTAGE_LOG_FILTER_FILE_CMD="bash -c \"ansifilter -c; exec cat\"" in make.conf

09:44 <sam_> console logs have colour, on disk has filtered

09:44 <leio> but how do I get the colors then after pastebin download for easier red spotting? :P

09:44 <sam_> oh u

09:44 <leio> chadmed: this kind of error is with both -gpu and gpu

09:44 <chadmed> oh thats new then

09:47 <chadmed> worked fine here

09:47 <chadmed> with USE="gpu"

09:48 <leio> sam_: also, if ansifilter is desired, it should work out of the box, but really we should default wgetpaste to a pastebin that understands ANSI colors itself; the current default of bpa.st is also uselessly strict on size so I need to force dpaste often

09:48 <leio> oh me :D

09:48 <chadmed> only breaks with USE="-gpu"

09:48 <sam_> I suspect people would moan if added ansifilter as a dep of portage or something so would need to have some pure python thing instead

09:48 <sam_> but yeah, there's some magic which uh.. xfce-terminal? does

09:48 <sam_> it has some pastebin integration where it dumps as html

09:49 <leio> I wrote ANSI understanding HTML generation back in 2004, it's not rocket science for a pastebin to do :)

09:52 <chadmed> i think the only fix for this right now given the vendored pipewire crate spaghetti is to make --features gpu unconditional so that it builds

09:52 <chadmed> doesnt really bother me that much since thats what youre clearly here for if youre installing this downstream fork of libkrun

09:54 <leio> chadmed: I think I figured out the difference - you don't seem to use FEATURES=test for the stuff you maintain?

09:55 <leio> it also reports this from iwdevtools:

09:55 <leio> * VDB: detected possibly incorrect RDEPEND (dev-libs/libkrun-1.6.0)

09:55 <leio> * > media-libs/virglrenderer

09:55 <leio> * > media-video/pipewire:=

09:55 <leio> so virglrenderer we figured out before, but pipewire looks kind of obvious need then too :)

09:58 <chadmed> oh duh yeah...

09:58 <chadmed> *sigh* -r2 coming in

09:58 <leio> but yeah, it passes if I don't run tests

09:59 <leio> so that'll be a problem for main tree later

09:59 <chadmed> yeah this will definitely need cleaning up

09:59 <chadmed> i think these ones are special cases since theyre a bit janky

10:00 <chadmed> once all this stuff is merged properly it shouldnt need such delicate handling

10:00 <leio> it's possible to just force disable tests if it is too hard to fix

10:00 <leio> but might be just an outdated crate or smth too

10:01 <leio> now what can I do with these libkrun libraries further? :)

10:01 <chadmed> i believe the primary use case is isolating any OCI image into a VM

10:02 <leio> think it might be worth IUSE default enabling native-context on overlays virglrenderer as the main use case for it in overlay?

10:02 <chadmed> and yes i suspect some of the deps for slp's forks are broken just by being out of date since its now a 3 month old fork with no updates

10:02 <leio> and same for gpu on libkrun

10:03 <leio> (IUSE default like IUSE="static-libs +native-context")

10:03 <chadmed> yeah

10:04 <leio> also virglrenderer fork has same tarball name which clashes with checksum of main tree one; should save it under a different name on the "->" redirect in SRC_URI

10:10 <veritas> Hi all. I am having some issues with Hyprland running on M1 Pro after the 6.6 kernel update. It crashes for me at startup. I am using NixOS with the nixos-apple-silicon module, mesa driver using overlay mode, pinned all nixpkgs to the nixos-apple-silicon nixpkgs latest version. Now Hyprland fails with eglQueryDeviceStringEXT, error: EGL_BAD_PARAMETER (0x300c). Anyone has any experience with a similar setup ?

10:54 <mps> anyone have working hyprland config for macbook

12:54 <leio> and virglrenderer fails with ../virglrenderer-cacafff69205a62758a22ef73c1334057f72e5d6/vtest/vtest_server.c:244:2: error: embedding a directive within macro arguments has undefined behavior [-Werror,-Wembedded-directive]

12:55 <leio> i guess it figured to -Werror

12:55 <chadmed> yeah i set a gcc override for that guy

15:04 <mps> question for alt-distro maintainers, are you enabled speakers for distros?

15:06 <mps> I mean, kernel patched with patches from https://github.com/AsahiLinux/linux/tree/speakers/enablement-READ-COMMIT-MESSAGE

15:09 <zzywysm_> NixOS for Apple Silicon has those patches

16:02 <tobhe> mps: currently only in testing for ubuntu, but everything looks good so I might publish them to the regular channel soon

16:05 <mps> tobhe: thanks for info

20:14 <mps> interesting, speakers block video playing from mpv and firefox while sounds work and on headphone everything is ok.

20:14 <mps> ffplay and telegram-desktop works fine on both, speakers and mpv

20:15 <mps> tried with X, sway and hyprland