#archlinux-ports | Logs for 2026-03-25

Back
[00:42:45] -!- linkmauve has parted #archlinux-ports
[00:51:02] -!- linkmauve has joined #archlinux-ports
[04:15:54] -!- hcmb_ has joined #archlinux-ports
[04:15:54] hcmb is now known as Guest9535
[04:15:54] hcmb_ is now known as hcmb
[04:16:09] -!- Guest9535 has quit [Ping timeout: 248 seconds]
[06:06:18] -!- solsTiCe3 has joined #archlinux-ports
[06:08:49] -!- solsTiCe has quit [Ping timeout: 265 seconds]
[06:08:49] solsTiCe3 is now known as solsTiCe
[06:12:29] -!- drathir_tor has quit [Remote host closed the connection]
[06:12:47] -!- drathir_tor has joined #archlinux-ports
[06:18:28] -!- greyltc has quit [Ping timeout: 244 seconds]
[06:21:30] -!- greyltc has joined #archlinux-ports
[06:54:14] -!- solsTiCe7 has joined #archlinux-ports
[06:56:26] -!- solsTiCe has quit [Ping timeout: 256 seconds]
[06:56:27] solsTiCe7 is now known as solsTiCe
[08:59:52] <linkmauve> Hi, why is gcc four times as big as on amd64?
[09:00:03] <linkmauve> 808 MiB installed.
[09:03:16] <solskogen|M> Because I don't split it up in a million pieces.
[09:04:49] <solskogen|M> the pkgbuild for aarch64 has only two packages. gcc and gcc-libs.
[09:05:53] <linkmauve> Do you plan on diverging from ArchLinux for some packages?
[09:07:11] <solskogen|M> Not unless I have to.
[09:08:30] <solskogen|M> gcc is the only package where I have done something completely different compared to x86_64.
[09:09:29] <linkmauve> Wouldn’t that cause issues for acceptance with ArchLinux eventually?
[09:10:12] <solskogen|M> Probably, but it will require a big rewrite of the gcc PKGBUILD.
[09:10:27] <solskogen|M> (aarch64 doesn't support multilib)
[09:10:51] <linkmauve> Multilib is to support both AArch32 and AArch64 in the same gcc?
[09:10:59] <linkmauve> With -m32 and such?
[09:11:14] <solskogen|M> yes - even the concept of lib32 doesn't exist on aarch64.
[09:12:21] <linkmauve> I guess I’ll continue having an armv7h ALARM subvolume then. :)
[09:12:24] <solskogen|M> I'm not saying it's not possible to rewrite the upstream PKGBUILD for gcc, but I haven't found the time to do that yet. And quite frankly, I don't care that much.
[09:12:42] <linkmauve> I mostly use that to build packages for my ARMv7 boards.
[09:13:04] <linkmauve> What is the status of integrating this port into ArchLinux proper, btw?
[09:13:07] <solskogen|M> supporting 32bit was never the scope for us anyways.
[09:13:16] <linkmauve> I know.
[09:13:59] <solskogen|M> As of now, I don't know. I keep us up to date with the packages.
[09:14:47] <solskogen|M> I'm also in the process of trying to figure out a way to bootstrap our port from another aarch64 linux distribution.
[09:16:51] <solskogen|M> which means a minimal LFS system that can compile pacman
[09:17:41] <linkmauve> Nice!
[09:23:56] <solskogen|M> That's not what I'm looking for at all. The idea is that anyone should be able to bootstrap and get the same results.
[09:24:24] <solskogen|M> I'm not even sure if that is possible with upstream Arch Linux as of now, so it's a huge task.
[09:29:27] <solskogen|M> But if anyone want to try to rewrite the PKGBUILD for gcc so that works on both aarch64 and x86_64 (and hopefully others as well) - please go ahead!
[09:30:23] <solskogen|M> IMHO the current one is over-engineered. It works, but over-engineered.
[09:30:57] <solskogen|M> I'm so old that I remember a time when gcc was only one package :-)
[14:05:44] -!- rennod has quit [Remote host closed the connection]
[14:07:23] -!- rennod has joined #archlinux-ports
[16:02:53] -!- yjun has quit [Remote host closed the connection]
[16:30:08] <greyltc> solskogen|M: have you looked much at systemd's mkosi?
[16:30:53] <greyltc> I've managed to get that bootstrapping alarm images
[16:32:41] <greyltc> I'm now starting to look at what needs to be changed to get it working with Arch's aarch64 port
[16:34:12] <solskogen|M> No, I haven't. I don't even know what it is :-)
[16:34:40] <greyltc> https://mkosi.systemd.io
[16:34:42] <phrik> Title: mkosi — Build Bespoke OS Images (at mkosi.systemd.io)
[16:34:44] <greyltc> it's pretty good
[16:35:28] <solskogen|M> Ah, for images. I made a custom script instead for that.
[16:36:12] <solskogen|M> With the reasoning that we should create a image that can either just be put on a usb or sdcard, and be used right away - or to be used as a installation medium.
[16:36:52] <greyltc> nice. what hardware are you testing your images on?
[16:37:51] <greyltc> and is your image gen script somewhere I can have a look at it?
[16:38:49] <linkmauve> Speaking of hardware testing, I’ve had great success running your port on an ODROID-M1, a ROCK-5B, and at Oracle Cloud. :)
[16:38:52] <solskogen|M> I don't think I published it anywhere (we haven't used it either)
[16:38:52] <solskogen|M> The problem is that we need two images, one for generic aarch64 (uefi) and one for Pi5.
[16:39:10] <solskogen|M> There might be a workaround for that, but I haven't had the time.
[16:39:14] <linkmauve> And I just succeeded in running notepad.exe in Wine on said ROCK-5B!
[16:39:24] <linkmauve> Where could I contribute the changes to the wine package?
[16:39:26] <solskogen|M> linkmauve: Perfect. Do you use our kernel or something else?
[16:39:34] <linkmauve> I build mainline myself.
[16:40:03] <linkmauve> There are always newer features I want that aren’t part of the latest released kernel.
[16:40:22] <solskogen|M> linkmauve: https://gitlab.archlinux.org
[16:40:23] <phrik> Title: Arch Linux / Packaging / Packages / wine · GitLab (at gitlab.archlinux.org)
[16:40:38] <solskogen|M> linkmauve: any reason why you don't use ours?
[16:40:39] <linkmauve> Right now it’s rkvdec, the driver for the H.264 and HEVC hardware decoders on this board, for which I’m writing a Vulkan video shim layer.
[16:40:58] <linkmauve> It only got merged into 7.0.
[16:40:59] <solskogen|M> We're quite up to date (6.19.9)
[16:41:39] <solskogen|M> Ah, I see. I'd like to have -rc kernels as well in our repo, but I know next to nothing on how to properly configure a kernel.
[16:41:43] <linkmauve> Also I’m a kernel hacker, so I’d rather dogfood what I’m working on. :)
[16:41:57] <greyltc> I've got Pi5s for testing. Last I looked (maybe a few weeks ago) it seemed like there was a package missing that should puts some blobs into /boot that i thought were needed to boot a pi5
[16:42:06] <solskogen|M> I'm just happy bschnei keeps our kernel up to date - but I know he would be happy if anyone could provide him with a "better" config.
[16:42:08] <linkmauve> solskogen|M, don’t you already provide one? You do the same, except on a different commit.
[16:42:42] <solskogen|M> I haven't looked at running mainline on Pi5, but we have rpi5 kernels in our repo.
[16:42:44] <linkmauve> And if the defconfig doesn’t work properly, I’d recommend getting in touch with Linux to fix it.
[16:43:13] <linkmauve> I almost exclusively run mainline on all of my computers. :)
[16:43:13] <solskogen|M> If you have any suggestions: https://gitlab.archlinux.org
[16:43:15] <phrik> Title: Files · aarch64 · Benjamin Schneider / linux · GitLab (at gitlab.archlinux.org)
[16:44:28] <solskogen|M> I'd like that as well
[16:47:56] <linkmauve> > # CONFIG_DRM_ROCKCHIP is not set
[16:47:56] <linkmauve> That’d be needed to display stuff on my two boards.
[16:48:12] <linkmauve> I could test your kernel at some point, and point out things missing.
[16:48:20] <linkmauve> I’m surprised though, that one should be part of the defconfig.
[16:49:35] <linkmauve> CONFIG_ARCH_APPLE also surprisingly you didn’t enable that, it’s required if you want to run on a Mac.
[16:51:37] <bschnei> linkmauve: check out this MR for some context: https://gitlab.archlinux.org
[16:51:38] <phrik> Title: Draft: aarch64 support (!9) · Merge requests · Arch Linux / Packaging / Packages / linux · GitLab (at gitlab.archlinux.org)
[16:53:01] <bschnei> if you make olddefconfig using the x86_64 config no platforms are enabled at all. the kernel will pretty much only work on a VM--which happens to be where most packaging work gets done due to the resources needed
[16:54:11] <bschnei> instead of just switching everything on blindly in the hopes that devices I don't own will work, I'd prefer to keep things fast and light and turn on what users need
[16:55:45] <bschnei> there's been a couple of contributions already which have been great. We welcome anyone who actually owns a device and wants to help us refine the kernel config to bring support to those devices and update the list here accordingly: https://ports.archlinux.page
[16:55:46] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[17:00:21] <linkmauve> Ok, I’ll see what I’m missing from your config for only my two Rockchip boards, and report back. :)
[17:03:16] <bschnei> awesome! thank you!!
[17:03:50] <bschnei> greyltc: the linux-rpi5 package we maintain should install what's needed to /boot https://github.com let us know if you are having problems
[17:03:51] <phrik> Title: linux-rpi5/PKGBUILD at main · bschnei/linux-rpi5 · GitHub (at github.com)
[17:04:12] <linkmauve> These are my only two ARMv8.2 boards, everything else I have is either ARMv8, ARMv7 or ARMv6.
[17:04:28] <linkmauve> But for ARMv8 and ARMv7 I can continue using ALARM.
[17:06:58] <greyltc> bschnei: maybe I missed it when I was looking, but I didn't see the start*.elf files anywhere
[17:07:01] <greyltc> https://www.raspberrypi.com
[17:08:51] <greyltc> I've yet to actually try to boot from vanilla arch ports, so I'm likely mistaken somehow
[17:21:15] <greyltc> These files are from https://github.com and come with this licence: https://github.com
[17:21:16] <phrik> Title: GitHub - raspberrypi/firmware: This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. · GitHub (at github.com)
[17:21:38] <bschnei> linkmauve: I do a very poor job of trying to maintain some v8 packages. I can't recommend using them on anything you need stability/reliability and there are a lot missing but if you wanted to experiment, I can send you the repo. v7 and below are likely to be out of scope given the current Ports RFC draws a line at 64-bit
[17:21:39] <greyltc> I had wondered if there was some licencing issue that explains why I didn't see them
[17:22:15] <bschnei> greyltc: I don't think those files are used by the pi5
[17:22:27] <linkmauve> Oh so ARMv8.2 isn’t the end goal, you might want to support ARMv8 as well?
[17:23:10] <bschnei> RPi has a single "firmware" repo that they use to try to support ALL of their devices. I stripped out all the stuff that is not pi5 related from our package which is why it is linux-rpi5 and not linux-rpi :)
[17:23:40] <greyltc> bschnei: great. hopefully they're just vestigial from rpi(x<5) days
[17:24:09] <bschnei> linkmauve: that depends entirely on whether we get enough people that want v8 :)
[17:24:49] <greyltc> I intend to do some proper testing with my hardware this week
[17:26:02] <linkmauve> I do, being able to run proper ArchLinux on my phone would be great. :)
[17:26:19] <linkmauve> But I also recognize the performances improvements of running a full ARMv8.2 userland.
[17:26:41] <bschnei> See also: https://gitlab.archlinux.org
[17:26:42] <phrik> Title: Determine which instruction set to support (#6) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[17:30:39] <bschnei> I have two Marvell Armada 3720s which is a v8 device I use as a router. I was thinking at some point I'd upgrade and that would probably happen before I have the time/energy to contribute to supporting v8, but given some recent developments (https://docs.fcc.gov/public/attachments/DOC-420034A1.pdf) I might be doing everything I can to keep my devices alive! :)
[17:31:49] <linkmauve> Keeping existing devices working is a noble goal on its own. :)
[18:01:03] -!- gromit has quit [Quit: ZNC 1.10.1+docker-git--rc11.10.x-znc-1.10.0-12-gee54fb12 - https://znc.in]
[18:02:03] -!- gromit has joined #archlinux-ports
[18:07:46] -!- marmis has quit [Ping timeout: 276 seconds]
[18:08:28] -!- drathir_tor has quit [Remote host closed the connection]
[18:14:02] -!- marmis has joined #archlinux-ports
[18:21:51] -!- drathir_tor has joined #archlinux-ports
[20:13:15] -!- hcmb has quit [Remote host closed the connection]
[20:14:16] -!- hcmb has joined #archlinux-ports
[23:10:16] -!- titus_livius has joined #archlinux-ports
[23:34:49] -!- coherence42 has quit [Read error: Connection reset by peer]
[23:34:54] -!- cjc7373 has joined #archlinux-ports