#archlinux-ports | Logs for 2026-07-16

Back
[00:07:21] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[01:22:37] -!- marmis has quit [Quit: Bye!]
[01:24:13] -!- marmis has joined #archlinux-ports
[01:39:25] -!- Charon77|PC has joined #archlinux-ports
[02:09:29] -!- Charon77|PC has quit [Ping timeout: 245 seconds]
[02:25:44] -!- rafael_bento has quit [Ping timeout: 245 seconds]
[02:38:46] -!- solsTiCe has quit [Quit: Ping timeout (120 seconds)]
[02:39:05] -!- solsTiCe has joined #archlinux-ports
[03:03:50] -!- cjc7373 has joined #archlinux-ports
[03:17:37] -!- idealseal has quit [Ping timeout: 276 seconds]
[03:17:43] -!- idealseal_ has joined #archlinux-ports
[04:00:47] -!- hcmb_ has joined #archlinux-ports
[04:00:47] hcmb is now known as Guest46
[04:00:47] -!- Guest46 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
[04:00:47] hcmb_ is now known as hcmb
[04:27:35] <bschnei> greyltc: if you want to orient yourself I would read: https://ports.archlinux.page
[04:27:37] <phrik> Title: Aarch64 | Arch Linux Ports (at ports.archlinux.page)
[04:28:23] <greyltc> thank you, I have read that
[04:31:55] <bschnei> what are you looking for specifically? most packages do not need forks to build
[04:33:37] <greyltc> for example a package for u-boot seems like a good fit
[04:35:37] <bschnei> We don't have a package for u-boot. That is typically device specific firmware that has to be compiled specific to a device and device-specific packages are things that tend to live in the AUR.
[04:40:54] <greyltc> It seems like aarch64 is probably going to need a number of device specific packages
[04:43:48] <bschnei> Modern U-Boot supports UEFI and it works out-of-the-box with linux as packaged for x64 and systemd-boot. So it's really a question of which devices with non-standard bootloaders the community wants to support. https://gitlab.archlinux.org for even more context :)
[04:43:50] <phrik> Title: Determine minimum required instruction sets (#6) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[04:46:09] <greyltc> also, I was under the impression that non x86_64 packages are barred from the AUR
[04:46:15] <bschnei> oops and https://gitlab.archlinux.org
[04:46:16] <phrik> Title: Determine boot loader support (#7) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[04:47:34] <greyltc> the community wants to support Raspberry Pi 5
[04:47:58] <bschnei> I haven't heard of a change in that policy yet but I don't follow the mailing lists closely where those kinds of changes are often announced. Device specific packages are just scattered about in random places currently and I have been a vocal proponent of providing a home for that work on the AUR for quite some time.
[04:48:27] <greyltc> That AUR rule is on the wiki: https://wiki.archlinux.org
[04:48:28] <phrik> Title: AUR submission guidelines - ArchWiki (at wiki.archlinux.org)
[04:48:39] <bschnei> rpi5 support is already there: https://github.com :)
[04:48:40] <phrik> Title: GitHub - bschnei/linux-rpi5 · GitHub (at github.com)
[04:49:04] <bschnei> I've had it running on one since I think January
[04:50:29] <greyltc> I'm just thinking that a u-boot layer might let the pi5 fall more in line with other aarch64 boards that have more friendly bootloaders
[04:51:27] <bschnei> Indeed. UEFI support (through u-boot or edk2) would be great, but solskogen and I were also of the opinion that we wanted to support users who didn't necessarily want to flash their firmware so that's what linux-rpi5 is for.
[04:51:59] <bschnei> https://github.com
[04:52:00] <phrik> Title: GitHub - worproject/rpi5-uefi: EDK2 firmware images for Raspberry Pi 5 · GitHub (at github.com)
[04:52:09] <greyltc> you mean rewrite their eeprom?
[04:52:13] <bschnei> ^ was a thing at one point, but I'm not sure what happened
[04:52:20] <bschnei> yes
[04:53:20] <greyltc> here's a arch package if you want to try it: https://github.com
[04:53:22] <phrik> Title: Release syntax fix test build · greyltc/rpi5-uefi · GitHub (at github.com)
[04:54:34] <greyltc> I followed a fork and made a small fix so that it compiles. It runs on my pi5. Can't say I've fully tested it though
[04:55:18] <greyltc> That's another example of something that might belong in https://gitlab.archlinux.org
[04:55:19] <phrik> Title: AArch64 · GitLab (at gitlab.archlinux.org)
[04:56:57] -!- drathir_tor has joined #archlinux-ports
[04:57:38] <bschnei> Very cool! I don't use my pi5 that much anymore :/ The novelty wore off when I got Arch running on it and it's collecting dust. I mostly work on an ARM cloud server so I can use the v8.2 packages that are avaialble and use that server to maintain a subset of packages for v8 for an ARM router I have at home. But I'm supportive of the idea that your package should have a home on the AUR.
[04:58:19] <bschnei> It's a fair question. I really don't know what the ideal location is for "device-specific documentation"
[04:58:28] <bschnei> Traditionally in x64 land that's the ArchWiki
[04:58:46] <bschnei> e.g. https://wiki.archlinux.org
[04:58:47] <phrik> Title: System76 Pangolin pang12 - ArchWiki (at wiki.archlinux.org)
[04:59:23] <bschnei> However, I also have no objections to documentation being added to the ports page. It'd likely be up to Antiz to make a call on what makes sense
[05:01:33] <bschnei> Contributions to either place I'm sure would be welcome
[05:01:57] -!- marmis2 has joined #archlinux-ports
[05:02:17] <bschnei> I prefer markdown to wikicode personally :)
[05:03:17] <greyltc> agreed!
[05:04:06] -!- marmis has quit [Ping timeout: 252 seconds]
[05:04:07] marmis2 is now known as marmis
[05:05:30] <greyltc> btw, you don't need to flash anything to use uboot or rpi5-uefi on a pi5
[05:05:40] <greyltc> is that what you were suggesting earlier?
[05:05:40] <bschnei> chainload?
[05:05:56] <bschnei> mhm
[05:06:03] <greyltc> yeah. i mean you can just tell the pi via config.txt to boot them
[05:06:46] <bschnei> gotcha. I was unaware. Could be an excellent solution for long-term support
[05:06:58] <greyltc> eg https://github.com
[05:08:00] <greyltc> i'd be worried about bricking my pi flashing some poorly maintained community crap onto it
[05:08:03] <bschnei> interesting and device trees get provided by?
[05:08:06] <greyltc> they're expensive these days!
[05:08:12] <bschnei> no joke
[05:09:52] <greyltc> i'm pretty sure uboot finds the device tree files it needs on the boot partition
[05:10:06] <greyltc> so maybe the kernel package would provide those
[05:10:17] <bschnei> You might also want to look into the stubble project. I think it's similar in spirit. I.e. have a layer that sits between device-specific stuff and generic distro packages.
[05:10:37] -!- drathir_tor has quit [Remote host closed the connection]
[05:11:08] <greyltc> yeah, all three sound similar
[05:11:32] -!- drathir_tor has joined #archlinux-ports
[05:11:38] <greyltc> I haven't heard of stubble, I'll check it out, thanks!
[07:34:41] -!- h|ignition has quit [Ping timeout: 252 seconds]
[07:36:27] -!- h|ignition has joined #archlinux-ports
[07:41:17] -!- h|ignition has quit [Ping timeout: 252 seconds]
[07:58:07] -!- h|ignition has joined #archlinux-ports
[13:16:31] -!- _d4s has joined #archlinux-ports
[13:31:17] -!- fermino has quit [Read error: Connection reset by peer]
[13:31:29] -!- fermino has joined #archlinux-ports
[13:36:39] _d4s is now known as d4s
[16:02:13] -!- SpieringsAE_sff has quit [Quit: SpieringsAE_sff]
[16:03:37] -!- SpieringsAE_sff has joined #archlinux-ports
[18:52:31] -!- julemand101 has quit [Quit: WeeChat 4.9.3]
[18:53:21] -!- julemand101 has joined #archlinux-ports
[19:37:35] -!- hch12907 has quit [Quit: Ping timeout (120 seconds)]
[19:37:55] -!- hch12907 has joined #archlinux-ports
[22:10:13] -!- titus_livius has joined #archlinux-ports
[23:23:06] -!- linkmauve has quit [Remote host closed the connection]
[23:29:03] -!- linkmauve has joined #archlinux-ports
[23:42:23] -!- linkmauve has quit [Remote host closed the connection]
[23:49:17] -!- linkmauve has joined #archlinux-ports