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
Dcow has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
<chadmed> scardracs: what do you mean the file provided by asahi linux? thats to build an arch imag
<chadmed> gentoo's livecd boot infra is completely different and incompatible which is why we need to do some evil things to the ISO
<chadmed> ideally we would not, and i worked on building a bootable disk image a little while ago that we can just distribute so users dont have to worry about bootstrapping it themselves
<chadmed> but at the moment i have more important things i can be working on
leafpaw has joined #asahi-alt
digicyc2 has quit [Ping timeout: 480 seconds]
ma3 has joined #asahi-alt
phire_ has joined #asahi-alt
phire is now known as Guest501
phire_ is now known as phire
ma2 has quit [Ping timeout: 480 seconds]
Guest501 has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
Glanzmann has joined #asahi-alt
<Glanzmann> janrinze: It is the right file. I extracted it from the Debian installer packages. On my air I run the gpu branch of m1n1. That is why the file size is different.
<Glanzmann> Let me know how it goes. Anyway back to work.
Glanzmann has quit []
nopeslide has joined #asahi-alt
Dcow has joined #asahi-alt
evanzheng has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
nopeslide has quit []
nopeslide has joined #asahi-alt
evanzheng has quit [Remote host closed the connection]
<scardracs> chadmed: understand
chadmed_ has joined #asahi-alt
Dcow has joined #asahi-alt
jamespmorgan has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
jamespmo_ has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-alt
chadmed_ has quit [Remote host closed the connection]
jamespmo_ has joined #asahi-alt
jamespmorgan has quit [Ping timeout: 480 seconds]
tobhe_ has joined #asahi-alt
tobhe has quit [Ping timeout: 480 seconds]
beeblebrox has joined #asahi-alt
KDDLB has quit [Quit: Ping timeout (120 seconds)]
kode54 has quit [Quit: Ping timeout (120 seconds)]
KDDLB has joined #asahi-alt
kode54 has joined #asahi-alt
benzmac16v has joined #asahi-alt
benzmac16v has quit [Ping timeout: 480 seconds]
benzmac16v has joined #asahi-alt
benzmac16v has quit [Ping timeout: 480 seconds]
<janrinze> tobhe_: does your Ubuntu installer play nice with Mac Studio Ultra?
<tobhe_> janrinze: I see no reason why it wouldn't, but I haven't tried.
<janrinze> installing now.. we'll see
<tobhe_> awesome :)
<janrinze> i noticed that i'm running osx 12.4 but the installer says it can only see 12.3
<janrinze> I need a fall-back linux option so i decided to try Ubuntu for that ;-)
<janrinze> tobhe_: your build scripts are nice. I'm curious, when was the latest build done?
<tobhe_> latest build should be from ~3 weeks ago
<janrinze> nice. so it has just about the latest of 'everything' ;-)
<tobhe_> I am working on new kernels atm and will do new builds once those are out
<janrinze> my curiosity was peeked because Ubuntu and Debian are 'siblings' ..
<janrinze> my Debian install is rather broken and I'm hoping that Ubuntu may be of help
<janrinze> it's unfortunate that OSX does not have native ext4 support.
<tobhe_> it is. I sometimes use a small fat partition to pass things from macos to linux. I think I've seen others use a fuse apfs implementation to mount their mac volumes
<janrinze> passing files is not my issue, fixing things on an ext4 partition is.
<janrinze> aha.. kernel 5.19.5-10
<janrinze> tobhe_: USB3 support is in 6.x i.i.r.c.
<tobhe_> you can install linux-asahi-edge or wait a day to get the new 6.1 kernel
<janrinze> can wait a day :-)
<tobhe_> it is currently stuck in the launchpad build queue
<janrinze> if i build 6.1.0-rc6 with debbuild would that work okay?
<janrinze> tobhe_: might be good for me to just do some excercise.
<tobhe_> that should work. you might have to manually update m1n1 after installing the kernel to get the new device trees
<cy8aer> hm, I wonder why @Glanzmann did not build 6.1.0-rc6 with debbuild...
<janrinze> that's something i certainly don't like about the way we boot.. device tree should not be hard coded in a bootloader. preferably it should be attached by grub
<janrinze> how are we supposed to support fall-back to an older kernel?
<j`ey> try not to break backwards compat :/
<janrinze> j`ey: not sure what you mean.
<scardracs> chadmed: ChaosPrincess: do you have any img file that can be flashed into an USB for usb booting?
<tobhe_> I don't think there's a hard break. some drivers might not attach properly
<j`ey> janrinze: try make it such that newer DTs work with older kernels
<janrinze> j`ey: sure.. but is that the case now? is 5.19.x compatible with >=6.1x ?
<tobhe_> should be compatible enough that it still boots
<j`ey> I think USB won't work :(
<janrinze> j`ey: also a kernel upgrade requires a bootloader upgrade..
<tobhe_> you can restore the 5.19 bootloader by running update-m1n1
<janrinze> and break the grub entry of a newer kernel subsequently..
<j`ey> janrinze: only if you need to update the dtb too
<janrinze> j`ey: dtb's are in constant flux for the time being.
<tobhe_> update-m1n1 doesn't touch grub at all
<janrinze> installing a kernel does.
<j`ey> janrinze: yes, but a kernel upgrade doesnt require a bootloader upgrade
<janrinze> j`ey: unless the dtb has changed, right?
<scardracs> j`ey: but you may want to do so if you want to boot into new kernel
<j`ey> janrinze: right
<scardracs> At least grub-mkconfig should be used
<scardracs> If not done by the package itself
<janrinze> j`ey: my whole trouble started when i read USB3 support somewhere and hoped to get it working..
<scardracs> janrinze: ATM it is enabled only on linux-asahi-edge
<janrinze> scardracs: then we have to explain to the debian people that the kernel build process requires a m1n1 build and u-boot build..
<scardracs> janrinze: the optimal thing is that kernel upgrade calls both automatically
<janrinze> scardracs: a debian kernel build will generate .deb packages that play nicely with previous installed kernels
<scardracs> But, for e.g., it’s not done automatically in gentoo (because we love pain and suffer lol)
<janrinze> scardracs: would that imply we will get a m1n1 .deb package and a u-boot .deb package?
jamespmorgan has joined #asahi-alt
<janrinze> scardracs: ARCHLinux collaborates with the packages for Asahi Linux for these, right?
<scardracs> Janrinze: it should be
<scardracs> ArchLinuxARM does not collaborates at any level with Asahi for now, IIRC
<janrinze> so all distibutions need to adapt for asahi linux then..
<scardracs> I don’t know if things are changed
<scardracs> janrinze: well, yes
<janrinze> choosing 4k display in the display settings would be nice..
<scardracs> janrinze: when GPU driver will be ready it should works on 4K too
<janrinze> scardracs: the drm driver is supposed to handle that.
<scardracs> Yep, but atm is working with CPU
<scardracs> We need the GPU driver made by AsahiLina
<janrinze> i guess you misunderstand.. the bootloader is already supposed to read the info from the monitor and set accordingly.
jamespmo_ has quit [Ping timeout: 480 seconds]
<scardracs> I'm not saying it doesn't work. I say that you need the driver for the GPU to make everything work properly
<janrinze> scardracs: Lina is working hard on hardware accelerated graphics driver. if u-boot can set the resolution then why can't the drm driver..
<scardracs> Because DRM driver is not ready to handle it (also because u-boot is just a line command bootloader, not an entire interface)
<j`ey> u-boot doesn't do anything there, m1n1 does
<janrinze> okay, m1n1. but it is still available code.
<scardracs> j`ey: right, m1n1
<scardracs> Anyway we need to wait for AsahiLina’s GPU driver to sort these things out. I can’t wait for a testing version of it
<scardracs> I’m sure it will be awesome
<janrinze> scardracs: i much more prefer incremental upgrade so that a large user base can report findings. The whole big-bang strategy that depends on one person is a bit risky
<j`ey> well thats what linux-asahi-edge is for, it has incremental features like DCP
<j`ey> (I also dont agree that the GPU thing is a 'big bang strategy')
<j`ey> there's no point releasing something which has so many bugs/issues that everyone will run into the same issues
<scardracs> janrinze: I don’t know anyone here that can do the same work that AsahiLina used to do in past months. Asahi Team is really small compared to other groups but see how far they go just using reverse engineering
<scardracs> j`ey:
<scardracs> I agree with you
<janrinze> scardracs: incremental upgrades allow for more developers to work on a part and get those patches up stream
<j`ey> you cant really do incremental until enough of the basic features are working
<j`ey> or parallel
<j`ey> paralell? both look wrong
<scardracs> parallel
<janrinze> j`ey: i disagree but then i'm old school..
<j`ey> janrinze: what do you disagree with?
<j`ey> you think multiple people can work on the code when it doesnt boot at all yet?
<j`ey> or when it renders one frame but then just crashes?
<janrinze> about not being able to do incremental until enough of the basic features are working
<j`ey> I also dont see how that relates to old school
<janrinze> j`ey: drm driver has basic things like setting the resolution..
<j`ey> well then you can work on it ;)
<j`ey> lina isnt working on the dcp driver really, that's been other people
<janrinze> what i mean is that is quite feasible to implement a subset of the functionality and gradually implement more..
<j`ey> yeah, that's whats happening
<j`ey> but you have to implement enough of the functionality for it to be usuable.. and DCP has just about reached that point, so is available in -edge
<janrinze> well.. in special branches that don't facilitate a large user base.
ashi has joined #asahi-alt
<j`ey> why have 100 people test code that is known to break in lots of ways
<scardracs> janrinze: linux-asahi-edge is on normal branch, not in the -dev one
<j`ey> the whole point is to get the code working well enough and *then* get it tested
<scardracs> And then mainlained upstream
<j`ey> I think youre misunderstanding the amount of effort it is to get the "basic" DRM features working
<ashi> Just out of curiosity, which bugs am I supposed to run into - I am running drm asahi driver and opengl is accelerated. Tried to crash it but failed :P
<janrinze> old school is sort of having a main branch and pull requests. making sure that those pull requests are kept to reasonable sizes.
<j`ey> that's going to happen when it's upstreamed
<scardracs> Initial support for M1 Pro/max/ultra will not happens before linux-6.2 so why rushing?
<janrinze> when someone whats to try a pull request they can test those at will.
<scardracs> janrinze: you can already do that
<janrinze> scardracs: already running on ultra for many months now..
<scardracs> janrinze: in linux-aschi, not in mainline linux kernel
<scardracs> asahi*
<janrinze> scardracs: https://github.com/AsahiLinux/linux/pulls .. not much to see here..
<j`ey> janrinze: do you do pull requests when the code is half working, to get more testers, or when it's working well?
<j`ey> yeah because the PRs are done via irc
<janrinze> j`ey: right..
<j`ey> markan asks the Usual Suspects if they have new code, and then he pulls it in
<janrinze> j`ey: merging branches.. yes..
<ashi> j`ey: some people actuall do half-working PRs and mark it WIP:, even a github feature, and sometimes nice to track progress
<j`ey> ashi: sure, that's not actually making a PR though :P
<j`ey> that's just to show it off or whatever, not for actually pulling
<ashi> j`ey: Not only to show off - also to make it visible and maybe have people test and comment
<mps> ashi: even simpledrm is quite fine, no need for drm
<janrinze> j`ey: it's just a different way of working that i'm not used to.
<j`ey> ashi: well that's what I meant by show off
<j`ey> janrinze: to me it seems to be what you suggested
<j`ey> you just think that they stuff should be easier to do incrementally.. but lots of the DCP work is just not incremental
<ashi> I find asahi generally a bit too closed for a crowd-funded project, but that is only my personal opinion. :P
<j`ey> ashi: it's not closed at all..
<j`ey> in what aspect do you think it's closed?
<janrinze> it's probably the spaghetti issue.. I'm used to defining small functional changes and implementing those.
<j`ey> janrinze: yeah.. not always possible
<ashi> In asahi-gpu someone proposed to make branches private to not have noobs like me test code (If I did not misread that)
<mps> ashi: I can post you gpu kernel if you want to test it
<janrinze> j`ey: not possible usually means 'i don't know how to do that' ..
<j`ey> ashi: did you read the context?
<ashi> mps: I have it running, along with mesa
<ashi> it is great
<j`ey> janrinze: i mean, feel free to do it for DCP or gpu then..
<mps> ashi: ah, ok
<mps> also I run it
<j`ey> ashi: 'the issue is that you’re wasting everyone‘s time by running random branches and then reporting issues'
<mps> ashi: you use wayland or xorg?
<janrinze> j`ey: I began my kernel stuff in 1996 .. so yes.. old school..
<scardracs> mps: IIRC Xorg does not work so well
<j`ey> janrinze: sure i get it, youre old school.. but this is exactly how development happens for stuff that is WIP
<ashi> j`ey: Could very well be that I missunderstand it, but I did not read it as from a welcoming community.
<mps> scardracs: right
<ashi> mps: wayland
<mps> sway works fine but I don't like it, so I use xorg
<j`ey> ashi: it's welcoming, but it's better to test what people ask to be tested, not just trying random combinations of things and then reporting issues
<ashi> mps: GNOME here with wayland
<scardracs> I don’t really understand what you means with old-school/new-school. There is only one way to do things: they are ready when they are enough stable to be usable for everyone. If someone wants to test things and report issue/s feel free to do so but not to force anyone to mainline something when devs are unsure how much safe
<scardracs> How much is safe to do so
<mps> ashi: I would switch to sway but I need to learn totally new WM, and I'm lazy for that
<ashi> j`ey: well, I was trying to run the driver on M2 Air, and it crashed even though it was supposed to be working (code was pushed, lina had it running in her stream). It crashed right away on boot but I was afraid to ask because I am not supposed to. That feels... well...
<ashi> After yesterdays stream it did work - and mesa was then also no problem to build and run
<janrinze> tobhe_: Ubuntu can't run chromium.
<tobhe_> let me check that
<ashi> mps: I was a long time i3 and then sway user - but with sway I failed to put some of those puzzle pieces into place to (gpg agent, ssh agent). A pre-configured "sway experience" would have helped but then I switched to GNOME + pop_shell for tiling
<janrinze> tobhe_: probably the chromium settings are expecting a gpu
<tobhe_> i think there was a way to force that off
<mps> ashi: sometimes I use sway in parallel with xorg but not much. And I don't like these big DEs, Gnome/KDE and similar (long time awesome wm user)
<mps> ashi: btw, from which git commit id you built mesa
<ashi> mps: same here, I just wanted a clean desktop with tiling and was to lazy to choose everything by hand (notification daemon etc), so GNOME works with tiling - "apt install sway-desktop" would be nice ;)
<ashi> mps: from linas branch , let me check
<ashi> it had the UAPI bump
<ashi> to v3
<mps> ashi: thank you much
<ashi> configured with the asahi driver and swrast , no vulkan drivers and did ninja install - restarted gdm3 and it worked right away
<ashi> After testing other random branches of alyssa, main mesa, lina, ...
<ashi> good that compiling mesa is lighting fast
<mps> ashi: I alredy created APKBUILD for alpine
<ashi> mps: nice
<mps> ashi: will build it tomorrow and test (now it is time for bed here)
<tobhe_> janrinze: I'm getting the same error. I think there was a way to fix that but I'm usually using firefox. Someone in #asahi might know what to do
<janrinze> tobhe_: 4k or 16k page kernel?
<ashi> mps: good night, you also need linas branches of m1n1 and the kernel of course (but I assume you have that already)
<janrinze> tobhe_: firefox works.
<tobhe_> 16
<janrinze> tobhe_: but youtube seems not to work..
<mps> (on alpine everything works)
<tobhe_> mps: on OpenBSD too. no idea which build option causes this. must be something software rendering related
<mps> tobhe_: ahem, always the problem is to find proper building options and dependencies versions
ashi has quit [Quit: Leaving]
<janrinze> tobhe_: Ubuntu is useful to me now as a backup. might want to try to add it in the grub of asahi :-)
<tobhe_> good to know that it works on the studio :)
<scardracs> Where can I find the instructions to install kernel with gpu enabled? I’ve entered #asahi-gpu but asking on it does not seems the better thing to do ‘:)
<janrinze> tobhe_: after a reboot Ubuntu drops in grub rescue.. and no USB for keyboard .. duh.
<tobhe_> huh? that's new
<janrinze> error no such device.. and a UUID..
<janrinze> let's try another reboot..
<tobhe_> it sounds like your machine is really good in triggering bugs in the first boot script
<tobhe_> normally that should change the UUIDs to random ones and update grub and fstab
<janrinze> it seems more like PARTUUID vs UUID
<janrinze> tobhe_: syncing disks? perhaps havint 64GB memory might keep files longer in buffers?
<janrinze> tobhe_: i'll keep an eye out on the UUIDs.. will report if it happens again.
<tobhe_> so the second boot worked?
<janrinze> yes.
jamespmo_ has joined #asahi-alt
<tobhe_> interesting
jamespmorgan has quit [Ping timeout: 480 seconds]
<janrinze> tobhe_: the UUID it tries to load is 87c6b0ce-3bb6-4dc2-9298-3a799bbb5994
<janrinze> \o/ managed to use grub rescue to boot an old debian partition!