#archlinux-ports | Logs for 2025-12-16

Back
[01:31:36] -!- Daanct12 has joined #archlinux-ports
[01:59:33] <bschnei> Antiz or gromit: I created two MRs for Ports/docs. It didn't assign anyone to them so I don't know if either of you were notified. If so, sorry for the double notification.
[02:27:43] <gromit> bschnei: awesome work!
[02:27:52] <bschnei> :)
[02:45:52] <bschnei> anthraxx, dvzrv (and heftig): as users with different devices show up to help, we need to evolve the arm64 kernel configuration I keep in the branch from https://gitlab.archlinux.org I am trying to be mindful of earlier comments about transparency/auditability of kernel configuration. While I based my original config off of the x86_64 config originally (and have scr
[02:45:52] <bschnei> ipts to reproduce *that* work), we've had to enable a lot of aarch64 related features to support bare metal devices. Beause I'm rebasing my branch, I don't have a detailed history of what was changed and why. I'm also afraid I may be spamming you with notifications every time I push. I'd appreciate any guidance. Perhaps I should abandon the MR (or at least take the config out of it)?
[02:45:52] <phrik> Title: Making sure you're not a bot! (at gitlab.archlinux.org)
[04:18:29] -!- hcmb has quit [Ping timeout: 246 seconds]
[04:18:46] -!- hcmb has joined #archlinux-ports
[07:40:29] -!- marmis0 has joined #archlinux-ports
[07:41:15] -!- marmis has quit [Ping timeout: 240 seconds]
[07:41:15] marmis0 is now known as marmis
[07:46:05] -!- SpieringsAE has joined #archlinux-ports
[07:46:05] -!- SpieringsAE has quit [Changing host]
[07:46:05] -!- SpieringsAE has joined #archlinux-ports
[08:21:26] -!- solsTiCe0 has joined #archlinux-ports
[08:23:24] -!- solsTiCe has quit [Ping timeout: 244 seconds]
[08:23:24] solsTiCe0 is now known as solsTiCe
[09:07:37] <anthraxx|M> bschnei: having a separate list would be helpful, this is also kinda how Debian does it have a base config (the long one) and then architecture specific overlays
[09:20:00] <noahimesaka1873|> also asahi kernel would be nice
[09:20:17] <noahimesaka1873|> there's asahi alarm but if it's gonna get upstream there should be arch official one too
[09:20:27] <solskogen|M> if you have a pkgbuild for it, I can put it in forge
[09:20:52] <noahimesaka1873|> https://github.com
[09:20:53] <phrik> Title: GitHub - asahi-alarm/PKGBUILDs (at github.com)
[09:21:50] <jelle> and then you maintain 69 kernels :P
[09:23:32] <solskogen|M> I'm fine with a couple, especially if they are very popular (like Pi). I assume the goal for the asahi kernel is to be mainstreamed?
[09:23:49] <noahimesaka1873|> solskogen|M: yeah but that will take quite some time
[09:24:07] <solskogen|M> I'm not gonna maintain them, in any way. But I'm fine with packaging them.
[09:26:33] <jelle> asahi is actively mainlined, I wonder what is still needed for a special build?
[09:27:14] <jelle> solskogen|M: I would not take asahi kernels from alarm or maybe it was manjaro which got into trouble with upstream :p
[09:28:09] <josd|M> I would say the asahi-alarm kernel is as far as we know correct :-D
[09:29:00] <solskogen|M> but they have their own repo, right? I'm not sure if they want to keep that or not. are the people behind it all here?
[09:30:04] <josd|M> I'm the maintainer of asahi-alarm (together with mkurz ). We use the asahilinux repo to build the kernel, and we often compare the config with fedora asahi
[09:30:47] <solskogen|M> do you need - or want - that we built it as well or are you fine with the way that it is?
[09:31:51] <solskogen|M> I don't have a system in place for checking if there's been a update into other repos than arch x86_64. so those kids of package update requires a lot of manual intervention from my part (at least for now)
[09:32:00] <josd|M> we don't need you to build the kernel, we have that. We basically only package the asahi specific bits, the rest comes from alarm (or soon this repo 😁)
[09:32:19] <solskogen|M> ok, perfect!
[09:33:16] <solskogen|M> have you tried using our packages instead of ALARM?
[09:33:22] <solskogen|M> (as a test, I mean)
[09:48:19] <strit|M> Isn't the page size of asahi kernel different than normal kernels?
[10:01:12] <artafinde|M> I want to use arch ports when stable for pikvm
[10:10:58] <Daanct12> do we have an archiso for generic arm ports?
[10:11:05] <Daanct12> i want to test my edk2 port
[10:11:22] <Daanct12> it currently boots windows and passed fwts tests
[10:14:29] <f_> xD
[10:14:53] <solskogen|M> <strit|M> "Isn't the page size of asahi..." <- 16k perhaps? That what the Pi kernels have as well. we used to have that for our linux package, but it caused trouble with nvidia cards.
[10:16:04] <jelle> I thought it was only apple which used 16k
[10:16:12] <strit|M> yeah, normal x86_64 kernel is 4k, i believe and I remember Asahi saying they use 16k which was a problem for upstreaming.
[10:16:22] <Daanct12> hi f_
[10:16:24] <Daanct12> ur here too
[10:16:36] <jelle> ah right rpi too
[10:16:56] <jelle> strit|M: its tricky for running x86_64 code
[10:17:02] <jelle> https://docs.fedoraproject.org :)
[10:17:03] <phrik> Title: Running x86/x86-64 applications on Fedora Asahi Remix :: Fedora Docs (at docs.fedoraproject.org)
[10:17:20] <Daanct12> didn't asahi had to like, emulate 4k just to get box64 or fex to even run?
[10:17:39] <noahimesaka1873|> strit|M: 16k is not that much hassle, their big problem is power management which apple differs a lot from others
[10:17:41] <jelle> I don't think they emulate but use a microvm afaik
[10:17:58] <jelle> noahimesaka1873|: everything on apple is different imo
[10:18:10] <noahimesaka1873|> yep muvm packaged for 4k pagesize for amd64 emulation
[10:18:21] <Daanct12> > think different
[10:18:31] <Daanct12> indeed
[10:18:36] <noahimesaka1873|> even intel macs are different
[10:18:53] <noahimesaka1873|> tho some can be shared with asahi
[10:22:00] <f_> Daanct12: ya
[10:22:31] <Daanct12> honestly if i were designing my own computer i should make it only support 64k pagesize
[10:22:37] <Daanct12> because no one supports it
[10:22:45] <Daanct12> geekbench fails to launch on 64k btw
[10:23:21] <noahimesaka1873|> celeste's modloader now theoretically should work on 64k
[10:23:46] <noahimesaka1873|> it had nasty selinux check that had hardcoded 4k mem region check which was problematic on asahi systems
[10:23:58] <noahimesaka1873|> it was fun to debug what was the problem
[10:25:13] <Daanct12> mhm
[10:25:29] <Daanct12> so selinux needs a fix i guess?
[10:25:41] <noahimesaka1873|> no
[10:26:02] <noahimesaka1873|> how the modloader check if selinux was present was the problem
[10:26:29] <noahimesaka1873|> it tried to add x flag to memory region, but the region size was fixed to 4k
[10:26:40] <noahimesaka1873|> which obviously fails on 16/64k systems
[10:26:59] <noahimesaka1873|> the fix was to dynamically change region size based on the system's pagesize
[10:27:10] <Daanct12> that's.. bad practice
[10:27:29] <Daanct12> but i guess nobody was aware of anything other than 4k back then
[10:28:27] <noahimesaka1873|> and it never officially supported architectures other than amd64
[10:29:16] <noahimesaka1873|> but because it is pure dotnet just using system runtime makes it run
[10:29:44] <noahimesaka1873|> (not really pure since there's sdl and such but whatever)
[10:36:41] <solskogen|M> I have to admit that I don't quite understand the whole page size thing.
[10:37:15] <solskogen|M> I mean, what benefits or impact a bigger or smaller page size has.
[10:37:36] <strit|M> Same here.
[10:38:09] <solskogen|M> or even the whole notion of why it's possible to change it in the first place. But hey, you can't know everything.
[10:38:44] <strit|M> I just know there are incompatabilities between systems/code that uses different sizes.
[10:39:24] <solskogen|M> oh yeah, and that it causes trouble with swap
[10:40:32] <noahimesaka1873|> solskogen|M: apple's dma can only work with 16k chunks
[10:40:55] <noahimesaka1873|> the whole memory subsystem of apple silicon is meant for 16k page size
[10:41:20] <noahimesaka1873|> (almost) everything works in 16k chunks
[10:41:50] <SpieringsAE> Daanct12: I bootstrapped my own image, not really an ISO so it is a bit slower, but much easier to do
[10:42:03] <SpieringsAE> was using EDK2 on a rk3588 borad
[10:46:49] <Daanct12> neat
[10:47:00] <Daanct12> i'm doing it on a rk3566 board
[13:30:30] -!- Daanct12 has quit [Quit: WeeChat 4.8.1]
[15:55:44] -!- SpieringsAE has quit [Quit: SpieringsAE]
[16:04:27] <noahimesaka1873|> <noahimesaka1873|> "(almost) everything works in 16k..." <- this also means that macOS is also 16k page sized
[16:04:47] <noahimesaka1873|> though afaik using rosetta will make a portion of memory 4k page sized
[16:05:08] <noahimesaka1873|> could be wrong, I'm not an expert
[17:04:00] -!- lynxy has quit [Remote host closed the connection]
[17:24:55] -!- lynxy has joined #archlinux-ports
[18:07:58] -!- lynxy has quit [Remote host closed the connection]
[18:13:19] -!- lynxy has joined #archlinux-ports
[18:13:54] -!- lynxy has quit [Remote host closed the connection]
[18:19:40] -!- lynxy has joined #archlinux-ports
[20:30:50] -!- SpieringsAE has joined #archlinux-ports
[20:40:47] -!- SpieringsAE has quit [Quit: SpieringsAE]
[21:36:27] -!- drathir_tor has quit [Remote host closed the connection]
[21:36:54] -!- drathir_tor has joined #archlinux-ports