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

Back
[00:35:01] -!- drathir_tor has quit [Remote host closed the connection]
[00:35:20] -!- drathir_tor has joined #archlinux-ports
[03:18:11] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[03:18:53] -!- drathir_tor has joined #archlinux-ports
[04:04:30] -!- hcmb_ has joined #archlinux-ports
[04:04:30] -!- hcmb has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
[04:04:30] hcmb_ is now known as hcmb
[04:23:07] <bschnei> heftig, dvzrz: saw your comments re: devtools. If it's any help in troubleshooting, docker has had aarch64 in arch() for a few years already: https://gitlab.archlinux.org
[04:23:08] <phrik> Title: upgpkg: 1:20.10.18-1 (f149fe3d) · Commits · Arch Linux / Packaging / Packages / docker · GitLab (at gitlab.archlinux.org)
[04:23:56] <heftig> bschnei: no, this is specifically about having subpackages where the arch does not include x86_64
[04:24:06] <bschnei> got it. thanks for clarifying!
[04:24:41] <bschnei> also haven't had the chance to say thank you for the work on the linux package. I haven't had a chance to test yet, but I will.
[05:01:49] -!- hcmb_ has joined #archlinux-ports
[05:01:49] hcmb is now known as Guest130
[05:01:49] -!- Guest130 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
[05:01:49] hcmb_ is now known as hcmb
[06:00:20] -!- cjc7373 has quit [Remote host closed the connection]
[07:12:28] -!- SpieringsAE has joined #archlinux-ports
[07:45:27] -!- solsTiCe has joined #archlinux-ports
[08:44:07] <DrZee> @antiz - could you have a look at the MR i have pendling for an update to the ports page? thanks!
[08:44:44] <Antiz> DrZee: Ah sorry, we got an issue with GitLab, I got unassigned from that repo. I'll fix it that.
[08:44:51] <Antiz> DrZee: Do you have a link? :)
[08:46:02] <DrZee> https://gitlab.archlinux.org
[08:46:03] <phrik> Title: Updated section about Arch Array and when its ok to have more architectures in there (!7) · Merge requests · Arch Linux / Ports / docs · GitLab (at gitlab.archlinux.org)
[08:46:13] <Antiz> Thanks
[08:58:45] <Antiz> DrZee: Not a big deal, but for next time it would be nice to open MR from another branch than main on your fork
[08:59:40] <Antiz> So we can rebase / apply changes on top of your branch. But because main is protected by default (including on forks), we can't.
[09:00:17] <Antiz> DrZee: LGTM now, thanks for the changes :)
[09:02:14] <DrZee> Not super experienced in git ... not an SDE ... need a crash course one day
[09:03:10] <Antiz> No problem, not a big deal. But yeah, you should be able to just create a branch on your fork, and just work on said branch and open your MR from that branch as well.
[09:04:14] <Antiz> DrZee: One last change required to please the CI ^^
[09:04:18] <Antiz> Then we merge ;)
[09:04:29] <Antiz> For the other CI warning, I'll address it myself in a separate MR
[09:04:59] <Antiz> DrZee: Unless you wanna do it yourself?
[09:05:56] <DrZee> yeah I did see that warning about list not sure what it wanted me to do .... the other lint warning us about spelling of pacman an subpackage wich understand less ...
[09:06:16] <Antiz> DrZee: You just need to add "[Pp]acman" and "[Ss]ubpackage" to the this file:
[09:06:20] <Antiz> https://gitlab.archlinux.org
[09:06:21] <phrik> Title: config/vocabularies/content/accept.txt · main · Niels P / docs · GitLab (at gitlab.archlinux.org)
[09:06:30] <Antiz> So to tell the linter that those words are okay and can be ignored
[09:06:54] <DrZee> not aware there was such a file ...
[09:07:00] <Antiz> "[Ss]ubpackage[s]?" Actually
[09:07:10] <Antiz> So that the plural form is also covered
[09:07:53] <Antiz> CI should be green after that
[09:16:23] <Antiz> DrZee: Will you add those or should I do it myself separately? As you prefer :)
[09:17:06] <DrZee> working on it but my token expired to push
[09:17:29] <Antiz> Oh, okay ^^
[09:20:11] <DrZee> ok pushed ... although it used the name from the access token ...
[09:20:20] <Antiz> Thanks, merging :)
[09:35:22] <DrZee> how do I flatten my fork of a project so it no longer shows I'm ahead by the recent commits?
[09:45:23] <Antiz> DrZee: You should have an "update fork" button somewhere
[09:46:20] <Antiz> Top right, under the "Code" blue dropdown button
[09:47:19] <DrZee> yeah but even after that it still shows in ahead by xxx commits
[09:48:04] <DrZee> most likely I need to squash the commits?
[09:51:08] <Antiz> Ah well, this is another reason why you don't want to work from the main branch :P
[09:51:19] <Antiz> It makes rebasing on upstream a bit messier.
[09:51:46] <Antiz> I could explain to you how to rebase properly from CLI. But if you're not familiar with git, you could just delete your fork and recreate one.
[09:52:40] <Antiz> Then for next time, just click the "+" button next to the "Find file" button, create a new branch, and work from there. Should avoid you some overhead ;)
[09:55:15] -!- yjun123 has quit [Quit: Konversation terminated!]
[09:56:09] -!- yjun123 has joined #archlinux-ports
[09:57:55] <DrZee> just list out the cli commands and I figure it out ...
[09:59:49] <BrainDamage> git branch <mybranchname>; git checkout <mybranchname>
[10:00:10] <BrainDamage> this will create a branch with a copy of your history to this point, and switch to it
[10:00:28] <BrainDamage> check it all looks ok
[10:02:08] <BrainDamage> then optionally you can clean your master branch: git checkout master, git reset --hard <commit before you worked on it>
[10:02:58] <BrainDamage> check again that everything looks correct, and you can switch to your branch again, git checkout <mybranchname>
[10:03:31] <BrainDamage> from there you can rebase
[10:03:46] <Antiz> "git branch <mybranchname>; git checkout <mybranchname>" <-- Can be done in a single command BTW
[10:04:16] <BrainDamage> yeah, but I prefer to give them out separately to someone who's starting with git
[10:04:20] <Antiz> git checkout -b <mybranch> or git switch -c <mybranch>
[10:04:23] <Antiz> BrainDamage: Fair enough
[10:07:35] <BrainDamage> if you plan to do "destructive" work that rewrites history like a rebase, it's always a good idea to create a couple of dummy branch copies, you don't have to switch to them, just having them created makes sure that git will preserve a copy
[10:07:58] <BrainDamage> so before you start the actual rebase, do a git branch mybackup, just for safety
[10:11:09] <BrainDamage> and if you want to be extra paranoid, backup the whole repo by copying it, it's especially worth at start when you're not sure
[10:26:41] -!- yjun123 has quit [Read error: Connection reset by peer]
[10:26:51] -!- yjun123 has joined #archlinux-ports
[11:05:55] <anthraxx|M> BrainDamage: i mean definitely the most paranoid/safe way; however cleanup is mostly gated around long deltas like 30+ days. before it, if something was ever in an index and got a ref ever, you can restore via git reflog 😄
[14:13:14] <DrZee> thanks that allowed me to setup a bit better !
[15:54:41] -!- SpieringsAE has quit [Quit: SpieringsAE]
[16:05:14] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[16:07:07] -!- drathir_tor has joined #archlinux-ports
[16:18:26] -!- drathir_tor has quit [Ping timeout: 252 seconds]
[16:19:27] -!- drathir_tor has joined #archlinux-ports
[16:20:48] -!- m_a_r_k has quit [Remote host closed the connection]
[16:21:36] -!- m_a_r_k has joined #archlinux-ports
[16:28:46] -!- drathir_tor has quit [Remote host closed the connection]
[16:29:08] -!- drathir_tor has joined #archlinux-ports
[17:22:03] -!- linkmauve has parted #archlinux-ports
[17:22:05] -!- linkmauve has joined #archlinux-ports
[17:40:36] -!- solsTiCe has quit [Quit: The Lounge - https://thelounge.chat]
[17:44:22] -!- solsTiCe has joined #archlinux-ports
[21:24:46] <yuvadm> bschnei: what's the current approach we expect for multi-board support for aarch64? single vanilla "arch" kernel makes sense? single `linux-dtbs` package for all boards/devices though?
[23:10:20] -!- titus_livius has joined #archlinux-ports
[23:44:03] <bschnei> yuvadm: ya, :sigh: the dtbs are a real pain. For the first question, to the best of my knowledge Arch doesn't attempt to maintain device-specific kernels in official (i.e. core/extra) repos. There are certainly variants (like LTS), but x64 benefits from being a mature platform with considerably more standards than ARM.
[23:47:20] <bschnei> One of the main reasons I'm here at all today is the kernel for one of my devicse isn't being regularly maintained at ALARM. When I took a closer look and realized just how many kernels/devices they have in their repos and how much custom work has to be done, it started to become clear in my mind that it is slippery slope trying to add (and maintain!) support for devices that don't have mainline linux support and/or req
[23:47:20] <bschnei> uire lots of hacks to workaround special bootloaders.
[23:50:26] <bschnei> On the other hand, if you won't support anything besides mainline ARM devices, I think you'll have a hard time attracting and retaining a community. This does slowly seem to be changing, but that does seem to be the state of the world today. The Raspberry Pi 5 is the most notorious example. Very popular device among the DiY crowd. From a culture fit perspective, Arch seems like an obvious OS to want to use. But it has a
[23:50:26] <bschnei> proprietary bootloader and isn't (yet) fully supported by mainline linux.
[23:52:02] <bschnei> The pragmatic approach (to me, at this point and time and based on my very limited experience) is package a linux kernel for official repos that will work on mainline supported devices and encourage users of popular non-mainline devices to package and maintain kernels on the AUR.
[23:53:36] <bschnei> I believe this can help bring Arch to more devices by encouraging people that have them and want to run Arch on them, to contribute and participate here which I also believe to be a Good Thing
[23:54:47] <bschnei> Simultaneously, it avoids placing the burden of trying to maintain all kinds of custom kernel packages (and configurations/bootloader hacks) on Arch staff who may or may not actually a device in question.
[23:55:28] <bschnei> may not actually own* a device in question.
[23:57:44] <bschnei> Regarding DTBs, I haven't seen how big the package can get if you enable all platforms. DTBs only get built for a platform if that platform is enabled in the kernel config. So as it stands, it's quite small which should mean installing it to /boot shouldn't be a problem even for devices with relatively small boot partitions. However, it's entirely possible that at some point in the future it has to be split up akin to l
[23:57:44] <bschnei> inux-firmware in order to reduce individual package size.