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

Back
[01:31:52] -!- leanguedes has quit [Remote host closed the connection]
[01:32:08] -!- leanguedes has joined #archlinux-ports
[03:15:51] -!- hcmb_ has joined #archlinux-ports
[03:15:51] hcmb is now known as Guest4641
[03:15:51] -!- Guest4641 has quit [Killed (erbium.libera.chat (Nickname regained by services))]
[03:15:51] hcmb_ is now known as hcmb
[07:16:50] -!- nl6720 has quit []
[07:17:54] -!- nl6720 has joined #archlinux-ports
[08:19:38] -!- nl6720 has quit [Ping timeout: 268 seconds]
[08:19:44] -!- nl6720_ has joined #archlinux-ports
[08:19:44] nl6720_ is now known as nl6720
[08:23:24] -!- Charon77|PC has quit [Ping timeout: 253 seconds]
[08:27:43] -!- nl6720 has quit [Ping timeout: 255 seconds]
[08:28:01] -!- nl6720 has joined #archlinux-ports
[08:34:21] -!- nl6720 has quit []
[08:35:22] -!- nl6720 has joined #archlinux-ports
[09:53:39] -!- h|ignition has quit [*.net *.split]
[09:53:39] -!- drathir_tor has quit [*.net *.split]
[10:20:58] -!- filmroellchen has joined #archlinux-ports
[12:02:56] -!- _d4s has joined #archlinux-ports
[12:38:21] <linkmauve> bschnei, where do you host your ARMv8 repository again?
[12:57:37] -!- h|ignition has joined #archlinux-ports
[12:59:04] -!- h|ignition has quit [Remote host closed the connection]
[13:02:29] -!- h|ignition has joined #archlinux-ports
[13:03:33] -!- drathir_tor has joined #archlinux-ports
[13:23:47] -!- hch129070 has joined #archlinux-ports
[13:26:04] -!- hch12907 has quit [Ping timeout: 243 seconds]
[13:26:04] hch129070 is now known as hch12907
[14:54:55] -!- nl6720 has quit [Ping timeout: 258 seconds]
[14:54:59] -!- nl6720_ has joined #archlinux-ports
[14:54:59] nl6720_ is now known as nl6720
[14:59:18] -!- sproed has joined #archlinux-ports
[15:50:21] <sproed> Hello! Is there any provider of a premade aarch64 image to test on my Radxa Orion O6?
[15:52:26] <sproed> seems the ratio of missing packages has gotten pretty good going by the rfc page
[16:02:21] <clover|M> <naeemmalik|M> "archboot.com" <- I dont think thats arch ports though.
[16:04:49] <sproed> I suppose it might work to just boot that and edit the pacman.conf from there?
[16:06:02] <clover|M> You'd have to reinstall every package afterward if they were made for arch linux arm
[16:06:19] <sproed> I'd be fine with that
[16:16:50] <bschnei> linkmauve: https://arch.bens.haus
[16:16:52] <phrik> Title: Index of /repos/ (at arch.bens.haus)
[16:25:12] <solskogen|M> <naeemmalik|M> "archboot.com" <- https://github.com should work
[16:25:14] <phrik> Title: Release 2026.08.06 · solskogen/aarch64linux-image-maker · GitHub (at github.com)
[16:26:17] -!- sproed has quit [Ping timeout: 269 seconds]
[16:29:22] -!- sproed_ has joined #archlinux-ports
[16:30:12] <solskogen|M> that link was supposed to go to sproed_ :)
[16:30:32] <sproed_> I figured, thank you!
[16:30:42] <bschnei> sproed: you could try clover's ISO: https://codeberg.org
[16:30:44] <phrik> Title: Cookie monster! (at codeberg.org)
[16:31:09] <solskogen|M> bschnei: I've tested my images on a Orion :-)
[16:31:33] <bschnei> could also* sorry I missed solskogen's note. ISOs can be tricky because sometimes you need special options. ^ I would start with solskogen's given that he has same device :)
[16:32:32] <clover|M> bschnei, that is currently only for the qcom WoA laptops. in theory it could support more since tuki/stubble should work without hwids on u-boot platforms
[16:32:51] <clover|M> s/tuki/uki/
[16:33:21] <bschnei> got it. ya i'd be curious to see how much stubble solves the device support issue in general...
[16:33:22] <linkmauve> Ta. :)
[16:33:59] <bschnei> linkmauve: do you have a pi4? or what v8 device are you trying to use?
[16:36:39] <clover|M> bschnei yes, i will make a testing ISO soon that includes all arm64 dtbs, then it may possibly "just boot" on some rockchip/allwinner too
[16:38:39] <solskogen|M> my image only works with EFI
[16:42:10] <bschnei> clover: the linux-dtbs package we currently build only has dtbs for platforms that are enabled in the kernel config: https://gitlab.archlinux.org
[16:42:11] <phrik> Title: config.aarch64 · aarch64 · Benjamin Schneider / linux · GitLab (at gitlab.archlinux.org)
[16:42:19] <clover|M> can you say a bit more about the ARMv8 repos, whats the status of it? is it ready to use now?
[16:42:49] <clover|M> is there plans to move it to the s3 bucket?
[16:44:11] <solskogen|M> Yes, there are plans. But I don't know how far @drzee has come
[16:44:16] <bschnei> drzee has been working on that a lot lately. he an solskogen are wizards :)
[16:44:24] <solskogen|M> it will be announced here :)
[16:44:58] <clover|M> cool, i want to make an iso for my pinebook pro :)
[16:45:17] <bschnei> the repos on my site can be used if people are feeling brave. a "core" system is stable. i use them on a router. but that is a very tiny list of packages that are driven daily. i have no idea if the vast majority of packages work
[16:45:45] <bschnei> that's why i was a bit curious about whether linkmauve had a device that could actually maybe run a DE
[16:46:41] <bschnei> you can make v8 ISO's if you want from my packages. i have some here already: https://arch.bens.haus that I update manually from time to time
[16:46:42] <phrik> Title: Index of /iso/ (at arch.bens.haus)
[16:48:44] <clover|M> neat, i wonder if it boots on my pbp
[16:49:04] <bschnei> So our status with v8 right now is we'd like to try to support people who do want to do the work to support v8 devices, but none of myself, drzee or solskogen have personal motivations/reasons to work through the packages that need work to build on v8. I build ones that build easy and clean and if I find ones that have problems that affect ALL architectures, then I usually spend the time to make an MR.
[16:50:03] <bschnei> Yes, I do have my router that is v8 but--again--that's a very small number of core packages that are ultra stable. No need for complex graphics hardware features, etc.
[16:51:40] <clover|M> very cool to have a DIY router. nice job
[16:53:17] <bschnei> thx. it's been a journey. i started with what I thought was simple: update router kernel the same way I update my desktop kernel (with pacman). that was a couple years ago and my advice to most people that want to do something similar is: start with x64 hardware lol
[16:57:55] <linkmauve> bschnei, it was actually for a friend of mine, but I do have many devices which can run a DE but are only ARMv8, such as my PinePhone, my Nintendo Switch, and various Cortex-A53 boards.
[16:58:14] <linkmauve> I actually have more ARMv7 boards than ARMv8 so far, but they are starting to be very old.
[16:58:22] <linkmauve> Mostly AllWinner ones, A10 and A20.
[16:59:06] <linkmauve> I have no Broadcom board whatsoever, even though they seem to be very popular, I’ve always found other boards cheaper and better supported in mainline.
[17:00:32] <linkmauve> I’m still traveling atm, so I could only test stuff on my phone.
[17:00:57] <linkmauve> Do you have any mobile-oriented DE in there perhaps? Such as phosh, or catacomb?
[17:02:53] <bschnei> I don't have anything packaged that isn't in Arch outside of libpisp, pandoc-bin and shellcheck-bin (the latter two to avoid dealing with haskell)
[17:03:55] <bschnei> phosh exists
[17:04:01] <linkmauve> Ok, too bad then, I’ll test stuff when I’m back home then.
[17:04:22] <linkmauve> Oh, indeed it does!
[17:04:31] <bschnei> :) but no catacomb
[17:04:50] <linkmauve> Why does it depend on evince?!
[17:04:51] <clover|M> DanctNIX is also a thing, they specialize with arch linux on pinephones and other linux mobile devices
[17:05:09] <linkmauve> clover|M, Danct12 is present here. :)
[17:05:26] <linkmauve> But I think it’s still built on ALARM instead.
[17:06:25] <clover|M> i know they have arch ports builds for the pinetab 2 now
[17:06:57] <bschnei> I just checked and phosh installs (which means all dependencies also exist)
[17:07:47] <Danct12> clover|M: arch ports will be used wherever possible :)
[17:08:28] <bschnei> I'm aware of ~100 pkgbases that have packages that are dependncies of packages that are in the v8 repos that are missing. So there are going to be some packages that may not install, but I believe most of them are relatively niche packages. If anyone encounters that problem, help with fixing it is always welcome.
[17:10:45] <linkmauve> bschnei, could you upload the list somewhere?
[17:11:17] <bschnei> sure, give me a few
[17:14:36] <bschnei> https://arch.bens.haus in order of count of packages blocked (descending) though I wouldn't really read into that too much
[17:14:42] <solskogen|M> ARMv8.2-A is a bit more complete :-)
[17:15:28] <solskogen|M> ARMv8.2-A is only missing this: acpi_call-lts arch-audit-gtk boxxy bugstalker bumblebee critter discord dmd docker-machine dosemu dotnet-core-6.0 dtools dwarffortress e3 fasm fastflowlm framework-system fuseiso intel-lpmd intel-media-driver intel-media-sdk intel-npu-compiler intel-npu-driver intel-oneapi-toolkit intel-pti ipxe iucode-tool java-rxtx libsmbios libva-intel-driver libvpl-tools libx86 linux-hardened linux-lts linux-rt linux-rt-lts
[17:15:28] <solskogen|M> linux-zen mesa-amber mivisionx nomad-driver-containerd nvidia-cg-toolkit nvidia-open-lts occt oneccl openra primus primus_vk r8168-lts rocal rpp scratch shake smlnj squeak-vm teamspeak3-server tp_smapi-lts vbetool vpl-gpu-rt wine-mono xf86-input-vmmouse xf86-video-intel yabridge yate
[17:16:30] <bschnei> what? no drawrffortress?? :)
[17:17:17] <bschnei> that one builds/built (?) fine for v8....
[17:18:12] <solskogen|M> well, good luck trying to start it bschnei (look at the PKGBUILD)
[17:18:42] <clover|M> so missing about ~70 packages but a lot of them aren't important for arm like the intel / nvidia ones
[17:19:51] <bschnei> lol. i see
[17:29:00] <solskogen|M> clover|M: correct. most of them doesn't make sense on aarch64, so no biggie
[17:36:37] <linkmauve> bschnei, some packages are missing their .sig, for instance icu, glibc or systemd.
[17:45:30] <bschnei> ya. only -any- packages which are straight rsync from upstream are signed. nothing else is
[17:46:41] <bschnei> it's been on a to do list but because I'm only aware of me driving them daily... :)
[17:51:02] <linkmauve> Starting now I’m the second person driving it daily. :)
[17:51:02] -!- sproed_ has quit [Read error: Connection reset by peer]
[17:52:12] -!- sproed has joined #archlinux-ports
[17:53:22] <linkmauve> I’m dual-booting it on my phone, so hopefully it’ll be ready at some point for Danct12 to rebase their phone distribution on it.
[17:53:37] <bschnei> I was also kinda dragging my feet on it because drzee has been hard at work to figure out how we might support building both packages using the same ci/cd pipline infrastucture
[17:53:55] <bschnei> and v8.2 is all signed
[17:54:39] <linkmauve> Ow, mesa links to llvm-libs, I’ll have to build my own mesa with only lima then.
[17:54:45] <bschnei> good to know! I will try hard not to break things for you :)
[17:54:54] <linkmauve> Not loading LLVM dynamically saves 100 ms off every program start.
[17:55:11] <bschnei> interesting
[17:55:15] <linkmauve> Don’t worry about me, feel free to break things if it improves things overall.
[17:55:36] <linkmauve> I will complain if things break, so you know about it. :)
[17:57:30] <bschnei> i haven't done anything so bad (yet) that can't be solved by rebuilding a few packages. but because I avoid trying to have packages with version numbers that are "ahead" of x64, if I re-release with same pkgver pacman will complain and you have to pacman -Scc to clear your local cache
[18:00:27] <linkmauve> bschnei, I just successfully built sdl_image 1.2.12, with this patch: https://linkmauve.fr
[18:02:57] <bschnei> consider an MR. there is a todo for this very task but sdl_image didn't get picked up on that list: https://archlinux.org
[18:02:58] <phrik> Title: Arch Linux - Todo: Apply RISC-V autoreconf patches (at archlinux.org)
[18:03:06] <linkmauve> The same patch worked for sdl_net as well.
[18:03:13] <linkmauve> Ok, will do.
[18:04:15] <bschnei> ya this is actually a lot of what is going on. this as well as cmake4 or gcc15 related "hangovers". you see it the most in packages where upstream is basically inactive so the package doesn't get frequent builds
[18:07:18] <bschnei> usually it is sufficient to add autoreconf -fiv in prepare so if you also need the touch for some reason, you'll probably want to explain that in the commit msg
[18:09:24] <linkmauve> I just created https://gitlab.archlinux.org and https://gitlab.archlinux.org
[18:09:26] <phrik> Title: Regenerate the configure script with autoreconf (!1) · Merge requests · Arch Linux / Packaging / Packages / sdl_net · GitLab (at gitlab.archlinux.org)
[18:18:08] <linkmauve> Some missing packages like dht also fail to build on x86_64.
[18:23:50] <bschnei> indeed that is also common. even packages that get frequent builds get their hashes broken for mysterious reasons. upstream can be 404 temporarily or even permanently
[18:25:27] <linkmauve> In this case, it’s because the packager replaced the Makefile with a CMakeLists.txt for some reason, and this one is broken against current cmake.
[18:26:36] <bschnei> There are also packages that did build but don't anymore. openai-codex is one that I think solskogen has pointed out
[19:08:24] <linkmauve> For libcaca, I could successfully build by setting HAVE_FLDLN2 to 0, but I’m very surprised the check passes on AArch64.
[19:08:33] <linkmauve> double x; asm volatile("fldln2; fldln2; fxch; fyl2x":"=t"(x):);
[19:08:43] <linkmauve> These are x86 instructions, not ARM ones.
[19:09:58] <linkmauve> And when I try to build this code using gcc it rightfully rejects it.
[19:28:29] <solskogen|M> libcaca will build if built without lto IIRC
[19:34:26] <linkmauve> solskogen|M, LTO makes that x86 asm code build?!
[19:46:10] <solskogen|M> I have a uncommited change to the PKGBUILD that disables LTO, and it seems to have built it.
[19:47:00] <linkmauve> solskogen|M, just disabling fldln2 also made it build on my phone.
[19:47:17] <linkmauve> That way we can still benefit from LTO.
[19:48:12] <linkmauve> I’m currently building lib2geom, I might want to run Inkscape on my phone after that. :)
[19:48:36] <linkmauve> So far with no change at all it is building, but very slowly, thanks C++…
[19:52:09] <solskogen|M> Not sure how much LTO is really give us.
[19:52:40] <solskogen|M> options_aarch64=(!lto)
[19:52:40] <solskogen|M> Is a pretty straight forward fix
[19:53:44] <linkmauve> It’s just a single x86 function being misdetected, that kind of fix should get fixed either upstream or perhaps in the compiler, wherever it happens.
[19:53:51] <linkmauve> Just doing a workaround feels very bad.
[19:55:29] <solskogen|M> I agree, this is a upstream issue.
[20:00:39] <bschnei> at least in that case there is _someone_ working on it upstream, but there hasn't been a tag/relase in 5 years...
[20:14:06] <linkmauve> Ah, for lib2geom it’s three tests which fail.
[20:14:22] <linkmauve> ellipse-test, elliptical-arc-test and polynomial-test.
[20:14:26] <linkmauve> solskogen|M, did they work for you?
[20:21:03] -!- filmroellchen has quit [Quit: filmroellchen]
[20:26:45] <solskogen|M> I don't run tests :)
[20:28:57] <linkmauve> :(
[20:29:36] <linkmauve> Does Inkscape still work fine, or are there random bugs due to those functions not working as they should?
[21:54:24] <bschnei> you'll find: flaky tests, tests that have been skipped intentionally forever, etc. A package building is a pretty big hurdle already. If it does, whether or not it is working as intended is really a question for the users of the package. While in some rare cases test failures have pointed to something legitimately being wrong, in the vast majority of cases I've come across they are more annoying than helpful. Upstream wr
[21:54:24] <bschnei> ites and maintains them an they should largely benefit upstream in the form of fewer user reported issues/faster development cycle/etc. So if they are failing but they test things that no users actually use or care about, they don't seem like the best way to spend time.
[21:58:41] <linkmauve> The same three tests fail on amd64, so the package should probably ignore them atm.
[21:59:44] <bschnei> Ya not a surprise. Here's an example of when I will raise upstream: https://github.com package was working fine all along and then literally everything stops. then i pay more attention.
[21:59:46] <phrik> Title: Issues · microsoft/mimalloc · GitHub (at github.com)
[22:01:01] <bschnei> nodejs packages also tend to be ones that have tests that fail randomly and often need to be built with --nocheck
[22:01:32] <linkmauve> They have an issue open about RISC-V, but I can reproduce the same failures on AArch64 and amd64: https://gitlab.com
[22:01:33] <phrik> Title: Test failed on riscv64 (#82) · Issues · Inkscape / lib2geom · GitLab (at gitlab.com)
[22:03:55] -!- sproed has quit [Read error: Connection reset by peer]
[22:10:12] -!- titus_livius has joined #archlinux-ports
[23:05:37] -!- DarwinSurvivor has quit [Read error: Connection reset by peer]
[23:05:54] -!- DarwinSurvivor has joined #archlinux-ports
[23:38:06] -!- drathir_tor has quit [Remote host closed the connection]