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
2026-05-08 17:53:11 <witcher01> fabricionaweb: you remind me that i should think about dropping maintainership for a package like that
2026-05-08 17:54:03 <witcher01> it doesn't happen constantly but wow it's some mental load when the maintainer has a productive week and pushes several new versions during that while i don't have time to bump
2026-05-08 19:20:40 <Ariadne> since upgrading to sddm 0.21.0-r10 it doesnt work at all
2026-05-08 19:22:30 <Ariadne> hmm sddm itself might not be to blame
2026-05-09 09:06:15 <ncopa> Ariadne: I’d like to have a release of ifupdown-ng before alpine 3.24. I have a PR to fix/improve tests
2026-05-09 09:21:11 <Ariadne> sure
2026-05-09 09:36:19 <ncopa> Will try implement match-macaddress stanza but need that the tests passed first
2026-05-09 10:45:33 <freetolga> vscode is gonna jump from electron 39 straight to 42
2026-05-09 10:45:34 <freetolga> https://github.com/microsoft/vscode/commit/892ee5dfdb5441ff433e59650524a81fc5478954
2026-05-09 12:25:10 <ptrc> is gitlab cooked for everyone or just me
2026-05-09 12:25:36 <ptrc> any requests touching a git repository take at least a few seconds
2026-05-09 12:29:10 <f_> has always been the case for me I think?
2026-05-09 12:29:38 <f_> Mainly touching aports though
2026-05-09 12:37:13 <ptrc> idk, usually something like curl on a merge request .patch would be less than a second
2026-05-09 12:38:40 <hannesbraun> the web ui is also much slower than usual for me
2026-05-09 12:45:41 <ikke> Chekcing
2026-05-09 12:46:32 <ptrc> thanks <3
2026-05-09 12:47:42 <ikke> many git processes
2026-05-09 12:47:51 <ikke> (usually means something is cloning a lot of repos)
2026-05-09 12:48:08 <ptrc> CI jobs, or someone spamming the instance?
2026-05-09 12:48:58 <ikke> The latter
2026-05-09 12:49:01 <ikke> usually
2026-05-09 12:49:05 <ikke> checking
2026-05-09 12:55:20 <ikke> I don't see scaping behavior atm
2026-05-09 12:55:40 <ikke> Just a lot of git processes
2026-05-09 12:57:19 <freetolga> the electron update is gonna be a pain
2026-05-09 12:57:25 <freetolga> they moved the chromium source into a seperate folder
2026-05-09 12:57:35 <freetolga> third_party/electron_node doesnt exist
2026-05-09 12:58:00 <freetolga> maybe the package maintainer fixed these issues in his source tarballs but im not aware?
2026-05-09 12:58:37 <ikke> possibly. ayakael ^?
2026-05-09 12:58:43 <freetolga> im trying to make it work without downloading stuff at runtime aswell
2026-05-09 12:59:51 <ikke> That would be nice
2026-05-09 13:03:10 <freetolga> ikke: this is my second ever alpine package and the first one this complex so i hope it doesnt fail in CI a bunch of times lol
2026-05-09 13:03:52 <freetolga> i cant push it to somewhere because the server is lagging and i cant unshallow fetch
2026-05-09 13:04:13 <ayakael> freetolga: update to which version?
2026-05-09 13:04:19 <freetolga> straight to 42
2026-05-09 13:04:28 <freetolga> because its the next one vscode will use
2026-05-09 13:04:45 <ayakael> Got you. I was planning to work on that after v3.24
2026-05-09 13:05:16 <freetolga> https://bpa.st/2ICQ
2026-05-09 13:05:22 <freetolga> i just use alpine edtge
2026-05-09 13:05:24 <freetolga> edge*
2026-05-09 13:05:26 <freetolga> gtg 
2026-05-09 13:05:35 <ikke> electron is only in edge
2026-05-09 13:06:21 <ayakael> I see, not using depot_tools
2026-05-09 13:06:36 <ayakael> This might be why the tarball topography has changed.
2026-05-09 13:15:33 <Biswa96[m]> there is an issue reported with clang 22.1.4 that it can not compile Linux kernel. Link https://github.com/llvm/llvm-project/issues/195657. please check if it happens in alpine also before updating llvm.
2026-05-09 13:19:34 <ikke> We do not use clang to build the kernel
2026-05-09 13:20:33 <sam_> (also, per the bug, it looks like it's possibly a gcc bug (or some UB in llvm which shows up w/ new gcc), so not upgrading clang wouldn't really help other than avoiding a rebuild, and I don't know if alpine has packaged gcc 16 yet anyway)
2026-05-09 13:21:13 <ikke> No, we're still on gcc 15
2026-05-09 13:21:22 <sam_> ah, great, you're fine either way then
2026-05-09 13:27:36 <ayakael> freetolga: I've triggered tarball generation for v42.0.1: https://ayakael.net/mirrors/electron/actions/runs/13937/jobs/0/attempt/1
2026-05-09 13:28:04 <ayakael> ikke: Yes, but no one is going to merge electron upgrades before v3.24 release for sure.
2026-05-09 13:31:06 <ikke> ayakael: I responded to freetolga mentioning that they only use edge
2026-05-09 13:45:04 <freetolga> ayakael: thanks but i usually cant connect to your server :(
2026-05-09 13:45:21 <freetolga> all turks have the same public ip
2026-05-09 13:45:37 <freetolga> its isp dependant not individual or even apartment dependant
2026-05-09 13:53:50 <ayakael> Can you try now? I allowed Turkey in my IP block
2026-05-09 13:54:38 <ayakael> That said, it looks like indeed something has changed. Tarball generation is broken.
2026-05-09 13:55:07 <freetolga> it works now
2026-05-09 13:55:44 <ayakael> Cool, anyways, I'm going hiking so won't be able to debug this today. In any case, if you find a way to build electron without depot_tools, that would be awesome.
2026-05-09 13:56:24 <ayakael> I triggered the pipeline again in case it was a networking issue
2026-05-09 13:58:20 <freetolga> i think its most ideal if we build it completely offline somehow
2026-05-09 13:59:21 <freetolga> i could also generate some tarballs locally with a reproducible script and put them on a NAS for now
2026-05-09 13:59:46 <freetolga> ayakael: it failed agian
2026-05-09 13:59:56 <freetolga> good hikes btw
2026-05-09 14:04:23 <ayakael> My workflow is essentially the snapshot() function on the APKBUILD
2026-05-09 14:05:02 <ayakael> Instead of having to trigger it for every update and upload to a server, my workflow does it for me automatically.
2026-05-09 14:05:58 <ayakael> The other approach is to download the source tarball for electron + chromium ourselves and try to reproduce what depot_tools does, but it's usually a real pain in the ass.
2026-05-09 14:06:19 <freetolga> ayakael: for some reason i dont see this in the gentoo ebuild
2026-05-09 14:06:24 <freetolga> not gentoo
2026-05-09 14:06:27 <freetolga> but unofficial ebuild
2026-05-09 14:06:32 <freetolga> https://github.com/PF4Public/gentoo-overlay/blob/master/dev-util/electron/electron-42.0.1.ebuild
2026-05-09 14:06:51 <freetolga> i think they just download the whole nodejs to use its modules?
2026-05-09 14:08:58 <ayakael> Looks like they reverse engineered it, I've yet to study their approach. I just hope to not end up with a 2.1K APKBUILD like they did, because that looks scary for future maintenance.
2026-05-09 14:24:18 <freetolga> ayakael: also i would like to seperate phases of prepare more 
2026-05-09 14:24:24 <freetolga> i want to rerun parts individually
2026-05-09 14:25:21 <freetolga> i think the source filling should be in unpack not prepare
2026-05-09 14:27:51 <freetolga> im gonna try to fix depot_tools ig
2026-05-09 14:32:11 <freetolga> ModuleNotFoundError: No module named 'httplib2.socks'
2026-05-09 14:32:17 <freetolga> i get this with latest depot_tools
2026-05-09 18:12:27 <skarnet> Whenever someone has the time, please take a look at, and merge, !102148. Thanks :)
2026-05-09 19:04:50 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17913#note_609451
2026-05-09 19:05:09 <ptrc> i have a feeling this is another case of LLM agent going around and posting bullshit 
2026-05-09 19:06:11 <ptrc> there’s no way someone can write coherent C code and then be completely unaware of any context at the same time 
2026-05-09 19:06:37 <ptrc> relatively coherent, that is; i haven’t revieved the actual patch, but the message structure feels very LLM
2026-05-09 19:32:30 <ncopa> Hard to tell there days
2026-05-09 19:36:47 <f_> ptrc: the first message was definitely AI
2026-05-09 19:37:07 <ikke> ptrc: the message contains a patch
2026-05-09 19:37:26 <f_> the second message seems handwritten at least partially
2026-05-09 19:52:36 <ptrc> ikke: yeah i’ve glanced at the patch, it’s definitely weird that it’s just tossed as an attachment rather than inline or merge request 
2026-05-09 19:53:09 <ikke> ack
2026-05-09 19:57:18 <ptrc> the patch is also not generated by git, rather by something like diff(1), but the paths match git behaviour ( a/ and b/ )
2026-05-09 20:00:41 <sam_> to be fair, I do that all the time and always normalise to -p1
2026-05-09 20:00:47 <sam_> but i agree it looks smelly
2026-05-09 20:08:39 <pj> it's definitely all "AI" for both messages, but maybe some local model or some heavy tuning
2026-05-09 20:14:39 <freetolga> idk i dont use ai for even boring stuff like bumping electron
2026-05-09 20:18:58 <freetolga> wow
2026-05-09 20:19:06 <freetolga> after a day of my weekend trying to fix paths i get this
2026-05-09 20:19:07 <freetolga> ERROR at //third_party/electron_node/node.gni:23:25: Disallowed exec_script call.
2026-05-09 20:21:02 <jvoisin> s-e-c-u-r-i-t-y
2026-05-09 20:22:13 <freetolga> the obvious way is to make a patch that hardcodes it right
2026-05-10 12:19:39 <freetolga> ayakael: i fixed all the paths
2026-05-10 12:20:36 <freetolga> i thought it was electron/chromium_src having chromium source
2026-05-10 12:20:40 <freetolga> but its the opposite
2026-05-10 12:20:45 <freetolga> its chromium_src/electron
2026-05-10 12:21:02 <freetolga> now im just dealing with stupid gn errors
2026-05-10 12:21:15 <freetolga> i think i will fix it by looking at your old apkbuild and doing the git init -q . and yarn stuff to 
2026-05-10 12:21:25 <freetolga> or we can patch out the git stuff?
2026-05-10 14:10:25 <skarnet> Ariadne: thanks for the merge!
2026-05-10 23:41:22 <ptrc> sigh
2026-05-10 23:41:25 <ptrc> https://gitlab.alpinelinux.org/srvnt-user123
2026-05-10 23:41:26 <ptrc> https://gitlab.alpinelinux.org/user-srvnt123
2026-05-10 23:41:30 <ptrc> why is there two of them now
2026-05-10 23:42:01 <skarnet> bots reproduce by duplication
2026-05-11 01:08:41 <Saijin_Naib[m]> Who do reports go to, and is being an "agent" an acceptable reason to report this shit? 
2026-05-11 01:45:56 <lotheac> ptrc: i don't think typos are a very reliable signal for human anymore tbh
2026-05-11 03:36:02 <samcday> Hello. I'm trying to package github.com/samcday/fastboop in a way that is acceptable to aports. This project has a very weird requirement that it needs a "stage0" sidecar binary, which is fully statically linked. That binary gets rolled into an Android boot.img which handles the device-side voodoo to bring up a liveboot environment for arbitrary distro rootfs on pocket 'puters.
2026-05-11 03:36:07 <samcday> So, that stage0 binary should only be built for aarch64 (since virtually all Android pocket 'puters are arm64), and should distribute a "/usr/lib/fastboop/stage0/stage0-aarch64" binary on _all_ host architectures. AFAICT, there's zero precedent for this in Alpine. Admittedly there's little precedent _anywhere_ 😅 The closest analogous thing I can find is Fedora's...
2026-05-11 03:36:12 <samcday> ... https://src.fedoraproject.org/rpms/fex-emu-rootfs-fedora/blob/rawhide/f/fex-emu-rootfs-fedora.spec, which ships an aarch64 rootfs artifact as a "noarch" package.
2026-05-11 03:36:14 <samcday> Any ideas? The upstream project already produces the static binaries as a release artifact, so I'm happy to entirely punt on trying to build stage0 in the APKBUILD, and instead just pull the prebuilt binary and wiggle it into place. Just not sure if that's kosher. And, it kinda seems fun to try and do it the masochist way xD
2026-05-11 05:02:02 <pj> ptrc: lol @ the LLM comment
2026-05-11 08:49:35 <Sertonix[m]> samcday: Prebuild binaries should be avoided but compiling anything for android requires a toolchain that is not packaged. So prebuild is the only option at the moment. A noarch subpackage is the best option, just like for qemu formware.
2026-05-11 08:56:10 <samcday> Sertonix[m]: to clarify: there's nothing Android-y here. This is all mainline Linux stuff.
2026-05-11 08:57:20 <samcday> So the static musl binary in question is built with "target-feature=+crt-static --target aarch64-unknown-linux-musl"
2026-05-11 09:08:23 <Sertonix[m]> Would need a cross build of musl which we I don't think we package at the moment
2026-05-11 10:17:19 <vmignot> Hi ! Latest skalibs 2.15 update didn't get propagated to the longaarch64 testing repo. Should I just do a release bump in this case ?
2026-05-11 10:19:56 <quinq> Why was it not?
2026-05-11 10:20:51 <vmignot> honestly, idk
2026-05-11 10:21:58 <ikke> https://build.alpinelinux.org/
2026-05-11 10:22:02 <ikke> It's still building
2026-05-11 10:22:09 <ikke> so pkgrel bump is not going to help (or required)
2026-05-11 10:22:46 <ikke> In fact, it was hanging
2026-05-11 10:24:35 <vmignot> thanks !
2026-05-11 10:25:04 <quinq> :)
2026-05-11 21:01:39 <ayakael> freetolga: can you make an MR on the gitlab so we can maybe work on it together?
2026-05-11 21:58:54 <omni> where do we draw the line for toolchain freeze? !101574
2026-05-11 22:07:11 <Sertonix[m]> Regardless of toolchain freeze there is a high chance of bugs showing up after that upgrade. I would recommend to merge it once the stable branch has been split.
2026-05-11 22:14:00 <omni> Sertonix[m]: thanks, I'll tag it hold
2026-05-11 23:31:14 <Asmadeus> silly question about licenses, some packages have "Public Domain" and others have "Public-Domain" -- public domain isn't a recognized SPDX identifier so it probably doesn't really matter either way but should we try to make them match? (main has 16 Public-Domain and 10 Public Domain, community has 22 and 3, so the dash variant is more common if we're going through that churn. It came up at work 
2026-05-11 23:31:20 <Asmadeus> through someone working on SBOM for one package, so I'll be happy to open MRs if there's an agreement)
2026-05-11 23:45:24 <Asmadeus> dnsmasq vulnerabilities... https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2026q2/018471.html "The CVE has been pre-disclosed to vendors" - is anyone working on it? If not (or no reply within the next hour or so) I'll bump master version and pick up patches to stable branches
2026-05-12 01:08:00 <Asmadeus> (dnsmasq done)
2026-05-12 05:19:18 <Sertonix[m]> Asmadeus: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10188
2026-05-12 05:31:19 <Asmadeus> Sertonix[m]: oh, thanks! Yeah you're right LicenseRef-$pkgname-public-domain would be even better, as it's not obvious that public domain has the same meaning for each package
2026-05-12 05:33:22 <Asmadeus> If it was just s/Public Domain/Public-Domain/ I wanted to squeeze it before the release branching, but I guess it's worth taking the time to make abuild understand LicenseRef and Do It Right..
2026-05-12 05:34:44 <Asmadeus> The problem with LicenseRef is that the SPDX is supposed to contain the license text though, so we need to properly include some sort of text, and tools building sbom would need to somehow be able to extract it from the -doc subpackage or something?
2026-05-12 05:35:25 <Asmadeus> (that's a bit heavy for IRC though so happy to bring that up on the issue and continue there if you prefer)
2026-05-12 05:49:26 <Sertonix[m]> For now I would ignore the requirment to correctly declare the text and consider it optional to include the text. I think the effort would be too high when packaging otherwise.
2026-05-12 05:54:33 <Asmadeus> Yeah, and it's not like that requirement isn't already present with the ambiguous license keywords that automatically get translated to LicenseRef, so I think your proposal makes sense to start with
2026-05-12 09:15:36 <fabricionaweb> Hi, good morning. I need some eyes/review on these two PRs !102095 and !102095
2026-05-12 09:16:00 <fabricionaweb> I meant !102133
2026-05-12 17:17:17 <Saijin_Naib[m]> I feel really dumb, but I am having trouble rebasing !102091 via the webUI (about 11,000 commits behind), and locally I am struggling as well as git complains that there are unresolved merge conflicts when I try to rebase or stash/pop
2026-05-12 17:17:42 <Saijin_Naib[m]> is there a name for what this situation is so I can read up further?
2026-05-12 17:17:56 <Saijin_Naib[m]> Or just nuke the branch and the PR, make a fresh/clean branch, then re-submit?
2026-05-12 17:20:48 <ikke> If there is a conflict, you need to resolve that conflict 
2026-05-12 17:21:26 <ikke> git status shows you what files are conflicted 
2026-05-12 17:21:47 <jvvv> 11,000 commits behind... branch is pretty old me thinks.
2026-05-12 17:24:49 <ikke> Yes, but that should not matter too much 
2026-05-12 17:25:08 <ikke> As long as the change you want to make still makes sense
2026-05-12 17:25:53 <jvvv> When that far behind, I think added aports and removed ones will be trouble spots
2026-05-12 17:26:09 <ikke> No
2026-05-12 17:26:19 <jvvv> Oh, ok
2026-05-12 17:26:45 <ikke> It only looks at the changes you made (3-way merge)
2026-05-12 17:27:59 <jvvv> Oh, yeah, so chances are, the changes that are made in the MR commits effect files that have changed since the branch was created... I see it now
2026-05-12 17:28:42 <ikke> Yes
2026-05-12 17:28:56 <ikke> For example, a pkgrel bump
2026-05-12 17:29:04 <Saijin_Naib[m]> Ah, okay
2026-05-12 17:29:32 <Saijin_Naib[m]> Yeah, I bumped it, but it is also a switch from autotools to meson, so the apkbuild is quite different than prior
2026-05-12 17:30:35 <jvvv> I would still work locally and save the commits with format-patch, reset --hard that number of commits on the MR branch, pull from master, the reapply... maybe that is lazy approach, maybe not
2026-05-12 17:30:39 <ikke> When running into a conflict, you could do: git checkout --ours APKBUILD
2026-05-12 17:30:55 <ikke> jvvv: that's basically what rebase does
2026-05-12 17:31:13 <jvvv> Good point
2026-05-12 17:31:42 <Saijin_Naib[m]> 
ACTION uploaded an image: (45KiB) < https://matrix.org/oftc/media/v1/media/download/AYHM-lo55teuxtMwPi5Ncf1FvwYZ5KTNi-yeInS5x8sxPX3u-EX4Hlp4k7hHRYxisNNpkas1qP_pIDA6V5aZwIFCeeZVeimAAG1hdHJpeC5vcmcvTXd6amFmaGpzWk90U2N4Q3ZQd2NYaGpF >

2026-05-12 17:31:47 <ikke> After the checkout, you can then make those changes again
2026-05-12 17:31:50 <Saijin_Naib[m]> Gitlab is giving me this workflow, which does not resolve the issue
2026-05-12 17:32:17 <ikke> You should not use git merge
2026-05-12 17:32:21 <ikke> You need to rebase your changes
2026-05-12 17:33:17 <ikke> git remote add upstream https://gitlab.alpinelinux.org/alpine/aports.git 
2026-05-12 17:33:20 <jvvv> Matrix links are like an endless noodle I just want to cut into tiny little peices
2026-05-12 17:33:31 <ikke> git fetch upstream
2026-05-12 17:33:41 <ikke> git rebase upstream/master
2026-05-12 17:34:41 <jvvv> This is the WAY
2026-05-12 17:38:39 <Saijin_Naib[m]> i have the alpine gitlab as upstream
2026-05-12 17:38:45 <Saijin_Naib[m]> git fetch never completes, it just endlessly hangs
2026-05-12 17:40:37 <ikke> It can take some time
2026-05-12 17:40:52 <Saijin_Naib[m]> Connection timed out
2026-05-12 17:41:04 <Saijin_Naib[m]> it worked instantly using origin/master instead of upstream
2026-05-12 17:41:16 <ikke> Sure, but that does not have the same effect
2026-05-12 17:41:17 <Saijin_Naib[m]> git rebase --skip, git pull --rebase going through now
2026-05-12 17:41:37 <Saijin_Naib[m]> No? My master branch is synced with upstream
2026-05-12 17:41:48 <Saijin_Naib[m]> Should that not pull in all the needed interim commits?
2026-05-12 17:41:53 <Saijin_Naib[m]> (not challenging, just bad at this)
2026-05-12 17:45:46 <Saijin_Naib[m]> rebasing 2,500 of 11,101
2026-05-12 18:12:39 <Saijin_Naib[m]> indeed not. 11,102 commits behind, 11,101 commits ahead
2026-05-12 18:17:13 <jvvv> Had you added any merge commits to that branch before you rebased?
2026-05-12 18:17:16 <Saijin_Naib[m]> Yeah, I am not good enough to figure this. Nuked and remade clean with !102276
2026-05-12 18:17:47 <Saijin_Naib[m]> jvvv I am not entirely sure... I think it should have been untouched minus my upgrade to xfce4-screensaver
2026-05-12 18:18:03 <Saijin_Naib[m]> I tried months ago and abandoned it, hence the age of the branch and how out of sync it was
2026-05-12 18:18:28 <jvvv> Ah, yeah, I see how that could cause it be that far behind
2026-05-12 18:19:59 <jvvv> In the future, if you name the branch the same as the one in the MR, if you recreate it, you can just force push since it is a personal branch... force pushing to public would be bad, but in case like this it is common.
2026-05-12 18:21:35 <Saijin_Naib[m]> Ooooh, okay. So delete locally (not in Gitlab WebUI), redo the branch/commit, then push?
2026-05-12 18:21:40 <Saijin_Naib[m]> Smart, awesome. Thanks!
2026-05-12 18:22:04 <Saijin_Naib[m]> And then I can hide that I got myself in this mess from people 🤣
2026-05-12 18:22:23 <jvvv> Yeah, but that is why you would have to add '-f' to the push, to overwrite you current gitlab copy of the branch
2026-05-12 18:23:55 <Saijin_Naib[m]> Yeah, makes sense. Thanks for helping me out with this, and ikke
2026-05-12 18:24:10 <jvvv> Sure, hide, but really you want clean branch for the merge... git can be hard... ikke is obviously better with it than I am, but over time you learn things you can get away with and other time people like ikke teach me better work flows when they correct me / advise me
2026-05-12 18:24:40 <ikke> It's perfectly fine to use push --force in this case
2026-05-12 18:25:21 <jvvv> I guess that was what I was trying to convey, but my words are not always succinct
2026-05-13 01:16:56 <jvvv> Did the mkinitfs repo get a hard reset? The release has ver 3.13.0 in the Makefile, but in the master branch it is 3.12.0. Also the commit for the 3.13.0 release does not point to a branch. Make me think the was a `git reset --hard` done since the release or maybe it could data lose for the repo?
2026-05-13 01:20:28 <Asmadeus> There's a 3.13.0 tag that's one commit above master, so it looks like ncopa just forgot to push it, rather than a hard reset
2026-05-13 01:20:49 <Asmadeus> you can get it with `git fetch --tags` and then `git checkout 3.13.0`
2026-05-13 01:22:04 <Asmadeus> (there's no difference except the version in the Makefile)
2026-05-13 01:23:11 <jvvv> Yes, I noticed, thanks. I was mostly concerned if it _was_not_ a reset because that might point to data loss.
2026-05-13 01:23:50 <jvvv> But missing the push could happen and seems more plausible.
2026-05-13 06:00:04 <ncopa> oh
2026-05-13 06:00:26 <ncopa> seems like I pushed the tag, but not yet the commit
2026-05-13 06:00:45 <ncopa> i pushed it now
2026-05-13 06:00:56 <ikke> protip: git push --follow-tags 
2026-05-13 06:01:11 <ikke> pushes the branch and all reachable tags at the same time
2026-05-13 06:02:15 <ncopa> i have had old, broken tags in my local checkout in the past. im afraid of pushing all tags
2026-05-13 06:02:21 <ikke> right
2026-05-13 06:02:26 <ikke> you'd have to clean that up first
2026-05-13 06:03:27 <ncopa> which is problematic with an interrupt driven workflow
2026-05-13 07:14:12 <dne> could someone merge !101762?
2026-05-13 08:00:47 <ncopa> merged
2026-05-13 08:01:04 <dne> thank you
2026-05-13 13:58:13 <andypost[m]> looks like build-3-24-x86_64 builder is hanging on php83-imagick build for a second day, anyone can kick it?
2026-05-13 14:12:02 <ikke> yes we can
2026-05-13 14:13:41 <andypost[m]> thank you
2026-05-13 15:01:48 <andar1an> gitlab being weird for anyone else?
2026-05-13 15:02:03 <ikke> andar1an: load is a bit high atm
2026-05-13 15:02:23 <andar1an> okie, thanks Ikke
2026-05-13 15:04:16 <ikke> Was a brief spike, seems to be better now
2026-05-13 15:04:48 <andar1an> it let me catch an error that needs fixing haha
2026-05-13 17:14:50 <fabricionaweb> what you do when you kinda want do a packabe but it is using the called monorepo?
2026-05-13 17:17:31 <ikke> fabricionaweb: adjust builddir to point to the specific directory of thing you want to package?
2026-05-13 17:17:43 <Habbie> i was looking at !102322 and said "i don't think you need a pkgrel bump"
2026-05-13 17:17:48 <Habbie> but then i see fossdd asked for a bump
2026-05-13 17:17:54 <Habbie> it doesn't seem worthy of a full rebuild
2026-05-13 17:17:59 <fabricionaweb> yes, that can work but I mean still get the full monorepo a tarball right
2026-05-13 17:18:03 <Habbie> (it's just a typo change in pkgdesc)
2026-05-13 17:18:25 <ikke> fabricionaweb: Yes, not sure if there is an alternative, unless they provide source archives for individual parts
2026-05-13 17:18:59 <fabricionaweb> I will try that, at least is build time, the runtime is cleared
2026-05-13 17:42:53 <achill> Habbie: always when a MR change changes the apkindex or the .apk file, a rebuild is required
2026-05-13 17:45:21 <ikke> Without the bump, the package is plainly not rebuilt, deferring updating the changed data to the next build
2026-05-13 17:54:13 <Habbie> ikke, yes - naively i'd think that might make sense for a pkgdesc typo :)
2026-05-13 17:55:10 <ikke> If another update is imminent and no one is bothered enough by the typo in pkgs.a.o, then it may make sense
2026-05-13 18:02:58 <fabricionaweb> hmmm the abuild is unpacking my tarball straight to "srcdir" lol have some of you experienced this before?
2026-05-13 18:04:05 <ikke> fabricionaweb: it means the files are not put into a directory in the tarbal
2026-05-13 18:04:34 <fabricionaweb> it seems, I thought something were smart enough to sort this
2026-05-13 18:10:25 <omni> it should have been a single commit, though
2026-05-13 19:01:44 <ikke> load average: 710.48
2026-05-13 20:29:16 <ayakael> omni: Heads up that I got !102049 ready for you
2026-05-13 21:33:37 <fabricionaweb> what when the binary (well also the package name) conflicts with an existing one
2026-05-13 21:46:22 <ptrc> fabricionaweb: we usually try to do renames whenever sensible
2026-05-13 21:46:37 <ptrc> see e.g. dragon-drop
2026-05-13 21:50:36 <fabricionaweb> yeah, I think I can rename
2026-05-13 21:50:38 <fabricionaweb> thanks
2026-05-14 07:26:12 <Asmadeus> ncopa: Would you mind having another look at !102254 ? (and !102255 and the next one for stable branches) The dnsmasq vulns are starting to make the news so would appreciate it
2026-05-14 09:17:14 <ncopa> Asmadeus: sorry for the nitpicking, and thanks for following it up. Lets get this merged today
2026-05-14 09:20:16 <Asmadeus> No worry, thanks for helping with the rel2/_p2 version, it's much better
2026-05-14 09:23:27 <Asmadeus> > wget: can't connect to remote host (85.119.82.65): Operation timed out / >>> ERROR: dnsmasq: fetch failed
2026-05-14 09:23:30 <Asmadeus> great..
2026-05-14 09:25:58 <Asmadeus> I've triggered a rerun for the arches that failed to fetch but I need to afk a few hours, if it fails again I'd suggest ignoring the errors if you can (or follow-up if you have time). Sorry for the round-trips
2026-05-14 13:53:51 <ayakael> I'm having issues with CI on v3.22 and v3.21. Notably, v3.22 is missing `getopt` cmd and v3.21 is missing `grep`
2026-05-14 13:54:31 <ayakael> v3.22: https://gitlab.alpinelinux.org/ayakael/aports/-/jobs/2347045
2026-05-14 13:54:41 <ayakael> v3.21: https://gitlab.alpinelinux.org/ayakael/aports/-/jobs/2347455
2026-05-14 14:07:34 <Sertonix[m]> Some bug is causing the busybox trigger to sometimes not run. Have you tried restarting the CI?
2026-05-14 14:15:39 <ayakael> Yes, 2-3 times
2026-05-14 14:36:13 <andar1an> before I create an issue, what causes other than umask or security policies in apparmor may prevent a specific package from extracting with an I/O error? failed to extract usr/bin/pkgname: I/O error. Other packages are installing, and this package was built yesterday, so wondering if it could be build gone wrong. Can try an older version in a bit
2026-05-14 14:47:44 <andar1an> may be something on my end. In abuild rootbld, also get failed to extract messages, but this time with connection aborted reason and bad end of line.
2026-05-14 14:49:04 <amrfti> Is there progress being made on creating a linux-hardened package?
2026-05-14 14:50:05 <amrfti> et would it be helpful to work on making a build for it?
2026-05-14 15:11:36 <andar1an> when in doubt, change vpn lol. Nothing wrong with package. Ignore questions.
2026-05-14 16:19:38 <panekj> bun has been rewritten in rust and it might be possible to bootstrap it now with some patching :>, cc: lnl
2026-05-14 16:20:05 <panekj> though the whole port was vibecoded by claude
2026-05-14 16:23:32 <andar1an> dk why I am getting a build error. error: cannot update the lock file /builds/andar1an/aports/community/nushell/src/nushell-0.112.2/Cargo.lock because --locked was passed to prevent this help: to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
2026-05-14 16:23:57 <andar1an> every other patch, and even the previous patch did this. I didn't change the build lines
2026-05-14 16:24:02 <andar1an> could I be missing something?
2026-05-14 16:33:10 <andar1an> guess I will just add offline to try, but It doesn't seem the norm 
2026-05-14 16:40:55 <andar1an> maybe wrong hash reference, and it is trying to generate a file instead of patching. Will check
2026-05-14 16:54:02 <andar1an> doesn't seem to be case. future me problem 
2026-05-14 18:56:48 <Sertonix[m]> Does a lockfile exist? Does the patch change any Cargo.toml? Does the patch change any Cargo.lock? Is the patch generated based on exactly the same code as fetched by the APKBUILD?
2026-05-14 19:27:58 <Sertonix[m]> (Next time it would help to link the corresponding MR like !102392 )
2026-05-14 19:42:01 <andar1an> gitlab in pain, or just me?
2026-05-14 19:42:25 <andar1an> is there a status endpoint we can look at if wondering?
2026-05-14 19:46:35 <ikke> andar1an: we don't have a status endpoint at the moment
2026-05-14 19:47:25 <andar1an> is gitlab struggling for you? 
2026-05-14 19:47:39 <ikke> Not anymore
2026-05-14 19:48:31 <andar1an> 🥳
2026-05-14 19:48:38 <andar1an> hopefully me too then soon
2026-05-14 19:49:10 <ikke> If it's still not reachable, there may be some routing issue going on
2026-05-14 19:54:35 <andar1an> it seems to be performing better for me now as well. things were taking a long time, but it seemed only related to that site. vpn change didn't seem to correct, so thought maybe heavy load.
2026-05-14 20:17:00 <ikke> There certainly was some heavy load
2026-05-15 00:19:43 <Sertonix[m]> Would anybody be willing to maintain an aMule package? Ref https://gitlab.alpinelinux.org/alpine/aports/-/issues/18173
2026-05-15 05:35:23 <Asmadeus> (just curiosity) I noticed chronyd doesn't depend on gnutls and a bunch of other libs anymore in edge, but I don't see any change to the APKFILE that'd explain this, did global build flags change or does someone know what changed?
2026-05-15 05:36:46 <Asmadeus> ah it's the chrony-nts split, I was blind
2026-05-15 05:36:47 <Asmadeus> ignore me
2026-05-15 08:51:37 <fabricionaweb> Hi, I need some review here !102133 and here !102095 
2026-05-15 09:51:41 <Shiz> any chance of the kernel being updated to mitigate https://www.openwall.com/lists/oss-security/2026/05/15/2 ?
2026-05-15 09:51:53 <Shiz> https://github.com/torvalds/linux/commit/31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a should apply
2026-05-15 10:11:08 <ikke> There will also be a v4 for the fragnesia patch
2026-05-16 04:16:38 <Saijin_Naib[m]> Is !97292 in a state where it can get merged? I also want to follow it up with !97494 to improve functionality of Pitivi from how it is currently packaged
2026-05-16 10:52:44 <ncopa> Saijin_Naib[m]: Im focusing on the 3.24 release so im not looking at testing atm. Need to fix existing stuff before we can add more
2026-05-16 10:54:50 <ncopa> riscv64 builder is a problem
2026-05-16 10:55:28 <ikke> due to speed?
2026-05-16 10:59:30 <ikke> It is quite behind, indeed
2026-05-16 11:09:07 <ncopa> due to lack of speed
2026-05-16 11:09:34 <ncopa> new rebuilds are added faster than it manage to chew the old
2026-05-16 11:10:44 <ikke> yeah
2026-05-16 11:11:10 <quinq> Wouldn't it make sense to abort the “old” ones?
2026-05-16 11:11:24 <ikke> quinq: there is no queue of old builds
2026-05-16 11:11:46 <omni> when it fails it starts over with the added changes
2026-05-16 11:12:08 <quinq> Yeah, I suppose an abort would be treated as a fail
2026-05-16 11:12:13 <quinq> So you get the new one
2026-05-16 11:12:38 <ikke> But it doesn't help if it has to build the same package multiple times after the packages are updated
2026-05-16 11:13:19 <quinq> Indeed, why would it build the same things multiple times over
2026-05-16 11:13:31 <ikke> step 1: build package
2026-05-16 11:13:36 <ikke> step 2: someone pushes a new version
2026-05-16 11:13:40 <ikke> step 3: rebuild that package
2026-05-16 11:14:01 <quinq> Yeah, so step 1 can be aborted on step 2
2026-05-16 11:14:40 <ikke> It almost never happens that step 2 happens while it's still buiding in step 1
2026-05-16 11:14:56 <ikke> It already finished building the package
2026-05-16 11:14:58 <quinq> I thought it was the point here
2026-05-16 11:15:01 <quinq> 13:09:34  ncopa$ new rebuilds are added faster than it manage to chew the old
2026-05-16 11:15:30 <quinq> Maybe I just misunderstood that
2026-05-16 11:15:58 <ikke> It means that the amount of packages it needs to build only grows
2026-05-16 11:16:32 <quinq> Ah right, I suppose it's about “builds”, not “REbuilds”
2026-05-16 11:16:40 <quinq> ok :)
2026-05-16 11:16:57 <omni> I see how it could be interpreted the other way, that a new go rebuild, for example, of all the aports is pushed before the riscv64 builder is done with the last one
2026-05-16 11:17:51 <omni> but I don't think much can be done about that, or that it takes care of itself, as builds fail often enough that it starts over anyway
2026-05-16 11:18:03 <ikke> It's a combination
2026-05-16 11:18:20 <ikke> packages that have been built already, but then upgraded have to be built again
2026-05-16 12:04:25 <ikke> In ~1h (13:00 UTC), gitlab will be unavailable for a bit to apply security updates
2026-05-16 13:00:12 <ikke> gitlab is down for a bit
2026-05-16 13:20:40 <ikke> gitlab is back
2026-05-16 13:35:39 <ikke> rebooting x86_64 builder host
2026-05-16 13:42:58 <tomalok> gitlab is telling me "access denied by administrative rule"?
2026-05-16 13:43:51 <ikke> do you have a reference (request id)?
2026-05-16 13:44:26 <tomalok> 2b5000e97c380644ea98d8d4c099b0f8
2026-05-16 13:45:25 <tomalok> if i go to the site fresh seems i get around it, but refreshing where i was before gives the denial
2026-05-16 13:46:19 <ikke> does that url you refresh include the __go_away_id?
2026-05-16 13:46:30 <ikke> __goaway_id query parameter
2026-05-16 13:52:50 <tomalok> yeah, found that in the URL.  stepped back in the history beyond that
2026-05-16 14:04:27 <Saijin_Naib[m]> @ncopa thanks for confirming. I'll wait until later 🤓
2026-05-16 19:43:39 <andar1an> is there somewhere I can see the merory limits on runners in gitlab? 
2026-05-16 19:44:02 <andar1an> or does anyone know of armhf or armv7 off top of head?
2026-05-16 19:46:31 <andar1an> ah, nvm. Found
2026-05-16 19:47:34 <andar1an> is there a method to up the k8s memory request in an APKBUILD file?
2026-05-16 19:48:12 <andar1an> my bad if dumb question
2026-05-16 21:37:19 <Sertonix[m]> The problem may not be available memory but available address space in a single process instead.
2026-05-16 22:11:50 <andypost[m]> looks like gitlab is overloaded
2026-05-16 22:14:12 <andypost[m]> no more 500, works again
2026-05-16 22:35:33 <JustSouptheyhe[m]> Would somebody mind taking a look at !101247 ? I usually wouldn't ask in chat like this, but since it touches some packages in main/, I worry it might get lost on the backlog :(
2026-05-16 22:58:07 <ikke> JustSouptheyhe[m]: It needs: 1. An ack from the maintainer. 2. Wait until after the release, we have a toolchain freeze now
2026-05-16 23:22:15 <JustSouptheyhe[m]> Ah, I was worried about that. Alright, I'll wait until the after the release is out for a bit to bring this up again (if it doesn't get reviewed beforehand). Thanks!
2026-05-17 14:44:13 <ikke> f_: is it okay to merge 102554? I need it for the wiki to have have the client ip resolve correctly
2026-05-17 14:44:16 <ikke> !102554
2026-05-17 14:57:00 <f_> ikke: just seen it, LGTM, feel free to merge it
2026-05-17 14:57:15 <f_> (also commented on gitlab)
2026-05-17 14:58:04 <ikke> thanks
2026-05-17 14:58:36 <f_> I probably should bump it to the latest current git
2026-05-17 14:58:55 <f_> it hasn't seen a release in a while and there seems to be some interesting additions since then
2026-05-17 14:59:20 <ikke> `yeah
2026-05-17 15:00:31 <f_> nice seems wiki is back
2026-05-17 15:00:47 <ikke> yes, indeed
2026-05-17 15:03:33 <ikke> having go-away packaged made deploying it a bit easier :)
2026-05-17 15:03:52 <ikke> Consider this also as vote to move it to community ;-)
2026-05-17 15:04:03 <f_> yeah thought about that too :D
2026-05-17 15:04:38 <ikke> For the other deployments, I use the docker image, but the wiki is hosted in an LXC container
2026-05-17 15:05:08 <f_> always super convenient when something you want to use is just a single  `apk add` away :)
2026-05-17 15:05:18 <ikke> ack
2026-05-17 15:05:38 <ikke> I had to pull it from edge, but that's generally not an issue for go applications :)
2026-05-17 15:44:55 <f_> ikke: anyway, !102556 so you don't have to pull it from edge on next major release :)
2026-05-17 15:45:13 <f_> (and so I don't have to either :P)
2026-05-17 15:46:40 <ikke> :D
2026-05-17 16:59:09 <ikke> gitlab will be restarted soon for upgrades
2026-05-17 17:06:08 <ikke> Gitlab is back up
2026-05-17 17:06:33 <ikke> And if you wonder where issues have gone, gitlab deemed issues to be too obvious and renamed them to work items
2026-05-17 17:23:58 <quinq> Even if it relates to something that actually doesn't work?
2026-05-17 17:27:39 <ikke> make-it-work items
2026-05-17 17:27:44 <ikke> cause-more-work items
2026-05-17 17:27:52 <ikke> it-doesnt-work items
2026-05-17 17:28:14 <ikke> i-prentend-to-work items
2026-05-17 17:33:34 <spameier> Hello everyone, I'm having an issue with upgrading naabu. The packaging step fails because it seems to require libc.so.6 but the binary is compiled with CGO_ENABLED=0.
2026-05-17 17:33:44 <spameier> MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/101451/diffs
2026-05-17 17:33:54 <spameier> Log: https://gitlab.alpinelinux.org/spameier/aports/-/jobs/2352116
2026-05-17 17:35:39 <ikke> spameier: Does ot pull in some precompiled binary somewhere?
2026-05-17 17:36:15 <ikke> libc.6.so is glibc
2026-05-17 17:43:44 <spameier> ikke: Not sure, I don't see any such thing, but I also don't know where to look exactly for it in Go projects.
2026-05-17 17:50:07 <ikke> Interesting, for some reason the built binary is linked both to musl as glibc
2026-05-17 17:50:30 <ikke> https://tpaste.us/5oex 
2026-05-17 17:50:43 <ikke> which also means your CGO_ENABLED=0 patch does not work
2026-05-17 17:50:56 <spameier> Hmm, they started to pull in https://github.com/ebitengine/purego with version 2.6.0. I guess that might be related.
2026-05-17 17:52:52 <spameier> If i add gcompat as a dependency, build now requires libdl.so.2 which is not in gcompat.
2026-05-17 17:53:37 <ikke> And it's not allowed anyway
2026-05-17 17:54:39 <spameier> Why's that? Guess I'll remove the package in that case from aports..
2026-05-17 17:57:26 <f_> ikke: heh, I actually asked in their feedback thing to rename back to issues
2026-05-17 17:57:50 <f_> their response was basically "we won't revert, just get used to it"
2026-05-17 17:58:04 <ikke> gcompat is an escape hatch for end users if they need to run some glibc software, but not for aports to depend on
2026-05-17 17:58:13 <ikke> (I'm aware there are some packages that still do it)
2026-05-17 17:58:53 <ikke> f_: I wouldn't expect so
2026-05-17 17:59:10 <f_> that's not even an unpopular opinion
2026-05-17 17:59:23 <f_> but I guess it is how it is
2026-05-17 18:02:08 <ikke> Yup
2026-05-18 02:42:47 <zacksiri> hi guys, alpine's gitlab seems to be down
2026-05-18 06:10:57 <ncopa> yeah, it was overloaded. should be back now
2026-05-18 07:02:04 <ncopa> meh. ppc64le kernel does not build with latest sources
2026-05-18 07:12:10 <achill> ncopa: yeah https://lore.kernel.org/all/87cxyuq6oa.fsf@gentoo.org/
2026-05-18 08:23:49 <ncopa> meh. the fix is actually trivial
2026-05-18 08:24:13 <ncopa> i mean, the resolusion of the cherry-pick conflict
2026-05-18 08:25:27 <ncopa> they shoudnt have backported the 09c15bbbed533903e600660ea09098b3b0524f48 papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()
2026-05-18 08:31:56 <ncopa> sam_: https://tpaste.us/RdJ9 
2026-05-18 08:32:07 <ncopa> (i could not send in #gento-dev)
2026-05-18 15:52:51 <sam_> ncopa: thanks
2026-05-18 15:52:53 <sam_> ncopa: i'll also voice you over there
2026-05-18 17:27:13 <ncopa> sam_: thank you for reporting it upstream. i didnt have energy to figure out how to do it, who to CC what to address, what to include, collect the needed info, etc
2026-05-18 21:11:18 <craftyguy[m]> could a maintainer please take a look at !102453 ? thanks!
2026-05-18 21:14:59 <ptrc> sure ^^
2026-05-19 03:28:18 <bratkartoffel> can someone please merge !101844 and !101845? these should be fine on the real builders
2026-05-19 11:37:55 <jahway603> Can I please have !102616 merged?
2026-05-19 19:36:24 <ryze312> Hello, is anyone available to merge !101137? It should be good to go, as it mostly just brings back ZeroTier package.
2026-05-19 19:37:30 <ryze312> ZeroTier was previously removed due to license incompatibility, but they recently put properitary parts under an optional compiler flag.
2026-05-19 19:43:27 <Ariadne> i would prefer we not
2026-05-19 19:44:06 <Ariadne> because what will inevitably happen is, somebody will ask for the proprietary feature to be enabled, and somebody else, who does not know about this trap, will enable the proprietary features
2026-05-19 19:45:25 <ryze312> I've added a comment specifying that the license will no longer be MPL 2.0, when built with ZT_NONFREE, I can make it more clear if it's an issue
2026-05-19 19:46:38 <Ariadne> why does this software need to be in alpine
2026-05-19 19:49:41 <ryze312> Personally, I have a few devices running Alpine that need to be connected to a ZeroTier network, Tailscale is not an option due to various reasons outside my control 
2026-05-19 19:50:23 <ryze312> I think some people would like that as well, though I can't speak for others
2026-05-19 19:51:27 <Ariadne> okay.  but why does this software need to be in alpine?
2026-05-19 19:51:42 <Ariadne> nothing stops you from distributing the apks outside alpine
2026-05-19 19:53:31 <Ariadne> personally, i am of the view that software in aports should be 100% compliant with the open source definition at source level, not just at binary level
2026-05-19 19:53:43 <Ariadne> and zerotier is not
2026-05-19 19:53:57 <ryze312> It's completely possible, I'm just sharing my work and think other people would benefit from including it in the repos along with Tailscale 
2026-05-19 19:54:16 <ryze312> If this doesn't get merged, I'll be okay with it
2026-05-19 19:54:19 <Ariadne> the tailscale client is 100% compliant with the open source definition
2026-05-19 19:54:34 <ryze312> I'm aware of that
2026-05-19 19:56:15 <Ariadne> alternatively, you could go back to the upstream and tell them that distributions still reject this because of the BSL trap
2026-05-19 19:56:27 <Ariadne> and they could fix it :)
2026-05-19 19:57:00 <Ariadne> for example, by having two tarballs: the 100% open source core, and then another with the commercial features
2026-05-19 19:57:52 <ryze312> This exactly what has been done and resulted in compiler flag getting introduced and official binaries no longer include proprietary controller code
2026-05-19 19:58:41 <ryze312> Additionally they no longer license ZeroTier with BSL, it's MPL 2.0 when built without ZT_NONFREE
2026-05-19 20:51:00 <jvvv> I'm working on a kernel for the Radxa Dragon Q6A that I have orderred, so I am curious how the linux-rpi patch is generated. Is it just a simple recursive diff of the raspberrypi sources against against the korg sources?
2026-05-19 20:51:41 <jvvv> Only one of those 'against' was intended.
2026-05-19 21:01:53 <ncopa> jvvv: I checkout the rpi-6.12.y branch, and do a git diff v6.12.<release> and upload that
2026-05-19 21:02:31 <ncopa> if the rpi-6.12.y is a version or two behind the latest upstream, I do git merge v6.12.N
2026-05-19 21:02:50 <ncopa> if there is a conflic, I solve it if its trivial
2026-05-19 21:03:34 <ncopa> often it is possible to merge if I revert the "offending" commit in rpi-6.12.y branch
2026-05-19 21:04:45 <ncopa> but yeah, its just a diff against linux-stable. I git cloned from kernel.org (or github i dont remember) and added rpi repo as a remote
2026-05-19 21:05:40 <ncopa> jvvv: what patches are needed for radxa dragon? I just got a radxa rock 5t that sits here on my desk, waiting for getting set up
2026-05-19 21:10:20 <jvvv> ncopa: I am getting pretty well acquainted with the dragon, but isn't the rock 5t a rockchip? I will look into it now and let you know what I find. The sources I am basing my local aport on are from https://github.com/radxa/kernel repo, linux-7.0.2 branch. Not sure if that is for both qcom and rockchip.
2026-05-19 21:14:27 <jvvv> Looks like it is for both and more. I can post my work to my gitlab.a.o aports repo, though I would be hesitant to do an MR until it was tested.
2026-05-19 21:16:24 <jvvv> I can study the rock 5t's specs to make sure the config works for both boards, or I can try to work it the be a radxa kernel for all/most radxa devices.
2026-05-19 22:00:01 <jvvv> ncopa: Using the method you described (git diff) generates a noticably smaller patch than what I had with diff -Naur
2026-05-19 22:24:06 <craftyguy[m]> is gitlab down?
2026-05-19 23:04:02 <Arnavion> Works for me
2026-05-19 23:04:33 <Arnavion> Ah no, nvm
2026-05-19 23:10:12 <lnl> Yeah down for me too
2026-05-19 23:11:03 <lnl> Random choice of 502, 500, or TLS handshake failed
2026-05-20 02:11:09 <jvvv> ncopa: I think the kernel I am working on packaging is specifically for the dragon q6a and is from the linux-7.0.2 branch. I've looked at some other branches with rockchip specific changes.
2026-05-20 02:13:45 <jvvv> ncopa: TBH, though, I think better inspiration for the 5t could be gleened from looking at armbian and openwrt sources, patches, configs.
2026-05-20 02:50:31 <zacksiri> Hey folks gitlab instance is down!
2026-05-20 03:19:48 <qaqland> yes, "Waiting for GitLab to boot"
2026-05-20 04:09:42 <ikke> It's back
2026-05-20 04:09:52 <ikke> extremely high load
2026-05-20 07:30:30 <ncopa> I am working on rsync update now
2026-05-20 10:11:17 <fabricionaweb> Ive been running the adguard from testing from long long time, it is working well, maybe we could move to community
2026-05-20 10:26:23 <ikke> fabricionaweb: best to let the maintainer know
2026-05-20 10:26:53 <fabricionaweb> it is me hahaha
2026-05-20 10:29:33 <ikke> fabricionaweb: then you can make an MR to move it
2026-05-20 14:00:35 <elagost> would someone be able to look at this MR? !98455 it has been sitting for a while and I've been using it personally for some time, it works well enough. Any suggestions would be welcome too.
2026-05-20 14:03:12 <fabricionaweb> hard to me to review the APKBUILD because Im used to upstream stuff this is like script on it
2026-05-20 14:03:24 <fabricionaweb> doesnt worth to add it to a repository and etc? 
2026-05-20 14:05:40 <elagost> does it need it? many apkbuilds have more lines of patches than the whole script here
2026-05-20 14:08:02 <fabricionaweb> haha yes, that is fair to me
2026-05-20 14:51:21 <jahway603[m]> Can I please get !102668 merged for 3.23? It includes a patch to fix an upstream error.
2026-05-20 15:30:14 <ikke> restarting gitlab real quick
2026-05-20 21:52:28 <Ariadne> personally, i wonder if `testing` should be renamed to `wip` to more reflect its purpose
2026-05-20 22:07:00 <dalias> perhaps
2026-05-20 22:07:35 <quinq> Or “kitchen”
2026-05-21 02:56:30 <Biswa96[m]> wip feels like kind of tech/dev related word. it may be hard to understand for first time users.
2026-05-21 08:11:15 <ncopa> I wonder I should rename webkit2-gtk-4.1 -> webkit2gtk4.1
2026-05-21 08:11:21 <ncopa> while I'm at it
2026-05-21 08:16:59 <ncopa> or maybe webkit2gtk3
2026-05-21 08:17:11 <ncopa> to indicate it is for gtk3
2026-05-21 08:18:22 <ncopa> it matches the description
2026-05-21 08:44:43 <ncopa> ptrc: what do you think about renaming webkit2gtk-4.1 -> webkit2gtk3?
2026-05-21 08:47:37 <ptrc> i mean, we kept the suffix to match with the name used for e.g. pkgconfig
2026-05-21 08:47:40 <ptrc> or development in general
2026-05-21 08:48:07 <ptrc> i'd if someone's writing/packaging an app, they're gonna expect one of those names
2026-05-21 08:48:48 <ncopa> they would not think "this is for gtk3 or gtk4"?
2026-05-21 08:49:04 <ncopa> the problem I'm trying to solve is the -
2026-05-21 08:49:18 <ncopa> was first thinkign webkit2gtk4.1
2026-05-21 08:49:29 <ncopa> but that sounds like gtk4 while it is gtk3
2026-05-21 08:49:32 <ptrc> hm, what's wrong with the dash?
2026-05-21 08:49:55 <ncopa> we dont have any other names with -[0-9]
2026-05-21 08:50:12 <ptrc> yeah, but that shouldn't be a problem, unless someone's writing a broken parser for package names
2026-05-21 08:50:27 <ncopa> right now you can separate the pkgname from pkgver with a regex -[0-9]
2026-05-21 08:50:49 <ncopa> i suppose you still can
2026-05-21 08:50:57 <ptrc> but it's not banned on the spec level to have a dash and a digit right after
2026-05-21 08:51:02 <ncopa> ok. I'm gonna revert the name change
2026-05-21 08:51:05 <ptrc> so it's not a behaviour any software should depend on :p
2026-05-21 08:51:33 <ptrc> the correct thing to do would be to split by `-` and take second-to-last segment
2026-05-21 08:51:39 <ptrc> which is also doable with regex
2026-05-21 08:52:16 <ncopa> i got my answer. you dont like the name change. I'll revert it and move on
2026-05-21 08:59:12 <ncopa> i think I'm gonna merge the upgrade to 2.52.3 without wait for CI. It builds locally on x86_64 and x86, and the current builders are broken anyway
2026-05-21 09:00:38 <ncopa> maybe not. its broken on loongarch64
2026-05-21 09:23:59 <quinq> ncopa, thank you for upgrading webkitgtk!!
2026-05-21 09:24:47 <ncopa> havent suceeded yet. there sia loongarch64 problem
2026-05-21 09:24:58 <ncopa> s/sia/is a/
2026-05-21 09:25:05 <quinq> Well, it's on in amd64
2026-05-21 09:25:14 <quinq> “community/webkit2gtk-4.1: upgrade to 2.48.7” this one
2026-05-21 10:25:12 <ncopa> what is up with lua resty https://build.alpinelinux.org/buildlogs/build-3-24-aarch64/community/lua-resty-jwt/lua-resty-jwt-0.2.3-r2.log
2026-05-21 12:01:25 <durrendal> ncopa: I've been working on a fix for that. Openresty should provide its own openresty-devel-kit which the lua-resty-* modules should depend on.
2026-05-21 12:25:17 <jahway603> Can I please get the backport !102706 merged?
2026-05-21 13:24:54 <ncopa> durrendal: is it this one? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102010
2026-05-21 13:38:13 <durrendal> ncopa: yes that's the one, though the tests fail on lua-resty-hmac after the change and I haven't had a chance to dig in and figure out why. It does build against it though. In theory openresty is so close to nginx from a code standpoint that it should be fine, but I wanted to validate that first.
2026-05-21 13:47:28 <ncopa> I pushed a fix for the tests
2026-05-21 13:47:36 <ncopa> should be ok now
2026-05-21 14:27:44 <durrendal> ncopa: thanks a ton!
2026-05-21 15:04:28 <Sertonix[m]> ncopa: https://gitlab.alpinelinux.org/alpine/apk-tools/-/work_items/10972#note_381642
2026-05-21 15:08:18 <ncopa> ha! thanks Sertonix[m]
2026-05-21 15:09:07 <ncopa> durrendal: it passes! im gonna merge it. Thank you!
2026-05-21 15:20:32 <craftyguy[m]> could maintainers please take a look at !102493 ? thanks!
2026-05-21 16:16:48 <bratkartoffel> can someone please merge !100328?
2026-05-21 16:17:22 <bratkartoffel> and for !100607, are there any open issues preventing this MR to get merged? The segfaults are kinda annoying as it triggers an alert on my servers
2026-05-21 16:17:57 <bratkartoffel> or should i split this MR and create a separate MR for the segfault fix?
2026-05-21 16:54:30 <jvvv> Why does the dovecot change not have a pkgrel bump?
2026-05-21 16:58:52 <jvvv> Seems wrong
2026-05-21 17:05:30 <f_> is the python3 upgrade still unfinished?
2026-05-21 17:05:55 <f_> or just me, apk complains some packages I have still depend on python3.12
2026-05-21 17:11:20 <ikke> f_: packages in testing may still require rebuilds
2026-05-21 17:11:31 <ikke> focus was getting main+community ready for the release
2026-05-21 17:11:36 <f_> okay, fair enough
2026-05-21 18:00:44 <ikke> riscv64 3.24 builder still has 1385 packages to build :(
2026-05-21 18:01:02 <ikke> (and counting)
2026-05-21 18:05:54 <f_> good luck
2026-05-21 18:33:39 <jvvv> ikke: would it be possible to temporarily repurpose some of the riscv64 builders older stable releases (like say, 3.18 or 3.19 and older) to build for 3.24 testing?
2026-05-21 18:34:11 <ikke> jvvv: Not really, our build infra is not setup for parallel building, and generally, they would run on the same hw anyway
2026-05-21 18:34:27 <ikke> For riscv64, we have multiple hosts, but they are all slow and some have issues
2026-05-21 18:34:44 <ikke> ncopa moved it to a different board in the hope that it speeds up
2026-05-21 18:34:50 <ikke> (the 3.24 builder)
2026-05-21 18:35:14 <jvvv> ah, yeah, I should have thought of it that way... what you say makes sense
2026-05-21 18:37:37 <jvvv> It sounded good in my head when I first thought of it
2026-05-21 18:55:58 <f_> btw, abuild doesn't really support cross-compiling does it?
2026-05-21 18:58:34 <ikke> abuild should support it, but we don't officially support it except for bootstrapping
2026-05-21 18:59:08 <f_> it seems to just run the compiler under qemu
2026-05-21 18:59:56 <ikke> Did you build a cross-compile toolchain?
2026-05-21 19:00:32 <f_> I have one installed but I use rootbld so I guess it doesn't matter there
2026-05-21 19:00:58 <ikke> yeah, not sure it works with rootbld
2026-05-21 19:01:03 <f_> right :\
2026-05-21 19:01:11 <f_> ugh I wish my laptop was arm
2026-05-21 19:02:40 <f_> I guess I'll try on an actual arm board for now
2026-05-21 19:20:51 <f_> okay, how do I use it? --help says to CHOST= and CTARGET= but all I get from that is it trying to install build-base-armv7 which doesn't exist
2026-05-21 19:32:06 <ikke> That's what bootstrap.sh generates
2026-05-21 20:44:15 <r0eme> ikke: if qemu-emulated riscv64 is okay...i have some capacity that I could spin up from time to time to help building. (would only be intermittently online tho). any starting points for me to look into? to check out what a builder would entail and how long a build would take on my stuff
2026-05-21 20:44:37 <ikke> r0eme: We used to do emulated, but iirc that gave problems as well
2026-05-21 20:44:51 <ikke> I think we could not run any tests while emulated
2026-05-21 21:31:52 <jvvv> ikke: One other thought... would stopping some of the stable builders for the older releases free up resources enough to help speed up the builders left enabled?
2026-05-21 21:32:19 <ikke> Other builders are idle
2026-05-21 21:33:06 <jvvv> I just wasn't sure if those were idling using any cpu cores, memory, etc
2026-05-21 21:33:26 <ikke> hardly anything
2026-05-21 21:33:47 <ikke> just some core services that do not user any resources
2026-05-21 21:34:02 <ikke> not significant anyway
2026-05-21 21:34:02 <jvvv> Ok, another idea I can send to /dev/null
2026-05-21 21:35:27 <ikke> What we need are faster cores, but they do not exist atm
2026-05-21 21:38:13 <jvvv> I get that. I did a bit of study on some various boards but it seems we have one of the faster ones as it is
2026-05-21 21:38:43 <ikke> spacemit k1?
2026-05-21 21:39:33 <jvvv> Oh, sorry, by 'we' I meant alpine
2026-05-21 21:41:08 <ikke> Understood. Was wondering if you checked the spacemit K1. Is apparently new
2026-05-21 21:42:14 <jvvv> Not sure, that 'studying' I did was before the new year. I will investigate... I doubt I can afford, but no harm looking.
2026-05-21 21:45:14 <jvvv> Huh, the bananapi bpi-f3 looks to be affordable
2026-05-21 22:13:32 <jvvv> Hard to find in stock
2026-05-21 22:45:36 <Sertonix[m]> f_: At the moment cross compilation only works without rootbld. rootbld can only use qemu.
2026-05-22 05:06:00 <Ariadne> ncopa: I'm going to move macifrename to alpine gitlab, can you submit the MR there? 
2026-05-22 05:08:05 <ncopa> Ariadne: that simplifies. can do so, yes. thanks!
2026-05-22 08:10:30 <f_> Sertonix[m]: ok thank you
2026-05-22 09:05:53 <JustSouptheyhe[m]> What's the process for documenting style in CODINGSTYLE.md? I'm trying to figure out the APKBUILD best practices in Alpine currently.
2026-05-22 09:11:11 <ikke> There's no formal process. Generally people start with an MR, and then leave it open for a bit to get feedback. Generally there is also some consensus by way of convention on a certain style.
2026-05-22 09:18:15 <JustSouptheyhe[m]> Alright. So there wouldn't be an issue for just documenting what's already being used by most APKBUILD files?
2026-05-22 09:18:26 <JustSouptheyhe[m]> (An issue, minus the discussion around it)
2026-05-22 09:19:43 <dne> would someone like to merge !102690 and !101107?
2026-05-22 11:02:08 <liske_> I'm trying to bump conntrack-tools in !102681 but CI failes with "prepare failed", but no error cause is shown. Running abuild locally works for me, what could be the problem?
2026-05-22 11:38:18 <fabricionaweb> soooo if Im doing an package and I cant build with lto=true but I can with lto=false, am I doing something wrong or is it fine
2026-05-22 12:18:03 <fabricionaweb> is the pipeline failing due key an issue on me?
2026-05-22 12:18:16 <fabricionaweb> No private key found. Use 'abuild-keygen' to generate the keys.
2026-05-22 12:18:28 <fabricionaweb> (thats from gitlab ci)
2026-05-22 12:30:57 <socksinspace> f_: i thought pmos had a half decent solution for cross building?
2026-05-22 12:40:27 <Sertonix[m]> IIRC it's similar to rootbld, not real cross compilation
2026-05-22 13:03:17 <f_> Sertonix[m]: it is crosscompile
2026-05-22 13:03:30 <f_> socksinspace: ^, but apparently doesn't work as-is for mesa
2026-05-22 13:03:42 <f_> and I don't want to debug why
2026-05-22 13:05:30 <Sertonix[m]> The mesa APKBUILD is not written for cross compilation
2026-05-22 13:08:47 <f_> yeah I can tell
2026-05-22 13:37:16 <Sertonix[m]> The main reason for it not working is that llvm does not provide .pc files. There is an issue open for that since 15 years: https://github.com/llvm/llvm-project/issues/9777
2026-05-22 14:49:37 <jahway603[m]> Is there anything else required to merge backport !102706?
2026-05-22 17:20:23 <Ariadne> ncopa: https://gitlab.alpinelinux.org/ariadne/macifrename#
2026-05-22 21:44:23 <jvvv> liske_: removing the prepare function got me past the update_config_sub failure, but it fails './configure' in the build function due version of libnetfilter_conntrack (1.1.1 needed but it found 1.1.0). Given that failure, there may other netfilter libs that need bumping for the conntrack-tools upgrade.
2026-05-22 21:49:49 <jvvv> liske: I just checked conntrack-tools' configure.ac file and it looks like getting libnetfilter_conntrack to 1.1.1 is the only blocker. Not sure about libnetfilter_conntrack backwards compatibility.
2026-05-22 21:55:29 <jvvv> liske_: libnetfilter_conntrack rdepends are iptstate, oidentd, and ulogd.
2026-05-22 21:55:37 <liske_> jvvv: according to it's git there seems to be a single commit only: https://git.netfilter.org/libnetfilter_conntrack/
2026-05-22 21:55:54 <liske_> for the 1.1.0=>1.1.1 upgrade
2026-05-22 21:57:28 <jvvv> yeah, I think the libnetfilter_conntrack is fairly innocuous
2026-05-22 21:58:15 <jvvv> the upgrade, I mean
2026-05-22 21:58:20 <liske_> Should I combine boh upgrades in a single PR?
2026-05-22 22:00:07 <jvvv> To my understanding, so long as it is a separate commit, it might be ok. I know if you were to bump the rdepends aports, including commits for those is concidered ok.
2026-05-22 22:05:49 <jvvv> I like to separate stuff like the libnetfilter_conntrack upgrade and the conntrack-tools upgrade into separate MR's, though I have been encouraged to combine related stuff before... not sure this one fits my previous experiences
2026-05-22 22:13:30 <liske_> well, !102849 show the same CI error pattern :*-(
2026-05-22 22:18:21 <liske_> and it is also update_config_sub… 
2026-05-23 01:24:37 <jvvv> liske_: I suggest to remove the prepare function. I have tested the build of the upgrade of libnetfilter_conntrack to 1.1.1 (I removed the prepare function). Worked well here
2026-05-23 01:30:25 <jvvv> liske_: The provides (so:libnetfilter_conntrack.so.3) remained the same so there should be no need to bump libnetfilter_conntrack rdepends
2026-05-23 01:31:43 <jvvv> I also test built libnetfilter_conntrack rdepends (iptstate, conntrack-tools, oidentd, ulogd)... no issues
2026-05-23 01:34:56 <jvvv> So after removing the prepare functions from both libnetfilter_conntrack and conntrack-tools, those two MRs should be ok
2026-05-23 01:37:34 <jvvv> I think it makes sense to combine those two MRs, but best to have an dev weigh in on that
2026-05-23 07:31:43 <fabricionaweb> Hi, anyone can review this little bump? !102693
2026-05-23 08:23:00 <liske_> jvvv: thanks!
2026-05-23 09:30:26 <qaqland> ncopa: it only need bats-core for !102564, bats-core is in main/
2026-05-23 11:11:50 <WhyNotHugo> Is options="chmod-clean" still a think? I don't see any references in the abuild source, but it's mentioned in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2026-05-23 11:23:45 <WhyNotHugo> I see several MRs updating packages which declare 'build-base' as a makedepends. Did something change in abuild recently, or have several people made the same mistake?
2026-05-23 12:00:26 <achill> yeah build-base should never be part of APKBUILDs
2026-05-23 12:07:34 <Sertonix[m]> WhyNotHugo: On alpine edge chmod-clean isn't needed anymore: https://gitlab.alpinelinux.org/alpine/abuild/-/commit/ae7bf633911b5238c4812541ad092e59f25e8804
2026-05-23 12:08:59 <Sertonix[m]> Ideally ask people where the idea of adding build-base comes from and if possible change that
2026-05-23 12:09:13 <WhyNotHugo> thanks, ack!
2026-05-23 12:23:46 <Sertonix[m]> achill: Can we make packages like abi-dumper not depend on build-base?
2026-05-23 12:24:06 <achill> Sure
2026-05-23 12:27:05 <achill> I can take a look later
2026-05-23 13:04:15 <jahway603[m]> Can I please get backport !102706 merged?
2026-05-23 13:33:15 <raspbeguy> Hello, can someone review !99277 !101252 !101791 !102729 
2026-05-23 13:33:15 <raspbeguy> !102731 !102877 please?
2026-05-23 16:15:05 <jvvv> liske_: You are welcome
2026-05-23 16:21:11 <jvvv> liske_: When you asked about having those two upgrades in the same MR, I should have thought about the fact that, with them in separate MRs, the conntrack-tools MR could wait a LONG time for its' CI to pass because it could take days (maybe even weeks) for it to get through riscv64 buider and get new pkg into repo.
2026-05-23 16:23:23 <jvvv> Having both commits in the same MR makes the new libnetfilter_conntrack package available to the conntrack-tools build, even in the CI
2026-05-23 18:00:22 <ikke> Yeah, if packages depend on each other, it's alright to combine them in one MR
2026-05-23 18:01:11 <liske_> I've added the libnetfilter_conntrack bump into the other PR, thanks!
2026-05-23 18:23:20 <jvvv> Nice
2026-05-23 18:30:07 <tomalok> is there someone with some golang chops that could take a look at a docker-cli-buildx error that pops up on the builders, but not when I build locally?  https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2358361 -- near as i can tell the problem is that build/git_test.go is trying to get some git info and failing on the builders, but it's
2026-05-23 18:30:07 <tomalok> succeeding locally because it's able to get aports' git info
2026-05-23 18:31:29 <tomalok> started with buildx-0.34.0
2026-05-23 18:33:57 <jvvv> tomalok: Seems like I've seen work arounds for similar by creating an empty git repo where it is looking for one... I can do some searching to see if I can find a reference that describes what I think I am recalling
2026-05-23 18:36:30 <jvvv> community/sdc/APKBUILD does something like what I'm talking about (in the prepare function)
2026-05-23 18:37:19 <jvvv> To find possible examples, I used: find aports -name APKBUILD -exec grep -H -e 'git init' {} \;
2026-05-23 18:53:37 <jvvv> tomalok: I applied the changes in your MR locally. It initially failed with rootbld, same as CI. I added git to checkdepends and added 'git init -q .' near the start of the check function. That fixed it.
2026-05-23 18:57:51 <tomalok> awesome, thank you jvvv!
2026-05-23 18:58:05 <jvvv> You are welcome
2026-05-23 19:11:05 <jvvv> Weird, it failed CI
2026-05-23 19:22:38 <tomalok> yeah
2026-05-23 19:22:58 <tomalok> first time i missed the . -- but also failed with the .
2026-05-23 19:25:43 <jvvv> I checked that also, just to be sure... I apologize. Obviously there is more to it. I am not golang guru, but I will see if I can dig something up.
2026-05-23 19:26:02 <tomalok> thx
2026-05-24 00:11:55 <jvvv> tomalok: I pushed !102914 so I could test possible fixes. CI passed. Let me know if that fixes things well enough so I close the MR and delete the branch or keep looking for a better fix.
2026-05-24 07:38:51 <ncopa> meh. i merged mariadb upgrade which passed in CI. why does it fail on the builders now?
2026-05-24 17:36:33 <raspbeguy> Hello, can someone review !99277 !101252 !101791 !102729 !102731 please?
2026-05-24 18:13:55 <ncopa> raspbeguy: i am currently busy with the 3.24 release, fixing things that we already have
2026-05-24 18:14:05 <ncopa> so testing is more or less ignored by me right now
2026-05-24 18:14:50 <raspbeguy> I see. Time for me to move some packages to community after 3.24 is released
2026-05-24 18:23:54 <raspbeguy> I never know when it's time to move a package from testing from community 
2026-05-24 18:24:01 <raspbeguy> To community*
2026-05-24 18:41:48 <f_> It's mostly whenever you feel like it
2026-05-24 18:41:58 <f_> and it has gotten sufficient testing
2026-05-24 18:42:56 <raspbeguy> Some of them definitely check those cases
2026-05-25 08:31:47 <fabricionaweb> will the 3.23 gets rust upgrade? I dont know how that works, vaultwarden for example is blocked
2026-05-25 08:31:57 <fabricionaweb> !102817
2026-05-25 08:39:37 <witcher01> i was under the assumption only security and bug fixes would land in stable releases. is this assumption wrong?
2026-05-25 08:47:38 <fabricionaweb> for the vaultwarden package, that 1.36 does contain security fix https://github.com/dani-garcia/vaultwarden/releases/tag/1.36.0 but it is locked due rust so not sure how to procceed
2026-05-25 12:32:02 <ayakael> Is there a way to backport the commits related to the security fix?
2026-05-25 12:39:42 <ikke> ayakael: cherry-pick?
2026-05-25 12:48:47 <omni> fabricionaweb: I think the current situation is that rust should be expexted to stay at the version it's at at the time of cutting an alpine stable release, the reason is that newer rust releases may require newer dependencies and upgrading those may affect a lot of other aports etc...
2026-05-25 12:51:32 <omni> for vaultwarden (and the macros crate), you could try and see if rust 1.93.0 is a hard requirement, by decrementing rust-version in their Cargo.toml, or if it was just lazy MSRV bumping on the upstream part
2026-05-25 12:53:18 <fabricionaweb> good idea ayakael, and thanks omni as well, I will try it
2026-05-25 13:04:41 <ayakael> Yeah, cherry-pick :)
2026-05-25 13:26:45 <WhyNotHugo> omni: newer versions of rust may also fail to compile older code. These are exceptional, but I've been the victim of this twice.
2026-05-25 13:26:56 <WhyNotHugo> Usually a fix is trivial, but still.
2026-05-25 13:36:28 <jahway603[m]> I've also had newer versions of rust fail to compile older code.
2026-05-25 14:34:47 <ikke> ayakael: ah, I misunderstood you. Thought it was a separate question instead of a reply to fabricionaweb
2026-05-25 14:35:41 <fabricionaweb> decreasing the rust-version build it local seems to work
2026-05-25 14:40:57 <fabricionaweb> something is happening, the MR doesnt contain my commit lmao
2026-05-25 14:46:41 <ollieparanoid1> I fixed two builds, now build-3-24-x86_64 has only one failing package
2026-05-25 14:46:44 <ollieparanoid1> gopass: https://build.alpinelinux.org/buildlogs/build-3-24-x86_64/community/gopass/gopass-1.16.1-r5.log
2026-05-25 14:46:48 <ollieparanoid1> I attempted to make a fix here, but it didn't work: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102978
2026-05-25 14:46:52 <ollieparanoid1> does somebody have an idea how to fix this one?
2026-05-25 15:52:30 <liske_> Is gitlab down?
2026-05-25 15:53:03 <fabricionaweb> it seems
2026-05-25 15:53:15 <liske_> oh now I got a: HTTP 502: Waiting for GitLab to boot
2026-05-25 15:56:37 <ikke> on it
2026-05-25 18:10:27 <skarnet> down is the only stable state
2026-05-25 18:19:11 <ikke> 
ACTION proceed to turn all servers down

2026-05-25 19:38:47 <liske_> ollieparanoid1: gopass builds locally for me, TestListRegressions1628 just passes
2026-05-25 20:49:41 <ollieparanoid1> I wonder if we should just disable the this specific test if it doesn't run properly in alpine builders... can't look more into it right now though
2026-05-25 21:51:07 <fabricionaweb> Maybe yes, and comment why
2026-05-25 21:54:09 <ikke> Anything I should try to test on the builders?
2026-05-25 22:26:54 <ikke> gopass fails due to GOTMPDIR for some reason
2026-05-25 22:28:56 <ikke> I think it's the path length
2026-05-25 22:34:45 <liske_> ikke: yeah this could it be - I did have two directory levels less than on the build host… moving the package directory two dir levels deeper makes the test fail locally, too
2026-05-25 22:35:28 <ikke> "gpg-agent[786567]: socket name '/home/buildozer/aports/community/gopass/tmp/TestListRegressions16281991659580/001/.local/share/gopass/stores/root/S.gpg-agent' is too long"
2026-05-25 22:35:37 <ikke> I ran into this before
2026-05-25 22:36:37 <ikke> unix sockets can be max 108 characters long :(
2026-05-25 22:37:45 <ikke> 1669f230df95ffdf0ce5ce6166cfbb345cbda510
2026-05-25 22:37:46 <liske_> yes :(
2026-05-25 22:42:50 <liske_> setting GOTMPDIR in check() looks like to work
2026-05-25 22:43:42 <ikke> yes
2026-05-25 22:45:47 <liske_> ikke: are you going to fix it yourself or should I open a PR?
2026-05-25 22:45:58 <ikke> Just pushed a fix
2026-05-25 22:46:19 <liske_> :-)
2026-05-25 22:48:47 <ikke> x86_64 is now uploading community
2026-05-25 22:48:55 <liske_> \o/
2026-05-25 22:49:09 <ikke> I do wonder why this only happens on x86_64 though
2026-05-25 22:49:32 <liske_> yeah that is weird
2026-05-25 22:50:49 <ikke> and now pulumi also passed :o
2026-05-25 23:22:16 <jvvv> For the GOTMPDIR socket name pathlen too long issue, is the tailscale patch the preferred approach or is it enough to export GOTMPDIR=/tmp in the APKBUILD?
2026-05-25 23:28:45 <omni> for gopass, tests are "temporarily" disabled on aarch64 and riscv64
2026-05-25 23:48:55 <jvvv> Ok. I was asking for other cases of the same issue in other aports.
2026-05-26 00:45:33 <omni> jvvv: it was more general information than an answer to your question, and a reminder that we may want to try to run the tests on those architectures
2026-05-26 00:58:46 <jvvv> omni: thanks for the heads up
2026-05-26 02:50:00 <qaqland> could someone have a look at !101907, it's ready
2026-05-26 11:15:59 <Sertonix[m]> omni: Please don't mess with abuild code as much as it has been done in main/libyuv. Consider using dev.a.o and/or downloading the code in prepare() instead
2026-05-26 11:27:19 <Sertonix[m]> Could !96390 be merged?
2026-05-26 16:27:12 <omni> Sertonix[m]: I didn't think prepare() would be a good fit, it was the best I could come up with, it would be nice to have something to handle googlesource.com
2026-05-26 16:39:26 <elly> googlesource.com rebuilds the tarball on the fly with new checksums for the same commit? that's very odd
2026-05-26 16:42:09 <abby> on void we have the concept of a content checksum for things like googlesource
2026-05-26 16:43:29 <abby> https://github.com/void-linux/void-packages/blob/f18993abcd6a3ddc2abd0765e4c6e4cb62b50da5/common/hooks/do-fetch/00-distfiles.sh#L6
2026-05-26 16:43:35 <abby> that function
2026-05-26 18:22:46 <Ariadne> computing that sounds expensive, or are you just stripping the tar headers?
2026-05-26 18:26:08 <abby> it's more-or-less tar xOf $distfile | sha256sum -
2026-05-26 18:26:20 <abby> might be expensive but it's not commonly needed
2026-05-26 18:45:13 <elly> that does not seem legit because that is _just_ the file contents, not the filenames
2026-05-26 18:45:24 <elly> and a tarball with the same file bytes but different names isn't the same
2026-05-26 18:46:52 <elly> I think it may be necessary to spelunk around in the tarball replacing the mtimes/ctimes so that the result has the expected hash? or ask the googlesource people to stop doing what they are doing maybe :)
2026-05-26 18:50:30 <abby> good luck
2026-05-26 18:50:47 <Sertonix[m]> If we already want accept usage of custom code we can just do git clone && git archive
2026-05-26 18:53:00 <Sertonix[m]> If we want to have something which doesn't require running custom code we have to upload reproducible tarballs somewhere.
2026-05-26 18:53:07 <abby> maybe our thing could be adjusted to include the file listing
2026-05-26 18:54:27 <elly> I guess the least custom way to do it would be to unpack the tarball, then repack it with --owner=0 --group=0 --mtime=0 (or whatever) to force all the metadata to stable values
2026-05-26 18:57:24 <Sertonix[m]> But it's not safely dealing with untrusted data. I would expect that git (especially when using a bare repo) would be a lot safer.
2026-05-27 01:41:41 <Ariadne> is it just me or is sddm really buggy in edge right now
2026-05-27 04:36:55 <Saijin_Naib[m]> Not just you. Seen a number of folks with issues with it in alpine-linux and on Masto
2026-05-27 04:37:11 <Saijin_Naib[m]> No idea on STR, though
2026-05-27 07:18:59 <f_> achill: you think it makes sense to add patches that fix critical bugs in mesa before they're included in the tree?
2026-05-27 07:19:39 <f_> exynos is broken with latest mesa 26.1, there's a patch to fix it but it wasn't merged yet, and alpine 3.24 is soon to be tagged
2026-05-27 07:23:32 <achill> i'd merge it
2026-05-27 07:24:00 <f_> thanks ^^
2026-05-27 07:24:36 <f_> FYI, it's this one https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41737, will submit an MR to aports to add it
2026-05-27 11:28:38 <omni> ncopa: I noticed now that you weren't assigned to !102461
2026-05-27 11:28:52 <omni> algitbot: hello?
2026-05-27 11:29:12 <omni> main/zfs: upgrade to 2.4.2 - https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102461
2026-05-27 11:51:34 <ptrc> anyone else getting throttled to hell and back on gitlab.a.o?
2026-05-27 11:51:45 <ptrc> > Get "https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102628.patch": net/http: TLS handshake timeout
2026-05-27 11:56:46 <omni> Yes.
2026-05-27 11:57:35 <ptrc> i guess it's the universe telling me i should take a break lol
2026-05-27 11:57:55 <ptrc> i've spent way too much time today on trying to make mozware less OOMy
2026-05-27 11:58:10 <omni> <3
2026-05-27 11:58:27 <ptrc> still haven't gotten x86 back though 😔
2026-05-27 12:00:32 <omni> did you try various LTO whatnots? it's "just" glean, right?
2026-05-27 12:00:55 <ptrc> my only idea at this point is to disable all optimization
2026-05-27 12:01:06 <ptrc> i've tried setting everything i feasibly could to just 1 thread
2026-05-27 12:03:39 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103062
2026-05-27 12:03:40 <ptrc> LIKE
2026-05-27 12:03:41 <ptrc> like *
2026-05-27 12:03:50 <ptrc> this is silly already
2026-05-27 12:04:02 <ptrc> and even then, it still doesn't work
2026-05-27 12:05:24 <omni> =/
2026-05-27 12:07:02 <caskd> yeah
2026-05-27 12:07:41 <caskd> same here
2026-05-27 12:07:47 <caskd> 500 trying to open a MR
2026-05-27 12:12:36 <omni> 
ACTION blames "AI" scrapers

2026-05-27 12:12:55 <ptrc> eyup
2026-05-27 12:15:52 <caskd> oh well
2026-05-27 12:16:04 <caskd> im surprised it didnt happen more often
2026-05-27 12:16:26 <caskd> im still fine with sending patches via mailing list :P
2026-05-27 12:16:54 <ptrc> hm, actually, do we still have functioning mailing lists?
2026-05-27 12:17:13 <ptrc> https://lists.alpinelinux.org/~alpine/aports
2026-05-27 12:17:15 <ptrc> hmmmm
2026-05-27 12:22:33 <skarnet> I've been trying to push a commit to codeberg for 15 minutes and it's not going through... all the forges struggling to keep up, unite!
2026-05-27 12:24:15 <caskd> imagine a world where bulk AI scrapers would've learned from decades of scraping experience from big search providers and respected the infra they collect data from 
2026-05-27 12:24:46 <caskd> it is a fantasy that's quite far fetched despite it being realistic enough
2026-05-27 12:25:58 <skarnet> > bulk AI scrapers
2026-05-27 12:26:00 <skarnet> > respect
2026-05-27 12:26:12 <caskd> i said far fetched
2026-05-27 12:26:17 <caskd> ^^'
2026-05-27 12:26:32 <skarnet> that's not far-fetched, that's oxymoronic
2026-05-27 13:43:22 <omni> https://git.alpinelinux.org/aports/commit/?id=cba02e2d25c017549ff696a29c896137516386d5
2026-05-27 13:43:45 <omni> ganska nöjd med 13:37:21 +0000 utan att ha försökt pricka
2026-05-27 13:44:23 <omni> wrong channel
2026-05-27 13:44:26 <omni> 
ACTION smh

2026-05-27 13:44:55 <dne> grattis! :)
2026-05-27 13:45:33 <f_>  /groupserv access @postmarketos list
2026-05-27 13:45:36 <f_> err
2026-05-27 15:02:44 <jvvv> knuxify: I pushed !103066 before looking for other solaar MRs. I incorporated your changes from !100059. It could be just as easy to add the py3-typing-extensions dep addition to your MR.
2026-05-27 17:26:08 <lotheac> caskd: not that it changes the individual (search engine|ai|scraper)'s value function, but i can't help but think: "back then", the scrapers benefited from the original content being available. in contrast, right now -- who cares, already trained your model on that.
2026-05-27 20:50:21 <ayakael> Could someone merge: !102341 !102343 !102345 and !102346
2026-05-27 20:50:21 <ayakael> Security upgrades for dotnet backported to 3.22 and 3.21. CI failures are due to a CI bug, but otherwise it builds.
2026-05-27 21:07:19 <ikke> ayakael: do you know what is causing that bug?
2026-05-27 21:08:23 <ikke> seems like busybox triggers are not executed?
2026-05-27 21:09:25 <ikke> I do have a fix for that
2026-05-28 03:00:19 <ayakael> No I don't. I lack the time to debug further unfortunately - in the middle of moving to a new appartment
2026-05-28 03:33:35 <craftyguy[m]> could a maintainer please take a look at !103053? thanks!
2026-05-28 04:32:17 <ncopa> morning! omni: do youthin you can help with https://build.alpinelinux.org/buildlogs/build-3-24-riscv64/community/racksdb/racksdb-0.6.0-r3.log
2026-05-28 04:32:27 <ncopa> it reproduces on x86_64 as well
2026-05-28 04:40:24 <Saijin_Naib[m]> Does anyone know if tweaking libguestfs to provide virt-sparsify (libvirt-dev makedepends and some fixes) would be possible?
2026-05-28 04:40:34 <Saijin_Naib[m]> Would be insanely helpful to have
2026-05-28 04:47:27 <ncopa> omni: never mind. I think I got it
2026-05-28 04:48:12 <ncopa> Saijin_Naib[m]: everything is possible. the impossible just takes a bit longer time...
2026-05-28 04:48:29 <Asmadeus> Saijin_Naib[m]: there already is libguestfs in testing and virt-sparsify is in https://github.com/libguestfs/guestfs-tools (different repo) so you likely 'just' need to build it
2026-05-28 04:52:53 <Saijin_Naib[m]> How would that work with libguestfs aport providing guestfs-tools already as a subpackage?
2026-05-28 04:53:31 <Asmadeus> you'd need to fight over the package name.. likely guestfs-tools-extra or something?
2026-05-28 04:53:54 <Asmadeus> libguestfs itself provides some tools, but there's more in the other repo
2026-05-28 04:54:21 <Asmadeus> or you could pull in the guestfs-tools sources in the libguestfs aports and build everything together, but it's probably better to keep separate
2026-05-28 05:25:35 <ikke> ayakael: the fix I applied worked, the pipeline is now green :)
2026-05-28 05:26:33 <jvvv> I'm working on an akms module plus firmware aport. The are three different module ($pkgname-variant-src) subpackages with correlated firmware ($pkgname-variant-firmware) subpackages. I'm trying to understand if I should have the module source subpackage depend on the firmware subpackage or use install_if instead.
2026-05-28 05:29:58 <jvvv> I think depends makes more sense.
2026-05-28 05:35:41 <ikke> yeah, depends is preferred. install_if is when you don't control the other package or don't want to update the other package everytime a new reverse dependency is added (think $pkg-openrc)
2026-05-28 05:38:09 <jvvv> OK, thank you. It is good to have that explained like that, really makes it clear to me.
2026-05-28 09:15:22 <omni> ncopa: because of situations like this, I'm not sure it was a good idea of me to package it like that but it helps a bit with catching when security fixes are needed
2026-05-28 09:21:11 <ncopa> yeah, it helps us to avoid ship vulnerable
2026-05-28 11:09:40 <omni> I just painlessly upgraded a couple of 3.23-stable VMs to current 3.24, no issues so far
2026-05-28 12:40:43 <WhyNotHugo> ncopa: thanks for the guidance with the soname details (on the hunspell MR).
2026-05-28 12:44:57 <ayakael> ikke: Thank you! :)
2026-05-28 12:45:41 <ikke> Basically, there is an issue when downgrading from apkv3 to apkv2 that prevents triggers to run. Solution is to switch to per-release images
2026-05-28 15:39:12 <pere87> could anyone review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99858?
2026-05-28 15:48:43 <pere87> also, can anyone remove the "mr-stale" label in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99834 ? This one has been approved, but otherwise, I fear a bot could close it in a month :(
2026-05-28 16:14:31 <ikke> We don't autoclose MRs
2026-05-28 17:33:02 <Ariadne> ncopa: reminder that i've published macifrename sources on gitlab, if we want to get a release out for 3.24
2026-05-28 17:41:50 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103155
2026-05-28 17:41:51 <ptrc> sigh
2026-05-28 17:43:08 <ptrc> it also feels like slop, considering their main product is slop
2026-05-28 17:44:08 <f_> the APKBUILD reads slightly AI-generated but don't take my word for it
2026-05-28 17:44:11 <elly> sounds like an easy reject?
2026-05-28 17:44:26 <ptrc> it is
2026-05-28 17:44:35 <f_> "it is" to what? :)
2026-05-28 17:44:39 <ptrc> an easy reject
2026-05-28 17:44:45 <ptrc> i'm not sure whether the apkbuild itself is LLM-generated
2026-05-28 17:44:52 <ptrc> but that doesn't matter that much
2026-05-28 17:45:04 <f_> I mean yeah not really lacking reason to reject
2026-05-28 17:45:37 <elly> there's not really enough of an APKBUILD to form much of an opinion either way on whether it itself is AI
2026-05-28 18:16:17 <elagost> would someone be willing to merge this? !98455 I've been using it for a while and it works well. any suggestions for changes would be very welcome too.
2026-05-28 19:45:48 <Ariadne> elagost: sure
2026-05-28 19:46:59 <elagost> TY!
2026-05-28 20:01:49 <ewo> Hi, if one was going to submit a package to aports, do you need a gitlab account? Thanks
2026-05-28 20:04:57 <ptrc> technically we do have a mailing list
2026-05-28 20:05:09 <ewo> ptrc: oops brain
2026-05-28 20:05:12 <ptrc> we used to have an integration that brings those over to gitlab, but in general it's way easier to just submit a merge request
2026-05-28 20:05:33 <ewo> fair aye
2026-05-28 20:06:00 <ewo> It's not much anyways, I just packaged xidle for myself
2026-05-28 22:59:05 <omni> why the pickyness of the order of sha512sums?
2026-05-29 04:24:32 <ikke> omni: due to the way abuild matches source to sum?
2026-05-29 05:11:44 <Sertonix[m]> It's easy to deal with in the abuild code and the checksums are generated by abuild anyways.
2026-05-29 09:26:38 <qaqland> for new aport, should I use '# Maintainer' or 'maintainer='? ref !101901
2026-05-29 09:27:41 <ncopa> Ariadne: not sure I like the https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/101247 libcc was less than 200k and now it is more than 3MB. We have 2700+ packages using libgcc at runtime and they all now pull in those extra 3MB. I wonder if it would make more sense to have a libgcc-static subpackage for those
2026-05-29 09:41:00 <Sertonix[m]> I think libgcc-dev would be a bit better
2026-05-29 09:44:39 <ptrc> https://github.com/nodejs/node/issues/62764
2026-05-29 09:44:41 <ptrc> interesting
2026-05-29 10:25:25 <fabricionaweb> Im now using maintaner key not the comment qaqland
2026-05-29 10:28:53 <fabricionaweb> qaqland that package is awesome lol
2026-05-29 12:19:05 <elly> wow so it is
2026-05-29 12:53:35 <skarnet> that's pretty impressive
2026-05-29 17:51:43 <Ariadne> ncopa: I agree let's do it
2026-05-29 17:58:52 <dalias> does libgcc-static subpackage make sense?
2026-05-29 17:59:34 <dalias> the static libs are hard requirements for gcc itself. shouldn't they just be in the gcc package?
2026-05-29 17:59:50 <dalias> or would gcc package depend on libgcc-static so that clang can also use them without pulling in gcc?
2026-05-29 18:22:40 <Ariadne> yes that is the goal
2026-05-29 18:28:03 <Ariadne> I also have GCC 16 ready to go in after Alpine 3.24 release
2026-05-29 19:01:42 <omni> :q
2026-05-30 08:24:35 <omni> fabricionaweb: thelounge is failing to build on build-edge-loongarch64, some timeout issue it keeps hitting but didn't seem to do on build-3-24-loongarch64
2026-05-30 08:47:31 <fabricionaweb> damn, I saw the email morning, Im out of pc until tomorrow :/ maybe we can disable it for loongarch
2026-05-30 08:52:10 <fabricionaweb> I sent !103242 but Im leaving for a trip now
2026-05-30 08:54:56 <fabricionaweb> my bad I could have just skip tests not whole build, I amend it 
2026-05-30 08:55:09 <fabricionaweb> thats what we do on rush lmao
2026-05-30 08:55:25 <fabricionaweb> see you later wife is yelling at me
2026-05-30 09:23:05 <omni> ok, let's do that for now (I thought I'd look a bit at it myself but accidentally pressed the merge button)
2026-05-30 12:27:17 <Guest10419> .
2026-05-30 13:25:27 <markand> its a shame that alpine will allow AI while postmarket doesnt
2026-05-30 13:26:15 <markand> especially towards a well designed simplicity oriented distro as the main goals
2026-05-30 13:26:28 <markand> despite that AI is known to be environmentally destructive
2026-05-30 15:17:20 <ptrc> markand: what do you mean?
2026-05-30 15:18:26 <JustSouptheyhe[m]> markand: nothing has been finalized, so please don't badger the Alpine devs about it. postmarketOS is a different organization from Alpine, so both are able to set different rules if they want to do so.
2026-05-30 15:20:27 <markand> I think it's already done https://gitlab.alpinelinux.org/alpine/council/-/work_items/697#note_615552
2026-05-30 15:23:56 <JustSouptheyhe[m]> Its not done until there's an official policy made. There's still a lot of different opinions on what a policy would even look like. I'd say just give the devs time.
2026-05-30 15:49:11 <f_> you're just linking to one comment of the discussion, as justsoup said it is still under discussion
2026-05-30 15:49:51 <f_> and even if they do end up accepting AI contributions, I'd appreciate it if you wouldn't harass alpine developers
2026-05-30 15:54:08 <f_> I am against AI contributions but I also against harassment
2026-05-30 16:02:38 <markand> where do you see harassment?
2026-05-30 16:04:33 <markand> I am explicitly silent most of the time and quite open mind in many area I dislike and as a contributor to alpine and maintaining some packages I'm just adressing my concerns over a topic that is to be settled down quickly
2026-05-30 16:36:39 <skarnet> personally I would also prefer a more explicitly anti-AI stance, so anything derived from Alpine (and Alpine users themselves!) can upgrade without fear of sloppy regressions
2026-05-30 16:37:17 <skarnet> it's not even ideological, it's practical: as the example of rsync shows, LLM-assisted code is generally poorer than human-only code
2026-05-30 16:37:56 <skarnet> and accepting AI-assisted contributions would just decrease the quality of software distributed by Alpine
2026-05-30 16:38:10 <skarnet> not always, there are certainly exceptions, but in general
2026-05-30 16:38:35 <f_> skarnet: it wouldn't really, alpine packages software that already accepts LLM contributions, so regardless of what alpine says their quality will decrease for sure
2026-05-30 16:39:31 <skarnet> well that's a problem that needs to be addressed case by case, it wouldn't be the first time Alpine packages stuff that doesn't follow its policies for various reasons
2026-05-30 16:39:40 <skarnet> and getting them to fall in line is an ongoing effort
2026-05-30 16:40:02 <skarnet> "A is already doing the bad thing" isn't a reason to let B do the bad thing as well
2026-05-30 16:40:38 <skarnet> I think anything more nuanced than a blanket ban will result in more work for Alpine devs
2026-05-30 16:41:08 <f_> skarnet: as I understand it the question isn't "do we still accept software accepting LLM assistance" but rather "do we accept LLM contributions in aports / alpine software"
2026-05-30 16:41:28 <skarnet> then I don't see why it's even a question
2026-05-30 16:41:38 <f_> because if the former is a "no", well, I guess let's move to a BSD kernel (sadly)
2026-05-30 16:41:38 <skarnet> it should be a no period
2026-05-30 16:41:51 <f_> because linux accepts LLM contributions
2026-05-30 16:42:05 <skarnet> again it's an ongoing effort
2026-05-30 16:42:29 <f_>  18:41 <skarnet> then I don't see why it's even a question
2026-05-30 16:42:30 <skarnet> if Linux starts breaking Alpine won't be the first to notice and there are going to be real, visible problems everywhere
2026-05-30 16:42:36 <f_> well pmOS did put a blanket ban on LLMs
2026-05-30 16:42:45 <skarnet> good
2026-05-30 16:42:52 <skarnet> now throw systemd out
2026-05-30 16:43:02 <f_> so far has been manageable, but it's a small project
2026-05-30 16:43:14 <f_> alpine is bigger than pmOS
2026-05-30 16:43:19 <skarnet> yes
2026-05-30 16:43:26 <skarnet> and also an upstream
2026-05-30 16:43:44 <f_> skarnet: and on init systems, pmOS still supports openrc and such fwiw, writing from pmOS/OpenRC
2026-05-30 16:43:55 <skarnet> yeah and that's cool
2026-05-30 16:44:39 <skarnet> but a blanket ban also means slowly pushing slopcode out :P
2026-05-30 16:44:57 <f_> anyway I'm just saying that for a project this size, a blanket ban on LLM contributions to postmarketOS projects went fine.
2026-05-30 16:45:01 <markand> it also pushes boring time consuming MR 
2026-05-30 16:45:24 <markand> GNOME devs got annoyed about slop extension with code that does not follow GJS guidance
2026-05-30 16:45:46 <skarnet> if the question is about Alpine software itself then I think the answer should be a clear no, anything else would both decrease quality and increase burden on devs
2026-05-30 16:46:06 <markand> alpine is bigger than pmOS but it's not as huge as debian which take 2 years to take a decision either
2026-05-30 17:35:13 <WhyNotHugo> f_: pmOS didn't do a blanket ban: it only applies to contribtions and its spaces. Software written by developers using LLM is not prohibited, and likely can't be (the obvious examples being Linux, Firefox).
2026-05-30 17:35:41 <WhyNotHugo> markand: several comments on the issue reflect a "not wanting to rush into a decision", so pushing for a fast decision isn't very polite.
2026-05-30 17:37:17 <f_> WhyNotHugo: A blanket ban on its space
2026-05-30 17:37:24 <f_> is what I meant
2026-05-30 17:42:00 <markand> WhyNotHugo, that your very own description of polite
2026-05-30 17:45:06 <f_> it's a project made by volunteers, it is unreasonable to push for doing things fast
2026-05-30 20:55:56 <iggy> all this anti-AI stuff reminds me of crazy people who want to ban books "I don't like it so nobody should be able to see (use) it"... it's a little extremist at times
2026-05-30 21:06:45 <abby> 🧐
2026-05-30 21:07:06 <Sheila> 🙄
2026-05-30 21:07:55 <Sheila> you're entitled to your opinion, but comments like that are unproductive and inappropriate for this channel.
2026-05-30 21:54:58 <fabricionaweb> analogy is my passion
2026-05-30 23:00:36 <quinq> It's also an incorrect one
2026-05-31 03:10:55 <shield[m]> hello is there any proper procedure for building one apkbuild from another, for example I want to make a small patch to the linux-stable x86_64 config file without maintaining a clone of linux-stable. Is it possible to call the abuild of linux-stable from the static git.alpinelinux.org and patch that abuild, then build it?
2026-05-31 03:31:08 <comk> shield[m] since APKBUILDs are just shellscript then yeah if you just need to change small thing you can `source` one from other and call the functions inside with your overrides. i guess you would include the APKBUILD in `source=`
2026-05-31 03:36:09 <shield[m]> Cool, wouldnt I need to include the entire community/linux-stable/* contents if I want it to build properly?
2026-05-31 05:23:42 <comk> shield[m] yes
2026-05-31 05:25:07 <comk> it might be more hassle than the idiomatic alternative of just forking it and i guess this is why its rarely seen in practice
2026-05-31 05:28:29 <comk> which itself you coud automate with `git` and `patch` and then only use abuild on the resulting apkbuild as normal  
2026-05-31 05:30:17 <comk> maybe worth checking if postmarketos has anything nice there since they downstream and patch many alpine packages
2026-05-31 05:31:29 <shield[m]> dont worry I parsed html to build the source= array
2026-05-31 05:31:33 <shield[m]> god save me
2026-05-31 05:41:25 <comk> shield[m] only more regexes can save you now 
2026-05-31 05:41:55 <qaqland> I created an issue for pulseaudio vs pipewire-pulse https://gitlab.alpinelinux.org/alpine/alpine-conf/-/work_items/10651
2026-05-31 05:42:57 <shield[m]> comk: amen
2026-05-31 08:36:50 <DylanVanAssche> I'm trying to upgrade libssc but it fails on s390x: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103262. To be honest, I have no idea why, of course the error exit code says something, but that's not enough information to find the root cause. Anyone a suggestion on how to debug this?
2026-05-31 08:59:43 <Ariadne> i am unhappy with the LLM policy that has been proposed by ncopa in the council LLM policy ticket.  i do not know what that means for my future as an alpine developer, honestly.
2026-05-31 09:02:06 <Ariadne> i guess i will sleep on it, and hope that the council does not move forward with a bad decision that does not reflect the overall vibe in the community right now.
2026-05-31 09:03:57 <Ariadne> however, should it be necessary, i am willing and able to help get a fork going that will ban LLM contributions.
2026-05-31 09:04:16 <Ariadne> and... anyone who is an alpine or postmarketOS developer is welcome to join me :)
2026-05-31 09:04:21 <vmignot> I'm clearly not invested in Alpine development compared to anyone here, but as a user that would make me probably move to Gentoo
2026-05-31 09:04:38 <vmignot> (or a fork)
2026-05-31 09:05:42 <Ariadne> i thought about just saying 'fuck it' and installing Gentoo, and that might still wind up being what i do, as i certainly cannot build a fork on my own.  but the reason why i work on alpine is because it is an integrated operating system.
2026-05-31 09:09:46 <Ariadne> but i also don't know what that means, right?
2026-05-31 09:10:24 <Ariadne> i made all of these things like pkgconf, libucontext, ifupdown-ng, etc. to improve alpine
2026-05-31 09:18:04 <ncopa> Sorry to hear that. I'm just trying to be more pragmatic
2026-05-31 09:22:02 <Ariadne> i'm not trying to be a dick here, but technical pragmatism isn't sufficiently holistic
2026-05-31 09:23:44 <Ariadne> you founded a project that has grown into all of this, and while technical pragmatism was part of how we got here, it was also standing for things like software freedom and human rights, and to me i feel like we have allowed ourselves to stray so far from what we once were
2026-05-31 09:24:19 <Ariadne> we are, frankly, victims of our own success
2026-05-31 09:25:00 <Ariadne> we cannot take a meaningful stance on something that is harmful because we are afraid that we will scare our colonizers?
2026-05-31 09:26:56 <ncopa> I know you well enough to know you dont have bad intentions
2026-05-31 09:27:21 <ncopa> im a bit on short time here (need to run...)
2026-05-31 09:27:45 <ncopa> can I ask you to please have patience with me?
2026-05-31 09:29:04 <ncopa> one of the reasons I don't want do full pmOS style ban is that I believe that there exist good use of AI. That is why there are exceptions of those bans
2026-05-31 09:29:09 <ncopa> but I need to run now
2026-05-31 09:30:28 <Ariadne> my intention is to preserve what we've built here.  it is not compatible with LLM/agentic/whatever.  we built Alpine to lift up humans.  humans.  not AI companies, or companies in general.  humans.
2026-05-31 09:32:04 <Ariadne> and in the interests of preserving that, i am telling you, and everybody else, where i stand on this, so that interested parties may either change course, or we can organize around building something more aligned with how the developers are feeling.
2026-05-31 09:35:00 <quinq> Being curious here, is the proposal public and accessible somewhere?
2026-05-31 09:35:09 <vmignot> Moreover, there is nothing wrong to lift it in the future if the situation with AI evolves. But I don't know why we should allow it by default.
2026-05-31 09:35:45 <vmignot> quinq: https://gitlab.alpinelinux.org/alpine/council/-/work_items/697
2026-05-31 09:35:50 <quinq> Thank you vmignot 
2026-05-31 09:36:58 <Ariadne> yes, i do not support just banning AI and being done with it.  obviously that is where pragmatism brings value.
2026-05-31 09:37:20 <quinq> I agree philosophycally with what Ariadne you are saying here
2026-05-31 09:37:31 <quinq> But is it something that can actually be enforced
2026-05-31 09:37:53 <Ariadne> in practice, nothing prevents somebody from copy and pasting from claude/chatgpt/whatever
2026-05-31 09:38:02 <Ariadne> the point is that it is a stated principle
2026-05-31 09:38:22 <Ariadne> in that our expectation is that participants will refrain from doing so
2026-05-31 09:38:23 <quinq> Maybe there's a tad more laxed way like what you submit is yours, you should try to not waste people's time and slop will be subject to arbitrary ban
2026-05-31 09:38:41 <quinq> Yeah Ariadne, I'm with you on that
2026-05-31 09:39:19 <quinq> But then maybe “ban” isn't enough to explain the actual harmful ways about it
2026-05-31 09:39:46 <quinq> Anyway, just my view, not trying to really debate your opinion
2026-05-31 09:43:08 <quinq> Could be a strong stance, but explaining that what matters is that one submitter did their homework, ncopa's points are technically good I think here, but they're just bullet points
2026-05-31 09:43:24 <quinq> I don't think “neutrality” would be a goal here though, because it isn't really
2026-05-31 09:43:33 <Ariadne> the reason I am particularly not in favor of this is because it is not aligned with what developers are saying.  it's not just about LLMs but the lack of alignment
2026-05-31 09:44:23 <quinq> And that submitting slop (either way) is considered offensive and antisocial and so prone to sanctions
2026-05-31 09:44:51 <Ariadne> sure but to me the idea that the council would go opposite of what the developers are discussing is jarring
2026-05-31 09:44:53 <quinq> Ariadne, that's a good point, but maybe it just needs a bit more brewing ;)
2026-05-31 09:44:57 <Ariadne> is my point
2026-05-31 09:45:07 <lotheac> for what it's worth i for one agree with ncopa
2026-05-31 09:45:10 <quinq> ah yeah, definitely
2026-05-31 09:45:16 <quinq> (Ariadne)
2026-05-31 09:45:59 <Ariadne> to be clear I don't think it is Alpine's place to fight commercial AI, but nobody is asking for that
2026-05-31 09:46:58 <quinq> It'll bankrupt itself anyway
2026-05-31 09:47:26 <Ariadne> in essence the reason I feel strongly about this is the disconnect between council and what developers are generally saying. 
2026-05-31 09:48:08 <quinq> Speaking out of my ass because I have no idea how it works, but maybe governence could be a bit remodeled?
2026-05-31 09:48:25 <quinq> Sounds wrong that there's a separation between a council and the developers it represents
2026-05-31 09:48:27 <Ariadne> I do not like LLMs but if it was clear that the majority wanted, I wouldn't care so much
2026-05-31 09:48:43 <quinq> At least there should be a percentage of voting coming from workers
2026-05-31 09:49:17 <sam_> fwiw I don't really believe the "avoiding arguments" thing is a real thing to worry about wrt banning LLMs. we have had essentially no cases of this (maybe one?) in gentoo 
2026-05-31 09:49:28 <sam_> it's one of those things which might be a theoretical concern but didn't end up being an issue in practice
2026-05-31 09:50:21 <quinq> Yeah, we can discuss it again when LLMs start having feelings
2026-05-31 09:50:33 <sam_> :)
2026-05-31 09:50:44 <sam_> also i think people who like LLMs generally see they're not welcome and don't even bother 
2026-05-31 09:50:57 <sam_> we made some people on HN mad the other day which feels like a win
2026-05-31 09:51:27 <quinq> :D
2026-05-31 09:59:22 <Ariadne> anyway I'm sure in the absence of an alpine fork that I can find some other operating system to participate in :) 
2026-05-31 10:13:44 <quinq> Naaa, wait for it, sure it'll come out to something sensible
2026-05-31 10:42:35 <f_> Yeah FWIW postmarketOS banning LLMs has not caused any issues
2026-05-31 11:09:13 <quinq> *so far after 5 days
2026-05-31 11:23:48 <f_> quinq: It's been more than 5 days :)
2026-05-31 11:24:45 <f_> it's been many months now
2026-05-31 11:26:13 <aelin> many is a bit of a stretch, it's been around 4
2026-05-31 11:29:46 <f_> many meaning "more than one"
2026-05-31 11:38:52 <f_> DylanVanAssche: maybe just disable tests on s390x
2026-05-31 11:38:59 <f_> or disable s390x entirely for now
2026-05-31 11:39:21 <invoked> beyond the time suck / global consequences of it all ... on a personal level, i don't want to work with people who use llms instead of reading/understanding things.
2026-05-31 11:47:47 <DylanVanAssche> [@_oftc_f_:matrix.org](https://matrix.to/#/@_oftc_f_:matrix.org) disabling s390x would affect iio-sensor-proxy. Maybe adjusting my testsuite (I'm maintainer) to skip this arch? I find it weird since the diff is only some paths in the meson.build which are changed compared to the version in Alpine. Not a single line of C code changed...
2026-05-31 11:48:23 <f_> DylanVanAssche: you can disable tests in the APKBUILD
2026-05-31 11:49:06 <ikke> DylanVanAssche: I can see if I can reproduce it
2026-05-31 11:49:07 <DylanVanAssche> Yes but I don't want that for all arches only for s390x then. Is that possible?
2026-05-31 11:49:13 <ikke> Yes
2026-05-31 11:50:01 <DylanVanAssche> Ah interesting! Wasn't aware of that. But if you manage to reproduce it and can share the meson error test log, that might be alreaduly sufficient to find the culprit. Thanks a lot!!
2026-05-31 11:52:03 <f_> DylanVanAssche: you can check if $CARCH is s390x and do options="$options !check"
2026-05-31 11:55:41 <ikke> DylanVanAssche: it reproduces, gathering the logs now
2026-05-31 11:56:40 <ikke> DylanVanAssche: any particular file I should get you?
2026-05-31 11:57:02 <ikke> The mentioned log file just contains the same that's already in the output
2026-05-31 11:57:58 <ikke> https://tpaste.us/jvPo
2026-05-31 11:58:13 <DylanVanAssche> There should be like a full log: https://gitlab.alpinelinux.org/dylanvanassche/aports/-/jobs/2375658#L520
2026-05-31 11:58:31 <ikke> That's in the paste
2026-05-31 11:59:17 <DylanVanAssche> Hmmm that's really weird... The output is totally different. Will need to analyze it then.
2026-05-31 11:59:57 <DylanVanAssche> Thanks for trying to get the logs! If I cannot figure it out, I will take the disable route. The library is only needed for ARM anyway
2026-05-31 12:00:23 <DylanVanAssche> On other platforms, it doesn't do anything anyway
2026-05-31 12:04:17 <ikke> Then it might make sense to disable the packages there completely indeed
2026-05-31 12:14:50 <Sertonix[m]> Does rebuilding the old version on s390x pass?
2026-05-31 12:15:20 <ikke> let me check
2026-05-31 12:16:07 <ikke> nope, also fails
2026-05-31 12:19:03 <Sertonix[m]> My first guess would be fortify-headers detecting OOB access or an issue in a makedependency. I unfortunatly don't have time to take a look right now.
2026-05-31 12:19:33 <ikke> If it's not relevant for s390x anyway, I'd suggest disabling the package
2026-05-31 12:24:13 <Sertonix[m]> Stub libraries are still useful for software portability
2026-05-31 12:26:42 <quinq> ok f_, was half joking about it, but good to fact it back ;)
2026-05-31 12:26:57 <f_> hehe :)
2026-05-31 12:34:42 <ncopa> I was kinda hoping we could get alpine 3.24 out before deal with the AI policy thing, but here we are
2026-05-31 13:27:25 <elly> you don't actually have to deal with it before 3.24, do you?
2026-05-31 13:45:47 <ncopa> I do sense a «if this is not handled in the next day the project will be forked 
2026-05-31 13:48:01 <ncopa> It is a very important topic for some
2026-05-31 13:48:22 <ncopa> Apparently more important than the 3.24 release
2026-05-31 13:49:32 <comk> ncopa think https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99502 can have a chance of progress? would really ike to see an upgrad eof it for 3.24 and that mr is just the first step of a few to get that package family straightened
2026-05-31 13:55:38 <ncopa> I can try have a look at it once the ci is green 
2026-05-31 13:55:56 <comk> once it stops building with distro llvm i thing it will also yield for example firefox unbuildable
2026-05-31 13:55:57 <comk> thx
2026-05-31 13:58:00 <markand> Ariadne, <3
2026-05-31 14:14:29 <invoked> ncopa: i doubt it is that imminent for alpine, but things in the world are def moving fast. i assume some share similar sentiments, we want to be part of communities where we don't have to talk to someone's agent, where people value this as a craft
2026-05-31 14:17:04 <invoked> either everyone feels uncomfortable around the elephant in the room (llm use makes me uncomfortable, and probably when i say mean things about llm use, it makes pro-ai people uncomfortable)
2026-05-31 14:17:31 <invoked> i think it's probably a more difficult path to try having it both ways
2026-05-31 14:38:03 <ollieparanoid1> while I also think this is a very important topic, I think everybody made their current position clear and adding more pressure to solve this now just adds more stress to the release process (which must already be rather stressful for ncopa)
2026-05-31 14:38:06 <ollieparanoid1> this is in turn probably also not helpful towards finding a good solution, so I would suggest continuing the discussion after the release is out
2026-05-31 14:38:23 <f_> +1 ^
2026-05-31 14:38:28 <WhyNotHugo> +1
2026-05-31 14:40:59 <elly> +1, that is what I was trying to get at originally - I think "we will sort it out after the 3.24 release, and if that is too slow for you we apologize" is a totally reasonable stance
2026-05-31 14:41:08 <elly> you are a volunteer and owe nobody anything
2026-05-31 14:48:04 <f_> Getting a release out is already stressful enough, I think there is no need to add more oil to the fire
2026-05-31 14:50:32 <comk> ollieparanoid1 ootl: what are positions?
2026-05-31 14:50:52 <ollieparanoid1> see https://gitlab.alpinelinux.org/alpine/council/-/work_items/697
2026-05-31 14:51:09 <comk> ty ollieparanoid1
2026-05-31 15:51:04 <elibrokeit> 05:29 <ncopa> one of the reasons I don't want do full pmOS style ban is that I believe that there exist good use of AI. That is why there are exceptions of those bans
2026-05-31 15:52:40 <elibrokeit> ncopa: if you believe that there exist good use of "AI", which from context I think means you accidentally typoed the term LLM but intend to roll with it anyway,... you should be able to clearly articulate what those good uses are when discussing the policy, in order to communicate effectively with the people who you collaborate with and will be affected by policy decisions that utilize 
2026-05-31 15:52:40 <elibrokeit> these "good uses" as justification
2026-05-31 15:58:10 <elibrokeit> 09:45 <ncopa> I do sense a «if this is not handled in the next day the project will be forked       It is a very important topic for some    Apparently more important than the 3.24 release
2026-05-31 15:59:45 <Sheila> I will note for the record that Adélie's genAI policy (https://www.adelielinux.org/policies/genai.html) requires strict transparency and that contributors understand what they are contributing and how it works.
2026-05-31 16:00:29 <Sheila> I feel this is one of the more sensible approaches, but I am probably biased as I helped formulate it.
2026-05-31 16:00:30 <elibrokeit> ncopa: I believe that this analysis is unkind towards the people you're falsely accusing. as far as I can tell from the timeline you've gotten honest answers ( == "people expressing their genuine feelings") to a comment *you* chose to make in the ticket at this time. nobody seems to be saying they have considered your existing comment to the last straw "and we're forking now", they are 
2026-05-31 16:00:30 <elibrokeit> just *continuing the discussion* that you started
2026-05-31 16:01:49 <elibrokeit> the point at which people may choose to "fork the project" is the point where *a decision is made* that they feel they can't live with. you haven't made a decision, you posted a continuation of an ongoing discussion expressing your feelings on the matter.
2026-05-31 17:19:48 <Ariadne> ncopa: yes, the project's leadership and founder making decisions that are not aligned with my perception of how the developers are feeling at large about any issue is more important to me than 3.24 release. 
2026-05-31 17:23:29 <Ariadne> I will just say it.  to me the expectation is that when the council is asked to do something it should generally be doing what the developers as a quorum want.
2026-05-31 17:25:47 <Ariadne> if the 3.24 release is most important then why propose taking an action that is opposite of that discussed in the ticket
2026-05-31 17:47:41 <Ariadne> like none of us are saying ban AI immediately or else.  you could have worked on the 3.24 release and nobody would be talking about forking Alpine now. 
2026-05-31 17:55:26 <Sheila> I feel like major decision-making should not occur near a release unless the decision(s) impact that release, or else it needs to be clear that they do not impact the release and the release is prioritised.
2026-05-31 18:09:46 <Ariadne> to be clear, my issue is about the disconnect between what developers have expressed in terms of preference and what was proposed by ncopa.
2026-05-31 18:10:18 <Sertonix[m]> [Dylan Van Assche](https://matrix.to/#/@dylanvanassche:dylanvanassche.be) Please disable the libssc tests on s390x for now. The bug is in py3-protobuf and when fixed the libssc successfully skips the tests like in the last sucessfull build.
2026-05-31 18:11:34 <DylanVanAssche> Sertonix Ah thanks a lot for the information, I wasn't aware of the `py3-protobuf` issue. Thanks!
2026-05-31 18:30:15 <Ariadne> and in general my issue is not just specifically the LLM issue. it is the dysfunctionality
2026-05-31 18:38:45 <Ariadne> I also speak up loudly because others don't feel they have the psychological safety to challenge ncopa because he is the founder of alpine. 
2026-05-31 18:41:29 <Ariadne> this is why it was inappropriate for ncopa to take the position of devils advocate here IMO.
2026-05-31 18:45:09 <shield[m]> Unreviewed ai content being contributed should be the only thing disallowed.
2026-05-31 18:46:53 <Ariadne> that is not an alpine that many of us want to be involved in
2026-05-31 18:48:06 <shield[m]> Almost every argument on either extreme of anything is wrong
2026-05-31 18:48:33 <shield[m]> if you use llms as they are now properly they are nothing more than a better search engine
2026-05-31 18:49:11 <Ariadne> ok
2026-05-31 18:51:24 <shield[m]> and how are you going to enforce this anyway, someone can build something with the heavy use of ai, and aslong as they looked with their own eyes and understood whats happening, cleaning up things here and there, how can you tell if the result is ai assisted
2026-05-31 18:51:47 <invoked> i love these "resistance is futile" arguments
2026-05-31 18:52:06 <shield[m]> What?
2026-05-31 18:52:42 <shield[m]> being on either side of the extreme is wrong
2026-05-31 18:52:58 <invoked> the way you phrased your open question about how this would be enforced implies that it can't be
2026-05-31 18:53:14 <shield[m]> well how would you enforce it
2026-05-31 18:53:41 <invoked> because prima facie good developers know it when they see it.
2026-05-31 18:54:00 <shield[m]> good developers can use ai
2026-05-31 18:54:32 <shield[m]> you are still under the assumption that ai assisted work is entirely made with ai with 0 human review
2026-05-31 18:54:48 <Sheila> shield[m]: who is under this assumption, exactly?
2026-05-31 18:55:03 <Sheila> please show where people are saying that that is happening.
2026-05-31 18:55:08 <skarnet> shield[m]: centrism is a fallacy, being "in the middle" does not automatically means you're right. If someone advocates killing nobody and someone else advocates killing 10 people, the reasonable solution is not killing 5 people
2026-05-31 18:55:38 <invoked> 
ACTION steps out of this and wishes godspeed on the new release.

2026-05-31 18:55:41 <skarnet> and I would say calling "extreme" the anti-AI sentiment is dishonest, because it is the majority opinion
2026-05-31 18:55:45 <shield[m]> skarnet: I said in this specific scenario, being on either extreme is wrong
2026-05-31 18:55:48 <Sheila> I don't think you're arguing in good faith, and I think asserting what people are saying, without sourcing instances of people saying that, is not helpful for demonstrating otherwise.
2026-05-31 18:55:56 <Ariadne> this is exhausting.  in the ticket there is a clear quorum of developers (e.g. the ones trusted to push packages to alpine) which want an LLM ban for now.
2026-05-31 18:56:05 <Sertonix[m]> shield: I think your opinion is clear and there is no new argument (compared to the gitlab issue). It's juat creating more noise
2026-05-31 18:56:15 <shield[m]> from what ive seen, if you use ai the exact same way we have been using google and stackoverflow for the past years, it results in the exact same or better workflow characteristics
2026-05-31 18:56:32 <shield[m]> Sertonix[m]: Thank you❣️
2026-05-31 18:57:57 <shield[m]> the inherent side effects of relying on these big llms however is a problem
2026-05-31 18:59:14 <Ariadne> which is why we want a ban for now
2026-05-31 19:03:49 <Ariadne> a ban for now is not a ban forever
2026-05-31 19:04:59 <shield[m]> thats fine, moratoriums are good
2026-05-31 19:08:03 <Ariadne> and I want other forms of automation that alpine has yet to implement such as automatic package upgrades where MRs are opened automatically for package upgrades
2026-05-31 19:27:27 <realroot[m]> tinydm 1.3.1-r0 won't work downgraded
2026-05-31 19:28:05 <realroot[m]> idk why wlan0: unavailable wifi (rtl8821ae) after updating
2026-05-31 19:30:05 <realroot[m]> kernel wasn't updated, v3.24
2026-05-31 19:37:47 <f_> realroot[m]: wdym?
2026-05-31 19:37:49 <f_> do you have some logs?
2026-05-31 19:40:40 <realroot[m]> rtl8821ae: Init MAC failed
2026-05-31 19:40:40 <realroot[m]> [NetworkManager] <error> [1780254238.8322] device (wlan0): Couldn't initialize supplicant interface: GDBus.Error:fi.w1.wpa_supplicant1.UnknownError: wpa_supplicant couldn't grab this interface.
2026-05-31 19:40:40 <realroot[m]> [NetworkManager] <info>  [1780254238.8323] device (wlan0): supplicant interface keeps failing, giving up
2026-05-31 19:46:22 <f_> does that have anything to do with tinydm?
2026-05-31 20:01:38 <Ariadne> realroot[m]: try downgrading linux-firmware-realtek
2026-05-31 20:04:24 <realroot[m]> it wasn't installed at all
2026-05-31 20:12:45 <realroot[m]> version from 3.23 didn't work
2026-05-31 20:13:55 <realroot[m]> [NetworkManager] <warn>  [1780258185.3988] device (wlan0): device not up after timeout!
2026-05-31 20:15:31 <realroot[m]> [kernel] [   18.433693] rtl8821ae: Init MAC failed
2026-05-31 20:42:24 <elibrokeit> shield[m]: the idea that a project should not have rules of behavior if the rules can't be enforced is sickening to me. this is just a code of conduct with different ideas from you about what constitutes polite conduct towards others, it is not a good look for you to be saying that the reason for getting rid of a code of conduct isn't because "I disagree with the definition of good 
2026-05-31 20:42:24 <elibrokeit> conduct" but rather "I disagree that it can be enforced therefore it should not be a policy so people don't have to break it"
2026-05-31 20:45:35 <jvvv> realroot[m]: realroot[m]: were there any other failures prior to the 'Init MAC failed' message? There are two main failure points for mac init for that driver; one has a debug message and the other just returns false.
2026-05-31 20:49:14 <jvvv> realroot[m]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c?h=v6.18.33#n916
2026-05-31 21:02:05 <iggy> is "ban all use of AI" the majority opinion or is this just a case of a vocal minority? I work with smart people and in the entire company, there's 1 "will never use AI" 2 "I haven't written code in months" and 20+ "it helps sometimes, but I like to keep my hands on the wheel"... Small sample size, but that generally seems to match what I see in other circles as well
2026-05-31 21:04:22 <iggy> if you look at something else controversial like Wayland, it seems pretty similar... a bunch of people at one end of the spectrum screaming that xorg will win in the end, a bunch of people at the other end of the spectrum yelling about how wayland is perfect and shouldn't be questioned, and way more people in the middle that just want to run some terminals and browsers with the
2026-05-31 21:04:24 <iggy> least amount of trouble
2026-05-31 21:22:47 <Sertonix[m]> How would you even define a majority in a world where identities can be created at little cost?
2026-05-31 21:29:19 <jvvv> realroot[m]: One of the module paramaters for the rtl8821ae is debug_level, default is 0 and range is 0-5.
2026-05-31 21:32:13 <skarnet> maybe, just maybe, *once* you should listen to the people who have been right about tech for 30+years
2026-05-31 21:32:28 <skarnet> but I understand that's not how the world works
2026-05-31 22:28:35 <elibrokeit> iggy: the scope of the discussion is a project-internal decision, so it isn't hard to get the opinions of "the exclusive club" affected. just ask every org member and every recent author of a merged PR, to share their opinion even if it is "my opinion is I don't care"
2026-05-31 22:28:53 <elibrokeit> people who don't care are obviously okay with a ban
2026-05-31 23:11:42 <Ariadne> at any rate from a practical standpoint, even if we wind up parting ways after the 3.24 release, i agree that we should focus on the 3.24 release for now.
2026-05-31 23:11:55 <Ariadne> because it will be cleaner to do so
2026-05-31 23:13:13 <Ariadne> but regardless i believe we need to make major changes to the governance, at the very least, we need something like Debian's general resolution process where we can collectively decide issues as a project.
2026-05-31 23:46:55 <iggy> obviously?
2026-05-31 23:50:40 <iggy> I would argue that the people who have an opinion and don't speak out are more interested in staying out of the crosshairs of the extremely vocal group which means they don't agree with that group
2026-05-31 23:51:17 <skarnet> you don't get to speak for the proverbial silent majority any more than anyone else
2026-05-31 23:52:00 <iggy> does the person I was responding to?
2026-05-31 23:52:17 <iggy> who said "obviously
2026-05-31 23:52:42 <skarnet> what she said was a truism, not an expression of the silent majority
2026-05-31 23:52:51 <skarnet> people who don't care are, by definition, okay with anything
2026-05-31 23:53:19 <el[m]1> iggy: okay but wayland hasnt been shown to do real harm, so i don't think it's similar in why people care. as much as otherwise there might similarly be a diverse group of opinions
2026-05-31 23:53:35 <comk> skarnet +1
2026-05-31 23:54:02 <iggy> it's some pretty big mental gymnastics to go from "people don't care" to "people are okay with an outright ban on something they have no opinion of"
2026-05-31 23:54:43 <skarnet> mental gymnastics? that is the definition of not caring
2026-05-31 23:54:59 <elibrokeit> definitionally, someone who thinks LLMs are awesome but doesn't want to use them out of fear of being in the crosshairs of the LLM haters, is okay with a ban because the ban doesn't affect them as they are already not using LLMs out of social fear, not governance fear 
2026-05-31 23:55:39 <comk> and in that hyppothetical scenario, sounds like desired outcome? 
2026-05-31 23:55:43 <iggy> it doesn't mean they aren't using them, it just means they don't talk about it
2026-05-31 23:55:49 <elibrokeit> and people who genuinely don't give a darn and their lack of giving a darn is their reasons for not replying, are okay with either outcome
2026-05-31 23:55:50 <comk> (fear aside. fear is the mind killer)
2026-05-31 23:56:15 <el[m]1> hm regarding wayland and harm, i suppose there has been some controversial debate regarding wayland and accessibilty now that i think about it. the situation seems to have improvement however. anyway, i dont think it's the same dimension of kinda somewhat objectively problematic
2026-05-31 23:56:26 <skarnet> think of the poor potential LLM users who would be oppressed by a ban in Alpine
2026-05-31 23:56:36 <skarnet> it's not like it's absolutely everywhere else
2026-05-31 23:57:39 <elibrokeit> I simply do not understand why the idea of asking people what their governance vote is, should be so controversial 
2026-05-31 23:58:14 <comk> el[m]1 thinking of this? https://nocoffei.com/?p=451 is but one example. many other workflows and platforms are still only working at all under Xorg and either broken or just not existing under Wayland
2026-05-31 23:58:30 <skarnet> elibrokeit: I don't disagree with that at all
2026-05-31 23:58:39 <iggy> nobody said don't vote, I merely said assuming how people would vote is people pushing their own agenda
2026-05-31 23:58:42 <elibrokeit> much less due to the theory that the silent majority aren't gonna vote at all because they're afraid someone is going to call them names on the Internet, and they want to remain in the community that they are terrified would do that 
2026-05-31 23:58:47 <comk> But I don't think that's "wayland harmful", it's "people depend on Xorg". different framing
2026-05-31 23:59:17 <el[m]1> comk: yes. i'm still hoping to this day that wayland will simply add an accessibility permission like e.g. android that allows wide-ranging access to windows and stuff
2026-05-31 23:59:23 <comk> simply dropping Xorg means dropping those users
2026-05-31 23:59:44 <comk> (im one of them btw)
2026-05-31 23:59:48 <elibrokeit> iggy: I'm saying that people who don't vote, or rather, vote "I decline to state an opinion, let me recuse myself", should be taken at their word and believed when they say they don't care
2026-05-31 23:59:55 <elibrokeit> I don't understand why this is controversial