02:15 <lactose> I want to try to craft a Slackware rootfs image to use with the official installer, but I'm confused as to how to do that.

02:17 <lactose> I'm looking at the Debian repo and I'm not sure how m1n1 and u-boot fit into the picture, also the official installer has no documentation that I could find

07:42 <cy8aer> m1n1 and u-boot together with the dps from the kernel create a file /boot/efi/m1n1/boot.bin which is the second stage of m1n1. In the @Glanzmann-Repo m1n1 has not only the m1n1 binary but also the combined boot.bin which is copied to /boot/efi/m1n1 at install time (together with creating a backup). So there is a dependency of m1n1 with the kernel because different kernels have different dps

07:43 <cy8aer> see https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/blob_plain/HEAD:/m1n1_uboot_kernel.sh what is happening there.

07:45 <cy8aer> The main problem is that it is difficult to find the dps at install time from the kernel packages so it is precompiled at packaging time. Other dists do it at install time. As long as the kernel dpc is not stable this must be done.

07:48 <cy8aer> And the pre compilation of boot.bin is only possible because the kernel source is lying around in the build dir at the same time with the m1n1_uboot_kernel.sh script

08:12 <cy8aer> has not -> there is

08:29 <cy8aer> dp -> dtb (sorry)

08:31 <cy8aer> aka device tree binary

10:35 <chadmed_> hm cargo-ebuild doesnt seem to tolerate workspaces properlyt

10:39 <leio> chadmed_: pycargoebuild is the current thing that's mostly used, not cargo-ebuild.

10:40 <chadmed_> leio: that doesnt either :p

10:40 <chadmed_> but at least it tells you it expects each member of the workspace to be its own package

10:52 <sam_> are you sure it doesn't handle it properly? (pycargoebuild)

10:52 <sam_> anyway file a bug if it's doing something wrong or speak to mgorny

10:54 <chadmed_> i think its expected behaviour because if you run it in a workspace it explicitly says to only do it at the path of an actual binary package

10:54 <chadmed_> so not necessarily a bug

11:01 <sam_> right

11:01 <sam_> i'm not really sure what else you want it to do

11:02 <chadmed_> a couple of things ive tried to package up in the last week or so have depended on cargo's workspace feature, where multiple interdependent modules get developed, built and installed from a single root

11:02 <chadmed_> libkrun is egregious because it makes use of this _and_ vendors multiple other crates that it really really shouldnt

11:03 <chadmed_> and because cargo-ebuild and pycargoebuild cant tolerate workspaces, i had to do some weird stuff to get cargo.eclass to behave nicely with those vendored crates and the different components that the actual package expects to build

11:04 <chadmed_> whereas cargo proper, you just run cargo build/install from the root and it iterates over the workspace members and it resolves all the dependencies and interdependencies, builds them in the correct order, then installs them

11:06 <sam_> but isn't it quite unusual for multiple binaries to be needed?

11:06 <sam_> this doesn't sound related to that part

11:06 <sam_> it sounds more related to stupid shenanigans like git crates

11:07 <sam_> but maybe i'm missing something, i'm no rust expert

11:07 <sam_> but you should file a bug if you think it should handle it better and it doesn't

11:07 <sam_> not clear to me what else it should do differently (every time I've hit a workspace, just picking the things I actually want worked fine for me) but if you have an idea in mind, go nuts

15:44 <lactose> I've done a little more research about m1n1 and U-Boot, so I think I understand them a bit better now. If I wanted to craft an image to be used with the installer, I need to set up stage 2 m1n1 + U-Boot and an EFI compatible bootloader (i.e. GRUB)?

15:46 <j`ey> along with the rootfs, yeah

15:53 <lactose> Well I figured that was a given haha. From what I could gather the installer handles stage 1 m1n1 so I wouldn't have to worry about that, is that right?

15:53 <j`ey> yup

15:58 <lactose> Alright cool, thanks a lot

15:59 <j`ey> https://github.com/AsahiLinux/asahi-alarm-builder/blob/main/build.sh is the ALARM build script

16:02 <lactose> Oh wow I never knew that existed, thanks

16:02 <lactose> I have plans to make a Slackware image so this will be incredibly useful

16:03 <j`ey> https://github.com/Marek-Svoboda/slackahi-support

16:03 <j`ey> I dont know where/if there are any slackbuilds

16:08 <j`ey> older repo https://github.com/mac-a-r0ni/asahi-slackware

16:14 <lactose> That first repo doesn't build an install image, it instead creates a squashfs and uses a different distro to handle the bootloader stuff

16:15 <j`ey> yup

16:16 <lactose> At least that's what I could make out of it. I don't really understand how it works. I know it's based on chadmed's asahi-gentoosupport though

16:19 <lactose> I've never worked with squashfs and I've certainly never seen one used as root

16:20 <j`ey> it's just a way of getting a live-ish environment