#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 😄