#archlinux-ports | Logs for 2025-11-12
Back
[04:57:08] -!- hcmb_ has joined #archlinux-ports
[04:57:08] hcmb is now known as Guest9589
[04:57:08] -!- Guest9589 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
[04:57:08] hcmb_ is now known as hcmb
[06:15:35] -!- wszqkzqk|M has quit [Ping timeout: 256 seconds]
[06:15:35] -!- kxxt|M has quit [Ping timeout: 256 seconds]
[06:15:35] -!- ektor5 has quit [Ping timeout: 256 seconds]
[06:15:50] -!- ektor5 has joined #archlinux-ports
[06:15:59] -!- kxxt|M has joined #archlinux-ports
[06:28:02] -!- wszqkzqk|M has joined #archlinux-ports
[08:53:05] <nie> Hi. What's the current state of AArch64 port?
[08:55:42] <Antiz> nie: WIP, early stage
[08:57:24] <strit|M> I'd say bootstrapping phase, still.
[08:57:44] <Antiz> Well, unofficially
[08:58:16] <solskogen|M> It works-ish. we have a lot of packages, so you can start using it. Just dont expect that things will not break :-)
[08:58:56] <solskogen|M> If something is not working, report it - and if you think you can fix it - fix it and create a good MR.
[08:59:09] <Antiz> From an official "Arch Linux" POV, contributions for ports are currently opened in the scope described in this mail: https://lists.archlinux.org
[08:59:10] <phrik> Title: First step for non-x86_64 contributions - Arch-dev-public - lists.archlinux.org (at lists.archlinux.org)
[09:00:19] <Antiz> TL;DR, we are accepting packaging related MR to fix build on non-x86_64 architecture (as long as it doesn't go in the way of x86_64, which is still the only architecture supported as of now)
[09:00:48] <solskogen|M> That said, 95% of the things that are broken in aarch64 is also broken in x86_64.
[09:01:27] <Antiz> We also have opened a dedicated namespace on GitLab for people to collaborate around ports and to track specific issue. The one for aarch64 is at https://gitlab.archlinux.org
[09:01:28] <phrik> Title: AArch64 · GitLab (at gitlab.archlinux.org)
[09:02:04] <nie> Ok thanks. I probably might help, and willing to get involved.
[09:02:08] <Antiz> Non, outside of the official "Arch Linux" POV, we have a small group of dedicated people here that have shown really great results so far :)
[09:02:11] <Antiz> s/Non/Now
[09:02:40] <Antiz> There's an unofficial repo, an unofficial bootstrap tarball from which you can install an Arch aarc64 system from, etc...
[09:03:11] <solskogen|M> nie: That's what we like to hear :-) Create an account on gitlab.
[09:03:30] <Antiz> But there are still pending issues that needs to be figured out before we can consider adopting that officially on the Arch side.
[09:05:08] <Antiz> On the tooling & toolchain side most notably. The bootstrap tarball is also initiated from ALARM which poses a "trusting trust" issue.
[09:05:34] <solskogen|M> Antiz: Not true. The boostrap tarball is created by us.
[09:05:46] <Antiz> solskogen|M: Yes, with ALARM toolchain
[09:05:55] <solskogen|M> No.
[09:06:02] <jelle> > The bootstrap tarball is also initiated from ALARM which poses a "trusting trust" issue.
[09:06:02] <Antiz> "initiated" was not the right word
[09:06:09] <jelle> this is no "trusting trust" issue
[09:06:27] <Antiz> solskogen|M: https://gitlab.archlinux.org
[09:06:28] <phrik> Title: Bootstrap the toolchain (#1) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[09:07:00] <Antiz> solskogen|M: The tarball is created with ALARM toolchain right?
[09:07:12] <solskogen|M> We still have a trusting trust issue, I agree. But we're completely separated from ALARM.
[09:07:27] <Antiz> We had that discussion last time already... x)
[09:07:34] <Antiz> I know you are separated from ALARM
[09:07:42] <jelle> its more a bootstrap issue :)
[09:07:49] <Antiz> 👆
[09:08:07] <Antiz> The tarball being initially generated from ALARM tooling / toolchain is the problem
[09:08:07] <jelle> and honestly arch x86 has the same issue :P
[09:08:23] <Antiz> jelle: Yup ^^ But we can't do anything about it now x)
[09:08:32] <solskogen|M> 100%. But don't drag ALARM into it :-) We started out with ALARM, but we're disconnected from that now.
[09:08:39] <Antiz> No you're not x)
[09:08:43] <jelle> thats not true? You can bootstrap rust if you want too
[09:09:21] <Antiz> solskogen|M: The fact that you started with ALARM **is** the "issue" here. You cannot claim you're fully disconnected from ALARM since you started with it.
[09:09:37] <Antiz> The issue is that ALARM is a foreign distro that we cannot establish trust in.
[09:09:44] <jelle> Antiz: I am curious how you propose to bootstrap java or rust though
[09:10:09] <Antiz> So we cannot claim that your very first tarball generated from ALARM tooling / toolchain was ever secure from our POV
[09:10:31] <Antiz> And therefore, every later tarball / packages that we originated from it might also be infected hypothetically
[09:10:43] <Antiz> By inherithance
[09:10:49] <Antiz> solskogen|M: This is what this issue is about https://gitlab.archlinux.org
[09:10:50] <phrik> Title: Bootstrap the toolchain (#1) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[09:10:56] <solskogen|M> Our very first tarball was not generated from ALARM tooling. But we had to start from somewhere.
[09:11:14] <Antiz> Yes, well ideally we would like that "somewhere" to be Arch Linux
[09:11:22] <Antiz> That's the whole point of https://gitlab.archlinux.org
[09:11:23] <phrik> Title: Bootstrap the toolchain (#1) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[09:12:53] <solskogen|M> I agree on that part. Someone, I can't remember the name, came up with something that used the cross compilers from Arch. It's a great start.
[09:13:09] <Antiz> Now there can be a debate around that hard requirement. As jelle said, even Arch itself has historic problems on that front.
[09:14:01] <solskogen|M> that doesn't mean it should continue with the aarch64 port :-)
[09:14:22] <Antiz> Sure, I'd love that actually :)
[09:14:28] <jelle> I do think we should setup some reasonable expectations however
[09:14:30] <strit|M> Cross-compiling from x86_64 to aarch64 is certainly doable, but slow. So compiling the toolchain that way will take time. GCC itself takles hours.
[09:14:57] <solskogen|M> cross compiling isn't slow.
[09:15:00] <jelle> like, can rust be bootstrapped initially by a binary from rust.org?
[09:15:24] <solskogen|M> jelle: yes - that's what we did
[09:15:32] <jelle> plus if you are bootstrapping everything, its a PITA with cycles
[09:15:37] <strit|M> solskogen|M: When I did it, it was at least 4 times the duration for most packages.
[09:15:37] <jelle> and we have no good way to break those
[09:15:54] <Antiz> But still maybe we could discuss relaxing that requirement. But I just wanted to make clear that the "issue" here is a foreign distro's tooling / toolchain / compiler being involved in the process at some point. I know you're not relying on it anymore, but the fact that it was once involved *may* imply some "trusting trust" issue (as we cannot
[09:15:54] <Antiz> claim trust in a foreign distro's tooling / toolchain).
[09:15:55] <solskogen|M> strit|M: only if you're using qemu :-)
[09:16:00] <jelle> afaik fedora has some %_bootstrap mode in spec files
[09:16:31] <strit|M> solskogen|M: I was. 🙂 Haven't found a better system for it. What are you using?
[09:16:42] <Antiz> But as jelle said, maybe it's not realistic to have a hard requirement on this. That's another debate though ^^
[09:16:45] <solskogen|M> strit|M: gcc?
[09:16:58] <jelle> qemu++
[09:17:40] <strit|M> solskogen|M: gcc on x64 can compiile gcc for aarch64 without qemu? Didn't know that.
[09:17:58] <jelle> strit|M: we have https://archlinux.org
[09:17:59] <phrik> Title: Arch Linux - aarch64-linux-gnu-gcc 15.1.0-2 (x86_64) (at archlinux.org)
[09:18:10] <jelle> but I think it needs more like binutils
[09:18:14] <solskogen|M> Only if you configure gcc the correct way. https://archlinux.org
[09:18:15] <phrik> Title: Arch Linux - aarch64-linux-gnu-gcc 15.1.0-2 (x86_64) (at archlinux.org)
[09:18:24] <jelle> cross compiling is a messy affair, not my interest :D
[09:18:26] <solskogen|M> damn, jelle beat me to it.
[09:18:41] * jelle did spot a new arm machine on the market
[09:18:50] <jelle> https://store.minisforum.com
[09:18:51] <phrik> Title: MINISFORUM MS-R1 Workstation (at store.minisforum.com)
[09:19:08] <jelle> solskogen|M: how good is that radxa for compiling?
[09:19:17] <jelle> the orion that is :)
[09:19:25] <solskogen|M> It should work to bootstrap from the cross compiler - into a very minimal system that can boot on Aarch64. and continue from there.
[09:19:56] <solskogen|M> jelle: It's a hell-of a lot faster than the Pi, that's for sure. But we're using AWS to do that.
[09:20:07] <jelle> brrrr :D
[09:20:07] <solskogen|M> building the packages, I mean.
[09:22:06] <solskogen|M> jelle: That's the same machine as the Orion
[09:22:25] <jelle> solskogen|M: yup
[09:22:35] <jelle> well entirely same chip?
[09:23:40] <Antiz> jelle: BTW, do you from where the Arch (x86_64) toolchain was historically boostrapped?
[09:23:41] <solskogen|M> for all practical purposes, yes.
[09:23:53] <jelle> Antiz: no, before my time.
[09:24:00] <jelle> it was andyrt who did that afaik
[09:24:22] <Antiz> Ah okay. Allan did some teasing around it but did not gave the actual answer :P
[09:24:40] <Antiz> I'm curious
[09:24:41] <solskogen|M> Arch for 64bit was a port for quite some time before it became official.
[09:25:04] <Antiz> Was it?
[09:25:26] <Antiz> I thought the 32bit architecture was, not the other way around
[09:25:30] <Antiz> But I could be wrong
[09:25:42] <jelle> solskogen|M: I think so yes
[09:27:18] <jelle> oh interesting the Radxa Orion O6N is 180 euros excluding shipping /taxes
[09:28:24] <solskogen|M> Go for it!
[09:28:45] <jelle> idunno, the orion reviews seemed mixed :p
[09:29:07] <solskogen|M> It's ARM. ofc it is.
[09:29:42] <jelle> well mostly firmware issues
[09:29:55] <jelle> from https://www.jeffgeerling.com
[09:29:56] <phrik> Title: Radxa Orion O6 brings Arm to the midrange PC | Jeff Geerling (at www.jeffgeerling.com)
[09:29:56] <solskogen|M> Many people argue about the best ARM SBC. And my answer will, for the foreseeable future, be Raspberry Pi. Not because the hardware is the best, but it's the best supported one.
[09:30:19] <jelle> but that ain't even true :P
[09:31:43] <jelle> you are correct if you use the rpi kernel
[09:32:17] <solskogen|M> and the community
[09:32:27] <solskogen|M> none of the other SBCs have that.
[09:33:00] <jelle> well the sunxi community exists for sure, I was part of it :p
[09:33:26] <solskogen|M> I've thrown much money out the window for SBCs that on paper is better than the Pi, but they require a old custom linux image just to boot.
[09:34:21] <solskogen|M> with custom 5-6 year old uboot fork, with patches that never made it into mainline. and that don't work on newer uboot.
[09:35:28] <strit|M> solskogen|M: I know that feeling from the Manjaro ARM days. 😛
[09:36:04] <solskogen|M> Ah, so that's where I remember your name from!
[09:36:29] <jelle> that wasn't a problem back then I as upstreamed u-boot stuff :p
[09:39:35] <linkmauve> I remember that article about bootstrapping a distribution entirely from scratch, maybe that’s something you could be interested in? https://guix.gnu.org
[09:39:36] <phrik> Title: The Full-Source Bootstrap: Building from source all the way down — 2023 — Blog — GNU Guix (at guix.gnu.org)
[09:42:18] <linkmauve> > 10:19:55 solskogen|M> jelle: It's a hell-of a lot faster than the Pi, that's for sure. But we're using AWS to do that.
[09:42:19] <linkmauve> And then you talk about trust. ^^'
[09:43:22] <Antiz> solskogen|M: Re-reading my earlier message about the ALARM thingy, I get that my phrasing was a bit confusing sorry about that.
[09:43:26] <solskogen|M> I mean, we got a Aarch64 Linux installed on it (yeah, thats our project name) and use your own scripts to build packages
[09:44:14] <linkmauve> solskogen|M, Raspberry Pi is extremely bad at upstreaming, well, anything. Mainline kernel still lacks a huge lot of things on their platform, and neither they nor their community seem to have much interest in fixing that.
[09:44:22] <solskogen|M> Antiz: no worries :-)
[09:45:04] <Antiz> I'm aware that you're not depending on anything ALARM anymore. My point was to say that the fact that ALARM's (or whatever other project it was) toolchain / tooling was *once* involved *may* be an issue for us.
[09:45:27] <linkmauve> These are issues neither AllWinner nor Rockchip SoCs have, both have a community focused on making mainline work and not rely on downstream kernels. Rockchip even pays for upstreaming of various stuff.
[09:45:33] <solskogen|M> Antiz: For which I agree with you 100% :-)
[09:46:02] <Antiz> But I get how my phrasing could have sound confusing, as if current tarballs / packages were still directly depending on ALARM's tooling.
[09:46:08] <mkurz|M> Where are the PKGBUILD for all the packages in https://arch-linux-repo.drzee.net ? Do you just build the upstream arch packages?
[09:46:09] <phrik> Title: Content of extra - aarch64 (at arch-linux-repo.drzee.net)
[09:46:12] <Antiz> Which is not true, I'm aware ;)
[09:46:46] <Antiz> solskogen|M: :) Hopefully we'll find a way to bootstrap a tarball from scratch from Arch Linux at some point /D
[09:46:48] <Antiz> :D*
[09:46:57] <Antiz> s/bootstrap/create
[09:47:01] <solskogen|M> mkurz|M: most of them are upstream. if they don't we either create a MR for it - or keep them in our personal gitlab accounts, since we don't have a centralized place to put them.
[09:47:31] <mkurz|M> ok... where is the obsidian package coming from?
[09:47:42] <linkmauve> Btw, are you still building only for ARMv8.2+? It’s quite confusing to call the port aarch64 if it doesn’t work on all aarch64 CPUs.
[09:47:58] <solskogen|M> -any packages are just copied from Arch.
[09:48:05] <mkurz|M> Maybe you should centralize the custom PKGBUILD in https://gitlab.archlinux.org for now?
[09:48:06] <phrik> Title: Ports · GitLab (at gitlab.archlinux.org)
[09:48:25] <mkurz|M> until upstreamed?
[09:48:31] <solskogen|M> linkmauve: yes, we are. That MIGHT change.
[09:49:03] <mkurz|M> solskogen|M: obsidian is not an -any package
[09:49:05] <solskogen|M> mkurz|M: I'd like that very much, but the Arch devs don't agree (yet?)
[09:49:19] <artafinde|M> I was under the impression arch was started from LFS but I guess they used a compiler :p
[09:49:31] <linkmauve> Do you have a link to the issues you had about building with gcc 15 for ARMv8 and ARMv8.1?
[09:49:33] <solskogen|M> I can't remember obsidian particularly, so it's probably just the normal PKGBUILD from Arch
[09:50:21] <jelle> solskogen|M: https://gitlab.archlinux.org
[09:50:22] <phrik> Title: PKGBUILD · main · Arch Linux / Packaging / Packages / obsidian · GitLab (at gitlab.archlinux.org)
[09:50:52] <solskogen|M> linkmauve: qt6-webengine was the first one I encountered. And it takes a lot of time to compile.
[09:50:53] <jelle> state repo issue? :p
[09:51:01] <linkmauve> Ow, Chromium…
[09:51:19] <linkmauve> I don’t have any SBC with enough RAM to link Chromium.
[09:51:24] <Antiz> jelle: This is expected no?
[09:51:41] <Antiz> Levente's mail specifically states to not touch arch array for now
[09:51:45] <jelle> Antiz: o? yes its proprietary stuff
[09:51:48] <jelle> wdym?
[09:52:04] <solskogen|M> jelle: ah, it's a binary package. Then it won't work :) I just packaging them blindly.
[09:52:08] <mkurz|M> I highly doubt that obsidian is build from the upstream arch PKGBUILD - I am building obsidian myself for now and you have to modify the PKGBUILD to make it work
[09:52:11] <Antiz> Ah it's proprietary? My bad then
[09:52:17] <jelle> solskogen|M: it is binary yes sadly packaged :(
[09:52:32] <Antiz> I didn't know it was a pre-compiled binary, my bad forget it
[09:53:29] <jelle> [non-free]!
[09:53:33] <Antiz> Hopefully we don't have much of those 🤞
[09:53:37] <Antiz> Discord is another one
[09:53:58] <strit|M> I also assume Steam is one?
[09:54:37] <Antiz> Yep
[09:55:22] <mkurz|M> here is what needs to be done to make obsidian work on aarch64:
[09:55:23] <mkurz|M> https://gitlab.archlinux.org
[09:55:23] <mkurz|M> using this modified PKGBUILD since 1 year now
[09:55:24] <phrik> Title: main to aarch64 · Matthias Kurz / obsidian · GitLab (at gitlab.archlinux.org)
[09:55:57] <strit|M> Maybe they have aarch64 specific binaries we can get with modifying the PKGBUILD.
[09:56:10] <mkurz|M> strit|M: yes, see my last messasge
[09:56:14] <mkurz|M> that is what I am doing
[09:56:18] <Antiz> mkurz|M: Yes that seems very much expected
[09:56:28] <strit|M> mkurz|M: I was talking about the nonfree stuff ion general.
[09:56:38] <mkurz|M> should I PR that against the upstream arch package?
[09:56:50] <mkurz|M> will they accept that?
[09:57:48] <Antiz> mkurz|M: The actual addition of 'aarch64' in the Arch array is debatable (regarding the scope defined in https://lists.archlinux.org)
[09:57:55] <Antiz> But the rest should technically be okay IMO
[10:15:06] <mkurz|M> Here we go: https://gitlab.archlinux.org
[10:15:08] <phrik> Title: Support aarch64 architecture (!5) · Merge requests · Arch Linux / Packaging / Packages / obsidian · GitLab (at gitlab.archlinux.org)
[10:55:06] <Antiz> mkurz|M: Thanks 🤗 I made some comments / suggestions
[11:20:39] -!- drathir_tor has quit [Ping timeout: 272 seconds]
[11:43:49] -!- nl6720 has quit []
[11:44:56] -!- nl6720 has joined #archlinux-ports
[11:58:20] -!- nl6720 has quit []
[11:59:12] -!- nl6720 has joined #archlinux-ports
[12:04:22] -!- nl6720 has quit []
[12:05:14] -!- nl6720 has joined #archlinux-ports
[12:33:35] -!- marmis has quit [Quit: Bye!]
[12:35:22] -!- marmis has joined #archlinux-ports
[14:09:57] -!- nl6720 has quit []
[14:10:52] -!- nl6720 has joined #archlinux-ports
[15:06:41] -!- drathir_tor has joined #archlinux-ports
[17:28:02] -!- drathir_tor has quit [Remote host closed the connection]
[20:51:49] <solskogen|M> finally aarch64 is up to date after the icu upgrade...
[21:08:18] <mkurz|M> <solskogen|M> "finally aarch64 is up to date..." <- You mean Arch Linux ARM? It's not up-to-date - chromium still wasn't updated since January
[21:08:41] <solskogen|M> I mean our unofficial Aarch64 Linux project :-)
[21:09:01] <solskogen|M> we've got newer packages than ALARM. And more packages.
[21:20:28] -!- marmis has quit [Quit: Bye!]
[21:22:27] -!- marmis has joined #archlinux-ports
[21:51:43] -!- marmis5 has joined #archlinux-ports
[21:53:24] -!- marmis has quit [Ping timeout: 240 seconds]
[21:53:25] marmis5 is now known as marmis
[23:10:11] -!- titus_livius has joined #archlinux-ports
[23:26:39] <noahimesaka1873|> New Steam Frame has been announced and they're using Snapdragon 8 Gen 3 with Arch-based SteamOS
[23:26:44] <noahimesaka1873|> ...what?!
[23:26:48] <noahimesaka1873|> how?
[23:27:01] <noahimesaka1873|> there's no official Arch for aarch64?!
[23:27:39] -!- lynxy has joined #archlinux-ports
[23:34:43] <solskogen|M> wow!
[23:49:09] <noahimesaka1873|> so is gonna valve fund alarm, arch ports or what?!?!??
[23:49:24] <noahimesaka1873|> the most shocking announcement ever
[23:55:22] <lynxy> is the history for his channel logged anywhere?
[23:55:26] <lynxy> s/his/this
[23:59:54] <noahimesaka1873|> dunno, but on matrix I can see past chats