#archlinux-ports | Logs for 2026-04-15

Back
[00:00:01] -!- bertptrs has quit []
[00:00:27] <Charon77> I only know about drzee like yesterday when I was asking on #archlinuxarm why chromium is broken
[00:00:37] -!- bertptrs has joined #archlinux-ports
[00:01:59] <stickynotememo> there's also the AArch64 group in the official gitlab instance but I don't see anything useful there
[00:20:20] <stickynotememo> how do i access drzee? if i go to the home page it just redirects me to an error message
[00:24:53] <Charon77> https://ports.archlinux.page
[00:24:54] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[00:25:23] <stickynotememo> cool thanks
[00:30:47] -!- fermino has quit [Quit: ZNC - https://znc.in]
[00:32:55] -!- fermino has joined #archlinux-ports
[00:38:29] -!- fermino has quit [Quit: ZNC - https://znc.in]
[00:41:41] -!- fermino has joined #archlinux-ports
[00:42:00] -!- fermino has quit [Client Quit]
[00:42:22] -!- fermino has joined #archlinux-ports
[00:52:21] <fermino> Hey there guys, fellow arch user here wanting to help with the aarch64 port :)
[00:53:10] <fermino> Is this channel bridge to matrix or would it make sense to be there too?
[00:53:55] <Charon77> looking here it doesn't seem this channel is bridged https://github.com
[00:53:56] <phrik> Title: infrastructure/docs/matrix.md at master · archlinux/infrastructure · GitHub (at github.com)
[00:56:33] <fermino> Yeap, saw the same but thought I'd ask :)
[00:58:07] <fermino> Anyways, is there any specific topic where help is needed? (my day job is as a sysadmin/cloud infra guy, but I sort of get my way around C and embedded)
[00:59:58] <Charon77> What I hear they need the most is testing, so people with arm hardwares / emu, running automated builds / tests maybe
[01:06:56] <fermino> Awesome, I have a rpi4 (that I understand is out of the currently aim) and an ick for messing around with qemu/binfmt, so I'll stick around and see what can be done!
[01:08:44] <fermino> s/ick/itch lol
[01:08:46] <Charon77> I'm using Lenovo Chromebook. Mediatek soc. 2GB of RAM
[01:10:17] <fermino> Ohh, I might be able to get a used chromebook on the cheap around here to mess with
[01:10:29] <Charon77> Tried compiling 'servo' browser overnight and just get OOM-killed :)
[01:10:51] <fermino> zram maybe?
[01:10:58] <Charon77> yes I'm on zram
[01:11:12] <Charon77> like around 4GB effectively
[01:13:00] <Charon77> ended up forking the repo and have AI adjust the github workflow for aarch64 (which the project supports but not for linux). End up dissapointed because the program exited immediately because it wants OpenGL 3.2, and I only have 3.1. I was able to force it to use EGL which does work but :/
[01:13:32] <Charon77> Things I wish I knew more before getting a chromebook, but eh, it works okay most of the time
[01:15:01] <fermino> Cross-compiling? (in my list of things to try i have a distcc setup and LXC+qemu, those are the things that come to mind)
[01:15:08] <Charon77> fermino anyway, I emailed heusel, sending my matrix account, I think it's invite only, and they're the one mentioning matrix.
[01:15:56] <fermino> Ohh, 'kay
[01:16:13] <fermino> I'll have to make an account
[01:16:24] <fermino> Is there any list of missing/failing packages?
[01:51:01] <Charon77> All I can find is https://gitlab.archlinux.org
[01:51:02] <phrik> Title: Work items · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[01:51:30] <Charon77> btw I raised a MR on the docs, care to take a look? https://gitlab.archlinux.org
[01:51:31] <phrik> Title: aarch64 project management background (!1) · Merge requests · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[01:59:57] <fermino> Ohhh, you're the one I tagged in the email, response, thought it was someone else hence my reply xD
[02:00:14] <fermino> @Charon77, I'll take a look at it tomorrow morning!
[02:00:16] <fermino> Thx for sharing
[02:27:15] -!- daurnimator has joined #archlinux-ports
[03:45:13] -!- hcmb_ has joined #archlinux-ports
[03:45:14] -!- hcmb has quit [Killed (osmium.libera.chat (Nickname regained by services))]
[03:45:14] hcmb_ is now known as hcmb
[05:48:26] <stickynotememo> Do I need an invite to join the ports matrix room?
[05:48:27] <stickynotememo> MatrixError: [403] You do not belong to any of the required rooms/spaces to join this room. (https://mozilla.modular.im/_matrix/client/v3/join/%23ports%3Aarchlinux.org)
[05:55:22] <Charon77> @stickynotememo I'm starting to get an overall feel of the project. I think the discussion is supposed to happen at this very thread according to this: https://gitlab.archlinux.org
[05:55:23] <phrik> Title: Write announcement / call for contributions (#4) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[05:57:30] <stickynotememo> is it just me or is it all somewhat confusing
[05:58:50] <stickynotememo> wait how is aarch64 any differnt from alarm?
[06:18:21] <solskogen|M> Not by very much. You can migrate directly from ALARM to our port effort.
[06:18:41] <stickynotememo> but they are distinct?
[06:19:37] <solskogen|M> yes they are
[06:20:29] <solskogen|M> We try to follow x86_64 as much as possible
[06:21:01] <solskogen|M> if anyone is up for a big challenge: make electron39 build on aarch64
[06:21:12] <stickynotememo> i mean im bored
[06:21:25] <stickynotememo> where do i find the effort so far
[06:21:42] <solskogen|M> then you'll be both bored ang angry. It takes almost 30min just to checkout the sources from git.
[06:21:56] <solskogen|M> What do you need to know?
[06:22:08] <stickynotememo> somewhere to start i guess
[06:22:16] <stickynotememo> i thought there would be a repository or something?
[06:22:57] <stickynotememo> or do i just get the electron search and start compiling on my raspberry pi
[06:22:58] <solskogen|M> https://ports.archlinux.page
[06:23:00] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[06:23:00] <stickynotememo> *source
[06:23:23] <solskogen|M> No, we're using PKGBUILDs directly from x86_64
[06:24:01] <stickynotememo> i see
[06:24:16] <solskogen|M> that means you clone https://gitlab.archlinux.org - and make it compile. And create a MR for the changes you did. make sure you don't break x86_64 in the process.
[06:24:17] <phrik> Title: Arch Linux / Packaging / Packages / electron39 · GitLab (at gitlab.archlinux.org)
[06:25:28] <stickynotememo> so would it be pushed back to the x86 repository?
[06:25:38] <solskogen|M> eventually, yes
[06:26:09] <stickynotememo> i see
[06:26:13] <stickynotememo> https://imgur.com
[06:26:15] <stickynotememo> what's this?
[06:26:44] <solskogen|M> something that perhaps one time worked, but now don't.
[06:26:54] <stickynotememo> hmm
[06:27:32] <solskogen|M> We DO however, have electron39-bin in our forge repo.
[06:27:39] <solskogen|M> that's just taken from aur
[06:27:53] <stickynotememo> sorry im still confused
[06:28:03] <stickynotememo> does aarch64 use a different package repo to x86 or not
[06:28:31] <solskogen|M> It uses a different repo for binary packages, yes. but the PKGBUILDs are from upstream x86_64.
[06:28:37] <stickynotememo> i see
[06:28:42] <solskogen|M> https://ports.archlinux.page
[06:28:43] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[06:28:46] <stickynotememo> aren't all packages binary packages tho?
[06:28:49] <stickynotememo> yeah i need to do some reading
[06:29:00] <solskogen|M> Yes and no.
[06:29:29] <solskogen|M> if the package ends with -bin it normally means that someone else than us built it
[06:30:16] <stickynotememo> right
[06:38:05] -!- moxie has joined #archlinux-ports
[06:38:57] <moxie> #archlinuxarm is non official thing?
[06:39:23] <solskogen|M> I don't know what you mean with non-official :)
[06:39:47] <moxie> there was some email thread about archlinxu/arm
[06:39:59] <Antiz> moxie: It's not
[06:40:01] <solskogen|M> this is the right place
[06:40:01] <Antiz> Never was
[06:40:04] <moxie> and coordination, a bit cnfusing where the talk actually is
[06:40:11] <moxie> ok, nice
[06:40:56] <moxie> I'll be intrested about that since getting jolla phone and plan to run archlinux arm / catacomb on it evantually after checking sailfishOS
[06:41:54] <Charon77> @solskogen hi, just to clarify: this is the right place, there's no matrix. I think people over the mailing list are confused.\
[06:42:17] <solskogen|M> I understand the confusion. As of now there are two aarch64 porting projects. ALARM (which is the official non-official) and the project me, bschnei and @drzee are behind which is the hopefully-will-be-official version. The prototype I talked about in the thread.
[06:42:18] <moxie> Yes, it's quite confusing
[06:42:34] <solskogen|M> Charon77: I'm on matrix :-)
[06:43:20] <Charon77> Care to share your handle? I'm worried of missing messages on IRC, and what about other people interested in the project?
[06:43:42] <Antiz> Charon77: There is a matrix bridge but I think you need an invitation. However, as far as I know, placeholder on the matrix bridge are limited, so I'm not sure we want to massively send inventation.?
[06:43:46] <Antiz> Invitations*
[06:43:53] <Antiz> heftig: Can you confirm / infirm?
[06:46:23] <Charon77> okay, I think it's an A/B problem, it's not like I want Matrix. What I want: Clear and persistent information about the project, what's going on who are the team, what's needing help
[06:46:32] <solskogen|M> IRC is fine
[06:46:59] <Antiz> Charon77: Sure, that's reasonable :) We have documentation already mentioning some of that. Patches are welcome.
[06:47:07] <Antiz> https://gitlab.archlinux.org
[06:47:09] <phrik> Title: Arch Linux / Ports / docs · GitLab (at gitlab.archlinux.org)
[06:47:22] <Antiz> https://ports.archlinux.page
[06:47:24] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[06:49:23] <Charon77> Funny story: I eventually found out about this page and was confused: https://gitlab.archlinux.org
[06:49:23] <Charon77>
[06:49:23] <Charon77> Turns out I was supposed to go to "Work items". You all must be familiar with GitLab, but it wasn't obvious to me where Work items is, and all I see was placeholder readme page. I've raised an MR to it
[06:49:23] <phrik> Title: Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[06:49:56] <Antiz> Charon77: Yup, I'm currently leaving a comment on it. Although, we'll close this one to be honest.
[06:50:00] <Antiz> Your MR that is.
[06:51:03] -!- julemand101 has joined #archlinux-ports
[06:51:15] <Antiz> TL;DR: The information you're seeking for ("Clear and persistent information about the project, what's going on who are the team, what's needing help") are valuable and should probably be added somewhere, but this README doesn't feel the right place for it.
[06:51:28] <Antiz> Expanding https://ports.archlinux.page would be the correct way
[06:51:29] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[06:52:53] <Antiz> Also, mentioning ALARM's state and relation is kinda meaningless. I don't think we wanna go that route.
[06:52:54] <Charon77> Actually, can I just change the README content? What it needs is links to arch linux ports, project management, etc
[06:53:11] <Charon77> (or I can create another MR)
[06:53:13] <Antiz> Charon77: Yes, that'd be much better IMO. This is what my comment is about.
[06:54:37] <Charon77> Makes sense, I can go change that. I feel like I'm learning a lot about the project, but I need to talk to you all, I'd like this written somewhere
[06:55:20] <Charon77> So, this project == drzee mirror? Using exactly the same PKGBUILD as x86_64?
[06:55:36] <Charon77> (correction: same PKGBUILD as mainline arch)
[06:55:48] <Charon77> with no patches whatsoever?
[06:55:58] <Antiz> ~Yes-ish
[06:58:04] <Antiz> "So, this project == drzee mirror?" <-- This project is about the aarch64 port effort started by bschnei, solskogen|M and drzee, for which packages happens to be hosted and distributed via drzee's mirror. Though qualifying it as the "drzee mirror" project may kinda be misleading IMO?
[07:00:26] <Antiz> Contributions are opened to the public, somewhat could create a separate mirror mirroring drzee's one, etc... I'm nitpicking here though, but it's just that the idea is to get people to contribute to a common effort with the ultimate goal of having it officially supported at some point. I don't think we should necessarilly brand this under a
[07:00:26] <Antiz> separate project / name. The idea is to work with upstream / mainline Arch as much as possible. Hopefully that makes sense.
[07:01:15] <Antiz> "Using exactly the same PKGBUILD as x86_64? with no patches whatsoever?" <-- If patches are needed, then the idea is to upstream then to mainline Arch (if that can reasonably be done).
[07:03:33] <phantomas> [kinda misleading] I agree. IMO if a distinction is to be made, it would be between the fork of arch that maintain its own PKGBUILDs (ALARM) and a port (this project) that aims to make mainline arch available on other plateform.
[07:03:52] <Antiz> Charon77: For what it's worth, Arch now allows non-x86_64 contributions in the scope defined in this scope: https://lists.archlinux.org
[07:03:54] <phrik> Title: First step for non-x86_64 contributions - Arch-dev-public - lists.archlinux.org (at lists.archlinux.org)
[07:05:10] <Antiz> Charon77: Which is what this port effort has been actively doing :) The drzee mirror itself is obviously handy for testing and debugging purposes and can of course technically be used to run an ARM system.
[07:07:08] <Antiz> But, as raised by phantomas, the fundamental point here is *not* to be yet another fork distributing packages built for ARM, it's to contribute to the general effort of making Arch PKGBUILDs be compatible with ARM for an eventual official support in the support.
[07:08:38] <Antiz> Technically speaking, we expect the drzee mirror to be temporary. It's really useful to provide prebuilt packages that solskogen|M is compiling all day (thanks again for the good work on that front by the way), for the lack of another place to do so at the moment.
[07:10:03] <Antiz> But it's not supposed to be around forever. Hence why I think it's relevant to present this as "join the common effort of bringing ARM support to Arch. Note that the drzee mirror provide prebuilt packages if needed", rather than "come contribute to the 'drzee mirror' project".
[07:10:22] <Antiz> Charon77: Let me know if that makes sense :)
[07:12:47] <Antiz> s/official support in the support/official support in the *future*
[07:19:05] <antiz|M> amstan: I guess the AUR can be a good place for that :)
[07:20:45] <antiz|M> amstan: There's a bunch of potential solutions for that
[07:22:57] <antiz|M> We only have limited power and human resources. A generic ARM port feels like a fair milestone. Aside from the RPI, I'm not sure other distributions officially maintain a lot of vendor specific kernel packages officially. Each boards requiring its own specific kernel is not feasible for us to maintain. Though there are a fair amount of potential solution for the community to provide those.
[07:25:07] <Charon77> Oh my gosh I think now it clicks to me. So for example with chromium, It's just some line changes on the official PKGBUILD https://gitlab.archlinux.org
[07:25:07] <Charon77>
[07:25:07] <Charon77> So, the arm specific PKGBUILD changes are officially put into archlinux gitlab, but the image builds are helpfully prepared by community
[07:25:07] <phrik> Title: PKGBUILD · main · Arch Linux / Packaging / Packages / chromium · GitLab (at gitlab.archlinux.org)
[07:29:03] <Antiz> Charon77: Exactly!
[07:32:38] <Antiz> Charon77: The general idea is to submit ports specific patches to official Arch PKGBUILDs (if it can be done in a reasonable way), in order to work toward an eventual official support for said ports at some point. When it comes to the AArch64 port specifically, people from the community (namely bschnei, solskogen|M and drzee at the moment) are
[07:32:38] <Antiz> indeed helpfully providing images and packages builds :)
[07:33:13] <Charon77> Next questions: What's the ask for community? Is there a list of packages that need to be tested?
[07:33:13] <Charon77> > There are 3 repos: core, extra, and forge.
[07:33:13] <Charon77>
[07:33:13] <Charon77> I don't see core-testing, extra-testing for example.
[07:33:14] <Charon77> Let's say I find issues with `chromium`, do I just send MR to archlinux gitlab PKGBUILD? What if a person just want to document the bug? Do we talk about it here? https://gitlab.archlinux.org
[07:33:14] <phrik> Title: Work items · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[07:34:09] <Antiz> Charon77: I guess that clarifies the general aim for you and what I was saying about "the drzee mirror" not necessarilly being "the project to contribute to" and not being an ultimate goal in that context ;)
[07:34:45] <Antiz> "Let's say I find issues with `chromium`, do I just send MR to archlinux gitlab PKGBUILD?" <-- Yep
[07:35:16] <Antiz> "What if a person just want to document the bug?" <-- I think the bug can be opened in the chromium repo then.
[07:35:49] <Charon77> I mean like a build issue that's clearly arm specific
[07:35:58] <Antiz> Yes, that's fine.
[07:36:25] <Antiz> The aarch64/project-management repo is more to discuss issues and milestones to lead to an official ARM support as a whole.
[07:36:50] <Antiz> As officially said in https://lists.archlinux.org we are now acception non-x86_64 contributions for packages.
[07:36:51] <phrik> Title: First step for non-x86_64 contributions - Arch-dev-public - lists.archlinux.org (at lists.archlinux.org)
[07:37:15] <Antiz> That includes bug reports / MR to fix build with a port.
[07:38:11] <Charon77> The reason I ask is because of this text:
[07:38:11] <Charon77>
[07:38:11] <Charon77> > non-x86_64 issues#
[07:38:12] <Charon77> > No issues or bug reports for non-x86_64.
[07:38:12] <Charon77> > If something’s broken with the PKGBUILD, you’ll need to sort it out and send a merge-request. Don’t file bugs in the tracker for other architectures.
[07:38:42] <Antiz> Charon77: Ah right, scratch that then
[07:39:47] <Antiz> Charon77: I guess the point is that you can't reasonably expect official staff to own architecture specific hardware on which they can reproduce and work on a bug report. So a bug report on its own doesn't provide much.
[07:40:07] <Antiz> So the expectation is that you find the fix yourself and submit through a MR instead.
[07:40:42] <Charon77> How about this: Someone finds an issue.
[07:40:42] <Charon77> Can they fix it?
[07:40:42] <Charon77> Yes -> submit MR
[07:40:42] <Charon77> No -> just bring it to this channel
[07:40:46] <Antiz> I guess a bug report coupled with a MR addressing it would technically be fine. But a bug report expecting official staff to work on it is not reasonable / helpful.
[07:41:02] <Antiz> Charon77: Yeah, that sounds like a sane path :)
[07:43:31] <Charon77> Could you help me understand this line?
[07:43:31] <Charon77>
[07:43:31] <Charon77> > Arch Linux Ports is a namespace for unofficial architectures ports until they are integrated in the main Arch Linux repositories.
[07:43:31] <Charon77>
[07:43:31] <Charon77> Yet at the same time, Ports > AArch64 is mostly empty... because aarch64 specific changes are already on official PKGBUILD
[07:43:58] <Charon77> Or maybe I'm conflating the term repository: gitlab repo vs arch repo (the binary distribution)
[07:44:23] <Antiz> Charon77: This is about offering a dedicated namespace to port efforts over GitLab to discuss global issues and milestones publicly.
[07:45:17] <Charon77> Got it. I'm almost
[07:45:31] <Charon77> Got it, I almost have everything I need to help write the docs
[07:46:28] <Charon77> What help does this project need the most? Testing? CI? I saw someone with cloud infra dayjob from archlinux arm wanting to help. Do you need help over there too?
[07:48:12] <Charon77> I saw that there was supposed to be announcement for this: https://gitlab.archlinux.org "Write announcement / call for contributions" from 4 months ago
[07:48:13] <phrik> Title: Work items · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[07:48:42] <Antiz> I'm guessing that, ultimately, we need people to detect build failures for ports and report them somewhere (e.g. here) or, better yet, submit fixes to the official PKGBUILDs (which is the current official scope for non-x86_64 contributions).
[07:51:39] <solskogen|M> Charon77: That's the *goal* - but there are packages that require tweaking. For most of them, I've created MRs for. But there are some that isn't published, because I'm not happy with them. That said 99% of the PKGBUILDs work right out of the gate.
[07:52:53] <moxie> solskogen|M: do you prefer irc or matrix?
[07:53:04] <solskogen|M> <antiz|M> "I guess the AUR can be a good..." <- Oh yes, but unless there's a very high demand I don't think we would make packages of them.
[07:54:17] <solskogen|M> Charon77: They're there, but they are not the same as x86_64. our testing-repos are like staging. For the time being.
[07:55:15] <Antiz> Charon77: I assume stuff like CI / infra would be helpful but this goes beyond the official scope / main point for now (which is to submit patches to allow build on non-x86_64 architecture). I think the doc hosted on the gitlab page should stay in line with the scope defined in the port RFC and the announcement sent in Arch-Dev-Public mailing list.
[07:56:10] <solskogen|M> By test I mean, just start using it. If something is broken, try to fix it and create MR. And keep us posted here :-)
[07:56:43] <solskogen|M> Everything I use my ARM devices for, work as they should. But I haven't tested every package I've built. so there might be dragons.
[07:57:35] <moxie> What sort of ARM devices you got, some rpi4b?
[07:58:20] <moxie> I could install arch arm there, and try it out, getting the actual jolla phone in july-aug so it'll take a while till testing on that can happen
[07:58:27] <Charon77> I have lenovo chromebook duet. whopping 2GB of RAM
[07:58:32] <solskogen|M> I've got a Odroid M2, Orion O6, CM5, Pi5, and Pi500+. Rpi4 is not supported. ARMv8.2-a is needed.
[07:58:42] <moxie> Ah
[08:00:01] <solskogen|M> The build machine is in AWS.
[08:00:20] <solskogen|M> kindly provided by @drzee
[08:00:28] <Charon77> Thank you so much, I think I got the context that I need. I'll try raising MR on the port docs, and hopefully can help clear up confusions people have both in alarm community and on the mailing list
[08:00:50] <solskogen|M> That would be great!
[08:01:26] <solskogen|M> I've got a preliminary script to create images as well as tarballs. But those images isn't published anywhere.
[08:01:32] <solskogen|M> (tarballs are)
[08:02:16] <Antiz> Charon77: Thanks you for the help :) Just a quick note if you allow me: Quick in mind that said documentation is targeted at Arch Linux itself specifically.
[08:02:43] <Antiz> Charon77: You don't have to (and shouldn't) take ALARM into consideration when writing the docs.
[08:03:03] <Antiz> s/Quick in mind/Keep in mind
[08:03:14] <Antiz> (Short night 😅)
[08:04:29] <Charon77> I understand that this is a separate effort and you don't want to undermine ALARM project. But questions will be asked. Perhaps I'll just answer if somebody asks
[08:04:39] <Antiz> Charon77: Not for us to care
[08:04:52] <Antiz> ALARM is a completely separate project / distro
[08:05:48] <Antiz> Charon77: I mean, you're free to share the doc in the ALARM community or personally answer questions asked there, of course.
[08:06:16] <Antiz> But please don't mention ALARM or indirectly try to establish a connexion with it from the official documentation.
[08:07:21] <Charon77> I'll just use this official phrasing of "unofficial architectures ports until they are integrated in the main Arch Linux repositories."
[08:07:41] <Charon77> But yes, I'll keep that in mind
[08:07:44] <solskogen|M> We tried to reason with the people behind ALARM before we started this, but they didn't want any help.
[08:08:11] <Antiz> Charon77: As you wish. I guess the point I'm trying to make is that this effort was **not** started with the intention to be a successor for ALARM.
[08:09:29] <Antiz> This is about the bigger picture of working toward our general goal of (finally) supporting non-x86_64 architectures (not only AArch64).
[08:09:33] <moxie> I wish they would've chosen different name, as archlinux arm / alarm is VERY confusing, just like cachyOS even tho it's arch under the hood
[08:10:29] <solskogen|M> for many years I thought it was a official Arch Linux port.
[08:10:43] <Charon77> moxie: from the website: "The Arch Linux™ name and logo are used under permission of the Arch Linux Project Lead."
[08:11:56] <Antiz> Charon77: In other words, ALARM itself as a project does not have any direct connection with this. The current state of ALARM (which is indeed concerning) is not the reason why we started allowing contributions targeting non-x86_64 architecture.
[08:12:59] <Charon77> Understood. that's why there's no "migrate from alarm" wording, but rather: here's how you can update your package.conf
[08:14:39] <solskogen|M> Last time I tried I could migrate from ALARM by changing the mirror in pacman.conf and reinstall everything
[08:15:00] <Antiz> Charon77: Yep, the doc should be kept generic / Arch centric basically. No need to assume what people are running nor target specific downstream / derivative project here.
[08:16:44] <Antiz> Charon77: Anyway, thanks a lot for considering expanding the documentation! That's really appreciated :)
[08:22:15] <Charon77> No problem, thanks for answering my barrage of questions. I'd love to help! (mostly out of frustration)
[08:22:45] -!- Solskogen has joined #archlinux-ports
[08:23:12] <solskogen|M> all help is appreciated :-)
[08:23:27] <moxie> Hm, is aur and archlinux.org accounts different? since it seems #ports:archlinux.org on matrix needs invite/account?
[08:24:01] <solskogen|M> Antiz: is it okay to publish aarch64-only packages in AUR now?
[08:24:58] <Antiz> moxie: Yes, those are different accounts
[08:25:58] <Antiz> solskogen|M: Hummmm, I don't think we officially clarified that point yet. I guess I forgot to followup on this :(
[08:26:09] <Antiz> solskogen|M: Do you have any need for that right now?
[08:26:11] <moxie> in 2024 there was some email about arch linux testers needed, is this still the case? I've been using arch linux as main dailydriver for past 5 years at least so maybe it's time to contribute back some of my free time :D
[08:26:39] <Charon77> Oh yeah that too, so is the project mostly happening on IRC? Is this channel bridged to Matrix?
[08:26:41] <solskogen|M> Sure, go ahead moxie
[08:26:45] <moxie> recently changed to zfs so it's quite trivial to run -testing snapshot repos and just mainline
[08:26:51] <solskogen|M> It is.
[08:27:15] <Antiz> moxie: Testers are always needed :D See https://wiki.archlinux.org There's #archlinux-testing if you wanna discuss that further.
[08:27:17] <moxie> I'll send email to the testhing thingy
[08:27:29] <Antiz> moxie: I'm the one creating accounts :)
[08:28:46] <Antiz> Please send the mail though ^^ I'll create your account once received (let's move testing related discussion to #archlinux-testing though)
[08:31:01] <solskogen|M> Oh, I should've done that long time ago.
[08:35:36] <phantomas> solskogen|M: [migrate from ALARM] I can confirm it work :) The main thing that's needed is to migrate is a running setup with pacman installed. ALARM has the advantage of a pre-made "image", but that's not really required to use that
[08:36:14] <phantomas> On that note, are there any prebuilt images available?
[08:36:43] <Charon77> You mean for flashing to device, like the live distribution?
[08:37:36] <phantomas> Kinda. Not all ARM devices support booting from USB, so a live distribution may not work
[08:37:37] <solskogen|M> I don't think ALARM has images, only tarballs. But no, we don't have images either. Not yet.
[08:37:54] <solskogen|M> I can create on the fly if needed, but we don't really have a place to put them.
[08:38:02] <phantomas> solskogen|M: I meant the tarball :)
[08:38:07] <solskogen|M> I might be able to trick @drzee to do that
[08:38:20] <solskogen|M> https://arch-linux-repo.drzee.net
[08:38:21] <phrik> Title: Index of arch/tarballs/os/aarch64/ (at arch-linux-repo.drzee.net)
[08:39:08] <phantomas> oh so there are some pre-made tarballs
[08:39:48] <solskogen|M> tarballs, yes. images, no.
[08:40:40] <Charon77> Yeah it's listed here https://ports.archlinux.page
[08:40:41] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[08:42:45] <phantomas> got it :) Tbh I converted a franken-alarm to the arch port the first time around, and used mkosi to built a custom image the second time, so I did not use any pre-made images in either setup I own
[08:43:31] <phantomas> images or tarball*
[08:44:23] <solskogen|M> the idea with images was to be able to write them to a usb stick to boot from, and install from that. But there's nothing wrong with using the images as is (you just have to resize)
[08:44:56] <solskogen|M> problem with images is that your're somewhat bound to the filesystem I've chosen.
[08:47:33] <phantomas> Yeah, agreed. And full disk images are a bad idea since you might need a specific bootloader version/address
[08:48:32] <phantomas> An alternative might be a recipe for mkosi/similar tools that let you build your own images, but I feel that's beyond the scope of a port
[08:48:53] <solskogen|M> That's the goal, yes
[08:49:08] <solskogen|M> But I can't do everything :-)
[08:50:56] -!- TheDcoder has joined #archlinux-ports
[08:52:01] <TheDcoder> Nice channel! How far has the effort come along?
[08:53:11] <TheDcoder> also I see a lot of "|M" nicks, what are they? 🤨
[08:54:03] <moxie> I was wondering about that too, is it for matrix perhaps or mobile, or neither :D
[08:54:20] <moxie> I'm sure someone will enlighten us soon
[08:54:30] <tippfehlr|M> that are matrix accounts bridged to IRC :)
[09:01:55] <solskogen|M> TheDcoder: we have a working prototype. https://ports.archlinux.page
[09:01:57] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[09:02:43] <solskogen|M> I think I've build and kept the packages up to date for about a year now
[09:03:35] <solskogen|M> I think we couldn't have found a worse time to begin. gcc-15 and new cmake broke SOOO many packages.
[09:07:21] <TheDcoder> ah, that sucks, but great job for building the packages so far! I thought we were still in the planning stage. Are we working together with the ALARM project on this?
[09:07:35] <solskogen|M> Not at all.
[09:08:21] <TheDcoder> tippfehlr|M: good to know, I remember matrix using the [m] suffix when they first started, I've stopped using it now.
[09:08:46] <TheDcoder> solskogen|M: why not? seems like it would be a waste to not share the effort.
[09:09:06] <solskogen|M> I agree. But they didn't want my help.
[09:09:35] <TheDcoder> Hmm... I wonder why.
[09:09:51] <TheDcoder> Are we using any of their PKGBUILDs?
[09:10:40] <solskogen|M> Only for linux-tools IIRC. So if you want, you start merging and create a MR.
[09:11:27] <Charon77> well, I heard when somebody offers to help fix the forum registration, they outright refused (or was it went silent)
[09:11:39] <solskogen|M> ~99% of the PKGBUILDs from x86_64 just work
[09:11:55] <TheDcoder> "Packages are built for devices supporting the ARMv8.2 (and later) instruction sets only. That means they will not work on Raspberry Pi 4 or devices with the ARM Cortex A53 or earlier CPUs." Dang gummit, I think this will alienate a lot of the userbase, even I am running the RPi 4.
[09:11:55] <solskogen|M> But we're not here to bash on ALARM.
[09:12:25] <Charon77> I'm surprised that the PKGBUILDs just work
[09:12:27] <TheDcoder> the 99% figure is great!
[09:12:38] <solskogen|M> Charon77: why?
[09:12:49] <TheDcoder> Charon77: all hail portable code :)
[09:13:12] <TheDcoder> solskogen|M: so what are the next steps towards official adoption?
[09:13:43] <solskogen|M> We're going to have a chat with the devs very soon, to talk about it.
[09:15:08] <TheDcoder> what's this talk about LSE which is preventing building for older ARMv8 platforms?
[09:16:06] <TheDcoder> I think it's a critical issue that needs to be worked on, otherwise I'm afraid it might be a DoA effort because most SBCs don't have the latest architecture.
[09:16:32] <solskogen|M> It was a issue, at least. It might have been fixed now.
[09:16:42] <moxie> What would be needed to work on rpi4b, ARMv7 or w/e the actual name is?
[09:16:45] <solskogen|M> But rebuilding everything is a huge effort.
[09:16:58] <solskogen|M> ARMv7 is out of the question. Only 64bit.
[09:17:12] <moxie> isn't rpi4b 64bit?
[09:17:29] <moxie> I'm shaky on arm details a bit even tho I've had one for long time :D
[09:17:35] <moxie> Just got intrested cause getting linux phone
[09:17:37] <solskogen|M> It is, but it's using ARMv8-a, not ARMv8.2-a.
[09:17:44] <moxie> I see
[09:18:28] <moxie> What's so different between the two?
[09:18:43] <TheDcoder> moxie: RPi 4 has an 64-bit SoC but it can run armv7 as well, but that doesn't mean it can't do ARMv8. Even the official Raspbian distro has switched to aarch64 (ARMv8)
[09:19:12] <solskogen|M> I might be persuaded to go back to using armv8-a.
[09:19:24] <moxie> Yeah I've ran alpine and rasbian on it or debian arm thingy, can't recall
[09:19:29] <TheDcoder> solskogen|M: oh, then that's good, wouldn't the rebuilding effort be solved once we get access to official Arch Linux hardware? I assume they have servers to build stuff.
[09:19:50] <solskogen|M> Not ARM, as far as I know.
[09:19:57] <moxie> for me and all other rpi4b owners, that would be great news :D
[09:19:59] <stickynotememo> could they get arm? as part of the project
[09:20:18] <TheDcoder> solskogen|M: what about cross-compilation?
[09:20:20] <moxie> if armv8-a was supported
[09:20:27] <solskogen|M> Rebuilding core would probably take a couple of hours. But all the packages in extra will take a LOT of time.
[09:20:41] <TheDcoder> and I imagine they'd be able to get a few ARM machines with the development funds as well
[09:20:49] <solskogen|M> cross-compilation is out of the question. That's another set of worms in the famous can.
[09:21:28] <TheDcoder> that's sad, Rust makes it look so easy.
[09:21:46] <solskogen|M> Look? Yes.
[09:21:48] <stickynotememo> TheDcoder: that makes me wonder what does the archlinux budget look like
[09:22:19] <solskogen|M> our effort is $0
[09:24:02] <TheDcoder> stickynotememo: I see that Arch is using SPI as the fiscal entity, not sure if they publish transparent budget reports
[09:24:10] <TheDcoder> https://www.spi-inc.org
[09:24:11] <phrik> Title: Arch Linux (at www.spi-inc.org)
[09:27:31] <Antiz> TheDcoder: Budget is a thing, but what we currently lacks to properly supports additional architecture is infra and automation / tooling.
[09:29:01] <Antiz> The monetary aspect is not the main blocker. We also need people with enough free time and will to put some work in it (which isn't always easy in a volunteer driven project)
[09:29:36] -!- alex19EP has joined #archlinux-ports
[09:29:37] <Antiz> But there is some milestones and work in progress on those side already :) It just takes time ^^
[09:30:06] <TheDcoder> yeah that makes sense
[09:30:51] <TheDcoder> how would someone new who is interesting in contributing start?
[09:31:08] <TheDcoder> I might lend a hand myself if the work isn't too cumbersome
[09:31:44] <Antiz> Currently, the scope of non-x86_64 related contributions is to submit patches to official PKGBUILDs where needed to allow building on said architectures.
[09:32:46] <Antiz> So if you come accros official PKGBUILDs that doesn't build on e.g. aarch64 and you're able patch it, feel free to submit a MR :D
[09:32:49] <TheDcoder> what about contribution to infra and tooling? IMO leaving the package-specific patches to real users would be the best, we already have 99% of them working anyway.
[09:34:15] <Antiz> Ah well, the tooling part mostly happens in devtools
[09:34:40] <Antiz> TheDcoder: https://gitlab.archlinux.org
[09:34:41] <phrik> Title: Draft: Support building secondary architectures and ports (!334) · Merge requests · Arch Linux / devtools · GitLab (at gitlab.archlinux.org)
[09:34:55] <solskogen|M> First thing is start use it, and see if you have any problems. Even if a package is built, doesn't mean that it works.
[09:36:07] <Antiz> TheDcoder: If you wanna help testing and getting this to finish line, that would be a great help tooling wise. This will allow to use our official packaging tooling on ports (which is expected for eventual official support in the future)
[09:36:54] <Antiz> TheDcoder: As for automation / infra part, this milestone is mostly tracked in the buildBTW project (our WIP automated build service): https://gitlab.archlinux.org
[09:36:56] <phrik> Title: Arch Linux / buildbtw · GitLab (at gitlab.archlinux.org)
[09:37:11] <TheDcoder> solskogen|M: I would but I'm running a Pi 4, which isn't currently supported.
[09:37:19] <Antiz> You can find milestones and work items about it. Although, I don't think those are being worked on yet.
[09:39:27] <TheDcoder> Antiz: buildbtw looks cool! And I know Rust so I might be able to contribute, will take a look when I'm free.
[09:40:35] <solskogen|M> TheDcoder: get a Pi500+ - the coolest ARM device I know :-)
[09:41:09] <stickynotememo> pi500?
[09:41:10] <TheDcoder> solskogen|M: in this economy? simply not a wise financial decision lol
[09:41:18] <stickynotememo> they were on pi 4 when i bought mine
[09:41:18] <TheDcoder> stickynotememo: it's the keyboard version
[09:41:19] <solskogen|M> Orion O6 / O6N is also quite nice.
[09:41:49] <solskogen|M> Pi500+ - it got both nvme and a very nice mechanical keyboard
[09:42:02] <moxie> So many who own pi4! solskogen|M are you not yet convinced for better cutoff point? :D
[09:42:14] <stickynotememo> i mean i have a pi3b+
[09:42:26] <stickynotememo> i bought it when the 4s were out though
[09:42:34] <TheDcoder> moxie: the issue holding off pi4 support might be solved, but now we have to rebuild all the packages, which is not easy lol
[09:42:45] <solskogen|M> You can run 64bit os on 3B+ as well, can't you?
[09:43:41] <stickynotememo> yes
[09:43:46] <stickynotememo> from what i understand
[09:43:52] <solskogen|M> That said, when the Pi5 came out was the time when you could really use it for something serious.
[09:46:25] <TheDcoder> Pi 4 is plenty good as server as well
[09:46:28] <solskogen|M> I've also managed to boot/use Aarch64 Linux (in the lack of a better name of this project) on my Macbook Neo using UTM :-)
[09:46:38] <stickynotememo> Yeah, can we come up with a name for it?
[09:46:57] <stickynotememo> aaarchlinux
[09:46:59] <stickynotememo> is not a good name
[09:47:12] <TheDcoder> solskogen|M: now get it working outside the VM :P
[09:59:36] <linkmauve> solskogen|M, what is the status of the Orion O6 stuff in Linux? Are they upstreaming their drivers, or do they expect people to use downstream kernels forever?
[10:00:06] <linkmauve> I’m very happy with both AllWinner and Rockchip SoCs and boards, which are running fine in mainline since basically forever.
[10:00:29] <linkmauve> Not upstreaming stuff is why I’ve stayed away from Broadcom for instance.
[10:00:38] <solskogen|M> the gpu isn't in mainline - but everything else seems to work for me (at least)
[10:00:53] <linkmauve> Which GPU is that?
[10:01:08] <solskogen|M> But I'm using a external GPU so the onboard gpu isn't my concern
[10:01:36] <linkmauve> Mali G720, weird I thought ARM was pretty good nowadays.
[10:01:46] <solskogen|M> "Arm® Immortals™ G720 MC10 GPU"
[10:01:58] <linkmauve> Is the issue in Linux or in Mesa?
[10:02:03] <linkmauve> Or perhaps both?
[10:02:18] <Charon77> Is there a list of packages that fail to build?
[10:02:22] <solskogen|M> lspci doesn't even recognize it (but it works) - but no 3d or acceleration
[10:02:47] <solskogen|M> Charon77: Not fully published.
[10:03:10] <solskogen|M> But again, building is not the main thing to worry about.
[10:03:28] <linkmauve> solskogen|M, such GPUs aren’t connected on the PCI bus, they are directly in the SoC.
[10:03:36] <solskogen|M> Unless you're a haskell expert. We don't have any haskell packages.
[10:04:17] <bertptrs> solskogen|M: what's currently broken for Haskell? the only Haskell I need is pandoc but still
[10:04:32] <solskogen|M> everything.
[10:04:55] <solskogen|M> we're using pandoc-bin from aur, since a lot of packages depend on it.
[10:04:57] <bertptrs> that sounds about right, but can you be more specific :P
[10:05:38] <bertptrs> I'm currently putting off running Arch on my Pi5, but this could be a nice project to figure out
[10:05:42] <solskogen|M> We need help bootstrapping haskell
[10:06:15] <bertptrs> I can try and figure that out. Thanks.
[10:06:21] <Charon77> I have Mali-G72. The vulkan implementation is a stub, OpenGL 3.1
[10:07:19] <linkmauve> Charon77, what do you mean by stub?
[10:07:58] <Charon77> `PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1`, not everything works, Zed (the text editor) refuses to run
[10:09:02] <linkmauve> Heh, sounds similar to my Mali-G52. :)
[10:09:40] <linkmauve> From what I’ve read, that generation (v7) doesn’t support the required hardware feature for a modern Vulkan implementation.
[10:09:50] <linkmauve> It can still provide 1.0 I think.
[10:10:05] <linkmauve> I have a v10 which provides 1.4 and is pretty solid though!
[10:10:41] -!- TheDcoder has quit [Read error: Connection reset by peer]
[10:11:03] -!- TheDcoder has joined #archlinux-ports
[10:11:35] <linkmauve> solskogen|M, panthor seems to have support for your GPU for the past year already: https://lwn.net
[10:11:36] <phrik> Title: drm/panthor: Add GPU specific initialization framework to support new Mali GPUs [LWN.net] (at lwn.net)
[10:11:50] -!- filmroellchen has joined #archlinux-ports
[10:12:18] <linkmauve> Same for Mesa, one year already: https://www.phoronix.com
[10:12:24] <Charon77> Oh and I frequently got graphical glitches, weird square glitching on bottom right, sometimes entire screen would flicker, and dmesg would yell at me. I'm running google's downstream kernel because upstream had issue
[10:12:51] <linkmauve> Charon77, have you reported them upstream? Whenever I have they got fixed quickly.
[10:13:22] <linkmauve> For instance I had this two years ago: https://gitlab.freedesktop.org
[10:13:23] <phrik> Title: Panfrost and panvk misrender when using GL_EXT_base_instance on Mali-G52 (#11892) · Issues · Mesa / mesa · GitLab (at gitlab.freedesktop.org)
[10:13:40] <solskogen|M> linkmauve: I never got it to work. and there seems to be a out-of-tree mod that should work: https://github.com (I haven't tried)
[10:13:41] <phrik> Title: GitHub - Sky1-Linux/cix-gpu-kmd: CIX Mali GPU kernel driver (mali_kbase) with DKMS packaging for Sky1/CD8180 · GitHub (at github.com)
[10:15:12] <linkmauve> Oh, why out-of-tree? :/
[10:17:15] <linkmauve> Ok, apparently your vendor only upstreamed the bare minimum to get your SoC working in mainline, see: https://github.com
[10:17:17] <phrik> Title: Sky1-Linux · GitHub (at github.com)
[10:22:46] <solskogen|M> I haven't given it much thought, since the machine in question has a nvidia gpu in it. Which meant that I could test ollama with cuda on aarch64 :-)
[10:25:38] <linkmauve> Ah, I’m not interested in proprietary software.
[10:32:58] <Charon77> linkmauve I'm using out of tree right now (very sad), I have reported some other device tree issue to the maintainers. Turns out the fastest way to get a hold on someone is by filing a regression :D
[10:34:44] <Charon77> I'd love to use upstream, but I can't easily switch kernels now, because how depthcharge works, and messing up means the display wouldn't initialize and I'd need a suzyqable (again), I'll test it out eventually
[10:36:28] -!- Charon77 has quit [Remote host closed the connection]
[10:41:54] -!- Charon77 has joined #archlinux-ports
[10:42:16] -!- Charon77 has quit [Client Quit]
[10:42:48] -!- Charon77 has joined #archlinux-ports
[10:43:13] -!- Charon77 has quit [Client Quit]
[10:43:28] -!- Charon77 has joined #archlinux-ports
[11:31:17] <solskogen|M> Something else we need help with is archiso. Make it create images for us, instead of my script.
[11:50:04] <TheDcoder> ALARM simply ships a tarball with the entire root FS in it, I think we can just do the same.
[11:50:19] <solskogen|M> We do
[11:51:21] <TheDcoder> okay, we just polish your script and stick to it :)
[11:51:25] <solskogen|M> But that requires that you already have a OS running on your device. With a image (which will be in addition to the tarball) you can write it to a usb stick or sd card or whatever from another location.
[11:52:07] <solskogen|M> archiso is the official way - that's why I want to use it.
[11:52:13] <TheDcoder> like live booting from an USB? I don't think SBCs can do that given the state of their BIOS... or lack there of.
[11:52:34] <solskogen|M> All of my devices can do that.
[11:52:45] <TheDcoder> even the RPi 5?
[11:52:53] <linkmauve> TheDcoder, sure you can, if you already have u-boot.
[11:53:11] <linkmauve> For all purposes, it acts as a BIOS.
[11:53:13] <TheDcoder> linkmauve: well that changes things, and it's a 3rd party thing if I am not wrong.
[11:53:13] <solskogen|M> Sure. The Pi5 can boot from sd card, usb, nvme. Even netboot.
[11:53:33] <linkmauve> u-boot? It’s a “universal” bootloader, that’s even in the name. :)
[11:53:46] <solskogen|M> the netboot, boots raspberry pi imager. So in theory, we could have Arch being installable from there.
[11:53:49] <TheDcoder> solskogen|M: I assume that's with u-boot?
[11:54:03] <solskogen|M> Nope.
[11:54:48] <solskogen|M> as long as your pi eeprom is up to date, you can boot whatever when you hold spacebar when powering it up.
[11:55:21] <TheDcoder> cool, must be a new feature then, because I don't think that's possible with Pi 4, it requires the SD card if I am not wrong
[11:55:54] <TheDcoder> it loads the bootloader from the FAT partition on it
[11:56:03] <solskogen|M> Pi4 can also do that.
[11:56:19] <linkmauve> Oh wow, a FAT driver in the bootrom? :o
[11:56:26] <solskogen|M> Not pi3.
[11:56:27] <linkmauve> How large is this thing?
[11:56:40] <solskogen|M> what thing?
[11:56:45] <linkmauve> The bootrom.
[11:56:51] <TheDcoder> really? how would I go about booting an SD card or an nvme?
[11:57:23] <solskogen|M> 512kb?
[11:57:36] <TheDcoder> linkmauve: I mean FAT is not really that complicated, especially if you're just reading stuff from it
[11:57:54] <solskogen|M> the easiest option is to write raspberry pi os to a sd card - and after you've booted it run "rpi-eeprom-update -a"
[11:58:06] <solskogen|M> and reboot
[11:58:13] <solskogen|M> https://github.com
[11:58:15] <phrik> Title: rpi-eeprom/firmware-2711/release-notes.md at master · raspberrypi/rpi-eeprom · GitHub (at github.com)
[11:58:17] <linkmauve> solskogen|M, has it been dumped?
[11:58:33] <solskogen|M> dumped?
[11:59:25] <solskogen|M> we have rpi-eeprom-update in our repos as well, but it's only for Pi5.
[11:59:39] <solskogen|M> I'm not sure how up to date ALARM is
[12:00:07] <linkmauve> solskogen|M, the bootrom is the part hardcoded in the SoC which chainloads other parts of the boot process, usually it does the bare minimum to initialize and pick the next one.
[12:01:00] <linkmauve> For instance that’s how it looks like on Rockchip SoCs: https://opensource.rock-chips.com
[12:01:05] <phrik> Title: Boot option - Rockchip open source Document (at opensource.rock-chips.com)
[12:01:56] <linkmauve> Does Broadcom boot straight up from that EEPROM you mention?
[12:02:03] <solskogen|M> Not all ARM devices are alike :-)
[12:02:26] <TheDcoder> interesting stuff, never knew that I could update the ROM on my Pi
[12:02:27] <solskogen|M> My Orion uses EDK - my Odroid M2 can use either uboot or edk.
[12:03:25] <solskogen|M> It's only for Pi4 and Pi5 (plus their counterparts CM4/5, Pi400/500/500+=
[12:04:27] <TheDcoder> linkmauve: https://www.raspberrypi.com
[12:05:24] <TheDcoder> I wish everyone just adopts UEFI
[12:05:58] <linkmauve> TheDcoder, right, so that’s exactly what I described, a bootrom (what they call the First stage bootloader) which is hardcoded in the SoC, which then loads the second stage from SPI.
[12:06:11] <linkmauve> TheDcoder, u-boot exposes UEFI if you like. :)
[12:06:27] <linkmauve> I usually skip that because I just want to boot Linux usually.
[12:06:29] <TheDcoder> it does? nice
[12:06:49] <linkmauve> TheDcoder, https://docs.u-boot.org
[12:06:50] <phrik> Title: UEFI on U-Boot — Das U-Boot unknown version documentation (at docs.u-boot.org)
[12:08:19] <linkmauve> solskogen|M, is that second stage bootloader free software nowadays, on Raspberry Pi?
[12:08:55] <TheDcoder> linkmauve: I see blobs in their repo so I guess not
[12:09:09] <linkmauve> :(
[12:09:10] <solskogen|M> Don't think so, no.
[12:09:22] <TheDcoder> probably because whatever SDK required to build it is locked under NDAs
[12:09:37] <solskogen|M> but don't take my word for it
[12:11:03] <linkmauve> Well, I guess I’ll continue using open platforms, where the only proprietary bits left are the bootrom (obviously, but you can’t change that ever) and the RAM training, and hopefully at some point I’ll gather enough courage to finish to reverse engineer that RAM part!
[12:11:30] <linkmauve> CyReVolt started working on that, but never finished their work.
[12:12:14] <TheDcoder> which platform are you using at the moment?
[12:13:01] <linkmauve> A rk3588, the Radxa Rock 5B.
[12:13:15] <linkmauve> I also have a rk3568, the ODROID-M1.
[12:13:33] <linkmauve> As well as a bunch of AllWinner A10, A20 and an A64 phone, the PinePhone.
[12:14:02] <linkmauve> All of these run mainline u-boot and Linux with almost no missing hardware features. :)
[12:14:21] <linkmauve> And for the AllWinner boards, no proprietary code being ran at all!
[12:18:58] <linkmauve> Oh, apparently u-boot also supports the Raspberry Pi, it might be a good replacement of that proprietary EEPROM bootloader, and give you UEFI and network boot and no need for a FAT partition and various other neat features: https://docs.u-boot.org
[12:18:59] <phrik> Title: Raspberry Pi — Das U-Boot unknown version documentation (at docs.u-boot.org)
[12:19:44] <TheDcoder> good stuff!
[12:20:29] <TheDcoder> I don't think u-boot replaces the EEPROM though, looks like it might sit on top of it.
[12:20:42] <linkmauve> Oh…
[13:07:52] <bschnei> In addition to traditional package maintenance work, we'd welcome help with device support in general. Our kernel config is fairly minimal. Confirmation that things work and MRs that fix them when they don't are welcome. https://gitlab.archlinux.org
[13:07:53] <phrik> Title: Files · aarch64 · Benjamin Schneider / linux · GitLab (at gitlab.archlinux.org)
[13:13:28] <bschnei> To help clarify a couple things: you can build x86_64 packages "as is" by passing the -A option to makepkg. When/if we do have a fork of a package that isn't ready for an MR, you will usually find those in my (bschnei) or solskogen namespaces on gitlab (see the URL above for linux, e.g.). solskogen and drzee are cooking something cool to make it easier to figure out which packages have problems, stay tuned here for upda
[13:13:28] <bschnei> tes.
[13:14:17] <solskogen|M> bschnei: I posted the link yesterday :-)
[13:14:27] <bschnei> ty!
[13:15:06] <solskogen|M> I've stopped the autobuilder due to fact that I'm trying to get python-pytorch to build.
[13:15:27] <solskogen|M> Using a whopping 200G of mem
[13:54:52] <linkmauve> Packages (1) linux-6.19.11.arch1-1
[13:54:53] <linkmauve> Total Download Size: 126.01 MiB
[13:54:53] <linkmauve> Total Installed Size: 125.84 MiB
[13:54:53] <linkmauve> This is the first time I see more to download than to install! Is it because you disabled compression for that package?
[13:55:43] <Charon77> linux is already compressed, so maybe it's double compressed
[13:55:59] <solskogen|M> might be, yes
[14:00:34] <Charon77> anyway I'm trying out the port now (finally), running `sudo pacman -S $(pacman -Qnq)`, hopefully nothing blows up
[14:00:53] <solskogen|M> Hopefully
[14:08:00] <Charon77> Okay, little problem
[14:08:03] <Charon77> error: failed to commit transaction (conflicting files)
[14:08:04] <Charon77> gcc-libs: /usr/lib/libasan.so exists in filesystem (owned by libasan)
[14:08:04] <Charon77> gcc-libs: /usr/lib/libasan.so.8 exists in filesystem (owned by libasan)
[14:08:04] <Charon77> gcc-libs: /usr/lib/libasan.so.8.0.0 exists in filesystem (owned by libasan)
[14:08:04] <Charon77> gcc-libs: /usr/lib/libatomic.so exists in filesystem (owned by libatomic)
[14:08:30] <linkmauve> When I try to boot the vmlinuz kernel you provide on my rk3588 board, I get “Bad Linux ARM64 Image magic!”
[14:09:34] <linkmauve> Charon77, this port decided to do gcc completely differently from upstream x86_64 for some reason…
[14:09:57] <linkmauve> You might have to force remove these libasan and libatomic packages, and install gcc-libs again.
[14:12:20] <Charon77> yeah, gcc-libs is no longer meta on their side
[14:16:25] <Charon77> Oh noes
[14:16:38] <Charon77> thank goodness of the issue, I tried installing gcc first
[14:16:40] <Charon77> gcc
[14:16:41] <Charon77> gcc: fatal error: no input files
[14:16:41] <Charon77> compilation terminated.
[14:16:41] <Charon77> Illegal instruction (core dumped) gcc
[14:16:55] <Charon77> I wonder which one it is
[14:20:13] <linkmauve> Charon77, coredumpctl gdb, then layout asm.
[14:25:41] <Charon77> oh crap I broke my system :D
[14:26:16] <Charon77> could someone give me link to pacman static
[14:26:29] <Charon77> curl still works, I don't have browser anymore
[14:44:44] <bertptrs> https://aur.archlinux.org ?
[14:49:37] <Charon77> okay, I was able to get libgcc from /var/cache/pacman
[14:49:52] <Charon77> I should be careful and not just blindly install everything :")
[14:54:02] <linkmauve> Yay, it worked!
[14:54:02] <linkmauve> [linkmauve@archlinux ~]$ uname -a
[14:54:02] <linkmauve> Linux archlinux 6.19.11-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 05 Apr 2026 09:49:48 +0000 aarch64 GNU/Linux
[14:54:22] <linkmauve> bschnei, this is on a Rock 5B, using your kernel, and a boot.scr for u-boot. :)
[14:55:26] <linkmauve> Now I’m trying to use the extlinux.conf method instead.
[14:55:40] <Charon77> Okay, I'm back on my feet
[14:56:07] <Charon77> so I think the package contains some instruction that I can't run. shouldn't have modified core just yet
[14:56:12] <Charon77> let me try gdb as you mentioned
[14:58:24] <linkmauve> Charon77, is your CPU ARMv8.2, with the crypto extension?
[15:01:11] <Charon77> would cpuinfo help?
[15:01:12] <Charon77> processor : 0
[15:01:12] <Charon77> BogoMIPS : 26.00
[15:01:12] <Charon77> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
[15:01:12] <Charon77> CPU implementer : 0x41
[15:01:19] <Charon77> CPU architecture: 8
[15:01:20] <Charon77> CPU variant : 0x0
[15:01:20] <Charon77> CPU part : 0xd03
[15:01:20] <Charon77> CPU revision : 4
[15:01:46] <linkmauve> bschnei, you might want to enable CONFIG_VIDEO_HANTRO=m, so that we could do video encoding/decoding on these SoCs.
[15:02:55] <linkmauve> Charon77, that’s a Cortex-A53, which is only ARMv8, not ARMv8.2.
[15:03:14] <linkmauve> You won’t be able to use this port, as it only targets ARMv8.2.
[15:03:32] <Charon77> how sad
[15:03:36] <linkmauve> You need at least a Cortex-A55 to support ARMv8.2 from ARM.
[15:03:51] <linkmauve> Charon77, which SoC is that btw?
[15:04:03] <Charon77> mt8183-kukui-krane
[15:04:41] <linkmauve> Yup, it says so here: https://wiki.postmarketos.org(google-krane)
[15:04:43] <phrik> Title: Lenovo IdeaPad Duet Chromebook (google-krane) - postmarketOS Wiki (at wiki.postmarketos.org)
[15:04:50] <linkmauve> Cortex-A73 and Cortex-A53.
[15:05:00] <coherence42> solskogen|M: have you built electron successfully?
[15:05:38] coherence42 is now known as cjc7373
[15:06:57] <Charon77> So that means if I want to use this, I'll need to build myself, but I can use upstream PKGBUILD
[15:07:52] <linkmauve> I guess so? I wouldn’t go through the pain of building an entire distribution on some Cortex-A73 though.
[15:27:56] <Charon77> I saw https://gitlab.archlinux.org that the two offending packages surrounding LSE has been resolved, I hope my device can be used..
[15:27:58] <phrik> Title: Determine which instruction set to support (#6) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[15:32:20] <linkmauve> Charon77, uh, you mean Chromium is actually compiled for ARMv8, not ARMv8.2?
[15:32:22] <linkmauve> It couldn’t possibly work on your CPU otherwise.
[15:37:12] <Antiz> Charon77: Thanks for the MR for docs. I can make a proper review later. Quick review: All the trailing double spaces you removed are intentional and should be kept. This produces in line return in markdown
[15:37:52] <Antiz> Also, we don't really care about line length. You don't have to split lines half sentence.
[15:39:25] <Antiz> Generally looks good otherwise, although I only had a quick glances, I will do a proper review later.
[15:40:31] <Antiz> The build system section is wrong though. Using BuildBTW is the final target but this is still a work in progress at the moment, it's not ready / usuable yet. I guess solskogen|M can clarify what they use for package building
[15:41:12] -!- bs86 has joined #archlinux-ports
[15:50:06] -!- bill-auger_ has joined #archlinux-ports
[17:07:11] -!- ubitux has joined #archlinux-ports
[17:08:33] <ubitux> hi; I'm interested in participating on the aarch64 port. I'd be happy to test building and running images on some boards.
[17:09:02] <ubitux> (followup from https://gitlab.archlinux.org)
[17:09:03] <phrik> Title: Write announcement / call for contributions (#4) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[17:23:24] -!- marmis1 has joined #archlinux-ports
[17:25:28] -!- marmis has quit [Ping timeout: 276 seconds]
[17:25:28] marmis1 is now known as marmis
[18:32:37] <linkmauve> solskogen|M, dolphin-emu fails on boot, it probably needs a rebuild: % dolphin-emu
[18:32:38] <linkmauve> dolphin-emu: error while loading shared libraries: libvpx.so.11: cannot open shared object file: No such file or directory
[18:34:07] <linkmauve> On x86_64 both versions are the same, and yet dolphin-emu is built against libvpx.so.12.
[18:45:21] <fermino> Wellll, I forgot I had an rk3566 laying around :)
[18:45:33] <fermino> Which I understand has good mainline support, so that'll be fun
[18:46:24] <linkmauve> Yup! Pretty happy about mine. :)
[18:49:08] <fermino> What board do you have?
[18:49:36] <linkmauve> An ODROID-M1.
[18:49:50] <linkmauve> It has a rk3568, but there are extremely few differences between both.
[18:50:08] <linkmauve> The rng for one doesn’t work on yours.
[18:56:46] <bill-auger_> i could test w/ pinebookpro, olimex teres, and lime2/freedombox
[18:57:09] <fermino> I have a powkiddy x55, I'm not quite sure about the boot process for it, but I'll start reading about it
[18:57:23] <bill-auger_> oh sry not lime2 thats v7
[19:04:12] <linkmauve> bill-auger_, Pinebook Pro is ARMv8, not ARMv8.2.
[19:04:32] <linkmauve> Olimex Teres is also ARMv8.
[19:04:52] <linkmauve> So out of these, none that is supported by this current port.
[19:24:03] <solskogen|M> linkmauve: Will fix. Thanks!
[19:32:27] <bill-auger_> ok :( guess im not rich enough to play this game
[19:43:36] <solskogen|M> How many of you cant join because of the ARMv8.2-a requirement?
[19:46:20] <linkmauve> Most of us it seems. :)
[19:46:44] <linkmauve> I have so many more devices which are ARMv8 only than ARMv8.2 here.
[19:47:00] <BrainDamage> I am also cut out
[19:47:33] <solskogen|M> goddamit. ARMv8.2 is already 10 years old.
[19:48:53] <linkmauve> It appeared in CPUs way later than when it got announced, and these cores cost more than the older ones so companies still pick older ones over newer ones.
[19:49:04] <BrainDamage> remember that a) manufacturers are slow to adopt and b) the boards are pretty cheap so they tend to use older cpus too
[19:49:13] <linkmauve> Like the rk3576 is newer than the rk3588, yet they went for older ARMv8 cores.
[19:49:13] <solskogen|M> I mean, ARM Cortex-A73 is from 2016.
[19:49:51] <linkmauve> solskogen|M, Cortex-A53 will never die. :)
[19:50:26] <linkmauve> Although, I see fewer and fewer Mali-4xx nowadays, so maybe perhaps someday!
[19:51:02] <solskogen|M> and do they require vendor specific kernels?
[19:51:06] <solskogen|M> or does mainline work?
[19:51:12] <BrainDamage> and newer devices are even less appealing now that prices skyrocketed
[19:52:27] <linkmauve> solskogen|M, mainline works on many devices, all of the ones mentionedz by bill-auger_ for instance.
[19:52:43] <bill-auger_> FWIW, i remember a discussion in #archlinuxarm , the concensus was that probably more people are using it on ARMv7 boards than any other
[19:53:19] <linkmauve> bill-auger_, they have package download stats, they just don’t publish them.
[19:54:33] <BrainDamage> most of my boards are v8-A, I have 2 v7, and some rpi0 which are v6 that I got because they were dirt cheap and sufficient for my tasks, v6 got already cut out from archlinuxarm, and this project cuts out all of my boards
[19:55:07] <bill-auger_> indeed olimex and pine64 are well supported - armbian has made images for them for about 2 years
[19:55:07] <linkmauve> The only ARMv6 I have here is the Nintendo 3DS, and mainline is still quite far for this one.
[19:55:29] <BrainDamage> fwiw rpi3 and rpi4 for instance are still being sold here on amazon, at outrageous prices, because rpi5 are sold at even more outrageous prices
[19:55:47] <linkmauve> I’ve ran mainline on my Olimex Lime ever since I got them, back in 2014. And to this day a Lime2 is still my main server. :)
[19:55:48] <BrainDamage> lie 180 bucks, at which point an x86 is a more appealing choice
[19:56:25] -!- fermino_ has joined #archlinux-ports
[19:56:27] <linkmauve> BrainDamage, Raspberry Pi hasn’t been cost efficient in a good decade, compared to better boards from other vendors.
[19:56:50] <linkmauve> It just is a popular brand, so people go for it, despite all of the shortcomings.
[19:56:56] <BrainDamage> rpi3 was briefly, rpi4 was ok actually
[19:57:00] -!- fermino has quit [Ping timeout: 246 seconds]
[19:57:00] fermino_ is now known as fermino
[19:57:23] <solskogen|M> And the reason it's popular is because there's a community around it.
[19:57:29] <solskogen|M> none of the other really have that
[19:57:40] <BrainDamage> as in, I compared the prices with odroids and other brands, and they had comparable prices and specs
[19:57:40] <bill-auger_> BrainDamage: drop the "RP" requirement and the cost is better - olimex and pine64 are significantly cheaper
[19:57:43] <solskogen|M> which is why the Pi is the best SBC board.
[19:57:53] <solskogen|M> Not because it's the cheapest or fastest.
[19:57:58] <BrainDamage> pi1, pi2 etc were just awful
[19:58:00] <bill-auger_> so raspberry users are paying extra for "community" ?
[19:58:22] <solskogen|M> hell yes
[19:58:24] <BrainDamage> again, they had comparable price points when they came out
[19:58:33] <fermino> The rpi foundation has been steadily moving from the hobbyist market to the enterprise
[19:58:44] <BrainDamage> but only 3 and 4
[19:59:01] <BrainDamage> however 3 got obsoleted by the market fast, 4 held slightly longer
[19:59:24] <linkmauve> solskogen|M, you don’t really need a community dedicated to a particular brand, if it runs mainline Linux you can use anything made for Linux for any purpose and that’s it.
[19:59:41] <BrainDamage> also, the engineering behind the 3 and 4 was much more sensible, like the ethernet chip not sitting on usb ...
[19:59:43] <solskogen|M> I think I've bought at least 8 different ARM boards. All of them got a lot of praise when they got released, but almost all of them was just... forgot when it first came out.
[19:59:46] <linkmauve> It’s only if one brand decides to do things differently that suddenly you need a community to get around the quirks.
[20:00:36] <solskogen|M> You either needed a special vendor specific kernel, or u-boot or even a home made distribution made by some random guy with a google drive account.
[20:00:38] <BrainDamage> you do need support, including hw specific quirks
[20:00:47] <linkmauve> BrainDamage, they both lack the crypto extension, which makes them pretty worthless for any network use, for instance.
[20:01:03] <linkmauve> I think they finally licensed that one in the Raspberry Pi 5?
[20:01:43] <linkmauve> solskogen|M, yeah, better pick the ones well supported upstream.
[20:02:02] <BrainDamage> they are fast enough to saturate my 1Gbps ethernet, which is good enough for me
[20:02:04] <solskogen|M> ALARM even has the latest supported kernel for the awesome utilite from 2015.. which is 3.0.35.
[20:02:42] <linkmauve> BrainDamage, in my experience, not really, when I write a program I don’t need to care if it will run on an Olimex or on a Pine64 device, nor if they use a SoC from AllWinner or from Rockchip, I just target the standard Linux API and that’s it.
[20:03:19] <BrainDamage> again, my bandwith is the bottleneck, not cpu here, even using crypto
[20:03:27] <linkmauve> That’s the exact role of the kernel, to abstract over hw specific quirks so that a particular program doesn’t need to know anything about the exact computer it runs on.
[20:03:30] <solskogen|M> While Raspberry Pi.. their latest OS even works on the Pi1.
[20:03:49] <BrainDamage> I run literally all my machines in my lan over vpn
[20:04:09] <BrainDamage> just so that my local and remote setup is identical, no split horizon dns, etc
[20:04:16] <BrainDamage> plus no plaintext traffic
[20:04:28] <linkmauve> BrainDamage, oh, I didn’t know that a Cortex-A53 could do AES at 1 Gbps, interesting!
[20:05:18] <linkmauve> solskogen|M, ALARM ships terrible BSP kernels, sometimes even though the boards in question are much better supported by mainline.
[20:05:40] <linkmauve> Imo it shouldn’t be a distribution’s role to ship downstream kernels.
[20:06:18] <BrainDamage> the kernels are sometimes needed for _all_ the functions, and usually rather necessary for average joe when they were released
[20:06:56] <BrainDamage> then they get gradually obsoleted by people mainlining support
[20:06:58] <BrainDamage> I have a couple of odroid c1 that got mainlined that way
[20:07:54] <BrainDamage> so they made sense at some point, but like most things in alarm, they were setup once and never looked again
[20:10:30] <fermino> I'm thinking about getting a used rpi3 to free up the 8gb rpi4 I have in my 3d printer; prices are so inflated here in arg, the best I can get is literally a used 1g rpi3 at around 40 bucks :(
[20:11:33] <solskogen|M> then I suggest some of you make a AUR package for the Pi4 kernel. https://github.com this is one I'm using for the Pi5.
[20:11:35] <phrik> Title: GitHub - bschnei/linux-rpi5 · GitHub (at github.com)
[20:12:51] <fermino> Yeah, I'll take a stab at it if I get to free it, I'm currently using the alarm rpi kernel and it's working incredibly well (VC4 w/ KMS and everything)
[20:12:52] <BrainDamage> I use the standard vanilla kernel with alarm, the problem is that it's armv8A
[20:13:39] <BrainDamage> rebuilding all the packages is too much of a task for me
[20:14:00] <solskogen|M> I'm not gonna do armv7
[20:14:20] <BrainDamage> it's armv8, but not 8.2
[20:14:32] <fermino> Anything mentioned armv5? I have some old thin clients laying around...
[20:14:33] <fermino> xD
[20:15:06] <BrainDamage> rpi3 is armv8 fwiw
[20:15:20] <fermino> Is there any sort of orchestration thingy for building packages? (besides the upcoming buildbtw) Or is it all manual so far?
[20:15:32] <solskogen|M> Feel free, but I'm not gonna spend my free time with that.
[20:16:04] <BrainDamage> alarm by default serves it with armv7, but it can run 64 bit armv8 kenels and packages if you wish to
[20:16:32] <solskogen|M> If it was up to me, we could have ARMv8-a, ARMv8.1, ARMv8.2 etc... But I don't have the time nor the horse power to make it so.
[20:16:48] <fermino> One bite at a time :)
[20:17:12] <fermino> Would it make sense to have different repos? (Like, is it a big difference performance wise?)
[20:17:33] <solskogen|M> We're at AWS.
[20:17:42] <solskogen|M> The answer to that question is no :-)
[20:17:57] <fermino> I mean, for different arch levels
[20:19:20] <solskogen|M> Arch has done that part quite easy to fix. Because we have core/os/$arch
[20:19:31] <fermino> Ohhh, right
[20:19:49] <solskogen|M> which would mean that armv8 would be core/os/armv8, armv8.2-a would be core/os/armv8.2-a etc.
[20:21:24] <BrainDamage> would even 8.1 make sense performance-wise?
[20:21:44] <solskogen|M> how many ARMv8.1 devices are there?
[20:21:57] <linkmauve> fermino, that’s a good question actually, I have different btrfs subvolumes for ALARM and for this port on some of my boards, I could run benchmarks if you have any to recommend.
[20:22:25] <linkmauve> BrainDamage, ARMv8.1 did bring atomics, so for instance in FEX-Emu it was a huge perf improvement.
[20:23:02] <linkmauve> But FEX is a JIT, so even when compiled for ARMv8 it can emit atomic instructions at runtime.
[20:24:24] <linkmauve> solskogen|M, https://en.wikipedia.org lists only two, Cavium ThunderX2 and Qualcomm Falkor.
[20:24:25] <phrik> Title: Comparison of ARM processors - Wikipedia (at en.wikipedia.org)
[20:34:41] <solskogen|M> coremark says that there's a ~7% performance difference between armv8-a and armv8.2-a on a Pi. and that's single thread.
[20:40:34] <linkmauve> That’s more than I was expecting!
[20:41:19] <solskogen|M> That's only one benchmark, but you get the idea.
[20:43:58] <solskogen|M> the difference between 8.2-a and 9.2-a was.. not so much.
[21:12:15] <solskogen|M> python-pytorch FINALLY finished after 7 hours
[21:26:34] <solskogen|M> linkmauve: fixed now I think.
[21:28:13] <linkmauve> Thanks!
[21:31:42] <solskogen|M> and for you newcomers: http://arch-linux-repo.drzee.net
[21:31:43] <phrik> Title: Arch Linux AArch64 Build Report (at arch-linux-repo.drzee.net)
[21:32:57] <solskogen|M> and by new comers, I mean those who joined today. That page is something I set in motion two days ago, so I didn't start tracking this until recently.
[22:10:13] -!- titus_livius has joined #archlinux-ports
[22:31:53] <bschnei> linkmauve: traffic has picked up here quite a bit. can you please send an MR so it doesn't get lost? Thanks!
[22:34:20] <bschnei> for those with v8 devices that are willing to use what are effectively experimental packages at this stage you can find them at https://repo.bens.haus expect things to break, be behind, etc. but I do run a very small subset of these packages on devices I own so a base system should be stable
[22:34:21] <phrik> Title: Index of /arch/ (at repo.bens.haus)
[22:36:06] -!- filmroellchen has quit [Quit: filmroellchen]
[22:36:08] <bschnei> Maintaining all these packages will not be my priority. I want to work on our documentation a bit before coming back to this issue
[23:19:05] -!- linkmauve has quit [Remote host closed the connection]
[23:28:27] -!- linkmauve has joined #archlinux-ports
[23:43:28] -!- linkmauve has quit [Remote host closed the connection]
[23:48:34] -!- linkmauve has joined #archlinux-ports