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
<chadmed>
6.6_p16-r1
<derek_>
chadmed mine is 6.3.0
<chadmed>
you should probably add ACCEPT_KEYWORDS="~arm64" to your make.conf
<chadmed>
or at least for the asahi packages
<chadmed>
i need to do some housekeeping on the overlay and also bump asahi-sources in ::gentoo
<derek_>
thanks chadmed
<derek_>
how does that make it work though, im new to gentoo
<chadmed>
packages are split into "stable" and "unstable" groups based on keywords
<chadmed>
arm64 is the "stable" keyword and ~arm64 is for unstable
<chadmed>
as gentoo is a rolling release, bleeding-edge versions are introduced in the "unstable" group until theyre tried and tested, and only promoted to stable once they are confirmed to be... well, stable
<derek_>
ok
ellyq has joined #asahi-alt
derek_ has quit [Remote host closed the connection]
lockbox has joined #asahi-alt
KxCORP5 has quit [Quit: Bye!]
KxCORP5 has joined #asahi-alt
kujeger- has joined #asahi-alt
kujeger has quit [Ping timeout: 480 seconds]
derek_ has joined #asahi-alt
<derek_>
chadmed sorry to disturb you but i couldn't get graphics to work and im probably being dumb
<derek_>
i tried installing mesa but glxinfo is still showing llvmpipe
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
<chadmed>
you need to mask the mesa in ::gentoo since our version is "behind" it
<chadmed>
make a folder in /etc/portage/ called package.mask
<chadmed>
then in a file put "media-libs/mesa::gentoo"
possiblemeatball has quit [Quit: Quit]
derek_ has quit [Ping timeout: 480 seconds]
derek_ has joined #asahi-alt
<derek_>
so we mask it because otherwise it will install the official version?
<chadmed>
yeah
<chadmed>
portage will always look for the latest valid version, so every time upstream leapfrogs us it will try to pull it in
<chadmed>
we need to mask upstream so that doesnt happen
<chadmed>
just installed p_16-dist on my studio and couldnt repro at all with a completely standard machine so idk
<chadmed>
was debugging with liv last night and found that manually creating /lib/firmware/vendor sorted it
<janneg>
another issue is that "/lib/modules/$(uname -r)/vmlinuz" is a relative link (created for "/usr/lib/modules/$(uname -r)/vmlinuz") breaking depmod
<sam_>
fwiw I have absolutely no guess on that
<sam_>
first i've heard of it
<sam_>
ah, I guess that fix is plausible
<sam_>
i'd forgot you did a custom dracut module
<janneg>
by manually creating /lib/firmware/vendor you mean just a mkdir?
<chadmed>
yup
<janneg>
so this is then the proper fix. The initramfs misses mkdir and the PR will fix it
<chadmed>
beautiful
<chadmed>
who has merge rights on asahi-scripts :p
<chadmed>
also sam_/leio if you can take a look at MR 36030 on ::gentoo, and 657 on api.g.o
<sam_>
how much do you need it done
<chadmed>
neither are urgent
<sam_>
if it's some random thing i'd prefer to wait but if it would help you a lot to get it in i can do it now
<sam_>
just been swamped with xz
<chadmed>
yeah totally understandable, theres no rush its just a version bump for asahi-sources and stabilising bindgen so we can stabilise our kernels
<sam_>
lemme check it out
<chadmed>
and adding the overlay to api.g.o but theres no rush on that at all
<sam_>
for api.g.o, does pkgcheck scan pass now? you can customise the checks in metadata/ if you must for now
<sam_>
(to disable known-failing stuff)
<chadmed>
i can re-keyword some stuff to ~arm64 to fix some of the unresolvable deps issues
<chadmed>
but two are irreconcilable and will need to be disabled (we inherit one from mesa::gentoo, and one is related to glibc not being found in musl profiles)
<chadmed>
there are no other fails though, spent all day cleaning up the other stuff
<chadmed>
eyyy stabilising bindgen fixed the pkgcheck flow
tobhe has joined #asahi-alt
hightower2 has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
dylanchapell has quit [Remote host closed the connection]
<janneg>
chadmed: I was planing to solve the dtb issue for asahi-kernel by installing the dtbs or symlinks into the kernel src dir
<chadmed>
the dist-kernel doesnt persist the sources though right
<chadmed>
oh it does
<chadmed>
not a fan of the edge case where someone might have multiple kernels installed and have the wrong thing symlinked to /usr/src/linux
<chadmed>
i guess though that it gives us more flexibility in that you _can_ have multiple DT-incompatible kernels installed as long as you remember to eselect kernel set && update-m1n1 between reboots
<leio>
USE=symlink is optional
opticron has quit [Read error: Connection reset by peer]
<leio>
oh, eselect kernel manages that symlink these days? :P
opticron has joined #asahi-alt
dylanchapell has joined #asahi-alt
<janneg>
it deletes most of the src in install (it retains Makefiles and a few select files)
<janneg>
USE=symlink is a kernel-2 eclass thing so the dist kernel will not update the symlink
<janneg>
so this is not feasible
<janneg>
maybe we should create a symlink as well
<chadmed>
the eclass just does ln -snf directly on ${EROOT}/usr/src/linux so maybe we can just do that too
<chadmed>
eselect kernel seems to be able to pick it up fine
<janneg>
symlink handling is in kernel-install.eclass but without use flag so that should be safe
pjakobsson has quit [Remote host closed the connection]
hightower2 has quit []
<leio>
maybe #gentoo-arm would have experience dealing with dtbs of other platforms
<leio>
haven't been able to follow the topic, but feels like a similar step than modules_install to put them somewhere version-specific for use
<janneg>
our use of dtbs differs from other platforms. there is already `make dtbs_install` and the kernel-build eclass uses that which results installing the dtbs in /boot/dtbs/6.6.0-asahi-16-dist/
<janneg>
our problem is that we need to inject the dtbs of the kernel which boots next into ${ESP}/m1n1/boot.bin
<janneg>
so the problem is finding the version of the next kernel
<leio>
how's that different from finding the version of the kernel you are putting into grub conf?
<leio>
but to be able to participate in this discussion, I better first actually convert over to a packaged kernel
<janneg>
maybe the dist kernel should simply run update-m1n1 with its dtbs
<leio>
chadmed: you could have slotmoved asahi-audio:0 to asahi-audio:1.0
jacksonchen666 has quit [Ping timeout: 480 seconds]
<leio>
e.g. slotmove entries in profiles/updates/* in ::gentoo (and the commits that added them modifying ebuild SLOT in the same commit)
<leio>
also unsure about global ~arm64 promoted so hard; I'd rather have them per-package accepted while necessary things are stabilized
<chadmed>
leio: if youre volunteering to deal with all the upstream stabilisations required to silence pkgcheck due to unresolvable deps then sure ;)
<chadmed>
the only thing we can have stable right now is the kernel and thats only because i specifically pinged sam about bindgen earlier today
<chadmed>
i guess the alternative is another file in asahi-gentoosupport that gets dumped into package.accept_keywords at install time
<chadmed>
but then that has to be maintained every time the dependency graph changes slightly
<chadmed>
its getting late and i have work tomorrow. let me play tomorrow night maybe with stabilising _everything_ locally then see which packages in ::gentoo need to be stabilised to enable that
jeisom has joined #asahi-alt
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-alt
stintel has quit [Quit: reboot - resizing VM disk]
stintel has joined #asahi-alt
<leio>
chadmed: if everything were in ::gentoo, we could just file a stabilization bug and have a bot tell us :)
<chadmed>
i think yesterday proves why we're not ready for that yet tbh
<chadmed>
im not thrilled about the prospect of waiting some arbitrary amount of time for someone to maybe get around to merging updates when we might tag out three or four kernel versions in a week with important fixes etc, and it is totally unfair on yourself and sam to have to deal with me bugging you to do it
<chadmed>
also mesa just cannot be upstreamed anyway
<leio>
chadmed: but someone was around within 4 hours?
<leio>
as for the stabilization stuff, having these fail pkgcheck with them having been stable is a real problem for pure overlay users as well, just maybe not with common USE flag combinations
<leio>
regarding ::gentoo vs overlay, nothing stops adding revbumps and changes to overlay until waiting them to get to main tree
<leio>
with asahi-specific packages we can order the revision numbers accordingly too (skip some in main tree to accommodate things with overlay)
<janneg>
there are not that many unstable dependencies. I only see dev-util/spirv-llvm-translator-17 and dev-libs/libclc-17 (for mesa, stable on amd64) and media-libs/lsp-plugins-1.2.14 (for asahi-audio, not stable on amd64)
cow123 has quit [Remote host closed the connection]
cow123 has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
klausvalka has joined #asahi-alt
klausvalka has quit [Remote host closed the connection]
klausvalka has joined #asahi-alt
klausvalka has quit [Remote host closed the connection]
klausvalka has joined #asahi-alt
klausvalka has quit [Remote host closed the connection]
klausvalka has joined #asahi-alt
klausvalka has quit [Remote host closed the connection]
klausvalka has joined #asahi-alt
chadmed_ has joined #asahi-alt
klausvalka has quit [Remote host closed the connection]
<chadmed_>
leio: fair point actually. i think the next targets for ::gentoo at least should be scripts and configs since once those are in then we can create fully ::gentoo bootable media and install images that dont need the overlay enabled
<chadmed_>
oh, and asahi-kernel now that it works :p