#archlinux-ports | Logs for 2026-02-14

Back
[00:04:13] <bschnei> Another posssible approach to dtbs is to install a single large package somewhere like /usr/lib and use hooks or whatever magic to install only the necessary DTBs to /boot for your device. A lot like how mkinitcpio works. But having seen ALARM try to automate some of this in their packages, I've found it to be a "solve one problem create six more" thing :/
[00:07:34] <bschnei> As a result, I'm currently of the opinion that less is more when trying to automatically configure /boot for ARM devices. By far the sanest approach I've found is to build the device tree into the bootloader itself (modern U-Boot supports this) and then have U-Boot load systemd-boot (modern U-Boot also supports this) and go from there.
[00:17:39] -!- drathir_tor has quit [Remote host closed the connection]
[00:17:59] -!- drathir_tor has joined #archlinux-ports
[00:19:28] -!- drathir_tor has quit [Remote host closed the connection]
[00:23:02] -!- drathir_tor has joined #archlinux-ports
[04:32:13] -!- yjun123 has quit [Remote host closed the connection]
[04:32:38] -!- yjun123 has joined #archlinux-ports
[05:00:41] -!- hcmb_ has joined #archlinux-ports
[05:00:41] -!- hcmb has quit [Killed (calcium.libera.chat (Nickname regained by services))]
[05:00:42] hcmb_ is now known as hcmb
[09:37:21] -!- Daanct12 has joined #archlinux-ports
[10:17:33] -!- dvzrv|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- archmatrix has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- jelle|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- heftig has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- carsme|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- C0rn3j|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- artafinde|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- tpkessler|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- integral|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- bgyorgy|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- solskogen|M has quit [Quit: Bridge terminating on SIGTERM]
[10:17:33] -!- anthraxx|M has quit [Quit: Bridge terminating on SIGTERM]
[10:18:47] -!- archmatrix has joined #archlinux-ports
[10:18:55] -!- phrik has quit [Remote host closed the connection]
[10:20:58] -!- phrik has joined #archlinux-ports
[10:25:19] -!- heftig has joined #archlinux-ports
[10:25:20] -!- anthraxx|M has joined #archlinux-ports
[10:25:22] -!- C0rn3j|M has joined #archlinux-ports
[10:25:23] -!- bgyorgy|M has joined #archlinux-ports
[10:25:23] -!- solskogen|M has joined #archlinux-ports
[10:25:25] -!- dvzrv|M has joined #archlinux-ports
[10:25:26] -!- jelle|M has joined #archlinux-ports
[10:25:30] -!- integral|M has joined #archlinux-ports
[10:25:36] -!- tpkessler|M has joined #archlinux-ports
[10:25:36] -!- artafinde|M has joined #archlinux-ports
[10:25:38] -!- carsme|M has joined #archlinux-ports
[10:32:13] -!- yjun123 has quit [Quit: Konversation terminated!]
[10:33:26] -!- yjun123 has joined #archlinux-ports
[11:41:40] <solskogen|M> bschnei: or grub :-)
[11:46:51] <solskogen|M> heftig: I see that you are a contributor for llvm/clang. Do you know if the llvm toolkit requires a specific build order?
[11:50:20] <heftig> Solskogen: sorry, not really. i do know that clang has to be built with the matching llvm, or it will misreport its own version
[11:51:10] <solskogen|M> heftig: Thanks!
[11:51:34] <solskogen|M> That was the information I was hoping for, no need to be sorry :-)
[11:57:31] -!- Daanct12 has quit [Quit: WeeChat 4.8.1]
[12:01:35] <hrdl> Re bschnei's https://gitlab.archlinux.org and non-mainline kernels: any thoughts on combining multiple config fragments in those non-mainline kernels prepare(), e.g. the suggested config.aarch64 and a kernel-specific config?
[12:01:36] <phrik> Title: Draft: aarch64 support (!9) · Merge requests · Arch Linux / Packaging / Packages / linux · GitLab (at gitlab.archlinux.org)
[12:07:55] <solskogen|M> hrdl: Are you thinking about vendor specific patches?
[12:14:01] <hrdl> I was thinking about kernels in AUR that ship a full config atm, e.g. linux-librem5. I was thinking about reducing those configs by only enabling/disabling config options that those vendor kernels intend to use in those configs and applying those after the "official" config.aarch64 was applied
[12:14:48] <solskogen|M> Unless there a good reason not to have them enabled by default, I guess.
[12:16:29] <solskogen|M> But I don't think that's a big problem really
[12:17:24] <solskogen|M> the problem is vendor kernels, that seems to be forgotten after some time. I've seen multiple times that the vendor kernel is some random guys fork of the linux kernel on github
[12:20:51] <hrdl> I understand. It's just a thought I had yesterday when I saw the MR above, but it doesn't solve the core problem of vendor kernels
[12:25:16] <solskogen|M> I tend to disagree somewhat with ben in that regard. I can live with vendor kernels, as long as they exists in AUR and is community supported. We can have a seperate repo for then with a huge warning sign that's saying that you're on your own. That said, I want the amount of those kind of kernels at a absolute minimum.
[12:26:22] <solskogen|M> I'd rather have -rc kernels :-)
[13:52:13] -!- gromit has quit [Quit: ZNC 1.10.1+docker-git--rc11.10.x-znc-1.10.0-12-gee54fb12 - https://znc.in]
[13:58:03] -!- gromit has joined #archlinux-ports
[14:34:13] -!- SpieringsAE_sff has joined #archlinux-ports
[14:35:10] <SpieringsAE_sff> finally getting around to making the kernel config work for snapdragon x1e. Hopefully have a merge request in a couple of hours
[16:04:47] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[16:06:55] -!- drathir_tor has joined #archlinux-ports
[17:29:39] <SpieringsAE_sff> is there a way to make mkinitcpio include all kernel modules?
[17:29:54] <SpieringsAE_sff> I removed autodetect, but it only include 1024 modules
[17:30:25] <SpieringsAE_sff> I think that is what is messing me up
[18:39:02] <bschnei> hrdl: my understanding is that could work too. Be aware that we may even use that approach to build the aarch64 config in future. That is, we may have a file that has *only* the options that need to be changed to go from a aarch64 defconfig derived from the full x64 config. So even though heftig kindly made room for multiple config files, it is still TBD how non-x64 configs get maintained long-term.
[18:41:49] <bschnei> but just like you and solskogen realized: that doesn't solve the problem of the device not actually being supported by the kernel. If supporting a device is just a matter of enabling config options...well then that should go into the official config anyway :)
[18:45:16] -!- binarycraft has joined #archlinux-ports
[18:50:30] <bschnei> solskogen: I actually think we're on the same page. The question of non-x64 device support is one where there are already good guidelines: https://rfc.archlinux.page
[18:50:31] <phrik> Title: 0032 Arch Linux Ports | Arch Linux RFCs (at rfc.archlinux.page)
[18:54:07] <bschnei> also "When devices of a port do not (or cannot) support a boot flow following the Boot Loader Specification, documentation and (if applicable) packages for the boot process must be provided."
[18:56:12] <bschnei> The Pi5 falls into this camp due to it's factory bootloader not using the BLS.
[18:57:23] -!- binarycraft has quit [Quit: WeeChat 4.8.1]
[19:46:15] -!- drathir_tor has quit [Remote host closed the connection]
[19:46:41] -!- drathir_tor has joined #archlinux-ports
[21:24:48] -!- linkmauve has parted #archlinux-ports
[21:36:07] -!- linkmauve has joined #archlinux-ports
[23:10:15] -!- titus_livius has joined #archlinux-ports