#archlinux-ports | Logs for 2025-09-03

Back
[04:53:19] -!- drathir_tor has quit [Remote host closed the connection]
[04:53:40] -!- drathir_tor has joined #archlinux-ports
[05:26:01] <Solskogen> bschnei: yes, and I doubt Gentoo has patches for a video codec from intel to work on aarch64 :-)
[05:42:54] <bschnei> lol ya if nobody can/wants to build it for aarch64 then there's probably a good reason
[06:23:20] -!- titus_livius has joined #archlinux-ports
[06:45:42] <DrZee> fyi .... repos are restricted now we have [any] which essentially is a copy of all packages marked as any in the arch x86 repos the signing files are also copied 1:1 [release] all packages compiled on ARM based on x86 PKGBUILD with modification where necessary signature files are generated by our repo system with a "dummy" pgp key (not cross signed) for testing [staging] contains new
[06:45:42] <DrZee> builds when we are rebuilding or building after version upgrade uses the same signing files as [release] .... public key found at https://arch-linux-repo.drzee.net would appreciate those playing around to enable signature verification in pacman and let me know any problems ... we currently don't sign the database but that can easily be added.
[06:46:16] <DrZee> repos are restructured not restricted... stupid auto correct on my phone
[09:05:32] -!- nl6720 has quit []
[09:06:19] <gromit> DrZee: do the databases not get cached? It seems like pacman redownloads them every time
[09:07:16] -!- nl6720 has joined #archlinux-ports
[09:21:15] <DrZee> gromit: how does pacman decide when you do a pacman -Sy if the db needs to be downloaded or the cached local version is ok? A http HEAD request?
[09:29:30] <DrZee> The way it's implemented may make pacman think it needs to redownload. IMHO not a big deal .... but if that's not like that for everyone I just need to understand how pacman makes the determination and then provide the right answer ...
[09:30:28] * nl6720 assumes it uses the If-Modified-Since header
[12:31:10] -!- Wkiktor has joined #archlinux-ports
[13:58:43] -!- Wkiktor has quit [Quit: Leaving]
[14:21:10] -!- thereal-gsky has joined #archlinux-ports
[15:23:13] <Solskogen> hi, thereal-gsky !
[15:24:07] <Solskogen> gromit: Can you create an account in gitlab for thereal-gsky? :-)
[15:31:15] <Solskogen> everyone: say hi to thereal-gsky!
[15:36:58] <Solskogen> DrZee, bschnei and me started the thing, and from Arch Linux side we got a lot of help from gromit, Antiz, anthraxx|M, and dvzrv
[15:37:06] <bschnei> welcome!!
[15:37:49] <Solskogen> https://md.archlinux.org
[15:37:50] <phrik> Title: aarch64-2025-08-28 - HedgeDoc (at md.archlinux.org)
[15:42:09] <Solskogen> I'm off to a school meeting. Back in a few hours.
[15:46:10] <bschnei> More useful context: https://lists.archlinux.org
[15:46:11] <phrik> Title: First step for non-x86_64 contributions - Arch-dev-public - lists.archlinux.org (at lists.archlinux.org)
[15:55:59] <Antiz> thereal-gsky: Welcome 🤗
[17:37:41] <thereal-gsky> hey all, thanks, glad others are picking up the aarch64 torch
[17:39:43] <thereal-gsky> I will see what you guys have and look for areas to lean in. My primary interest is in the RPi SoCs
[17:45:02] <thereal-gsky> I am more familiar with github than with gitlab but is this work hosted at gitlab.archlinux.org? I alerady have an account there for bug submissions.
[17:46:38] <jelle> thereal-gsky: arch repository are hosted on gitlab.archlinux.org yes
[17:48:05] <Antiz> thereal-gsky: Currently the main part to contribute to verify if architecture dependent packages correctly build as-is on aarch64. If they do not, one can investigate why and provide a fix via a merge request (given said fix is reasonable and doesn't go against x86_64, which is still the only officially supported architecture as of now)
[17:49:19] <Antiz> thereal-gsky: There are details about that in this email: https://lists.archlinux.org
[17:49:20] <phrik> Title: First step for non-x86_64 contributions - Arch-dev-public - lists.archlinux.org (at lists.archlinux.org)
[17:53:49] <thereal-gsky> I will check out that doc
[17:53:58] <Antiz> thereal-gsky: Solskogen, bschnei and DrZee already have some fairly advanced work done on their side. They already have a repo with all the packages they successfully built for aarch64 so far: https://arch-linux-repo.drzee.net & https://arch-linux-repo.drzee.net
[17:53:59] <phrik> Title: Content of any - aarch64 (at arch-linux-repo.drzee.net)
[17:55:14] <Antiz> This repo can already be used to bootstrap / run an Arch aarch64 system. Although note that this isn't official yet, of course. I'll let them tell you more about all of this.
[17:56:34] <Antiz> thereal-gsky: Lastly, we also had a meeting together (Solskogen, bschnei, DrZee and gromit, anthraxx|M, dvzrv & myself on the Arch Linux side) to discuss the course of action & the current difficulties. Notes for this meeting are available here: https://md.archlinux.org
[17:56:36] <phrik> Title: aarch64-2025-08-28 - HedgeDoc (at md.archlinux.org)
[17:58:10] <Antiz> This should give you a broad picture of where the effort is at currently. Again, the main goal for now is to identify packages that do not build as-is on aarch64 and provide fixes for them via a merge request in the scope / limits defined in the mail I linked you earlier.
[17:58:43] <Antiz> Of course, feel free to ask questions if anything :)
[18:03:37] <thereal-gsky> I will review and post here, thanks. What about SoC specific stuff akin to what I am building for Arch ARM (kodi-rpi, linux-rpi, vlc-rpi, etc.?)
[18:03:47] <bschnei> To add, we don't have a centralized place for our work. Forks of packages are in mine and Solskogen's "spaces"
[18:03:55] <thereal-gsky> not stage appropriate yet?
[18:04:06] <bschnei> https://gitlab.archlinux.org
[18:04:07] <phrik> Title: Benjamin Schneider · GitLab (at gitlab.archlinux.org)
[18:04:09] <jelle> thereal-gsky: why is vlc-rpi even a thing
[18:04:22] <bschnei> https://gitlab.archlinux.org
[18:04:22] <phrik> Title: Christer Solskogen · GitLab (at gitlab.archlinux.org)
[18:04:32] <thereal-gsky> hw-accelerated video decoding
[18:04:49] <anthraxx|M> thereal-gsky: we're not really aiming for arch specific packages, maybe last resort thing. But it's all supposed to be general.
[18:05:40] <thereal-gsky> thing with RPi specifically is the RPi Foundation forked the kernel as you may know and provide hardware-specific stuff therein
[18:05:53] <thereal-gsky> main thing is hw video decoding
[18:06:22] <anthraxx|M> We are very far from that being our current problem 😅
[18:06:30] <thereal-gsky> :D
[18:06:36] <jelle> thereal-gsky: the RPI foundation upstreams this no?
[18:06:41] <thereal-gsky> eventually
[18:06:46] <jelle> if not, I don't see any reason to do them any favours
[18:06:48] <thereal-gsky> but development is very active
[18:07:06] <bschnei> I'm a fan of allowing that kind of work in the AUR :) but agree with anthraxx...there are so many very "basic" packages that need a little love.
[18:08:06] <thereal-gsky> I can think of a decent chunk of RPi users who will want the video decoding. Kodi runs nicely with some patches to provide this but only in combo with the RPiF kernel
[18:08:16] <thereal-gsky> this is what I keep running on Arch ARM for example
[18:08:53] <bschnei> To confirm, this is a Pi5, right? Not a Pi4?
[18:09:03] <thereal-gsky> both do it
[18:09:12] <thereal-gsky> RPi3 and even 2 can as well
[18:09:16] <thereal-gsky> just more limited
[18:09:37] <thereal-gsky> 5 can do HEVC at full 4k@60 fps
[18:09:47] <jelle> https://www.phoronix.com not yet
[18:10:46] <thereal-gsky> I saw that a few months back
[18:11:04] <thereal-gsky> when it is mainlined, will still need a patched ffmpeg to use it
[18:11:08] <Antiz> thereal-gsky: Yeah, we're not yet at the stage to think about RPI specifically. Although, just as a side note, I think the target that bschnei, Solskogen and DrZee are reaching for is ARMV8.2
[18:11:22] <Antiz> thereal-gsky: Which basically leaves RPI older than RPI5 out of the equation
[18:11:36] <thereal-gsky> OK
[18:11:41] <bschnei> Ya that's why I was asking. The absence of LSE support prior to ARMv8.2 poses some challenges.
[18:11:59] <thereal-gsky> yes, all these devices are a mixed bag for sure
[18:12:14] <jelle> bschnei: ought to be solveable
[18:12:28] <thereal-gsky> does the project have a toolchain out there for cross-compiling?
[18:13:20] <bschnei> jelle: I've started notes on the subject: https://github.com
[18:13:22] <phrik> Title: GitHub - bschnei/arch_a64: Arch Linux packaging automation for aarch64 architecture (at github.com)
[18:13:26] <jelle> thereal-gsky: afaik no cross compiling is hapening, thankfully
[18:14:04] <bschnei> DrZee found this note over at Qt: https://doc.qt.io
[18:14:05] <phrik> Title: Supported Platforms | Qt 6.8 (at doc.qt.io)
[18:16:33] <jelle> bschnei: that doesn't say much about aarch64
[18:16:44] <jelle> or am I missing something
[18:17:07] -!- thereal-gsky has quit [Quit: WeeChat 4.7.1]
[18:17:30] <bschnei> "Note: For Linux on Arm on desktops, we use Raspberry Pi 5 with 8GB RAM and Ubuntu 24.04 as a reference platform."
[18:17:37] <jelle> yes
[18:17:59] <jelle> doesnt say the rpi 4 doesn't work :)
[18:18:35] <bschnei> Correct, but it suggests upstream is not currently interested in helping it build for ARMv8
[18:19:48] <jelle> https://koji.fedoraproject.org builds with gcc 15
[18:19:49] <phrik> Title: qt6-qtwebengine-6.9.2-1.eln151.aarch64 | RPM Info | koji (at koji.fedoraproject.org)
[18:20:05] <jelle> and fedora supports older rpi's so it isn't aarch64 8.2
[18:20:48] <jelle> https://src.fedoraproject.org
[18:20:49] <phrik> Title: Tree - rpms/qt6-qtwebengine - src.fedoraproject.org (at src.fedoraproject.org)
[18:21:09] -!- thereal-gsky has joined #archlinux-ports
[18:21:14] <jelle> if you still have the build log, check if it is https://bugreports.qt.io
[18:21:22] -!- thereal-gsky has quit [Client Quit]
[18:21:36] -!- thereal-gsky has joined #archlinux-ports
[18:22:01] <anthraxx|M> <thereal-gsky> "I can think of a decent chunk of..." <- How is it going to upstream these patches in Kodi/VLC?
[18:22:19] <bschnei> That's encouraging :) The way I see it is: when/if people show up that want to make it work, then that's when it'll become a thing. Solskogen pushed for broader coverage of packages but to get there he had to target v8.2. I just have a small router. I have no need for Qt. So for now it remains outstanding issue that isn't high on either mine, Solskogen's or DrZee's lists
[18:22:27] <thereal-gsky> no idea what a plan is for upstreaming
[18:23:08] <thereal-gsky> I am glad enough to play on the bleed edge and package for others
[18:23:18] <jelle> bschnei: I have no idea what arch users would want, but I reckon headless would be quite a bit
[18:23:51] <thereal-gsky> for routing tasks, it is REALLY tough to beat OpenWrt
[18:24:13] <thereal-gsky> I had a RPi powered router firewall for ages before getting a mini PC
[18:24:23] <thereal-gsky> in all cases running OpenWrt
[18:24:47] <thereal-gsky> I get the best of both worlds by running lxc on OpenWrt with Arch x86_64 in the containers
[18:26:16] <bschnei> I was long-time DD-WRT user. I know it's not the same, but I didn't have a great experience admining it. No disagreement on performance, but I'm on Starlink out in the woods. A Cortex A-53 is probably never going to a bottleneck for me :D
[18:26:35] <thereal-gsky> ha!
[18:26:50] <thereal-gsky> I too used DD-WRT for years (dumb AP)
[18:26:56] <thereal-gsky> and Tomato USB before that
[18:27:12] <thereal-gsky> OpenWrt is _the_ distro for embedded
[18:27:35] <bschnei> I am waiting though for someone to come up with something better than this ESPRESSObin. I'm watching https://mono.si closely. Overkill for my needs but has a v8.2 chipset
[18:27:36] <phrik> Title: Gateway development kit preorders (at mono.si)
[18:27:54] <thereal-gsky> you can't go wrong with x86 my friend
[18:27:56] <anthraxx|M> <thereal-gsky> "no idea what a plan is for..." <- That's where we'd want help as well, people driving individual efforts or keep track of upstreaming required software patches, as Arch we still try to have very very little custom patches 😊
[18:28:20] <thereal-gsky> I am using this currently: https://www.ikoolcore.com
[18:28:21] <phrik> Title: R2 Max: 10 GbE Firewall & Virtualization Host for Pro Users – iKOOLCORE (at www.ikoolcore.com)
[18:28:29] <bschnei> lol gromit said the same thing. but then...where's the fun in everything working just fine all the time :D
[18:29:09] <bschnei> ooh that looks cool!
[18:29:27] <thereal-gsky> Think I paid 200 USD for the N150 version on sale
[18:29:52] <bschnei> My girlfriend said I can't buy anymore routers :/
[18:29:53] <thereal-gsky> $50 more for RAM and I had an older SSD for data
[18:30:03] <thereal-gsky> ahhaahhaah
[18:31:22] <bschnei> Solskogen managed to get one of these: https://radxa.com it has two ethernet ports but it's hard to find and expensive for now
[18:31:23] <phrik> Title: Orion O6 (at radxa.com)
[18:32:26] <DrZee> thereal-gsky: we all came together from slightly different sides .... i for one primarily concern my self with getting a good base for ARM server (AWS Graviton line ... while this is a hobby project and notvrelate to my day job .... I do work for AWS) currently I run servers on x86_64 Arch and even provide AMIs for it ... but ARM has 20% cheaper cost for same performance.... and I like to
[18:32:27] <DrZee> save. While it would be nice to run on RPi (i have a few older) the servers are my motivation. Ben is on the router angle and solskogen somewhere between.... but for all of us it was a problem that arch arm was suffering ....
[18:33:12] <DrZee> so here we are ....
[18:33:39] <thereal-gsky> I understand
[18:34:01] <thereal-gsky> my interest is more specific based on my own (maybe selfish) use cases
[18:34:14] <DrZee> we all are a little:)
[18:34:15] <thereal-gsky> happy to help
[18:34:21] <thereal-gsky> just not sure where I am best placed
[18:34:26] <Antiz> My interest is server on an RPI :P
[18:36:37] <thereal-gsky> it does that well
[18:37:29] <DrZee> but I think having a good stable base that builds a mainline kernel and packages similar to arch x86 and keeps these up to date at the same pace is the right foundation. then we can either open up AUR to host variants (for versions of PKGs that need some special fix) or have an experimental repo where these things reside. build a strong foundation first and the branch ... IMHO ... my 2
[18:37:29] <DrZee> cents
[18:38:00] <thereal-gsky> that sounds right
[18:38:44] <bschnei> thereal-gsky: small changes to PKGBUILDs if they are FTBFS on aarch64 is helpful. What you (and we bring) is that we are trying to build these things on a different architecture so we experience failures and hurdles that don't just affect aarch64 but possibly all non-x64 architectures. I think there's value in having that perspective and proposing changes where reasonable.
[18:40:07] <bschnei> Here's my latest example: https://gitlab.archlinux.org
[18:40:08] <phrik> Title: Fix build failure on aarch64 with LTO enabled (!1) · Merge requests · Arch Linux / Packaging / Packages / potrace · GitLab (at gitlab.archlinux.org)
[18:41:02] <DrZee> thereal-gsky: that being said I would like to pick you brain on te kernel config .... the current kernel while running great also on AWS hardware seems to miss something.... I can't figure out what the issue is, but have some hunch that its related to acpi interface or how ARM handles device overlay maybe you come across it ...
[18:41:32] <thereal-gsky> oh, that is a deep and scary rabbit hole
[18:42:02] <thereal-gsky> Kevin is real the expert with the kenrel, initicpio, and so forth
[18:42:03] <DrZee> thereal-gsky: well yes ... hence I need more braiiinsssss ....
[18:42:08] <thereal-gsky> :D
[18:42:25] <bschnei> DrZee: are you getting kernel errors/warnings on boot? Feel free to send them my way if so
[18:42:28] <thereal-gsky> have you guys reached out to him specifically to collab with the generic kernel/
[18:42:53] <thereal-gsky> I will grab the tarball for bootstrap and try it on a RPi4 or 5
[18:43:01] <thereal-gsky> happy to look initially at the kernel
[18:43:08] <thereal-gsky> but again, Kevin is the real expert
[18:43:51] <bschnei> I haven't yet because our kernel config is missing a lot of features and I need to start over again to keep a trail of what was changed when starting with the current Arch x64 kernel config.
[18:44:07] <bschnei> (and why it was changed)
[18:45:40] <DrZee> no warning... what happens is related to shutdown. when you sendt the shutdown command to the virtual host it technically (at least if i understand it correctly) sends a button press into acpi or similar that then triggers the kernel to shutdown grateful. It works on AWS own ARM linux (red hat derivative) and also perfectly on Arch x86 .... but not on ARM my suspicion is either some
[18:45:40] <DrZee> config not set in the kernel or a module not loaded that should ....
[18:46:47] <thereal-gsky> dumb question: did you start with the arm64 defconfig
[18:47:07] <DrZee> but comparing the kernel config just hurts main braiiinnn (mmm) .... and I can't find the needle
[18:47:12] <thereal-gsky> I have been keeping the Arch ARM mainline kernel up-to-date
[18:47:21] <thereal-gsky> looking at its config could be helpful
[18:47:52] <thereal-gsky> currently on 6.16 (linux-aarch64) and 6.17-rc4 (linux-aarch64-rc)
[18:48:26] <Antiz> root@archlinux-arm-ports ~# uname -a
[18:48:26] <Antiz> Linux archlinux-arm-ports 6.17.0-rc4-1-mainline #2 SMP PREEMPT_DYNAMIC Tue, 02 Sep 2025 15:06:54 +0000 aarch64 GNU/Linux
[18:48:44] <DrZee> I can try ... the current ALARM kernel I can not bootstrap on AWS ... I had my own PKGBILD and I can't remember if that one worked correctly.... I can try to bootstrap on that and see though
[18:48:56] <Antiz> I think gromit did some stuff too? 👆 😜
[18:49:25] <thereal-gsky> good deal, someone is using that kernel :D
[18:50:05] <bschnei> DrZee: that indeed sounds like a missing option but shouldn't be hard to find. thereal-gsky: no, started with Arch x64 config and have been switching things on as needed...most non-cloud devices will not work with it
[18:50:47] <thereal-gsky> so I never build one starting from another distros config... always from a defconfig then add to it
[18:51:15] <thereal-gsky> if you look a the PKGBUILD for linux-rpi, you will see one strategy to build on top of a defconfig base
[18:51:55] <DrZee> I think where we are right now with our ARM kernel is that we as Ben said used the config that sits in Arch x86 ... when u use that and run configure the Linux build system figures out that it's x86 and "converts" it to arm only applying default values to arm specific config and of course tossing x86 specific config ...
[18:51:58] <thereal-gsky> but again, that kernel is tracking the RPiF defaults to maintain latest-and-greatest features
[18:52:02] <bschnei> interesting. the intention was to try to make sure features (architecture agnostic options) were as similar to x64 as possible
[18:52:34] <thereal-gsky> again, different goals
[18:52:40] <thereal-gsky> different strategies
[18:52:56] <bschnei> ^ what DrZee said. if you run make olddefconfig and you feed it x64 config it maps it over fine, but literally all ARM Platforms will be disabled :D
[18:54:56] <bschnei> I've been trying to build the packages needed to build the kernel package before I come back to config. I'm close but getting stuck on python-sphinx...
[18:55:58] <jelle> issues bootstrapping?
[18:57:44] <bschnei> I'm not really sure. Failures always seem to be in checks(). The contribjsmath one was getting stuck in particular.
[18:58:05] <DrZee> hmm hadn't checked defconfig ... I think that can be the right tool once we have a base kernel that tracks the x86 kernel closely .... as Ben mentioned the idea was to have them be as identical as possible and then target Arm v8_2 ... just like arch x86 only target x86_64 ... and then ppl can make their own modification from there. but maybe I should throw defconfig against the most
[18:58:05] <DrZee> recent AWS Linux ARM kernel (Even though it's only 6.1) and see what comes up
[18:58:13] <jelle> bschnei: just rebuilding python-sphinx?
[18:59:36] <bschnei> Let me try that one right now and see what it does...
[19:03:11] <jelle> bschnei: building :-)
[19:03:14] <jelle> tests take a while
[19:03:36] -!- thereal-gsky has quit [Quit: WeeChat 4.7.1]
[19:05:40] <bschnei> it dies on test_latex_labels
[19:05:57] <jelle> bschnei: interesting not here
[19:06:12] <jelle> The built package (python-sphinx) is the one in the repo right now! python-sphinx-8.2.3-1-any.pkg.tar.zst
[19:08:20] <bschnei> https://0x0.st
[19:09:29] <bschnei> I think upstream has already merged a fix
[19:10:05] <bschnei> https://github.com
[19:10:07] <phrik> Title: Tests: change-in-output with docutils r10151 (0.22-rc) · Issue #13609 · sphinx-doc/sphinx · GitHub (at github.com)
[19:11:08] <bschnei> strange it doesn't fail on x64 though
[19:38:22] <bschnei> python-sphinxcontrib-jsmath does fail on both. upstream issue: https://github.com
[19:38:24] <phrik> Title: sphinxcontrib-jsmath test_disabled_when_equations_not_found fails with Sphinx 8.2.3 · Issue #13442 · sphinx-doc/sphinx · GitHub (at github.com)
[22:10:13] -!- titus_livius has joined #archlinux-ports
[22:40:28] -!- marmis1 has quit [Quit: Bye!]
[22:41:37] -!- marmis1 has joined #archlinux-ports
[22:43:17] -!- bschnei has quit [Read error: Connection reset by peer]
[22:43:30] -!- bschnei has joined #archlinux-ports
[23:23:22] -!- bschnei has quit [Remote host closed the connection]
[23:24:14] -!- bschnei has joined #archlinux-ports
[23:33:42] -!- bschnei has quit [Remote host closed the connection]
[23:35:40] -!- bschnei has joined #archlinux-ports
[23:51:06] -!- bschnei has quit [Remote host closed the connection]
[23:51:19] -!- bschnei has joined #archlinux-ports