ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
glem8100548 has joined #asahi-alt
glem810054 has quit [Ping timeout: 480 seconds]
glem8100548 is now known as glem810054
glem810054 has quit [Read error: Connection reset by peer]
<chadmed>
no one was hurt but about 3000 homes had no power for most of yesterday
<chadmed>
in case you hadnt checked again, server's been back up for a while now
zerdox has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
n3ph has joined #asahi-alt
n3ph has quit [Read error: No route to host]
balrog has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
dcavalca8569 has quit []
dcavalca8569 has joined #asahi-alt
n3ph has quit [Remote host closed the connection]
zerdox has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
Retr0id has quit [Quit: Ping timeout (120 seconds)]
Retr0id has joined #asahi-alt
<spuos>
chadmed: glad nobody was hurt
zumi has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
john-cabaj has joined #asahi-alt
qyliss has quit [Quit: bye]
zerdox has joined #asahi-alt
qyliss has joined #asahi-alt
cyrinux has quit []
cyrinux has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
flokli has quit [Ping timeout: 480 seconds]
flokli has joined #asahi-alt
spuosthelivemedia has joined #asahi-alt
<spuosthelivemedia>
coming to you live from the gentoo install media after figuring the actual way to get the uboot to work, it's spuos!
zerdox has quit [Ping timeout: 480 seconds]
<spuosthelivemedia>
chadmed: it's me spuos, I'm on the live media :D
<noisycoil[m]1>
spuostheterrible: which u-boot are you using on Debian?
<spuosthelivemedia>
noisycoil[m]1: latest m1n1 from the installer
<noisycoil[m]1>
Which installer
<spuosthelivemedia>
oh whoops
<noisycoil[m]1>
There is no official Debian asahi installer
<spuosthelivemedia>
the asahi.sh scriopt
<noisycoil[m]1>
From where?
<spuosthelivemedia>
like most alts you're supposed to make a small efi boot env from the
<spuosthelivemedia>
oh I said it wrong again
<spuosthelivemedia>
the alx.sh installer you use for fedora
<spuosthelivemedia>
s/asahi/alx
<noisycoil[m]1>
Ah, so you're building it yourself?
<spuosthelivemedia>
that was back in late 2023, I double checked, so it looks like I followed instructions from tg.st and curled tg.st/d
<spuosthelivemedia>
right now I'm installing gentoo in some free space
<noisycoil[m]1>
Ok! Asking just to inform you that our u-boot-asahi in Debian is not up-to-date
<noisycoil[m]1>
And that may cause issues with multiboot
<spuosthelivemedia>
I see. fun fact: I ran the update script from alx.sh when I prepped to install gentoo and it luckily worked without breaking debian
<spuosthelivemedia>
as always I suck at asking and answering questions on irc'
<noisycoil[m]1>
If it worked it worked :-)
<spuosthelivemedia>
lol
<spuosthelivemedia>
do I need a efi partition when I'm partitioning gentoo?
<spuosthelivemedia>
or does it go on the same one as the gentoo stub
<spuosthelivemedia>
by that I mean the uboot and m1n1
<opticron>
I thought you needed an EFI stub for each install because the stub only contains m1n1 stage 1 and m1n1 stage 2+u-boot is contained in the actual OS partition?
<opticron>
(I could be wrong)
<opticron>
and that the stage 1 m1n1 was explicitly pointed at a single partition guid
<spuosthelivemedia>
ok I don't know what that means
<spuosthelivemedia>
I have a new m1n1/uboot made for gentoo though
<spuosthelivemedia>
opticron: I'm not sharing it, I made an additional one for gentoo
<spuosthelivemedia>
but do I put the stuff in it?
<spuosthelivemedia>
I can't read that link I'm in a tty
chadmed has joined #asahi-alt
chadmed has quit []
chadmed has joined #asahi-alt
<opticron>
ah, once the ESP is created you shouldn't have to modify it unless you need to change the partition it points to (or theoretically change the OS-specific firmware)
<spuosthelivemedia>
so I make a new area for the gentoo boot?
<opticron>
The OS will want to mount it to pull that firmware on boot
<opticron>
Yes, you need the ESP and the OS partition
JayBeeFOSS has quit [Remote host closed the connection]
JayBeeFOSS has joined #asahi-alt
JayBeeFOSS has quit [Remote host closed the connection]
nela has quit [Quit: bye!]
nela has joined #asahi-alt
JayBeeFOSS has joined #asahi-alt
zerdox has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
spuosthelivemedia has quit [Ping timeout: 480 seconds]
aleph has joined #asahi-alt
aleph is now known as Guest6213
Guest6213 is now known as aleph-complex
ciara has quit [Remote host closed the connection]
ciara has joined #asahi-alt
n3ph has joined #asahi-alt
spuosthelivemedia has joined #asahi-alt
<spuosthelivemedia>
alright I'm back from a long day of work and can finally get back to what's important:gentoo!
<spuosthelivemedia>
chadmed: quick question, earlier you said something about using the llvm toolchain, should I try making a llvm desktop profile?
<n3ph>
spuosthelivemedia: you can certainly try
<spuosthelivemedia>
I've never dealt with irregular profiles so I don't really know if that's going to end in pain
<chadmed>
spuosthelivemedia: no need for a specific profile, all the required changes can be made in /etc/portage/make.conf, /etc/portage/env/ and /etc/portage/package.env
<chadmed>
and the server is alive and kicking on both ipv4 and ipv6
<chadmed>
oh you mean bc i keep disconnecting. no thats just because broadcom wifi is abysmal dogshit :p
<chaos_princess>
i had previously ran a llvm toolchain but switched back to gcc. It mostly work, but there are certain packages (i.e. telegram-desktop) that do not care about being buildable with llvm
<chadmed>
you can just set a package.env entry for those
<chadmed>
it used to be waaaay worse but now theres only a handful of packages that dont build
<spuosthelivemedia>
lol, rest in 802.11
<chaos_princess>
oh, i know i can, it was more me trying to test a theory that i can set llvm systemwide and not care
<spuosthelivemedia>
sweet, is there a guide for the changes I'd need?
<chaos_princess>
also, llvm has an amazing footgun in that you must not ever remove entries from LLVM_TARGETS if it is the system toolchain
<chadmed>
you can recover from doing that but its very very very annoying
<chadmed>
ask me how i know :)
<chadmed>
you also cant ever remove BPF as a target as of (i think) llvm 17
<chaos_princess>
i have recovered, and yes, it was very annoying :P
<chadmed>
probably just like get your system bootable from / first though
<spuosthelivemedia>
I can't imagine why eBPF would cause dep issues, odd.
<spuosthelivemedia>
yeah in that case It sounds like a good idea to get bootable first
<leio>
for gcc, until gcc-15 don't use -march=native or -mcpu=native, it won't do what you want; use both at once or write it out
<leio>
(will remain relevant for your gcc overrides for the few packages)
<chaos_princess>
are they fixing m-series cpu detection in gcc 15?
<leio>
they are fixing it generally being broken with unknown CPUs
<leio>
there is a patch for adding some basic knowledge of apple-m{1,2,3}, but I don't know if it'll go in at its current state, nothing of real interest in that yet.
<leio>
sam_ says the unknown CPU fix is in main slated for 15 (?)
<leio>
(I tested that they work, though meanwhile just got to know to pass both if you use native)
<leio>
(except ffmpeg configure was broken or something)
<chaos_princess>
speaking about cpu detection, someone (who might end up being me) should maybe look at the chromium stuff where it generates sve instructions on unsupported platforms