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
zumi_ has joined #asahi-alt
zumi has quit [Remote host closed the connection]
zumi_ is now known as zumi
zumi has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
jn has joined #asahi-alt
jnn has quit [Ping timeout: 480 seconds]
ciara has quit [Remote host closed the connection]
ciara has joined #asahi-alt
ciara has quit [Remote host closed the connection]
ciara has joined #asahi-alt
dcavalca8569 has quit [Ping timeout: 480 seconds]
dcavalca8569 has joined #asahi-alt
Guest4698 has joined #asahi-alt
Guest4698 has quit []
ipatch has quit [Quit: WeeChat 4.5.0]
n3ph has joined #asahi-alt
<chaos_princess> chadmed / n3ph: is steam currently working for y'all?
<chadmed> chaos_princess: yeah ive been playing hl2 all night
<chadmed> did something break for you/
<chaos_princess> fails to start here, the classic "steamwebhelper not responding", but waiting for like 5 mins changes nothing
<chadmed> wehhh
<chadmed> did steam update? nothing else has really changed recently
<n3ph> I am still unsetting LANG before starting steam and I am on FEX main HEAD.
<chaos_princess> idk, probably
<n3ph> So far, all is working more or less, except Factorio
<chaos_princess> running as `muvm bash` then `FEXInterpreter /usr/bin/steam -cef-force-occlusion -cef-force-opaque-backgrounds` if relevant
MichaelLong has quit []
<chaos_princess> n3ph: tyvm, LANG is the culprit
<chaos_princess> which is weird since i have it set to C.UTF8
<chaos_princess> what is it set to on y'all's machines?
<n3ph> chaos_princess: This LANG workaround is really wired. I was bisecting a while ago, but the changes in the triggering commit are trivial and unrelated to the bug itself
<n3ph> I have `C.UTF8`
<chaos_princess> oh, the thing we suspect to be a race condition?
<n3ph> yes
<chadmed> iirc youre not supposed to use C with steam
<chadmed> it doesnt like it
<chaos_princess> what is it on yours?
<chadmed> do you think i can remember where i read that at 12:30am? not a chance lol but i did read it
<chadmed> en_AU.UTF-8
<chaos_princess> hmm
<chadmed> i need to figure out how to debug games in the vm too
<chaos_princess> did `export LANG="en_US.UTF8"`, steam still works
<chadmed> i finished dxhr again and wanted to go through dxmd again, but neither the opengl linux build nor the dx12 windows build work... and i dont have enough space on my macos partition for the metal build :p
<chaos_princess> so i guess C locale is busted somehow
<n3ph> chaos_princess: ack, just tried that ATM as well - same here
<chadmed> yeah i think i read on the steam runtime readme or something that you shouldnt use C as the locale
<chaos_princess> don't bother with dxmd, unless you like cliffhangers :P
<n3ph> interesting. But why would this end up in that race condition
<chaos_princess> n3ph: can you re-link the culprit commit?
<n3ph> mom
<chadmed> chaos_princess: ive played through it three times already :p
<chadmed> i remember the first time i played it when it came out i woke up everyone in the house with a mighty "WHAT THE FUCK IS THAT IT ARE YOU FUCKING KIDDING ME"
<chadmed> then i read that squeenix made them cut 2/3 of the game out to sell as expansions, but the game sold like ass because it was "unfinished" so they canned the expansions and fired the team
<chaos_princess> for debugging games in vm - just gdb and strace, the issue is debugging stuff inside fex, which is currently "gdb and pray you will be able to understand what is happening (you won't)"
<chaos_princess> they are working on better gdb support though
<chadmed> the issue is that all games immediately crash with X issues
<chadmed> lina thought it was xshmfence but we've got all that set up correctly on our side
<chaos_princess> sqenix and being disappointed with just multiple million copies in sales, name a more iconic duo
<chadmed> adam's body in the versalife vault is some brilliant foreshadowing for where squenix and whichever PE firm they sold deus ex to have taken the franchise
<chaos_princess> n3ph: ah, ok, thats probably not it
<n3ph> That was the 12th of December: https://oftc.irclog.whitequark.org/asahi-alt/2024-12-12
<chadmed> that commit exists in muvm-0.2.0 so that wouldnt have caused things to magically break
<chaos_princess> yea, its something that got broken since locale now started being passed through
<n3ph> At least, that was it breaking steam form me, it terms of that wired race condition
<n3ph> Wich makes sense, as LANG is passed to muvm from there on
<chadmed> long term fix is to put whoever designed steam for linux into a big mincer and turn them into sausages
<chadmed> well its like this on windows and macos these days too
<chaos_princess> huh "[2025-01-01 15:33:39] WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work."
<chaos_princess> so, C works better than C.UTF8?
<chadmed> is that error from the steam runtime?
<n3ph> yes
<chaos_princess> yes
<chadmed> i _think_ we're missing some x86 things that steam really wants
<chaos_princess> nvm, im dumb, its utf8, not utf-8
<chadmed> might be worth hitting up the fex discord. last time apparently n3ph's steam install was "buggered" (ryans words)
<n3ph> Also, I don't really know why I am using `C.UTF8`.. I assume most users will have a more specific locale set.
<chadmed> we should probably throw renderdoc in the next build at least just to shut some linker errors up
<chaos_princess> not the case here since i wiped and reloaded it entirely as a part of my debugging
<chaos_princess> and with en_US.UTF8 i get "cannot read properties of undefined" in steam window
<n3ph> chadmed: I always got and still get these logs, with newly bootstrapped steam installs
<chadmed> chaos_princess: inside the store page cef frame?
<chaos_princess> yes, primary cef frame, and it does not open any specific tab, just that error full screen
<chadmed> oh huh thats a new one
<chadmed> ive had the store page crash with a similar error but ive been able to get to the library no worries
<chadmed> ohhh is that -gamepadui?
<janrinze> quick question: if i want to start over with installing Debian on a M1 Mac Studio, should I still use Glanzmann's installer or is there a newer installer?
<chaos_princess> no
<chaos_princess> thats for chadmed, no idea about debian
<chadmed> janrinze: cc cy8aer
<chadmed> chaos_princess: oh huh yeah ive never seen that one before then
<chaos_princess> full screen as in full window, not entire screen as if i was using big picture mode
<n3ph> janrinze: Wasn't that this one? git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/
<chaos_princess> kinda feels like everything locale-related is some flavour of broken
<janrinze> n3ph: yup, that's the one I used originally
<chadmed> chaos_princess: do we generate the locales for the rootfs as part of the gcc build?
<n3ph> haven't heard of anything newer, but no guarantee...
<chaos_princess> no
<chadmed> err, glibc*
<chaos_princess> well, we emerge it, but nothing beyond that
<chadmed> might be worth adding a package.use with "sys-libs/glibc compile-locales"
<chaos_princess> but shouldn't it just pick locale files from host os?
<chaos_princess> or how does that whole thing even works?
<n3ph> it should, if there are non in the rootfs, I think
<janrinze> cy8aer: you know how to install a more recent Debian on a M1 Mac Studio?
<chadmed> i mean id _hope_ so...?
<chadmed> what locales do you have compiled on your host then
<cy8aer> Unfortunately it is still the old bootstrapping from glanzman and then using my libraries.
<n3ph> cat /etc/locale.gen | grep -v "^#"
<n3ph> en_US.UTF-8 UTF-8
<n3ph> de_DE@euro ISO-8859-15
<chaos_princess> only en_US.UTF-8 UTF-8 here
<n3ph> But: `WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work.`
<cy8aer> I have a recent life image. Just give me a second to find the link
<chadmed> n3ph: thats why i have a suspicion that the x86 glibc may only be interested in the x86 rootfs's locales
<chadmed> idk if theres some ABI nonsense with compiled locales or something
<chaos_princess> where do those live?
<chadmed> usr/share/locale/ i think
<chadmed> wait no thats something else
<chadmed> well /usr/lib/locale/locale-archive is certainly a binary file
<n3ph> `strings /usr/lib/locale/locale-archive | less`
<n3ph> But there is also `localedef --list-archive`
<chaos_princess> ok, so i think i get what is happening. The correct locale name is C.utf8
<chaos_princess> and it is the only locale that we have in overlay
<chaos_princess> now wondering if i should recompile glibc with the relevant flag or nuke the relevant file from the overlay and let it pick the host file
<chadmed> worth trying the latter
<chadmed> compiling locales on the 5 Hz single core the CI farm gives you will be deeply unpleasant
<cy8aer> janrinze: this could be a good documentation base for installing: https://git.g3la.de/repos/m1-debian/wiki
<chaos_princess> yep, that works
<chadmed> lets go
<n3ph> `yep, `C.utf8` works
<chaos_princess> well, considering that all caches expired, gitlab's 6502 will have to work overtime no matter what approach i will take
<chaos_princess> so, pr tomorrow-ish i guess
<n3ph> Just to mention `SteamEnv=1` is pointless, I've tried
<chadmed> they really need to just like re-engineer the steam client from the ground up again
<chaos_princess> tbh using electron proper instead of cef might be an upgrade
<chadmed> qt6 steam pl0x gaben
<chaos_princess> which is not a sentence i've ever expected to type
<chadmed> i wonder what the cef->electron porting effort is like
<chadmed> the most web i do is bastardised half-compliant ES5 for $work idk how cef/electron's js apis compare
<chaos_princess> js should be mostly ok, depending on how much custom api they have
<chaos_princess> it is the surrounding c++ that will be the issue
<chadmed> right so there is still custom business logic done in a real language in electron
<chadmed> what the hell is the point then just use qt and use qml for your UI which you can pretty easily just jank into Real(tm) javascript anyway
<chaos_princess> usually no/maybe, electron expects business logic to be in js on top of node, but you can call out to c++. cef is more ok with writing it in c++ straight in the renderer process
<n3ph> BTW, regarding Factorio 1FPS; This is the case for running in box64 as well. So not related to muvm+FEX...
<n3ph> I was running Factorio in box64 for a long time and that worked pretty well. So I expect something to have changed within mesa causing Factorio to not work well anymore..
n3ph has quit [Ping timeout: 480 seconds]
MichaelLong has joined #asahi-alt
MichaelLong has quit [Ping timeout: 480 seconds]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
chadmed has quit []
chadmed has joined #asahi-alt
ipatch has joined #asahi-alt
n3ph has joined #asahi-alt
dakralex has joined #asahi-alt
dakralex is now known as DanielKr
DanielKr has quit []
dakralex has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
n3ph has quit []
n3ph has joined #asahi-alt
n3ph_ has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
MichaelLong has joined #asahi-alt
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
n3ph has joined #asahi-alt
n3ph_ has quit [Ping timeout: 480 seconds]
kdb42490356 has joined #asahi-alt
kdb4249035 has quit [Ping timeout: 480 seconds]
kdb42490356 is now known as kdb4249035
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
dakralex has quit [Ping timeout: 480 seconds]