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
matteo has joined #asahi-alt
cow123 has quit [Remote host closed the connection]
cow123 has joined #asahi-alt
KxCORP5 has quit [Quit: Bye!]
KxCORP5 has joined #asahi-alt
matteo has quit [Remote host closed the connection]
matteo has joined #asahi-alt
matteo has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-alt
possiblemeatball has quit [Quit: Quit]
possiblemeatball has joined #asahi-alt
possiblemeatball has quit [Quit: Quit]
matteo has joined #asahi-alt
matteo has quit [Ping timeout: 480 seconds]
matteo has joined #asahi-alt
jeisom has quit [Ping timeout: 480 seconds]
matteo has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Remote host closed the connection]
JayBeeFOSS has joined #asahi-alt
SalimTer- has joined #asahi-alt
SalimTerryLi has quit [Ping timeout: 480 seconds]
matteo has joined #asahi-alt
matteo has quit [Ping timeout: 480 seconds]
<chadmed_>
mps: hopefully will get it merged for 0.5.3
<chadmed_>
working on the final piece of the puzzle today
<mps>
chadmed_: thanks for info
<mps>
and no hurries, at least for me
mokou has quit [Remote host closed the connection]
checkfoc_us has quit []
mokou has joined #asahi-alt
checkfoc_us has joined #asahi-alt
<chadmed>
yeah im pretty sure the API change means that no one is planning to ship wp 0.5 for some time yet
<chadmed>
well except fedora which is shipping it by default for F40 next week :p
<chadmed>
hence my rush to get this done
<mps>
alpine already shipped 0.5.1
<mps>
and because freeze time for next stable is near I have fear that next stable will have it
<sam_>
chadmed: wait f40 includes 0.5?
<chadmed>
sam_: it will yeah, hence why i have been tearing out tufts of hair over this -.-
<chadmed>
at least thats what neal said
matteo has joined #asahi-alt
<chadmed>
icymi the changes to asahi-audio to accommodate wont affect us or any other distro sticking with 0.4.x for the time being as i have split development into two branches and will tag out 1.x releases of asahi-audio that will remain compatible with that api
matteo has quit [Ping timeout: 480 seconds]
matteo has joined #asahi-alt
matteo has quit [Ping timeout: 480 seconds]
sefidel has quit [Remote host closed the connection]
sefidel has joined #asahi-alt
<jannau>
chadmed: is there anything wrong with https://github.com/chadmed/asahi-overlay/pull/78 ? we can't skip kernel-install_pkg_preinst() since it fixes symlinks in the modules dir for merged-usr
<chadmed>
i only dont get why we're symlinking the DTBs installed to /boot into the source tree
<chadmed>
shouldnt we be setting INSTALL_DTBS_PATH to the source tree instead?
<chadmed>
otherwise whichever kernel was installed last will be the One True DTBs
<chadmed>
and eselect kernel wont transparently handle the dtbs
<jannau>
I'd like to keep the DTBs installed to /boot so symlinking them was the best option
<jannau>
I don't follow how eselct kernel is related to this. the chosen DTBs are the ones from the /usr/src/linux symlink (if we revert the update-m1n1 change). that will work with my solution and asahi-sources (if the kernel is compiled after installation)
<jannau>
maybe we should write an asahi-dtbs eselect module which manages /boot/dtb as symlink
<chadmed>
my original idea was that if we install the dtbs into the source tree, we can revert update-m1n1 so that it looks at /usr/src/linux for the DTBs again
<chadmed>
doing this would mean that running eselect kernel <number> && update-m1n1 will _always_ give you the "correct DTBs since eselect kernel changes the symlink at /usr/src/linux to the selected kernel
<leio>
I still don't follow this kernel stuff, so this might be completely stupid note, but reading this I need to ask - could update-m1n1 somehow detect that there's a version mismatch between the kernel it picks and the dtbs it picks? Perhaps from the path component of where it takes them from?
<leio>
(and issue a warning at least, if so)
<chadmed>
update-m1n1 doesnt pick a kernel
<jannau>
that will work with my changes. /usr/src/linux-6.6.0_p16-asahi-dist/arch/arm64/boot/dts/apple has symlinks to the installed ones in /boot/dtbs/6.6.0-p16-asahi-dist/apple/
<chadmed>
all it does is concatenate the DTBs and u-boot on to the end of m1n1
<chadmed>
ohhh duh sorry i completely brainfarted that the dtbs in /boot are also versioned
<jannau>
don't merge yet
<chadmed>
too late...
<chadmed>
what needs fixing
<chadmed>
ill just fix it
<jannau>
not sure if anything needs fixing but my test machine "'*.dtb' -> '/boot/dtbs/6.6.0-p16-asahi-dist/apple/*.dtb'". I thought I fixed this
<jannau>
not sure if I bothered to merge after the fix or if it is still broken
<chadmed>
for dtb in /boot/dtbs/${module_ver}/apple/*.dtb; do ??
<chadmed>
looks fine to me
<leio>
right, I'm just confusing with my own update script that cats kernel, kernel cmdline and dtbs together
<chadmed>
i need to check if 6.8 builds with rust without patches now
<jannau>
6.8 builds with rust 1.76 and 1.77
<jannau>
there is however no 6.8 asahi tag yet
<chadmed>
yeah figured, i was just going to clone the wip branch and try build
<chadmed>
we also need to talk to mpagano to figure out how to get genpatches to play nice with rust
<chadmed>
i asked a couple of times in #gentoo-kernel but got no response
<jannau>
can we store the kernel sources under the proper name? on the next tag bump? I'm a little annoyed by having identical asahi-sources and asahi-kernel tars
<jannau>
chadmed: reinstalled and the symlinks are correct so I did fix it
<chadmed>
excellent :)
<chadmed>
jannau: wdym by "proper" name?
<chadmed>
have it so that portage only downloads the one tarball for both kernels?
<jannau>
yes, use the same name as the github url so both ebuilds use the same tarball
<chadmed>
yeah next time we need to do a revbump or when 6.8 (or maybe even 6.9 at this rate) gets tagged ill fix that up
<leio>
if it's just asahi-<version>.tar.gz then I'd feel a bit worried that something unrelated might use the same naming and would move both to asahi-source-${PV}.tar.gz or some such instead
<jannau>
yes, it's just the tag name, I guess we could prepend "linux-"
<leio>
and same named things in multiple packages is only OK when the checksums match between them, that's a given and already considered here
<chadmed>
if we make sure that ${PV} is the same across both packages i think thats the best solution as it means our automatic tarball/version handling doesnt have to change
<chadmed>
and we can still just mv old.ebuild new.ebuild to bump versions
matteo has joined #asahi-alt
<leio>
you generally want something like ebump and handling keywording (keeping latest stable, making the new version testing first, etc)
<leio>
you get some early testing while making use of stable keywords for those that prefer it; doesn't mean you have to keep them in testing for 30 days like main tree guideline (not a rule)
<jannau>
who made trhe color scheme / syntax highlighting for less? dark blue on back background is unreadable
<chadmed>
leio: TIL about ebump :p
<jannau>
I don't see why we would need use ${PV}, as long as we download the same file there's no need to do anything. I'd prefer linux-${MY_P}.tar.gz as name
<jannau>
does firefox-124.0.2 build for anyone?
matteo has quit [Ping timeout: 480 seconds]
matteo has joined #asahi-alt
matteo has quit [Remote host closed the connection]
<leio>
I still just use a script that just runs cp and ekeyword + more stuff to set me up for tarball comparisons
<leio>
(ekeyword ~all <ebuild>)
<leio>
PV was just an example, whatever correctly points to the upstream tarball version component really, not PV
<leio>
trying firefox now, gimme 28 minutes, I've enabled pgo so it takes a bit :)
<chadmed>
28 mins for a pgo build is still pretty good
<chadmed>
my lto builds with no pgo take about 10 mins on the studio
<leio>
I had 7 or so, then I started with building full debug
<jannau>
fails with "use of undeclared identifier '__NR_epoll_wait'" in security/sandbox/linux/Unified_cpp_sandbox_linux2.cpp