#archlinux-ports | Logs for 2025-11-14

Back
[04:54:57] -!- hcmb_ has joined #archlinux-ports
[04:54:57] hcmb is now known as Guest6126
[04:54:57] -!- Guest6126 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
[04:54:57] hcmb_ is now known as hcmb
[06:43:39] -!- nl6720 has quit []
[06:44:35] -!- nl6720 has joined #archlinux-ports
[07:01:16] -!- nl6720 has quit []
[07:02:09] -!- nl6720 has joined #archlinux-ports
[08:00:09] -!- bschnei has quit [Remote host closed the connection]
[08:00:33] -!- bschnei has joined #archlinux-ports
[08:07:52] <mkurz|M> <mkurz|M> "Here we go: https://gitlab...." <- It was merged. This is really great. So Arch now accepts aarch64 related changes to `PKGBUILD`s.... (full message at <https://matrix.archlinux.org/ircmedia/v1/media/download/AZyDS1MfszOqpfExNnd3uSBtUOBPMfEp2zcGxIW9FCZ9uvA9zCmEPSYuMahK-wgEPYWiYYKrindhxLF6Wl6kf3BCeayYEZZwAGFyY2hsaW51eC5vcmcvcEtlbUVFSFVYWUFCSXZMdUtWRHdNUGZD>)
[08:08:45] <solskogen|M1> mkurz|M: I'll build it very soon!
[08:13:01] <mkurz|M> Also, I think it would be a good idea to somehow track package which need modifications at some central place. You probably know about https://archlinux.org - maybe use that(?), use something similar - or just use the issue tracker in Gitlab (https://gitlab.archlinux.org/archlinux/ports/)
[08:13:01] <mkurz|M> And again, maye collect all the custom PKGBUILD you currently host in your private gitlab accounts at a central place, and then get them upstreamed from there.
[08:13:01] <mkurz|M> Anyway, really happy you started with this project, it would be amazing and and absolute dream having official aarch64 support in Arch! Thanks!
[08:13:01] <phrik> Title: Arch Linux - Todo Lists (at archlinux.org)
[08:13:15] <mkurz|M> s/package/packages/
[08:13:34] <mkurz|M> s/package/packages/, s/maye/maybe/
[08:14:23] <strit|M> I think the problem is that we want the backend and the tools to be able to handle ports, before we open the gates to wide. 🙂
[08:15:03] <josd|M> Understand, but we can't help if we don't know where help is needed 😁
[08:22:46] <Antiz> mkurz|M: Thanks for the suggestions, most of those are a WIP actually :)
[08:23:24] <Antiz> I see you discovered https://ports.archlinux.page, which is something we just created but have not announced yet.
[08:23:25] <phrik> Title: Arch Linux Ports (at ports.archlinux.page)
[08:24:16] <Antiz> The aim is to centralize documentation related to ports efforts there (until they become official)
[08:28:08] <Antiz> We also picked up some work on the tooling side:
[08:28:19] <Antiz> https://gitlab.archlinux.org & https://gitlab.archlinux.org
[08:28:20] <phrik> Title: feat: allow building for unsupported architecture (!294) · Merge requests · Arch Linux / devtools · GitLab (at gitlab.archlinux.org)
[08:31:56] <Antiz> I also plan to publish a follow-up to the initial email about port efforts, answering some questions and highlighting some work done & areas that would need some help.
[08:34:56] <solskogen|M1> I'd love to have a Q&A session if that is something that could help.
[08:37:14] <Antiz> Could be interested. I'll keep that in mind, I'll let you know :)
[08:37:59] <Antiz> Anyway, all of this to say that we have some work planned on some of those next steps (most notably about discoverability of the port efforts). We actually got a dedicated topic session about ports during our last Arch summit :)
[08:39:15] <Antiz> Free time is a bit rare at the moment (at least on my side), but we'll try to move forward with those asap :)
[08:39:41] <Antiz> s/Could be interested/Could be interesting
[08:56:06] <mkurz|M> Arch summit is a meeting of arch maintainers?
[08:56:13] <Antiz> Yes
[08:56:29] <mkurz|M> how often do they take place?
[08:56:33] <Antiz> Once a year
[08:56:41] <mkurz|M> online?
[08:56:48] <mkurz|M> there is no public information?
[08:56:53] <Antiz> Nope, IRL
[08:57:05] <mkurz|M> like it's just for arch devs?
[08:57:07] <solskogen|M1> During FOSDEM?
[08:57:09] <Antiz> "there is no public information?" <-- Well, this is a staff-only event
[08:57:18] <mkurz|M> ok got it
[08:57:23] <mkurz|M> thanks
[08:57:52] <mkurz|M> I was just wondering if there is a yearly (public) arch conference that I am missing... 😅
[08:58:02] <Antiz> Nope ;)
[08:58:07] <Antiz> There used to be
[08:58:12] <Antiz> (ArchConf)
[08:58:25] <strit|M> Closest might be a meetup at FOSDEM. Those happen from time to time.
[08:59:08] <Antiz> But ArchConf hasn't happened since a bunch of years.
[09:00:17] <solskogen|M1> There's was a online event during Covid IIRC
[09:00:59] <Antiz> It would be nice to revive it, but that requires a lot of time, efforts and (eventually) money. So we're not sure yet if we'll be able to do so right now
[09:01:06] <Antiz> solskogen|M1: Yes that was ArchConf
[09:01:30] <Antiz> It got a few "IRL" edition in the past, then one "online" edition during Covid
[09:02:01] <Antiz> The online edition was the last one as of now
[09:02:24] <mkurz|M> Also relevant I guess:
[09:02:24] <mkurz|M> https://gitlab.archlinux.org
[09:02:25] <phrik> Title: Facilitate support in official tools (#5) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[09:02:54] <Antiz> 👍
[09:03:56] <mkurz|M> Really happy to finally see some movement regarding arch ports. I had the impression it was dead already... Thanks again!
[09:08:43] <strit|M> I think it moves faster now than ever. 🙂
[09:18:30] <solskogen|M1> mkurz: obsidian is now packaged!
[09:27:47] <mkurz|M> <solskogen|M1> "mkurz: obsidian is now packaged!" <- Thanks!
[09:37:55] -!- titus_livius has joined #archlinux-ports
[12:03:20] -!- Danct12 has joined #archlinux-ports
[12:03:26] <Danct12> o/
[12:03:40] <Danct12> are we getting back together..?
[12:03:41] <Antiz> 👋
[12:23:15] nie_ is now known as nie
[13:06:20] <strit|M> Hi Danct. 😛
[13:51:49] <solskogen|M1> Danct12: I sure hope so!
[13:54:00] <Danct12> can i get a matrix link for this?
[13:55:06] <solskogen|M1> what's your matrix id?
[13:55:42] <Danct12> @danct12@kde.org
[13:55:49] <Danct12> whoops
[13:55:56] <Danct12> @danct12:kde.org
[13:56:05] <Danct12> accidentally email'd
[13:56:49] -!- wszqkzqk|M has quit [Quit: Client limit exceeded: 90]
[13:56:56] -!- danct12|M has joined #archlinux-ports
[13:56:59] <danct12|M> 👋
[13:59:38] <danct12|M> a quick introduction: i maintain an alarm port of a few pine64 devices. hopefully i can help getting the port moving forward. i use arch btw
[14:00:07] <danct12|M> hey! been a long time since i saw you, how is it going these days?
[14:00:22] <solskogen|M1> Great to have you onboard!
[14:01:50] <danct12|M> danct12|M: also known as "danctnix", but that's a common mistake made by people and i have decided to call it that
[14:02:01] <solskogen|M1> You can find our tarball here: https://arch-linux-repo.drzee.net - and the repos here: https://arch-linux-repo.drzee.net
[14:02:01] <solskogen|M1> Use at your own risk. We have mainline kernel and pi-kernel in there. ARMv8.2-A or better.
[14:02:03] <phrik> Title: Index of arch/tarballs/os/aarch64/ (at arch-linux-repo.drzee.net)
[14:03:44] <danct12|M> solskogen|M1: are we going to support ARMv8.0? there's many boards with Cortex-A53
[14:04:48] <danct12|M> the pi 4 for example, which a lot of folks uses alarm are currently using, and raspberry pi still sells them as an "affordable" arm board
[14:04:55] <solskogen|M1> As of now, no. But that might change in the future. We had some problems with ARMv8-A and the latest and greatest gcc. Linking stuff like qt6-webengine called for trouble.
[14:05:11] <jelle> danct12|M: that is not the official stance of the arch project :p
[14:05:14] <solskogen|M1> we migh even throw the Pi5 kernel out (and have them in AUR) - because we want to focus on EFI.
[14:06:35] <danct12|M> > because we want to focus on EFI
[14:06:35] <danct12|M> sounds great to me, grub works with u-boot nicely
[14:06:39] <danct12|M> * > because we want to focus on EFI
[14:06:39] <danct12|M> sounds great to me, grub works with u-boot nicely
[14:08:19] <solskogen|M1> Personally, I don't quite see a reason why a new port should support 13 year old cpus :-) But it's not a hill I'm willing to die on.
[14:08:23] <danct12|M> <solskogen|M1> "You can find our tarball here..." <- what about toolchains and how should i compile my stuffs?
[14:09:18] <danct12|M> * my stuffs? (most importantly, how to bootstrap)
[14:09:27] <solskogen|M1> I have my own scripts for building packages ( just a overlay for makechrootpkg ) - but that's one of the things that need working.
[14:10:33] <solskogen|M1> Someone, I don't remember their name, had a rough bootstrapping tool/script.
[14:10:33] <solskogen|M1> But we started with ALARM, and worked our way out of that.
[14:11:02] <solskogen|M1> We have more packages, and are more up to date, than ALARM.
[14:11:29] <solskogen|M1> If you could help with bootstrapping from x86_64, that would be great!
[14:11:37] <danct12|M> solskogen|M1: greysky?
[14:12:10] <danct12|M> i think they're the one that has been running a sinking ship for about a year or two now
[14:12:28] <solskogen|M1> https://gitlab.archlinux.org
[14:12:29] <phrik> Title: Bootstrap the toolchain (#1) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[14:15:09] <solskogen|M1> I've been mostly compiling packages - and been keeping our packages up to date - and fixed problems as good as I can and created MRs in gitlab. Most packages Just Work(tm) - but some require some extra work. I haven't tested every package, so if your favorite package don't work. Please report :-) Everything I use, works fine.
[14:16:28] <danct12|M> solskogen|M1: neat
[14:16:41] <danct12|M> i should get my orange pi 5 setup again so i can try this out
[14:16:52] <danct12|M> but right now i have my pinetab 2, which is armv8.2
[14:17:22] <danct12|M> even an updated chromium too? sick
[14:17:33] <solskogen|M1> Oh yeah
[14:18:11] <solskogen|M1> But dragons. There are some.
[14:18:57] <danct12|M> maybe i should try to throw an armv8.0 board onto an armv8.2 rootfs and see if it boots ™️
[14:19:08] <danct12|M> never tried that before
[14:19:30] <solskogen|M1> that will not work. We've tried :-)
[14:19:42] <danct12|M> aw :(
[14:29:36] <solskogen|M1> I'll try building some of the packages that have cause problems earlier with armv8-a flags instead. See if the problem is still there.
[14:31:37] <solskogen|M1> what we don't want is to fall into the same trap as ALARM and have "hundreds" of unmaintained uboot and kernel forks in our repo.
[14:31:58] <solskogen|M1> armv7 is out of the question.
[14:32:37] <danct12|M> solskogen|M1: a lot of the things are armv8 now, so yeah
[14:32:56] <danct12|M> actually it turns out i will not be able to run arch on my fxtec pro1x as well :P
[14:33:09] <danct12|M> has a 2021 soc, but 5+ years old architecture
[14:33:53] <danct12|M> so now i only have two promising devices, my pt2 and opi 5
[14:35:01] * jelle has plenty sunxi aarch64 devices /o\
[14:35:38] <solskogen|M1> If it's up to me (and it's not) I'll say we set ARMv8.2 as a baseline.
[14:38:54] <danct12|M> jelle: my device list (aarch64):... (full message at <https://matrix.archlinux.org/ircmedia/v1/media/download/AaC3SjNa1kh_H9dNc1Po_Ip3VWjt8GPAg057J3jqIy6k2OBrVLdrJ5dW-Ekvc9_0H4mXxHwaRcozrIb09wY1dG9CeayucXpgAGFyY2hsaW51eC5vcmcvT1RwSU5qYXNCbG5yUVdFRVhwUUZIZ2hv>)
[14:39:03] <danct12|M> i'd like to say 80% of this list are rockchip devices
[14:39:10] <jelle> hehe
[14:39:25] <danct12|M> add orange pi 5 to the list as well
[14:40:51] <danct12|M> a bonus: fxtec pro 1 and pro1x are unfused
[14:41:09] <danct12|M> so it can boot a custom xbl/abl
[14:41:27] <danct12|M> i am also able to wipe abl and restored it like nothing happened xD
[14:54:16] <danct12|M> i have a test subject, can i invite them here?
[14:54:30] <danct12|M> they got a snapdragon x1 laptop
[14:54:46] <danct12|M> * x1 laptop, and they planned to install linux on it sometime ago but never got around to
[14:55:56] <solskogen|M1> I.. I think you can?
[15:00:01] -!- kyeh|M has joined #archlinux-ports
[15:00:15] <danct12|M> welcome kyeh
[15:00:15] <kyeh|M> o/
[15:00:41] <solskogen|M1> welcome to the jungle!
[15:00:57] <kyeh|M> That sounds like me, but to clarify, I will probably have one soon-ish (<3 month, I hope)
[15:01:23] <jelle> danct12|M: snapdragon is still device tree fun :-(
[15:04:31] <danct12|M> there are ways around that
[15:05:08] <jelle> I know the lenovo one works but not fully
[15:05:25] <danct12|M> well there's a dell one that works without funny workarounds
[15:14:05] <kyeh|M> I'll be getting it through my work, and they have a preference towards HP, but the device tree seems to be here https://lkml.org
[15:14:06] <phrik> Title: LKML: Juerg Haefliger: [PATCH 0/3] HP EliteBook Ultra G1q support (at lkml.org)
[15:14:37] <jelle> thats with all X1 laptops
[15:15:34] <danct12|M> 2026 will be the year of 55%
[15:15:38] <lynxy> i have an x1e device running archlinuxarm with only a few issues- would be neat to be running arch itself
[15:16:16] <jelle> danct12|M: 55%?
[15:17:01] <lynxy> i know of a few interested parties in oftc's #aarch64-laptops
[15:21:07] <danct12|M> jelle: https://www.youtube.com
[15:21:09] <phrik> Title: - YouTube (at www.youtube.com)
[15:21:27] <jelle> danct12|M: I doubt this :P
[16:31:20] <strit|M> <danct12|M> "hey! been a long time since i..." <- Doing alright. Took a break from distro maintenance and now back to a little package maintaining. Not for Manjaro anymore, but for regular Arch.
[16:45:45] <hrdl> Danct12: didn't you own a Pine64 PineNote? I hope to find some time to give this port a try this month
[17:01:01] <solskogen|M1> lynxy: special kernel or can you use mainline?
[17:01:49] <lynxy> in theory mainline should work for the xps 9345, but i've been using linaro's qcom-laptops kernel
[17:01:57] <lynxy> running 6.18-rc4 at the moment
[17:02:21] <solskogen|M1> If 6.17 can run, please try our fork :-)
[17:03:01] <lynxy> 6.17 should be fine too! i think early 6.16 was when a lot of the required patches were upstreamed
[17:07:27] <solskogen|M1> In theory, you can do a in-place upgrade from ALARM to our repos. But I'd recommend a backup first :-)
[17:24:56] <lynxy> how would i go about doing that? :eyes:
[17:25:10] <lynxy> i'm not fussed about backing up, everything on here exists elsewhere
[17:25:25] <solskogen|M1> Backup or switch to our repos? :-)
[17:25:41] <lynxy> switch to your repos :]
[17:26:41] <solskogen|M1> Server = https://arch-linux-repo.drzee.net
[17:26:48] <solskogen|M1> we have core and extra.
[17:27:09] <solskogen|M1> and just force install everything.
[17:27:13] <solskogen|M1> Or try it in a chroot first.
[17:55:59] -!- nl6720 has quit []
[17:57:54] -!- nl6720 has joined #archlinux-ports
[18:48:14] -!- hrtk_ has joined #archlinux-ports
[18:48:40] -!- hrtk has quit [Ping timeout: 265 seconds]
[18:54:31] -!- drathir_tor has quit [Ping timeout: 272 seconds]
[18:56:15] -!- drathir_tor has joined #archlinux-ports
[19:26:56] -!- gehidore has quit [Quit: brb parkour]
[19:28:16] -!- gehidore has joined #archlinux-ports
[20:57:16] <danct12|M> hrdl: Yes. I said so. :P
[20:59:17] <danct12|M> <strit|M> "Doing alright. Took a break from..." <- Yes, I saw that. Manjaro ARM is kind of dead around the time ALARM starts to have issues.
[21:02:13] <danct12|M> I recently switched over to Fedora on my Pinebook Pro for this reason alone since some packages started to become less up to date than it was before.
[21:27:19] <strit|M> <danct12|M> "Yes, I saw that. Manjaro ARM..." <- I know Manjaro ARM kind of stopped moving when I left the project. No one else wanted to pick up where I left it. ALARM's "demise" had been underway before that.
[21:28:32] <solskogen|M1> what did you work on, on Manjaro ARM?
[21:30:12] <strit|M> I did the tools that built images and packages, maintained most of our specific packages, built our CI pipelines and some general management.
[21:31:03] <solskogen|M1> images and CI pipelines are some of the things we need help with :)
[21:31:33] <strit|M> Most of it was bash hackery. :P
[21:32:56] <solskogen|M1> well, what we have is more or less coded with a lot of help from amazon q. It's hacky, but it works (and it performs quite well)
[21:33:20] <lynxy> solskogen- i'm failing to fetch a required PGP key, could not be looked up remotely key ending 0751
[21:33:47] <solskogen|M1> That is correct. That part is not done either.
[21:34:19] <lynxy> is there another source for this key that i could use?
[21:34:25] <solskogen|M1> DrZee: Is the man behind that
[21:34:36] <solskogen|M1> I don't think that key is published.
[21:37:33] <solskogen|M1> until futher notice, you just have to trust us :-)
[21:44:38] <lynxy> ohkay, remotes changed and siglevel changed to never, temporarily- a couple of local packages are newer and one or two are missing from remote but otherwise it seems fine
[21:44:54] <solskogen|M1> what's missing?
[21:45:08] <lynxy> ah just the rofi-wayland fork, i think
[21:46:06] <lynxy> though it's likely not necessary. it seems my other device is running the rofi package just fine
[21:46:12] <solskogen|M1> That isn't in ALARM either
[21:48:20] <lynxy> hmm- running pacman now i get `/usr/lib/libassuan.so.9: version LIBASSUAN_1.0 not found (required by /usr/lib/libgpgme.so.45)`
[21:49:53] <solskogen|M1> do you have /usr/lib/libgpgme.so.45.0.1 ?
[21:50:02] <lynxy> i do
[21:50:39] <solskogen|M1> you've got /usr/lib/libassuan.so.9.0.2 as well?
[21:50:50] <lynxy> yup!
[21:52:36] <solskogen|M1> Hmmmm... Strange. Early on, we built a newer version of libassuan.so than what's in x86_64 (we built packages that where the latest in github, not the tagged versions which we do now) - I decided not to go back.
[21:53:14] <solskogen|M1> ok, but that means that it's not possible to do a upgrade from ALARM anymore. I'd suggest you download the tarball to rescue your system.
[21:54:10] <lynxy> ohyah okay!
[21:54:11] <solskogen|M1> If you force-installed everything it should work, so I dont quite understand why that happened to you.
[21:54:50] <lynxy> anything i can fetch from the system that might help with debugging that- or is it an issue that isn't a focus rn?
[21:54:54] <solskogen|M1> but yes, that is the reason we have pacman-static in our repo (from aur)
[21:55:21] <solskogen|M1> Nah, I'll try the same when I got the time.
[21:55:58] <lynxy> coolcool, i'll push the required files from one of my cached tarballs and fix the state
[21:58:11] <solskogen|M1> "nm -D /usr/lib/libgpgme.so | grep LIBAS" should say <somethingsomething>@LIBASSUAN_2.0
[21:58:49] <solskogen|M1> copying libgpgme.so.45.0.1 from the tarball should be enough
[21:59:50] <lynxy> nah i get <somethingsomething>@LIBASSUAN_1.0
[22:00:25] <solskogen|M1> so for some strange reason, your library didn't get upgraded.
[22:01:09] <lynxy> huh- i'll experiment a little, one sec
[22:03:08] <solskogen|M1> because you did force reinstall packages right? not just a "pacman -Suy" ?
[22:10:24] <lynxy> is the most reasonable way to force re-install to do an export and feed that into the `pacman -S` command?
[22:11:04] <lynxy> fixing was simple, just had to copy libassuan.so.9.0.0 from the tarball and fix the symlin
[22:11:19] <lynxy> s/symlin/symlink
[22:11:20] <solskogen|M1> pacman -Qqn | pacman -S -
[22:11:27] <solskogen|M1> from here: https://wiki.archlinux.org
[22:11:28] <phrik> Title: pacman/Tips and tricks - ArchWiki (at wiki.archlinux.org)
[22:12:15] <lynxy> ah, i believe i used a different variation which didn't fully work how i expected :]
[22:14:46] <solskogen|M1> Do that now :-)
[22:15:08] <lynxy> doing so- i'll let you know when it's done
[22:15:36] <solskogen|M1> I hope you don't have your lifes work on the device :-)
[22:16:03] <lynxy> not at all- the personal files that do exist on it are syncthing'd across and largely backed up on my rackserver
[22:16:27] <lynxy> i've learn the data loss lesson before (more than once)
[22:16:33] <lynxy> s/learn/learnt
[22:17:02] <solskogen|M1> Real sysadmins don't take backup, but cry often.
[22:17:18] <lynxy> i've done enough crying over data :sob:
[22:17:33] <solskogen|M1> I learned that back in 1999 :-)
[22:17:53] <lynxy> ah, when i was.. 2
[22:19:54] <solskogen|M1> I'm a old fart. Get used to it :-)
[22:19:55] <lynxy> oh yah it seems to work this time- my bad!
[22:20:23] <solskogen|M1> Great! What device are you using?
[22:21:37] <lynxy> the dell xps 13 9345- wait, would you like me to switch to the provided kernel or? i'm a little hesitant as one or two of the revisions of 6.17 might be missing a patch which the oled display requires
[22:21:53] <lynxy> fixable, just requires pulling the nvme out
[22:23:03] <solskogen|M1> That's all up to you. We have 6.17.7.arch1 there now.
[22:23:24] <solskogen|M1> I'd keep the vendor kernel somewhere safe :-)
[22:24:46] <lynxy> lemme set up the current as a backup entry in systemd-boot
[22:49:06] -!- titus_livius has joined #archlinux-ports
[22:52:16] -!- tpkessler|M has joined #archlinux-ports
[22:52:36] -!- heftig has joined #archlinux-ports
[23:10:12] -!- titus_livius has joined #archlinux-ports
[23:31:17] <lynxy> naw i ain't getting it booting with the mainline kernel, even using the dtbs from the linaro fork
[23:33:34] <danct12|M> lynxy: at least you'll be getting wifi working once it works xD
[23:34:23] <lynxy> it times out waiting for a labelled disk device which definitely exists, and when it drops into emergency kernel i get no keyboard input- this is similar in symptom to the issues in earlier kernel versions for sd x1e devices before certain patches (i forget which) were upstreamed
[23:35:05] <lynxy> danct12, oh? how do you mean- i heard something about dell pushing to linux-firmware sometime soon, though i'm using the firmware pulled from windows rn
[23:37:34] <danct12|M> most qcom devices are exactly identical to each other
[23:37:39] <danct12|M> so they have the same wlan soc
[23:37:42] <danct12|M> * same wlan/bt soc
[23:37:54] <danct12|M> maybe some will be using broadcom but i think that's apple currently
[23:38:24] <danct12|M> and guess who maintains qcom on mainline? it's a company named linaro and recently we have quicinc
[23:38:39] <danct12|M> meanwhile my tablet needs an out of tree driver for it to work xD
[23:38:40] <danct12|M> a bad one