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
zerdox has quit [Ping timeout: 480 seconds]
<chadmed>
jannau: merged your PR but portage does not respect profiles/package.use. might write a news item telling people to >> it into their own package.use
HitokiriKincho has quit [Remote host closed the connection]
HitokiriKincho has joined #asahi-alt
KxCORP589 has quit [Quit: Bye!]
KxCORP589 has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
jeisom has quit [Ping timeout: 480 seconds]
HitokiriKincho has quit [Remote host closed the connection]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Remote host closed the connection]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Remote host closed the connection]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
axt has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
<jannau>
chadmed: my bad, I did not test. after package.unmask for mesa I just assumed it would work
<chadmed>
thats okay im working on syncing the ebuilds now anyway
<jannau>
the most pratical way to do this would add a kde/plasma use flag for the meta package which then depends on kwin[+caps]
<chadmed>
seems like meson no longer treats "enabled" as truthy so i have some editing to do
<jannau>
afaik that only depends on whether the meson option is a feature / or boolean
<jannau>
enabled/disabled/auto is for feature, true/false for booleans
<jannau>
i.e. it's project changes and not meson changes
<chadmed>
it cant be though since the tarball is exactly the same
<jannau>
this is for mesa? maybe it was always wrong and it got silently ignored
HitokiriKincho has joined #asahi-alt
<jannau>
that still configures with my use flags
<chadmed>
the new ebuild has $(meson_feature opengl glvnd) which sets -Dglvnd=enabled but -Dglvnd is a bool
<chadmed>
so that's either broken in ::gentoo or upstream changed glvnd to a feature after we tagged out our latest mesa
<leio>
chadmed: for bool there's meson_use instead of meson_feature, yes
<leio>
if I unpack mesa-24.0.6, it's a bool in meson_options.txt, but a feature in mesa-24.1.0-rc1
HitokiriKincho has quit [Ping timeout: 480 seconds]
<chadmed>
what is our mesa based on though
<chadmed>
we claim 24.1 but is it not?
<jannau>
committed on 6th of april
<jannau>
we have a mesa 24.1 dev snapshot from february
<leio>
24.1 isn't released, it must just be on top of 24.1 branch before the glvnd change
<chadmed>
ah there ya go then
<chadmed>
i just changed the ebuild anyway so thats fine
<leio>
I imagine adapting the rest of the changes and just s/meson_features/meson_use/ for glvnd should work
<jannau>
no, it's just from the main branch after the 24.0 branch point
<leio>
ok, so before 24.1 was even branched out yet?
<jannau>
the ebuild is called 24.1.0_pre... for a reason
HitokiriKincho has joined #asahi-alt
<chadmed>
leio: nah its just that one feature, everything else configures fine
<chadmed>
looks like we hard depend on LLVM_TARGETS: SPIRV now too?
<leio>
I don't have it and it built fine?
<leio>
presuming you aren't making a mesa snapshot bump beyond syncing
<leio>
or maybe it doesn't work fine? :D
<chadmed>
yeah just ebuild sync, exact same tarball
<chadmed>
but now meson cant fine llvmspirvlib
<chadmed>
s/fine/find
<chadmed>
the llvm dep handling was completely changed
<leio>
that should be from spirv-llvm-translator
<chadmed>
yeah i have :17 and :18 installed, wont find either
<chadmed>
ill figure it out
<leio>
yeah, otherwise I'd have to see the ebuild so far or the meson configure run output
<leio>
make sure you have the PKG_CONFIG_PATH="$(get_llvm_prefix)/$(get_libdir)/pkgconfig" part ran; old ebuild had a separate block `if use video_cards_asahi;` for that
<leio>
as in, the assignment needed adapting too to not refer to LLVM_MAX_SLOT
<leio>
with llvm-r1.eclass the user now picks their llvm version explicitly with LLVM_TARGETS, kind of like python stuff
<chadmed>
ahhh i see whats wrong here
<chadmed>
if use llvm && opencl
<chadmed>
looks like opencl is masked (???) so its not picking up PKG_CONFIG_PATH
<chadmed>
yeah that got it
<leio>
in the old ebuild you separately made asahi do llvm stuff too; are you moving towards controlling it via USE=llvm and making it REQUIRED_USE instead?
<leio>
I don't think our spirv-llvm-translator stuff is for opencl?
<chadmed>
well i want to make the ebuild have as few modifications from upstream as possible. now that llvm deps are handled (mostly) sanely with LLVM_SLOT etc all i have done is add video_cards_asahi ( llvm ) to REQUIRED_USE
<chadmed>
if we explicitly depend on spirv-llvm-translator outside of opencl then we should probably express that a bit nicer than just duplicating all the llvm deps
<leio>
ok, but I guess if we need spirv-llvm-translator stuff outside opencl, you'll need to repeat those and the necessary deps (presumably not all that opencl wants) and then a bunch if `if use llvm && (use opencl || use video_cards_asahi)` or something?
<chadmed>
yeah thats the plan. the only shared dep here is spirv-llvm-translator so im just going to refactor the if use llvm && use opencl bit and that fixes it
HitokiriKincho has quit [Ping timeout: 480 seconds]
<leio>
guess we don't need rust at all for mesa yet?
<leio>
otherwise there was also the dev-libs/libclc[spirv(-)] BDEPEND shared with intel, which you probably got already too
<chadmed>
yeah already got that one
* leio
doesn't like how conservative in-tree mesa is about LLVM_COMPAT
schroes has quit [Ping timeout: 480 seconds]
* leio
wants to get rid of llvm:17 :D
<chadmed>
same with ff
<chadmed>
both work totally fine with llvm:18
<chadmed>
hang on really stupid question i think ive overthought this but (use opencl || use video_cards_asahi) is still true when BOTH are true right
<chadmed>
like its not XOR in bash
<chadmed>
yeah dw dont listen to me
<chadmed>
$thing at $work is ambiguous about ||'s behaviour. sometimes its XOR and sometimes it's not and now i have gaslit myself into second guessing every || operator
schroes has joined #asahi-alt
HitokiriKincho has joined #asahi-alt
zerdox has joined #asahi-alt
<chadmed>
im adding llvm:18 to LLVM_COMPAT btw
<LarstiQ>
chadmed: oh that sounds awful || behaviour of $thing
<chadmed>
LarstiQ: *everything* about $thing is absolutely awful. im writing a blog post about just how abjectly awful it is in fact since im allowed to now
<LarstiQ>
looking forward to it :)
<leio>
it's not like I know for sure that `if use foo && (use bar || use baz)` will work in ebuild ;p
<chadmed>
yeah i tested all good :)
<sam_>
firefox requires care because of the stupid rust thing
<chadmed>
jannau: i made the asahi-meta USE flag "kde" since that gets selected by the desktop/plasma profile anyway
<chadmed>
so no user intervention should be required if they are installing plasma properly
<leio>
if asturm will make it just force enabled always, you might want to make the dep to be kwin[caps(+)] so it doesn't break when it happens (but I haven't looked what you did)
<leio>
he looks to be looking feedback from sam_ in relation to that
<chadmed>
i just did kwin[caps]. i dont think it should be unconditional, but +caps in IUSE is a good solution
<leio>
caps(+) means that it will assume caps is there when kwin loses IUSE=caps, which seems to be the current plan.
<leio>
with just kwin[caps] it'll break if that plan comes to fruition in main tree.
HitokiriKincho has quit [Ping timeout: 480 seconds]
<leio>
ah, you don't think we should go with that plan, misread part of it.
<leio>
(go with that in main tree)
<chadmed>
yeah
<chadmed>
i dont really care enough to voice dissent if thats what asturm wants to do
<leio>
how does that work there anyways vs rtkit?
<sam_>
for KDE stuff we try to be opinionated about avoiding broken cases
<chadmed>
but there will probably be some people grumbling about building with caps
<sam_>
especially whre it might lead to people rpeorting stuff upstream
<chadmed>
the rtkit involved here is the apple one, not the poettering one
<leio>
is cmake adding CAP_SYS_NICE when it opts to depend on libcaps?
<sam_>
I'll think about it here (not looked at the bug in detail yet, just saw it in inbox)
<leio>
I'm comparing with how mutter gets realtime prio
<chadmed>
janne made dcp's rtkit threads explicitly ask for high priority workqueues
<leio>
I know, I'm running it; it doesn't solve it here
<chadmed>
probably doesnt help performance that i have energy efficient workqueues on by default ;)
<leio>
makes it better though
<chadmed>
im going to reload my session a bit later to see if caps fixes what i thought was iomfb_flush issues
HitokiriKincho has joined #asahi-alt
<leio>
ah, I see; libcap dependency is build time only and kwin cmake adds CAP_SYS_NICE at install time
<leio>
via setcaps call
<chadmed>
i noticed in kwin:5 that rapidly cycling brightness would cause swaps to hang and the brightness changes to be noticeably slow. this would also occurr when changing the CTM, which is why i thought our performance woes might be in/after iomfb_flush
<leio>
you can just depclean libcap afterwards if you are so bothered, then you presumably keep depcleaning build deps.
<leio>
(cause it's always fun to reinstall rust all the time :D)
<chadmed>
ive given up i just use rust-bin on the laptops
<leio>
I still haven't moved away from rust-bin, and still need to do it to test if it "fixes" all cbindgen using packages being broken with clang here
<leio>
(can't we get firefox to work with llvm:18 now with some LLVM_TARGETS locking to rust and rust-bin too?)
<leio>
(err, LLVM_SLOT locking)
chadmed has quit [Quit: Konversation terminated!]
<leio>
also, rust-bin-1.78 is llvm:18
<jannau>
I think we need move the rust-src use flag to virtual/rust. or rust depedencies are not nice. I somehow ended up with dev-lang/rust-bin-1.77 and dev-lang/rust-1.75
chadmed has joined #asahi-alt
<chadmed>
hmm the sw cursor probably isnt helping either
<chadmed>
(re kwin frame pacing obviously, not the rust use flags :p)
<chadmed>
i wonder if macos also uses a sw cursor for that funky little wiggle-the-cursor-to-make-it-big a11y thing
<chadmed>
or if that's just dcp scaling a giant cursor texture down for "normal" use
<sam_>
yes, I think we're better off now that we have llvm-r1
<sam_>
jannau: ah, yeah
<sam_>
also really need to slot rust properly still
<sam_>
it should be easy
<sam_>
it just needs eclass machinery to allow choosing which rust you use
jeisom has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
zerdox has quit [Ping timeout: 480 seconds]
axt has left #asahi-alt [#asahi-alt]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
KxCORP5894 has joined #asahi-alt
steffen[m]_ has joined #asahi-alt
imobilis_ has joined #asahi-alt
KxCORP589 has quit [reticulum.oftc.net helix.oftc.net]
Lew-J has quit [reticulum.oftc.net helix.oftc.net]
imobilis has quit [reticulum.oftc.net helix.oftc.net]
steffen[m] has quit [reticulum.oftc.net helix.oftc.net]
flokli has quit [reticulum.oftc.net helix.oftc.net]
KxCORP5894 is now known as KxCORP589
steffen[m]_ is now known as steffen[m]
imobilis_ is now known as imobilis
flokli has joined #asahi-alt
Lew-J has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
zerdox has joined #asahi-alt
zerdox_ has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
zerdox_ is now known as zerdox
tobhe_ has joined #asahi-alt
tobhe has quit [Ping timeout: 480 seconds]
cyrinux3 has quit []
cyrinux3 has joined #asahi-alt
zerdox_ has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
zerdox_ is now known as zerdox
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Ping timeout: 480 seconds]
cy8aer has joined #asahi-alt
<cy8aer>
Ok, in Debian unstable glibc 2.38 is shipped. As I understand this library version is needed to get widewine running. So now I have some questions:
<cy8aer>
- does stock glibc 2.38 really works with widewine
<cy8aer>
- Are there actual recipes laying around which describe how to get widewine running?