2026-05-01 00:20:35 <ayakael> I'll be pushing an update to electron to fix the sandbox related changes. Sorry for the delay, the last few weeks has been difficult with time
2026-05-01 09:04:02 <bdprom> community/llhttp-9.4.1 now includes support for building shared AND static libs, should i build & subpackage the static lib variant too, or leave as just shared only?
2026-05-01 09:07:39 <ncopa> go for shared only, til someone ask for static lib
2026-05-01 09:08:15 <bdprom> will do, thanks :)
2026-05-01 09:18:45 <bdprom> oh, it includes a soname bump which wasnt reported by abuild, ive never done a soname bump before, guess i'll leave it (i know the theory at least..? just pkgrel+1 its revdeps as reported by `apk query --match depends so:libllhttp.so.9.3`?)
2026-05-01 09:23:03 <achill> sounds correct, yeah
2026-05-01 09:28:50 <bdprom> thanks, i'll give it a go
2026-05-01 09:49:47 <ikke> bdprom: use checkapk, it will report soname changes 
2026-05-01 09:50:10 <ikke> (abump automatically invokes it)
2026-05-01 09:57:36 <bdprom> ikke: ah thanks, i assumed abuild ran it, not abump, TIL
2026-05-01 10:03:42 <Sertonix[m]> [@PureTryOut:matrix.org](https://matrix.to/#/@PureTryOut:matrix.org) In the python 3.14 upgrade py3-speechrecognition got removed but there are 2 packages in testing that depend on it. It would be possible to package 2 compatibility libraries or try patching py3-speechrecognition or drop the 2 testing packages as well. Any preference?
2026-05-01 11:43:07 <PureTryOut> Oh I missed that, sorry for that. I'd have to check what those packages are but since no one has complained about it so far (it's been a while since I dropped py3-speechrecognition) I'm leaning towards just removing it
2026-05-01 11:43:59 <PureTryOut> Ah ovos things, yeah I have a WIP PR open which upgrades a bunch of stuff and pretty sure they also got rid of this dep. Not sure if the current versions can run without it yet though
2026-05-01 16:58:17 <jvvv> In reference to #17976, I submitted upstream PR https://github.com/ImageMagick/ImageMagick/issues/8709. Upstream has decided to not change due to security implications (understandable). Not sure of next step.
2026-05-02 03:17:52 <Sertonix[m]> achill: Not sure how to create usable notifications but I was at least able to dump MRs including effected packages: https://paste.sr.ht/~sertonix/3d7e6aa4e1646739b5e5f393f372f8dd74c9ded5
2026-05-02 03:19:51 <Sertonix[m]> (I should probably rewrite that in python or js)
2026-05-02 03:33:05 <jvvv> py3-sphinxcontrib-actdiag is failing but might build if !101756 is merged. That MRs CI is failing for riscv64 because that builder has not uploaded py3-blockdiag pkgs yet (build was successful on 16Apr
2026-05-02 03:34:21 <jvvv> How can riscv64 builder be made to upload its built pkgs?
2026-05-02 05:48:09 <ikke> jvvv: isn't it?
2026-05-02 08:54:43 <jvvv> ikke: the latest build log for py3-blockdiag is py3-blockdiag-3.0.0-r7.log, but latest package in repo is py3-blockdiag-3.0.0-r6.apk  
2026-05-02 08:56:50 <jvvv> that build log was generated 16 Apr and it shows a successful build. I would have expected that by now it would be uploaded to repo.
2026-05-02 08:58:25 <jvvv> Not sure what else to think, except maybe the built package got lost somehow.
2026-05-02 09:05:22 <ikke> It can still be present on the builder 
2026-05-02 10:04:54 <ncopa> build-edge-riscv64 finally completed
2026-05-02 10:05:04 <ncopa> after a month or so?
2026-05-02 10:13:32 <f_> wow
2026-05-02 11:34:32 <ikke> Any ideas about the rpi kernel?
2026-05-02 13:38:53 <WhyNotHugo> Fun fact: if one commit moves a file and another commit changes contents of the file, GitLab's UI says "File renamed with no changes"
2026-05-02 13:39:06 <WhyNotHugo> Example: !101549 (the .patch URL actually shows the changed lines)
2026-05-02 13:46:13 <Advert[m]> https://t.me/+c-LC9ed_hBgwYmZh
2026-05-02 14:28:34 <Sertonix[m]> I think the real issue is that gitlav has horroble cache invalidation of the MR views
2026-05-02 14:33:00 <ikke> Sertonix[m]: it's asynchronous and depends on gitaly being available
2026-05-02 14:33:08 <ikke> If gitaly is under load, it can be delayed
2026-05-02 20:08:45 <ikke> Heads-up, aarch64/arm* CI is currently down
2026-05-02 20:10:20 <ayakael> Electron update for latest musl: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/101720
2026-05-02 21:49:35 <omni> WhyNotHugo: it's interesting that librewolf also builds firefox-on-glean (I read the comment on why it's disabled on x86), I thought they boasted about "No Telemetry"
2026-05-02 21:50:22 <WhyNotHugo> I've been looking at removing at and it's **really** deeply intertwine with the entire codebase.
2026-05-02 21:50:35 <WhyNotHugo> *intertwined
2026-05-02 21:51:01 <WhyNotHugo> It's feasible to make a drop-in replacement for glean that's a no-op and doesn't have all the dozens of dependencies that glean pulls in.
2026-05-02 21:51:32 <WhyNotHugo> I gave up after 1k LoC replacing the entire API surface with no-op.
2026-05-02 21:51:51 <omni> I feel you
2026-05-02 21:52:17 <WhyNotHugo> The only thing keeping me from using qutebrowser is that it doesn't have feature-parity with ublock… maybe me time is best spent there.
2026-05-02 21:52:25 <WhyNotHugo> But I think there's a patch which lack of reviewer bandwidth.
2026-05-02 21:52:34 <omni> I was hoping to find a way to build firefox/firefox-esr on x86
2026-05-02 21:53:24 <WhyNotHugo> I'm tempted to open an issue upstream: "telemetry is so memory-intensive to build that we can't build Firefox without massive amounts of memory".
2026-05-02 21:55:05 <omni> I think the issue is that 32bit x86 cannot allocate that much memory
2026-05-02 21:55:20 <omni> it may be possible to fiddle with the build options to make it pass
2026-05-02 21:56:11 <WhyNotHugo> We *can* increase the amount of LTO jobs, which spreads the work across multiple processes, but this degredes performance.
2026-05-02 21:57:00 <omni> wrt py3-adblock, I have a couple of times looked at updating it to build with latest brave/adblock-rust, I did make some progress sometime last year (I wonder what I did with that work..)
2026-05-03 06:31:55 <ikke> I'm in EFI-ception
2026-05-03 06:46:26 <ikke> arm* CI has been fixed
2026-05-03 07:29:36 <ncopa> im bootstrapping openjdk8 (and 11?) on build-3-24-x86
2026-05-03 10:29:46 <ikke> che-ci-1 was still running an older edge kernel. The lts kernel failed to boot because the bootloader needed to be updated. Took a while before I had a running environment to fix it in, and figuring out I had to mount the boot partition in /boot/efi, not /boot
2026-05-03 13:22:59 <ncopa> oh..
2026-05-03 13:54:36 <jvvv> if an MR is just changing the source url, does it need a pkgrel bump?
2026-05-03 13:55:16 <ikke> jvvv: The source url is not recorded in the packge. If the source remains exactly the same, I don't see a reason
2026-05-03 13:59:58 <jvvv> ikke: Thanks. There is a more dependable source url for libtickit and the checksum matches so I think I should change it so it clear the builders better.
2026-05-03 14:12:58 <jvvv> If someone could merge !101828, it should help fix the libtickit fetch failures on the builders.
2026-05-03 14:13:33 <ikke> !101828
2026-05-03 14:13:55 <jvvv> Thanks mio!
2026-05-03 14:14:20 <mio> you're welcome
2026-05-03 14:29:39 <Lool78> @fcolista :  I have update traefik to cover CVEs (including CVE-2026-35051 rated as critical) -, here is the PR : https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/101829
2026-05-03 14:38:31 <Antiz1> Can I get someone to look at !99837 and !99824 by any chance? 🤗
2026-05-03 15:21:05 <Lool78> Hi all can someone push the !100634 (opencloud)
2026-05-03 15:30:09 <Lool78> @omni : Correction done int he description of the traefik package, see !101829
2026-05-03 15:40:31 <ikke> Lool78: I don't see the secfixes update yet. Did you forget to include it, or is gitlab showing out-of-date info?
2026-05-03 15:40:59 <ikke> https://gitlab.alpinelinux.org/Lsm-CVX/aports/-/commit/3c9cb622961a22ad266b1b309118e3d6172282f6
2026-05-03 16:07:25 <Lool78> <@ikke> : I was sure to have made the modification with a  git commit --amend let me dig 
2026-05-03 16:11:47 <Lool78> I have redone it : see https://gitlab.alpinelinux.org/Lsm-CVX/aports/-/commit/36246b2b642ba5fa75ca0104ef63852c0213743a 
2026-05-03 16:12:05 <Lool78> Do you need me to do some thing more ? 
2026-05-03 18:41:50 <ikke> ghc on aarch64 fails due to a sphinx isseu
2026-05-03 18:42:39 <ikke> https://tpaste.us/DrKd 
2026-05-03 18:46:32 <jvvv> ikke: do you have link to full log?
2026-05-03 18:47:35 <ikke> jvvv: I still have it in my terminal, the log file was sadly overwritten
2026-05-03 18:48:04 <ikke> hmm, sadly, it's soo big that part if it was truncated
2026-05-03 18:48:35 <ikke> oh, n/m
2026-05-03 19:48:26 <ikke> jvvv: http://build.alpinelinux.org/buildlogs/build-3-24-aarch64/community/ghc/ghc-9.10.3-r1-bootstrap.log
2026-05-03 20:24:03 <jvvv> ikke: Is there any thing special I should have set when starting build that makes it a "bootstrap" build? I have abuild running now in a qemu-user chroot, but now I'm not sure if I should have done any thing extra for the build environment besides `abuild deps` before starting.
2026-05-03 20:24:35 <ikke> jvvv: no, not in these cases, only install ghc-bootstrap from edge
2026-05-03 20:25:19 <ikke> This is the snippet I use to bootstrap ghc: https://tpaste.us/BMYb 
2026-05-03 20:29:13 <jvvv> Ok, thanks.
2026-05-03 21:25:02 <jvvv> Would the rpi5 be a good sbc for home package building, or are there more powerful sbc's that would be a better fit in similar price range?
2026-05-03 21:26:15 <jvvv> Actually, doesn't need to be a sbc, I was just thinking that would keep costs down.
2026-05-04 05:17:47 <WhyNotHugo> I merged an MR for pipewire which introduced a new dependency (libmysofa). The dependency was in testing, so builders failed (although CI had passed fine)…
2026-05-04 05:18:28 <ikke> WhyNotHugo: reference to MR?
2026-05-04 05:18:29 <WhyNotHugo> I moved libmysofa into community to unbreak this (other MRs depend on this too). The maintainer for libmysofa had not replied in a few weeks, I hope it's okay to move the port without an explcit approval from the maintainer.
2026-05-04 05:18:54 <WhyNotHugo> !100395
2026-05-04 05:23:44 <ikke> WhyNotHugo: it never succeeded, all pipelines were skipped
2026-05-04 05:24:01 <ikke> or canceled
2026-05-04 05:24:07 <WhyNotHugo> Oh, my bad. It just never failed 🤦
2026-05-04 05:34:31 <ikke> WhyNotHugo: It's a good habbit to check at least one pipeline before you merge
2026-05-04 05:40:28 <WhyNotHugo> I checked, saw no failures, and interpreted that as success.
2026-05-04 05:40:48 <WhyNotHugo> (I'm now aware that my train of though was clearly faulty)
2026-05-04 05:42:58 <ikke> Yeah, but I mean it's a good idea to check the output of the pipeline
2026-05-04 05:43:11 <ikke> Things like soname bumps are there, but maybe other issues are reported as well
2026-05-04 05:43:19 <ikke> And specifically build jobs
2026-05-04 05:44:15 <WhyNotHugo> 👍
2026-05-04 06:21:28 <jvvv> ikke: ghc build hung for me before it got to the error that is in you log. I will work on it in the morning.
2026-05-04 06:21:58 <ikke> Mio suggested a patch 
2026-05-04 06:22:28 <jvvv> oh? how has it worked out, or is it still building?
2026-05-04 06:25:47 <ikke> I didn't have time yet to test it 
2026-05-04 06:26:17 <ikke> https://gitlab.haskell.org/ghc/ghc/-/commit/e8f5a45de561ec80c88cd3da2c66502deb32d4c3
2026-05-04 06:37:08 <jvvv> Ok, I will try that when I wake up.
2026-05-04 07:01:07 <lotheac> WhyNotHugo: libmysofa package maintainer doesn't seem active, maybe we should adopt it
2026-05-04 07:01:25 <lotheac> (and thanks for merging my MR, I pretty much forgot about it already...)
2026-05-04 07:02:03 <lotheac> clearly i should be a bit less patient in waiting for maintainers :D
2026-05-04 07:02:59 <WhyNotHugo> Builders for aarch64 are failing with: ERROR: Preparation failed: Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version (docker.go:958:0s)
2026-05-04 07:06:24 <ikke> Which runner?
2026-05-04 07:06:36 <WhyNotHugo> I meant CI runners
2026-05-04 07:06:52 <WhyNotHugo> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2333895
2026-05-04 07:07:39 <ikke> That's ncopa's runners
2026-05-04 07:07:50 <ikke> ncopa: ^ can you update gitlab-runner on them?
2026-05-04 07:12:26 <ncopa> i though i did. I did docker compose pull
2026-05-04 07:12:38 <ncopa> how do I upgrade gitlab-runner?
2026-05-04 08:18:20 <ncopa> i think it works now. thanks
2026-05-04 12:45:05 <EvTheFuture> What can I do to resolve the conflict in !101112
2026-05-04 13:17:30 <ikke> EvTheFuture: Rebase your branch on an updated master branch
2026-05-04 13:17:39 <ikke> Fetch from alpine/aports
2026-05-04 13:58:20 <EvTheFuture> @ikke Thanks, I see that it was updated in testing to an even newer version so I just closed the MR and will create a new one later on instead
2026-05-04 13:58:57 <EvTheFuture> Does this one seem ok to merge? !101176
2026-05-04 15:51:48 <ikke> It's back 
2026-05-04 15:56:00 <Sertonix[m]> \o/
2026-05-04 16:43:46 <craftyguy[m]> could a maintainer please take a look at !101325? thanks!
2026-05-05 09:27:03 <bdprom> glib 2.88.0 > 2.88.1 has several low severity security fixes but no assigned CVEs from what i can see (only some YesWeHack & CWE vanity IDs), should i still mark it as a security bump? looks like secfixes in APKBUILD is outdated too
2026-05-05 09:31:49 <omni> yes, I think it should still be "security upgrade to", secfixes can be added later
2026-05-05 09:32:43 <bdprom> cool cool
2026-05-05 09:33:33 <ncopa> agree, it makes it more visible that MR should be prioritized
2026-05-05 09:35:32 <omni> and backports to stable branches needed
2026-05-05 09:42:56 <bdprom> thanks both, and i havent really done any backporting yet, is there a threshold severity above which bumps need to be backported? i.e. is it necessary for low severity, non-CVE fixes?
2026-05-05 16:23:51 <Sertonix[m]> Generally fixes which doesn't break stuff is ok to backport
2026-05-05 17:37:58 <user0> hiii could aports!96377 be merged?
2026-05-05 17:41:30 <ptrc> tbqh even though there's no explicit policy about it, i have a feeling that nobody wants to be the person to merge some cryptocurrency stuff into alpine
2026-05-05 17:46:32 <user0> why not, we have xmrig
2026-05-05 17:51:01 <user0> and the last mr related to it was merged only ~1 month ago: aports!99705
2026-05-05 17:51:12 <user0> it's even in community repos
2026-05-05 17:57:00 <pj> then please wait for whoever is comfortable to merge it
2026-05-05 17:57:10 <user0> alright thanks
2026-05-05 19:23:22 <McLovin> Greetings everyone, I was just reading https://gitlab.alpinelinux.org/alpine/tsc/-/issues/78 and noticed that nosh https://github.com/jdebp/nosh seems to have not been considered as a possible alternative candidate. Does anyone know which candidates for replacement were considered so far? What are the necessary/sufficient criteria for a decision of adoption, integration and implementation? (Writing here cause 
2026-05-05 19:24:15 <ikke> McLovin: Your message was truncated at "Writing here cause"
2026-05-05 19:25:20 <McLovin> ikke: Oh, thanks. The message continues with: "... I dont want to create a gitlab account.) Thanks!"
2026-05-05 19:26:19 <ikke> McLovin: The issue is not an exhaustive list of what is considered
2026-05-05 19:27:35 <McLovin> ikke: That's what I thought. I just wanted to throw nosh in the ring in case it has not been considered.
2026-05-05 19:27:50 <ikke> McLovin: I see surprisingly little information in that repo
2026-05-05 19:28:15 <ikke> (I see the separate homepage link)
2026-05-05 19:28:54 <McLovin> ikke: Yeah, more info is provided on https://jdebp.uk/Softwares/nosh/
2026-05-05 19:34:51 <skarnet> yeah we can add nosh when we have the infrastructure for supporting several service managers :)
2026-05-05 19:36:03 <skarnet> nosh is pretty much its own thing, so it's true it hasn't received much attention, but once the framework is in place, it should be easier to plug in whatever service manager you like
2026-05-05 19:40:23 <McLovin> skarnet: Thanks for your info. That seems like a viable approach. You and the other folks involved, certainly know what is best for Alpine. Since I don't really know the criteria and priorities at hand I just thought that I should mention nosh. Maybe it ticks your boxes.
2026-05-05 19:44:19 <skarnet> nosh ticks a lot of boxes, too many of them :P and the one it doesn't tick well is usability for non-power-users, which is also a problem I have with s6 so I'm fixing s6 first :P
2026-05-05 19:46:45 <McLovin> skarnet: I see. nosh is more the kitchen sink approach, in the direction of (but far off) systemd, but still... nosh is certainly not a simple replacement.
2026-05-05 19:46:57 <skarnet> no it's not XD
2026-05-05 19:48:49 <McLovin> skarnet: A big box to tick certainly is: What is the team familiar and comfortable with? What is it able to support long term? And it "helps" to have a developer of tools like s6 in the team here. :)
2026-05-05 19:49:36 <McLovin> skarnet & ikke: In that sense: Thank you for your attention and good luck!
2026-05-05 19:49:46 <skarnet> I wouldn't say I'm in the team (though I would certainly like to find more time to help them) but I'm interested in making it easier for distributions to provide a choice of service managers
2026-05-05 21:19:15 <Sertonix[m]> McLovin: supported will probably be only a single service manager in the long term. As a power use (and due to alpine packages making little assumptions about service managers) you can configure and use an unsupported service manager with alpine today
2026-05-05 21:19:37 <Sertonix[m]> *user
2026-05-05 21:21:32 <Sertonix[m]> Oh, I planned to but never finished to write a log manager called cyclog. Looks like I would need to come up with a different name
2026-05-05 22:32:34 <r0eme> heh...just so happens that I recently thought about writing my own init (compatible with systemd units). funny that related chatter happens when drop by on this channel...
2026-05-05 22:37:22 <r0eme> Sertonix[m]: instead of a unified service format...perhaps for each package that is a service, a separate package containing the s6/nosh/whatever-init scripts could be provided. methinks debian did something similar
2026-05-05 22:39:20 <r0eme> though at least in the beginning I'd see this more of a community-effort than to ask core devs to support multiple inits out of the box
2026-05-05 22:39:43 <r0eme> (apologies if I touch points that have been discussed before)
2026-05-05 22:40:18 <Sertonix[m]> If you do that the heat of the discussons would probably be enough to power a whole city...
2026-05-05 22:42:35 <Sertonix[m]> But jokes aside it is not feasable to ensure correct operation. A community effort which which manages their own repository would be possible.
2026-05-05 22:45:13 <skarnet> a community repository of service files for every supported service manager is considerably more effort than a unified format
2026-05-05 22:48:18 <Sertonix[m]> It very much depends ob the selection of service managers and unified "features"
2026-05-05 22:49:40 <skarnet> for openrc, s6, and stuff like dinit and maybe nosh, it will be rather reasonable
2026-05-05 22:50:20 <Habbie> that community plan didn't work out for debian (packages are allowed to ship sysvinit files next to their systemd units)
2026-05-05 22:50:44 <skarnet> well of course
2026-05-05 22:50:45 <Habbie> (but i believe most didn't)
2026-05-05 22:51:23 <skarnet> systemd wants hegemony - this is not conspiratorial, it is its nature and purpose
2026-05-05 22:51:45 <skarnet> it's really difficult to map a unit file to other service managers because the view of the system is quite different
2026-05-05 22:51:51 <Habbie> yes
2026-05-05 22:52:22 <skarnet> you need a holistic view of the system to describe it in both systemd terms and e.g. openrc terms. And that's super hard to automate
2026-05-05 22:52:23 <Habbie> incidentally i learned this week that devuan made room for less insane choices than sysvinit
2026-05-05 22:52:35 <Habbie> but, also as a 'secondary' platform
2026-05-05 22:54:05 <Sertonix[m]> skarnet: A community effort can be more on-deman. Only a supported service manager needs complete coverage of all services.
2026-05-05 22:55:28 <skarnet> but then you can't integrate it with a package manager and make it easy for the distro or the user
2026-05-06 01:10:06 <lnl> How do we define our riscv64 baseline?
2026-05-06 05:54:46 <jvvv> ikke: After tweaking my qemu vm setup for aarch64, it has taken approx a day and a half for the ghc build to fail for a different reason than the log you provided. https://tpaste.us/Vpyd
2026-05-06 05:58:51 <jvvv> I've ordered a Radxa Dragon Q6A for home lab... I should get it in a week or two. I could try again then, but I suspect that will be too late. Besides, I'll probably need some additional time getting the rig setup to, so I think I will not be able to help with that as I had hoped.
2026-05-06 05:59:31 <ikke> jvvv: no worries, thanks for trying
2026-05-06 05:59:50 <ikke> I have been busy with other urgent things, so haven't been able to test the suggested fix from mio yet
2026-05-06 06:00:18 <jvvv> The patch you linked from mio does seem to do the right thing... the documentation got built successfully.
2026-05-06 06:00:34 <ikke> ok, thanks for confirming that
2026-05-06 06:00:59 <ikke> No idea if it will still fail for similar (or different) reasons as for you
2026-05-06 06:02:19 <jvvv> Hard to say, specifically since I was running qemu in full emulation mode. That aarch64 sbc I have coming should give me some better capabilities for build arm arches.
2026-05-06 06:03:56 <jvvv> I would have liked to get a really beefy aarch64 board, but the price jumps pretty dramatically.
2026-05-06 06:07:52 <jvvv> It was a toss up between the qcs6490 and rk3588. The qcs6490 has better mainline kernel support starting with linux 7.0.
2026-05-06 06:16:19 <jvvv> ikke: I didn't think it would be a good idea to try to paste the whole log, but I placed a copy on my vps: https://stygian.me/ghc_aarch64_build.log
2026-05-06 07:16:12 <maribu> The builders are looking relatively idle now. Maybe someone could give !101725 a look? It is going to take a bit of time to build, but not completely terrible. (E.g. the x86_64 CI took a bit more than 4 hours.)
2026-05-06 08:37:23 <r0eme> skarnet: Sertonix[m]: Habbie: Hmmm, I see. Main point of contention will be if upstream says "we rely on systemd" - even if there's somebody willing to provide alternative init "scripts", won't help much.
2026-05-06 08:38:29 <r0eme> heh, in an ideal world there would be $package, and $package-s6, $package-nosh, $package-systemd, $package-... - provided by whomever :)
2026-05-06 08:45:14 <skarnet> in an ideal world you wouldn't even have to provide them, they could be automatically generated by a common service description :)
2026-05-06 08:45:28 <skarnet> s/by/from/
2026-05-06 08:50:42 <r0eme> :)
2026-05-06 08:51:00 <r0eme> though to that ideal world...it would be a first stepping stone
2026-05-06 08:51:24 <r0eme> 
ACTION notices that we already have a lot of $package-openrc packages!

2026-05-06 08:53:22 <ikke> Yes, abuild complains if you install init.d files that are not in een -openrc subpackage 
2026-05-06 08:57:14 <ncopa> maribu: merged. thanks for the heads up on keeping builders busy
2026-05-06 08:59:13 <r0eme> ikke: this is great, and whoever thought of this deserves all the praise.
2026-05-06 14:02:15 <Sertonix[m]> I would like to slightly change the way that licenses not specified by SPDX are expressed in APKBUILDs. LicenseRef-* is a way to do that intended to be used in SPDX license expressions: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10188
2026-05-06 14:03:04 <Sertonix[m]> Please mention any concerns on the issue
2026-05-06 14:55:12 <Saijin_Naib[m]> Can anyone review !97593
2026-05-06 14:55:12 <Saijin_Naib[m]> It looks like VTK fixes and other rebuilds have settled, so it seems a good time to get eyes on
2026-05-06 17:49:12 <mramberg> Would love it if niri got bumped (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/101877) - I've built the apk and deployed it to my phone fwiw.
2026-05-06 20:03:01 <Saijin_Naib[m]> omni hate to ping here, but for Pitivi, !97292, is there a sense of what the right move is with regards to the pyc subpackage failing unless I use the script that makes the linter mad?
2026-05-06 20:03:24 <Saijin_Naib[m]> I would like to take over Pitivi, fix it up, and add some features, but the pyc subpackage appears to be a blocker
2026-05-06 20:20:11 <quinq> So, pipewire just blocks software
2026-05-06 20:20:50 <quinq> Trying to play a video, it stays stuck; switching to other audio output, it plays, switching back to pipewire, it blocks again
2026-05-06 20:20:58 <quinq> Modern software™
2026-05-06 20:26:57 <quinq> $ wiremix
2026-05-06 20:26:57 <quinq> Error: Start error: Resource busy
2026-05-06 20:26:59 <quinq> wut
2026-05-07 10:22:16 <omni> Saijin_Naib[m]: no worries
2026-05-07 15:34:09 <strangeperson> trying to upgrade Tuwunel (!101754) fails again, this time for aarch64: `linking with `cc` failed`, I guess it's an OOM error again
2026-05-07 15:42:04 <Biswa96[m]> achill fossdd xmlsec reverse dependencies may need to be rebuilt. I can not install libreoffice.
2026-05-07 15:42:17 <Biswa96[m]> see dependencies here https://pkgs.alpinelinux.org/package/edge/community/aarch64/libreoffice-common
2026-05-08 10:16:31 <fabricionaweb> Im going drop maintainership for pnpm, if someone wants take it over. This package updates several times a week lol
2026-05-08 10:54:06 <dne> move fast and…
2026-05-08 11:03:33 <skarnet> annoy maintainers