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
2026-04-03 22:12:35 <Shiz> Sertonix[m]: sounds like ideally a job for a virtual package eventually
2026-04-03 22:12:53 <Shiz> provides=virtual/cc or something of that kind
2026-04-03 22:16:44 <quinq> Also what does Alpine ports have to do with Chimera
2026-04-03 22:16:48 <quinq> s/does/do/
2026-04-03 22:26:44 <Sertonix[m]> Shiz: Probably, yes
2026-04-03 22:28:41 <Sertonix[m]> quinq: It's the only example I am aware of where alpine has been bootstrapped on and that mainly uses clang.
2026-04-03 22:36:01 <Shiz> I have a branch from 2017 or so of aports that used clang
2026-04-03 22:36:04 <Shiz> way back when :p
2026-04-03 23:49:35 <WhyNotHugo> Sertonix[m]: I see. So either we'd have to add an explicit "makedepends=gcc" (not ideal), or makedepends="cc" and deal with provider priority…?
2026-04-03 23:52:58 <Sertonix[m]> We probably don't need to deal with provider priority since only having a single (packaged) provider for cc is fine for alpine.
2026-04-04 00:45:24 <RavFX[m]> Hi, I have a question about the process to commit new package on Alpine community repo. 
2026-04-04 00:45:24 <RavFX[m]> Mainly, do I have to assing someone after creating the merge request? It's my first time adding a new package, before I did only update packages and someone got assigned automatically.
2026-04-04 00:46:10 <RavFX[m]> That's the purge request in question : https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99676
2026-04-04 00:46:10 <RavFX[m]> Also, sometime the CI stuff "timed out", And I have to manually restart them.
2026-04-04 00:47:53 <RavFX[m]> s/purge/merge/g
2026-04-04 01:00:02 <skarnet> you don't have to assign someone, it just pings them when you do it
2026-04-04 01:00:15 <skarnet> unless it's urgent, just leave it as is
2026-04-04 01:00:48 <skarnet> but asking for a review here does work
2026-04-04 01:00:58 <skarnet> a dev will take a look whenever they have time :)
2026-04-04 01:04:53 <RavFX[m]> oh cool, thanks.
2026-04-04 01:04:53 <RavFX[m]> Is there a parameter to make these package mutually exclusive (you install one, or you install the other)
2026-04-04 01:04:53 <RavFX[m]> Monero-gui include everything that come with community/monero
2026-04-04 01:04:53 <RavFX[m]> Other question, I am making an APKBUILD for Monero-gui.
2026-04-04 01:05:57 <RavFX[m]> Or I should make monero-gui depend on monero and just install the monero-gui binary
2026-04-04 01:34:19 <skarnet> it depends on several factors, but if you have a way to avoid negative dependencies, I'd say it's better. Do the latter if possible.
2026-04-04 03:07:12 <comk> RavFX[m]: One option is to have one APKBUILD which outputs both monero-cli and monero-gui if they are built from same source. Perhaps existing monero APKBUILD could be modified.
2026-04-04 03:08:58 <RavFX[m]> Could be a solution. Can it be made to only install monero-cli/monerod if someone install monero but don't want the GUI (that later require QT and all the tralala)
2026-04-04 03:09:31 <RavFX[m]> if you can link me to the doc to do such thing it would be nice comk
2026-04-04 03:11:04 <comk> RavFX[m]: yes it can. the resulting packages can be the same result as from split, it only affects build 
2026-04-04 03:12:19 <RavFX[m]> Nice to know, that would be ideal yeah
2026-04-04 03:13:59 <comk> its explained a bit in man APKBUILD, search for subpackages
2026-04-04 03:14:00 <comk> https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Multiple_Subpackages
2026-04-04 03:14:42 <RavFX[m]> Thanks!
2026-04-04 03:18:29 <RavFX[m]> And once I am done, what is the process?
2026-04-04 03:18:29 <RavFX[m]> Do I update the one in community or I make the replacement in testing (and it won't conflict)?
2026-04-04 03:18:29 <RavFX[m]> as I have to add new stuff in testing but monero is in community.
2026-04-04 08:38:15 <bratkartoffel> I got a little problem and don't know how to make this right. !100034 introduced an incompatible upgrade of java-libsignal-client to 0.91.0, but signal-cli 0.14.1 is not compatible with that version. As I've backported this change to 3.23 already (!100044), I received some mails abouting this breaking stuff. Any ideas how I can downgrade the version or fix this situation?
2026-04-04 08:39:24 <bratkartoffel> I thought about "upgrading" the APKBUILD to pkgver=0.91.0.0.87.4 (and effectively use 0.87.4) but this looks quite wrong / ugly to me
2026-04-04 08:39:51 <bratkartoffel> But this would fix the error for now and when a new signal-cli release comes, I could easily remove this hack
2026-04-04 08:44:38 <bratkartoffel> any objections about this change? !100068
2026-04-04 09:46:05 <Sertonix[m]> bratkartoffel: Is there an upstream patch that could be backported?
2026-04-04 10:15:39 <omni> do we need to bump the pkgrel from what was before an upgrade when reverting an upgrade? !100068
2026-04-04 10:19:21 <ikke> omni: yes
2026-04-04 10:19:44 <omni> and should it be "community/java-libsignal-client: revert upgrade to 0.14.1"?
2026-04-04 10:20:04 <bratkartoffel> Sertonix[m]: there is no upstream patch yet, no.
2026-04-04 10:21:19 <bratkartoffel> "community/java-libsignal-client: revert upgrade to 0.91.0" sounds fine for me too, I can change it
2026-04-04 10:25:35 <omni> I meant 0.91.0
2026-04-04 10:41:35 <omni> bratkartoffel: there we go
2026-04-04 10:43:25 <bratkartoffel> omni: thank you, didn't know it was that easy to downgrade the aport. Thought about automatic updates and that the version must be incremented in all cases
2026-04-04 10:46:24 <omni> yeah, perhaps not obvious if you haven't done it before, and np
2026-04-04 10:55:04 <ikke> Well, users will not be automatically downgraded, they would have to provide --available with doing apk upgrade
2026-04-04 11:02:13 <bratkartoffel> ikke: that's what I meant, yes. As only one user has reported the issue (via mail) by now, there shouldn't be many affected users
2026-04-04 11:02:59 <ikke> correct
2026-04-04 11:03:09 <ikke> And if they are affected, you can tell them they need to provide --available
2026-04-04 11:19:01 <omni> well, I usually see reporting users as the tip of an iceberg :p
2026-04-04 11:20:41 <omni> both because most users don't report (wait for someone else to do it or a fix to arrive) and because it's impossible to estimate how many they are
2026-04-04 11:21:29 <bratkartoffel> i'm more on the optimistic side, as the easter holidays keep the people busy with their families ;)
2026-04-04 11:23:08 <omni> sure, and we got this downgrade (or reverted upgrade) in pretty fast, so chances are that not many upgraded and that those who did may know about, or have a havit of, using --available
2026-04-04 11:23:49 <omni> bratkartoffel: so I didn't mean to alarm you, I was more reasoning in general
2026-04-04 11:26:02 <bratkartoffel> no worries, I know what you meant. I'm just unhappy about how this happened. Should have verified the libsignal upgrade in the MR before approviing it. Missed that, but it won't happen again.
2026-04-04 11:56:24 <proycon> I hadn't realized 0.91.0 didn't work well with signal-cli 0.14.1, ran into that too this morning.. fortunately you already found the cause and reverted it
2026-04-04 11:57:17 <ikke> fyi, bratkartoffel already left the chat
2026-04-04 11:57:29 <proycon> ah yes
2026-04-04 20:34:29 <ayakael> Fixed the CI on dotnet10-sdk upgrade to 10.0.201 !99062
2026-04-04 21:30:42 <WhyNotHugo> Is buildlan (from abuild) still used? It seems to somewhat overlap with rootbld.
2026-04-04 23:47:12 <Sertonix[m]> I am not aware of it being used anywhere. I would be tempted to remove it at some point and see who complains
2026-04-04 23:48:43 <Sertonix[m]> (But I don't know the setup on the builders)
2026-04-04 23:59:41 <Sertonix[m]> ncopa: Has buildlab ever been more than a proof of concept?
2026-04-05 03:57:44 <WhyNotHugo> That's a very reliable technique.
2026-04-05 03:58:50 <WhyNotHugo> Also intentionally *not* upgrading absolutely all testing packages with the same rationale. Come back in 6 months and wipe anything which is still build with python3.12.
2026-04-05 13:58:45 <Hello> \o/
2026-04-05 13:59:00 <Hello> missing package from v3.21
2026-04-05 13:59:10 <Hello> into all mirrors...
2026-04-05 13:59:30 <Guest6621> python3 is missing
2026-04-05 13:59:57 <Guest6621> c u, I found solution for myself... have a nice day...
2026-04-05 15:29:05 <MrAdvert[m]> Humble greetings to all, here for a brief advert and not to take much of your time 🚨 ❄️ 
2026-04-05 15:29:05 <MrAdvert[m]> https://t.me/+c-LC9ed_hBgwYmZh
2026-04-05 15:29:05 <MrAdvert[m]> We got products available and many more. Check out the shop below to see products available and remember you owe yourself happiness.  join to get promo updates 👇 👇👇👇👇
2026-04-05 15:29:05 <MrAdvert[m]> Are you going through depression, anxiety and stress or a lover of cannabinoids and psychedelics or physique Enhancement products to be in shape?
2026-04-05 16:29:58 <ikke> arg
2026-04-05 22:15:17 <clipcarl> Hi!
2026-04-05 22:15:17 <clipcarl> Is this the proper place to ask a specific technical question about creating an APKBUILD for a package submission? I searched the online docs and didn't find an answer to my question.
2026-04-05 22:29:27 <skarnet> it sounds appropriate, yes :)
2026-04-05 22:37:30 <clipcarl> I'll be be submitting an APKBUILD for cksh, a very small (under 300k statically linked on x86_64) ksh-style shell with similar programming and interactive comfort features to bash, except much smaller, much faster and with a much more device developer friendly permissive license. This shell is used by a number of small and large useful programs / projects I will also be submitting, but needs to be 
2026-04-05 22:37:36 <clipcarl> accessed at /bin/cksh for compatibility reasons. Since Alpine is transitioning to /usr merge, I'd like advice on how to create the APKBUILD to achieve this. I see two possible approaches:
2026-04-05 22:37:40 <clipcarl> 1. Have APKBUILD place the binary in /bin . This is the simplest and probably the most reliable approach and I think should be directly compatible with both /usr merged and non /usr merged sytems.
2026-04-05 22:37:46 <clipcarl> 2. Have APKBUILD place the binary in /usr/bin and use post-install and post-deinstall scripts to add and remove symlinks on non /usr merged systems. This may be viewed more favorably for the /usr merge transition but may be more fragile.
2026-04-05 22:37:53 <clipcarl> Which is best? Is there another approach I'm missing?
2026-04-05 22:38:08 <Habbie> just the first question that comes to mind for me - how does the bash port handle it?
2026-04-05 22:38:37 <Habbie> i also wonder about the compatibility thing. bash generally survives not being /bin/bash on, say, FreeBSD
2026-04-05 22:40:33 <Habbie> .. so looking at how the freebsd cksh port handles things would also be interesting
2026-04-05 22:44:15 <clipcarl> I'm looking at bash's APKBUILD and it looks like it installs directly to /bin currently... Though I'm not seeing the bash binary itself but only the -dev binaries. I must be missing something.
2026-04-05 22:48:18 <clipcarl> I was hoping somewhere there was new guidance for shells specifically since where they reside on the FS needs to remain stable for compatibility.
2026-04-05 23:04:02 <Habbie> my best guess is that nobody wrote down explicit guidance for that because it doesn't come up that often
2026-04-05 23:04:35 <Habbie> i can also recommend submitting your APKBUILD as a merge request on gitlab, perhaps with your questions mentioned, so you can at least get anything besides those questions reviewed
2026-04-05 23:06:05 <Habbie> i also wonder if non-usrmerged systems even exist currently, or soon, but i don't know enough about Alpine for that
2026-04-05 23:06:57 <skarnet> For execline (which is not a shell but a similar interpreter) I did the latter: install the binary in /usr/bin and added conditional scripts to add symlinks to /bin in non-usrmerged setups. You can see it in the main/execline aport.
2026-04-05 23:07:40 <Habbie> oh nice
2026-04-05 23:12:34 <clipcarl> @Habbie I have very man non /usr merged systems. But my setup is pretty custom.
2026-04-05 23:12:40 <Habbie> right
2026-04-05 23:13:40 <clipcarl> @skarnet Yeah, that's what I was think for option #2: add post-install and post-deinstall scripts to manipulate symlinks.
2026-04-05 23:15:14 <clipcarl> Also the default Alpine minirootfs and container images are still non /usr merged, I believe
2026-04-05 23:20:47 <Habbie> huh, indeed. just two symlink collections (but that's because of busybox, not because of the merge)
2026-04-05 23:21:15 <Habbie> the only non-symlink in /bin on the container image is busybox
2026-04-05 23:21:28 <Habbie> 6 other non-symlinks in /usr/bin
2026-04-05 23:22:07 <clipcarl> But there *is* a /bin in the container image, right? So it's not /usr merged
2026-04-05 23:22:16 <Habbie> correct
2026-04-05 23:22:32 <Habbie> zero symlinks in / and /usr on the alpine:edge image from dockerhub
2026-04-05 23:24:12 <clipcarl> I think I'll take @skarnet's approach and add comments to the APKBUILD explaining that I can switch to the install-in-/bin approach if later determined that would be more reliable
2026-04-05 23:24:36 <Habbie> sounds right to me
2026-04-05 23:25:33 <clipcarl> Thank you both @Habbie and @skarnet for the advice. I'll stick around for a bit in case anyone else has advice for me
2026-04-05 23:26:25 <clipcarl> Oh, and happy Easter to all who celebrate that
2026-04-05 23:26:47 <Habbie> you are very welcome. I will point out that skarnet knows what they are doing and their answer fits your exact circumstance, and i will repeat that submitting the apkbuild (after taking skarnet's advice) is a great next step, but sticking around is always wise
2026-04-05 23:26:50 <Habbie> happy easter :)
2026-04-05 23:29:16 <skarnet> yw and happy Easter!
2026-04-05 23:30:16 <skarnet> (yeah I know what I'm doing except that one of my scripts had a bug and caused a breakage for a couple users, so, always double-check ^^")
2026-04-05 23:30:50 <Habbie> (very good of you to remind us to 'trust but verify' :) )
2026-04-05 23:32:17 <clipcarl> LOL. That's an oldie. Is that a Reagan?
2026-04-05 23:32:30 <Habbie> uh, i only know it as a joke about X.509
2026-04-05 23:32:52 <Habbie> but i have one "we are from the government and we are here to help" stocked for you ;)
2026-04-05 23:33:04 <clipcarl> Heh
2026-04-05 23:34:07 <Habbie> https://en.wikipedia.org/wiki/Trust,_but_verify some Reagan in there
2026-04-05 23:34:09 <clipcarl> Yeah, Reagan used "Trust but verify" 
2026-04-05 23:34:21 <clipcarl> I didn't realize it was a Russian proverb
2026-04-05 23:53:26 <Habbie> same
2026-04-06 00:09:49 <omni> #18100
2026-04-06 00:10:23 <omni> algitbot: no?
2026-04-06 00:10:48 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/issues/18100
2026-04-06 00:11:01 <omni> py3-installer 1.0.0 impacting gpep517 install-wheel
2026-04-06 00:12:50 <omni> seems to mostly be wheel installation for tests for some aports, where gpep517 install-wheel is used, what we've seen so far
2026-04-06 00:36:35 <Habbie> !18100
2026-04-06 10:30:46 <ikke> !18100
2026-04-06 10:31:14 <ikke> !18100
2026-04-06 10:43:38 <omni> but I meant #18100
2026-04-06 11:41:10 <socksinspace> !100213 a little present for the retro PC enthusiasts in the room ;)
2026-04-06 15:14:34 <ikke> omni: understood, just wanted to test the bot
2026-04-06 15:18:17 <omni> sure, just wanted to be clear =)
2026-04-06 15:18:49 <ikke> :)
2026-04-06 15:22:05 <mjacob> Ariadne: When seeking inspiration to fix a problem with GCC installing libraries at /usr/lib64 instead of /usr/lib on a from-scratch distribution that uses /usr/lib instead of /usr/lib64 on all platforms, I looked for inspiration from other distributions. I found https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0023-x86_64-disable-multilib-support.patch. However, I was wondering if 
2026-04-06 15:22:05 <omni> hmm.. mgorny of gpep517 suggests we'd skip python installer 1.0.0, meaning downgrading to 0.7.0
2026-04-06 15:22:11 <mjacob> the commit message is still correct. It says “multilib is not presently supported on Alpine GCC”, but the diff does something else. It renames the library directories and disables multiarch, but doesn’t seem to disable multilib. Why is there `MULTILIB_OSDIRNAMES+= m32=../lib32` if multilib is not supported?
2026-04-06 15:30:46 <Shiz> mjacob: the apkbuild disables multilib support explicitly
2026-04-06 15:30:55 <Shiz> if you look at https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/t-linux64, those are the only variables it exposes
2026-04-06 15:31:08 <Shiz> my guess is even with multilib disabled, these named variables still get used by the build process
2026-04-06 15:32:23 <Ariadne> yes
2026-04-06 15:42:57 <mjacob> As far as I understand, multilib consists of two parts: 1) Generating code for different sub-architectures (e.g. 32-bit and 64-bit x86). 2) Looking at libraries in different directories based on the sub-architecture.
2026-04-06 15:43:05 <mjacob> Passing --disable-multilib to GCC configure disables (1) but not (2).
2026-04-06 15:43:06 <socksinspace> mjacob: it may also be worth looking at what musl-cross-make does, i recall their approach to disabling multilib being simpler
2026-04-06 15:43:18 <mjacob> In a distribution that doesn’t support (1), it makes sense to disable (2) and use /usr/lib consistently on all platforms. If I understand correctly, Alpine does that. I suppose that linked patch’s purpose is exactly that. Is that correct?
2026-04-06 15:43:26 <Shiz> yes
2026-04-06 15:43:40 <Shiz> (even with multilib enabled, there's better ways than /lib32 and /lib64...)
2026-04-06 15:45:22 <Shiz> like /lib/<target-tuple>, which I do believe gets added when multilib is enabled (the if_multiarch invocations there)
2026-04-06 15:45:37 <Shiz> it's more that gcc hardcodes /lib32 and /lib64 with or without multilib enabled :p
2026-04-06 15:46:04 <mjacob> Yes, the /lib/<target> is multiarch.
2026-04-06 15:47:18 <mjacob> So my original question was why https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0023-x86_64-disable-multilib-support.patch retains `MULTILIB_OSDIRNAMES+= m32=../lib32` when multilib is not supported.
2026-04-06 15:48:57 <Shiz> I'd say the patch subject is a bit off
2026-04-06 15:49:18 <Shiz> what it really is is a generic patch that changes gcc's default lib names to take 64-bit as the default and 32-bit as the fallback (if any), instead of the opposite away as it is upstream
2026-04-06 15:50:20 <Shiz> it *also* strips the if_multilib calls, so in that aspect it removes some multilib support as well
2026-04-06 15:50:28 <Shiz> er, if_multiarch
2026-04-06 15:50:55 <mjacob> Yes, I was confused by the patch subject.
2026-04-06 15:52:04 <mjacob> (The if_multiarch shouldn’t make a difference if multiarch is not explicitly enabled)
2026-04-06 15:59:28 <mjacob> I found that setting `MULTILIB_OSDIRNAMES=` effectively prevents “renaming” /usr/lib on all platforms in all configurations. This might be useful for Alpine as well. However, maybe `MULTILIB_OSDIRNAMES+= m32=../lib32` has some purpose on Alpine which I don’t understand. Therefore, I was asking.
2026-04-06 16:01:03 <Shiz> I imagine it's just for completen/w 10
2026-04-06 16:01:05 <Shiz> whoops
2026-04-06 16:01:09 <Shiz> I imagine it's just for completeness*
2026-04-06 16:01:28 <Shiz> the patch could also be used in a distro that *does* want lib32 that way
2026-04-06 18:42:18 <quinq> oh sheet
2026-04-06 18:42:27 <ikke> ?
2026-04-06 18:43:20 <quinq> I think I found a bug I introduced, checking now
2026-04-06 18:44:02 <quinq> Ah no, it's fine, the commit is correct, for some reason the file on disk is different
2026-04-06 18:44:07 <quinq> Sorry for the noise :D
2026-04-06 18:57:10 <omni> has anything changed wrt indentation practices? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95795#note_598688
2026-04-06 19:02:42 <ikke> No, it has never been officially standardized
2026-04-06 19:02:53 <ikke> but the convention has been to indent it if multi-line
2026-04-06 19:13:46 <quinq> Is anybody else having issues with jellyfin (server / desktop)?
2026-04-06 19:33:02 <ikke> omni: We would need to codify it in CODESTYLE.md
2026-04-06 19:36:14 <fmirkes> Hello, question regarding the "license" var in APKBUILD files: I have a project which uses two licenses, and across other aports I see them sometimes concatenated via "AND" or "OR". Is there any difference between the keywords? Didn't find anything regarding that in the wiki/manpage.
2026-04-06 19:37:33 <ikke> fmirkes: AND is used when there are multiple components with different licenses (so both are in effect)
2026-04-06 19:38:14 <ikke> OR is used when a single component has multiple licenses (so you can choose which license works best for your usecase)
2026-04-06 19:38:57 <ikke> fmirkes: see https://spdx.github.io/spdx-spec/v3.0.1/annexes/spdx-license-expressions/
2026-04-06 19:44:29 <fmirkes> makes sense, thanks for the link :)
2026-04-06 20:35:39 <dne> mcrute: hey! would you mind approving/merging the remaining two bird version bumps? !100061 & 100197
2026-04-06 20:36:12 <dne> !100197
2026-04-06 20:43:04 <mcrute> dne: sure thing I'll get those done this afternoon
2026-04-06 20:44:03 <dne> mcrute: 👍
2026-04-06 21:42:31 <RavFX[m]> I finished updating my APKBUILD for !99676 as recommanded! If someone can review/approve
2026-04-06 21:43:16 <RavFX[m]> I have implemented !100066 and also corrected by following recommandation from the other MR. If someone can review it would be great, thanks!
2026-04-06 22:18:08 <omni> ikke: an attempt !100260
2026-04-06 22:24:36 <Sertonix[m]> Do we need an extra section? It would seem to fit under "Indentation" as well
2026-04-06 22:29:17 <omni> I kinda like ### Indention being very short and clear, but it's a valid suggestion
2026-04-06 22:37:44 <Sertonix[m]> Maybe the text could be shortened a bit: "Lines in a multi-line value including the terminating quote should be indented.". And the comment about abuild checksum should probably be moved out of the "Line length" section since it applies to indentation as well.
2026-04-06 22:39:55 <Sertonix[m]> Then one could rename "Line length" to "Line break" and put tge information about *depends and source there?
2026-04-06 22:48:41 <omni> abuild checksum applies to indentation as an exception to the rule?
2026-04-06 22:58:53 <Sertonix[m]> Yes, seems to me like that
2026-04-07 08:56:28 <ncopa> hi! how everyone has had a nice weekend!
2026-04-07 08:56:49 <ncopa> hope*
2026-04-07 08:57:15 <ncopa> fabled: do you think you could have a quick look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95668?
2026-04-07 09:09:42 <dne> does anyone have thoughts on !99274, and if it should perhaps replace main/varnish?
2026-04-07 09:11:58 <ikke> Is there a reason to introduce a  new package rather than renaming the existing?
2026-04-07 09:13:06 <dne> not really, except, there was already !99204
2026-04-07 09:14:24 <dne> (that switches upstream instead)
2026-04-07 09:25:18 <ikke> Seems like it's forked? github.com/varnish/varnish still exists
2026-04-07 09:26:32 <dne> well, it's complicated: https://vinyl-cache.org/organization/20-years.html
2026-04-07 09:27:49 <dne> Varnish Software (the company) owns the name (varnish), so the OSS project renamed to Vinyl Cache
2026-04-07 09:29:15 <dne> and github.com/varnish/varnish is now a downstream of Vinyl Cache (AFAIUI)
2026-04-07 10:04:31 <quinq> Hello
2026-04-07 10:04:50 <quinq> It seems that some packages have sdl2-compat as a dependency, while others have sdl2
2026-04-07 10:05:04 <quinq> And both are incompatible with each-other
2026-04-07 10:05:09 <quinq> Is that “on purpose”?
2026-04-07 10:05:39 <quinq> I'd think that the -compat would be a drop-in replacement for the actual sdl2, just more limited maybe
2026-04-07 10:06:14 <quinq> As in, if sdl2 is installed, then there's no need for sdl2-compat because the actual thing's already available
2026-04-07 10:08:19 <quinq> For example I see that you committed koreader with a dependency on sdl2-compat, whas that concious?
2026-04-07 10:24:19 <ikke> Who is "you?
2026-04-07 10:49:50 <quinq> oops, forgot to highlight achill :D
2026-04-07 10:57:34 <achill> they are abi compatible so it shouldn't matter which one
2026-04-07 10:58:00 <achill> but for new stuff I'd recommend sdl2-compat because that's also what gets by default instead of sdl2
2026-04-07 11:01:46 <quinq> abi wise, why not
2026-04-07 11:01:51 <quinq> apk-wise, they aren't
2026-04-07 11:02:11 <quinq> At least it refuses to install the package here because I hade sdl2 installed
2026-04-07 11:05:20 <Sertonix[m]> The issue is that koreader should depend on so:libSDL2-2.0.so.0 instead of sdl2-compat.
2026-04-07 11:19:33 <achill> or just sdl3 if possible
2026-04-07 14:42:58 <WhyNotHugo> py3-onnxruntime depends on py3-flatbuffers. The former is available on armhf, but the latter is not, so the former is impossible to install due to unsatisfiable constraints.
2026-04-07 14:43:25 <WhyNotHugo> Apparently, nothing catches this kind of error; packages have built fine and shipped into repos for many months.
2026-04-07 14:43:34 <WhyNotHugo> It's just impossible to install.
2026-04-07 15:34:41 <Sertonix[m]> I have a script which should catch the error but I don't have the time for it at the moment: https://codeberg.org/sertonix/alpine-scripts/src/branch/main/apk-dot-error
2026-04-07 17:31:24 <socksinspace> holy heck, how much disk space does our kernel need to build? I thought 16 GiB would be plenty for my VM disk
2026-04-07 17:32:53 <Sertonix[m]> If you plan to frequently build kernels it's probably best to disable debug symbols
2026-04-07 17:35:37 <socksinspace> for now it is just part of the process to get the gremlins out of the bootstrap process with a known-good architecture
2026-04-07 17:47:32 <socksinspace> but that 16GiB isn't enough is helpful information for if/when i get to actually set up a package builder
2026-04-07 19:19:05 <Sertonix[m]> Is the existance of alpinelinux.cn known? It seems to be connected to some chinese linux communities and not problematic
2026-04-07 19:19:44 <ikke> Not specifically, no
2026-04-07 21:08:49 <socksinspace> oh god, it looks like 32GiB might not be enough either
2026-04-08 01:19:38 <WhyNotHugo> Can we close !74468, which targets 3.19 which is no longer supported?
2026-04-08 01:24:08 <lotheac> i would leave that up to the package maintainer. the support level is documented as "on request" so it's not as if it's forbidden to make changes to those branches
2026-04-08 01:36:47 <durrendal> Will second lotheac here, 3.14 forward are supported ad hoc. If a maintainer feels that the best use of their time is backporting that change we should support it.
2026-04-08 01:37:12 <durrendal> Or, alter the definition of what is and is not supported.
2026-04-08 02:03:26 <WhyNotHugo> ack
2026-04-08 02:04:02 <WhyNotHugo> And I see mirrors still hold all the way back to 3.0
2026-04-08 02:23:55 <durrendal> Yeah we had an archive at one point, but things change when you have to migrate everything in a pinch.
2026-04-08 02:24:00 <durrendal> https://lambdacreate.com/paste/alpine-mirror-analysis.txt
2026-04-08 02:24:39 <durrendal> If you're curious about how big those mirrors are I put together a bunch of info on it out of curiosity. 
2026-04-08 02:25:39 <durrendal> alpine's a lot bigger than it used to be, at least in repo size
2026-04-08 02:30:34 <WhyNotHugo> Huh, I somehow expected testing to be larger than community
2026-04-08 02:43:28 <durrendal> It's not super obvious from the numbers but it's because testing only exists on edge insofar as the mirrors are concerned 
2026-04-08 02:44:07 <durrendal> That top total number is aggregate across all versions, so community is 3.0-edge
2026-04-08 06:45:44 <ikke> durrendal: for the record, 3.14-3.18 have support level "on-request" so they're not EOL yet
2026-04-08 14:35:04 <ikke> So, create a new branch based on 3.23-stable, cherry-pick the commits
2026-04-08 14:35:14 <ikke> And then create an MR to target 3.23-stable
2026-04-08 14:51:36 <slink> dne, ncopa fyi https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.html
2026-04-08 14:52:36 <craftyguy[m]> could a maintainer please take a look at !100337 ? Thanks :D
2026-04-08 15:14:30 <durrendal> ikke: good call out, I didn't properly gate that ad hoc support statement.
2026-04-08 17:08:26 <elagost> would someone look at !98455 ? It's been sitting for a bit. I think it's ready enough.
2026-04-08 18:09:07 <jvoisin> since discussion about licenses happened here ~recently, on Fedora, vim-common is licensed as:
2026-04-08 18:09:09 <jvoisin> License        : Vim AND LGPL-2.1-or-later AND MIT AND GPL-1.0-only AND (GPL-2.0-only OR Vim) AND Apache-2
2026-04-08 18:09:11 <jvoisin>                : .0 AND BSD-2-Clause AND BSD-3-Clause AND GPL-2.0-or-later AND GPL-3.0-or-later AND OPUBL-
2026-04-08 18:09:13 <jvoisin>                : 1.0 AND Apache-2.0 WITH Swift-exception
2026-04-08 18:19:26 <invoked> lol.
2026-04-09 07:51:41 <fabricionaweb> Hi, this have been staled for a while, I need review !97235 
2026-04-09 09:54:08 <omni> https://pkgs.alpinelinux.org/contents?file=PKG-INFO&path=*%2F*egg-info&name=&branch=edge&repo=&arch=x86_64
2026-04-09 09:54:16 <omni> still too many eggs in the basket
2026-04-09 09:57:42 <fabricionaweb> what are we doing to remove the eggs?
2026-04-09 10:07:10 <omni> switching to gpep517, where possible
2026-04-09 14:34:52 <lillianb> is gitlab down? I'm getting 502 on git cloning aports
2026-04-09 14:36:57 <dne> "At 15:30 UTC, gitlab will be restarted to apply security updates and will be briefly unavailable."
2026-04-09 14:40:03 <ikke> It's back
2026-04-09 14:40:05 <dne> this was 14:30 UTC though :)
2026-04-09 14:40:16 <lillianb> dne, thanks, where would I see that notification?
2026-04-09 14:40:39 <ikke> off-by-one error
2026-04-09 14:40:59 <lillianb> nice, working again for me, thanks ikke
2026-04-09 14:42:52 <dne> lillianb: there was a banner on gitlab
2026-04-09 14:43:23 <lillianb> oh
2026-04-09 14:43:56 <lillianb> a suggestion to put it on the 502 page as well then, I wasn't looking at gitlab recently
2026-04-09 15:09:39 <bdprom> hi all, i was bumping libcap to 2.78 to fix CVE-2026-4878, but i noticed the APKBUILD doesnt have a 'secfixes:' comment, should this be added, or is it not so important? (i used `-s CVE...` for abump btw)
2026-04-09 15:10:03 <ikke> bdprom: you can add it
2026-04-09 15:11:09 <bdprom> sure thing, thanks
2026-04-09 16:54:50 <puretryout[m]1> Ariadne seems your change in bc0089b96c1b1f6dd188c130a412eb37da08baf3 in 2011(!) is causing https://gitlab.postmarketos.org/postmarketOS/pmaports/-/work_items/4428 due to not defining UID_MIN anymore in `/etc/login.defs`. Do you know what kind of errors that commit is talking about and if it's still relevant? I'm not entirely sure why we don't just ship the default file
2026-04-09 16:59:18 <Ariadne> I don't remember, sorry
2026-04-09 16:59:30 <Ariadne> I think it was printing warnings or something
2026-04-09 17:06:21 <fabricionaweb> I got the collective for leaderboard, I was wondering why, just checked I lost 750k that is why lmao
2026-04-09 17:06:35 <fabricionaweb> erase that, wrong channel, my bad lol
2026-04-09 17:51:30 <puretryout[m]1> Ariadne I don't blame you, 15 years is a long time ago 😅 I made a MR to add least add the one value I need in there, but perhaps we should just restore the original file at this point. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100475
2026-04-09 17:55:14 <f_> puretryout[m]1: fyi: you wrote UIX_MIN not UID_MIN
2026-04-09 17:56:09 <puretryout[m]1> woops lol
2026-04-09 18:37:12 <achill> puretryout[m]1: i was 4 years old when the commit was made lol
2026-04-09 18:40:56 <craftyguy[m]> back in my day, we had to push commits uphill, in the snow
2026-04-09 18:42:06 <sam_> both ways
2026-04-09 18:57:06 <f_|m> sometimes feels like yesterday
2026-04-09 23:35:49 <histopson[m]> MASTER THE ART OF HACKING 🕹️... (full message at <https://matrix.org/oftc/media/v1/media/download/ASgRQf858RXj8IuUD0wQ-tWe5rrEbBMMUq4KtyhT85euWUeLwaLvHrThNFeqfS1UVjF2mlyrAcRxi3htQc229HtCedvLMhvwAG1hdHJpeC5vcmcvZ21ZdVpEUW5ua0FnQ2JOckNtQWNqdkJD>)
2026-04-10 08:10:11 <fcolista> do we have a clue on when python3.14 will be build for riscv64?
2026-04-10 08:12:44 <ikke> fcolista: the community repository needs to finish
2026-04-10 08:13:38 <ikke> So keep an eye on https://build.alpinelinux.org/ and perhaps help fix build issues
2026-04-10 11:52:11 <WhyNotHugo> Could we not rebuild "noarch" packages only once on a single architecture? E.g.: riscv64 could just re-use the same builds from x86_64 or aarch64.
2026-04-10 11:58:35 <achill> thats the whole idea behind it, but it currently lacks infrastructure to do that
2026-04-10 12:05:42 <achill> but we should keep that in mind for the builder re-architecture
2026-04-10 13:07:43 <Sertonix[m]> I don't think we should trust packages marked as "noarch" to truly be the same between arches. As an example I have seen that the common way to generate manpages for go cli allows for defaults shown in the manpage to vary between architectures. Manually checking for such differences is too much effort in my opinion and not checking would be a disservice for the other arches
2026-04-10 13:15:38 <achill> i think we can work towards that goal tho. e.g. with reproducable builds that would be detect-able. speaking of the future, there is a bunch of work linked to that of course
2026-04-10 13:18:44 <f_> Sertonix[m]: wouldn't they need to be "arch=all" then?
2026-04-10 13:21:39 <achill> subpackages can be noarch when the origin package is not
2026-04-10 13:22:46 <achill> and architecture-specific changes can still happen on noarch-packages
2026-04-10 13:23:21 <achill> because nothing is happening with noarch packages so nothing is enforced
2026-04-10 13:52:30 <Saijin_Naib[m]> I know review time is precious, but could maybe these get a look? !97292 !97494 as they fix broken features in Pitivi editor
2026-04-10 14:22:01 <lanodan> Hi, not really sure what happened (looking at #alpine-commits it seems like it didn't trigger) but it seems like riscv64 on v3.23 didn't get the musl-1.2.5-r22 revbump unlike x86* and aarch64/arm*
2026-04-10 14:54:27 <WhyNotHugo> I don't really understand why our typical usage of `gpep517 build-wheel` is split across three lines and pipes stdin to stderr. That smells like cargo-culted to me.
2026-04-10 14:54:32 <WhyNotHugo> I do understand the 3>&1 pipe tho
2026-04-10 15:13:35 <ptrc> i think it's because of the newapkbuild template?
2026-04-10 15:35:17 <ikke> ncopa: I suppose we need new stable releases for the musl CVE?
2026-04-10 15:44:27 <achill> that would be good yes
2026-04-10 16:14:26 <ptrc> hm. i got a weird apk-tools bug and i feel like i'm losing braincells
2026-04-10 16:14:29 <ptrc> ERROR: unable to select packages:
2026-04-10 16:14:29 <ptrc>     conflicts: solaar-1.1.19-r1[py3.14:hid_parser=0.0.3-r3]
2026-04-10 16:14:29 <ptrc>     satisfies: world[py3-hid-parser>0.0.3-r2] solaar-1.1.19-r1[py3-hid-parser]
2026-04-10 16:14:29 <ptrc>   py3-hid-parser-0.0.3-r3:
2026-04-10 16:14:29 <ptrc>   solaar-1.1.19-r1:
2026-04-10 16:14:31 <ptrc>     conflicts: py3-hid-parser-0.0.3-r3[py3.14:hid_parser=1.1.19-r1]
2026-04-10 16:14:31 <ptrc>     satisfies: world[solaar>1.1.18]
2026-04-10 16:14:47 <ptrc> why does the second "conflicts" take the version of solaar into the hid_parser dependency..??
2026-04-10 16:19:01 <ikke> What do you mean with "take the version of solaar into hte hid_parser dependency?
2026-04-10 16:19:30 <ptrc> oh, i.. nevermind, i see what's happening
2026-04-10 16:19:33 <ikke> solaarsolaar-1.1.19-r1 provides:
2026-04-10 16:19:37 <ptrc> yeah
2026-04-10 16:19:38 <ikke> py3.14:hid_parser=1.1.19-r1
2026-04-10 16:19:47 <ptrc> it somehow copied all the dependencies into itself
2026-04-10 16:20:16 <ikke> fun
2026-04-10 16:24:02 <ptrc> apparently the arch package has the same issue: https://archlinux.org/packages/extra/any/solaar/
2026-04-10 16:24:43 <WhyNotHugo> ptrc: solaar uses its own vendored hid-parser
2026-04-10 16:25:00 <ptrc> ohhhh, i see now
2026-04-10 16:26:22 <ptrc> it would be nice if they were actually vendored somehow
2026-04-10 16:26:31 <ptrc> and not just tossed into site-packages on install
2026-04-10 16:27:41 <ptrc> but i'm just thinking out loud, for now fixed the issue with `apk add -t py3-hid-parser`, however hacky that would be
2026-04-10 16:38:00 <Quantum_3[m]> if a pr open for updating a package, but its already out of date (and i need to fix something anyway), should i just close it and reopen with the latest?
2026-04-10 16:39:47 <achill> or just update the mr
2026-04-10 16:44:03 <WhyNotHugo> ptrc: would be nice if upstream properly vendored it into its own module or relied on the stable one
2026-04-10 17:00:14 <ncopa> I havent paid attention recently. Sounds like we should
2026-04-10 17:00:22 <ncopa> re musl CVE that is
2026-04-10 17:00:31 <ncopa> has had very limited time for alpine lately
2026-04-10 17:02:16 <omni> what's the CVE number?
2026-04-10 17:03:40 <achill> CVE-2026-40200
2026-04-10 17:03:43 <achill> https://www.openwall.com/lists/musl/2026/04/10/3
2026-04-10 17:11:12 <ncopa> Aw. Yeah, let’s upgrade ASAP and start work on stable releases
2026-04-10 17:12:24 <ncopa> I would appreciate if someone could create an issue with the release checklist and start look at the items, tzdata etc.
2026-04-10 17:13:14 <ncopa> I think we may also need to update zlib in older stable branches 
2026-04-10 17:13:32 <ncopa> I can start looking at kernels
2026-04-10 17:26:12 <achill> okay: https://gitlab.alpinelinux.org/alpine/aports/-/issues/18117
2026-04-10 17:28:13 <omni> there may be some security upgrades/patches of late to backport
2026-04-10 17:31:19 <omni> I haven't kept up with all of them, but I would search the git log of edge and 3.23-stable for "security", "patch" and "CVE" and see if there's anything that makes sense to backport to the other stable branches (or missing in 3.23-stable)
2026-04-10 17:32:29 <achill> but thats also not highly relevant for the minor releases since the package list for the release tarballs are quite small
2026-04-10 17:32:30 <bdprom> i bumped libcap + libpng yesterday, both are moderate severity
2026-04-10 17:33:31 <achill> and thats the whole reason for the minor releases
2026-04-10 17:35:43 <bdprom> cool cool
2026-04-10 17:48:46 <omni> I opened MRs backporting libpng security upgrade, but not libcap
2026-04-10 17:49:00 <omni> didn't look if it's an easy upgrade on all stable branches
2026-04-10 17:49:14 <omni> (libcap, that is)
2026-04-10 19:23:04 <ikke> The stable builders do need to be idle before a release can be made
2026-04-10 21:11:35 <pj> what's happening on edge builders? go pkgrel bump?
2026-04-10 21:12:38 <achill> yesss
2026-04-10 21:13:39 <pj> noooo 😭 i need Revert "community/polkit-qt: remove Qt5 build"
2026-04-10 21:13:47 <pj> guess I'll wait
2026-04-10 21:13:54 <achill> right
2026-04-10 21:14:00 <achill> you could build it locally 🤷
2026-04-10 21:35:01 <quinq> (/14
2026-04-10 21:35:25 <achill> (/15
2026-04-10 22:27:56 <abby> (V)(´°w° )(V)
2026-04-10 22:37:09 <Sertonix[m]> achill: I have already done the reproducible check and spent many hours trying to bother a few upstreams. You are free to run my script or ask me to run it (since it needs a local mirroe of edge repo) and send the latest dump. https://codeberg.org/sertonix/alpine-scripts/src/branch/main/apk-noarch-check
2026-04-11 07:27:47 <ncopa> morning! looks like the CVE only affect 32-bit. and the other is in iconv tools, so I don't think we need to do a panic release
2026-04-11 07:28:23 <ikke> no panic release, no
2026-04-11 07:28:36 <ikke> But we'll probably get reports about it
2026-04-11 07:28:57 <ncopa> yes, and I think we should tag release when we can
2026-04-11 07:29:04 <ncopa> I also need to get the 3.24 builders up
2026-04-11 07:29:10 <ncopa> im a week late with that already
2026-04-11 07:29:25 <ncopa> but first I need to tag release for abuild and lua-aports
2026-04-11 07:39:19 <ncopa> Sertonix[m]: I wouild like to tag a new abuild releases within next days. Can you help me look over the issues/MRs for abuild and find which we should merge?
2026-04-11 07:41:58 <ncopa> anyone available to help me bump libuv to 1.52.1? there is one test that is failing
2026-04-11 07:56:22 <ncopa> actually, im on libuv. the test is broken i think
2026-04-11 08:24:20 <bdprom> fyi, xdg-dbus-proxy was also updated to fix a vuln where clients could intercept traffic they werent supposed to see (CVE-2026-34080), so there's a lot of flatpak related vulns fixed recently
2026-04-11 08:25:33 <bdprom> not sure if that makes a release more expedient, not sure how this process works tbh
2026-04-11 08:52:22 <bdprom> question: i'm bumping retroarch and its related pkgs, should i create a commit for each pkg then 1 MR, multiple MRs, or one commit one MR?
2026-04-11 09:16:31 <Sertonix[m]> Common is multiple commits in 1 MR. And CC all maimtainers if there are multiple
2026-04-11 09:21:34 <bdprom> cool, thanks.. CC as in, mention them in the MR message?
2026-04-11 10:12:57 <Sertonix[m]> Yes
2026-04-11 10:20:51 <bdprom> Sertonix[m]: great, thanks!
2026-04-11 15:00:44 <bdprom> i'm packaging https://github.com/DHowett/ectool, which produces /usr/bin/ectool, this conflicts with package coreboot-tools-ectool.. how should i handle this, i guess not provides/replaces? maybe just rename the ectool bin to fw-ectool or something?
2026-04-11 15:03:58 <ncopa> how does other distros handle this?
2026-04-11 15:04:57 <bdprom> in the Arch AUR, it's installed as /usr/bin/fw-ectool, with a symlink /usr/bin/ectool -> fw-ectool
2026-04-11 15:06:06 <bdprom> Nix just uses /usr/bin/ectool
2026-04-11 15:10:03 <bdprom> i would lean towards just using `ectool`? it should be pretty obvious from the pkg names alone that the use would be installing 2x ectools?
2026-04-11 15:17:36 <jvvv> If someone has time, would a dev take a look at !96853? It should be ready for commit and it just got the approval of the current maintainer.
2026-04-11 15:18:07 <f_> bdprom: I would go for fw-ectool personally
2026-04-11 15:19:02 <f_> the main usecase where just ectool would be in e.g. build systems that expect this tool to be installed as ectool and not fw-ectool
2026-04-11 15:23:00 <ncopa> lets try do stable releases on Monday or Tuesday
2026-04-11 15:27:29 <bdprom> f_: so you mean use `/usr/bin/fw-ectool`?.. i just opened a MR using /usr/bin/ectool, but i can change it
2026-04-11 15:30:04 <f_> bdprom: okay then you can keep ectool
2026-04-11 16:17:48 <bdprom> f_: alrighty :)
2026-04-11 16:21:28 <ncopa> Sertonix[m]: do you think we can tag an abuild release now? what do you think should be fixed if not?
2026-04-11 16:37:55 <Sertonix[m]> Can we include abuild!453 ?
2026-04-11 16:41:52 <ikke> abuild: avoid using host paths in rootbld: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/453
2026-04-11 16:48:19 <Sertonix[m]> algibot has been renamed to ikke?!
2026-04-11 16:52:23 <omni> should we also get !98224 in before 3.23.4?
2026-04-11 16:52:37 <omni> the rebuilds may take a while on riscv64
2026-04-11 16:53:05 <ikke> omni: only packages which are in the release media are relevant for a release
2026-04-11 16:55:46 <omni> sure, but maybe I should hold off merging that if you are trying to cut a release?
2026-04-11 19:11:51 <realroot[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88906 any hope for rocm?
2026-04-11 22:51:42 <Sertonix[m]> ncopa: I think all important abuild MRs are now merged
2026-04-12 11:34:52 <Lool78> Hi all, I am working on a package for OpenCloud (https://github.com/opencloud-eu). I do it for my own use but my objective is to have it included in the community. I have a couple of questions. The main one is on the way to include options="!check net" to avoid a vendorization. Is it acceptable for Alpine ?  
2026-04-12 12:02:12 <jvvv> Is the s390x builder stuck?
2026-04-12 13:31:50 <bdprom> Lool78: yeah, afaik you'd include 'net' in the options directive, then do something like `cargo vendor --locked` in the prepare() function
2026-04-12 13:32:05 <bdprom> but i'm a relative novice at packaging in alpine, so don't listen to me :)
2026-04-12 13:33:07 <bdprom> at least, that's a common pattern
2026-04-12 13:34:04 <omni> look at other aports for guidance
2026-04-12 13:34:25 <Lool78> bdprom: Thanks I am working on generating a vendor as I found some example of it....
2026-04-12 13:34:40 <Lool78> omni : I did it thanks
2026-04-12 13:35:26 <Lool78> it is cooking now (cross fingers) ....
2026-04-12 13:35:39 <bdprom> Lool78: ah cool, there's also https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Rust if you havent seen it already
2026-04-12 15:25:46 <Lool78> Open cloud published in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100634
2026-04-12 16:19:21 <xyhhx> incredible
2026-04-12 17:30:40 <inmary[m]> Get in touch with this platform for greatness you’ll definitely thank me later
ℹ️❤️
👇🏻👇🏻👇🏻
2026-04-12 17:30:42 <inmary[m]> https://t.me/+pa-CiKYv9-5lNWM8
2026-04-12 19:35:14 <Newbyte> Is it intentional that :latest means latest stable on Dockerhub while it means Edge in Alpine's registry? Very confusing. See e.g. https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8340
2026-04-12 19:37:01 <strangeperson> hello there! I'm trying to upgrade tuwunel (!100648), but build for x86_64 fails with "OOMKilled". what can I do about it?
2026-04-12 19:42:30 <Newbyte> * 
2026-04-12 19:43:35 <ikke> Newbyte: I suppose not
2026-04-12 19:43:48 <Newbyte> Ollie created an issue about it now https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/187
2026-04-12 19:43:59 <ikke> Newbyte: wrong project
2026-04-12 19:45:53 <ikke> I've moved it
2026-04-12 19:46:19 <Newbyte> Thank you!
2026-04-12 21:46:53 <jvoisin> tomleb: can you approve !99914 please?
2026-04-12 22:14:21 <quinq> You have to hurry indeed, they seem to be making a release per week
2026-04-12 22:18:05 <jvoisin> I hate what navidrome is becoming.
2026-04-12 22:28:52 <quinq> For media sharing, I use sshfs+mpv
2026-04-12 22:29:06 <quinq> (+musicbrainz)
2026-04-12 22:31:20 <xyhhx> jvoisin: what's navidrome becoming?
2026-04-12 22:33:43 <quinq> avatardrome
2026-04-12 22:38:58 <jvoisin> piling more and more useless crap on top of a decent-ish web music player
2026-04-12 23:12:18 <jvvv> omni: In the future, for py3-qt6 and pyside6, should I not wait for the deps to clear all the builders? I was waiting for the remaining to clear through the riscv64 builder, but I guess maybe that is not right approach.
2026-04-12 23:17:13 <jvvv> Either way, omni, thanks for your attention to those. I probably should have already had the rdep bumps added. Will do that next time.
2026-04-13 00:25:19 <omni> jvvv: it was marked as Draft: and it makes sense to try without rebuilds first, I pointed it out to avoid them being missed
2026-04-13 00:29:38 <jvvv> omni: Appreciated. I am investigating the freecad build failure. Looks to be boost related, but still looking at it.
2026-04-13 00:30:06 <omni> there are other attempts at doing that
2026-04-13 00:31:15 <omni> !100616
2026-04-13 00:31:32 <omni> algitbot: no?
2026-04-13 00:31:36 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100616
2026-04-13 00:34:18 <jvvv> Oh, ok.
2026-04-13 00:36:09 <jvvv> Looks like the bump to 1.1.0 avoids the boost error, but fails differently.
2026-04-13 00:36:16 <omni> yes
2026-04-13 00:36:29 <kiltarzip> yeahh
2026-04-13 00:38:14 <omni> jvvv: you're welcome to try and sort it out
2026-04-13 00:40:44 <jvvv> I'm looking at a couple upstream changes that might be related.
2026-04-13 01:04:14 <omni> jvoisin: some aports have issues with tests after the py3-pygments upgrade
2026-04-13 01:05:20 <omni> https://build.alpinelinux.org/buildlogs//build-edge-riscv64/community/py3-cli_helpers/py3-cli_helpers-2.10.0-r1.log
2026-04-13 01:05:28 <omni> for example
2026-04-13 02:34:14 <Advert[m]> https://t.me/+c-LC9ed_hBgwYmZh
2026-04-13 03:32:01 <jvvv> omni: Maybe I will have time tomorrow... need some z's
2026-04-13 08:50:49 <ncopa> im tagging abuild 3.17.0_rc1 now
2026-04-13 08:51:07 <ncopa> will bump in edge repo. Watch out for breakages
2026-04-13 08:56:32 <achill> fyi about 130 packages will be failing because of missing pyc subpkgs
2026-04-13 08:56:49 <achill> I'll get a list later today when I'm home again if anybody wants to give a hand
2026-04-13 09:26:08 <bdprom> achill: i'll happily lend a hand if i can figure out what to do without potentially breaking anything :)
2026-04-13 11:04:15 <fabled> is anyone working to upgrade 3.23-stable to Qt 6.10.3 ?
2026-04-13 11:12:58 <ncopa> probably not
2026-04-13 15:20:18 <invoked> omni: in arti 1.4.0, logging to files doesn't seem to work. arti 2.2.0 (edge) it's fine
2026-04-13 15:24:11 <invoked> nvm, it's complaining about permissions, sorry for the ping.
2026-04-13 15:39:00 <omni> invoked: don't be, I apreciate it
2026-04-13 16:47:25 <invoked> omni: arti doesn't log to syslog if it fails, only stderr (which gets lost). maybe set error_log=? not sure
2026-04-13 16:48:06 <invoked> or maybe add comments to arti.toml about it
2026-04-13 16:53:10 <invoked> /var/log/arti/ needs to be arti:arti 0700
2026-04-13 16:56:21 <omni> or 0750, right?
2026-04-13 16:56:39 <omni> I was thinking of backporting b9f5cfee9ff040a1f57538fa0501951c79ad3ed7
2026-04-13 16:56:49 <omni> algitbot: ?
2026-04-13 16:57:37 <omni> https://git.alpinelinux.org/aports/commit/?id=b9f5cfee9ff040a1f57538fa0501951c79ad3ed7
2026-04-13 16:59:44 <invoked> maybe it changed after 1.4.0. this is what i got with 1.4.0: "/usr/bin/arti: error: Unable to create parent directory for logfile "/var/log/arti/info.log": Incorrect permissions: "/var/log/arti" is u=rwx,g=rx; must be g-rx
2026-04-13 17:01:42 <invoked> either way it's brittle and users can't see it
2026-04-13 17:09:20 <omni> yes, it changed togethere with the 1.5.0 upgrade in edge
2026-04-13 17:15:00 <invoked> 2.2.0 is probably more ready for anything than 1.4.0 is
2026-04-13 17:16:21 <invoked> though i think features=full is still leaving out hs key management and relay functions
2026-04-13 17:21:29 <omni> wait a minute, the above change should be in 3.23-stable, and arti be at version 1.8.0
2026-04-13 17:23:05 <omni> (I may have recalled thinking about backporting to 3.22 back when the init script change was introduced)
2026-04-13 17:28:06 <invoked> it is 1.8.0, sorry. my mistake
2026-04-13 17:28:45 <invoked> i don't know where i got 1.4.0 from
2026-04-13 17:31:26 <invoked> it was 1.4.0 when i started working on this. :)  i still have it in my scrollback.
2026-04-13 17:31:50 <invoked> is it tuesday already? holy cow.
2026-04-13 17:34:33 <invoked> that (1.4.0) was from an old local build i didn't know was in $PATH.
2026-04-13 17:36:12 <invoked> therefore amend my earlier comments to be 1.8.0 failing on /var/log/arti/ set to 0750
2026-04-13 17:55:27 <omni> invoked: would you mind trying build artefacts from https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100710 ?
2026-04-13 17:58:16 <invoked> omni: can do, will do. a few hours ok? i have a lunch thing
2026-04-13 18:09:47 <panekj> PureTryOut: spectacle is SIGSEGV'ing since few days (i'm guessing due to bump)
2026-04-13 18:10:58 <panekj> https://tpaste.us/DryR 
2026-04-13 18:22:42 <omni> invoked: I'm in no rush
2026-04-13 18:38:45 <puretryout[m]1> panekj ah I hadn't noticed yet but you're right. I'll see if simply rebuilding fixes it
2026-04-13 18:47:38 <jvvv> omni: what do you think about splitting out the freecad rebuild from the pyside6 upgrade, then dealing with the freecad upgrade from !100616?
2026-04-13 18:49:16 <jvvv> once pyside6 is available on the mirrors, it seems like it would be a better situation to try to get freecad upgraded.
2026-04-13 18:53:59 <omni> jvvv: I too have thought of it, but it might break freecad or block packages from upgrading
2026-04-13 18:56:22 <jvvv> ok, that is a possiblity, so I see your point. Should I try pulling aelin's changes into my branch?
2026-04-13 19:02:59 <omni> something to build on, but it also looked like they still failed on armv7 and x86 (and the commit message should be modified)
2026-04-13 19:03:35 <omni> I didn't look at how they failed but retriggered the builds to see if they pass now
2026-04-13 19:08:34 <jvvv> I was hesitant to work on fixing freecad-1.0.2 when we know we want to upgrade freecad to 1.1.0. But if fixing 1.0.2 first is the safest way, I will dive back into that. I was not having luck last night, then couldn't keep eyes open.
2026-04-13 19:11:53 <jvvv> armv7 and x86 both failed again. I will work on freecad-1.0.2 for the pyside6 upgrade for now, unless you suggest otherwise.
2026-04-13 19:14:10 <ncopa> heads up. im pushing lua-aports 1.3.2 which uses Lua 5.5
2026-04-13 19:14:23 <ncopa> in case builders behave unexpected
2026-04-13 19:34:25 <omni> https://build.alpinelinux.org/ says "failed"?
2026-04-13 19:37:04 <ikke> -ash: buildrepo: not found
2026-04-13 19:37:09 <ikke> That would explain
2026-04-13 19:39:39 <ikke> lua is missing
2026-04-13 19:40:28 <ikke> It still depends on lua5.4
2026-04-13 19:41:30 <ikke> lua-optarg is not built for lua5.5
2026-04-13 19:44:49 <ikke> !100716
2026-04-13 19:47:50 <ikke> ok, it fails because it upgrades lua-aports in CI as well
2026-04-13 19:51:06 <ikke> module 'mqtt.publish' not found:
2026-04-13 19:54:14 <ikke> looks like the tests didn't catch that
2026-04-13 19:57:23 <ikke> x86_64 fixed
2026-04-13 19:58:30 <ikke> x86 fixed
2026-04-13 19:59:29 <ikke> aarch64 fixed
2026-04-13 20:00:35 <ikke> armv7 fixed
2026-04-13 20:00:45 <quinq> striiiikuuuuuu
2026-04-13 20:01:45 <ncopa> aw. sorry
2026-04-13 20:01:49 <ikke> armhf fixed
2026-04-13 20:03:10 <ikke> ppc64le fixed
2026-04-13 20:04:26 <ikke> s390x fixed
2026-04-13 20:05:33 <ikke> riscv64 fixed
2026-04-13 20:06:28 <ikke> loongarch64 fixed
2026-04-13 20:06:32 <ikke> all builders are fixed now
2026-04-13 20:07:02 <skarnet> \o/
2026-04-13 20:11:34 <ncopa> so this doesnt happen again https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100718
2026-04-13 20:11:42 <ncopa> ikke thank you for cleaning up my mess
2026-04-13 20:12:11 <ikke> np
2026-04-13 20:12:25 <ikke> ncopa: there are also some dependencies that were missing
2026-04-13 20:12:39 <ncopa> I saw
2026-04-13 20:12:40 <ikke> Seems like we need beter test coverage to catch those
2026-04-13 20:15:00 <ncopa>  /usr/share/buildrepo/plugins/report-build-errors.lua is owned by aports-build-1.6.4-r1
2026-04-13 20:15:54 <ikke> oh, did I add it to the wrong package?
2026-04-13 20:16:28 <ncopa> it happened because aports-build has _luaver=5.4
2026-04-13 20:25:31 <ikke> I guess you can remove the lua-mqtt-publish dependency from lua-aports again
2026-04-13 20:25:38 <ncopa> I'm on it
2026-04-13 20:25:44 <ikke> ack
2026-04-13 20:27:28 <ncopa> we have fragile build infra
2026-04-13 20:32:58 <ikke> And yet it has managed to build our packages for all this time :)
2026-04-13 20:33:51 <ikke> For all it flaws, it generally just works™
2026-04-13 20:35:13 <ncopa> and it builds fast
2026-04-13 20:38:52 <achill> yeah as fast as building with a single builder can be
2026-04-13 20:39:27 <achill> here a list of failing packages without -pyc subpkgs if someone wants fix stuff: https://gitlab.alpinelinux.org/alpine/aports/-/issues/18123
2026-04-13 20:40:27 <ikke> building concurrently comes with its fair share of issues as well
2026-04-13 20:40:58 <ikke> say I push an upgrade of a package, realize I forgot to bump its dependencies, so I push it right after
2026-04-13 20:41:15 <ikke> You need to somehow ensure those rebuilds happen only after the first package has been built
2026-04-13 20:43:48 <ncopa> current build infra is stupid and simple
2026-04-13 20:44:08 <ncopa> we need to get the build-edge-riscv64 over the finish line
2026-04-13 20:44:27 <ncopa> we need to disable tests or whatever
2026-04-13 20:45:38 <ikke> 2/13
2026-04-13 20:45:44 <ikke> new commits have been pushed
2026-04-13 20:46:00 <achill> ikke: yeah exactly, actually i have plans to work on it but didnt manage to find time for it
2026-04-13 20:46:22 <ikke> I have been playing with in my mind for quite some time already
2026-04-13 20:46:36 <achill> ncopa: please dont disable tests. especially on riscv64 they usually indicate something wortfull
2026-04-13 20:47:13 <ikke> achill: combining forces would be usefull I guess
2026-04-13 20:47:28 <achill> yeah sure
2026-04-13 20:47:56 <achill> ncopa: also i've found out 807ee63810da3e7d2e9753020e160af9c1ec2c07 by accident this morning and was not amused. please ping me when you disable stuff like that, so that i actually now that i have to look at it
2026-04-13 21:17:25 <jvvv> omni: I've pushed a fix for the freecad-1.0.2 build failure in !100535
2026-04-13 21:50:07 <Sertonix[m]> achill: This is another case for needing a generic "please notify me about everything related to package X".
2026-04-13 21:50:55 <achill> true, forgot about that idea, youre right
2026-04-13 21:51:54 <Sertonix[m]> Maybe I should start reading the gitlab API docs to see what would be possible
2026-04-13 22:08:22 <Sertonix[m]> 10 years... https://gitlab.com/gitlab-org/gitlab/-/work_items/14281
2026-04-14 01:29:13 <jvvv> aelin: I've tested an upstream fix for the 32 bit build issue for !100616. https://github.com/FreeCAD/FreeCAD/commit/442baf1ddad9fa2bc852de555524975266969c1e
2026-04-14 08:23:52 <ncopa> im working on gopass on build-edge-riscv64 now
2026-04-14 08:27:26 <ncopa> achill: sorry about that. yeah I should have pinged you
2026-04-14 08:27:45 <ncopa> achill: do you want me to create an issue to follow it up?
2026-04-14 08:52:15 <bdprom> is there a way of installing a locally built package to $pkgdir using abuild, but NOT having it create apk files immediately after? i'd like to see what a package split and its files look like without the build cluttering my local repos
2026-04-14 08:53:02 <bdprom> seems like create_apks is always called and there's no way to stop before that
2026-04-14 08:54:55 <Sertonix[m]> You can change the repo directory to a dummy location
2026-04-14 08:55:33 <bdprom> ah yeah, i just found REPODEST (-P)
2026-04-14 08:55:34 <bdprom> thanks!
2026-04-14 10:24:35 <kaathewise> Do HTTP pulls work with the alpine repo?  Mine keep timing out
2026-04-14 10:24:42 <kaathewise> *aports repo
2026-04-14 10:25:18 <ptrc> kaathewise: do you mean the git repo?
2026-04-14 10:25:28 <kaathewise> Yeah
2026-04-14 10:25:56 <ptrc> seems to work for me
2026-04-14 10:27:00 <kaathewise> Does the instance do any, uh, geographic blocking by chance?
2026-04-14 10:28:21 <ikke> kaathewise: we have dropped some prefixes due to excessive cloning
2026-04-14 10:29:25 <ikke> kaathewise: would you mind sharing the source ip address privately with me?
2026-04-14 10:31:47 <kaathewise> Sent it.  Apparently I'm also 22 thousand commits behind, so that might be the reason fetching fails
2026-04-14 10:34:37 <ikke> There is no distinction between the interface and cloning with http in this regards, so if one works, the other should work as well
2026-04-14 11:26:34 <omni> what's the timeline on tagging and building patch releases?
2026-04-14 11:28:19 <omni> thinking wether I should merge the chromium upgrade to 3.23-stable (takes about 8 hours or something to build, aarch64, armv7 & x86_64) or if we should wait
2026-04-14 12:38:03 <panekj> PureTryOut: still same issue (but after updating I had to give it permissions for screenshots, if it doesn't have permissions it launches fine??)
2026-04-14 12:40:28 <PureTryOut> It still complains about not being rebuilt? It works fine for me, although it does complain about permissions
2026-04-14 12:40:48 <panekj> well, it was launching with "no permissions for capturing screen" or something like that and after tinkering with permissions it's SIGSEGV again
2026-04-14 12:41:36 <panekj> https://tpaste.us/7o9d 
2026-04-14 12:42:21 <PureTryOut> Actually it's still complaining about tesseract with the repo version, a locally built version with the fix earlier worked fine... Wtf
2026-04-14 12:43:39 <panekj> also one time it launched I did go into settings and it showed no OCR support
2026-04-14 12:43:53 <panekj> so I'm confused why did it launch once
2026-04-14 12:44:15 <PureTryOut> Oh derp I never applied the patch, just committed the file... Wtf
2026-04-14 12:44:29 <PureTryOut> Upstream is changing use of tessarect anyway, I'll just add that commit instead
2026-04-14 12:49:08 <panekj> thanks
2026-04-14 12:50:08 <puretryout[m]1> Still SIGSEGVing now it's linked, but at least it doesn't complain anymore 😅
2026-04-14 12:53:40 <omni> I've seen a lot of SIGSEGVs with (qutebrowser and) qt6-qtwebengine after the 6.11 upgrade, but haven't dug into it
2026-04-14 12:53:58 <omni> I'll let you know when I do and if I find someting
2026-04-14 12:54:11 <puretryout[m]1> Thanks!
2026-04-14 13:50:45 <ncopa> omni: stable releases was supposed to happen today, but I have kind of spent my alpine time budget for today
2026-04-14 13:52:11 <omni> ncopa: ok, then I'll merge the upgrade and it should be done by the time your funds are up again
2026-04-14 13:52:32 <ncopa> ok
2026-04-14 13:52:59 <ncopa> fabled: I suppose I should backport apk-tools 3.0.6 to 3.23-stable?
2026-04-14 14:02:26 <ncopa> ikke: i merged this: https://gitlab.alpinelinux.org/alpine/ca-certificates/-/merge_requests/25 I suppose we should tag new ca-certificates release?
2026-04-14 14:03:57 <fabled> ncopa: yes. Thanks!
2026-04-14 14:04:33 <fabled> I'll try to do MR for Qt 6.10.3 for 3.23-stable this week. But it's not release blocker. Probably even better to release before merging that
2026-04-14 14:05:00 <ikke> ncopa: ack
2026-04-14 14:07:40 <ncopa> fabled: anything to do for apk-tools 2.14? eg 3.2[0-2]-stable?
2026-04-14 14:29:43 <fabled> ncopa: no
2026-04-14 14:47:26 <quinq> It seems that mattermost-desktop (electron?) crashes on edge/amd64
2026-04-14 14:47:32 <quinq> 16:46:47.557 › [WebContentsEventM...] [e3ad3fc2-e72e-494...] [e7e8098d-9c30-45d...] Renderer process for a webcontent is no longer available: crashed
2026-04-14 14:49:03 <quinq> Ah yeah, sorry, the actual error is just before thas
2026-04-14 14:49:09 <quinq> ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x148 arg1=0x1c arg2=0x7fe1992ac9c0 arg3=0x1 arg4=0xcaa0nr=0x148 arg1=0x1c arg2=0x7fe1996ba9c0 arg3=0x1 arg4=0x0
2026-04-14 14:49:31 <quinq> Same error as for qtchromium
2026-04-14 14:54:41 <quinq> lnl, mio? :>
2026-04-14 14:56:36 <fabled> quinq: have you upgraded everything? seems https://gitlab.alpinelinux.org/alpine/aports/-/commit/410819154a887d30bd5349a2eeea5df439973086 should have fixed that 3 weeks ago
2026-04-14 14:57:13 <quinq> Well
2026-04-14 14:57:26 <quinq> It seems that package actually *just* landed into the repos :)
2026-04-14 14:57:41 <quinq> ( 7/16) Upgrading qt6-qtwebengine (6.11.0-r1 -> 6.11.0-r2)
2026-04-14 14:57:57 <quinq> Nope, crashes the same
2026-04-14 14:58:12 <quinq> (after an apk upgrade -a, that is being done at least a couple times per day)
2026-04-14 14:59:15 <fabled> hum, that was already before qt 6.11.0, must be something else
2026-04-14 14:59:26 <lnl> qt6-qtwebengine is unrelated to Electron anything
2026-04-14 15:02:48 <quinq> Also
2026-04-14 15:02:58 <quinq> (as in “that too”)
2026-04-14 15:05:01 <lnl> I think this is #17608 for electron only
2026-04-14 15:05:47 <lnl> Fixed here in chromium https://gitlab.alpinelinux.org/alpine/aports/-/commit/63664a5c5eff79b63e8538a34e13bd4dc25cbe73#9ab0c53630409f2b1b078e14f45a205e21193791
2026-04-14 15:06:15 <fabled> ah, seems the same patch is needed for testing/electron
2026-04-14 15:06:39 <quinq> Sounds correct :)
2026-04-14 15:06:46 <quinq> It's needed for anything chromium-based
2026-04-14 15:07:02 <quinq> chromium, qt-webengine, electron, etc.
2026-04-14 16:36:27 <PureTryOut> For some reason abuild rootbld is not saving all the .apk's it's downloading to /var/cache/apk and thus redownloads it every time I run it. What could be the cause of that?
2026-04-14 16:38:38 <Sertonix[m]> Can you check (in htop or woth abuild -v) if the apk command is running with --cache-dir and/or --no-cache?
2026-04-14 16:50:55 <WhyNotHugo> PureTryOut:  Does /etc/apk/cache point there?
2026-04-14 17:09:12 <PureTryOut> WhyNotHugo: no such file exists
2026-04-14 17:09:45 <PureTryOut> Sertonix: it's running with neither
2026-04-14 17:39:12 <Sertonix[m]> If /etc/apk/cache doesn't exist then that is the problem.
2026-04-14 17:40:34 <f_|m> /etc/apk/cache does not exist for me yet cache works just fine
2026-04-14 17:40:44 <f_|m> ah eh nevermind
2026-04-14 17:56:04 <Sertonix[m]> Did people start using /etc/apk/config to enable the cache?
2026-04-14 17:57:23 <WhyNotHugo> PureTryOut: /etc/apk/cache should be a symlink to where you want your cache.
2026-04-14 17:57:27 <WhyNotHugo> setup-apkcache?
2026-04-14 19:12:24 <PureTryOut> Ah running pmOS so that's not available (no alpine-conf and installing it conflicts with init systems). I can make the symlink manually though, thanks for the pointers!
2026-04-14 19:14:06 <PureTryOut> yup that did the track, awesome!
2026-04-14 19:23:12 <omni> a package cache is very nice for when you need to downgrade packages
2026-04-14 19:25:48 <PureTryOut> Well I had the cache, regular apk invocations used it already just abuild didn't
2026-04-14 19:43:28 <ikke> it's apk that uses that symlink though
2026-04-14 20:07:42 <PureTryOut> Then idk why I did have a filled cache 🤔
2026-04-14 20:12:12 <panekj> something broke docker
2026-04-14 20:12:26 <panekj> failed to create endpoint lrlyfsngxy7y9nih8e1f3j5zw on network bridge: failed to add the host (veth9a664b1) <=> sandbox (veth66552c5) pair interfaces: operation not supported
2026-04-14 20:14:27 <panekj> or buildx since that's during building
2026-04-14 20:15:42 <panekj> oh, it's because kernel update
2026-04-15 00:22:37 <omni> Ariadne: https://github.com/jemalloc/jemalloc/releases/tag/5.3.1
2026-04-15 00:29:17 <Ariadne> what about it 
2026-04-15 00:53:58 <omni> as the maintainer of the aport, I thought you could be interested in the first release in four years
2026-04-15 01:34:55 <Ariadne> I find that suspicious tbh
2026-04-15 01:35:04 <Ariadne> Like some jia tan energy
2026-04-15 01:40:17 <omni> https://engineering.fb.com/2026/03/02/data-infrastructure/investing-in-infrastructure-metas-renewed-commitment-to-jemalloc/
2026-04-15 02:20:51 <omni> craftyguy[m]: I think your cosmic* test builds, in check(), may be overwriting the preceding builds due to the --release flag, it shouldn't happen if you run the tests with just cargo test --frozen
2026-04-15 02:21:10 <omni> something for the next upgrade, perhaps
2026-04-15 02:35:40 <craftyguy[m]> oh dang
2026-04-15 02:36:07 <craftyguy[m]> does that also prevent building everything again just to run tests?
2026-04-15 02:51:10 <omni> no, still does that, but to different target dir
2026-04-15 02:53:53 <omni> I'm a bit foggy, but `cargo test --release --frozen` may produce different output than `cargo auditable build --release frozen`
2026-04-15 10:11:05 <panekj> why are tests built in release mode?
2026-04-15 10:48:47 <ncopa> looks ok? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/e5b1220ea225b63858221f4b1390ae81fd24f8d5/posts/Alpine-3.20.10-3.21.7-3.22.4-3.23.4-released.md
2026-04-15 10:52:44 <ikke> Looks ok to me
2026-04-15 11:03:07 <ncopa> hmpf... the s390x release failed: https://tpaste.us/pyvg
2026-04-15 11:04:57 <ncopa> seems like this broke ABI: 755ed4df0d147f907017375571a9a7029f38fe30
2026-04-15 11:08:48 <omni> panekj: I have done this too and I think my idea has been that I should test the same thing that I packag
2026-04-15 11:09:03 <omni> then, some time ago, I learnt that this is not the correct aproach here
2026-04-15 11:11:44 <omni> ncopa: did we miss rebuilds?
2026-04-15 11:12:47 <omni> I tried to take care not to with !98224
2026-04-15 11:14:02 <omni> eddge is still missing rebuilds since !98035
2026-04-15 11:14:48 <omni> but I haven't managed to get them to pass !100495 !100713
2026-04-15 11:16:55 <omni> ncopa: and now I followed your link and, yes, we did miss s390-tools
2026-04-15 11:20:05 <omni> !100809
2026-04-15 11:20:14 <ncopa> in general, we shouldn't break ABI in stable releases. 
2026-04-15 11:21:24 <ncopa> maybe debian has backport patch for that snmp CVE
2026-04-15 11:21:52 <ncopa> also, its a bummer the riscv64 builder was mississing since March without anyone notice
2026-04-15 11:22:17 <ncopa> it now needs to build rust which will take a day or two
2026-04-15 11:22:41 <ncopa> for each branch, 3.22, 3.21 and 3.20
2026-04-15 11:22:52 <ncopa> so six days before its finished, best case
2026-04-15 11:23:14 <ncopa> and we cannot really do docker releases for those until those are finished
2026-04-15 11:23:39 <ncopa> so I think we will have to drop riscv64 support for 3.22-stable and older
2026-04-15 11:23:42 <ncopa> at least for now
2026-04-15 11:23:50 <ncopa> at least the docker image
2026-04-15 11:24:20 <omni> I think I did notice, but thought that it was that resources were directed to the python 3.14 rebuilds on edge, then forgot about it
2026-04-15 11:24:52 <ncopa> i think weneed to fix the builder infra
2026-04-15 11:25:11 <ncopa> i had a look at how to mark those servers as "offline"
2026-04-15 11:25:24 <ncopa> and we need to redesign it a bit
2026-04-15 11:25:35 <ncopa> not sure I will be able to do that and keep backwards compat :-/
2026-04-15 11:26:04 <omni> I've noticed that I sometimes have to retrigger builds for stable branches because they, or not all the builders, don't always seem to do when something is pushed
2026-04-15 11:28:48 <omni> uhm why does a simple rebuild of s390-tools add a lot of files to the package? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2307222
2026-04-15 11:28:51 <omni> Sertonix[m]: 
2026-04-15 11:31:55 <omni> ncopa: wrt not breaking ABI in stable releases, I'll keep that in mind, I didn't think about it in this case
2026-04-15 11:32:05 <ncopa> its easy to miss
2026-04-15 11:32:13 <ncopa> so no worries
2026-04-15 11:32:35 <ncopa> i also think its kinda ..... to do critical security release with breaking ABI included
2026-04-15 11:32:40 <ncopa> it is asking for trouble
2026-04-15 11:34:31 <omni> I only thought of what we package, but of course it may be breaking for someone relying on it to be stable in stable releases
2026-04-15 11:35:42 <omni> ncopa: but are you saying that we should revert the net-snmp uprade in 3.23-stable and patch instead?
2026-04-15 11:36:02 <omni> or just what we should do for the other stable branches
2026-04-15 11:36:54 <omni> I mean, undoing it now, and patching instead, may be breaking ABI twice for someone
2026-04-15 11:50:38 <ncopa> no, lets keep it as is and lets try avoid it in future
2026-04-15 11:50:56 <ncopa> yea, lets not break ABI twice
2026-04-15 11:51:02 <omni> 👍
2026-04-15 12:00:51 <ncopa> oh, and now openssl fails to build on 3.21... great...
2026-04-15 15:07:43 <Ariadne> https://alpinelinux.org/posts/Alpine-3.20.10-3.21.7-3.22.4-3.23.4-released.html there is a typo here "alpine linue" 
2026-04-15 15:07:59 <ikke> Someone already made an MR to fix it
2026-04-15 15:24:13 <ncopa> i was about to fix it but looks like someone fixed it
2026-04-15 16:02:25 <ikke> ncopa: is it expected 3.20-22 releases are not uploaded yet?
2026-04-15 16:03:22 <ncopa> what arch?
2026-04-15 16:03:38 <ikke> arm* x86*
2026-04-15 16:03:47 <ncopa> they should be uploaded
2026-04-15 16:04:07 <ncopa> only riscv64 should be missing
2026-04-15 16:04:20 <ikke> https://gitlab.alpinelinux.org/img/alpine/-/merge_requests
2026-04-15 16:04:21 <ncopa> so maybe they also broke... sigh
2026-04-15 16:04:29 <ikke> MR pipelines are failing
2026-04-15 16:05:05 <ikke> release 3.20
2026-04-15 16:05:13 <ncopa> huh
2026-04-15 16:05:15 <ikke> 3.21 x86 is missing
2026-04-15 16:05:19 <ncopa> its all broken
2026-04-15 16:05:30 <ncopa> 3.22 is only missing riscv64
2026-04-15 16:05:34 <ikke> yes
2026-04-15 16:06:30 <ncopa> im investigating
2026-04-15 16:08:58 <ikke> x86_64 for 3.21
2026-04-15 16:10:02 <ncopa> looks like builder didnt pick it up
2026-04-15 16:11:17 <ncopa> > verify that builders complete the release build successfully (check if release is uploaded to dl-master)
2026-04-15 16:11:23 <ncopa> i need a script for that....
2026-04-15 16:13:57 <ncopa> thank you for noticing
2026-04-15 16:34:50 <ncopa> bootstrapping builders fails due to libffi fails to build now
2026-04-15 16:35:03 <ncopa> tests fails
2026-04-15 16:35:10 <panekj> PureTryOut: omni: kde portal has been broken as well, i think together with spectacle
2026-04-15 16:55:35 <ncopa> libffi tests fails due to fortify i think
2026-04-15 17:34:48 <Sertonix[m]> I just opened a MR to avoid that in fortify-headers
2026-04-15 17:36:15 <Sertonix[m]> It should be safe to backport: https://github.com/jvoisin/fortify-headers/pull/88
2026-04-15 17:43:10 <realroot[m]> https://gist.github.com/clouedoc/14af89b947ddf7805e4b1765ba025cbf 
2026-04-15 17:43:10 <realroot[m]> >Driver 	mhi-pci-generic
2026-04-15 17:43:33 <realroot[m]> can somebody enable that for x86_64? do I have to open an issue?
2026-04-15 18:48:54 <jvvv> realroot[m]: best is for you to open an issue
2026-04-15 19:25:07 <ncopa> the -pyc enforcement causes problems for main/python3
2026-04-15 19:27:11 <ncopa> I think we need to revert
2026-04-15 19:28:14 <ikke> Hmm, no option to override
2026-04-15 19:28:23 <ncopa> thats why we need to revert
2026-04-15 19:49:20 <achill> see https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18123#note_602367
2026-04-15 20:54:16 <ncopa> thanks
2026-04-15 20:55:04 <ncopa> i think we will have enough with build failures due to fortify-headers, musl, linux-headers
2026-04-15 20:55:37 <ncopa> unreliable and slow riscv64 builders does not help either
2026-04-15 22:13:50 <Sertonix[m]> ncopa: Did you see !100825 ?
2026-04-15 22:43:22 <jvvv> omni: I think !100535 should be good to go.
2026-04-15 22:50:39 <omni> jvvv: good job!
2026-04-15 22:59:33 <jvvv> omni: Also I found an upstream fix for freecad 1.1.0 upgrade (specifically, the 32 bit build issue): https://github.com/FreeCAD/FreeCAD/commit/442baf1ddad9fa2bc852de555524975266969c1e
2026-04-15 23:03:30 <jvvv> I mentioned it in !100616, but I just noticed that you have !100398. I have !100725, but I only meant that for proving out the fix.
2026-04-15 23:31:34 <omni> jvvv: I've included your changes in my MR and rebased, I also want to try a rebuild once the new pyside6 is available in repositories
2026-04-15 23:34:44 <jvvv> That makes sense, I think. I am holding off on my asymptote MR until the pyside6 builds are through.
2026-04-16 01:03:44 <iggy> ikke: (and anyone else interested in the alpine go pkg): https://gitlab.alpinelinux.org/alpine/go/-/merge_requests/76 A huge improvement in package parsing performance, let me know how bad of a coder I am
2026-04-16 02:13:42 <jvvv> I think the s390x builder is stuck
2026-04-16 04:58:41 <ikke> ayakael: dotnet8 has a test failure
2026-04-16 04:58:46 <ikke> dotnet-trace                                                [FAIL](10s)
2026-04-16 09:02:56 <omni> ikke: is it why build-edge-armv7 is stuck?
2026-04-16 09:54:53 <ncopa> sigh, gettext tests fails now. dont know if it is due to new musl or fortify-headers
2026-04-16 11:15:47 <fabled> ncopa: maybe we should cherry pick https://git.musl-libc.org/cgit/musl/commit/?id=0572555dab1d1e10b5f7351a005ec588cab41e25
2026-04-16 11:16:16 <fabled> Not sure if this is the issue though 
2026-04-16 12:19:31 <ncopa> gettext failure was due to gettext bundled libunistring uses unicode 16, and the testsuite was expecting that, while system libunistring uses unicode 17
2026-04-16 12:32:33 <ikke> armv7 CI is way behind
2026-04-16 12:32:40 <ikke> 29 pending jobs
2026-04-16 12:32:58 <ikke> 38 pending jobs in total
2026-04-16 12:33:19 <fabled> Hrmpf. Qt 6.10.3 failed in 3.23-stable
2026-04-16 12:37:14 <ikke> Package epoxy was not found in the pkg-config search path.
2026-04-16 12:38:44 <fabled> yes, i wonder what changed, since in edge its not needed. perhaps some dependency used to depend on it or similar
2026-04-16 12:41:58 <fabled> ah, found the reason
2026-04-16 12:42:10 <fabled> it was pulled in by the gtk3 dependency earlier which was removed
2026-04-16 12:42:17 <fabled> will cherry-pick 648f94162c13e95914e1d5ab6d5c414480e0b19e
2026-04-16 12:42:37 <ikke> ncopa: to confirm, I was not able to build all the 3.20-3.22 images
2026-04-16 12:43:04 <ikke> s/not/now
2026-04-16 12:47:30 <PureTryOut> fabled: ah good find, I missed that was a thing
2026-04-16 13:03:22 <omni> PureTryOut: why was there no merge request for 7f00144934034b30108dc3978d1144b37104dfce ? have you verified that it builds on all architectures?
2026-04-16 13:22:02 <PureTryOut> omni: there was, GitLab was broken so I couldn't merge via UI and did it manually
2026-04-16 13:22:23 <PureTryOut> It's https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/100509
2026-04-16 13:29:23 <omni> ok, not many successful pipelines, hopep it works
2026-04-16 13:30:13 <omni> I don't think it should be possible to push directly
2026-04-16 14:06:17 <PureTryOut> It never has all arches succeeding because some of the CI builders are too slow for the sheer amount of packages
2026-04-16 14:54:02 <pj> omni: same
2026-04-16 15:01:24 <achill> ncopa: oh are you already bootstrapping? i was gonna merge your linux-headers 7.0 MR now
2026-04-16 15:21:54 <ncopa> I am bootstrapping yes
2026-04-16 15:22:12 <achill> urgh then its too late
2026-04-16 15:22:25 <ncopa> i have only started with riscv64
2026-04-16 15:22:32 <ncopa> so I think its fine
2026-04-16 15:23:07 <ncopa> i will have to bootstrap the other arches as well
2026-04-16 15:24:32 <achill> okay then i guess im merging it
2026-04-16 16:06:49 <ncopa> thanks!
2026-04-16 16:15:55 <omni> PureTryOut: I'm sure you have the best of intentions, but I think you need to be more patient, and perhaps extend the time of the pipelines, too often things break on the builders that would have been caught in CI
2026-04-16 16:16:33 <omni> and that's also related, too often things that break in CI is merged and then break the same way on the builders
2026-04-16 16:17:01 <omni> and the impact is not limited
2026-04-16 17:08:35 <PureTryOut> I have no possibility of extending pipeline timeouts, and I'm pretty sure it already has been extended quite a bit. Some builds just can not be executed in CI properly and there is nothing more to do then trying to make sure the stuff we do know breaks is fixed before merging. And that's what I'm doing
2026-04-16 17:37:12 <f_> PureTryOut: you can adjust them in your fork's repo settings
2026-04-16 17:55:55 <achill> f_: for developers the repo where CI runs is the alpine/aports repo where we cant edit CI configuration
2026-04-16 17:56:04 <f_> ah
2026-04-16 18:10:31 <ncopa> >>> perl*: Tracing dependencies...
2026-04-16 18:10:31 <ncopa> ERROR: /usr/lib/libgdbm.so.6.0.0: Could not find owner package
2026-04-16 18:10:31 <ncopa> ERROR: /usr/lib/libgdbm_compat.so.4.0.0: Could not find owner package
2026-04-16 18:10:46 <ncopa> I wonder if this is related new abuild?
2026-04-16 18:11:00 <ncopa> happens when trying to bootstrap build-3-24-aarch64 (using edge packages)
2026-04-16 18:33:06 <ncopa> drats
2026-04-16 18:33:57 <ncopa> i cloned the builders while they were running lots of deps installed
2026-04-16 18:34:14 <ncopa> i need to kill the build and clone the builder after that
2026-04-16 18:34:46 <ncopa> otherwise I have lots of deps installed without knowing what package they came from 
2026-04-16 18:50:33 <fabricionaweb> now that they changed vapoursynth I want to port to try it to alpine https://www.vapoursynth.com/2026/03/26/new-packaging-and-install-methods-in-r74/
2026-04-16 19:05:29 <runxiyu> a
2026-04-16 20:10:06 <ncopa> im bootstrapping the 3.24 builders now
2026-04-16 20:10:21 <ncopa> hopefully they will be done by tomorrow
2026-04-16 20:10:38 <ncopa> it means we are effectively in a feature freeze for main  now
2026-04-16 20:11:03 <ncopa> at least for build tools (gcc, make, autoconf, etc)
2026-04-16 23:25:53 <panekj> can we revert the KDE bumps...? I can live without screenshots (barely) but the portal is broken which means I can't deal with any files
2026-04-17 00:12:57 <aelin> whynothugo: why not just merge my MR?
2026-04-17 00:13:08 <aelin> why do peopel always disable things rather than looking at open MRs :(
2026-04-17 00:13:19 <WhyNotHugo> I didn't see it, sorry.
2026-04-17 00:14:15 <WhyNotHugo> aelin: ^ can you re-enable aarch64 on that MR?
2026-04-17 00:14:24 <aelin> ...sure, one moment
2026-04-17 00:16:52 <aelin> done
2026-04-17 00:35:15 <WhyNotHugo> Does Alpine discourage/forbid having multiple versions of the same package? For example, builds with and without PAM?
2026-04-17 00:35:46 <aelin> looking at OpenSSH, doesn't seem so
2026-04-17 00:37:06 <omni> would be different subpackages of the same aport, no?
2026-04-17 00:38:49 <WhyNotHugo> Asing in reference to !59022
2026-04-17 00:39:14 <WhyNotHugo> Upstream is adverse to the idea of having a single build usable with/without pam.
2026-04-17 00:39:53 <WhyNotHugo> If having multiple versions is not frowned upon, I don't understand what blocks that.
2026-04-17 00:45:16 <omni> do you mean "variants"?
2026-04-17 00:46:43 <omni> I think it makes sense to have two builds packaged separately as in what that MR does and what emersion suggests
2026-04-17 00:55:13 <unvFK9I3vgc> WhyNotHugo: think of emacs, it comes in many flavors
2026-04-17 00:55:51 <WhyNotHugo> omni: two separate packages, or subpackages as done with openssh?
2026-04-17 00:58:31 <omni> WhyNotHugo: a single aport seems easier to maintain
2026-04-17 00:58:55 <WhyNotHugo> Not sure to do in this case with the maintainer being unreponsive tho.
2026-04-17 00:59:02 <WhyNotHugo> And we likely need thre flavours/variants.
2026-04-17 01:04:22 <omni> then maybe add a separate swaylock-shadow aport and try to convince them to include it as a subpackage of swaylock later, idk
2026-04-17 01:05:08 <omni> but perhaps it is possible to ping them some other way than through the MR, like via en electronic mail
2026-04-17 01:05:44 <panekj> no idea what that is, seems like an ancient technology
2026-04-17 01:07:03 <omni> something with circuits, I recall, have barely used it since last century
2026-04-17 01:10:55 <WhyNotHugo> Do I need access to a multivac for that?
2026-04-17 06:59:58 <iggy> there's certainly different versions as separate packages (ceph is the first one that comes to mind)
2026-04-17 07:03:52 <ikke> Yes, but we don't want to make that the norm
2026-04-17 10:26:46 <ikke> bootstrapping rust on x86_64
2026-04-17 10:28:07 <ikke> bootstrapping rust on x86
2026-04-17 10:29:55 <ikke> bootstrapping rust on aarch64
2026-04-17 10:39:18 <ikke> bootstrapping rust on armv7/hf
2026-04-17 11:02:22 <ncopa> thanks!
2026-04-17 11:02:46 <ncopa> i have upgraded the msg.a.o server to v3.23. I'm not sure if the builders are re-connecting
2026-04-17 11:03:03 <ncopa> there seems to be some activity at least
2026-04-17 11:22:02 <ncopa> ikke: can you please bootstrap rust on ppc64le as well?
2026-04-17 11:23:38 <ikke> ncopa: yes
2026-04-17 11:27:01 <ncopa> thanks
2026-04-17 11:27:35 <ikke> x86_64 and aarch64 have finished
2026-04-17 11:33:14 <ncopa> how many arches are missing to bootstrap rust? I have finished riscv64
2026-04-17 11:33:41 <ikke> s390x and loongarch
2026-04-17 11:33:58 <ncopa> ok
2026-04-17 11:34:13 <ncopa> https://build.alpinelinux.org/ appaears to be broken after msg.a.o restart
2026-04-17 11:35:58 <ikke> Restarted the backend
2026-04-17 11:36:24 <ikke> Means builders will appear once it sends messages
2026-04-17 11:37:02 <ncopa> thanks!
2026-04-17 12:00:21 <ikke> x86, armv7, armhf, ppc64le finished
2026-04-17 13:54:13 <andar1an> not issue worthy and I may be wrong, but dies stop_post for openssh server init service need to have _sshd_pids=$(pgrep "sshd-session:") updated to maybe just "sshd:"? I needed to change for openssh-server-pam, so can't confirm if openssh-server process is named sshd-session:, but if not stopping the rc-service doesn't stop the process. 
2026-04-17 13:57:40 <andar1an> if it is issue worthy, just let me know and I can take a moment to create, but thought I would put here first
2026-04-17 14:09:55 <ikke> oh, rust bootstrap failed
2026-04-17 14:13:00 <ikke> on ppc64le*
2026-04-17 14:14:22 <ikke> Bootstrapping rust on loongarch64
2026-04-17 16:05:49 <omni> I see that andar1an also created an issue, #18130
2026-04-17 19:41:35 <ncopa> circular deps: sanlock -> lvm2 -> sanlock
2026-04-17 19:42:20 <ncopa> there is nothing in the abuild dep chain that pulls in lvm2, so I don't think it will be build during initial aports bootstrap
2026-04-17 20:12:19 <ikke> bootstrapping rust on s390x
2026-04-17 20:50:27 <Sertonix[m]> ncopa: It could be solved my extracting libsanlock_client into it's own APKBUILD. Not a very nice way though
2026-04-17 20:51:19 <ncopa> indeed
2026-04-17 20:55:38 <ncopa> we should try keep the build-3-24-riscv64 busy. it is the bottleneck for the release
2026-04-18 02:16:45 <panekj> thank you to whoever fixed kde progs
2026-04-18 02:22:11 <Saijin_Naib[m]> What is the way to check if a particular package on a builder has been rebuilt yet?
2026-04-18 02:22:44 <Saijin_Naib[m]> it seems py3-discid is still built against python 3.12 on riscv64 builder, so my package rebuilds are breaking since some riscv64 was built against python 3.14, but not all
2026-04-18 02:33:31 <omni> as in built but not uploaded yet? have a look in https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/$pkgname/ (or testing or main)
2026-04-18 02:50:25 <Saijin_Naib[m]> Sweet! Buildlog says it succeeded two days ago, but CI one is still built against 3.12?
2026-04-18 03:03:39 <Saijin_Naib[m]> For pkgs.alpinelinux.org, would it be considered a better UX if the untracked packages (not checked against anyita/release-monitoring.org) showed the version string as black/white instead of green, like it does currently?
2026-04-18 03:04:03 <Saijin_Naib[m]> That sort of is a false-positive for current version checking when scanning through the list of pacakges, just as red would be (likely) a false negative
2026-04-18 03:04:27 <Saijin_Naib[m]> I also have no idea how hard that would be to implement and can't do it, so just asking prior to potentially opening a Feature Request
2026-04-18 03:04:58 <Saijin_Naib[m]> userstory: I like to check if packages are current, and try to add them to release-monitoring if I know they are untracked, this would make both things much easier
2026-04-18 05:47:26 <ncopa> seems like rust on s390x is done. I'm restarting that builder.
2026-04-18 05:55:30 <ncopa> i am retrying rust on ppc64le
2026-04-18 05:58:41 <ikke> ncopa: ack
2026-04-18 06:30:59 <ncopa> >>> ERROR: nftables*: Packages must not put anything under /etc/nftables.d, use /usr/share/nftables.avail instead
2026-04-18 06:31:12 <ncopa> smells like abuild is too restrictive again
2026-04-18 06:45:41 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/18132
2026-04-18 06:46:36 <ncopa> i reverted the nftables postcheck
2026-04-18 08:02:04 <Saijin_Naib[m]> omni not even just not rebuilt, but a minor version behind all the other arches and has not been rebuilt in almost a year!
2026-04-18 08:02:05 <Saijin_Naib[m]> https://pkgs.alpinelinux.org/packages?name=py3-discid&branch=edge&repo=&arch=&origin=&flagged=&maintainer=
2026-04-18 09:01:13 <bdprom> is there a script or anything that lists flagged/outdated packages installed on my system? i'd like to contribute with some aport maintenance, but prefer to push only updates that i dogfood myself
2026-04-18 09:21:36 <omni> Saijin_Naib[m]: riscv64 is not done with python 3.14 rebuilds of testing/ yet and hasn't uploaded, and it hasn't built 1.3.0-r1 because py3-discid was upgraded to 1.4.0 before build-edge-riscv64 got to it
2026-04-18 10:28:52 <omni> invoked: did you try the arti 2.2.0 build?
2026-04-18 11:50:53 <raspbeguy> mio, ncopa: here is a draft for solving lvm2/sanlock circular deps !100961
2026-04-18 12:19:00 <pc_magas> A package of mine seemto be released upon testing: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97429 how I can install it in my system?
2026-04-18 13:07:32 <raspbeguy> mio, ncopa: now everything pass
2026-04-18 13:07:49 <raspbeguy> (in the pr)
2026-04-18 13:17:08 <Leso> Hello! Brief question: We just merged !97109 which upgrades testing/piper-tts to 1.4.2. The problem is that the package has changed the versioning scheme from dated versions to semantic (?) versioning, in any case the new version number is now lower than the previous one causing the builders to ignore the update
2026-04-18 13:17:22 <Leso> Is there any common practice to deal with this kind of upstream change?
2026-04-18 13:23:38 <Sertonix[m]> Since it is only in testing it might be enough to require users to run "apk upgrade -a" which will do the version downgrade
2026-04-18 13:24:38 <Leso> @Setronix Yes, that would be fine of course :) The problem is rather that the builders do not build the package in the first place, since – I guess – they do not recognize that a rebuild is necessary
2026-04-18 13:26:55 <Leso> see https://pkgs.alpinelinux.org/packages?arch=&name=piper-tts
2026-04-18 13:27:59 <Leso> Should I ask in the #alpine-infra channel or is this the right place?
2026-04-18 13:28:22 <Sertonix[m]> The builders might be paused. Downgrades still trigger rebuilds
2026-04-18 13:28:40 <Leso> oh okay, interesting
2026-04-18 17:06:26 <el[m]1> https://news.opensuse.org/2025/11/04/raspberrypi5-opensuse/ you might find this interesting. opensuse apparently upstreamed a bunch of the raspberry pi 5 hardware support. so i'm guessing alpine's kernel could probably drop some of the patches
2026-04-18 18:45:03 <ncopa> raspbeguy: I set APORTS_BOOTSTRAP=1 and built it manually on all builders. its a bit annoying
2026-04-18 18:45:58 <ncopa> el[m]1: would be great if we could drop the linux-rpi kernel and only use mainline
2026-04-18 19:38:01 <omni> and enable linux-lts on armhf?
2026-04-18 19:40:25 <abby> fwiw even with the suse patches it looks limited, no usb or pcie boot
2026-04-18 20:57:31 <andypost[m]> [@_oftc_omni:matrix.org](https://matrix.to/#/@_oftc_omni:matrix.org) I think !100917 could be merged thank you 
2026-04-18 20:59:47 <andypost[m]> Btw why mariadb checksums broken again?
2026-04-18 23:24:09 <omni> andypost[m]: you approve of my madness? ok :D
2026-04-19 02:11:42 <craftyguy[m]> could a maintainer please take a look at !100941? Thanks :)
2026-04-19 11:10:17 <omni> please hold merging to master for a bit, something semms to be up...
2026-04-19 11:59:45 <raspbeguy> hello, I fixed my MR !100961 about circular deps between lvm2 and sanlock
2026-04-19 12:00:57 <raspbeguy> I also wish my fix for ghostty would be merged soon !99729
2026-04-19 12:47:17 <omni> unhold
2026-04-19 12:48:25 <omni> packages were built and uploaded but logs weren't, is what was up, sorted now
2026-04-19 14:34:38 <quinq> wiki down for me and everyone else
2026-04-19 14:43:12 <quinq> In the meantime, do I need to have a user in any special group in order to be able to use Bluetooth headset?
2026-04-19 14:53:34 <Biswa96[m]> quinq: this archive may help https://web.archive.org/web/20260310032731/https://wiki.alpinelinux.org/wiki/Bluetooth
2026-04-19 14:54:52 <quinq> Thank you Biswa96[m] :)
2026-04-19 15:25:36 <quinq> Allright, it works, seems I was missing the pipewire-spa-bluez package
2026-04-19 15:40:11 <ikke> wiki is working for me (now)
2026-04-19 15:42:08 <Biswa96[m]> yup, it's working now. but sometime ago, it was showing 502 error https://http.cat/status/502
2026-04-19 15:53:19 <quinq> Yeah ikke, it's back now
2026-04-19 17:55:01 <anton>  hello users
2026-04-19 19:04:31 <f_> hello you're gone already :(
2026-04-19 19:09:07 <quinq> https://youtu.be/5O6KDuKJoB0
2026-04-20 05:31:23 <quinq> WhyNotHugo, does librewolf APKBUILD really have to depend on jq?
2026-04-20 05:31:29 <quinq> Could simple use sed
2026-04-20 05:31:52 <quinq> Like: sed -n 's/.*"sha":"\([^"]\{1,\}\)".*/\1/p'
2026-04-20 09:15:45 <lindsay> Could someone help review !99421? I add a new aport `yoga` into community repo directly, which need by fcitx5.
2026-04-20 11:30:44 <Sertonix[m]> quinq: It doesn't depend on jq, you can just manually change the commit hashes like I did.
2026-04-20 19:22:32 <roselandgoose> Could someone with merge take a look at !100253 please. I've got thumbs up from the maintainer
2026-04-20 19:22:49 <roselandgoose> and I'd love to have this in before upstream releases _again_ lol
2026-04-20 19:23:55 <roselandgoose> (which, actually, it looks like they did 3 hours ago.. oye ve)
2026-04-20 21:08:44 <roselandgoose> thank you! :)
2026-04-21 04:39:01 <Saijin_Naib[m]> Anyone able to help me with bumping xfce4-screensaver from 4.18.4 to 4.20.2?
2026-04-21 04:39:18 <Saijin_Naib[m]> Build went from autotools to meson, but there seems to be need for fixed patching
2026-04-21 04:39:42 <Saijin_Naib[m]> There are non-trivial security fixes that should make it less likely to show the desktop when resuming, etc, which are important
2026-04-21 04:39:46 <Saijin_Naib[m]> I've taken a few passes at it, but I keep getting stuck
2026-04-21 04:40:07 <Saijin_Naib[m]> I think it is the only xfce4 component we are back-level on, currently
2026-04-21 05:14:37 <Biswa96[m]> is there any error?
2026-04-21 05:25:44 <Saijin_Naib[m]> Oh, not this time
2026-04-21 05:25:54 <Saijin_Naib[m]> Last time I tried was at 4.20.0, this time went very smooth
2026-04-21 05:26:41 <Saijin_Naib[m]> Now remaining rough edges are the "hack" that allows xfce4-screensaver to use xscreensaver modules (a symlink, I think, to look where their .desktop files are stored) and testing/verification from more knowledgeable people that it built right, PAM works right, etc
2026-04-21 05:26:51 <Saijin_Naib[m]> I just used it for a suspend/reusme cycle and it seems to behave well
2026-04-21 05:27:17 <Saijin_Naib[m]> To be clear, our version never supported the xcreensaver modules properly
2026-04-21 05:27:36 <Saijin_Naib[m]> I can't enable wayland, as we are missing some deps
2026-04-21 05:27:51 <Saijin_Naib[m]> But wayland support with XFCE4 is still experimental, so I believe that should be acceptable at this point to have it disabled?
2026-04-21 05:28:41 <Saijin_Naib[m]> same goes for the systemd module, as we do not seem to ship libsystemd-dev
2026-04-21 05:35:57 <Saijin_Naib[m]> https://docs.xfce.org/apps/xfce4-screensaver/faq#where_are_all_the_screensavers
2026-04-21 05:36:47 <Saijin_Naib[m]> https://www.reddit.com/r/xfce/comments/tcst5b/comment/lsbodxo/
2026-04-21 05:37:05 <Saijin_Naib[m]> We need to generate .desktop files for each xscreensaver module for XFCE4 Screensaver to use them
2026-04-21 05:59:51 <Saijin_Naib[m]> 
ACTION uploaded an image: (145KiB) < https://matrix.org/oftc/media/v1/media/download/AfZTIvWsCwtlzdZqXBQBXvCAVICwx5-LmnoBgDMEkteRn_yaKrUGbOEhWYcSuPz_gVYWZ2-Lx6bH6w7bHNCZq-5Ced9rirugAG1hdHJpeC5vcmcvS05RUFNDQUpma3hPc25OQ0JhVHNPdlJF >

2026-04-21 05:59:58 <Saijin_Naib[m]> So, that bash script works, and they do work fine in xfce4-screensaver
2026-04-21 06:00:34 <Saijin_Naib[m]> Would that need to be a post-install script in the xscreensaver-extras and xscreensaver-gl-extras packages to make those desktop files for xfce4-screensaver to pick up when they are installed?
2026-04-21 06:31:30 <ncopa> I am not able to reproduce the libmicrohttpd test error locally
2026-04-21 06:33:57 <ncopa> oh.. I can reproduce it, with abuild rootbld
2026-04-21 09:46:50 <ncopa> the 3.24 builders are done with main and starting with community now
2026-04-21 09:58:21 <ncopa> im bootstrapping go on build-3-24-loongarch64
2026-04-21 11:29:14 <sam_> ncopa: thanks for commenting on the microhttpd ubg
2026-04-21 11:29:15 <sam_> bug
2026-04-21 12:53:17 <ncopa> no wor
2026-04-21 12:53:22 <ncopa> no problem
2026-04-21 12:53:44 <ncopa> it does look like a bug in openssl
2026-04-21 14:43:47 <quinq> Hi
2026-04-21 14:43:52 <quinq> Trying to build linux-lts: /DATA/DEV/Alpine/aports/main/linux-lts/0001-x86-CPU-AMD-avoid-printing-reset-reasons-on-Xen-domU.patch: FAILED
2026-04-21 14:46:03 <quinq> Sorry, nevermind, I didn't know that abuild doesn't lookup the filenames but instead relies on having same source order as the sums
2026-04-21 15:08:40 <quinq> Ouch, seems there's an actual bug though (with abuild?)
2026-04-21 15:09:54 <quinq> The process ignores SIGSTOP (or doesn't propagates it correctly)
2026-04-21 15:10:22 <quinq> So you just suspend the controlling abuild process, but the compilation is still continuing in the background
2026-04-21 15:11:48 <quinq> Note that this is with abuild rootbld, might give a hint
2026-04-21 15:16:31 <skarnet> you can't catch SIGSTOP at all, or propagate it
2026-04-21 15:17:01 <skarnet> when set to a process, it impacts the process and the process only; when you ^Z, it impacts the foreground process group
2026-04-21 15:17:10 <skarnet> s/set/sent/
2026-04-21 15:17:59 <skarnet> abuild rootbld might do something with bwrap or similar that isolates the build in a different session/process group/namespace
2026-04-21 15:18:17 <skarnet> so a SIGSTOP sent to the fronting program would not impact what is going on in the subprocesses
2026-04-21 15:18:26 <quinq> Yes, that's why I said it's with rootbld
2026-04-21 15:18:36 <quinq> bwrap seems to spawn with a different process group id
2026-04-21 15:18:52 <skarnet> there's your reason
2026-04-21 15:19:06 <quinq> Yes, that's the problem
2026-04-21 15:19:38 <quinq> Next is, why
2026-04-21 15:19:45 <quinq> Or rather how to not do this
2026-04-21 15:21:51 <quinq> Maybe by not asking for --unshare-pid
2026-04-21 15:22:04 <skarnet> don't SIGSTOP a hierarchy containing multiple process groups
2026-04-21 15:22:53 <quinq> Yes, that's what's not working and is the issue
2026-04-21 15:23:10 <skarnet> you have an inherent conflict between job control and task isolation
2026-04-21 15:23:23 <skarnet> there's no easy solve, you have to choose what you want to prioritize
2026-04-21 15:23:26 <quinq> You can only stop the front-end, the rest will still be running without control
2026-04-21 15:24:29 <quinq> Yeah, that's why I'm suggesting not passing --unshare-pid (though I'm unsure that's the actual option that spawns a new group pid)
2026-04-21 16:38:43 <Sertonix[m]> The only robust solution I can think of would be to usr a complete VM like QEMU system which you can hold completely.
2026-04-21 16:39:35 <Sertonix[m]> As far as I remember processes can just change their own group pid which would make that unreliable
2026-04-21 17:47:17 <quinq> I don't know a build system that does that, but if/when that happens then it could be patched if needed
2026-04-21 17:55:14 <quinq> Other question, I need to patch a linux driver (drivers/bluetooth/btusb.c)
2026-04-21 17:55:44 <quinq> I see that akms exists, could it be done somehow without too much hastle with it?
2026-04-21 17:56:08 <quinq> (instead of having to rebuild the entire kernel port)
2026-04-21 19:41:56 <ncopa> I lots of those module not found errors in python packages. whats going on? https://build.alpinelinux.org/buildlogs//build-edge-riscv64/testing/py3-mapbox-earcut/py3-mapbox-earcut-1.0.1-r4.log
2026-04-21 19:42:53 <ncopa> using python3 -m installer works, but I dont know if that is the right way to fix it? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/101122/diffs
2026-04-21 19:46:35 <ncopa> same here: no module found https://build.alpinelinux.org/buildlogs//build-edge-riscv64/testing/py3-cdio/py3-cdio-2.1.1-r7.log
2026-04-21 20:00:14 <omni> we did notice issues with the new py3-installer a couple of weeks ago, didn't get much feedback on !100227 and am not sure it's the right course of action
2026-04-21 21:57:21 <omni> ncopa: ah, yes, both of those aport you mention utilize `gpep517 install-wheel` and that doesn't work since py3-installer 1.0.0
2026-04-21 21:58:13 <omni> I didn't look there a couple of hours ago, thought it was something new we hadn't seen yet
2026-04-21 22:02:55 <omni> so I guess I'd still advocate for getting aports in line with the most common, and with py3-installer 1.0.0 the only functional, way of installing wheels, with `python3 -m installer` rather than `gpep517 install-wheel`
2026-04-21 22:03:42 <omni> most of the now "broken" python aports are in testing/ and about fiftyish in community/
2026-04-21 22:35:37 <WhyNotHugo> Building a wheel (zip) and then unpacking it so weird. I've been thinking of a drop-in replacmenet for the wheel package which just puts the file in a target directory¸ so we can avoid the pack->unpack step (and also no need for `py3-installer`)
2026-04-21 22:35:44 <WhyNotHugo> The odd part is that build-packaging becomes one step.
2026-04-22 00:36:30 <ayakael> I'm investigating the dotnet-related build issues with 3.14