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

Back
[01:49:36] -!- drathir_tor has quit [Remote host closed the connection]
[01:49:54] -!- drathir_tor has joined #archlinux-ports
[03:31:10] -!- Daanct12 has joined #archlinux-ports
[04:14:52] -!- hcmb_ has joined #archlinux-ports
[04:14:52] hcmb is now known as Guest3776
[04:14:52] -!- Guest3776 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
[04:14:52] hcmb_ is now known as hcmb
[05:01:28] -!- drathir_tor has quit [Remote host closed the connection]
[05:01:46] -!- drathir_tor has joined #archlinux-ports
[05:23:23] -!- drathir_tor has quit [Remote host closed the connection]
[05:23:40] -!- drathir_tor has joined #archlinux-ports
[07:21:13] -!- Daanct12 has quit [Ping timeout: 248 seconds]
[08:31:26] <yuvadm> solskogen|M: why do we need to bootstrap from another aarch64 distro? i wrote an initial stage 1 bootstrap from the aarch64-linux-gnu-* packages, haven't continued the work but we can continue for stage 2
[08:31:31] <yuvadm> https://gitlab.archlinux.org
[08:31:32] <phrik> Title: Yuval Adam / aarch64-bootstrap · GitLab (at gitlab.archlinux.org)
[08:42:48] -!- Daanct12 has joined #archlinux-ports
[08:43:27] <solskogen|M> trusting the trust :)
[09:35:38] -!- meijin007 has joined #archlinux-ports
[09:40:56] <meijin007> FYI: I got the aarch64 port booting on an RPi 5 from USB today; wrote up the steps here: https://gist.github.com
[09:40:57] <phrik> Title: Installing Arch Linux aarch64 (drzee.net port) on Raspberry Pi 5 · GitHub (at gist.github.com)
[09:43:08] <solskogen|M> I'd like to have the bootstrap tarball ready for the Pi5 as well, so you wouldn't require a existing aarch64 install to do the post-steps.
[09:43:40] <meijin007> you mean not needing to switch the kernel?
[09:44:31] <solskogen|M> Install, yes. I don't think there's a kernel in the bootstrap tarballs at all.
[09:44:55] <solskogen|M> and we should perhaps unlock the root user.
[09:45:18] <meijin007> yes, the locked root user was a pain
[09:46:38] <solskogen|M> the 4th second could also be moved to after first boot.
[09:47:18] <meijin007> yeah, good point.
[09:47:32] <meijin007> you mean trusting the drzee signing?
[09:48:57] <solskogen|M> yes
[09:49:18] <solskogen|M> are you the guy behind this: https://sapir.io ?
[09:49:19] <phrik> Title: Blog - Assaf Sapir (at sapir.io)
[09:49:43] <meijin007> but the rpi-linux is from that repo that needs the sign, no?
[09:49:58] <meijin007> yes, this is me :) I just uploaded it, how you found it so fast
[09:50:04] <yuvadm> heh hey meijin007 :)
[09:50:16] <meijin007> Hey yuvadm!
[09:50:37] <solskogen|M> the link was provided in the gist :-)
[09:50:53] <meijin007> oh lol
[09:51:09] <solskogen|M> I just want to point out that nowhere does it say that our port is in any way, shape or form, official.
[09:51:40] <solskogen|M> we want to, but nowhere does it say that it is.
[09:52:22] <yuvadm> meijin007 great write up, and yeah nothing about this effort is official and it's not ready for end users, but for whoever wants to help push this to an eventual proper port, this is the way to go
[09:52:31] <meijin007> yes, sure, it just feels more "official" because of the domain name
[09:52:33] <solskogen|M> and we have a lot more packages than ALARM does.
[09:53:00] <yuvadm> yeah i do not trust ALARM at all at this point, it's unmaintained and I'm surprised it's still chugging along
[09:53:13] <solskogen|M> On the top of https://ports.archlinux.page is says very clearly Status: Unofficial
[09:53:14] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[09:53:43] <Antiz> I agree, the "official" word in the title of the article is misleading / click bait-ish ^^
[09:54:01] <Antiz> Rest is fine though, good lecture! Thanks meijin007 :)
[09:54:35] <solskogen|M> I'm not sure how much clearer we can be :-)
[09:54:37] <meijin007> thanks, I will change the title :)
[09:54:38] <meijin007> my main problem with ALARM that the maintaner doesn't seems to care any more
[09:55:11] <yuvadm> did he ever? that project was always inaccessible to contributions
[09:55:38] <meijin007> not that just, even the forum is completely broken
[09:55:40] <yuvadm> they* - it was like 3 guys at the peak
[09:57:05] <BrainDamage> it was bound to happen sooner or later, they made the project extremely hostile to external contribution, eventually the motivation or time of current maintainers would dry out
[09:57:27] <meijin007> yap
[09:57:33] <BrainDamage> they setup a system that cannot outlive themselves
[09:59:03] <meijin007> btw you can now change https://ports.archlinux.page that rpi5 is known to be supported :D
[09:59:04] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[09:59:25] <Daanct12> i still have no idea how the build system for alarm works
[09:59:28] <Daanct12> zero docs
[09:59:51] <solskogen|M> BrainDamage: which is the reason we started the porting effort. We started with asking them if we could help, but didn't get any decent reply.
[10:00:14] <solskogen|M> I've been running our port on Pi5 since september :-)
[10:00:37] <yuvadm> Daanct12 I belive it was al built around their own homebrew distcc setup
[10:04:57] <meijin007> changed the title, thanks for the feedback!
[10:05:59] <meijin007> btw why not supporting rpi4?
[10:20:16] <solskogen|M> I don't have it.
[10:20:56] <solskogen|M> And we had some issues with some packages that required armv8.2-a
[11:02:58] <linkmauve> meijin007, in your blog post you mention a 16 KiB kernel, does that provide a substantial improvement over 4 KiB pages for regular workloads?
[11:03:12] <linkmauve> I assume stuff like Wine, which I just got working yesterday, wouldn’t work any longer though.
[11:04:37] <linkmauve> I’m on Rockchip, not Broadcom, but the CPU should be sensibly similar.
[11:04:53] <linkmauve> Does it interact well with the IOMMU of various devices?
[11:37:13] <meijin007> linkmauve this is what is recommended (AFAIK)
[11:37:27] <meijin007> I guess (?) for most of the thing it won't matter
[11:37:52] <solskogen|M> 16k is what the Raspberry Pi kernels have by default at least
[11:38:11] <meijin007> only for the rpi5, no?
[11:38:41] -!- gehidore has quit [Ping timeout: 268 seconds]
[11:39:54] -!- gehidore has joined #archlinux-ports
[11:47:23] <solskogen|M> Correct
[11:48:49] -!- Daanct12 has quit [Quit: WeeChat 4.8.2]
[12:00:09] <linkmauve> I don’t have any Broadcom board, so is it recommended for other brands?
[12:00:33] <linkmauve> How does it affect userland?
[12:03:45] <solskogen|M> I can't say I've noticed anything special.
[12:52:46] <meijin007> is there any talking about making this "official" port? I am not sure I understood from the rfc what it takes
[12:59:10] <phantomas> meijin007: afaiui that's the end goal
[13:02:52] <yuvadm> meijin007: i have no idea but i would guess it's not exactly a well defined process
[13:03:23] <yuvadm> i understand it as lots of grunt work that needs to be done and is in progress, and at some point it will be baked enough to move forward with an RFC
[13:54:28] <meijin007> let me know if there is anything I can help with. it's a bit strange it's officially supported by doughter distros of arch but not by arch
[14:49:17] <solskogen|M> the best thing you can do is test and use the system. fix and/or report any problems. Make PRs.
[16:08:21] -!- maxjrh has joined #archlinux-ports
[16:31:12] -!- binarycraft has joined #archlinux-ports
[16:33:11] <binarycraft> bschnei: please help review this change, fixed qcom_scm timeout issue on x1e: https://gitlab.archlinux.org thanks!
[16:33:11] <phrik> Title: Sign in · GitLab (at gitlab.archlinux.org)
[17:11:36] -!- binarycraft has quit [Quit: WeeChat 4.8.2]
[17:47:37] <bschnei> binarycraft: thanks for this! can you modify to leave the pkgrel alone? that is consistent with Arch policy and makes sense as we may not necessarily be ready to build something at the same time we accept a MR
[17:58:33] <solskogen|M> bschnei: pffft... that's nothing. I'm ready to build something BEFORE submitting a MR ;-)
[18:02:36] -!- binarycraft has joined #archlinux-ports
[18:03:11] <binarycraft> bschnei: sure, I have reverted the change on pkgrel
[18:06:59] <bschnei> meijin007: thank you so much for the write ups! Stories are always more interesting to read than documentation so we really appreciate the time you put into sharing yours. Do not be surprised if https://gitlab.archlinux.org gets marked as completed/closed because it doesn't appear to be an actual issue/work item (unless I'm missing something). Regarding contribut
[18:06:59] <bschnei> ors, by far the vast majority of grunt work of just trying to keep packages up to date is shouldered by solskogen. This includes regular maintenance of linux-rpi5. drzee contributes "devops" for us (cloud resources, etc.). I build a subset of packages for my v8 devices and when I find problems with those I try to contribute via MRs here or raising issues upstream. The one thing I'll caution on is the note that we build
[18:06:59] <bschnei> packages "straight from upstream". In the vast majority of cases, this is a a true statement, but there are non-trivial packages where solskogen or myself maintain forks that are not ready for MRs. https://gitlab.archlinux.org being perhaps the most notorious example. So a more accurate description of the situation is that we start with x86_64 Arch packages and only fork when needed, and when we do fork, w
[18:06:59] <bschnei> e do that work here on Arch's gitlab instance so that our contributions are part of this community. Hope that helps to clarify a couple of things. Feel free to DM me if you want to chat :)
[18:07:00] <phrik> Title: I was able to run this on a raspberry pi (over USB thumb drive) (#8) · Tasks · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[18:07:01] <phrik> Title: Benjamin Schneider / linux · GitLab (at gitlab.archlinux.org)
[18:08:53] <bschnei> binarycraft: merged! thank you!
[18:13:07] -!- binarycraft has quit [Quit: WeeChat 4.8.2]
[18:14:55] <bschnei> meijin007: https://ports.archlinux.page does already note that the packages work on Pi5--with the caveat that it needs a non-mainline kernel
[18:14:57] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[18:17:11] <bschnei> also rpi4 is a arm-v8 device. for more context see: https://gitlab.archlinux.org I should probably update this issue. We overcame some original obstacles and the current state here is: "we don't know what we don't know". In other words, we need to attempt to build all packages for v8...
[18:17:12] <phrik> Title: Sign in · GitLab (at gitlab.archlinux.org)
[18:17:41] <solskogen|M> Rebuilding everything is a huge pain :-)
[18:18:16] <bschnei> oh c'mon now. it only took us...how many months to do it the first time around? :D
[18:19:08] <solskogen|M> Wonder how many packages are broken this time around...
[18:21:12] <bschnei> ...I might be able to get you estimate but it would include noise from bad hashes, failed check(), etc. so it wouldn't be a number that reflects v8 but just packages that don't *easily* build for v8...
[18:21:31] <bschnei> I need some time...that's a lot to try to build...
[19:33:47] <meijin007> bschnei feel free to close #8, I just didn't found this place so I wanted just ot share
[19:38:24] <meijin007> regarding the root user lock - is that also true for the base filesystem in arch by default?
[19:38:26] -!- maxjrh has quit [Quit: maxjrh]
[19:45:56] <meijin007> https://gitlab.archlinux.org
[19:45:56] <meijin007> maybe we should allign with that
[19:45:58] <phrik> Title: shadow · main · Arch Linux / Packaging / Packages / filesystem · GitLab (at gitlab.archlinux.org)
[19:54:40] <meijin007> ok so this also actually locked by default then I wonder how it work :thinking:
[20:31:46] <solskogen|M> we don't make any changes to that package, so we are already aligned.
[20:32:41] <meijin007> oh, right :facepalm:
[20:33:09] <solskogen|M> That said, the normal x86_64 to install is to use pacstrap.
[20:33:55] <meijin007> is it possible with arm?
[20:35:11] <solskogen|M> Ofc, how do you think we create the tarballs? :-)
[20:36:04] <solskogen|M> But yes, I have a script ready for making a image that people can put on a usb stick which will boot into a minimal aarch64 environment. that image can be used as is (if you want) - or you can use it to pacstrap a second device
[20:36:18] <meijin007> this will be great
[20:37:35] <solskogen|M> even better would be to use archiso to create that image
[20:38:56] <solskogen|M> but again, the most help you can give is to just use the system - and report any problems. I've built all packages, but I haven't - and cannot - test everything. I only know that the stuff I use work as it should :-)
[20:39:49] <meijin007> I might just move from alarm to this on my PI and pacamn -Syuu and rebuild all aur :D
[20:40:43] <solskogen|M> Last time I checked you could just switch the repos from ALARM and over to ours and reinstall EVERY package.
[20:40:58] <solskogen|M> Not just pacman -Suy, but a forced reinstall of everything
[20:41:18] <solskogen|M> but I won't promise that it works.
[20:51:53] -!- meijin007 has quit [Quit: Client closed]
[21:21:13] <yuvadm> bschnei: what's the limitation on arm v8 builds? effort in updating PKGBUILDS or infra?
[21:22:23] <solskogen|M> enough cpu cores I guess
[22:49:26] <bschnei> yuvadm: ya what solskogen said. it just takes time to get that many packages built. even with multiple cores, not every packaging operation scales up. and while you are building new things you fall behind on maintaining existing things. package building is effectively a round the clock operation just to tread water
[22:50:20] <solskogen|M> my build script can build multiple packages at the same time, which helps a lot.
[22:54:04] <bschnei> one possible thing I can do is drop the .log files from failed v8 package builds on a server so that people interested in the work can start combing through. but I should also adopt solskogen's tools. as he notes, some of the bottlenecks can be overcome with better scripting and i'm going to run into them quickly if I try to build everything
[23:10:12] -!- titus_livius has joined #archlinux-ports