219 Replies
LET'S GOOOOOOOOOOOOOOOOOOOOOOOOOO
Ublue Asahi variant?
The first thing we're going to need to do is build out images for aarch64. This should be rather simple. We can't build for CI test so we'll need to build from the official images on quay. I'll be working on this today and hopefully have main images up by days end. This will entail splitting packages by arch and ensuring our CI can accommodate builds. We don't technically need ARM runners for this since we can simply pass what arch we want to buildah but that would significantly speed up the process
I'm looking through a project right now created by a Red Hat eng for providing Asahi Silverblue images to get a better idea of what that will entail but we have to tackle the prior first and foremost
Yup!
Are all Ublue packages available as arm64?
check the ARM thread with @ecurtin's work!
No. We'll need to build them out
we just need to finish off what he started, and it probably needs to be caught up
Definitely will!
there's a few arm issues in github
Maybe I will hold off doing mutable Asahi Fedora Remix for a bit.
Actually impressed with Fedora Asahi Remix. I haven't rebooted into MacOS since installing it. And software support is not nearly as bad as I thought it would pan out to be. Not having brew does burn a bit though
I'm hoping we can replace a lot of what I use there in Wolfi ^
github will have general arm linux servers this year, no committed date though, so hopefully not too long, but let's wolfi the world anyway, mwhahaha
That's awesome! Can't wait for that. In the meantime: https://github.com/ublue-os/main/pull/524
Going to go see Ghostbusters but I will be resuming work on this after
I really want to get some stuff cleaned up in HWE builds before we do this
(see https://discord.com/channels/1072614816579063828/1220077695279435777/1220095648268030106 )
Swore I pulled an aarch64 image locally using the same tag
We can't do this out of hwe
i didn't say we could
but i'm kinda tired of adding more and more complexity without cleaning things up
Have a list of items/an open issue? I'd really like to move this forward
huh are we pulling from quay.io/fedora now?
no
and not timothee's repo? Sorry on a plane can't look it up rn
Just for aarch64
Timothees repo doesn't appear to support aarch64
ah
oh dang I should have asked him about arm builders, I was supposed to make sure he hooked up with equinix... fuuuuu that's on me
I didn't realize until today lol
Would prefer by a mile to continue using his images
i'm still unclear if quay.io/fedora images will be published reliably starting with F40
they will, they will not be signed
that's good but since quay.io/fedora doesn't publish a "base" image, we are still hurting slightly where we use that...
do we know what they're publishing ARM wise?
i think they do publish both arm and x86_64 for all the atomic desktop images
oh that doesn't sound so bad
sorry, i'm kinda taking this thread over RJ, i'm just in flight on the F40 preview stuff, which will remove some images for the future
plus started working on hwe merging (see the thread I linked)... and I see those things as cleanup which would be nice to do before adding more complexity...
should we add an order of operations?
and @j0rge no word yet from Timothee on the names for thsoe F40 images, so i'm about just do what we have now
YOLO
rename later if need be
maybe aarch64 isn't actually blocked, i just feel sick and tired (literally) and don't feel like dealing with more shiny right now
ack
let's reconvene tomorrow or so, he's seeing a movie and I'm over the atlantic lol
I didn't know we had started on hwe, I thought we were on f40 enablement
re: F40... i'm fine with YOLO, i just kinda expected more of our core contributors to weigh in
i thought Noel created a PR/issue, but maybe he didn't... i can do so... I have some stuff I started locally, but my brain is mush
might be time to trim active approvers then
or we can actively start pinging approvers directly
@bsherman I can't read through this rn (in a rush) but I'll take a look when I get back
I did not create an issue. I thought your acknowledgement was something you were going to do, sorry!
no worries, i can create one... i think i'll do it in nvidia
no worries
lets just not rush anything
It's my opinion if aarch/asahi images are experimental at this point, I don't think cleaning up the HWE stuff is a blocker for it.
I would just understand that they are not a priority right now.
I do agree getting some help on consolidating the HWE repo would be highly appreciated though.
not quite as fun work, but it will be 100% worth it.
@EyeCantCU THis may interest you: https://github.com/ericcurtin/fedora-asahi-ostree-desktops
Im gonna leave a message here because of interest
Yup. That's the repo I mentioned earlier :). There's also an open issue covering more of what needs to be done
Can look over what we've got open currently
Okay, now I know why the check failed... The behavior of the
--platform flag in Docker isn't quite the same as it is in Podman. Setting --arch instead fixes the check, but errm.... anyway, let's definitely discuss or talk on this. Tomorrow should be completely open for me so we can break things down over a call (messages over Discord work too) if you're all available so that we can prioritize what we need to get out of the way since F40 is right around the corner. Taking a look at our PRs for F40 right now to get a better idea of what things look like
If all atomic desktops currently offer aarch64, we can get those building as well, but if there are bigger fish, let's fry those...
Something more is going on here. I can get an aarch64 image with Docker but not Podman in CI...
If I use podman build with a Containerfile pointing to the official Silverblue image, it correctly layers aarch64 packages... So, obviously the tag supports the arch. I don't know why exactly podman is being weird in this case. Will keep diggingInstalled it finally on Friday to my mb pro but haven't had that much time to setup it. But seems to be in pretty good shape, I guess there are some issues with flatpaks
Has less issues than I was having on my XPS surprisingly. Unfortunately, my work laptop decided it was a good time to go so I've been setting up what I can on here until a new one gets shipped out
i still dream about a phosh or plasma mobile setup for mobile devices no matter how many people tell me "android and ios are fine though." we can take some ideas from postmarketos and apply them here. too bad phone and tablet hardware is barely supported ๐ฆ
and i guess we still need to focus on the desktop as a priority of course ๐
Well, once we have aarch64 builds we can offer that. I've hit a snag though. The official images on Quay don't support it. Docker was using emulation. I thought it was a Podman and went issue to issue because I had figured something like that would be reported but I was wrong
We can still do this. We just either need to get inventive and assemble our own base images or, better yet. If we could get in touch with Tim other and see about enablement on that side of things, even better. Already looking through his repo to try and figure out what we'd need to accomplish thst. Packages are already defined by arch so I'm surprised the images aren't multiarch
I could've swore the Fedora images were supposed to be multiarch though
What made it confusing is the Asahi OSTree repo is using the Fedora Silverblue image on Quay
Also the fact that rpm-ostree is so permissive about arch when you go to rebase is kind of scary. Outright was okay switching from the aarch64 image to an amd64 image and replaced arch specific packages without complaining ๐คฃ
hmmm...
I could've swore the Fedora images were supposed to be multiarch thoughI would also swear the official images are both x86_64/aarch64/ppc64 given the tags here: https://quay.io/repository/fedora/fedora-silverblue?tab=tags
Pardon me but what the heck ๐คฃ
Multiarch in Podman must be broken?
the farthest i've gone with aarch64 is an FCOS install on a Pi3, but it was painfully slow... so I didn't bother tinkering with building a ucore image... i want something a bit faster to test with
Going to try a few things
Podman, Buildah, and even ostree aren't recognizing it as multiarch
maybe try with something else known to be multiarch to verify?
are you building on an aarch64 machine?
or specifically specifying the architecture?
Hi Guys!
I'm joining from the Asahi perspective
I've been wanting a ublue variant for a while (well many in the community have including Hector Martin for the secure boot story), the main problem is having one Apple Silicon piece of hardware that I have my full Automotive development environment on that I have to actively use ๐
For sure! Thanks for joining in here. I'm happy to donate my M1 mac for testing if we need it. I'm not actively using it for anything!
If you'd like to change that to another repo feel free! There's a couple of different repos that could be used
Hey Eric, awesome to have you here! I'm not sure if what I'm seeing on my end is necessarily an issue with the image anymore. It's built for multiple arches. It's just that Podman doesn't seem to recognize aarch64 support is there so I'm slightly confused. Even when explicitly setting the platform
Sorry I want to make sure I understand.
Do you represent asahi or work on asahi?
I use our Chainguard images this way all the time
Yup. On the MacBook running Fedora Asahi Remix itself ๐
Well I work for Red Hat, I work with Asahi community also, I speak with them regularly, I enabled Rust for Linux kernelspace support downstream, enabled some kernel configs downstream in kernel-ark, gave some talks, fixed a couple of different bugs, etc.
Very cool. You would be welcome regardless, I just wasnโt sure of your comment.
I have to step away to feed children ๐
Ah wait I thought this was the aarch64 group, misread the title that's why I said Asahi perspective
Looking to pull off both. Aarch64 first and foremost
Well, if we are going to get aarch64 images working, we would probably want to target Macs as a platform.
Raspberry Pi 4 support is easier, it's more standardized. I would say Asahi is more useful though because the hardware is like a bazillion times faster.
So the fastest way to iterate is to run podman in an aarch64 Linux environment, that's what I'd recommend. You can jump into some issues using "--arch" flag for emulation, it might work for some specific tasks. But just running podman/osbuild/whatever natively on an actual aarch64 environment is better.
For sure! I've got the hardware to test as soon as we're able to produce images and then I was going to move over to Asahi support ๐
This will also be beneficial to bazzite long-tern also, there's murmerings of all sorts of powerfull gaming handhelds coming out for aarch64 soon
I've got it running on Asahi which should default to aarch64 during pulls but in spite of that I still get a warning saying it pulled the amd64 image and inspecting the manifest, I wasn't seeing aarch64 anywhere unfortunately
What image did you pull? Does it have a aarch64 image available? It might just fallback to pulling an amd64 one if an aarch64 one isn't available
That'll be nice. Honestly, I'm all in on ARM going forward. I've never had a laptop last this long on a single charge and perform this nicely at the same time
Yeah Apple Silicon is stupidly fast, it's almost addictive
It does. I pulled quay.io/fedora/fedora-silverblue which, according to the tags, should be supported
It is! And I very rarely hear the fans kick on or anything. Even while building more demanding packages
It's faster than my desktop
Did you try:
sudo podman pull --arch aarch64 quay.io/fedora/fedora-silverblue
you shouldn't have to do the --arch thing, but sometimes if you pulled an amd64 before it gets stuck on amd64 until you pull another aarch64 imageYup. I've tried that and with the platform flag :/
Weird I can't say I've run into this issue
Maybe just ask in a podman channel, it sounds like a generic podman issue you are running into
And there's Qualcomm boards coming out that are basically equivalent performance
Have you pulled this image specifically?
Yeah in the past I'll try again now, but I have to get back to work shortly have some tight deadlines this week
No worries! Would just be good to narrow it down to a single computer having the issue.
I'll have to do that. Thanks for your help with this ๐
I've heard about those. It's awesome to hear the performance will be close, especially after their last attempt at making a higher performance chip lol
I run into this regardless of whether I use my MacBook or my desktop unfortunately. It doesn't seem isolated but having confirmation from others would definitely be appreciated
@ecurtin thanks for dropping in again! We have fresh blood to give this another try lol.
@EyeCantCU I think I figured out the issue https://quay.io/repository/fedora/fedora-silverblue?tab=tags&tag=latest if you hover over the penguins, you see only fedora 39/40/41 have aarch64 built images available, so don't pull latest, pull a specific version
Quay
Quay is the best place to build, store, and distribute your containers. Public repositories are always free.
So maybe something like
sudo podman pull --arch=arm64 quay.io/fedora/fedora-silverblue:39
But as I said the --arch shouldn't be necessary, it should default to arm64 if it's availableI'm omw to pick up my replacement work laptop but thank you so much!!! I'll try it as soon as I am back and settled
This is the main Fedora Asahi Development channel if anyone wants to join here https://matrix.to/#/#asahi-devel:fedoraproject.org
Matrix - Decentralised and secure communication
You're invited to talk on Matrix. If you don't already have a client this link will help you pick one, and join the conversation. If you already have one, this link will help you join the conversation
No luck with any of the versioned tags unfortunately
It works for me ๐
A podman channel might be better to debug
I'll give that a go haha
You can actually build this stuff without podman too, that's an option
I just sometimes find the Containers easier than like just soley osbuild etc. you have a lot more freedom for customization
Very interested in this! Anything I can help with?
I'm working on packaging a competitor to Box64 that Valve is funding
Our CI unfortunately encounters the same problem I do locally. I had considered osbuild but it doesn't sound like it will be ready for a while and setup would vastly deviate from main if we did go that direction... Then again, aarch64 support isn't something we've had in the past and having some form of a testing ground for this stuff could be promising for when it is ready. Most definitely off in its own repository if we went that route
weird.
what does your podman pull command look like?
Hey Kyle! I'm just trying to produce base aarch64 images at the moment and I'm struggling with that because our current tooling (Podman/Buildah) isn't recognizing the arch for the official Fedora images properly. If you get the chance, I'd really appreciate it if you could help figure this one out. If not, I'll ask about it in other channels when I have some free time ๐
podman pull --platform linux/aarch64 quay.io/fedora/fedora-silverblue:39
I've also tried with --arch
But like... This is even the case for BuildahSure, can you point me to a repo?
I've got an open PR up in main. I'll share
pulling down trying this:
podman pull --arch=arm64 quay.io/fedora/fedora-silverblue:39
easy way to inspect the pulled container when I'm done?
got this warning: WARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)
this shows up as an option in the manifest.
using
podman manifest inspect quay.io/fedora/fedora-silverblue:39Yup. Which makes it doubly confusing it isn't recognized as an arm64 image by podman initially or buildah
I wonder if there is something wrong on Fedora's end?
I could post in the ostree desktops matrix channel.
Would really appreciate that
gonna try pulling 40 instead.
Wasn't having luck with 39, 40, or 41 unfortunately
does chainguard publish aarch64 images? maybe validate podman/skopeo tooling with a different image publisher?
Yes, we do. I use Podman with our images pretty much every day ๐
ok, so it's not podman/skopeo, it really seems like the images themselves are not what they appear to be
just to confirm, you're doing the --arch=arm64 for the chainguard images and they are appearing correct?
Yes, that works :). But even if not set, aarch64 is the native architecture of what I work with
Gotcha, hopefully Timothy or someone can give an answer tomorrow about it.
we could also work upstream and help timothy just update his workflow to include building and tagging ARM images.
Would love to help him with this
And I appreciate everyone here jumping in to help out. You all are amazing
well, i for one hate arm
and 64
who needs 64 arms
that's a MONSTER if you ask me
just cut off 62 and have 2 arms like a normal biped
Lmao
I wouldn't want 64 arms either
fun
@EyeCantCU the metadata is wrong.
:facepalm:
it is the right image.
architecture is set wrong lol
or it could be quay.
Thanks discord for blocking facepalm behind Discord Nitro... Anyway lol
That would explain it
yeah, It's something we should report to timothy.
It's awesome we finally have an explanation for this outside of "it's broke"
yup. I reported it in matrix, hopefully Timothy or someone sees it and corrects it ๐
nice!
Thank you Noel!
Yea, post-flatpak Noel is the best Noel!
Relaxed Noel
I'm almost done with Flatpaks.
I swear.
I want so ****ing badly to be done.
In other words FEX? ๐
yup
FEX looks promising ๐
Going to look at enabling aarch64 in CI test today after I wrap up a few things with work
Thank you so much for the heads up. I'd be happy to help with whatever is holding the images back
Hey everyone - sorry for the lack of updates the last few days. Things got really busy with work. Crazy fun, but busy lol
I didn't realize it at first, but our copr is building out aarch64 packages ๐
Hi yall, while I do not have the skills to help much with code, if anyone needs something tested on apple silicon hardware, I have an m1 macbook air that I would be happy to temporarily sacrifice to beta testing during my spring break (next week), or later on, maybe this summer. I am excited for immutable asahi linux, but I know this project complicated and time consuming, so I hope I can be helpful to somebody here.
sorry if this has been answered before but is the asahi version going to use gnome by default? itd match the mac aesthetic much closer. and is there a wiki or something so we can add stuff like this to a sort of FAQ
ideally we'll have mac versions of each image
Asahi kinda defaults to kde, but i heard that is just bc the devs were easier to work with, so it reached a stable implementation faster. UBlue might actually have make a decision if fedora goes through with changing workstation to kde in 41 or turns down the proposal
Oh hopefully they switch to defaulting to gnome
I definitely want to cover each image. KDE currently has the best support but there's no reason we shouldn't be able to build out images for everything with aarch64 support
If most DEs and WMs are supported, the default wonโt matter too much since it all comes down to picking from a dropdown on the new uBlue site
While Iโm here I just want to add that Iโm now on spring break with an unused MacBook Air, and I would be happy to help out if anything already needs bare metal testing
Defaults always matter imo. People get choice fatigue and go with the defaults
I don't really see a problem with KDE being the default for Asahi if they're the ones currently most cooperative with the Asahi developers
Yeah, no sense using GNOME if it's sub par
Use what works best
Exactly
Better Mac support is literally in the list of benefits for the proposal to switch workstation to kde
Let's keep the thread ontopic please
Asahi will not default to gnome, that is for sure
:'( sad
I agree! Both KDE and Gnome work great with Apple Silicon
Don't believe everything you hear/read Gnome works fine too ๐ This is more KDE is my favorite desktop, so I'm gonna promote it kind of talk. Both Gnome and KDE work great
This feedback about KDE being so much better on Apple Silicon is from people that have been using KDE as their primary DE before Asahi even existed
I switch between KDE <-> Gnome in general
I'm really excited in putting some universal blue on my macbook air m1.
Blocked by ongoing work for now: https://pagure.io/releng/issue/10399
@Danielle I responded on the ucore aarch64 github thread and I'm mentioning you here for reference to what discussion has occurred related to the desktop builds.
Very little coreos specific effort has been made (except that I did once test install aarch64 coreos on a Pi3, which was so slow I ceased spending time on it).
@EyeCantCU I know you've confirmed the fedora atomic desktop images on quay.io are not getting aarch64 properly... but do you know if this is true for the fedora-coreos images, too?
The Fedora CoreOS images are good to go. If you want to do
aarch64 ucore, we canA nice blueprint for what this can look like https://github.com/ondrejbudai/fedora-bootc-raspi
GitHub
GitHub - ondrejbudai/fedora-bootc-raspi: Fedora bootc image for Ras...
Fedora bootc image for Raspberry Pi. Contribute to ondrejbudai/fedora-bootc-raspi development by creating an account on GitHub.
heh, the floodgates are opening! Let's gooooooooooooooooooooooooo
I would say we are not as blocked on this as we think, 90% of the enablement doesn't require a desktop the published Fedora IoT should be good enough to start
Fedora IoT is just Kinoite/Silverblue without Plasma/Gnome pretty much
We don't currently offer IoT images but we could build them out. It would give us something to start with. Will investigate this weekend
This is really awesome
Yeah just as a development thing it would be very useful to start
yeah, I heard that Fedora IOT was one of the first projects upstream looking at doing bootc?
Yup
That repo referenced above is a Fedora IoT image for Raspberry Pi
excellent, yes, this would be a great way to start.
For sure! Thanks for the resources. I'll try and get something set up ๐
so does this fedora-bootc image have arm builds for it then I'm assuming?
Yup it sure does
heck yeah.
We'll call it IoU (just kidding)
Here is the main repo for fedora-bootc: https://pagure.io/fedora-iot/fedora-bootc
forked off this guy: https://github.com/CentOS/centos-bootc
It was said the kernel replacing using bootc isn't in a great place right now, maybe ublue should start with Raspberry Pi 4 because it's the normal Fedora kernel ๐คทโโ๏ธ
only bazzite is using a custom kernel right now, everything else is still stock
And Asahi unfortunately
We have to build a custom kernel for Asahi and that's not gonna change anytime soon, there's multiple reasons, you need to build for 16k, Rust for Linux support, not yet upstreamed stuff, etc. The stock Fedora kernel on Apple Silicon boots and not much else
Appreciate the heads up. Unfortunate to hear that. Can start with Pi compatibility
Wasn't it set to 8k at one point?
I have a decked out pi 4, so I'm down to test these
oh, I had forgotten, yes of course. ๐
Na it was always 16k, you can get 4k to boot, buts it's missing so much functionality it's hard to recommend.
Well, shipping it with 16k helped me resolve an issue with a lot of our rust packages the other day so it actually works out ๐
There's actually a huge list of page size issues we fixed in Asahi in all sorts of random projects, it's so rare for people to run on anything other than 4k, we encountered many 4k assuptions in applications
But it's pretty good now we haven't enountered many in a while
macOS is a 16k OS also, so that's part of the reason it works best, the hardware was designed that way
That's really cool to hear! It was definitely a fun thing to get sidetracked with. I haven't had many issues with Asahi honestly. It works very well. There's a few things that aren't packaged that I use in my workflow but that gives me something to do when I have the time to get to it haha. I guess the biggest thing I've noticed is that putting it to sleep doesn't really do much of anything. End up powering it off when I know I won't be using it for a while
All right, working on bootc images right now. Also going to write an action that pulls the image down and converts it over to an .xz
๐ค https://github.com/ublue-os/main-bootc/actions/runs/9044052234/job/24852292190
https://github.com/ublue-os/main-bootc/pkgs/container/bootc-main
Now to do AArch64
๐ฎ
Now that's strange: https://github.com/ublue-os/main-bootc/actions/runs/9044203244/job/24852621279#step:11:486
Errors galore... and it's... green
Well... an arm64 image was pushed to latest fwiw:
"Architecture": "arm64",upto you guys now๐ญ
Going to return to the tagging issue later today. In the meantime, an aarch64 image is building. Going to push ahead to a Pi image and revisit afterwards
Have multiplat images building with Docker, buildx, and qemu. Just need to fix auth!
Calling it a day but we now have base bootc images built for aarch64 and x86_64 to work with. And that's without aarch64 runners :). CI quirks have been worked out. Building an image for the RPi this week and I'll be looking into building out images with DEs as well
Nope
I did add an aarch64 build for my sunshine copr today if anyone feels like experimenting with it down the line https://copr.fedorainfracloud.org/coprs/matte-schwartz/sunshine/
they stopped building their arm version upstream since it was destroying their GitHub runners
I only have an M3-chip MacBook Pro so no asahi for me for awhile
That's awesome. I'll give it a go this weekend. Although, I'm not sure how far OpenGL 4.1 will get me ha
That would be ideal at the moment, but there are blockers (linked above). Working on bootc images when I have the chance. Hoping to make some progress today
Here's where everything is tracked. As for ci-test specifically, I'm unsure: https://pagure.io/releng/issue/10399
That's what I got when I asked ๐
Yes
Applies to the official images
No they don't
they have tags but dont have images
The official Atomic images currently only support x86 64
The images on Quay are x86 64 only
Yeah, it's confusing. Things are all over the place
Timothee has atleast somewhat working Kinoite (asahi) installation
yesss
Oh my gosh this is amazing
Yeah, I am curious where the code is for it.
Last time I remembered, there wasn't any container images for arm.
Maybe that has changed?
Curious where it's sitting as well. Will look around
Update to this:
I literally can not wait to get Ublue Asahi images out the door
Timothee is a legend
Well the Asahi team has been really great. Lot of bugs have been squashed during the week
Can't wait
Probably one of the coolest things uBlue could do for itโs asahi build would be providing an easier way for inexperienced users to toggle the apple_dcp.show_notch=1 kernel parameter to enable the space around the notch to actually be used. Iโm not sure if โbatteries includedโ is still terminology used anywhere on the site, but this feels like a pretty good example of that.
we're doing kargs for specific hardware already, shouldn't be too hard
I heard Hector Martin is against the idea because heโs waiting for a Wayland protocol to stop fullscreen apps from using the notch space, but the only time it really is an issue is if youโre watching a video feed taller than 16:9 (16:10, 4:3, etc) as it will be be partially behind the notch instead of exclusively using the space below it. I think as long as itโs either opt in or opt out, not mandatory, itโs pretty much fine.
Gist
Asahi Linux - krun + FEX + Steam
Asahi Linux - krun + FEX + Steam. GitHub Gist: instantly share code, notes, and snippets.
It would also be super cool to have a steam container on the image as well. In case yall havenโt seen it yet, I think this is the most up-to-date guide on how to set that up. Sorry for all the spam in the thread Iโll stop now
Would love to disable the notch cutout out of the box or automate that as I needed to disable it when I installed Asahi for the extra screen real estate. I use a screen magnifier and losing even more screen space just wasn't going to cut it
Quay
Quay is the best place to build, store, and distribute your containers. Public repositories are always free.
just saw this on timothee's livestream ^
Can you link to the livestream?
Fedora Project
YouTube
Fedora Linux 40 Release Party โ Day 2
Register now to gain access to the event chat: https://pretix.eu/fedora/f40-party/
The Fedora community will celebrate the release of Fedora Linux 40 with a virtual Release Party on 24-25 May 2024. For a few hours each day, Fedora contributors and leaders will speak about recent changes in Fedora Linux and the Fedora Project. Our global Release...
lol I shouldโve thought of that, I was trying to find a YouTube channel under his name
I know what I'm doing today!
noel is up in 20 minutes, I'll put it in announcements
how do you join this?
went through the "ticket" process and no invite
seems to be matrix only?
yeah lol
yeah, I wonder if invites got shut off today or something.
kinda dumb..;
Asahi Lina (ๆๆฅใชใ) // nullptr::live
vt.social
Asahi Lina (ๆๆฅใชใ) // nullptr::live (@[email protected])
Attached: 1 image
โจ We got a bunch of Steam games to run on Asahi Linux!!! โจ
Most of them run at a solid 60FPS and all of them are playable on my M2 Pro~ ๐
All running on a krun microVM with FEX and full TSO support ๐ช
I was not expecting Party Animals to run! That's a DX11 game, running with the classic WineD3D on our OpenGL 4.6 driver! ๐คฏ
W...
Felt like I should share this, since I linked to a (likely now outdated) guide for a similar setup yesterday
the wild thing about this for me is that the games are running in a small vm
๐ค CI up for Asahi images leveraging Timothee's images as a base: https://github.com/ublue-os/asahi/actions/runs/9257408963/job/25465451642
Now I need a way of installing these on my Mac :heh:
Gradually working on restoring things we have in main
Rebuilding powerstat with aarch64 support so that our just config drops in...
Ah wait
Exclusive arch is set to x86_64
Will have to make the dep conditional
Kind of. They're moreso for testing at this point than actual day to day usage
I mean the Asahi ones are the โonlyโ ones currently available to pull with a arm64 tag if Iโm not mistaken
Yes
What would a kinoite bootc image be for example? i wanna try this in a VM
There isn't one. You would have to use fedora-bootc and layer on the KDE packages.
I see
but that means it's doable.