2026-03-01 02:30:43 <jvvv> ncopa: I pushed !98219
2026-03-01 02:31:20 <jvvv> If you get a chance, maybe you could take a look
2026-03-01 04:54:39 <qaqland> !98138 always got sigsegv in rootbld and ci, however it tests well with 'abuild -r'
2026-03-01 04:54:57 <qaqland> are there any reasons or suggestions? :(
2026-03-01 05:08:00 <jvvv> qaqland: at quick glance, guessing it needs `options=net`
2026-03-01 05:37:41 <jvvv> qaqland: sorry, I see that is already there. Will look more closely
2026-03-01 06:21:01 <Saijin_Naib[m]> I accidentally took maintainership of parole on edge when I upgrade it to 4.20.0 and switched to meson packaging
2026-03-01 06:21:23 <Saijin_Naib[m]> What would be the proper "verb" for fixing it back to @ncopa?
2026-03-01 06:21:39 <Saijin_Naib[m]> community/parole: change maintainer or restore or fix or?
2026-03-01 06:59:20 <quinq> Saijin_Naib[m], “revert”
2026-03-01 07:07:49 <ikke> I'd say restore. Revert is generally used when reverting entire commits 
2026-03-01 07:09:06 <quinq> Yeah, that's the point :)
2026-03-01 08:18:26 <Saijin_Naib[m]> Sweet, thanks
2026-03-01 11:29:15 <omni> qaqland: it looks like I didn't reply to your question, perhaps I thought the reply ikke gave was sufficient, but I thought now that I should probably at least say something; it is not intentional and please open an issue or MR if you think it should change
2026-03-01 11:57:31 <f_> What's alpine's policy on packaging vibecoded software=
2026-03-01 12:26:20 <qaqland> omni: any context?
2026-03-01 12:30:25 <lotheac> f_: is that a real question? no policy exists
2026-03-01 12:30:45 <f_> lotheac: yes it's a real question
2026-03-01 12:30:51 <f_> ok thanks
2026-03-01 12:30:56 <lotheac> what's the context if i may ask?
2026-03-01 12:31:39 <f_> A cursory look at a merge request only to see that the software it is packaging, had a lot of its code written by claude
2026-03-01 12:31:41 <ikke> https://gitlab.alpinelinux.org/alpine/council/-/issues/697 discusses it
2026-03-01 12:34:14 <f_> ah thanks
2026-03-01 12:36:30 <lotheac> it discusses a related subject, but vibe-coded *contributions* are different from vibe-coded *software* that alpine would package/distribute
2026-03-01 12:37:09 <ikke> Both have been mentioned in that issue though
2026-03-01 12:37:32 <lotheac> true, it touches on too many topics at once
2026-03-01 12:37:59 <lotheac> on this particular question, i personally agree with ariadne https://gitlab.alpinelinux.org/alpine/council/-/issues/697#note_587029
2026-03-01 14:02:44 <Sheila> is there anyone I could hand nheko/mtxclient/coeurl over to? it's been A While since I cared about matrix, and honestly I should've divested maintainership a while ago.
2026-03-01 21:00:09 <omni> qaqland: your question the other day, about scenefx-dev
2026-03-01 21:30:41 <achill> Sheila: feel free to assign it to me :3
2026-03-01 21:57:53 <Sheila> 👍
2026-03-01 23:41:01 <Saijin_Naib[m]> @achill if you take over many more packages, it will need to be called Achill Linux 
2026-03-02 00:23:20 <skarnet> Nochill Linux
2026-03-02 00:39:00 <Saijin_Naib[m]> 🤣
2026-03-02 00:53:26 <Sheila> achill: all right, MR 98322.
2026-03-02 03:43:07 <qaqland> omni: I am just confused. imo it's upstream needs to be changed
2026-03-02 08:37:22 <qaqland> i think i can fix it like https://git.alpinelinux.org/aports/tree/community/wlroots0.19/APKBUILD#n39
2026-03-02 09:27:22 <raspbeguy> hello, could someone help me figuring out why this build doesn't pass? I have no go error message, so it's difficult to understand https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/2241566
2026-03-02 09:28:43 <lotheac> try removing -v from the go build command; it's likely there but you can't find it easily because of all the package names it prints
2026-03-02 09:41:16 <raspbeguy> I can do that but I'm not sure how that will help
2026-03-02 09:51:49 <raspbeguy> https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/2241590 not better
2026-03-02 11:50:02 <ikke> raspbeguy: from strace: writev(2, [{iov_base="cc: error: unrecognized command-line option '-Qunused-arguments'\n", iov_len=65}], 1) = 65
2026-03-02 11:50:24 <ikke> Not sure if that's _the_ issue, but most likely
2026-03-02 11:56:27 <ikke> although strace says the main process exited with 0
2026-03-02 12:34:02 <raspbeguy> the issue was a missing baslash, how silly is that
2026-03-02 12:46:55 <omni> qaqland: as in that a fix should be upstreamed (so that we get the .so symlink in the -dev subpackage) or as in that there is some other scenefx upstream that we need to change to?
2026-03-02 19:47:03 <Jarico[m]> Importing worked for the first time since the installation of the postmarketOS system.
2026-03-02 19:47:03 <Jarico[m]> Sadly, Importing Aegis .json files into GNOME authenticator doesn't work currently, this is also the case on Gentoo:
2026-03-02 19:47:03 <Jarico[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17985
2026-03-02 21:39:45 <pj> I'm trying to figure out the mess of udev rules that is happening
2026-03-02 21:39:56 <pj> libfido2-udev installs a rule that breaks pcscd from accessing yubikeys
2026-03-02 21:40:43 <pj> well, i had also other issue with pcscd but now it works :>
2026-03-02 22:21:01 <jvvv> I wonder if udev rule problems like that could be solved by having a packaging convention similar to what exists for nftables fragments... that they should not be installed into where they will loaded by default.
2026-03-02 22:24:58 <pj> i think in this case there is a conflict and potentially pcscd should be run with plugdev group?
2026-03-02 22:25:00 <pj> mayhaps
2026-03-02 22:25:17 <pj> like the libfido2 and pcscd should both have access
2026-03-02 22:42:17 <jvvv> I think I understand what you mean. I haven't messed with udev rules lately and personally it only comes up rarely. I do remember that device ownership has been an issue for me, just not recently. Perhaps I am not as adventurous as I used to be about the software I try out 
2026-03-02 22:46:59 <pj> well, I just switched from chimera to pmOS/alpine (hello again) and I'm moving all my configs, this is what irks me right now :P
2026-03-02 22:47:58 <pj> I have all my SSH and PGP keys via pcsc so it's quite important that it works
2026-03-02 22:51:23 <jvvv> got it, makes perfect sense
2026-03-03 08:28:43 <raspbeguy> Hello, can someone have a look on !98334 please
2026-03-03 08:53:44 <fabricionaweb> bot is 🛌
2026-03-03 09:30:07 <raspbeguy> then direct link https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98334
2026-03-03 11:10:37 <ncopa> statusupdate on python 3.14 upgrade: now py3-cffi fails. It seems like there is a 2.0.0 release with support for 3.14, but some tests are failing
2026-03-03 11:11:05 <ncopa> I also noticed that the python3-cffi package has been removed from fedora
2026-03-03 11:15:50 <ncopa> found a patch from upstream that fixes the tests
2026-03-03 17:46:11 <invoked> why did fedora remove it?
2026-03-03 17:46:49 <invoked> or is it two different packages
2026-03-03 18:47:28 <jvvv> ncopa: I think I found a possible fix for the py3-cffi test failures: https://github.com/python-cffi/cffi/commit/c36c02fa6f4f1d12a9cead81861c6f42af47da22
2026-03-03 18:48:36 <jvvv> I am setting up to test patch based on the commit
2026-03-03 18:53:43 <jvvv> test_parsing passes after applying patch for that commit
2026-03-03 18:54:21 <Ermine> I'm getting 'libfakeroot internal error: payload not recognized!' when running abuild
2026-03-03 18:54:44 <jvvv> ncopa: oh, you already said that... totally missed that... sorry for duplicating work
2026-03-03 19:11:51 <Ermine> Also abuild failed to make a subpkgdir
2026-03-03 19:12:32 <jvvv> Ermine: what aport?
2026-03-03 19:12:58 <andar1an> hello all. Wondering if someone can please point me to a package that handles wierd versions in APKBUILD. I am not sure how to work with following without messing with default unpack:  master-514-5792c66 is not a valid version
2026-03-03 19:13:07 <Ermine> jvvv: blktrace, but this is a new one and I didn't commit it yet
2026-03-03 19:15:50 <jvvv> Ermine: can you paste it?
2026-03-03 19:17:15 <Ermine> jvvv: https://0x0.st/P1kW.txt
2026-03-03 19:22:36 <Ermine> wait, i figured this one out: it is installing mans at wrong location
2026-03-03 19:22:43 <jvvv> Ermine: I think issue is that manpages are installed to /usr/man instead of /usr/share/man
2026-03-03 19:23:28 <Ermine> jvvv: yeah, figured this out
2026-03-03 19:23:47 <jvvv> yeah, sorry... I'm slow
2026-03-03 19:25:46 <andar1an> ah, it is the dash I think in versiom. How should one work with dashes for pkgver in APKBUILD? 
2026-03-03 19:26:04 <andar1an> just replace with a dot?
2026-03-03 19:28:10 <andar1an> or should I do something like: pkgver=517 pkgversub=ba35dd7 
2026-03-03 19:33:19 <Ermine> andar1an: i guess you want something like 517_gitba35dd7
2026-03-03 19:34:29 <andar1an> will that make it possible to grab the tar easily when the url format has a dash in release name? I guess that is grabbing by commit? 
2026-03-03 19:35:03 <andar1an> currently added an additional variable for minor portion and concatenating in string. Will try the git thing now. Thanks Ermine 
2026-03-03 19:35:16 <Ermine> andar1an: usually people add a variable like _gitcommit and use it in source to mark the commit
2026-03-03 19:35:38 <andar1an> ya, I have been doing that for submodules, but this is a release package 
2026-03-03 19:36:19 <andar1an> guess works the same haha. TY
2026-03-03 19:36:33 <Ermine> Would be nice if !97936 and !98429
2026-03-03 19:36:46 <Ermine> ... were reviewed
2026-03-03 20:57:42 <jvvv> To my eyes, both !97936 and !98429 look like they should be good to merge. I'm not a dev so I'm not sure that having a review from me would help move them forward.
2026-03-03 20:58:52 <ikke> !97936 !98429
2026-03-03 22:49:20 <elagost> If someone could look at !98150 it is ready to merge, the same version was merged into edge and it is a security update.
2026-03-03 22:53:17 <lotheac> done
2026-03-04 00:29:12 <Sertonix[m]> Ermine: The fakeroot errrors aren't new and don't seem to be fatal. Finding the cause would still be nice
2026-03-04 00:31:41 <jvvv> should `abuild deps` install $checkdepends as well as $makedepends ?
2026-03-04 00:36:04 <jvvv> nvrmnd, found it looking at abuild:calcdeps()
2026-03-04 04:38:51 <Saijin_Naib[m]> Anyone have bandwidth to review/merge some of my MRs?
2026-03-04 04:38:51 <Saijin_Naib[m]> !96672 !97218 !96398 !96397 !97494 !97229 !97224 !96399 !97292 !98141
2026-03-04 04:43:59 <Saijin_Naib[m]> Haha, Biswa96, Not all, any one that looks correct/easy. Like a few are bumps of other folks' stuff, so maybe that as a start?
2026-03-04 05:45:07 <Saijin_Naib[m]> Can someone help me suss this fail on s390x out?
2026-03-04 05:45:07 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/Saijin-Naib/aports/-/jobs/2244435
2026-03-04 05:45:18 <Saijin_Naib[m]> It passes on all the other runners, so it seems arch-specific
2026-03-04 05:49:09 <Saijin_Naib[m]> looks like sigsev 11 is memory access violation... but only under s390x?
2026-03-04 06:01:31 <ikke> s390x is big-endian, could have to do with that
2026-03-04 06:15:18 <Saijin_Naib[m]> Ahh, hmm, okay. Is that the only arch we have in our runners that is big-endian?
2026-03-04 06:18:49 <ikke> yes. Not saying that is necessarily the reason, just one difference
2026-03-04 06:19:28 <Saijin_Naib[m]> It seems salient for sure. I'm not sure moodbar was developed/tested against s390x, so it may well misbehave there
2026-03-04 06:31:03 <qaqland> omni: at first I thought the changes should be made upstream in scenefx, but later I found its meson.build basically comes from wlroots.
2026-03-04 09:34:58 <ncopa> py3-pytest-benchmark fails now
2026-03-04 12:33:58 <ncopa> whee! im done with python 3.14 rebuilds in main/
2026-03-04 12:34:14 <ikke> nice
2026-03-04 12:43:32 <pj-> ptrc: fabled: do you have any idea how to deal with yubikey udev rules? pcscd needs rule "/usr/lib/udev/rules.d/92_pcscd_ccid.rules is owned by ccid-1.7.0-r0" which gives access for pcscd group
2026-03-04 12:44:12 <pj-> libfido2-udev brings in rule "usr/lib/udev/rules.d/69-yubikey.rules" that assigns yubikeys to plugdev
2026-03-04 12:46:08 <ncopa> llvm15	llvm16	llvm18	llvm19
2026-03-04 12:46:39 <ncopa> llvm20 llvm21 llvm22
2026-03-04 12:46:51 <ncopa> we have 7 different versions of llvm
2026-03-04 12:48:23 <ikke> yup..
2026-03-04 12:49:03 <ikke> llvm15 -> ghc
2026-03-04 12:49:08 <ikke> llvm16 -> postgres16
2026-03-04 12:49:24 <ikke> llvm18 -> ghc-loongarch
2026-03-04 12:50:17 <ncopa> lets get rid of llvm 19?
2026-03-04 12:50:31 <ncopa> and 20?
2026-03-04 12:50:31 <ikke> ccls, ldc
2026-03-04 12:52:29 <ikke> dotnet8, dotnet9, bcc, bpftrace, wasm-micro-runtime, zig
2026-03-04 13:02:12 <fabled> pj-: sounds problematic. So pcscd rule takes affect? Maybe instruct users needing yubikey access to be added to pcscd group?
2026-03-04 13:02:28 <fabled> Alternatively file issue upstream to pcscd and yubikey
2026-03-04 13:03:01 <pj-> well, actually libfido2-udev takes over the ccid rules
2026-03-04 13:03:18 <pj-> yubikey ends up owned by plugdev group
2026-03-04 13:03:27 <pj-> that breaks pcscd
2026-03-04 13:03:59 <pj-> I'm trying yubikey-manager now and that seems to also not work, at least with deleted libfido2 rules
2026-03-04 13:05:25 <pj-> ykman and piv-tool (from opensc) can see the yubikey (when running as me)
2026-03-04 13:07:09 <pj-> pcscd runs as u=pcscd,g=pcscd, if the device bus was owned by plugdev and pcscd part of plugdev, would that work?
2026-03-04 13:08:01 <pj-> looks at my groups: uid=10000(user) gid=10000(user) groups=10000(user),10(wheel),18(audio),23(input),27(video),28(netdev),102(plugdev)
2026-03-04 13:08:30 <fabled> If it retains all groups. Then yes. Adding pcscd to plugdev would work too
2026-03-04 13:09:03 <fabled> Then the plugdev use rule would need to be renamed to sort after pcscd rule so that yubikey actually gets plugdev group 
2026-03-04 13:09:23 <pj-> hm? yubikey gets plugdev
2026-03-04 13:09:40 <pj-> it is an earlier rule but it does end up with plugdev
2026-03-04 13:17:25 <pj-> would it also be better to change ccid rules to use plugdev instead of pcscd
2026-03-04 18:08:51 <Ariadne> is anyone else seeing https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/5151 upon upgrade to pipewire 1.6.0?
2026-03-04 18:20:00 <Ariadne> Saijin_Naib[m]: i am considering starting an alpine multimedia packaging team, if that interests you?
2026-03-04 18:21:52 <Saijin_Naib[m]> Yeah, provisionally! I'm not self-sufficient yet, but I daily Alpine on desktop for me and my family, so I have a vested interest in making it fun and comfortable
2026-03-04 18:22:10 <Saijin_Naib[m]> What do you need from me in that role?
2026-03-04 18:27:55 <Saijin_Naib[m]> Anyone have local "desktop" s390x?
2026-03-04 18:28:28 <Saijin_Naib[m]> moodbar for Exaile segfaults under s390x with gst-launch-1.0 invocation, and exaile/moodbar dev indicated it may mean a fault in GST under s390x itself
2026-03-04 18:28:39 <pj> afaik the only people who had s390x was IBM and Ariadne :>
2026-03-04 18:28:55 <Saijin_Naib[m]> I can't test locally, and I only came across this issue due to the moodbar testsuite failing CI
2026-03-04 18:28:56 <Ariadne> s390x cannot do desktop
2026-03-04 18:28:58 <lotheac> it's an ibm mainframe type thing, "desktop" may not really exist
2026-03-04 18:29:05 <Saijin_Naib[m]> Ahhh, okay
2026-03-04 18:29:14 <Ariadne> like i guess you can do like a VNC session or whatever
2026-03-04 18:29:16 <Ariadne> but... why
2026-03-04 18:29:17 <pj> I'm surprised there are still desktop packages built for s390x?
2026-03-04 18:29:19 <Saijin_Naib[m]> So GST being borked is more of a non-issue?
2026-03-04 18:29:30 <pj> wasn't it established to remove those
2026-03-04 18:29:32 <Saijin_Naib[m]> https://github.com/exaile/moodbar/issues/15
2026-03-04 18:29:32 <ikke> '
2026-03-04 18:29:54 <pj> just disable s390x
2026-03-04 18:29:56 <pj> no one will cry
2026-03-04 18:30:07 <Saijin_Naib[m]> Haha, I did for moodbar
2026-03-04 18:30:20 <Saijin_Naib[m]> But given the above, should I skip s390x for any aport I maintain that is a GUI/desktop thing?
2026-03-04 18:30:28 <Saijin_Naib[m]> Just leave the CLI tools enabled?
2026-03-04 18:31:23 <pj> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/54
2026-03-04 18:32:01 <pj> tl;dr it's up to you
2026-03-04 18:32:45 <invoked> i just bumped one of my desktops to edge and basic pipewire things seem fine. i'm heading out so will try to test a video call or something later.
2026-03-04 18:33:25 <Saijin_Naib[m]> I'm on pipewire 1.6.x as well, I'll test as well later
2026-03-04 18:33:30 <Saijin_Naib[m]> Bluetooth and audio works fine
2026-03-04 18:34:45 <pj> unless there have been some updates today to pw, I'm listening to music and watching youtube constantly without issues 
2026-03-04 23:21:17 <omni> looks like community/clang-rtlib was omitted in !98296
2026-03-04 23:30:14 <omni> oh, there's !98504
2026-03-05 06:52:29 <Saijin_Naib[m]> Anyone can review !97637
2026-03-05 06:52:52 <Saijin_Naib[m]> This is a major upgrade/rework of our VTK package, de-vendoring almost everything and expanding supported formats and features majorly
2026-03-05 06:53:09 <Saijin_Naib[m]> This was way over my head, but someone from manyfold was nice enough to pick it up and take it way further
2026-03-05 06:53:41 <ikke> There's a conflict that needs to be fixed
2026-03-05 06:53:51 <Saijin_Naib[m]> their F3D aport also depends upon this being merged, and in turn, my Exhibit aport requires VTK upgrade and F3D to be merged (Exhibit is a GTK user-friendly 3D data viewing program based upon F3D)
2026-03-05 06:54:25 <Saijin_Naib[m]> How can I see what that is? In the CI logs?
2026-03-05 06:55:06 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97637/diffs
2026-03-05 06:55:12 <ikke> Rebasing would show the actual conflict
2026-03-05 06:56:34 <Saijin_Naib[m]> I'll ping them
2026-03-05 06:57:19 <Saijin_Naib[m]> Thanks as ever, ikke
2026-03-05 07:40:21 <Saijin_Naib[m]> Anyone want to take over my kew aport? They're vibecoding now, so I want nothing to do with it
2026-03-05 07:41:25 <quinq> Which one?
2026-03-05 07:45:02 <Asmadeus> I assume testing/kew
2026-03-05 07:45:04 <Saijin_Naib[m]> Same goes for my deadbeef aports which are not merged yet
2026-03-05 08:56:18 <ncopa> i dont think there are any clang rtlib 22 upstream sources yet
2026-03-05 08:57:02 <ncopa> it seems like afl++ tests deadlocks
2026-03-05 09:05:23 <omni> ncopa: isn't it provided by compiler-rt, subpackage of llvm-runtimes?
2026-03-05 09:11:00 <ncopa> https://github.com/llvm/llvm-project/releases/download/llvmorg-22.1.0/compiler-rt-22.1.0.src.tar.xz gives 404
2026-03-05 09:22:28 <omni> yes, but https://git.alpinelinux.org/aports/tree/main/llvm-runtimes/APKBUILD#n134
2026-03-05 09:34:15 <Saijin_Naib[m]> @Asmadeus yeah, sorry. Should have been more specific
2026-03-05 09:53:05 <ncopa> hum, ok
2026-03-05 09:53:18 <ncopa> so we dont really need the clang-rtlib package anymore?
2026-03-05 09:55:51 <ncopa> there are 1531 packages to rebuild with python 3.14
2026-03-05 09:56:39 <omni> only if things depending on it cannot build with latest in their $_llvmver
2026-03-05 10:03:43 <achill> ncopa: they dont package per-project specific tarballs anymore
2026-03-05 10:04:28 <achill> https://discourse.llvm.org/t/rfc-do-something-with-the-subproject-tarballs-in-the-release-page/75024
2026-03-05 10:08:12 <ncopa> ok. so maybe we need build llvm/clang/etc in one APKBUILD and split subpackages from that?
2026-03-05 10:08:23 <achill> no
2026-03-05 10:08:32 <achill> i mean this is the recommended way but we dont have to
2026-03-05 10:08:54 <achill> you can just cd into the project-basedir in the generic tarball
2026-03-05 10:12:27 <ncopa> we need to retire py3-nose
2026-03-05 10:12:45 <ncopa> https://fedoraproject.org/wiki/Changes/RetirePythonNose
2026-03-05 10:12:53 <ncopa> does not work with python 3.14
2026-03-05 10:13:25 <ikke> oof
2026-03-05 10:14:31 <ikke> There is apparently nose2?
2026-03-05 10:15:30 <ikke> https://github.com/nose-devs/nose2
2026-03-05 10:15:35 <ikke> It's in the same namespace
2026-03-05 10:15:59 <ncopa> no idea
2026-03-05 10:17:56 <ncopa> i figured out how to fix afl++ deadlock with python 3.14
2026-03-05 10:22:49 <ncopa> re py3-nose, I would expect most project has already removed it as dependency
2026-03-05 10:23:19 <omni> we have py3-nose2 (it and py3-nose are currently unmaintained), not too many aports seem to depend on py3-nose
2026-03-05 10:23:35 <ncopa> we should clean it up
2026-03-05 10:23:42 <ncopa> i dont think its too much work
2026-03-05 10:23:46 <ikke> ~20 packages left
2026-03-05 10:24:08 <ncopa> i built py3-numpy here now with python 3.14. I simply removed py3-nose from deps
2026-03-05 10:24:19 <skarnet> it was too much on the nose
2026-03-05 10:24:35 <omni> oh
2026-03-05 10:24:41 <omni> badum
2026-03-05 10:24:56 <skarnet> tsss
2026-03-05 10:25:16 <achill> ncopa: yeah most packages probably moved away anyway
2026-03-05 10:26:36 <omni> it's easy to skip looking at changes to pyproject.toml, requirements.txt or similar, what could be removed instead of just what needs to be added
2026-03-05 10:27:54 <ncopa> we also have this https://gitlab.alpinelinux.org/alpine/aports/-/issues/18017
2026-03-05 10:28:02 <ncopa> its simple job. just a bit time consuming
2026-03-05 10:28:15 <ncopa> and right now time is not something I have a lot of
2026-03-05 10:28:45 <ikke> Maybe in the future? :)
2026-03-05 10:29:09 <ncopa> heh
2026-03-05 10:29:31 <ncopa> mio has also a list of things that needs to be fixed for python 3.14: https://dev.alpinelinux.org/~mio/py3.14/community.py3.errors.txt
2026-03-05 10:30:19 <ncopa> i have my python-3.14 branch here: https://gitlab.alpinelinux.org/ncopa/aports/-/tree/python-3.14?ref_type=heads
2026-03-05 10:30:57 <achill> in a few weeks my exams are over, so i can help you then
2026-03-05 10:31:34 <ncopa> i rsync built packages to https://dev.alpinelinux.org/~ncopa/py3.14/
2026-03-05 10:32:14 <ncopa> so if anyone wants to help:
2026-03-05 10:32:35 <ncopa> 1) try prioritize py3-* MRs
2026-03-05 10:32:48 <ncopa> 2) help with the py3-nose removal
2026-03-05 10:33:02 <ncopa> 3) help with the py3-future removal https://gitlab.alpinelinux.org/alpine/aports/-/issues/18017
2026-03-05 10:33:38 <ncopa> 4) help with build fixes of python 3.14 packages that is known to fail: https://dev.alpinelinux.org/~mio/py3.14/community.py3.errors.txt
2026-03-05 11:01:05 <Sertonix[m]> ncopa: I already removed a lot of py3-nose usage. Should I create a tracking issue?
2026-03-05 11:35:09 <jvoisin> it would be nice to have a system to track those issues indeed
2026-03-05 11:35:17 <jvoisin> py3-nose, as well as py3-six, and so one
2026-03-05 11:35:34 <jvoisin> "low hanging fruits if you want to contribute to Alpine and achieve immortal fame and glory"
2026-03-05 11:55:57 <omni> and the issue tracker isn't such a system? (I see you opened #17822)
2026-03-05 11:57:39 <omni> Sertonix[m]: I don't think you need to ask wether you should create such an issue =)
2026-03-05 11:58:59 <jvoisin> omni: yes, but it's a bit inconvenient. I guess it could be improved with some tagging, like "meta issue", "good first issue" and whatnot
2026-03-05 12:11:29 <omni> "Python 3.14", perhaps, or some milestone
2026-03-05 14:49:52 <ayakael> I got django52 working !98489 and rebuilt all downstream packages. On riscv64, CI is too slow to consistently pass all tests due to timeouts.
2026-03-05 15:29:19 <ayakael> ncopa: copy that, plan to have time tomorrow to contribute
2026-03-05 15:36:56 <achill> ayakael: thanks!!
2026-03-05 15:40:42 <ayakael> ncopa: would you like me to take maintainership of django? I can bring it under my wing.
2026-03-05 17:12:33 <kunkku> py3-django-oscar fails to build because the source package on distfiles.a.o seems corrupted
2026-03-05 17:34:30 <ikke> Or upstream recreated the archives 
2026-03-05 17:37:31 <ikke> Renamed the file
2026-03-05 20:01:08 <kunkku> the upstream checksum has not changed
2026-03-06 07:21:51 <ncopa> ayakael: im very grateful if you can take care of django. Thanks!
2026-03-06 09:26:55 <achill> be prepared for awesome go 1.26 rebuilds :)
2026-03-06 10:09:28 <lotheac> i need to find time to fix the go1.26 vector insn issue on riscv64 (particularly nor-ci-1)... without that i imagine go1.26 rebuilds will be painful
2026-03-06 10:09:36 <lotheac> unless you skip ci
2026-03-06 10:09:54 <lotheac> i've just been swamped this week :/
2026-03-06 10:11:19 <lotheac> maybe next week ... fingers crossed
2026-03-06 11:26:22 <jvoisin> speaking of Python upgrade, Canonical is also having a lot of fun as well doing it: https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#python3-defaults
2026-03-06 15:19:04 <invoked> Q: are we going to take a position on ai stuff?  eg  https://wiki.gentoo.org/wiki/Project:Council/AI_policy
2026-03-06 15:19:27 <ikke> invoked: https://gitlab.alpinelinux.org/alpine/council/-/issues/697
2026-03-06 15:19:35 <invoked> thanks
2026-03-06 16:38:50 <ikke> Anoying, the docker-registry test suite (abuild check) can only be run once, after that, it fails for some reason that it can no longer find a main module...
2026-03-06 16:51:58 <ikke> oh, build has to run for check to work :/
2026-03-06 17:23:34 <Saijin_Naib[m]> Gentoo has a solid policy there. I like it.
2026-03-06 17:52:07 <Ariadne> ikke: i think 697 does not answer the question on whether it is *legal* for us to ingest upstream LLM-generated code.  i have no desire to police what upstreams do, but it would be nice for *somebody* to issue some legal guidance saying whether it is legal or not.
2026-03-06 17:52:55 <ikke> Ariadne: yes, understood
2026-03-06 17:53:29 <ikke> That ticket is whether we allow contributions generated by LLM
2026-03-06 17:53:35 <ikke> issue*
2026-03-06 17:58:59 <Ariadne> yes, i created 703 for it
2026-03-06 17:59:06 <Ariadne> my point is that we have to consider both...
2026-03-06 21:56:17 <WhyNotHugo> Odd timing to ask, but, can we merge !97023? It's been around in a pretty clean state for a few weeks now.
2026-03-06 22:13:55 <ayakael> ncopa: done https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98630
2026-03-07 00:54:47 <ayakael> update: I did not have time to contribute to the py3.14 update. I will try to help wednesday. at least django5.2 is done :)
2026-03-07 09:31:49 <maribu> The CI for the update of ghidra reported a build failure (see https://gitlab.alpinelinux.org/maribu/aports/-/jobs/2249639). However, the package was actually build. I don't quite understand what the issue there is. There is one unexpected "rm: can't remove '/builds/maribu/aports/testing/ghidra/src': Directory not empty". Might that be the culprit?
2026-03-07 10:34:13 <Sertonix[m]> It is a bit odd that there os no previous error message from rm. If the issue is reproducible you could try adding cleanup_srcdir() { strace -- rm -rf "$srcdir"; } to see which syscalls are failing.
2026-03-07 11:12:38 <maribu> OK, the issue was not reproducible. A rerun succeeded.
2026-03-07 11:14:33 <quinq> When in doubt, reboot and forget about it until next time
2026-03-07 12:03:29 <maribu> quinq: Reminds me a bit of a catch phrase of "The IT Crowd" :)
2026-03-07 12:04:33 <quinq> off an on again ;)
2026-03-07 13:59:05 <ikke> I have seen a similar error before
2026-03-07 23:55:53 <aelin> regarding the aws-lc build errors, building with clang mitigates the issue, perhaps we could just do that for now?
2026-03-07 23:56:25 <aelin> something seems to be quite broken in g++ there if i'm not mistaken, the sizes it infers just don't make sense to me
2026-03-08 01:33:00 <ayakael> py3-click-repl fixed for py314: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98671
2026-03-08 02:01:47 <p_6f3Ik7Suw> ncopa: would you be so kind and enable CONFIG_BPF_LSM=y
2026-03-08 02:01:55 <p_6f3Ik7Suw> in your fine kernel
2026-03-08 02:39:59 <ayakael> py3-tika fixed as well: !98694
2026-03-08 08:27:37 <ncopa> p_6f3Ik7Suw: can you please create an issue in gitlab, with label "kernel" and explain why?
2026-03-08 11:48:51 <p_6f3Ik7Suw> ncopa: thx. will do
2026-03-08 13:30:12 <p_6f3Ik7Suw> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/18029 - am not allowed to set the kernel label.
2026-03-08 13:34:53 <f_> I think you need to be "Guest" to do that
2026-03-08 13:42:35 <p_6f3Ik7Suw> how do i become guest?
2026-03-08 15:50:39 <Biswa96[m]> would anyone like to review this MR please? !98094
2026-03-08 15:53:06 <f_> Biswa96[m]: can't hit approve nor merge but it looks good to me
2026-03-08 15:53:22 <f_> (approve requires Guest, merge requires being an alpine developer :p)
2026-03-08 16:00:18 <Biswa96[m]> ok, I forgot about that MR and just got the email from a merge conflict :-)
2026-03-08 18:12:50 <elagost> would anyone be interested in reviewing !98455 ? It's an apk hook for btrfs snapshots. It would be neat if it could put these snapshots in the grub menu, too, but I've not got that far yet
2026-03-08 20:40:11 <Saijin_Naib[m]> Can someone review !96672? Alpine-qa-bot is yelling at me to make moves
2026-03-08 20:40:50 <Saijin_Naib[m]> I would really appreciate someone knowledgeable checking it, since libpeas touches a number of aports, but in local testing it fixed rhythmbox and pitivi which have been broken for a year or so on edge
2026-03-08 20:43:57 <ikke> Saijin_Naib[m]: These packages are maintained by 2 different persons. They would need to ack it
2026-03-08 20:44:19 <Saijin_Naib[m]> Okay. I can't assign anyone, so do you mind assigning them?
2026-03-08 20:44:59 <f_> you can't assign more than one person in gitlab-ce
2026-03-08 20:45:16 <f_> you can in gitlab-EE
2026-03-08 20:45:18 <Saijin_Naib[m]> haha, nice. I can't assign anyone because of my role, so :P
2026-03-08 20:45:39 <Saijin_Naib[m]> Do I just @ them in a comment on the MR?
2026-03-08 20:46:50 <Saijin_Naib[m]> Who is Krassy Boykinov on Gitlab?
2026-03-08 20:57:03 <ikke> chereskata
2026-03-08 20:59:53 <Saijin_Naib[m]> thank you
2026-03-09 01:33:51 <jvvv> ayakael: Sorry about py3-astor. My commit message should have been about fixing build with py3.14 and maybe that could have saved you some work.
2026-03-09 01:40:42 <Saijin_Naib[m]> Are gitlab @ accounts like, federated or only visible to guests if we interact directly?
2026-03-09 01:40:53 <AFdev[m]> Hello.
2026-03-09 01:40:53 <AFdev[m]> If you're interested in long-term collaborating, feel free to reach out to me. 
2026-03-09 01:40:53 <AFdev[m]> I’m a full stack and AI developer currently seeking a new project opportunity.
2026-03-09 01:40:53 <AFdev[m]> I hope you're doing well. 
2026-03-09 01:40:53 <AFdev[m]> Looking forward to hearing from you!
2026-03-09 01:41:27 <Saijin_Naib[m]> I could not find chereskata until I opened an MR to update Flare and they got assigned to my MR. After that, I can search for and find them
2026-03-09 08:06:40 <ikke> AFdev[m]: We don't appreciate this kind of spam here
2026-03-09 08:12:22 <PureTryOut> They're a bot, no worth replying
2026-03-09 14:31:28 <macmpi> Hi, it seems new aports MR approval rate in testing repo has been quite low lately: understand resources are scarce and reviewers must be quite busy with other critical stuff. Is there some sort of expected schedule for some batch reviews on backlog before next release?
2026-03-09 14:36:49 <ncopa> i think we need py3-legacy-cgi package
2026-03-09 14:44:56 <ncopa> for py3-webob
2026-03-09 16:33:57 <ayakael> macmpi: I've been wondering the same thing. There doesn't seem to be a policy other than « we'll get to it when we do », which currently means new aports aren't processed for a long time. This adds to the fact that, for every new aports, there are more future update MRs to process. With the gradual rise of open MRs (was it 350 just a year or two
2026-03-09 16:33:57 <ayakael> ago) to 1000 now, I see a scaling problem.
2026-03-09 16:36:01 <ayakael> jvvv: Yeah, I would've appreciated a ref to the py314 issue, else I would've left it to you.
2026-03-09 16:38:12 <ayakael> I have a bunch of aports in my staging repo (see https://ayakael.net/forge/ayaports/src/branch/edge/user) and used by my coop ilot (see https://forge.ilot.io/ilot/iports/src/branch/v3.23/ilot, notably authentik) that I'd like to eventually upstream, but for lack of clear policy on this, I've postponed.
2026-03-09 16:39:54 <ayakael> jvvv: ahh I see you did ref, but didn't post a message in the issue, my bad, I should've seen.
2026-03-09 19:22:30 <jvvv> ayakael: I've seen how you post more directly to the issue. I think that is good and will emulate that going forward.
2026-03-09 19:24:12 <ikke> One thing that concerns me a lot (and something I directly have to deal with) is the growth of our repos
2026-03-09 20:40:40 <Ariadne> ikke: git or package
2026-03-09 20:40:50 <ikke> package
2026-03-09 20:41:35 <Ariadne> i do ponder if alpine packages too many things that would be better suited by flatpak, etc
2026-03-09 20:45:02 <vlt> Hello everyone :)  I came here to ask how to search for why xelatex (from texlive-xetex) takes consistently about 25 % more time on Alpine Linux than on Debian, for example, but having skimmed the irc logs I don’t think anyone even wants to know :D (except maybe maribu)
2026-03-09 20:46:11 <vlt> (I’m sorry if I caused some serious PTSD by even mentioning it.)
2026-03-09 20:46:13 <Ariadne> you are comparing two entirely different operating systems
2026-03-09 20:46:50 <vlt> Ariadne: Yes, I know. I think I was just curious.
2026-03-09 20:47:27 <Ariadne> there are too many variables
2026-03-09 20:47:28 <maribu> Are the same versions of TeXlive being used on both systems?
2026-03-09 20:47:40 <ikke> Could be a number of factors even
2026-03-09 20:48:50 <Ariadne> however, if i were to guess, AFAIK TeX uses a lot of small allocations, and this is probably leading to suboptimal from musl's malloc.  linking TeX against mimalloc would probably optimize it.
2026-03-09 20:49:19 <Ariadne> i am also looking into adding musl-mimalloc package which replaces musl's malloc with mimalloc (as done in chimera)
2026-03-09 20:49:34 <maribu> I recall having seeing some "creative" use of sscanf as backbone for the parsing in some of the TeX tools. A few years ago a certain corner cause triggered a bug in musl's sscanf implementation, which quickly got fixed. Someone wanting to implement a fast parser won't use sscanf. And someone implementing a sane and lean sscanf won't assume it to be used for performance critical stuff.
2026-03-09 20:50:51 <maribu> My honest advice if you care for productive use of a type setting environment: Use typst instead.
2026-03-09 20:51:25 <vlt> maribu: https://gist.github.com/vlt/afee3ff70073ab64f1c0ab6ecb00fa30
2026-03-09 20:51:59 <ikke> ah pi-ver
2026-03-09 20:53:02 <invoked> ikke: is the bottleneck on the infra side?
2026-03-09 20:53:29 <invoked> (re: repo growth)
2026-03-09 20:53:58 <ikke> Yes, builder storage, dl-master storage, t1-mirror storage, 3rd-party mirror storatge
2026-03-09 20:54:00 <ikke> storage*
2026-03-09 20:54:01 <vlt> 
ACTION is having a look at typst

2026-03-09 20:54:17 <invoked> pointing people to flatpak seems gross, though
2026-03-09 20:55:05 <ikke> And the quick dismissal of "storage is cheap" is even less true nowadays than before
2026-03-09 20:55:28 <maribu> vlt: The difference in performance is more likely to be caused by the scripts provided by texmf-dist, than by texlive-bin.
2026-03-09 20:55:41 <invoked> maybe we need to get better at pruning
2026-03-09 20:56:53 <invoked> ie, the feedback loop of whether some packages are meaningful enough to the community to have in there.
2026-03-09 20:57:12 <invoked> but i have no idea how we'd accomplish that.
2026-03-09 20:59:18 <ikke> And it would be quite a massive pruning to have effect
2026-03-09 20:59:59 <maribu> vlt: A word of warning: I personally have stopped using LaTeX almost two years ago, so I'm not too motivated on spending time on LaTeX these days. I fear I won't be able to help you due to lack of time (and being honest, also lack of motivation).
2026-03-09 21:02:00 <vlt> maribu: No worries! Having read about what a mess tex* seems to be, I don’t really care much either :D
2026-03-09 21:10:57 <ikke> repo sizes per release: https://tpaste.us/YqBZ 
2026-03-09 21:11:29 <ikke> 7.5G for 3.4, 99G for 3.23. ~10x increase
2026-03-09 21:12:07 <ikke> And that's just for one release
2026-03-09 21:12:13 <ikke> one arch&
2026-03-09 21:12:42 <invoked> yeah, oof.
2026-03-09 21:14:00 <invoked> some hard decisions need to be made, sounds like
2026-03-09 21:14:55 <ikke> btw, this ties directly in the remarks about open MRs for new packages
2026-03-09 21:15:26 <invoked> pruning community seems like a first step though. alpine would have to get more opinionated.
2026-03-09 21:15:55 <jvoisin> there are also a bunch of oudated libraries without any reverse dependencies that could be pruned
2026-03-09 21:17:45 <jvoisin> also, maybe releases like 3.4 should be removed form the mirrors (https://alpinelinux.org/releases/ end of support in 2018, ~8 years ago)
2026-03-09 21:21:16 <ikke> Possibly, but I think we want to at least keep these repos somewhere, would be a pitty to permanently delete those files
2026-03-09 21:21:24 <ikke> and it does not add up to a significant win
2026-03-09 21:22:11 <pj> what's the comparison of testing vs comm vs main
2026-03-09 21:23:45 <ikke> pj: https://tpaste.us/YqBZ shows it
2026-03-09 21:23:48 <jvoisin> ikke: throw them at archive.org?
2026-03-09 21:24:51 <ikke> We would need to delete ~13 older releases to get the equivalent of 1 new release
2026-03-09 21:25:27 <pj> Yeah, I think community needs to be pruned a bit
2026-03-09 21:30:33 <invoked> sort distfiles by size and select the ones which seem optional, which will probably include some games. fonts eat a lot
2026-03-09 21:30:38 <tomalok> something amiss with golang on riscv64?  have a MR with the latest docker stuff and i'm getting... "---> Making bundle: dynbinary (in bundles/dynbinary)
2026-03-09 21:30:38 <tomalok> Building dynamic bundles/dynbinary-daemon/dockerd (linux/riscv64)...
2026-03-09 21:30:38 <tomalok> SIGILL: illegal instruction
2026-03-09 21:30:38 <tomalok> PC=0x23a02 m=4 sigcode=1" (etc.)
2026-03-09 21:31:18 <invoked> if we can pull metrics off fastly or something that would be useful too.
2026-03-09 21:31:56 <invoked> get a shortlist to purge in gitlab going, see who complains :)
2026-03-09 21:33:42 <pj> ikke: I'm assuming you don't have any block level dedup?
2026-03-09 21:34:43 <ikke> pj: no, we we don't
2026-03-09 21:34:57 <ikke> The master mirror may have it, it uses zfs