#archlinux-ports | Logs for 2025-08-07

Back
[08:26:49] -!- marmis has quit [Quit: Bye!]
[08:28:56] -!- marmis has joined #archlinux-ports
[08:38:22] -!- marmis has quit [Quit: Bye!]
[08:40:19] -!- marmis has joined #archlinux-ports
[09:14:36] <Solskogen> gromit: https://gitlab.archlinux.org - could you take a look? :-)
[09:14:37] <phrik> Title: upgpkg: 0.4.6-1 (!1) · Merge requests · Arch Linux / Packaging / Packages / cern-vdt · GitLab (at gitlab.archlinux.org)
[09:18:37] <Antiz> Solskogen: I'm on it
[09:18:53] <Antiz> Is Benjamin here?
[09:46:19] <Solskogen> on the other note, chmlib requires a small change in order for it to work on aarch64. Do you prefer a patch or a sed in a MR?
[09:46:58] <Solskogen> Antiz: he was (bschnei)
[09:47:36] <Antiz> I don't see him connected right now, I'll just leave a comment in the MR :)
[09:47:55] <Solskogen> he's in the US so it's about 3 in the morning there.
[09:48:16] <Solskogen> I might be able to answer if you have questions regarding that MR
[09:48:17] <Antiz> Ah ok
[09:48:49] <Antiz> I don't have questions, but the MR needs to be revised / redone basically (to match our packaging merge request guidelines) :/
[09:50:58] <Solskogen> I see. I'm wondering what has to be changed, because it looks good to me (which doesn't relly mean anything)
[09:51:13] <Antiz> I'm writing a comment on the MR, but to sum up:
[09:51:25] <Antiz> 1 - We do not accept merge request for trivial version bump. Merge requests should be units of changes rather than units of releases. Except for specific cases, release related variables (`pkgver`, `pkgrel`, `epoch`) should remain untouched.
[09:52:11] <Antiz> (see the last bullet point at https://wiki.archlinux.org)
[09:52:12] <phrik> Title: General guidelines - ArchWiki (at wiki.archlinux.org)
[09:52:43] <Solskogen> Ok, I understand. I was just thinking it's a MR that kills to birds with one stone.
[09:52:58] <Antiz> Yes, that's the second issue
[09:53:08] <Antiz> I mean, it kills 3 birds with one stone
[09:53:38] <Antiz> The first bird (package update) shouldn't be killed
[09:53:39] <Solskogen> What's the third one? :)
[09:53:47] <Antiz> The second bird (the cmake fix) should be in its own MR
[09:54:40] <Antiz> The third bird (the port specific fix) should be clearly highlighted (e.g. it doesn't appear in the MR title or description) and should be in its own MR too
[09:54:59] <Solskogen> Ok, noted.
[09:55:11] <Antiz> As we want all secondary architecture related merge-requests to be flagged with
[09:55:11] <Antiz> the new `pkg::ports` GitLab label.
[09:55:50] <Antiz> So ideally someone should resubmitted the cmake and the port specific fix in their own MR :)
[09:55:55] <Antiz> Then I can merge + bump the package ;)
[09:58:46] <Solskogen> In that regard, should I use that label on this? https://gitlab.archlinux.org - because it's not needed on x86_64, but it is on aarch64 for some strange reason (and probably other 64bit architectures as well)
[09:58:48] <phrik> Title: force libdir to be /usr/lib so that it never tries to use /usr/lib64 (!1) · Merge requests · Arch Linux / Packaging / Packages / xmms2 · GitLab (at gitlab.archlinux.org)
[09:59:13] <Antiz> From my understanding, yes.
[09:59:24] <Antiz> Although... I don't see that label available from the list 😅
[09:59:51] <Antiz> I'll ping people about it, to see if we can fix it x)
[10:00:30] <Solskogen> Yeah, I was looking for it as well :-)
[10:01:27] <Solskogen> it doesn't look (at least not on the first glance) that I can add any labels.
[10:02:18] <Antiz> Yes, I think it's up to the assignee on our side to add it.
[10:02:31] <Antiz> Although, we can't do that either as it doesn't exists yet apparently ^^
[10:05:21] <Antiz> Solskogen: I left a comment on Benjamin's MR for transparency and I also pinged some people about the missing label.
[10:05:27] <Antiz> I'll let you know
[10:06:52] <Antiz> As for `sed` vs patch files, it depends on how small the changes are. If it's a really small / trivial change, `sed` is fine.
[10:07:46] <Antiz> Although, I personally prefer patch files as `sed` is a bit more "opaque" (as it doesn't really the context in which the change is applied within the file) and, more importantly, it can fail silently.
[10:08:47] <Antiz> So I tend to use patch files everytime on my side (out of security), but this is more of a personal preference thing. Again, for small / trivial changes, sed is fine :)
[10:09:22] <Solskogen> Let me try and see what the maintainer says
[10:11:35] <Antiz> 👍
[10:33:45] <Antiz> Solskogen: https://gitlab.archlinux.org <-- Can you highlight somewhere that this is required for ports?
[10:33:47] <phrik> Title: force libdir to be /usr/lib so that it never tries to use /usr/lib64 (!1) · Merge requests · Arch Linux / Packaging / Packages / xmms2 · GitLab (at gitlab.archlinux.org)
[10:34:44] <Antiz> As we are missing the dedicated label for now, it'd be great to make clear that this a change related to ports.
[10:35:09] <Antiz> Actually, even with the label, making this clear from the MR description wouldn't hurt IMO :)
[10:35:25] <Antiz> I'll merge it and rebuild the package once you're done ;)
[10:38:29] <Antiz> (The MR desc, or from the commit message directly, even better probably)
[11:02:32] <Solskogen> Ok, thanks again! Will do better next time.
[11:04:06] <Antiz> That's okay, thanks for your comprehension and your work :D
[11:04:59] <Antiz> BTW, feel free to ping if some MRs are unassigned or are not getting reviewed. I'm happy to help wherever I can :)
[11:09:30] <Solskogen> Ok, will do. I guess gromit is happy with that :-) He's the one I've been nagging when "nothing" happens.
[11:10:33] <Antiz> Haha yeah, let's split the load :P
[11:11:51] <Solskogen> I have a more than a handfull of uncommited fixes that fixes stuff that used to work but now ftbfs. do you guys want MRs for that? When ever I come across things like that I always try to compile it on my x86_64 machine as well, just to be sure that it's not a aarch64 issue.
[11:12:26] <Antiz> Sure, sounds good!
[11:13:03] <Antiz> I kinda wish we would do some "world rebuilds" from time to time to detect those actually 😅
[11:13:20] <Solskogen> it's a issue for us when ever a package doesn't build (because we don't have it) - but I'm not so sure if it's taken seriously.
[11:13:40] <Solskogen> yes! that would helped a lot.
[11:13:49] <Solskogen> But ok, I'll do that from now on.
[11:13:55] <Antiz> Nah, I mean, if a package fails to build on x86_64, it **has** to be addressed.
[11:14:37] <Antiz> So yeah, please don't hesitate to open MR for those :)
[11:16:56] <Solskogen> and a issue if I'm not able to fix it?
[11:17:37] <Antiz> Yes, so at least it's reported somewhere.
[11:18:18] <Antiz> I assume some packages simply cannot be fixed (because they hardly depends on some old versions of dependencies or something). In that case, we could consider dropping it.
[11:18:46] <Antiz> (if it isn't required by any other package, obviously)
[12:06:24] <Solskogen> Ok, so kubernetes is just downloading a (broken) version of go for aarch64 instead of just using the one that is already installed.
[14:48:24] -!- flx has quit [Server closed connection]
[14:48:48] -!- fsinger has joined #archlinux-ports
[18:52:57] -!- marmis has quit [Quit: Bye!]
[18:55:42] -!- marmis has joined #archlinux-ports
[20:26:29] -!- marmis has quit [Quit: Bye!]
[20:27:31] -!- marmis has joined #archlinux-ports
[23:48:24] -!- txtsd has quit [Server closed connection]
[23:54:16] -!- txtsd has joined #archlinux-ports