2026-04-01 12:59:08 <WhyNotHugo> Would appreicate further feedback on !87735
2026-04-01 13:03:47 <eletrotupi> heya, any low hanging fruits for packages to grab? i feel like i could add one or another to my roster
2026-04-01 14:12:27 <ikke> eletrotupi: It works best if you work on packages that you want and use yoursefl
2026-04-01 14:12:29 <ikke> Yourself
2026-04-01 14:24:58 <WhyNotHugo> eletrotupi: also check if any packages which you're using are unmaintained
2026-04-01 14:48:21 <eletrotupi> aight
2026-04-02 14:10:56 <cousin_luigi> Greetings.
2026-04-02 14:12:28 <jahway603[m]> Any idea why Anitya package flagging for Nextcloud is not working? https://release-monitoring.org/project/11062/
2026-04-02 14:12:28 <jahway603[m]> There was a new release today, but it did not flag the previous version - so now it's two releases behind with no indication on pkgs.alpinelinux.org
2026-04-02 14:15:49 <cousin_luigi> I'm kind of new to alpine, do you think there's margin of improvement here https://paste.rs/yaz9r ?
2026-04-02 15:14:57 <bl4ckb0ne> is it expected to not have more than one version of llvm-dev installed? there's a confict with llvm-test-utils
2026-04-02 15:15:26 <bl4ckb0ne> im trying to somehow use both llvm16-dev and llvm22-dev
2026-04-02 15:15:37 <bl4ckb0ne> non dev packages install fine though
2026-04-02 15:20:23 <bl4ckb0ne> hm im missing clang-opencl anyway, looks like i got no choice to build llvm16
2026-04-02 16:30:30 <quinq> Hi
2026-04-02 16:30:44 <quinq> I'm not sure how to create a merge request
2026-04-02 16:30:53 <quinq> I followed this: https://wiki.alpinelinux.org/wiki/Creating_patches#Creating_a_merge_request
2026-04-02 16:31:14 <quinq> But it seems it ends up creating a merge request to my “fork” instead of the main repository
2026-04-02 16:34:08 <quinq> How am I supposed to submit a merge request to the actual main repository?
2026-04-02 16:34:56 <ikke> quinq: you fork aports, create and push a branch to your fork, then create a merge request (unless the fork is private, it should by default target the original repo)
2026-04-02 16:35:09 <quinq> Ahhh, it is private
2026-04-02 16:35:39 <quinq> I can't submit a merge request unless I expose the entire repository?
2026-04-02 16:40:16 <quinq> ok, I think I found out how to do it
2026-04-02 16:41:19 <quinq> Yes, had to redo the merge request, and edit the branches
2026-04-02 16:41:22 <quinq> Thanks for the hint, ikke :)
2026-04-02 17:04:42 <bl4ckb0ne> is `export CXXFLAGS="$CXXFLAGS ...` the right way to insert a flag in a cmake build? 
2026-04-02 18:12:57 <Sertonix[m]> It is more common to only change CXXFLAGS for the cmake configuration command and avoid polluting the environment with export
2026-04-02 21:14:38 <raspbeguy> Good evening, do you know if re-building python packages ils over jet ? 
2026-04-02 21:14:47 <raspbeguy> Yet*
2026-04-02 21:27:58 <quinq> I heard it's ready for main and community, but some packages from testing remain to be done
2026-04-02 21:28:30 <quinq> (and the riscv64 packages might need a bit more time, not sure)
2026-04-02 21:33:18 <raspbeguy> OK thanks
2026-04-02 21:36:39 <quinq> You're welcome :)
2026-04-02 22:04:12 <omni> #18025
2026-04-02 23:14:16 <craftyguy[m]> could a maintainer please take a look at !99341
2026-04-03 06:22:07 <JustSouptheyhe[m]> Would it be possible to split libgcc into a subpackage of gcc so the whole compiler isn't pulled in? postmarketOS builds mainline kernels with LLVM, but some of our kernels are old and try to select GCC over Clang if it is in the environment. Because clang depends on the whole of gcc for libgcc, this is always the case. This isn't asking to build clang with compiler-rt or anything, that's a whole different thing, but just to
2026-04-03 06:22:07 <JustSouptheyhe[m]> split libgcc so it can stand without the whole of gcc.
2026-04-03 06:27:52 <JustSouptheyhe[m]> To clarify, I mean libgcc-dev specifically, not libgcc, which is already a subpackage.
2026-04-03 10:30:49 <Sertonix[m]> Would that have a follow up request to remove gcc from build-base?
2026-04-03 10:33:16 <Sertonix[m]> <JustSouptheyhe[m]> "Would it be possible to split..." <- Can't you just explicitly specify the compiler you want to be used?
2026-04-03 10:34:14 <JustSouptheyhe[m]> Sertonix[m]: We don't need to remove gcc from build-base because we can just not install build-base. Nothing would change on the Alpine side except needing to list `libgcc-dev` instead of `gcc` for some of the packages that depend on it.
2026-04-03 10:35:44 <JustSouptheyhe[m]> Sertonix[m]: That's what `LLVM=1` is for, but some older kernels do not properly support this option. The individual variables can be used, but that doesn't always work that well.
2026-04-03 10:38:05 <JustSouptheyhe[m]> This isn't me trying to betray y'all's trust and sneak LLVM into the toolchain. There's just a problem pmOS is facing and I wanted to know if we needed to hack around it downstream or if y'all would be okay with a fix upstream.
2026-04-03 12:45:47 <knuxify|m> Achill[m]: do you happen to have the test failure logs that led to c2583564ff ("testing/memray: disable tests")?
2026-04-03 15:01:54 <WhyNotHugo> I've often wondered if we can remove build-base from being an "implicit" dependency for all packages and declare it explicitly when required.
2026-04-03 15:02:17 <WhyNotHugo> For example, many Python packages don't depend on it, so installing all of build-base for every single one is a lot of pointless churn.
2026-04-03 15:13:38 <ikke> WhyNotHugo: build-base is already present both in the builders and CI
2026-04-03 15:14:06 <WhyNotHugo> But it gets installed on each run for `abuild rootbld`, for example
2026-04-03 15:15:30 <ikke> It would require auditing / modifying a lot of packages, just for rootbld
2026-04-03 15:16:33 <ikke> I mean, we may eventually go there, but it's not a short-term project
2026-04-03 15:55:49 <proycon> Is anybody able to look at this MR? the signal-cli in Alpine just failed because signal itself changed something, this updated version from upstream should allow people to fix it: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100034
2026-04-03 16:00:01 <ikke> Allow people to fix it? Or do you mean that they can upgrade to this version to fix it?
2026-04-03 16:01:34 <proycon> yes, they need this version to reregister with signal
2026-04-03 16:02:03 <proycon> signal deregistered old accounts, I just got disconnected about 1h30m ago
2026-04-03 16:02:25 <proycon> this issue explains it: https://github.com/AsamK/signal-cli/issues/1993
2026-04-03 16:02:53 <proycon> so I'm hoping with the latest signal-cli version I can register
2026-04-03 16:03:16 <proycon> but it wasn't in Alpine yet so hence the MR ;)
2026-04-03 16:03:31 <ikke> Waiting for feedback from the maintainer
2026-04-03 16:03:42 <proycon> ok
2026-04-03 16:15:53 <Sertonix[m]> WhyNotHugo reducing/removing build-base is a difficult task. Removing git from rootbld already exposed many implicit makedependencies. And I expect there to be a lot more once abuild doesn't depend on GNU tar anymore. I would be in favor of first fixing such implicit dependencies before looking at build-base
2026-04-03 16:23:01 <Sertonix[m]> Having build-base instead of gcc explicitly was also one thing which helped when bootstrapping alpine from chimera.
2026-04-03 16:25:17 <Sertonix[m]> But aside from some difficulties I support that
2026-04-03 16:57:08 <ikke> WhyNotHugo: https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/153
2026-04-03 16:57:15 <ikke> Draft: feat(services): Add service to comment on soname changes 
2026-04-03 16:57:32 <ikke> It's not finished yet, but making progress
2026-04-03 17:01:53 <ikke> Feedback welcome
2026-04-03 17:03:15 <ikke> proycon: the maintained acked, merging it now
2026-04-03 17:03:31 <proycon> thanks!
2026-04-03 19:17:04 <WhyNotHugo> Sertonix[m]: "Having build-base instead of gcc explicitly" ← didn't quite understand that.
2026-04-03 19:41:56 <WhyNotHugo> Looking at checkapk, I think we can diff the old/new `nm -D --defined-only --format=posix /usr/lib/libzstd.so.1.5.7 | awk '{print $1}'` to ascertain whether symbols have changed in a sofile.
2026-04-03 19:56:18 <ikke> Maybe a good addition to checkapk
2026-04-03 20:00:07 <sam_> I would consider using libabigail's abidiff if possible
2026-04-03 20:00:14 <sam_> it's much more robust and handles other ABI breaks
2026-04-03 20:08:15 <Sertonix[m]> WhyNotHugo: If build-base were to be removed packages would probably specify makedepends_build=gcc. But when cross compiling from chimera the CBUILD C compiler is clang. The build-base abstraction allows that to not be an issue at the moment