2026-03-01 02:30:43 ncopa: I pushed !98219 2026-03-01 02:31:20 If you get a chance, maybe you could take a look 2026-03-01 04:54:39 !98138 always got sigsegv in rootbld and ci, however it tests well with 'abuild -r' 2026-03-01 04:54:57 are there any reasons or suggestions? :( 2026-03-01 05:08:00 qaqland: at quick glance, guessing it needs `options=net` 2026-03-01 05:37:41 qaqland: sorry, I see that is already there. Will look more closely 2026-03-01 06:21:01 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 What would be the proper "verb" for fixing it back to @ncopa? 2026-03-01 06:21:39 community/parole: change maintainer or restore or fix or? 2026-03-01 06:59:20 Saijin_Naib[m], “revert” 2026-03-01 07:07:49 I'd say restore. Revert is generally used when reverting entire commits 2026-03-01 07:09:06 Yeah, that's the point :) 2026-03-01 08:18:26 Sweet, thanks 2026-03-01 11:29:15 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 What's alpine's policy on packaging vibecoded software= 2026-03-01 12:26:20 omni: any context? 2026-03-01 12:30:25 f_: is that a real question? no policy exists 2026-03-01 12:30:45 lotheac: yes it's a real question 2026-03-01 12:30:51 ok thanks 2026-03-01 12:30:56 what's the context if i may ask? 2026-03-01 12:31:39 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 https://gitlab.alpinelinux.org/alpine/council/-/issues/697 discusses it 2026-03-01 12:34:14 ah thanks 2026-03-01 12:36:30 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 Both have been mentioned in that issue though 2026-03-01 12:37:32 true, it touches on too many topics at once 2026-03-01 12:37:59 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 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 qaqland: your question the other day, about scenefx-dev 2026-03-01 21:30:41 Sheila: feel free to assign it to me :3 2026-03-01 21:57:53 👍 2026-03-01 23:41:01 @achill if you take over many more packages, it will need to be called Achill Linux 2026-03-02 00:23:20 Nochill Linux 2026-03-02 00:39:00 🤣 2026-03-02 00:53:26 achill: all right, MR 98322. 2026-03-02 03:43:07 omni: I am just confused. imo it's upstream needs to be changed 2026-03-02 08:37:22 i think i can fix it like https://git.alpinelinux.org/aports/tree/community/wlroots0.19/APKBUILD#n39 2026-03-02 09:27:22 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 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 I can do that but I'm not sure how that will help 2026-03-02 09:51:49 https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/2241590 not better 2026-03-02 11:50:02 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 Not sure if that's _the_ issue, but most likely 2026-03-02 11:56:27 although strace says the main process exited with 0 2026-03-02 12:34:02 the issue was a missing baslash, how silly is that 2026-03-02 12:46:55 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 Importing worked for the first time since the installation of the postmarketOS system. 2026-03-02 19:47:03 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 https://gitlab.alpinelinux.org/alpine/aports/-/issues/17985 2026-03-02 21:39:45 I'm trying to figure out the mess of udev rules that is happening 2026-03-02 21:39:56 libfido2-udev installs a rule that breaks pcscd from accessing yubikeys 2026-03-02 21:40:43 well, i had also other issue with pcscd but now it works :> 2026-03-02 22:21:01 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 i think in this case there is a conflict and potentially pcscd should be run with plugdev group? 2026-03-02 22:25:00 mayhaps 2026-03-02 22:25:17 like the libfido2 and pcscd should both have access 2026-03-02 22:42:17 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 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 I have all my SSH and PGP keys via pcsc so it's quite important that it works 2026-03-02 22:51:23 got it, makes perfect sense 2026-03-03 08:28:43 Hello, can someone have a look on !98334 please 2026-03-03 08:53:44 bot is 🛌 2026-03-03 09:30:07 then direct link https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98334 2026-03-03 11:10:37 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 I also noticed that the python3-cffi package has been removed from fedora 2026-03-03 11:15:50 found a patch from upstream that fixes the tests 2026-03-03 17:46:11 why did fedora remove it? 2026-03-03 17:46:49 or is it two different packages 2026-03-03 18:47:28 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 I am setting up to test patch based on the commit 2026-03-03 18:53:43 test_parsing passes after applying patch for that commit 2026-03-03 18:54:21 I'm getting 'libfakeroot internal error: payload not recognized!' when running abuild 2026-03-03 18:54:44 ncopa: oh, you already said that... totally missed that... sorry for duplicating work 2026-03-03 19:11:51 Also abuild failed to make a subpkgdir 2026-03-03 19:12:32 Ermine: what aport? 2026-03-03 19:12:58 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 jvvv: blktrace, but this is a new one and I didn't commit it yet 2026-03-03 19:15:50 Ermine: can you paste it? 2026-03-03 19:17:15 jvvv: https://0x0.st/P1kW.txt 2026-03-03 19:22:36 wait, i figured this one out: it is installing mans at wrong location 2026-03-03 19:22:43 Ermine: I think issue is that manpages are installed to /usr/man instead of /usr/share/man 2026-03-03 19:23:28 jvvv: yeah, figured this out 2026-03-03 19:23:47 yeah, sorry... I'm slow 2026-03-03 19:25:46 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 just replace with a dot? 2026-03-03 19:28:10 or should I do something like: pkgver=517 pkgversub=ba35dd7 2026-03-03 19:33:19 andar1an: i guess you want something like 517_gitba35dd7 2026-03-03 19:34:29 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 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 andar1an: usually people add a variable like _gitcommit and use it in source to mark the commit 2026-03-03 19:35:38 ya, I have been doing that for submodules, but this is a release package 2026-03-03 19:36:19 guess works the same haha. TY 2026-03-03 19:36:33 Would be nice if !97936 and !98429 2026-03-03 19:36:46 ... were reviewed 2026-03-03 20:57:42 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 !97936 !98429 2026-03-03 22:49:20 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 done 2026-03-04 00:29:12 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 should `abuild deps` install $checkdepends as well as $makedepends ? 2026-03-04 00:36:04 nvrmnd, found it looking at abuild:calcdeps() 2026-03-04 04:38:51 Anyone have bandwidth to review/merge some of my MRs? 2026-03-04 04:38:51 !96672 !97218 !96398 !96397 !97494 !97229 !97224 !96399 !97292 !98141 2026-03-04 04:43:59 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 Can someone help me suss this fail on s390x out? 2026-03-04 05:45:07 https://gitlab.alpinelinux.org/Saijin-Naib/aports/-/jobs/2244435 2026-03-04 05:45:18 It passes on all the other runners, so it seems arch-specific 2026-03-04 05:49:09 looks like sigsev 11 is memory access violation... but only under s390x? 2026-03-04 06:01:31 s390x is big-endian, could have to do with that 2026-03-04 06:15:18 Ahh, hmm, okay. Is that the only arch we have in our runners that is big-endian? 2026-03-04 06:18:49 yes. Not saying that is necessarily the reason, just one difference 2026-03-04 06:19:28 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 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 py3-pytest-benchmark fails now 2026-03-04 12:33:58 whee! im done with python 3.14 rebuilds in main/ 2026-03-04 12:34:14 nice 2026-03-04 12:43:32 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 libfido2-udev brings in rule "usr/lib/udev/rules.d/69-yubikey.rules" that assigns yubikeys to plugdev 2026-03-04 12:46:08 llvm15 llvm16 llvm18 llvm19 2026-03-04 12:46:39 llvm20 llvm21 llvm22 2026-03-04 12:46:51 we have 7 different versions of llvm 2026-03-04 12:48:23 yup.. 2026-03-04 12:49:03 llvm15 -> ghc 2026-03-04 12:49:08 llvm16 -> postgres16 2026-03-04 12:49:24 llvm18 -> ghc-loongarch 2026-03-04 12:50:17 lets get rid of llvm 19? 2026-03-04 12:50:31 and 20? 2026-03-04 12:50:31 ccls, ldc 2026-03-04 12:52:29 dotnet8, dotnet9, bcc, bpftrace, wasm-micro-runtime, zig 2026-03-04 13:02:12 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 Alternatively file issue upstream to pcscd and yubikey 2026-03-04 13:03:01 well, actually libfido2-udev takes over the ccid rules 2026-03-04 13:03:18 yubikey ends up owned by plugdev group 2026-03-04 13:03:27 that breaks pcscd 2026-03-04 13:03:59 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 ykman and piv-tool (from opensc) can see the yubikey (when running as me) 2026-03-04 13:07:09 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 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 If it retains all groups. Then yes. Adding pcscd to plugdev would work too 2026-03-04 13:09:03 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 hm? yubikey gets plugdev 2026-03-04 13:09:40 it is an earlier rule but it does end up with plugdev 2026-03-04 13:17:25 would it also be better to change ccid rules to use plugdev instead of pcscd 2026-03-04 18:08:51 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 Saijin_Naib[m]: i am considering starting an alpine multimedia packaging team, if that interests you? 2026-03-04 18:21:52 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 What do you need from me in that role? 2026-03-04 18:27:55 Anyone have local "desktop" s390x? 2026-03-04 18:28:28 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 afaik the only people who had s390x was IBM and Ariadne :> 2026-03-04 18:28:55 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 s390x cannot do desktop 2026-03-04 18:28:58 it's an ibm mainframe type thing, "desktop" may not really exist 2026-03-04 18:29:05 Ahhh, okay 2026-03-04 18:29:14 like i guess you can do like a VNC session or whatever 2026-03-04 18:29:16 but... why 2026-03-04 18:29:17 I'm surprised there are still desktop packages built for s390x? 2026-03-04 18:29:19 So GST being borked is more of a non-issue? 2026-03-04 18:29:30 wasn't it established to remove those 2026-03-04 18:29:32 https://github.com/exaile/moodbar/issues/15 2026-03-04 18:29:32 ' 2026-03-04 18:29:54 just disable s390x 2026-03-04 18:29:56 no one will cry 2026-03-04 18:30:07 Haha, I did for moodbar 2026-03-04 18:30:20 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 Just leave the CLI tools enabled? 2026-03-04 18:31:23 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/54 2026-03-04 18:32:01 tl;dr it's up to you 2026-03-04 18:32:45 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 I'm on pipewire 1.6.x as well, I'll test as well later 2026-03-04 18:33:30 Bluetooth and audio works fine 2026-03-04 18:34:45 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 looks like community/clang-rtlib was omitted in !98296 2026-03-04 23:30:14 oh, there's !98504 2026-03-05 06:52:29 Anyone can review !97637 2026-03-05 06:52:52 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 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 There's a conflict that needs to be fixed 2026-03-05 06:53:51 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 How can I see what that is? In the CI logs? 2026-03-05 06:55:06 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97637/diffs 2026-03-05 06:55:12 Rebasing would show the actual conflict 2026-03-05 06:56:34 I'll ping them 2026-03-05 06:57:19 Thanks as ever, ikke 2026-03-05 07:40:21 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 Which one? 2026-03-05 07:45:02 I assume testing/kew 2026-03-05 07:45:04 Same goes for my deadbeef aports which are not merged yet 2026-03-05 08:56:18 i dont think there are any clang rtlib 22 upstream sources yet 2026-03-05 08:57:02 it seems like afl++ tests deadlocks 2026-03-05 09:05:23 ncopa: isn't it provided by compiler-rt, subpackage of llvm-runtimes? 2026-03-05 09:11:00 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 yes, but https://git.alpinelinux.org/aports/tree/main/llvm-runtimes/APKBUILD#n134 2026-03-05 09:34:15 @Asmadeus yeah, sorry. Should have been more specific 2026-03-05 09:53:05 hum, ok 2026-03-05 09:53:18 so we dont really need the clang-rtlib package anymore? 2026-03-05 09:55:51 there are 1531 packages to rebuild with python 3.14 2026-03-05 09:56:39 only if things depending on it cannot build with latest in their $_llvmver 2026-03-05 10:03:43 ncopa: they dont package per-project specific tarballs anymore 2026-03-05 10:04:28 https://discourse.llvm.org/t/rfc-do-something-with-the-subproject-tarballs-in-the-release-page/75024 2026-03-05 10:08:12 ok. so maybe we need build llvm/clang/etc in one APKBUILD and split subpackages from that? 2026-03-05 10:08:23 no 2026-03-05 10:08:32 i mean this is the recommended way but we dont have to 2026-03-05 10:08:54 you can just cd into the project-basedir in the generic tarball 2026-03-05 10:12:27 we need to retire py3-nose 2026-03-05 10:12:45 https://fedoraproject.org/wiki/Changes/RetirePythonNose 2026-03-05 10:12:53 does not work with python 3.14 2026-03-05 10:13:25 oof 2026-03-05 10:14:31 There is apparently nose2? 2026-03-05 10:15:30 https://github.com/nose-devs/nose2 2026-03-05 10:15:35 It's in the same namespace 2026-03-05 10:15:59 no idea 2026-03-05 10:17:56 i figured out how to fix afl++ deadlock with python 3.14 2026-03-05 10:22:49 re py3-nose, I would expect most project has already removed it as dependency 2026-03-05 10:23:19 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 we should clean it up 2026-03-05 10:23:42 i dont think its too much work 2026-03-05 10:23:46 ~20 packages left 2026-03-05 10:24:08 i built py3-numpy here now with python 3.14. I simply removed py3-nose from deps 2026-03-05 10:24:19 it was too much on the nose 2026-03-05 10:24:35 oh 2026-03-05 10:24:41 badum 2026-03-05 10:24:56 tsss 2026-03-05 10:25:16 ncopa: yeah most packages probably moved away anyway 2026-03-05 10:26:36 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 we also have this https://gitlab.alpinelinux.org/alpine/aports/-/issues/18017 2026-03-05 10:28:02 its simple job. just a bit time consuming 2026-03-05 10:28:15 and right now time is not something I have a lot of 2026-03-05 10:28:45 Maybe in the future? :) 2026-03-05 10:29:09 heh 2026-03-05 10:29:31 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 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 in a few weeks my exams are over, so i can help you then 2026-03-05 10:31:34 i rsync built packages to https://dev.alpinelinux.org/~ncopa/py3.14/ 2026-03-05 10:32:14 so if anyone wants to help: 2026-03-05 10:32:35 1) try prioritize py3-* MRs 2026-03-05 10:32:48 2) help with the py3-nose removal 2026-03-05 10:33:02 3) help with the py3-future removal https://gitlab.alpinelinux.org/alpine/aports/-/issues/18017 2026-03-05 10:33:38 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 ncopa: I already removed a lot of py3-nose usage. Should I create a tracking issue? 2026-03-05 11:35:09 it would be nice to have a system to track those issues indeed 2026-03-05 11:35:17 py3-nose, as well as py3-six, and so one 2026-03-05 11:35:34 "low hanging fruits if you want to contribute to Alpine and achieve immortal fame and glory" 2026-03-05 11:55:57 and the issue tracker isn't such a system? (I see you opened #17822) 2026-03-05 11:57:39 Sertonix[m]: I don't think you need to ask wether you should create such an issue =) 2026-03-05 11:58:59 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 "Python 3.14", perhaps, or some milestone 2026-03-05 14:49:52 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 ncopa: copy that, plan to have time tomorrow to contribute 2026-03-05 15:36:56 ayakael: thanks!! 2026-03-05 15:40:42 ncopa: would you like me to take maintainership of django? I can bring it under my wing. 2026-03-05 17:12:33 py3-django-oscar fails to build because the source package on distfiles.a.o seems corrupted 2026-03-05 17:34:30 Or upstream recreated the archives 2026-03-05 17:37:31 Renamed the file 2026-03-05 20:01:08 the upstream checksum has not changed 2026-03-06 07:21:51 ayakael: im very grateful if you can take care of django. Thanks! 2026-03-06 09:26:55 be prepared for awesome go 1.26 rebuilds :) 2026-03-06 10:09:28 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 unless you skip ci 2026-03-06 10:09:54 i've just been swamped this week :/ 2026-03-06 10:11:19 maybe next week ... fingers crossed 2026-03-06 11:26:22 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 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 invoked: https://gitlab.alpinelinux.org/alpine/council/-/issues/697 2026-03-06 15:19:35 thanks 2026-03-06 16:38:50 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 oh, build has to run for check to work :/ 2026-03-06 17:23:34 Gentoo has a solid policy there. I like it. 2026-03-06 17:52:07 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 Ariadne: yes, understood 2026-03-06 17:53:29 That ticket is whether we allow contributions generated by LLM 2026-03-06 17:53:35 issue* 2026-03-06 17:58:59 yes, i created 703 for it 2026-03-06 17:59:06 my point is that we have to consider both... 2026-03-06 21:56:17 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 ncopa: done https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98630 2026-03-07 00:54:47 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 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 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 OK, the issue was not reproducible. A rerun succeeded. 2026-03-07 11:14:33 When in doubt, reboot and forget about it until next time 2026-03-07 12:03:29 quinq: Reminds me a bit of a catch phrase of "The IT Crowd" :) 2026-03-07 12:04:33 off an on again ;) 2026-03-07 13:59:05 I have seen a similar error before 2026-03-07 23:55:53 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 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 py3-click-repl fixed for py314: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98671 2026-03-08 02:01:47 ncopa: would you be so kind and enable CONFIG_BPF_LSM=y 2026-03-08 02:01:55 in your fine kernel 2026-03-08 02:39:59 py3-tika fixed as well: !98694 2026-03-08 08:27:37 p_6f3Ik7Suw: can you please create an issue in gitlab, with label "kernel" and explain why? 2026-03-08 11:48:51 ncopa: thx. will do 2026-03-08 13:30:12 ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/18029 - am not allowed to set the kernel label. 2026-03-08 13:34:53 I think you need to be "Guest" to do that 2026-03-08 13:42:35 how do i become guest? 2026-03-08 15:50:39 would anyone like to review this MR please? !98094 2026-03-08 15:53:06 Biswa96[m]: can't hit approve nor merge but it looks good to me 2026-03-08 15:53:22 (approve requires Guest, merge requires being an alpine developer :p) 2026-03-08 16:00:18 ok, I forgot about that MR and just got the email from a merge conflict :-) 2026-03-08 18:12:50 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 Can someone review !96672? Alpine-qa-bot is yelling at me to make moves 2026-03-08 20:40:50 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 Saijin_Naib[m]: These packages are maintained by 2 different persons. They would need to ack it 2026-03-08 20:44:19 Okay. I can't assign anyone, so do you mind assigning them? 2026-03-08 20:44:59 you can't assign more than one person in gitlab-ce 2026-03-08 20:45:16 you can in gitlab-EE 2026-03-08 20:45:18 haha, nice. I can't assign anyone because of my role, so :P 2026-03-08 20:45:39 Do I just @ them in a comment on the MR? 2026-03-08 20:46:50 Who is Krassy Boykinov on Gitlab? 2026-03-08 20:57:03 chereskata 2026-03-08 20:59:53 thank you 2026-03-09 01:33:51 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 Are gitlab @ accounts like, federated or only visible to guests if we interact directly? 2026-03-09 01:40:53 Hello. 2026-03-09 01:40:53 If you're interested in long-term collaborating, feel free to reach out to me. 2026-03-09 01:40:53 I’m a full stack and AI developer currently seeking a new project opportunity. 2026-03-09 01:40:53 I hope you're doing well. 2026-03-09 01:40:53 Looking forward to hearing from you! 2026-03-09 01:41:27 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 AFdev[m]: We don't appreciate this kind of spam here 2026-03-09 08:12:22 They're a bot, no worth replying 2026-03-09 14:31:28 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 i think we need py3-legacy-cgi package 2026-03-09 14:44:56 for py3-webob 2026-03-09 16:33:57 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 ago) to 1000 now, I see a scaling problem. 2026-03-09 16:36:01 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 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 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 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 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 ikke: git or package 2026-03-09 20:40:50 package 2026-03-09 20:41:35 i do ponder if alpine packages too many things that would be better suited by flatpak, etc 2026-03-09 20:45:02 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 (I’m sorry if I caused some serious PTSD by even mentioning it.) 2026-03-09 20:46:13 you are comparing two entirely different operating systems 2026-03-09 20:46:50 Ariadne: Yes, I know. I think I was just curious. 2026-03-09 20:47:27 there are too many variables 2026-03-09 20:47:28 Are the same versions of TeXlive being used on both systems? 2026-03-09 20:47:40 Could be a number of factors even 2026-03-09 20:48:50 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 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 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 My honest advice if you care for productive use of a type setting environment: Use typst instead. 2026-03-09 20:51:25 maribu: https://gist.github.com/vlt/afee3ff70073ab64f1c0ab6ecb00fa30 2026-03-09 20:51:59 ah pi-ver 2026-03-09 20:53:02 ikke: is the bottleneck on the infra side? 2026-03-09 20:53:29 (re: repo growth) 2026-03-09 20:53:58 Yes, builder storage, dl-master storage, t1-mirror storage, 3rd-party mirror storatge 2026-03-09 20:54:00 storage* 2026-03-09 20:54:01 ACTION is having a look at typst 2026-03-09 20:54:17 pointing people to flatpak seems gross, though 2026-03-09 20:55:05 And the quick dismissal of "storage is cheap" is even less true nowadays than before 2026-03-09 20:55:28 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 maybe we need to get better at pruning 2026-03-09 20:56:53 ie, the feedback loop of whether some packages are meaningful enough to the community to have in there. 2026-03-09 20:57:12 but i have no idea how we'd accomplish that. 2026-03-09 20:59:18 And it would be quite a massive pruning to have effect 2026-03-09 20:59:59 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 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 repo sizes per release: https://tpaste.us/YqBZ 2026-03-09 21:11:29 7.5G for 3.4, 99G for 3.23. ~10x increase 2026-03-09 21:12:07 And that's just for one release 2026-03-09 21:12:13 one arch& 2026-03-09 21:12:42 yeah, oof. 2026-03-09 21:14:00 some hard decisions need to be made, sounds like 2026-03-09 21:14:55 btw, this ties directly in the remarks about open MRs for new packages 2026-03-09 21:15:26 pruning community seems like a first step though. alpine would have to get more opinionated. 2026-03-09 21:15:55 there are also a bunch of oudated libraries without any reverse dependencies that could be pruned 2026-03-09 21:17:45 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 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 and it does not add up to a significant win 2026-03-09 21:22:11 what's the comparison of testing vs comm vs main 2026-03-09 21:23:45 pj: https://tpaste.us/YqBZ shows it 2026-03-09 21:23:48 ikke: throw them at archive.org? 2026-03-09 21:24:51 We would need to delete ~13 older releases to get the equivalent of 1 new release 2026-03-09 21:25:27 Yeah, I think community needs to be pruned a bit 2026-03-09 21:30:33 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 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 Building dynamic bundles/dynbinary-daemon/dockerd (linux/riscv64)... 2026-03-09 21:30:38 SIGILL: illegal instruction 2026-03-09 21:30:38 PC=0x23a02 m=4 sigcode=1" (etc.) 2026-03-09 21:31:18 if we can pull metrics off fastly or something that would be useful too. 2026-03-09 21:31:56 get a shortlist to purge in gitlab going, see who complains :) 2026-03-09 21:33:42 ikke: I'm assuming you don't have any block level dedup? 2026-03-09 21:34:43 pj: no, we we don't 2026-03-09 21:34:57 The master mirror may have it, it uses zfs 2026-03-10 00:46:29 It could be useful to work on better docs and tooling for finding, hosting, creating extra repos (ala ppa's, AUR, etc) 2026-03-10 00:49:17 ssh prismatic 2026-03-10 00:49:25 oops 2026-03-10 00:54:47 related to above -- chromium updates switching to every 2 weeks will be adding to the problem 2026-03-10 01:01:05 looks like some downstreams are going to move to even number releases to stay at a4 week release cycle 2026-03-10 01:15:35 or we could just switch to extended stable 2026-03-10 01:15:59 which is every 8 weeks 2026-03-10 01:21:22 tomalok: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98770 2026-03-10 01:21:45 the issue only happens on some rv64 runners 2026-03-10 02:14:15 @iggy_ if I could set it up easily, it could be cool. Federated search across repos would be cool 2026-03-10 03:48:27 ikke: the infra is one scaling bottle neck, but one that can be adressed. I'd feel weird telling someone, who wishes to contribute to Alpine Linux being the very best linux distro out there, that their new aport proposal is deprioritized because there isn't enough storage. I think the more pressing bottleneck is « political » (in the sens of 2026-03-10 03:48:27 policy and vision for the project). Concretely 1) what kind of packages do we want to include and 2) how many core developpers are we able to include in Alpine's structure to be able to support that. These things are more of a gouvernance scaling problem than a technical one. 2026-03-10 03:52:34 (and gouvernance is a subject I find truly fascinating, but indeed goes beyond the scope of this chat room, so will keep it at that) 2026-03-10 08:42:50 lotheac: good job with the riscv64 SIGILL 2026-03-10 08:43:22 thanks 2026-03-10 08:44:02 it was a pretty puzzling one because your hardware happens to be the same hardware which is referenced in the go commit messages which added the broken stuff... 2026-03-10 08:44:03 i'd guess the long term solution would be to fix riscv_HWPROBE_IMA_V to be set to correct value 2026-03-10 08:44:30 it could be a kernel thingy 2026-03-10 08:44:37 that kernel reports wrong 2026-03-10 08:44:39 no, the vector insn *work* as advertised, i think it's a context switch / register saving issue 2026-03-10 08:45:27 i had an llm generate a C test program which runs a ton of vector insns on 4 threads and it has no problems 2026-03-10 08:46:29 it's only go, and only without GODEBUG=asyncpreemptoff=1, that it crashes 2026-03-10 08:46:50 interesting 2026-03-10 08:57:13 i hope the go people have a deeper understanding than i do, but because goroutine context switches don't go through the kernel (afaiu) it feels like something related to register saving could be the problem 2026-03-10 11:12:03 do we have any plan for py3-pastel? ModuleNotFoundError: No module named 'pkg_resources' 2026-03-10 11:12:58 s/py3-pastel/py3-paste/ 2026-03-10 11:19:08 a draft PR: https://github.com/pasteorg/paste/pull/105 2026-03-10 11:22:05 that patch does not solve it 2026-03-10 11:22:45 maybe we should merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97555 2026-03-10 11:24:01 it looks like they want retire paste. "My hope for a long time has been that we could retire paste out of existence." 2026-03-10 11:24:19 only py3-webtest uses it in community apparently 2026-03-10 11:25:22 remove both? 2026-03-10 11:30:36 py3-webtest does not use it at all 2026-03-10 11:30:43 so we can remove py3-paste 2026-03-10 11:34:34 ok we are moving forward again 2026-03-10 11:37:54 meh... ModuleNotFoundError: No module named 'cgi' 2026-03-10 11:38:04 we need py3-legacy-cgi i think 2026-03-10 11:38:51 https://pypi.org/project/legacy-cgi/ 2026-03-10 13:19:18 ∞/w 11 2026-03-10 16:43:22 /nick iggy 2026-03-10 16:46:05 Saijin_Naib[m]: yeah, I'm most familiar with Ubuntu's PPAs (which is probably not what would actually solve the problem, just move the problem to more infra that Alpine would have to maintain), but the idea of a central place to search for additional or updated packages seems like it would be an easier lift 2026-03-10 16:48:11 it would also be nice if there were some way to host a repo on gitlab/github releases/pages/etc... I tried years ago and I can't remember exactly why I couldn't get it to work, but from what I remember, it didn't seem impossible, just not doable then because of assumptions 2026-03-10 16:48:48 Ahh, that could be interesting as an approach, as well 2026-03-10 16:49:14 I ended up rolling my own API to do it 2026-03-10 16:50:46 Anyone have time to review !98792 (looks like x86_64 CI OOMd) and !97593 (which relies upon the prior) 2026-03-10 17:01:32 ikke: looks like edge-x86 builder is stuck 2026-03-10 17:20:07 anjan: Would you mind creating a new release of honeybee and push it to aports? The package is currently not buildable nor installable. 2026-03-10 18:39:40 hello, does somebody know who runs gitlab.alpine.org? i have reproducably problems when trying to see file commit history . getting permanently errors like "500: We're sorry, something went wrong on our end Request ID: 01KKCGH3FDPYMVS6P65Y9KAN1V Try refreshing the page, or going back and attempting the action again. Please contact your GitLab administrator if this problem persists." 2026-03-10 18:42:09 for this url for example https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/gnome-session/APKBUILD?ref_type=heads 2026-03-10 19:12:49 you might be rate-limited. try it again after a few minutes 2026-03-10 19:19:31 No, it's due to the size of the aports repo. It's a timeout 2026-03-10 19:19:47 Not sure what to do about it 2026-03-10 19:28:03 i'm assuming you already tried a shallow clone and gitlab complained 2026-03-10 19:31:35 That url works fine for me, though 2026-03-10 19:32:23 please click on the history button. timeout occurs there 2026-03-10 19:32:52 i did a clone a whlie ago into my own account and after that, history worked for a while, but now it has the same problem there too 2026-03-10 19:33:03 have found https://gitlab.com/gitlab-org/gitlab/-/work_items/344549 2026-03-10 19:33:39 that doesn't sound too promising. maybe clone to local system then as a workaround? 2026-03-10 19:34:21 Right, history pages is what's causing issues 2026-03-10 19:37:40 "The root cause of the problem is rename detection in Git is slow, thus the Gitaly request is slow, thus history timeout." 2026-03-10 19:41:10 it's kind of pathetic they closed it wontfix because they didn't have a big enough monorepo there to reproduce it 2026-03-10 19:51:15 i'm administering two gitlab instances and i think it's a monster. so i'm indulgent when others have issues with it :D 2026-03-10 20:04:35 gitlab only feels good to me when i'm comparing it with atlassian stuff. in the long run, i have serious misgivings about it 2026-03-10 20:05:00 at least where it concerns things like this 2026-03-10 20:05:35 that thread shows they don't really care that much about solving some problems 2026-03-10 20:45:52 gitlab was the best (read: only) thing that could handle aports at the time 2026-03-10 20:46:16 gogs (or it's predecessor) would choke on aports at the time 2026-03-10 20:47:59 I guess gogs was the predecessor, and then forked as gitea 2026-03-10 20:55:06 and then forgejo 2026-03-10 20:56:44 yup 2026-03-10 20:57:12 21:41 i do ponder if alpine packages too many things that would be better suited by flatpak, etc 2026-03-10 20:57:32 Ariadne: just to note, flatpak only supports like two of the total ~9 arches alpine supports (x86_64, aarch64) 2026-03-10 20:57:44 well, flathub you mean. 2026-03-10 20:57:57 asleep, yes I meant flathub 2026-03-10 20:58:20 but it's either flathub or alpine maintains its own repo, right? 2026-03-10 20:58:23 (also i would be in support of getting off of gitlab, forgejo is sufficiently mature that i think we could scale a lot more easily with it) 2026-03-10 20:58:49 It would not be an easy migration 2026-03-10 20:58:54 indeed not 2026-03-10 20:59:39 f_: sure, maybe. my point was that i think we package things that might be better off elsewhere. 2026-03-10 20:59:52 i guess the agit workflow support in forgejo would be beneficial for aport 2026-03-10 20:59:55 Where? 2026-03-10 21:00:19 at least that is what gentoo advices for portage contributions 2026-03-10 21:00:25 f_: who knows? obviously there is no third-party repo that exists that is 1:1 with alpine, much less alpine-ports 2026-03-10 21:00:38 f_: presumably flathub or other repo. 2026-03-10 21:00:51 Ariadne: you mean, you'd want to see something like AUR but for alpine of sorts? 2026-03-10 21:01:00 if I had to pick an example, nheko does not really need to exist in Alpine itself. 2026-03-10 21:01:45 f_: yes, but also no. i mean i would like to see "apps" move to flathub and alpine focus on the core operating system and pmOS focus on embedded adaptations (like phones, SBCs, etc.) 2026-03-10 21:01:56 Sheila: main gripe I have with flathub is it works great for aarch64/x86_64 but there is zero support for anything besides that (loongarch64, armv7, etc) 2026-03-10 21:02:06 I _was_ hoping to work on a third-party repo for Alpine, a la rpmfusion, but there's a lot of work that needs to go into that that I'm not able to do for various reasons. 2026-03-10 21:02:23 f_: yes, i am pondering whether it might be worth putting resources into helping flathub get that support 2026-03-10 21:02:47 that would be pretty cool 2026-03-10 21:03:31 but i am just one person with one opinion 2026-03-10 21:03:45 and alpine has grown into a meta-distribution anyway 2026-03-10 21:04:07 we need to make a number of policy decisions and changes to accommodate that reality 2026-03-10 21:05:04 ikke: out of curiosity have you read pmOS's retrospective on migrating from gitlab.com? 2026-03-10 21:05:31 f_: I think, or at least partially 2026-03-10 21:05:38 would probably be useful for roughly getting an idea how hard it would be to migrate 2026-03-10 21:05:45 (https://postmarketos.org/blog/2024/10/14/gitlab-migration/) 2026-03-10 21:05:49 But we're using gitlab more extensively I think 2026-03-10 21:06:16 we're also still using gitlab, just a selfhosted one 2026-03-10 21:06:20 anyway, to make forward progress in these areas, we need a functional TSC and Council, as always i am willing to help with either/both of these 2026-03-10 21:06:23 yup, so gitlab -> gitlab 2026-03-10 21:06:27 indeed 2026-03-10 21:06:34 Ariadne: fyi, we're working on that 2026-03-10 21:06:39 it was a bit hard, just gitlab-EE -> gitlab-CE 2026-03-10 21:06:51 Some EE things are not in CE 2026-03-10 21:07:04 ack 2026-03-10 21:08:00 (notably epics, which we were using) 2026-03-10 21:11:39 I don't like flatpak or flathub 2026-03-10 21:11:45 it's certainly better than snap but that's a very low bar 2026-03-10 21:12:25 I'd rather everything be a distro package 2026-03-10 21:15:01 Ariadne: at least gitlab has a competent security team. I wouldn't put much trust into forgejo security-wise :/ 2026-03-10 21:15:22 not sure about flathub in that respect either 2026-03-10 21:15:27 jvoisin: sure, but gitlab is also a gigantic resource hog 2026-03-10 21:15:40 villosa! (when it's ready) 2026-03-10 21:15:46 "nice things and why we can't have any" 2026-03-10 21:16:39 Noisytoot: i guess my question is, what is the value in every distro packaging 10k desktop apps 2026-03-10 21:17:07 like, ok, we can patch out telemetry and other antifeatures (and in alpine we try to do this as much as possible) 2026-03-10 21:18:52 i'd rather see us get more opinionated about what goes in, rather than striking out classes of packages 2026-03-10 21:18:57 like you did with firejail, for instance 2026-03-10 21:20:48 flatpaks bundling libraries causes too much duplication (meaning higher memory and disk space usage) and makes it harder to exercise freedom 1 and replace libraries globally 2026-03-10 21:21:52 if I want to replace a library that's used by many programs with a modified version on alpine, it's easy (I can just modify the package locally, build, and install it). if I want to do the same with flatpak, I'd need to rebuild every flatpak with my modified version 2026-03-10 21:25:45 invoked: sure, but where do we draw the lines? i drew the line with firejail because it has an atrocious CVE record, which is not something we want in a security tool 2026-03-10 21:27:57 having more opinion battles would be messy, but so is ... democracy. the line is the maximum amount our smallest mirrors will accept 2026-03-10 21:28:42 everything past that line, people have to build it 2026-03-10 21:28:50 locally 2026-03-10 21:29:59 It's still an arbitrary line that would be hard to impossible to communicate 2026-03-10 21:30:38 with @netblue30 for over a month, so to avoid leaving firejail in a broken 2026-03-10 21:30:38 mostly bugfixes), we (@kmk3 and @SkewedZeppelin) chose to release 0.9.76. 2026-03-10 21:30:38 state for many common programs for too long (and since the release contains 2026-03-10 21:30:38 > Usually the releases are created by @netblue30, but we could not get in contact 2026-03-10 21:30:45 oh, grr 2026-03-10 21:31:05 i was going to say i would probably be ok with firejail *today* because they went back and fixed a lot of the code to remove classes of vulnerability 2026-03-10 21:31:11 but, well, nevermind :) 2026-03-10 21:31:38 but i was glad to see alpine having opinions like that. 2026-03-10 21:31:53 "maintainer goes AWOL during major bug incident" is still a security- for me 2026-03-10 21:32:54 invoked: but that's only marginal in this discussion 2026-03-10 21:33:09 invoked: i mean, i want to bring the number of SUID-programs in a typical alpine install to as close to zero as possible 2026-03-10 21:33:15 that opinion has not changed :) 2026-03-10 21:33:35 (hence capsudo, i want to replace doas with it) 2026-03-10 21:34:16 Ariadne: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87750 2026-03-10 21:34:22 ikke: yeah, my point is i think it's been one of alpine's strengths to have its opinions. similar to openbsd and friends 2026-03-10 21:34:54 ikke: *shrug* i have no objection to sudo-rs in theory, but in practice i think they are solving the wrong problem 2026-03-10 21:34:57 invoked: We have been opinionated in certain things, but in many others not that much 2026-03-10 21:35:32 i do not think "rewrite sudo in rust" solves sudo's main security defects which are related to combinatorial complexity with the config format 2026-03-10 21:36:08 yeah, that's what my idea about it is as well 2026-03-10 21:37:53 i also do not like the mandatory depend on PAM as WhyNotHugo flagged 2026-03-10 21:37:53 but no reason to security-NAK it just being in community 2026-03-10 21:38:41 for my part I don't really like the complexity of such a privileged tool in general 2026-03-10 21:39:30 with more complexity there's more that can possibly go wrong 2026-03-10 21:39:50 btw, we got a request whether it would be possible to switch from opendoas to upstream doas 2026-03-10 21:39:54 (as you prob. know, but I guess it's really the usual problems of sudo, but reimplemented in rust) 2026-03-10 21:39:59 since opendoas seems to be not that much maintained 2026-03-10 21:40:24 Opendoas has not seen any commits for years I think? But is upstream doas working on linux? 2026-03-10 21:40:44 As I understand it opendoas existed to port doas to linux, which would imply that upstream doas does not work as is? 2026-03-10 21:40:52 (or used to not work as-is) 2026-03-10 21:41:06 Yeah, doas itself is written for *bsd 2026-03-10 21:41:16 i don't think it changes that much on openbsd 2026-03-10 21:41:29 it's finished software 2026-03-10 21:43:02 but it works differently on linux so it should be measured on its own 2026-03-10 21:43:30 invoked: yeah but openbsd are active on security things, aren't they? 2026-03-10 21:43:49 on anything in base, yes 2026-03-10 21:44:25 outside of base, all bets are off, but they try. 2026-03-10 21:50:05 I found another doas port https://codeberg.org/thejessesmith/doas/ 2026-03-10 21:55:34 seems to be what FreeBSD has as security/doas in ports 2026-03-10 21:56:15 gentoo is on https://github.com/Duncaen/OpenDoas 2026-03-10 21:56:39 but i've lost touch with how gentoo reviews things anymore. has like, sam reviewed it? dunno 2026-03-10 21:56:40 as are we 2026-03-10 21:57:29 thejessesmith/doas is slicer69/doas https://π.duncano.de/slicer69-doas 2026-03-10 21:58:22 void uses duncaen/opendoas too 2026-03-10 22:01:45 codeberg does not work 2026-03-10 22:02:25 er 2026-03-10 22:02:38 ikke: i think solving the entanglement of maintainer-scripts and doas conf.d is necessary before switching upstreams 2026-03-10 22:03:31 ikke: where is that request btw? 2026-03-10 22:05:57 I don't really like the idea that installing a package can change my doas configuration.. =/ 2026-03-10 22:06:19 I don't think packages should (be allowed to) install to that destination, but rather some examples/ folder 2026-03-10 22:10:30 omni: by solving the entanglement, i mean introducing a runner specifically for maintainer scripts 2026-03-10 22:10:38 Time for an Alpine desktop downstream? Boreal Linux? Move all the non-core or GUI stuff there? 2026-03-10 22:11:44 omni: e.g. today doas is abused for this purpose, which is why the configuration directory nonsense happened (because I wanted sudo out of main) 2026-03-10 22:12:01 but the configuration directory stuff was meant to be an interim measure 2026-03-10 22:12:27 and by now, perhaps people rely on it 2026-03-10 22:14:46 but I don't mind the idea of the configuration directory, that /etc/doas.conf is read first and then /etc/doas.d/*.conf, as long as nothing is automatically added to /etc/doas.d/ 2026-03-10 22:14:49 I think 2026-03-10 22:15:06 I'm not gonna fight for the existance of /etc/doas.d/, I don't use it 2026-03-10 22:16:20 it's just that I can see that it could be a conventient maintainer/user releationship if maintainers could ship tailored configuration for you to copy there if you want 2026-03-10 22:17:21 i have no opinion on that, namely that 2026-03-10 22:17:39 1. we need to decide if we want to keep the configuration directory nonsense if we switch to another port 2026-03-10 22:17:52 2. it would be good to remove the main variable driving the need for it 2026-03-10 22:18:26 in an ideal world, we would have solved the maintainer script problem differently. 2026-03-10 22:20:12 but ultimately, i see a capsudo-doas package as a replacement to doas (it would have a capsudo-doasd which acts as an authorization layer based on /etc/doas.conf config and block minting of capability objects that are not granted by the config) 2026-03-10 22:20:58 that will give us SUID-less escalation, and then we can have another capsudo instance for maintainer scripts or such 2026-03-10 22:21:27 Q: why switch to another port 2026-03-10 22:21:54 i do not know :) 2026-03-10 22:22:16 i would rather put energy towards getting rid of SUID binaries in the default install :p 2026-03-10 22:22:28 amen 2026-03-10 22:22:29 agreed 2026-03-10 22:23:14 I can tell you there is one bin that depends on suid 2026-03-10 22:23:17 mount 2026-03-10 22:23:49 specifically for cifs-tools 2026-03-10 22:24:55 in the first blog i wrote explaining capsudo, i did write about that scenario :) 2026-03-10 22:25:39 one of the things i want to build is a service which mints arbitrary capsudo capabilities at runtime, but that is a while down the road 2026-03-10 22:25:49 one could consider it "polkit done right" 2026-03-10 22:26:14 verses polkit which has *checks notes* a fucking javascript engine in it 2026-03-10 22:26:34 as long as I don't have to re-live the sudo -> doas nightmare again 2026-03-10 22:26:50 I just came back to alpine, don't want to regret that 2026-03-10 22:27:37 how was that a nightmare ? 2026-03-10 22:28:19 there was funny patch for doas.d that broke the system 2026-03-10 22:28:24 for me 2026-03-10 22:28:39 it is nightmare, because I have to fix things I wish I didn't want to fix 2026-03-10 22:29:02 nah, in this case it will be smoother 2026-03-10 22:29:12 and probably opt-in for the foreseeable future 2026-03-10 22:29:36 but yes, doas.d was a mistake 2026-03-10 22:32:47 and at least in the present, my focus is on migrating the maintainer-scripts out to something built on capsudo, so that we can grant maintainer-scripts a very scoped escalation capability 2026-03-10 22:33:36 then the maintainer-script runner would spawn a capsudod that lives for the life of the maintainer script and can only mint that very specifically scoped capability 2026-03-10 22:34:17 once /that/ part is done, we can talk about doas itself ;) 2026-03-10 22:34:42 I forgot i have run0 because of pmOS so I think I'm good with whatever happens to doas 2026-03-10 22:35:30 ACTION shrugs 2026-03-10 22:35:52 Ariadne: capsudo requires a process (capsudod) to be running, what happens if that gets killed? 2026-03-10 22:37:14 to clarify, capsudo requires *any* broker that speaks the capsudo protocol, more specifically. for example, capsudod-pwauth sits in front of capsudod and issues a challenge (then forwards connections onward to capsudod which submit the correct answer) 2026-03-10 22:37:18 i'm not even sure the persist/timestamp feature in opendoas was ever properly reviewed by distros as safe 2026-03-10 22:37:31 invoked: i looked at it briefly, it seems fine 2026-03-10 22:38:20 alright 2026-03-10 22:38:23 suid doesn't have the danger of a process getting killed for whatever reason and leaving you unable to escalate privileges to fix it 2026-03-10 22:38:43 Noisytoot: that's what supervise-daemon(8) is for 2026-03-10 22:38:55 also, there is, you know, su(8) 2026-03-10 22:40:33 I didn't want to suggest that we should switch to another doas port, just mention that one existed as I started to look at it following ikkes comment about opendoas not being much maintained 2026-03-10 22:40:47 and alpine is not going to stop shipping su(8) 2026-03-10 22:41:03 but as invoked said, it doesn't move much in upstream either, and we did backport that rowhammer thing 2026-03-10 22:41:18 openbsd has a special kernel api 2026-03-10 22:41:22 we don't have 2026-03-10 22:41:30 which is part of the problem 2026-03-10 22:42:21 i mean the only thing that can be done about rowhammer regardless is to ensure the secret is as short-lived as possible 2026-03-10 22:42:23 most important question is: does doas need to move at all? like it has certaine defined functionality and works well? unless I'm mistaken or unaware of something 2026-03-10 22:42:58 pj: i do not think it does, but i would like to move away from SUID-based escalation (with the exception of su(8)) 2026-03-10 22:43:41 I'm assuming "move away" means from main to community 2026-03-10 22:43:51 in my case I mean move to another fork 2026-03-10 22:44:05 or, err, port 2026-03-10 22:44:09 yes, i see no reason to move to another port 2026-03-10 22:44:17 our current doas port is fine for what it is 2026-03-10 22:44:29 setup-user 2026-03-10 22:44:51 has to be in main unless that changes 2026-03-10 22:45:21 yes 2026-03-10 22:45:58 again, i am not proposing moving doas to community now. 12-18 months from now may be a different story. 2026-03-10 22:48:57 i suspect there would even be a period where it asks whether you want to use capsudo-doas or normal doas for privilege escalation :) 2026-03-10 22:49:13 but all of this is moot because capsudo-doas does not exist yet 2026-03-10 22:51:35 should probably make a call on what to do about doas.d in the short term 2026-03-10 22:53:51 retain for now, until that part of capsudo is ready :) 2026-03-10 22:54:36 sgtm 2026-03-10 22:56:31 I would still want packages to not install anything to it 2026-03-10 22:57:10 yes, that's the point of moving those packages away from it 2026-03-10 22:57:14 today they do this 2026-03-10 22:57:24 tomorrow, they will use something specific to running maintainer-scripts 2026-03-10 22:57:41 e.g. they will stop installing things to /etc/doas.d as they no longer use doas 2026-03-10 22:58:42 in the meantime, can't we move from installing files there to instead put them into example folders? 2026-03-10 22:59:27 no, because it will break the maintainer-scripts 2026-03-10 23:00:22 to clarify: there are a handful of services which install maintainer-scripts as part of a cron, some of these maintainer-scripts use doas to do things like reload the service configuration 2026-03-10 23:01:01 if i had been aware of this problem when we were still using sudo, i would have written capsudo much sooner 2026-03-10 23:01:23 but it became known to the TSC at the very last minute 2026-03-10 23:01:31 which is how we wound up with this /etc/doas.d situation 2026-03-10 23:02:45 so the idea is to provide a tool as part of the capsudo suite that runs the maintainer-script with access to a scoped capsudod :) 2026-03-10 23:03:12 or perhaps even with just a pre-minted capability 2026-03-10 23:03:16 i'm still thinking on it 2026-03-10 23:03:25 Ariadne: I'd be quite disappointed if packages were dropped in favour of relying on Flatpak. Alpine packages just work (including with each other), Flatpak is a world of pain every time I have to deal with it. If you want to containerise apps, even running them in (alpine) podman containers with some mounted sockets would be less of a pain. 2026-03-10 23:04:17 I've been experimenting with running distro packages in tight sandboxes, and have some interesting prototypes, but just prototypes right now. 2026-03-10 23:04:55 Re doas.d/, the default Alpine install puts a file in there, which overrides doas.conf. I find that super annoying, and have locked myself out of systems because of it more than once. 2026-03-10 23:05:25 hugo i agree. though, the open problem remains -- we're too big, so something needs to change 2026-03-10 23:05:39 using flatpak'd code editors/IDEs is just impossible 2026-03-10 23:05:42 or, i guess, magic increase in infra 2026-03-10 23:06:19 it is not just infra, it is security, it is quality assurance, it is packaging in general 2026-03-10 23:06:36 at some point, we can't package the entire universe 2026-03-10 23:06:46 invoked: a huge repo like this has its issues, but it also makes is feasible to keep things tightly aligned. Like rebuilding all go packages when go has a securit update. 2026-03-10 23:07:00 IMO, packaging anything for desktop usage outside of armv7/aarch64/x86_64 is wasteful... 2026-03-10 23:07:13 that's a good start 2026-03-10 23:07:19 pj: i disagree, alpine loongarch is quite usable 2026-03-10 23:07:33 and I guess that 2026-03-10 23:07:42 hopefully all 3 users of that arch will forgive me 2026-03-10 23:08:09 you just pissed off all the s390 desktop users 2026-03-10 23:08:10 and some people seem to want desktop stuff also on riscv64 and ppc64le 2026-03-10 23:08:11 I always hessitate wrt to that. Should I keep the list of architectures minimal, or aspire to cover all of them? 2026-03-10 23:08:28 anyway i am not in support of cutting archs 2026-03-10 23:08:31 ok but realistically, how usable is desktop on rv64 2026-03-10 23:08:43 I find it unusable even in CLI 2026-03-10 23:08:50 we have found legitimate QA problems in desktop packages before by building on s390x for example 2026-03-10 23:09:12 ok, how useful is that vs used storage 2026-03-10 23:09:15 and compute 2026-03-10 23:09:32 well, i am paying a boatload of money every month to alpine 2026-03-10 23:09:38 and it is not being spent 2026-03-10 23:09:48 and i'm probably going to stop doing so soon 2026-03-10 23:09:58 I'm only paying with my spare time 2026-03-10 23:10:06 so there seems governance issue rather than infra issue 2026-03-10 23:11:02 so, i think talking about infra resources when there is monthly income to spend on solving that problem is... well 2026-03-10 23:11:07 ACTION shrugs 2026-03-10 23:11:25 well, earlier it was said to be infra issue 2026-03-10 23:11:51 yes, but imo it is a matter of execution moreso than the inability to execute 2026-03-10 23:12:17 https://alpinelinux.org/posts/2026-01-18-new-sponsors-strenghten-infrastructure.html 2026-03-10 23:12:31 in fact, we have more infra today than we had last year 2026-03-10 23:12:52 *plus* cash to buy even more infra should we need to 2026-03-10 23:13:26 oh damn, open home foundation dropped nice 2026-03-10 23:14:20 you could probably reclaim a couple Gs by cutting the fonts. "introducing: setup-fonts" 2026-03-10 23:14:48 anyway, i would argue that mirrors do not necessarily need to carry all archs 2026-03-10 23:15:13 (as long as we have a way to skip irrelevant mirrors in setup) 2026-03-10 23:16:43 is noarch still a thing? 2026-03-10 23:17:00 noarch will also help once we have a dedicated noarch repo 2026-03-10 23:17:22 I remember there was noarch at some point? 2026-03-10 23:17:30 there is in APKBUILD. 2026-03-10 23:17:43 at the moment, noarch packages get rebuilt on each arch tho 2026-03-10 23:17:46 I remember it on some mirror 2026-03-10 23:17:57 cool, that is called an error 2026-03-10 23:18:57 besides the real infra problem isn't storage, it is building packages 2026-03-10 23:19:13 for example go rebuilds = hundreds of packages clogging the builders 2026-03-10 23:19:47 we need to parallelize those builds 2026-03-10 23:19:57 WhyNotHugo: I wish we didn't (have to) rebuild all go aports, if we had a way to know what aports that would actually need to be rebuilt it wouldn't take days, and we would perhaps additinally benefit from also knowing what other dependencies we need to bump to mitigate security issues 2026-03-10 23:20:00 but I guess the upstide of doing it like this is that continuously fixing build issues ahead of cutting a release makes for less work when it is time for that 2026-03-10 23:22:01 something something build-time SBOMs 2026-03-10 23:22:08 yes 2026-03-10 23:23:12 I think of it everytime there's a bulk rebuild, and sometimes in between, but so far I'm not working on a solution either 2026-03-10 23:23:18 doesn't go embed the dependency tree in builds already? 2026-03-10 23:23:39 others are working on stuff that will be useful to parallelize the build 2026-03-10 23:23:44 yes, but how do we search it? 2026-03-10 23:23:48 like the problems we face are not insurmountable 2026-03-10 23:24:04 it's in elf headers iirc? 2026-03-10 23:25:40 omni: anyway the solution to /etc/doas.d having stuff installed into it is next on my roadmap for capsudo, probably after kubecon. i want to get pkgconf 3.0 out first. 2026-03-10 23:26:21 Ariadne: I looked at the aports adding things there and am less worried https://pkgs.alpinelinux.org/contents?file=&path=%2Fetc%2Fdoas.d&name=&branch=edge&repo=&arch=x86_64 2026-03-10 23:26:51 omni: https://pkg.go.dev/runtime/debug#BuildInfo 2026-03-10 23:26:52 omni: yeah its just for a handful of maintainer-scripts as i said 2026-03-10 23:27:16 but I vaguely recall it was available just by reading binary as well, don't remember exactly as of now 2026-03-10 23:27:46 omni: for example, tailscale needs the ability to run /usr/sbin/resolvconf 2026-03-10 23:29:07 anyway i am not in support of cutting archs 2026-03-10 23:29:29 what do you think about the weird distinction between mainstream and exotic targets in gcc-cross-embedded? 2026-03-10 23:29:43 i do not care about gcc-cross-embedded 2026-03-10 23:29:55 pj: syft scan /path/to/go-binary 2026-03-10 23:30:18 arm-none-eabi and riscv-none-eabi are the only mainstream targets (that are built for every architecture), while everything else is exotic and built only for x86_64 and aarch64 (I just noticed that the package has a typo and says "x86_86") 2026-03-10 23:30:38 that is indeed exotic 2026-03-10 23:30:55 omni: how does that work? looks at DWARF? 2026-03-10 23:31:37 pj: I forget, but you can also strings /path/to/go-binary | rg "^dep\t" | sort -u 2026-03-10 23:31:46 that is faster than whatever syft does 2026-03-10 23:32:09 see, I knew there was a way, thanks for reminding :> 2026-03-10 23:32:13 aarch64-none-elf, i386-elf, x86_64-elf are exotic targets and probably shouldn't be (the latter two are my fault though). also I think exotic targets should at least also be built for ppc64le (I don't think those builders are particularly slow and if I can get a POWER9 system cheaply enough I intend to use it as a desktop) 2026-03-10 23:33:08 omni: i do like the syft scan option, especially since it can output in various formats 2026-03-10 23:33:15 and I just noticed another typo in the same APKBUILD: "aarach64" 2026-03-10 23:33:17 pj: but still, we would need to keep some database of sorts, right? to be able to search what aports are actually affected by a certain stdlib issue fixed in a golang security upgrade 2026-03-10 23:33:22 and it worked pretty fast at least scanning syft bin 2026-03-10 23:34:03 pj: yes, it's quite nice that it can output in various formats, as you say, and it's not that slow 2026-03-10 23:34:09 omni: unfortunately yes, imo best option would be to have some kind of apk providers like go: rust: 2026-03-10 23:34:23 and put that in package during build 2026-03-10 23:34:28 omni: anyway, i am thinking of writing a utility, capinvoke, which spawns relevant capsudod with some scoped directory or something and then runs a process that has access to that directory 2026-03-10 23:35:18 pj: problem is that provides= conflict with each other 2026-03-10 23:35:51 can't have nice things in this world, can i 2026-03-10 23:36:17 well, we can add package notes or something 2026-03-10 23:36:39 I think I'd rather go SBOM route and hack in jq 2026-03-10 23:37:30 btw. I have fixed melange and that gives sboms (but it's go so I'm guessing non-starter due to main repo) 2026-03-10 23:37:47 melange does not run APKBUILDs 2026-03-10 23:38:23 and the way chainguard does build SBOMs is, well, suboptimal imo 2026-03-10 23:38:28 Ariadne: What issues do you see with desktop applications in the community repo packaged by people who are willing to maintain the? 2026-03-10 23:39:01 Sertonix[m]: nothing, i was just pondering whether we need to package every desktop app 2026-03-10 23:39:31 maybe get rid of electron apps... 2026-03-10 23:39:52 but then you would lose vscode :) 2026-03-10 23:40:00 I'm not using vscode 2026-03-10 23:40:06 or whoever wanted it 2026-03-10 23:40:08 Ok, I would like to keep them as long as there isn't a real reason to drop them (like relyong on EOL toolkits) 2026-03-10 23:40:34 but yes, things like signal desktop for example, were things i were considering there 2026-03-10 23:40:42 telegram 2026-03-10 23:40:48 telegram is qt 2026-03-10 23:40:57 yes 2026-03-10 23:41:08 my point is that these are apps tied to an upstream lifecycle 2026-03-10 23:42:05 and upstream can block the old versions 2026-03-10 23:42:35 so from that perspective, it makes more sense to let upstream distribute those apps to users via flatpak 2026-03-10 23:43:00 another example, technically, would be audacious 2026-03-10 23:43:20 an audacious claim 2026-03-10 23:43:29 there is enough difference between different distro builds, that i know the current maintainers would prefer to live in a world where they just shipped a flatpak instead 2026-03-10 23:43:49 because every day someone installs on fedora and asks why they can't play mp3s or whatever 2026-03-10 23:43:58 (i guess now the problem is AAC files, but still) 2026-03-10 23:45:00 if only portals were working 2026-03-10 23:46:24 my impression of flathub is that the ratio of packages to developer is high and stuff gets blindly bumped 2026-03-10 23:46:25 "this opensource project would be great if it wasn't for the fucking users", to paraphrase Randal Graves 2026-03-10 23:46:41 i could be wrong 2026-03-10 23:47:17 invoked: i would be happier with flathub if it were strictly *upstream* developers (e.g. the people who maintain the code being built and distributed) pushing flatpaks there 2026-03-10 23:47:35 maybe someone should go build that :) 2026-03-10 23:48:10 I would be happier with flathub if it had a "free software only" policy 2026-03-10 23:48:30 I would be happier if it were the upstream developers maintaining their projects as aports :B 2026-03-10 23:48:31 some sort of build in CI then upload with OpenID Connect federation with the CI service 2026-03-10 23:48:49 omni: i do not think that Slack, Inc. will maintain their client in aports :p 2026-03-10 23:49:20 also i am not trying to slander flathub to state my preference for just having a path towards people just building "extra" locally 2026-03-10 23:49:21 do we have a slack aport? 2026-03-10 23:49:39 Noisytoot: yes, that is another gripe i have with flathub, the non-free software should be a separate repo 2026-03-10 23:50:45 I meant aports we have, but then again.. upstream developers are wrong 2026-03-10 23:50:55 (please take what I say with a grain of salt) 2026-03-10 23:51:00 one could technically host flatpak on github pages + releases 2026-03-10 23:51:43 pj: i think there is value in having something discoverable 2026-03-10 23:52:21 btw. frogejo and gitea have alpine repos support 2026-03-10 23:52:52 Ariadne: souns like an opportunity for AP 2026-03-10 23:54:09 pj: But forgejo only supports v2 indexes and at least to me it seemed like the private key has to be on the server to sign the index 2026-03-10 23:54:26 yuck 2026-03-10 23:54:39 re: frogejo, I actually wanted to host my ports on codeberg and was wondering if it was possible to limit keys used for signing index and for signing packages 2026-03-10 23:55:01 Yes, index is signed by git forge 2026-03-10 23:55:43 I wish there was a way to either treat that key as index-signing-only key or maybe add option to frogejo to push own index 2026-03-10 23:56:27 Sertonix[m]: they probably just took the index code from melange tbh 2026-03-10 23:58:29 IMHO this is a forgejo mis-design. Having 2 kinds of trusted signing keys is too likely to lead to (abusable) confusion in my opinion 2026-03-10 23:59:07 yes 2026-03-10 23:59:19 or you just dont trust them at all and --insecure 2026-03-10 23:59:43 anyway, i do not personally care if we package the entire world. i am not invested either way 2026-03-11 00:00:08 Ariadne: it's not melange code 2026-03-11 00:00:20 pj: yes, i went and looked 2026-03-11 00:35:27 I appreciate that these conversations are being had, because it's something that needs to be decided on. 2026-03-11 00:36:57 ariadne: but I agree, along with your previous comment, that Alpine needs a functional governance model to make these kinds of decisions so that all stakeholders can have their say in the matter, else the consequence can be demobilization. I know pabloyoyoista has been working on some ideas that I think can be useful for Alpine 2026-03-11 00:40:47 invoked: As for flathub, I tend to be pretty alergic to these solutions, preferring to put my time into packaging on Alpine for their to be applications available for users looking to use them. I built some infra around electron and signal-desktop to make it easier to maintain (i.e introduced my servers as runners to not clog up CI), and so far 2026-03-11 00:40:47 (apart from the hours it takes to rebuild), I've been pretty satisfied with the workflow. W/o the aport, Signal-desktop wouldn't really exist on Alpine on anything other than x86_64, unless you used an unofficial flathub. 2026-03-11 00:58:57 For example, I've invested heavily over the years (through adding dotnet, maintaining electron, navigating truly cursed build systems) to being more desktop apps to Alpine. It was actually a good intuition because pmOS came about. I'd be disappointed if a (non-collective) decision was made invalidating all of that work, on the basis of lack of 2026-03-11 00:58:57 infra when Alpine could have the resources if called upon. If a decision was made stating that Alpine is going a different direction, than I'd expect that decision to be a product of a function governance model. Fortunately, these problems aren't unique to Alpine, we can look at Debian for a (rather bureaucratic) example of thinking about 2026-03-11 00:58:57 governance models in tech. 2026-03-11 01:02:18 French collectives (on a more anarcho-syndicalist side of things) have developped also more decentralized (or federated) approaches to development (see free software syndicalism) if say Alpine would want to explore of more decentralized approach (i.e Alpine provides a shared core, where different projects - like pmOS - offshoot to provide for 2026-03-11 01:02:18 different use cases) 2026-03-11 01:03:15 bringing* 2026-03-11 01:09:50 yeah. there's a sort of meta thing, like, what differentiates alpine. we ultimately have some opinions/choices that make us different in base, and there's an identity around the rest of the system 2026-03-11 01:10:09 it's one thing to say, well, if you want to play steam games -- install flatpak 2026-03-11 01:10:19 (whatever) 2026-03-11 01:10:47 those are exceptional cases 2026-03-11 01:11:47 it feels to me like we lose some of our identity in giving more things up to flatpak 2026-03-11 03:36:34 what's the difference between this runner, and the other riscv64 CI runners: shared-runner (riscv64) siLj_NXxv, system ID: r_mjfEt4B6rOYF 2026-03-11 03:37:41 I seem to reliably trigger a crash when building a Go app (podman) only on that riscv64 runner, the other ones seem fine: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98824#note_590760 2026-03-11 04:02:39 craftyguy[m]: !98770 -- that runner happens to support vector instructions and happens to have a problem with them on go 1.26. we disabled riscv64 vector insns in go for the time being but it doesn't seem like the updated package has hit the builders yet, so the ci still runs the unpatched version 2026-03-11 04:03:17 so... i think it should resolve itself once build-edge-riscv64 gets to go 1.26.1-r1 2026-03-11 04:04:06 hmm wait, it already did build that. so why would your CI run have installed 1.26.0-r1 2026-03-11 04:05:07 oh wow, thanks for the info, I'll stop trying to debug this further 😅 2026-03-11 04:06:05 also... great timing on my part lol. I've been holding that patch for a while and decided to submit it exactly when this is happening 2026-03-11 04:08:10 I'm not sure why it installed 1.26.0-r1... the most recent failure was about an hour ago. maybe one of the cdn mirrors is not updated yet? 2026-03-11 04:09:47 maybe yeah. in either case i think the problem should go away with time once 1.26.1-r1 is available :p 2026-03-11 04:10:24 it's possible the builder *built* it but did not upload it yet, i can't see it on the mirrors either 2026-03-11 04:11:36 anyways, I'm totally fine waiting it out. I'm very relieved I don't have to try and debug why it was failing :D 2026-03-11 04:46:28 Hey Sertonix[m], I just pushed a change here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98828 2026-03-11 04:47:38 The reason I hadnt released was cause I wanted to write a blog post about this new release and I havent had time. 2026-03-11 04:48:45 Are you using honeybee? Does it work for you? 2026-03-11 05:51:33 Ariadne: The way opencollective works makes it less than trivial to use it for recurring infrastructure costs. 2026-03-11 05:52:27 And with the current infra, we cannot just throw money at it 2026-03-11 05:52:54 The extra infrastructure we received is really helpful, but disk space is still limited 2026-03-11 05:58:17 I mean, most of the infrastructure is sponsored, we cannot throw money at it to get more diskspace there 2026-03-11 06:01:21 So we need to change something structurely, for example by archiving older releases, but that's less effective untill relatively recent releases, and will probably break someones setup. 2026-03-11 06:01:35 And by reducing growth. Unbounded growth is unsustainable 2026-03-11 06:18:55 i mean we should do that 2026-03-11 06:19:04 i don't think we need ancient alpine 3.x releases on the main mirrors 2026-03-11 06:19:14 we could certainly move them to an archive server 2026-03-11 06:38:58 does alpine have any control over redirects on mirrors? If so, could maybe just spin up a single big disk server to hold the really old stuff and just have all the mirrors 301 to the "archive" server 2026-03-11 06:40:14 iggy: no 2026-03-11 06:40:31 At least, not on 3rd-party mirrors 2026-03-11 06:42:23 a new apk release on old versions that auto-rewrites? would require people to actually update (unlikely if they're running old versions) 2026-03-11 06:42:53 I'm out of bad ideas :/ 2026-03-11 06:44:03 it doesn't really sound like old releases are the real problem though (at the very least not _all_ of the problem) 2026-03-11 06:47:38 In any case not in the long run 2026-03-11 06:49:38 stop doing releases and become a strictly rolling upstream for others to make releases from? No wait, RedHat already did that with centos stream 2026-03-11 06:55:25 it seems like at some point an unsupported version should become a broken version, figuring out when that is gets tough... do you have metrics about most requested versions? If not from mirrors from the primary or from dl-cdn 2026-03-11 07:00:20 ncopa: !98833 -- or would you prefer to have the patch in github.com/ncopa/linux? 2026-03-11 07:25:17 lotheac: nice! I think its fine with that MR 2026-03-11 07:27:53 thanks go to the go people, they pointed me to the exact patch :) i had no idea what's going on 2026-03-11 07:28:50 after you have a chance update the kernel on nor-ci-1, i'll verify that re-enabling the go HasV doesn't crash on it 2026-03-11 07:29:23 (& undo the previous hacks from community/go) 2026-03-11 07:32:19 they said rvv doesn't work reliably prior to 6.9... but i guess we need to use 6.6 due to the vendor patches on this machine still? 2026-03-11 07:42:54 yes. I have followed the upstream progress, and I think there are still some things missing in 6.19 for spacemit k1 2026-03-11 07:43:15 I dont remember what it was, but it was something like the SD card or nvme 2026-03-11 07:43:39 or maybe I'm mixing with the p550 2026-03-11 07:47:01 ok, sounds like backporting the patch is the better move right now then 2026-03-11 07:48:08 do you want to test it on your hardware first, or should i just merge after ci is done 2026-03-11 09:07:42 i think you can just merge it once it passes 2026-03-11 09:09:38 achill: do you mind if I merge !98361 2026-03-11 10:40:25 anjan: I was only checking for aports which can't be installed. 2026-03-11 10:53:14 https://www.phoronix.com/news/RISC-V-Slow-Fedora-Packages Alpine and Chimera aren't the only ones 2026-03-11 10:53:43 Regarding saving of disk space on mirrors: Sharing noarch packages with same content across archrs should save at least 100GB for the alpine edge repositories. But until we have a way to add multiple signatures to the same package (which is only supported in the v3 format) we can't easily do that. 2026-03-11 10:57:44 Sertonix[m]: and the builder architecture does not support it either 2026-03-11 10:59:44 Yes, I know 2026-03-11 12:04:00 im currently blocked by py3-google-api-core: ModuleNotFoundError: No module named 'grpc_status' 2026-03-11 12:04:28 it looks like it is community/grpc that is supposed to provide that. I don't know why it doesn't 2026-03-11 12:15:45 there has been some changes in the google python ecosystem recently-ish 2026-03-11 12:16:34 mh, but it might be unrelated 2026-03-11 12:16:55 upgrading grpc would be nice, as the dependency on py3-six has been recently removed :3 2026-03-11 12:16:56 could be it's in https://pypi.org/project/grpcio-status/ now 2026-03-11 12:32:48 ok, well, that's part of the grpc repo/tarball but the APKBUILD doesn't seem to build/package it 2026-03-11 12:36:24 that makes sense 2026-03-11 13:00:40 👋 2026-03-11 13:02:25 Sorry in advance if that sounds pushy, that's not the attention here. But may I bribe someone to have a look at some opened merge request on the abuild side? 👼 2026-03-11 13:03:56 There's a few cool stuff in there, although I'm primarily interested into this one: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/468 2026-03-11 13:04:28 I'm looking forward to backport this change set into the abuild Arch Linux package, which would allow to use the `abump` script there 2026-03-11 13:05:22 (Since only `abuild rootbld` is relevant / possible to use on non Alpine / apk based distros) 2026-03-11 13:07:33 Having this being approved / merged before I backport it on the Arch Linux side would make sense I guess :) 2026-03-11 13:10:36 There are other cool MRs (IMO) opened for abump specifically, but the above one would greatly ease / streamline Alpine packaging from non-Alpine based distros (hence my current interest for it) :) 2026-03-11 13:35:10 anyone available to help create a package of? https://pypi.org/project/grpcio-status/ 2026-03-11 15:25:17 ncopa: a bit late i guess but yeah sure 2026-03-11 17:19:19 ncopa: feel free to merge it 2026-03-11 17:20:12 otherwise i should do the kernel upgrades but im currently kinda busy so i dont have any eta 2026-03-11 17:37:39 ncopa: !98863 2026-03-11 18:05:22 Is it still required / recommended to specify provider_priority for virtual-packages? It used to be that apk would otherwise not know which provider to choose. 2026-03-11 18:13:30 Fun, new curl security release requires ngtcp2, which is not packaged yet 2026-03-11 18:13:50 So I suppose we would need to manually backport those fixes... 2026-03-11 18:13:53 for old releases 2026-03-11 18:14:13 configure: error: nghttp3 enabled without a QUIC library; enable ngtcp2 2026-03-11 18:14:45 a secfix requires a new dep? ffs 2026-03-11 18:14:56 invoked: it's a new release 2026-03-11 18:15:06 ok 2026-03-11 18:15:12 But curl only provides new releases 2026-03-11 18:15:53 ie, no security backports 2026-03-11 18:16:09 madness. 2026-03-11 18:16:17 So you have to either upgrade to the latest version, or manually backport patches 2026-03-11 18:19:26 I guess it's because they dropped support of openssl-quic 2026-03-11 18:19:30 https://github.com/curl/curl/pull/20226 2026-03-11 18:19:37 "curl users building with vanilla OpenSSL can still use QUIC through the means of ngtcp2" 2026-03-11 18:23:32 achill: any opinion what we should do? ship ngtcp2 or drop quic? 2026-03-11 18:23:50 According to that PR, openssl-quic was experimental 2026-03-11 18:38:29 ikke: i dont really mind, i would look into shipping ngtcp2 but i also dont have time this or next week to look into it 2026-03-11 18:38:53 I'll check to see how much work it is 2026-03-11 18:39:24 looks like main/ngtcp2 is available, no? 2026-03-11 18:39:53 oh 2026-03-11 18:40:37 I saw: checking for libngtcp2 options with pkg-config... no 2026-03-11 18:40:43 and searched for: pc:ngtpc2 2026-03-11 18:40:47 and it returned nothing 2026-03-11 18:41:25 ahh yeah thats mean :p 2026-03-11 18:42:41 ok, yeah, ngtcp2-dev works 2026-03-11 18:46:29 vquic/curl_ngtcp2.c:37:10: fatal error: ngtcp2/ngtcp2_crypto_quictls.h: No such file or directory 2026-03-11 18:49:33 Ours is built against libretls, while curl expects quicktls, gnutls or wolfssl 2026-03-11 19:20:14 help to update easyeffects? https://gitlab.alpinelinux.org/alpine/aports/-/issues/17987 2026-03-11 19:34:39 realroot[m]: you need to update Qt6Gui it seems 2026-03-11 19:34:52 or tweak the required version to accept 6.10.1 2026-03-11 19:35:10 and add all the missing dependencies 2026-03-11 20:49:10 ptrc 2026-03-11 21:10:37 So we're a bit in a bind with curl.. 2026-03-11 21:11:29 uh oh, what happened with curl? 2026-03-11 21:13:12 security release, they dropped openssl-quic, and nghttp3 requires a quic implementation 2026-03-11 21:13:55 oh jeeze :/ 2026-03-11 21:13:56 ngtcp2 is offered as an alternative, but our ngtcp2 is built against gnutls 2026-03-11 21:15:44 So basically, we cannot quickly apply upstream security fixes 2026-03-11 21:17:25 The alternative is manually backporting the security fixes, but that's also not without risk 2026-03-11 21:21:15 could just disable quic for now until ngtcp2 is figured out 2026-03-11 21:22:20 Would mean disabling nghttp3 2026-03-11 21:23:36 Which will probably break some usecase 2026-03-11 21:23:38 yeah. i mean, it'll probably bust what someone wants to do, but it'll buy some time 2026-03-11 21:23:42 especially if you have to backport 2026-03-11 21:24:09 curl has a distributors meetup soon, I'll be joining it 2026-03-11 21:24:53 I can build curl with removing nghttp3 indeed 2026-03-11 21:25:07 Let's see if the build completes 2026-03-11 21:27:09 so quictls for ngtcp2 is deprecated, openssl is experimental.. 2026-03-11 21:27:28 We use gnutls, but not sure if you can combine that with curl built against openssl 2026-03-11 21:29:10 https://github.com/ngtcp2/ngtcp2/issues/2034 2026-03-11 21:31:25 seems unlikely 2026-03-11 21:32:52 ngtcp2 would need to go openssl, and then someone would have to figure if that causes a regression somewhere else 2026-03-11 21:37:23 dropping http3 in curl (for now) at least buys time to work on that. i doubt it'll break much unless someone is testing http3 with curl specifically 2026-03-11 21:39:47 which honestly ... who knows. maybe there are monitoring plugins that do that. no clue 2026-03-11 21:41:20 I have locally built ngtcp2 with an openssl backend 2026-03-11 21:41:24 That seems to work as well 2026-03-11 21:41:35 but the APKBUILD explicitly set openssl to off 2026-03-11 21:42:19 invoked: you know hyrums law 2026-03-11 21:42:41 :) 2026-03-11 21:43:13 http3 + ngtcp2 is marked as not experimental in curl 2026-03-11 21:43:15 https://curl.se/docs/http3.html 2026-03-11 21:46:06 "the used QUIC library needs to consider itself non-beta" 2026-03-11 21:47:13 "it is fine to "leave" individual backends as experimental if necessary" 2026-03-11 21:47:57 i dunno, 4 medium vulns (the proxy one seems more than medium to me) 2026-03-11 21:48:21 it's a predicament 2026-03-11 21:48:28 yes 2026-03-11 21:49:00 people who depend on http3 don't care if it fixes some security issue if they can no longer use the library 2026-03-11 21:49:51 In any case, both options are not helping with backporting it to stable releases 2026-03-11 21:50:14 i don't know what curl does, i'm assuming it falls back to http2 like browsers do 2026-03-11 21:50:49 I have no idea 2026-03-11 21:51:09 if it were me, i'd say it's more important to get these vulns fixed and risk the wrath of a small cohort 2026-03-11 21:51:24 not the end of the world 2026-03-11 21:51:43 but unfortunately it's you, sorry :/ 2026-03-11 21:53:15 it would be nice if curl did their releases differently 2026-03-11 21:53:28 It's certainly something I'm going to bring up 2026-03-11 21:53:34 I know bagder did comment on it before 2026-03-11 21:56:52 why not build curl against gnutls too? 2026-03-11 22:01:02 that's only for things that need libcurl-gnutls, unless i'm mistaken 2026-03-11 22:16:26 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98883 2026-03-12 03:08:59 shouldn't be rustc patched to increase stack size to fix p521 2026-03-12 03:10:27 gitui and rbw have workarounds in APKBUILDs but that still leaves rustc broken outside of aports 2026-03-12 07:08:42 Does anyone here know why alpine doesnt enable openrc parallel boot? I wrote in #alpine-linux about it 2026-03-12 07:11:31 Imbus: parallel openrc is full of issues and much less reliable than serial openrc 2026-03-12 07:13:36 Are there issues documented somewhere? 2026-03-12 07:13:51 cant find any notes about it from upstream 2026-03-12 07:15:16 not that I know of. It will be fixed at *some* point but navi has other priorities atm. 2026-03-12 07:16:02 presumably related to ordering? 2026-03-12 07:17:18 yes and no. Full readiness notification is needed for ordering to work, yes, but afaik it's in place now (it wasn't when parallel openrc was written at first) 2026-03-12 07:17:37 but mostly it's a question of unreliable implementation with busylooping all over the place 2026-03-12 07:18:30 basically if you enable rc_parallel, you'll get a zillion processes busylooping until their dependencies are met and it's Not Good 2026-03-12 07:19:26 bottom line is "use at your own peril" 2026-03-12 07:21:06 Amazingly, it is the only way I can get qemu to work on my skylake desktop, however 2026-03-12 07:21:29 If I do serial openrc, all the services bomb and it can't be started. If I do parallel, it works. No idea why. 2026-03-12 07:21:54 On my other machines, it leads to issues, as skarnet noted. Usually around NFS mounting at boot 2026-03-12 07:22:24 wdym by "get qemu to work"? if serial fails it's probably a timeout somewhere 2026-03-12 07:23:09 "works with parallel but not with serial" smells very bad XD 2026-03-12 07:25:23 I mean qemu, libvirt, and the assoicated services to run virt-manager do not start (they all state failed/crashed) in Serial 2026-03-12 07:25:54 Thrashing about I enabled parallel and it worked, disabled, everything breaks, re-enable it all works. I gave up trying to figure why 2026-03-12 07:26:01 This persists across reformats on that machine, too 2026-03-12 07:26:06 No other machine has that behavior 2026-03-12 07:26:54 it sounds like the services have interdependencies and are waiting for each other with timeouts or something, and when launched in parallel they manage to communicate with each other, but in serial obviously not 2026-03-12 07:28:08 That sounds very reasonable 2026-03-12 07:28:23 Could be why I can't replicate it on slower / lower core-count machines 2026-03-12 07:28:41 but, my N350 (about the same perf and same thread count) does not have that issue and starts fine in serial 2026-03-12 07:29:11 there's probably an unresolved dependency loop, I'm in the (slow) process of analyzing all the services in Alpine (to go towards service manager independence) and I'll take a look at it when I get to qemu 2026-03-12 07:29:34 it will be... this summer most likely ^^' 2026-03-12 07:29:37 Oh wow, thanks 2026-03-12 07:29:44 I was just going to say, all of that to say, s6 plz 2026-03-12 07:30:03 it's on the way, slowly ^^" 2026-03-12 07:30:07 If you need me to capture a log or something, let me know 2026-03-12 07:30:20 thanks. Will do. Again, probably this summer. 2026-03-12 07:30:31 My wife's desktop is hardware-identical and will have that same SSD in it, but my original desktop is sold 2026-03-12 07:31:32 if you have issues with a given type of hardware and not with others, it may be completely unrelated, e.g. qemu has problems on this hardware only 2026-03-12 07:32:04 no idea why parallel would make it work aside from timeouts magically being met 2026-03-12 07:34:33 I would assume someone would have found out 2026-03-12 07:34:38 Skylake i7-6700k 2026-03-12 07:34:41 Not exactly uncommon 2026-03-12 07:34:59 On my N3450 or N350 machines, sure, not many folks using qemu on those 2026-03-12 07:56:49 lotheac: thank you very much! 2026-03-12 07:57:12 np 2026-03-12 07:57:28 incidentally i am more than happy to take over leading the security team again. the conflict-of-interest (working at an Enterprise Linux vendor) has been resolved for 2 years now. 2026-03-12 08:06:52 actually i am happy to do anything and everything necessary to get many things unstuck 2026-03-12 08:18:30 Ariadne: thats great! appreciate that 2026-03-12 08:18:58 things are moving slow currently due to many of us a busy with other stuff 2026-03-12 08:39:11 But moving non-the-less 2026-03-12 08:43:24 Ariadne: nice :) welcome back 2026-03-12 08:44:55 well, it depends 2026-03-12 08:45:24 no takebacks! ;) 2026-03-12 08:50:19 look, i am just being honest, because one of the things i learned when reflecting on things is that sometimes i put myself forward without setting clear preconditions and boundaries, which has in the past led to unfortunate disagreements 2026-03-12 08:51:22 aelin is right, i should not be asked to do security reviews if i am not an active member of the security team (and indeed, i have been informally acting in that role for some time already, which is not good but also necessary given the current governance situation) 2026-03-12 08:53:33 and because of this situation i debate moving on, because from my perspective alpine is a community of lovely people without any clear technical direction, and frankly, i am a technical architect so that is a discordance that i do not find particularly comfortable 2026-03-12 08:55:02 but then... i move on. where do i go? what do i do? working on an Enterprise Linux distribution certainly did not bring me joy 2026-03-12 08:57:26 glad that you're back, if it's what you decide 2026-03-12 08:57:55 i mean i have wanted to be back for 2 years. 2026-03-12 09:01:48 i think alpine is growing from being a traditional distribution, to being a meta-distribution. i think without strong leadership and good architectural decisions, this transition will be a disaster. 2026-03-12 09:02:59 i think the people who recognize this and have the vision to guide us in this moment are not equipped to do so 2026-03-12 09:03:13 and, bluntly, i think *that* is the root of the governance crisis 2026-03-12 09:04:49 whether we like it or not, the reality is that we have grown from being simply a mainline distribution to being the baseline for real derivatives with real users. some commercial, like alpaquita and WizOS, and some non-commercial like postmarketOS. 2026-03-12 09:06:11 yeah, I can see that 2026-03-12 09:07:06 as an aside, IMO we should be asking the commercial downstreams to support us financially. 2026-03-12 09:08:22 that can only happen when a clear vision and strong governance is established, I think 2026-03-12 09:08:35 that's why i said it was a side item :p 2026-03-12 09:11:18 so without a path to rapid resolution of the dysfunctional governance, i am not sure what my joining the security team will accomplish (other than my delegated authority becoming formal authority again) 2026-03-12 09:21:10 anyway... 2026-03-12 09:22:09 i think council needs to be expanded to 5 seats, and TSC needs to be expanded as well to either 9 or 11 seats. 2026-03-12 09:23:31 i think the entire TSC membership needs to be scrapped and reconstituted based on who is presently active in the project, and who is actually pushing meaningful architectural-level work in the project 2026-03-12 09:24:09 We are already working on that 2026-03-12 09:24:15 i also think that there needs to be at least one person from pmOS on TSC. 2026-03-12 09:24:20 With the help of Pablo 2026-03-12 09:27:00 however... at the same time, while we should make it *easy* for pmOS to get what they need done in Alpine, we need to protect against Alpine's identity as an independent (and importantly non-GNU operating system) OS being compromised 2026-03-12 09:27:42 one of the reasons why I have mixed views on systemd is because if Alpine were to adopt systemd, we would basically land at "basically GNU/Linux, but with a different ABI" and that seems not great 2026-03-12 09:28:23 importantly that isn't anything against systemd, i think they do a lot of really interesting stuff, but what keeps me "hooked" with Alpine is that we built an independent operating system with its own distinct identity 2026-03-12 09:28:49 but with *that* said, pmOS deserves and needs representation. 2026-03-12 09:29:55 Yes, with our current plan, they will 2026-03-12 09:31:03 (and yes pablo is somebody who i think is a big picture thinker and sees where we need to go. i trust his judgement after spending quite a bit of time talking to him, both on IRC and in person :)) 2026-03-12 09:35:38 so, what i would say is, i am willing to help wherever. but the thing is, in order for *me* to be helpful to alpine in it's current moment, i need appropriate authority. 2026-03-12 09:36:14 that does not mean council per se, but it certainly means TSC, and it certainly means the council meets on a regular basis and does what people on the TSC ask it to do in a timely manner. 2026-03-12 10:01:01 also, since i am dropping a manifesto, i would like the TSC to formally state that ports are allowed to have architectural baselines that exceed minimum viable spec. that belief is not true, has never been true, and leads to unnecessary friction. 2026-03-12 10:01:42 alternatively, i would like to force the x86-32 port to be i486, which will effectively kill it :) 2026-03-12 10:03:28 (save some space on the mirrors with this one little trick :D) 2026-03-12 10:12:20 why i486 2026-03-12 10:14:18 Ariadne: isn't it already i586 2026-03-12 10:14:21 Or i686 2026-03-12 10:14:32 it is i686+SSE2, which is effectively P4 and Athlon XP 2026-03-12 10:14:50 pj: i386 is no longer supported by Linux kernel 2026-03-12 10:15:21 Ariadne: so isn't it already far above i486? 2026-03-12 10:15:53 it has been at least i586 for a while now 2026-03-12 10:15:55 so I don't get the comment about i386 2026-03-12 10:15:58 i486 2026-03-12 10:15:59 yes, because the people who make the decisions for the x86 port decided that i686+SSE2 is the realistic baseline to have a fully functioning distribution on that architecture 2026-03-12 10:17:16 I mean, it's not really people deciding on the port, it's software/compiler devs not wanting to support it either 2026-03-12 10:17:29 it is both 2026-03-12 10:17:37 iirc, isn't go incompatible with anything below i586 2026-03-12 10:17:44 or even i686 2026-03-12 10:18:01 yes, which is why Alpine requires i686+SSE2. thank you for making my point. 2026-03-12 10:18:39 if it was not obvious, my point is that if porting teams must target the lowest possible CPU spec that Linux will boot on (in the case of LoongArch tsc#101, -mno-lsx) then we should also force x86-32 to follow that requirement 2026-03-12 10:18:44 well, you have not made yours so far 2026-03-12 10:20:54 (tsc#101 will eventually move forward, but only because GCC 16 has acceptable codegen) 2026-03-12 10:21:03 yes, excellent work algitbot 2026-03-12 10:22:15 in re go there is always the possibility of using gccgo instead of golang. (not a serious proposal.) 2026-03-12 10:22:24 gccgo is unusable 2026-03-12 10:22:59 it is barely usable to even bootstrap go 2026-03-12 10:23:22 i do not think it works for that anymore :( 2026-03-12 10:23:46 i think it would be even easier to just go from old C codebase 2026-03-12 10:28:17 won't that lead to less performance on some hw? 2026-03-12 10:28:35 won't what lead to less performance? 2026-03-12 10:29:46 probably not using newer cpu instructions 2026-03-12 10:30:04 >=i586 2026-03-12 10:32:28 f_: in the case of tsc#101, yes disabling vectorization will hurt performance. GCC 16 seems to have sufficient codegen improvements that some of that performance loss is offset. 2026-03-12 10:32:50 Ariadne: sure, but how about other arches? 2026-03-12 10:33:03 f_: that 2026-03-12 10:33:14 f_: that's my point, porting teams should be the ones making that decision 2026-03-12 10:33:22 okay 2026-03-12 10:34:11 (tbh, it's incredible alpine still supports x86 at all, nice work whoever is maintaining this) 2026-03-12 10:34:19 basically i would like the tsc to affirm this 2026-03-12 10:34:47 so that when people ask for things porting teams are unwilling to support, we can point at the TSC decision 2026-03-12 10:35:01 they can always appeal to the TSC, of course, if they have some compelling argument 2026-03-12 10:37:07 makes sense 2026-03-12 10:40:36 community/nickel was deadlocked on build-edge-x86. I killed it 2026-03-12 10:40:49 perfect timing to say this ncopa xD 2026-03-12 10:41:15 03:03 (save some space on the mirrors with this one little trick :D) 2026-03-12 10:43:18 yeah, 32 bit is painful nowadays 2026-03-12 10:43:33 mostly i want the TSC to formally state that so next time we get some retrocomputing weirdo with their Vortex86 CPU that claims to be i686 but isn't, we can direct them to the TSC statement saying that ports do not have to meet any minimal baseline 2026-03-12 10:43:57 Ariadne: Didn't we already do exactly that 2026-03-12 10:43:59 ? 2026-03-12 10:44:08 we did for vortex86 specifically 2026-03-12 10:44:14 my ask is to make it generic 2026-03-12 10:46:33 for example, in loongarch tsc#101 we agreed to try reducing the baseline to allow the cheap $25 loongarch SBCs with the introduction of GCC 16. but if the loss of autovectorization results in too much of a performance regression, then we may abort that change because protecting the baseline performance of loongarch desktop users (where Alpine is actually somewhat popular) is a higher priority than the $25 SBCs 2026-03-12 10:47:41 so if the porting team decides reverting that change is necessary, a statement from the TSC backing our authority to do so would be nice to have 2026-03-12 10:48:17 i get it. we need a decision 2026-03-12 10:48:30 sometimes even a bad decision is better than no decision 2026-03-12 10:49:26 (my preference is that we can support the $25 loongarch SBCs without hurting desktop performance too much, but the port was originally for desktop SKUs anyway) 2026-03-12 10:50:48 this kind of issue also exists on armv7 btw 2026-03-12 10:51:29 i think we should drop armhf (armv6) 2026-03-12 10:51:40 approved 2026-03-12 10:51:47 some armv7's lack neon. Alpine works mostly fine on them until the moment you try running e.g. firefox (not a good example, but some other things are compiled under the assumption that neon is supported) 2026-03-12 10:52:15 ok new proposal, gut TSC and Council, make me CEO of Alpine 2026-03-12 10:52:24 everyone will get what they want 2026-03-12 10:52:25 ncopa: some ports in postmarketOS are armhf for legacy reasons 2026-03-12 10:52:31 except for the ones who don't 2026-03-12 10:52:32 FYI 2026-03-12 10:53:18 legacy reasons meaning, these ports are supposed to be for armv7 devices, so there's no reason they need to be armhf 2026-03-12 10:53:35 so can we fix them? 2026-03-12 10:53:43 yes we can 2026-03-12 10:53:55 should be trivial, but also most of them are using downstream 3.x kernels 2026-03-12 10:54:00 so they may break at any moment 2026-03-12 10:54:12 lovely... 2026-03-12 10:54:48 ha! 2026-03-12 10:54:50 The only reason for us to keep armhf atm are some of the rpi boards 2026-03-12 10:55:02 its rpi 1 and rpi zero 2026-03-12 10:55:10 i think rpi zero is still produced 2026-03-12 10:55:20 Ariadne: I guess we can just move them to armv7, if it builds and someone can test then we can ship it, else it goes in the archived/ category 2026-03-12 10:55:25 yes they extended production 2026-03-12 10:55:39 none of us want to put any substantial effort into downstream ports 2026-03-12 10:55:44 they keep doing that 2026-03-12 10:56:00 if they build and boot that's good, else we just archive it and move on 2026-03-12 10:56:05 rpi zero is EOL in 2030 https://endoflife.date/raspberry-pi 2026-03-12 10:56:33 that is 4 years from now 2026-03-12 11:00:48 RPi 1 is still produced too 2026-03-12 11:01:05 it is rpi 1 a+ now 2026-03-12 11:03:34 https://fosstodon.org/home 2026-03-12 11:03:46 sorry https://fosstodon.org/@ncopa/116215867094108492 2026-03-12 11:03:59 I did not expect this, but out of all the "armhf" devices pmOS supports, only RPi1 and Zero are actual armhf 2026-03-12 11:04:06 the rest are all armv7 running armhf alpine 2026-03-12 11:05:35 (though there is a considerable amount of armv7 devices pmOS boots on) 2026-03-12 11:06:37 but yes out of like 735 devices, only 2 are actual armhf/armv6 2026-03-12 11:07:12 all other 26 "armhf" devices supported are actually armv7 2026-03-12 11:08:08 and out of all of them, only one (armv7 pretending to be armhf) runs a mainline kernel 2026-03-12 11:08:31 anyway what I'm saying is it's not a huge loss if armhf gets dropped. 2026-03-12 11:21:10 i think it would simplify maintenance a bit 2026-03-12 11:21:29 reduce load on mirrors, maintainers, CI etc 2026-03-12 11:23:50 I think most maintenance effort would be prevented by automatically disabling blocked packages. 2026-03-12 11:49:12 fwiw I wanted to drop armhf in pmOS for a long time, but the consensus so far was that we're going to keep it as long as Alpine supports it since the effort is quite low, but we barely have any packages that compile for it 2026-03-12 11:49:22 dropping armhf and keeping armv7 would make me quite happy ^^ 2026-03-12 13:09:06 I support what sertonix says, we can keep armhf with the absolute minimum maintenance by inheriting the armhf-optout of dependencies 2026-03-12 13:09:45 I believe that would be a good middle ground between the actually people still using it and us having more work because of it 2026-03-12 14:57:49 aelin: as I explained above, I think pmOS w/o armhf really would only drop like 2 devices (pi0, pi1) out of like 735, because all our armhf ports are actually for armv7 devices and should be moved there 2026-03-12 14:58:03 Maybe worth discussing at some point 2026-03-12 14:58:24 out of 28* 2026-03-12 14:59:01 but I think armv7 should be kept because a considerable amount of devices pmOS supports are armv7 2026-03-12 15:00:57 so I'm against dropping armv7, especially as I do rely on an armv7 device myself 2026-03-12 15:07:29 ACTION has an armv5 device :] 2026-03-12 15:15:11 What are you running on it? 2026-03-12 15:17:31 Nothing really, it's an old D-Link NAS 2026-03-12 15:45:52 d-link is a brand i haven't heard in a while. 2026-03-12 15:49:27 Caveat: I've only skimmed the log, so I may have missed details. 2026-03-12 15:49:40 but on the (few days ago) topic of pruning packages and py3-* 2026-03-12 15:50:11 I am the (totally absent) Maintainer of a couple py3-qt* packages that I don't ever use. 2026-03-12 15:50:23 and iirc they have no rdepends 2026-03-12 15:50:43 but it seems that somebody uses them. 2026-03-12 15:52:21 I would love to A. pass off maintainership to someone who actually uses them, and/or B. remove whatever isn't actually used by anyone. 2026-03-12 15:53:02 py3-qt6, py3-qt6-pyc, and py3-pyqt6-sip 2026-03-12 15:54:08 roselandgoose: I just looked up py3-qt6 has 30 rdepends. but I can work up an MR to adopt these, unless someone else wants them 2026-03-12 15:54:08 I can't actually build them locally in a sane amount of time, and (for example) they currently have weird build errors on riscv (happens) 2026-03-12 15:55:29 jvvv: oh! that is good to know. I must have run the wrong rdepends command (considering only installed or w/e) 2026-03-12 15:56:21 it will return 0 if you don't have it installed, at least 'apk info -r' will 2026-03-12 15:56:51 that would be much appreciated :) I do have a script lying arround for translating the python dep info to apks, btw 2026-03-12 15:57:02 I dont know how other py3-* maintainers handle that. 2026-03-12 15:57:10 And just asking apk would exluce make/checkdepends as well 2026-03-12 15:57:18 exclude* 2026-03-12 15:58:02 yep. I use 'find aports -name APKBUILD -exec grep -H 'aport_name' {} \;' for that 2026-03-12 15:58:29 ap revdep for each repo would work as well 2026-03-12 15:58:33 ap is from lua-aports 2026-03-12 15:58:58 Nice, I have that installed. I need to use it more apparently. 2026-03-12 16:01:17 neat! 2026-03-12 16:02:38 roselandgoose: I am in the middle of several things rn, but will submit an MR for those aports today, tomorrow if I run into issues buildingg any update 2026-03-12 16:03:03 :D thx 2026-03-12 16:03:21 You're welcome 2026-03-12 17:43:06 If I am pushing a change meant to fix test failure on a specific build arch and I leave off the pkgrel bump, will the builder pick up that change? 2026-03-12 17:44:41 yes 2026-03-12 17:44:59 The builder will keep on trying to build that package, since that specific version+pkgrel combination is still missing 2026-03-12 17:45:20 So indeed not necessary to bump pkgrel 2026-03-12 17:46:12 Thank you 2026-03-12 17:47:12 (lua-aports buildrepo determines which packages still need to be built, in case you were interested) 2026-03-12 17:48:41 I need to work with the various lua and go aports tools more so I can be more familiar with them. Thanks for the pointer, always appreciated. 2026-03-12 17:53:59 !98926 2026-03-12 19:11:08 btw i'll look at the curl MR in a few mins, im currently grabbing something from the supermarket 2026-03-12 19:11:17 achill: ack, thanks 2026-03-12 22:02:17 roselandgoose: !98930 and !98931 2026-03-13 03:59:43 dne: Are you working on py3-pyserial? Because I followed the link you supplied about it in #18025. I need py3-pyserial as dep of a dep for an update I'm working on, so I tried building it with the patch from that PR. I built successfully. 2026-03-13 04:00:17 *It built 2026-03-13 06:47:00 Hello, can someone review !98796 please? 2026-03-13 06:48:04 jvvv: please go ahead, haven’t had the time, other than looking up that patch 2026-03-13 07:11:37 good morning! 2026-03-13 07:11:56 just want to express my gratitude for all the help with fixing the python 3.14 stuff 2026-03-13 07:11:59 Morning 2026-03-13 07:12:19 i now have ~470 packages built of 1700 2026-03-13 07:12:22 aports 2026-03-13 07:12:43 and we have two more weeks to go before we need to start with the 3.24 builds 2026-03-13 07:17:58 eh the release is already coming. Someone could give a chance to this one, that is waiting for a while please :3 2026-03-13 07:18:00 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91737 2026-03-13 07:33:48 merged. thanks! 2026-03-13 07:40:46 thanks a lot! \o/ 2026-03-13 09:31:04 ** WARNING: connection is not using a post-quantum key exchange algorithm. 2026-03-13 09:31:20 im getting that warning, and then im not able to log in. it just hangs 2026-03-13 09:36:06 hum... something happened to my network 2026-03-13 09:47:41 or soemthing happened to ssh client 2026-03-13 09:48:12 no, its my ssh config thats broke 2026-03-13 10:07:38 dotnet8-runtime test fails on stable branches on x86_64 2026-03-13 10:08:29 dotnet-trace fails 2026-03-13 10:09:15 and it has not yet been pushed to edge... 2026-03-13 11:11:19 anyone available who can help with main/py3-poetry-core and community/poetry upgrades? i now have 13 tests failing on poetry with python 3.14 2026-03-13 11:20:29 ok, I have disabled the failin tests of poetry. I have pushed to my python-3.14 branch 2026-03-13 11:21:02 https://gitlab.alpinelinux.org/ncopa/aports/-/commits/python-3.14 2026-03-13 12:51:19 hi could someone review (and potentionally merge) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96377? 2026-03-13 14:48:12 so, verdict, alpine drops armhf? 2026-03-13 15:08:35 thats for the TSC to decide 2026-03-13 15:12:45 ncopa: Sorry, was afk when you asked... but I did work on getting py3-poetry-core and poetry working locally. I need to look at it again but if it does more than skip tests, should I submit MR(s) for such? 2026-03-13 15:14:02 ncopa: I was messing with the poetry stuff in conjunction of getting something else figured out, so just never got back to it last night, though I had intended to. 2026-03-13 15:51:28 please don't drop armhf 2026-03-13 15:52:26 I have alpine on a pi zero 2026-03-13 15:57:45 simply dropping armhf from mainline does not mean that armhf users are necessarily stranded 2026-03-13 16:56:50 im over poetry. next is py3-lazy-object-proxy 2026-03-13 17:14:04 Ariadne: can you elaborate? 2026-03-13 17:14:17 f_: #alpine-ports 2026-03-13 17:14:38 not registered 2026-03-13 17:14:49 it exists 2026-03-13 17:14:52 you can join it 2026-03-13 17:14:52 :p 2026-03-13 17:15:03 yes, I'm just sayin' :P 2026-03-13 17:15:22 and yes, we kinda fucked up there 2026-03-13 17:15:45 I take it that "alpine ports" initiative you were talking about way back is kind of a thing now? 2026-03-13 17:16:04 Ariadne: you can always beg oftc to /samode #alpine-ports +o Ariadne 2026-03-13 17:16:08 :P 2026-03-13 17:17:52 Ariadne: so your idea is to have armhf unofficially supported under the alpine-ports umbrella, right? 2026-03-13 17:18:13 yes, i think that one is really easy for us to do 2026-03-13 17:18:27 how would that work? 2026-03-13 17:19:06 what do you mean? we build the aports repos and publish the packages, like we do with other ports. 2026-03-13 17:19:25 https://codeberg.org/alpine-ports 2026-03-13 17:19:32 I mean, what would be the difference compared to "regular" alpine 2026-03-13 17:20:28 oh okay right 2026-03-13 17:21:49 also i do not think ircd-hybrid has SAMODE. 2026-03-13 17:22:21 it doesn't, but you get what I mean 2026-03-13 17:25:11 and +o Sertonix would be more appropriate, as they have been leading the initiative 2026-03-13 17:27:49 I can ask #oftc 2026-03-13 17:28:48 Ariadne: sertonix is on matrix so that won't work very well I thin 2026-03-13 17:28:49 k 2026-03-13 17:31:51 should I add it to matrix space :> 2026-03-13 18:01:53 i don't know, it is unofficial 2026-03-13 18:19:44 ncopa: py3-lazy-object-proxy !98967 2026-03-13 18:40:18 what's the purpose of the alpine-ports thing? Just curious 2026-03-13 18:41:07 Combination of forces for people who want to port alpine linux to architectures that we don't 2026-03-13 18:41:51 Combining* 2026-03-13 20:10:02 durrendal: alpine on things like, say, my Amiga A3000. retro and/or exotic architectures that alpine itself does not need to provide builds for 2026-03-13 20:14:54 Neat! I like the idea :) 2026-03-13 20:15:40 Also sounds like it could be a good home for arches that lost support to go, like mips. 2026-03-13 20:27:22 Ariadne: will it run on the a2286? ;) i used to have one of those. 2026-03-13 20:28:10 invoked: any 68k should work 2026-03-13 20:32:40 i don't think i ever used it once. in my younger days, i worked weekends at a commodore retailer, and i was talked into that board 2026-03-13 20:33:44 if it wasn't that one, maybe it was the xt. i forget. one of the two 2026-03-13 21:10:29 Ariadne: did you just say that alpine runs on m68k now? 2026-03-13 21:13:11 there is a port in progress, mostly not being done by me, but someone else on fedi 2026-03-13 21:13:15 i forget their handle :) 2026-03-13 21:13:18 cool 2026-03-13 21:13:39 so alpine-ports is basically alpine for fun arches and alpine-linux is alpine for boring arches ;) 2026-03-13 21:14:17 very interesting! 2026-03-13 21:16:49 LE might be boring but i'm ok with it 2026-03-13 21:17:19 me too 2026-03-13 21:17:32 but you know, it's fun to see alpine running on an m68k, or even on a nintendo wii 2026-03-13 21:37:57 alpine does not support any non-hf arm arches, right? 2026-03-13 21:38:55 Habbie: correct 2026-03-14 01:16:57 Does anything on the system return the path to wasi-sysroot? 2026-03-14 03:39:16 Hi all! check this out, An Unknown Artist - https://www.anunknownartist.com/ 2026-03-14 13:47:22 hi, any idea why no runner wants to pick my job? https://gitlab.alpinelinux.org/user0-07161/aports/-/jobs/2259365 2026-03-14 13:47:57 Because they are busy 2026-03-14 14:03:52 i see 2026-03-15 00:06:46 has anyone played with fil-c on alpine already? 2026-03-15 00:10:07 not according to git log aports 2026-03-15 09:32:54 I have compiled fil-c on alpine once and started writing an APKBUILD 2026-03-15 12:26:33 ikke: i will merge !99013 if you don't mind (and close !99002) 2026-03-15 12:26:49 Yeah, fine with me 2026-03-15 12:27:17 thanks 2026-03-15 12:27:59 hopefully this will actually upload the go riscv64 vector workaround to the mirrors :D 2026-03-16 08:08:41 morning 2026-03-16 08:08:46 src/fontforge-20251009/fontforge/ffpython.h:39:10: fatal error: Python.h: No such file or directory 2026-03-16 08:08:56 i get similar error with community/rpm 2026-03-16 08:09:05 python 3.14 that is 2026-03-16 11:47:07 duc: can you please fix your connection? 2026-03-16 11:49:20 i dont get it. why does not cmake set the /usr/include/python3.14 cflag, but it does set /usr/include/python3.12 2026-03-16 11:49:31 both fontforge package and rpm 2026-03-16 12:43:16 Upgrade to dotnet 10.0.201 is done, unfortunately build artifacts were too large CIs failed: !99062 2026-03-16 12:45:54 hi, while updating a APKBUILD, i noticed that my -udev-rules subpackage generate a warning as should be named -udev, how can i make the new subpackage -udev replaces the old -udev-rules one ? 2026-03-16 12:57:15 ayakael: too large artifacts does not make the build fail 2026-03-16 12:58:12 At least, it should not 2026-03-16 13:12:47 `ERROR: Uploading artifacts as "archive" to coordinator... 413 Request Entity Too Large id=2261527 responseStatus=413 Request Entity Too Large status=413 token=64_scJgA9 2026-03-16 13:12:47 FATAL: too large` 2026-03-16 15:02:54 Does anybody know if qemu-system-arm on alpine edge x86_64 got slower in the last few months? I don't remember it being as slow as it is now 2026-03-16 16:14:22 by the way, I noticed I can't label the issues I create, does that require some sort of permissions? 2026-03-16 16:14:34 I see a few "/label" lines but they don't seem to work 2026-03-16 16:15:44 f_: yeah, you need to be at least developer before you can set labels 2026-03-16 16:15:59 ah 2026-03-16 16:16:01 I had some plan to add some label support to aports-qa-bot, but haven't got time for it yet 2026-03-16 16:16:07 right ok 2026-03-16 16:19:38 also is the pmOS gitlab integration working now? 2026-03-16 16:19:48 I saw a "login with postmarketOS" button 2026-03-16 16:20:07 oh, good question. I haven't tested it yet 2026-03-16 16:21:10 I don't have an account on pmOS, so someone with a pmOS account should test it out 2026-03-16 16:21:52 I'll give it a shot 2026-03-16 16:34:46 ikke: it doesn't work 2026-03-16 16:34:57 :( 2026-03-16 16:35:46 when I click on "Connect postmarketOS" in the preferences it just redirects to some oauth/authorize page on gitlab.pmos.org and then that just redirects to some issue I wrote 2026-03-16 16:36:20 maybe it needs something on pmOS side 2026-03-16 16:39:55 When I do it, I get redirected to the sign-in page (because I don't have an account) 2026-03-16 16:48:18 I do too 2026-03-16 16:48:26 but when I sign in that's all it does 2026-03-16 19:24:02 ok I think I need help with the cmake and python cflags things 2026-03-16 20:53:13 ncopa: Is that for fontforge and rpm? 2026-03-16 20:53:50 yeah, but I got help from Ariadne 2026-03-16 20:54:07 it is ccache that 2026-03-16 20:54:16 it was ccache that messed up things 2026-03-16 20:55:50 Ah, OK, I built both on my python3.14 vm and had no troubles... thought maybe I was missing something. 2026-03-16 20:56:37 Sorry that I've been inactive last day or two, just getting over a stomach bug. 2026-03-16 20:56:52 aw... i hope you feel better 2026-03-16 20:57:08 Thanks, I do. 2026-03-16 21:08:30 ikke: i tried the login with postmarketOS thing and the Alpine GitLab gives me "Invalid grant: the provided authorization grant is invalid, expired, revoked, does not match the redirection uri used in the authorization request, or was issued to another client" 2026-03-16 21:08:36 seems like a different error than f_ is seeing 2026-03-16 21:33:52 hmpf. freecad fails to build now 2026-03-16 21:33:53 so:libvtkCommonCore.so.1 (no such package): 2026-03-16 21:33:53 required by: opencascade-7.9.3-r0[so:libvtkCommonCore.so.1] 2026-03-16 22:17:24 I think vtk 9.52 PR 2026-03-16 22:17:40 Needs to finish building 2026-03-16 22:17:48 Floppy is looking into it 2026-03-16 22:25:14 the MR to rebuild opencascade against that vtk is still draft, so the problem will persist until opencascade rebuild 2026-03-16 22:25:40 !98792 2026-03-16 22:25:56 Yeah, I pinged them to take a look 2026-03-16 22:26:15 I am talking about !98961 2026-03-17 07:47:39 morning! thanks for following up with the vtk stuff 2026-03-17 07:48:19 anyone available to help with ktoblzcheck? it needs a version bump to 1.59 but there are tests failing with python 3.14 2026-03-17 07:53:58 ncopa: I am 2026-03-17 09:45:41 ncopa: I'm not getting anywhere with ktoblzcheck. 2026-03-17 10:25:18 ncopa: Only thing I can think of is to skip the tests. So far, I have looked at debian, fedora, arch, gentoo, opensuse... none of them are running the tests. Some, like debian, have a note about several of the tests being broken. 2026-03-17 10:26:07 https://salsa.debian.org/debian/libktoblzcheck/-/blob/master/debian/rules?ref_type=heads 2026-03-17 10:38:09 ok. anyone reported it upstream? 2026-03-17 10:38:19 i suppose we can disable the test 2026-03-17 10:53:26 unfortunately, it is more than just the python test failing that I have seen. 2026-03-17 10:53:44 I will look upstream now 2026-03-17 11:00:15 The bug list has only 5 items, none seem related to the errors I have seen. From what I can see, it seems like the ktoblzcheck-data needs to be installed. I am working on packaging that, just to confirm that theory. 2026-03-17 11:07:22 https://tpaste.us/nN04 2026-03-17 11:09:19 i saw those tests failing as well. it is only 1 test that fails with the current version 2026-03-17 11:16:49 yes, same here 2026-03-17 11:25:28 im looking at py3-truststore. looks like example.com cert is not validating properly. 2026-03-17 11:25:39 curl https://example.com also fails 2026-03-17 11:25:52 curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20) 2026-03-17 11:31:16 seems like the root cert is not trusted 2026-03-17 11:31:26 depth=2 C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2 2026-03-17 11:31:28 verify error:num=20:unable to get local issuer certificate 2026-03-17 11:33:18 yeah, so maybe our ca-certificates is outdated? 2026-03-17 11:33:46 chromium trusts it 2026-03-17 11:34:09 and so does firefox 2026-03-17 11:34:51 We have NSS_3_120_RTM 2026-03-17 11:39:59 There is a newer version: https://gitlab.alpinelinux.org/alpine/ca-certificates/-/merge_requests/25/diffs, but only seems to add e-Szigno TLS Root CA 2026-03-17 11:40:38 fwiw `curl https://example.com` fails on fedora 44 but works on debian stable, so it could be ca-certificates is too recent instead? 2026-03-17 11:43:05 on debian it apparently finds `depth=3 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services` above CN=SSL.com TLS Transit ECC CA R2 2026-03-17 11:44:49 https://gitlab.alpinelinux.org/alpine/ca-certificates/-/blob/master/certdata.txt#L673 2026-03-17 11:45:34 ah I think it's signed with sha1, let me try to accept sha1 in openssl.cnf I always need to look that up... 2026-03-17 11:47:05 (probably not that, sorry need to afk) 2026-03-17 11:55:14 whoopsie! i upgraded chromium and no I get "Illegal instruction" when I try to start up chromium 2026-03-17 11:55:26 [0317/125407.498665:WARNING:third_party/crashpad/crashpad/snapshot/linux/process_reader_linux.cc:95] sched_getscheduler: Function not implemented (38) 2026-03-17 11:55:26 Illegal instruction 2026-03-17 11:55:56 $ chromium 2>&1 | tpaste 2026-03-17 11:55:56 https://tpaste.us/zP0Z 2026-03-17 11:55:56 Illegal instruction 2026-03-17 11:57:17 https://gitlab.alpinelinux.org/alpine/aports/-/issues/18057 2026-03-17 12:01:08 cmake debug output is useless 2026-03-17 12:06:00 Ok so I think it is a sha1 problem, not with the signature of the SSL.com TLS Transit ECC CA R2 which is sha256 but of the root CA itself whicch is self-signeed with sha1WithRSAEncryption 2026-03-17 12:06:04 curl -s https://raw.githubusercontent.com/zerotier/edge/refs/heads/master/usr/share/ca-certificates/mozilla/Comodo_AAA_Services_root.crt | openssl x509 -noout -text 2026-03-17 12:06:32 Could that make the ca-certificates makefile not inclde it in the bundle? I don't see this certificate in the bundle 2026-03-17 12:08:35 appending that manually to /etc/ssl/certs/ca-certificates.crt makes curl example.org work so it's definitely not included, but I'm not sure what the cause is 2026-03-17 12:23:49 That logic would be here then: https://gitlab.alpinelinux.org/alpine/ca-certificates/-/blob/master/c_rehash.c?ref_type=heads 2026-03-17 12:34:20 Running `mk-ca-bundle.pl` with an additional -v says `Skipping: Comodo AAA Services root lacks acceptable trust level`, so I think it'd be that one -- trust level? are apparently configurable, e.g. using the big hammer of `-p ALL:ALL` makes that CA get included, but I'm not sure we want to play with that 2026-03-17 12:34:33 Time to look if I can figure what options firefox would be using 2026-03-17 13:00:49 ... okay, so first, debian's ca-certificates doesn't use mk-ca-bundle.pl and I think their script just basically ignores trust level, so that's why it works on debian... But that's not why it works in firefox: looking at the cert in firefox I get a different certificate chain. depth=0 and 1 are the same two certs, but depth=2 is a different CN=SSL.com TLS Transit ECC CA R2 (we have one up to Dec 31 2026-03-17 13:00:55 23:59:59 2028 GMT signed by CN=AAA Certificate Services, firefox lists one up to Oct 17 17:02:22 2037 GMT signed by CN=SSL.com TLS ECC Root CA 2022 -- and _that_ CA we do trust in our bundle) 2026-03-17 13:02:10 Now I don't get why firefox has a different chain here, I'd assume it's not using what the server sends but somehow has a newer copy of the intermediate certificate in its keyring? We don't have CN=SSL.com TLS Transit ECC CA R2 in certdata so I don't see it... 2026-03-17 13:05:08 Anyway, I'm tempted to close this as "not our bug" -- we could add the AAA CA in the bundle but since it's explicitly not trusted to delegate server certificates I think we're correct in not adding it, and we'd want to fix that at mozilla level for everyone if it should be trusted.. (or the server configuration could be updated to list the new chain, even if the old one is theorically still valid..) 2026-03-17 13:23:13 (ah, taking back my remark on debian, using the ca bundle in debian sid correctly excludes that CA -- so it's been removed somewhat recently) 2026-03-17 13:28:23 fedora has same problem indeed 2026-03-17 13:29:58 Hi, bot is poking me about my stalled mr !96626 2026-03-17 13:33:19 to be precise the root for example.com was removed in https://gitlab.alpinelinux.org/alpine/ca-certificates/-/commit/0da13f6975bbb4558a8f4d08274f1bd293eb607e -- Comodo AAA Services root and a few others went from CKT_NSS_TRUSTED_DELEGATOR to CKT_NSS_MUST_VERIFY_TRUST which is not added to bundle 2026-03-17 13:44:41 curl https://example.com on debian and ubuntu appear to work, but thats probably due to old ca-certificates 2026-03-17 14:27:06 yes, it fails on sid 2026-03-17 16:32:41 ayakael: is it expected that (at least a large part) of electron is built single core? 2026-03-17 16:33:29 Hmm, SAMUFLAGS=-j1 for some reason 2026-03-17 16:53:17 Turned out I had a stray JOBS=1 in my env :/ 2026-03-17 17:57:51 haha. (i try to fix that type of stuff by giving myself 20 pushups each occurrence. which doesn't work but my delts and tris are not bad.) 2026-03-17 20:09:21 It wasn't even in a config file or anything, just ephemeral in the ssh session where I tried to build electron 2026-03-17 21:58:46 is there a way to show the key a package was signed with? I used tar to extract the .SIGN.RSA.foo@bar.rsa.pub from an apk, but it isn't plain text 2026-03-17 22:01:42 A package doesn't contain the key, the file name indicates the key and the contents is a binary signature 2026-03-17 22:41:38 ncopa: after packaging ktoblzcheck-data and add that to checkdepends for ktoblzcheck, I am down from 8 tests failing to 2. 2026-03-17 23:22:14 maybe I should take a step back on my question. I'm trying to generate an index for a package repo I have and some of the packages are showing an error `BAD signature` but not all of them, but I'm pretty sure I built all of them with the same key. Not sure what to check next. The apk version is 3.0.4, but I normally index this repo with a tool that uses the apk go package (which 2026-03-17 23:22:16 works) and I'm pretty sure I've previously index'ed this repo with a < 3.0 apk fine 2026-03-18 01:58:41 p_6f3Ik7Suw: This can compile some simple static binaries at least: https://codeberg.org/sertonix/rports/src/branch/main/random/fil-c/APKBUILD 2026-03-18 03:04:24 ncopa: I seem to be stuck getting ktoblzcheck to pass the last 2 tests, but I have pushed a branch to my gitlab.a.o fork so you can see where I am at: https://gitlab.alpinelinux.org/jvvv/aports/-/tree/ktoblzcheck?ref_type=heads 2026-03-18 05:29:18 ncopa, jvvv: something like !99203 ? 2026-03-18 05:45:15 never mind, the BANKDATA_PATH gets hardcoded if set that way 2026-03-18 06:17:32 updated the MR with an initial draft 2026-03-18 09:25:05 Sertonix[m]: thx! when you say at last some simple static does that mean it fails with complex dynamic ones? 2026-03-18 10:05:32 python 3.14 progress: Total: 1090/1529 2026-03-18 10:05:40 thats pretty good! 2026-03-18 10:06:20 hum... maybe the counting is wrong... 2026-03-18 10:06:57 $ git log --format=oneline origin/master.. | wc -l 2026-03-18 10:06:57 655 2026-03-18 10:07:08 which sounds more correct to me 2026-03-18 10:07:29 nice either way 2026-03-18 10:20:15 #17970 for visibility 2026-03-18 10:20:54 for example, there's tree-sitter and some related aports that would need new maintainer(s) 2026-03-18 10:24:37 there's also !97550 2026-03-18 10:24:49 mainly python aports 2026-03-18 11:58:59 ok, mopidy needs a fix for pkg_resources https://github.com/mopidy/mopidy/commit/136c6f435eafecb56d6b56d970db12c098cd88a2 2026-03-18 11:59:06 but the patch does not apply 2026-03-18 12:00:16 maybe we should switch to 4.0.0a15 2026-03-18 12:01:26 anybody available to follow that up? 2026-03-18 12:12:15 p_6f3Ik7Suw: It seems to fail with dynamic linking and I haven't tested complex ones. 2026-03-18 15:51:02 Sertonix[m]: hmm, interesting, thx! 2026-03-18 17:38:54 anyone has time to look at !99199 ? 2026-03-18 18:05:55 ubprocess.CalledProcessError: Command '['/usr/bin/pnpm', 'run', 'bundle']' died with . 2026-03-19 06:27:53 What would make the package contents of a local build different from what the runner generated with the same apkbuild? 2026-03-19 06:28:20 For evolution-tray, my local build generated the gsettings schema and it is in the apk,, but the build server one is missing that file 2026-03-19 06:28:34 Build log doesn't seem to obviously say why 2026-03-19 06:30:27 Most obvious cause would be some hidden dependency that is present locally but not in the build environment 2026-03-19 06:32:58 Hmm, okay, and something their build/configure script doesn't call out as a log item then? 2026-03-19 06:36:11 You can use the registry.alpinelinux.org/alpine/infra/docker/build-base image to get a similar environment as CI 2026-03-19 06:41:04 ikke: re: alpine/go... I've been using it to generate apkindex files, but it seems terribly slow (about 8x slower than apk to read packages/create index... mostly the read packages part). From digging around, it seems like a big part of it is the fact that it reads the entire package out into some temp files and does a lot of extra processing (vs apk that just reads the 2026-03-19 06:41:06 meta/control streams directly). Would you be open to some new functionality that could support that kind of use case? Or maybe that just what ParsePackage should do? It doesn't look like it uses more than the control stream anyway 2026-03-19 06:43:09 iggy: yes, improvements are welcome 2026-03-19 06:44:03 The current implementation was contributed by chainguard 2026-03-19 06:47:09 And absolutely, I would prefer if using a tmpdir can be avoided completely 2026-03-19 06:49:54 ikke, you're a genius 2026-03-19 06:50:07 rgr, I'll look into it a little more and maybe open an issue to throw around some ideas... Just didn't want to spend too much time on it if the current code was meeting everybody else's expectations 2026-03-19 06:50:24 !99254 has the fix in for the missing schema 2026-03-19 06:51:20 As and aside, once someone makes an activitypub plugin for Evolution, I don't think I'll ever need to leave it 2026-03-19 10:18:16 jvoisin: hey! thanks for upstreaming the patches from nsjail. it was on my todo list, but you beat me to it. very cool. 2026-03-19 10:36:14 jvvv: the dev is an ex-colleague of mine, couldn't pass on the occasion :D 2026-03-19 10:36:20 thank you for maintaining nsjail <3 2026-03-19 10:47:34 it is a pleasure to maintain, nsjail is very handy tool, been using it very quite some time. 2026-03-19 11:33:53 we have a week or two before I start setting up 3.24 builders. If you need anything in that is related build toolchain those changes needs to happen within a week or two 2026-03-19 11:34:01 i think we should tag new abuild release as well 2026-03-19 11:35:28 current python 3.14 build failure: community/onboard 2026-03-19 11:35:46 seems like this project has not had any releases since 2017. maybe we should delete it 2026-03-19 11:36:58 Daanct12: ^ 2026-03-19 11:38:32 ncopa: yeah, let's do that. it's only for x11 anyways 2026-03-19 11:38:48 im not sure how many users uses it 2026-03-19 11:44:46 Daanct12: please give an 'ok' https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99273 2026-03-19 11:48:52 fwiw, it is an accessibility package 2026-03-19 11:50:11 abby: it's an on screen keyboard/osk 2026-03-19 11:50:36 yes, that's an accessibility feature 2026-03-19 11:50:47 for computers without a keyboard, right? 2026-03-19 11:51:00 or people who can't use a keyboard 2026-03-19 11:51:13 OH 2026-03-19 11:51:20 sorry 2026-03-19 11:52:32 when i think about a11y, i think of screen reader, high contrast and braille, not an osk 2026-03-19 11:53:41 ubuntu 26.04 has py3.14 and onboard, though they might have switched to their own git snapshot 2026-03-19 11:53:51 https://packages.ubuntu.com/source/resolute/onboard 2026-03-19 11:54:02 need to look into that for void 2026-03-19 11:54:47 personally i don't use x11 anymore, so i think i'll go on with removing it from alpine 2026-03-19 11:55:17 if people are interested in maintain it, they can do it 2026-03-19 11:55:33 ncopa: i'll reply to the mr when i can get access to my account 2026-03-19 12:54:58 next stop is community/picard which has a failing test. Did not find any obvious fix within 5 mins. anyone volunteer to look at that? 2026-03-19 13:17:49 i have a fix for picard 2026-03-19 13:20:12 i dont. I have a fix for picom 2026-03-19 13:23:03 FYI, gitlab will be restarted in about 10 minutes 2026-03-19 13:24:21 👍 2026-03-19 14:26:37 I use onboard 😬 2026-03-19 14:32:59 Danct12: this would need adjustments in pmOS 2026-03-19 14:34:04 that being said, onboard is hosted on Launchpad's bzr hosting which will shut down soon 2026-03-19 14:36:38 Interesting, armv7 finished first building chromium 2026-03-19 14:40:59 (In CI) 2026-03-19 14:57:21 nice 2026-03-19 15:20:18 ncopa: https://tpaste.us/MYoP fixes picard tests. It was manually cherry picked from picard commit ebb146465655dcaa68c9f1d23af728f309d45d35. For py3.14, build and check succeeds but fails when splitting the picard-lang subpkg. 2026-03-19 15:34:31 f_: how about you maintain it :D 2026-03-19 15:34:47 no use for it sorry :p 2026-03-19 15:34:56 i don't think there are any x11 users on postmarketOS anymore 2026-03-19 15:35:05 there are still a few 2026-03-19 15:35:19 ikke: how long build? 2026-03-19 15:35:46 well not that many enough to maintain it 2026-03-19 15:36:00 maybe 2026-03-19 15:36:15 i guess the only users on x11 are downstream kernels 2026-03-19 15:36:19 yeah 2026-03-19 15:36:26 for the most part 2026-03-19 15:36:39 downstream kernel are mostly useless when running anything other than fbdev 2026-03-19 15:37:21 panekj: 11h39m 2026-03-19 15:37:36 panekj: 12h08m for aarch64 2026-03-19 15:37:49 x86_64 still running 2026-03-19 15:38:07 darn 2026-03-19 15:38:10 yikes 2026-03-19 15:38:19 good thing we have sponsors 2026-03-19 15:38:28 otherwise that'd be unbuildable for most part 2026-03-19 15:38:38 does CI share CPU time with other runs? 2026-03-19 15:38:55 for first time armv7 is faster 2026-03-19 15:38:56 pj: In general, yes 2026-03-19 15:39:12 (I guess it's just an aarch64 running in 32bit mode though?) 2026-03-19 15:39:19 f_: correct 2026-03-19 15:39:22 possibly other job running on x86? 2026-03-19 15:39:50 still +7h for browser build is ew 2026-03-19 15:39:54 firefox builds in 1h 2026-03-19 15:40:20 I was wondering if there is (s)ccache and if it could use it 2026-03-19 15:41:10 c++ is a hell of a drug^Wlanguage to build and especially link 2026-03-19 15:42:15 I'm not so sure that it is C++ fault 2026-03-19 15:42:23 webkit isn't exactly fast to build either afaiu 2026-03-19 15:43:55 pj: would that help when builders are distributed 2026-03-19 15:43:55 maybe it's just the amount of code in general, but i'm sure that c++ link times don't help .) 2026-03-19 15:45:25 caching compiler outputs only helps if you're compiling the same thing multiple times, which generally should not be the case for distro package builds (something changed -> rebuild needed) 2026-03-19 15:45:26 yes and no? 2026-03-19 15:46:08 like, if jobs are bouncing between machines then it would be hard because cache is local to the machine unless using sccache which can keep cache in some remote place like s3 or other stuff 2026-03-19 15:46:58 lotheac: caching compiler outputs helps exactly in such scenario where the package doesn't change that frequently and most of the build remains the same between updates 2026-03-19 15:47:30 if *any* of the inputs to the build change, including compiler versions or any dependency version, you have to rebuild anyway 2026-03-19 15:47:43 sure 2026-03-19 15:47:49 ok, fine, same compiler, same input source file and headers -> yeah, cache hit 2026-03-19 15:47:56 ncopa: fixing picard's lang subpackage is easy. i'll push an MR shortly 2026-03-19 15:48:03 but i'm not convinced it would be a huge win 2026-03-19 15:48:29 happy to be proven wrong though! 2026-03-19 15:48:52 consider: CI builds the package for 12h, MR is merged, now builders are building the exact same package again 2026-03-19 15:49:30 they do build it normally in 7h because they don't get multiple jobs but if they had most of the build built already? 2026-03-19 15:50:20 pj: aarch64 and armv7 run on the same host 2026-03-19 15:50:23 for sanity and security reasons i would actually prefer that CI is completely separate from package builders and that CI cannot even theoretically affect built packages, but yes, i see what you are saying 2026-03-19 15:50:37 I agree with lotheac there 2026-03-19 15:51:35 now, if you showed instead that two separate builds of some version of chromium actually had most CUs not change at all, and could be cached - that would be a different story :) 2026-03-19 15:51:42 some two versions, i mean 2026-03-19 15:52:46 pj: on x86_64, we have some more nodes, chromium is on a node with no other builds 2026-03-19 15:54:34 maybe at some point will try to help it :> 2026-03-19 15:55:03 ikke: CI? 2026-03-19 15:55:06 yes 2026-03-19 15:55:16 huh 2026-03-19 15:55:37 maybe it's docker penalty? 2026-03-19 15:56:09 Not docker, and all CI runs in containers 2026-03-19 15:56:24 And builders use LXC containers 2026-03-19 15:57:04 builders are beefier than CI? 2026-03-19 15:57:39 We have various servers for CI 2026-03-19 15:57:57 All in all, builders do have more cores and memory 2026-03-19 15:58:02 for x86_64 2026-03-19 15:58:38 oh, x86_64 now finished as well 2026-03-19 16:03:16 ncopa: !99279 2026-03-19 16:07:31 hmm, buildbot seems broken on edge 2026-03-19 16:07:42 ModuleNotFoundError: No module named 'cairocffi' 2026-03-19 16:09:04 buildbot-badges to be exact 2026-03-19 16:10:24 cairocffi, cairosvg and klein, where klein is not in aports 2026-03-19 18:55:40 jvvv: thanks! 2026-03-19 19:00:44 now its py3-dask. looks like it can be upgraded, but has lots of failing tests. It may also need to revisit the dependencies 2026-03-19 19:06:10 548 failed, 14882 passed, 1299 skipped, 426 xfailed, 192 xpassed, 6 warnings, 238 errors in 76.27s 2026-03-19 19:06:10 (0:01:16) = 2026-03-19 19:06:44 $ git diff | tpaste 2026-03-19 19:06:44 https://tpaste.us/0xXN 2026-03-19 19:06:57 in case anybody wants to have a stab at it 2026-03-19 19:07:03 im gonna skip it for now 2026-03-19 19:21:10 ok there are a bunch of packages in the dependency chain for py3-dask 2026-03-19 19:32:40 ncopa: i'm working on it... the dep tree is pretty deep, but i'll see what i can do 2026-03-19 19:35:37 thank you! 2026-03-19 19:36:26 easier task if someone else is up for it is py3-audioread. we need 2 new dependencies: 2026-03-19 19:36:29 "standard-aifc; python_version >= '3.13'", 2026-03-19 19:36:29 "standard-sunau; python_version >= '3.13'", 2026-03-19 19:37:08 so we need create py3-standard-{aifc,sunau} packages 2026-03-19 19:54:14 those two probably originate from the same upstream source 2026-03-19 19:54:55 https://github.com/youknowone/python-deadlib 2026-03-19 20:08:44 they do. the other option is to let the import of those be optional 2026-03-19 20:09:49 fedora simply removed them: https://src.fedoraproject.org/rpms/python-audioread/blob/rawhide/f/0001-Remove-legacy-sound-modules-absent-in-Python-3.13.patch 2026-03-19 20:10:50 im gonna fix audioread 2026-03-19 21:13:49 python progress: 2026-03-19 21:13:49 Progress: 689/1505 2026-03-19 21:13:49 Total: 816 (to build) 2026-03-19 21:14:12 this is excluding the 28 packages in py3-dask dependency tree 2026-03-19 21:14:51 today has been significant progress, thanks to all the help I have got with fixing things 2026-03-19 21:26:32 py3-spsdk needs an update 2026-03-19 21:27:07 and it needs to remove py3-commentjson dep which was removed as dep in 1.6.0 2026-03-19 21:27:24 in other words, the dependency list needs to be updated 2026-03-20 04:21:29 Ohttps://ilot.io/apps/onlyoffice/s/sco8518-tp4?fileId=3531568 2026-03-20 04:22:57 woops 2026-03-20 08:08:04 Congrats WhyNotHugo 🍻 2026-03-20 08:10:43 Congrats indeed, well deserved! 🎉 2026-03-20 08:26:38 promoted as alpine dev? :) 2026-03-20 08:29:29 https://gitlab.alpinelinux.org/alpine/council/-/issues/702 2026-03-20 08:42:57 \o/ 2026-03-20 09:08:49 Thanks all! 2026-03-20 10:09:20 WhyNotHugo: congrats! 2026-03-20 10:56:53 ncopa: thanks! 2026-03-20 11:00:18 Congrats! 2026-03-20 13:57:17 Congrats! 2026-03-20 14:18:01 Just like your username says 🤣 2026-03-20 14:18:01 Congrats! 2026-03-20 14:32:33 congrats hugo 2026-03-20 14:49:55 cheers! :) 2026-03-20 14:50:28 yay! 2026-03-20 15:41:12 anyone can help me version bump py3-cx_freeze? I think it will help with the python 3.14 rebuilds 2026-03-20 15:41:42 its weekend now. Have a nice weekend everyone! 2026-03-20 16:30:03 Builders failed for one failed on a single architecture (404 fetching sources, network glitch?). This gets auto-retried, or requires some intervention? 2026-03-20 16:30:39 nvm, I see it retried and worked 2026-03-20 16:31:24 Only edge is auto retried 2026-03-20 16:31:36 you can poke algitbot to send a retry command: 2026-03-20 16:31:42 algitbot: retry 3.23-stable 2026-03-20 18:46:42 congrats WhyNotHugo ^^ 2026-03-20 20:16:49 more testing of !99332 would be appreciated 2026-03-20 20:16:59 then we can merge it maybe tomorrow or the next days 2026-03-20 20:33:36 ncopa: it has been brought up that onboard actually has a new upstream on github 2026-03-20 20:33:41 and that's what's used in ubuntu 2026-03-20 20:33:49 github.com/onboard-osk/onboard 2026-03-20 20:33:50 onboard-osd? 2026-03-20 20:34:05 yeah 2026-03-20 20:34:27 Saijin_Naib[m] mentioned it 2026-03-20 20:34:31 ah 2026-03-20 20:35:20 were there any objections for readding onboard with this new upstream? 2026-03-20 20:35:31 all I can see right now is "will it stay maintained?" 2026-03-20 20:36:42 ok I see Saijin_Naib wants to package it 2026-03-20 20:38:41 If someone else can keep it in community, that would be my preference 2026-03-20 20:39:05 Else, I can pakcage in testing for now while this new fork gets a good test 2026-03-20 20:39:30 I don't actually really use onboard, but if no one can look after it I wouldn't mind 2026-03-20 20:41:20 If I package it as contrib, do you want maintainer? 2026-03-20 20:41:31 I'll help with routine bumps and such 2026-03-20 20:42:02 don't really feel strongly about it, whichever makes sense to you 2026-03-20 20:43:26 I'll go that route 2026-03-20 20:43:36 I may have time tonight to try it 2026-03-20 22:06:12 f_ It might be a bit of work to package from first glance, as we have to package a sub-module (py3-pypredict) that it uses as a text prediction engine, and tests fail without it 2026-03-20 22:06:21 Also, that is handy to have for sure 2026-03-21 03:08:13 Would it be useful if maintainer= supported multiple values (like subpackages=)? 2026-03-21 03:22:47 Could be, yeah. Or maybe more teams are needed. I put an RFC for an xfce team, where onboard is recommended and used by many distros, so a team/xfce could fill that 2026-03-21 03:36:07 Teams sound good for DEs or groups of packages. But it's not flexible for having two or three people maintaining a single package in an ad-hoc way. 2026-03-21 03:42:24 Very true 2026-03-21 06:34:03 heyo. trying to build an aports package -- installed apk-tools, but `abuild -h` says `Unable to deduce build architecture: Install apk-tools or set CBUILD`. i've already installed apk-tools, and i can't find anything on this `CBUILD` in the packaging wiki entry. anyone know what it is? 2026-03-21 06:40:32 jj: what architecture are you on? What does apk --print-arch return? 2026-03-21 06:41:10 x86_64 2026-03-21 06:41:30 it's old x86_64 though, but i don't think that'd make any difference 2026-03-21 06:42:24 oh -- `sudo abuild -h` works. what's up with alpine's sudo / non-sudo separation btw? 2026-03-21 06:43:02 (i.e. the "my unpriviledged user doesn't have `apk` in PATH" thing) 2026-03-21 06:43:56 jj: that's not expected 2026-03-21 06:44:31 oh? interesting. this has been the case on two alpine installs so i thought it was... 2026-03-21 06:45:46 `whereis` points me to `/sbin/`. is this not part of a normal install? 2026-03-21 06:51:28 cool yup okay, adding `/sbin/` to PATH solved my problem. shocked i didn't run into issues w/ not having it earlier tbh (beyond needing to `sudo` unnecessarily) 2026-03-21 06:54:41 er. actually, another question. `abuild checksum` reports a permission error writing to `/var/cache/distfiles/`, `sudo abuild checksum` fails with a warning to not run it as root. what's up here? the wiki doesn't suggest anything 2026-03-21 07:43:34 you should add your user to abuild group (which has g+w on that dir) 2026-03-21 08:50:56 thx! missed that step in the build env setup 2026-03-21 10:22:13 would anyone be able to look at !99242 ? currently keyd is broken in edge and this would fix it 2026-03-21 10:31:13 WhyNotHugo: multiple maintainers was discussed somewhere already but I couldn't fond where. Maybe it was on IRC? 2026-03-21 12:13:24 ikke: I still have`413 Request Entity Too Large` on !99062 2026-03-21 12:13:30 Have any idea why that is ? 2026-03-21 14:23:37 ayakael: my guess is that the total size of the reports (build log, some extracted logs) is larged than the artifact size 2026-03-21 14:24:31 Allowed artifact size* 2026-03-21 17:39:10 Hi, !98772 - an update for existing component (xilinx bootgen, from version 2021.1 to latest 2025.2). Unfortunately it seems maintainer is away, could someone take a look to it. 2026-03-21 19:44:34 musl 1.2.6 is now in alpine o/ 2026-03-21 20:04:14 thank you for your service 2026-03-21 20:38:53 dont thank me, thank dalias for pressing the tag button :p 2026-03-21 20:44:37 Sweet! Are we getting closer to musl locales support baked in? 2026-03-21 20:50:38 finally the FILE write procfs bug is fixed? although alpine was carrying the patch for a while ig? 2026-03-21 20:52:14 What bug? 2026-03-21 20:54:27 kcxt[m]: yeah for alpine it had no effect, but finally being in a release is still a major +1 2026-03-22 04:03:02 Could someone merge !99317? 2026-03-22 09:28:14 mio: Do you think we should still package community/cheese? It is archived upstream and depends on clutter which is archived upstream as well 2026-03-22 09:31:55 You could remove it next time GTK breaks API, shouldn't be too long 2026-03-22 12:18:30 qutebrowser/qt6-qtwebengine crashes consistently for me with musl 1.2.6, have worked around it by downgrading to 1.2.5-r21 for now 2026-03-22 12:22:42 omni: any traceback? 2026-03-22 12:23:32 haven't looked into it further, tabs are SIGSEGV crashing 2026-03-22 12:24:16 I first thought it was my last qtwebengine chromium security upgrade, but downgrading qt6-qtwbengine didn't help, downgrading musl did 2026-03-22 12:24:35 I'll see if I can provide more later 2026-03-22 12:25:49 reminded me that I have a couple of other aports pinned to older releases... 2026-03-22 12:57:22 ../../../../../src/3rdparty/chromium/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall nr=0x148 arg1=0x15 arg2=0x7f405776c250 arg3=0x1 arg4=0x0 2026-03-22 13:41:23 omni: hm I had the new musl with qutebrowser used since yesterday 2026-03-22 13:41:39 haven't noticed anything bad and restarted qutebrowser a couple of times afaik 2026-03-22 13:41:53 I'm not home until this evening, but I can check then again 2026-03-22 13:42:53 Sertonix[m]: yeah please just remove it. upstream has moved to snapshot some time ago and cheese will just keep getting a pain for us 2026-03-22 13:43:13 quinq: cheese is already at gtk3 lol 2026-03-22 13:43:34 omni, achill, can reproduce the qutebrowser crash here 2026-03-22 13:44:18 achill, “already” when current version is 4.22 ;) 2026-03-22 13:44:35 that's what I meant 2026-03-22 13:45:24 ah :> 2026-03-22 13:46:33 148, sched_rr_get_interval 2026-03-22 13:49:56 Why would it fail though 2026-03-22 13:52:16 which arch? 2026-03-22 14:03:35 amd64 2026-03-22 14:03:46 seccomp-bpf failure 2026-03-22 14:03:50 maybe that's rather *their* issue 2026-03-22 14:20:25 oh ok 2026-03-22 14:20:38 get different issues here on armv7 2026-03-22 15:59:40 Sertonix[m]: mostly kept it as it used to be a relatively known app, not sure if there are still users. as quinq mentioned, it's probably only a matter of time it stops working if there isn't a new fork or revived upstream. would be fine with removing if people have moved on to alternatives 2026-03-22 16:01:03 maybe some mention of other options would be good when the time comes 2026-03-22 16:01:10 I think everybody should have switched to snapshot by now 2026-03-22 16:02:46 I am trying to remove clutter* and that is one package depending on it 2026-03-22 17:27:08 I noticed musl does not include arc4random. Where can i get this? Should i use libbsd here, or am i missing something obvious? 2026-03-22 17:32:28 Snapshot lacks a ton of features cheese has 2026-03-22 17:32:49 Cheese was more akin to MacOS photobooth vs just generic mobile camera app 2026-03-22 17:34:02 But yeah, archived upstream is no good 2026-03-22 17:34:45 guvcview is still broken, too. I cant figure out how to fix it, and that often is recommended as a simple capture program 2026-03-22 17:35:28 #16885 2026-03-23 10:48:22 achill: finally getting renameat2 in musl is huge though, should make packaging DNF a lot easier? 2026-03-23 10:58:42 why do we want to package DNF 2026-03-23 11:03:17 achill: i had reverted musl snapshot upgrade because of the seccomp filters needing to be changed. moving to 1.2.6 means we have to fix the seccomp filters. maybe we should revert again and then fix the seccomp filters and move back to 1.2.6? 2026-03-23 12:43:02 note from debian's dnf package: 2026-03-23 12:43:04 Dnf requires a working rpm installation and is meant to be used in chroots, 2026-03-23 12:43:06 see README.Debian for more information. 2026-03-23 12:43:11 the use case is limited, but it exists 2026-03-23 12:52:59 I'm using osc/obs-build which has some dependencies on rpm but unsure if it needs DNF (i'm guessing not) 2026-03-23 12:53:20 but it would be nice to have dnf to use in chroots 2026-03-23 14:02:20 if there's an sodiff in a package, does it requires a rebuild of the dependancies? 2026-03-23 14:03:55 Yes, if the actual soname changed 2026-03-23 14:08:19 went from `so.29` to `so.31` 2026-03-23 14:10:44 Then yes, anything that depends on so:.so.29 would need to be rebuilt 2026-03-23 14:15:52 achill: i updated !99281, the license should be fine now 2026-03-23 14:25:40 I wonder if our GitLab bot could auto-merge MRs for packages where the subtimtter is the maintainer and only pkgver and checksums have changed. 2026-03-23 14:25:57 And pipeline passes, of course 2026-03-23 14:27:29 WhyNotHugo: it would for example then not verify if there are soname changes and suggest that depending packages should be rebuilt 2026-03-23 14:27:46 And other things reviewers would check 2026-03-23 14:28:00 Of course, many things can be automatically checked for, but someone has to build the logic for that 2026-03-23 14:28:12 I often forget about the soname changes. 2026-03-23 14:28:25 I think CI could emit a warning for that, and then its surfaced into the MR view? 2026-03-23 14:28:29 there's an auto-merge feature that you can enable manually for your MR... in theory. in practice you're going to have to rebase manually and merge, which is a bit annoying 2026-03-23 14:29:00 Many things are possible, if someone does the work the implement it 2026-03-23 14:29:49 We already added extra files as artifacts to make it easier of automation 2026-03-23 14:42:01 omni: sorry to bother you, but could I get a review on !98332 2026-03-23 15:50:06 how do you guys debug failing builds on other architectures? like do you cross compile or open up a vm? trying to fix simdjson on loongarch64 but am not sure best way to do it 2026-03-23 15:52:59 A VM is probably the easiest to setup. Tools like valgrind/strace/gdb can not be used easily in cross rootbld 2026-03-23 15:56:03 If there is a way to print a lot of debug info it is also possible to use the CI and than starte at the code to figure out where it went wrong 2026-03-23 15:58:28 hm ok 2026-03-23 15:58:28 ill just use a vm then 2026-03-23 16:16:19 qaqland: I'll try and have a proper look a bit later, sorry for the wait! 2026-03-23 19:02:34 ayakael: hmm, the build log itself is just 3.5M, so unlikely that it's just reporting that would be too large, strange 2026-03-23 19:03:59 It does say: ">>> Artifact size 1805851648 larger than max (300000000), skipping uploading them", which means it would not copy the .apk files into the artifact directory 2026-03-23 19:06:19 logs/: found 495 matching artifact files and directories 2026-03-23 19:06:21 hmm 2026-03-23 19:10:20 ayakael: ah, I see the APKBUILD writes stuff to the logs dir 2026-03-23 19:10:22 that would explain it 2026-03-23 19:13:18 jvvv: are you working on py3-dask? it needs to be updated, and I think it will require some work 2026-03-23 19:14:02 I also wonder if someone else can help me upgrade py3-cx_freeze to 8.6.2? The tests appears to fail 2026-03-23 19:14:10 alternatively we can delete it 2026-03-24 00:04:30 i managed to make simdjson compile on loongarch64 (only failing architecture) by switching to clang (using gcc does not work for whatever reason, even though it should), so im wondering if i should just switch the compiler over in the APKBUILD to use clang or is that not recommended? 2026-03-24 00:17:07 does switching the compiler break linking against other things? 2026-03-24 00:17:22 does 'whatever reason' deserve more investigation? 2026-03-24 00:18:31 "how do you guys debug failing builds on other architectures?" reading the logs is a good start! 2026-03-24 00:20:45 well it seems that gcc is failing because it says loongarch64 is not a supported architecture... (full message at ) 2026-03-24 06:28:49 doas apk add curl-dev 2026-03-24 06:28:49 openssl-dev-3.5.5-r1: 2026-03-24 06:28:49 breaks: libressl-dev-4.2.1-r0[!openssl-dev] 2026-03-24 06:28:49 ERROR: unable to select packages: 2026-03-24 06:28:49 satisfies: curl-dev-8.19.0-r0[openssl-dev>3] curl-dev-8.19.0-r0[pc:openssl] 2026-03-24 06:28:52 Hummm 2026-03-24 06:35:20 breaks: libressl-dev-4.2.1-r0[!openssl-dev] 2026-03-24 06:35:57 You have libressl-dev installed 2026-03-24 07:45:20 Quantum_3[m]: does it build with gcc if you disable fortify? -U_FORTIFY_SOURCE 2026-03-24 08:58:10 any ideas on how to get !98913 through CI on x86? looks it might be running out of memory during tests; would it make sense to try with "ci-large" runners for x86 and x86_64? 2026-03-24 09:33:13 Wow, we have less than 999+ open MRs in aports. 2026-03-24 09:51:45 did we ever define baseline requirements with respect to x86_64? That is, do we support x86-64-v3 or x86-64-v2 or x86-64-v1? We had a similar discussion for x86 in the past https://gitlab.alpinelinux.org/alpine/tsc/-/issues/20 but I think never for x86_64 2026-03-24 11:21:03 nmeum: Not that I'm aware 2026-03-24 11:21:05 of 2026-03-24 11:37:50 WhyNotHugo: fyi, I'm taking a stab at seeing if we can at least post a comment about soname changes 2026-03-24 11:59:47 i think I have py3-dask fixed now 2026-03-24 12:40:51 ikke: there are some report formats which can be saved from the pipeline and are surfaced in the MR page. 2026-03-24 12:41:49 But I think they're quite narrowly focused. Unit tests report (count of failed/pased and warnings), or code quality reports 2026-03-24 12:56:32 Yes, indeed 2026-03-24 12:56:49 I was thinking at perhaps using them, but at least leave a comment if there is a soname difference to make it extra clear 2026-03-24 13:23:03 A comment is probably the best fit. 2026-03-24 13:54:22 ncopa: i think it ended up failing with a error in a different place (but still about a target mismatch) 2026-03-24 13:54:22 i have school now though, will try again when i get home 2026-03-24 14:01:52 I forked apkbuild-lint-tools, but there are no instance-wide runners which can pick up pipelines for it: https://gitlab.alpinelinux.org/WhyNotHugo/apkbuild-lint-tools/-/jobs/2272828 2026-03-24 14:02:04 (want to build images with tweaks to test out changes) 2026-03-24 14:03:46 I have assigned one, but you have to recreate the job 2026-03-24 15:07:01 registry.alpinelinux.org is the one provided by GitLab? 2026-03-24 15:08:59 WhyNotHugo: yes 2026-03-24 15:44:26 jvolsin: what went wrong? 2026-03-24 16:22:37 This soname change implies that dependants need to be rebuilt? https://gitlab.alpinelinux.org/strophy/aports/-/jobs/2272896 2026-03-24 16:27:54 The actual soname is the part after SONAME 2026-03-24 16:28:03 which is the same before and after 2026-03-24 16:28:22 The first part is the filename, but that can change, as long as the SONAME remains the same 2026-03-24 17:11:09 We assume that the new shared object has the same ABI because upstream would have changed it to so.1 otherwise? 2026-03-24 17:13:48 yes, that's the convention 2026-03-24 17:14:02 Ofcourse, not every project adheres to it 2026-03-24 17:14:48 libxml2 is a notorious breaker of ABI 2026-03-24 19:57:23 I can't get GitLab CI to push images to GitLab Registry. 2026-03-24 19:57:31 If I use a personal access token, it says "your account must log in with a Personal Access Token (PAT)" 2026-03-24 19:57:40 If I use a deploy token, it says "unauthorized: incorrect username or password" 2026-03-24 19:57:51 Both cases have permission to read and write registry. 2026-03-24 19:58:13 Oh, wait, the PAT has "read repository", no "read registry" 2026-03-24 20:07:23 Okay, with the right permissions same error :/ 2026-03-24 21:13:42 WhyNotHugo: The CI_JOB_TOKEN should even be sufficient 2026-03-24 21:18:13 WhyNotHugo: what you are running into is that it tries to push to both gitlab and odcker 2026-03-24 21:18:15 docker 2026-03-24 21:37:00 It would require MIRROR_DOCKER_HUB to be unset 2026-03-24 22:08:58 Only pushin to gitlab registry, not docker hub: https://gitlab.alpinelinux.org/WhyNotHugo/apkbuild-lint-tools/-/jobs/2273025 2026-03-24 22:09:13 This initially failed because DOCKER_USER and DOCKER_PASSWORD was unset 2026-03-24 23:54:59 Can I please get this backport merged? !99522 2026-03-25 08:20:17 WhyNotHugo: That pipeline still shows it tries to push to the docker registry. DOCKER_USER and DOCKER_PASSWORD are only required in that case. You have to set MIRROR_DOCKER_HUB to an empty value to disable it 2026-03-25 09:57:47 mio: FYI, I have updated the find-python-rdeps.sh script on https://dev.alpinelinux.org/~ncopa/py3.14/ 2026-03-25 09:58:58 there was a small bug 2026-03-25 10:00:23 I think we have around 1900 packages that needs to be rebuilt with python 3.14 2026-03-25 10:00:47 so far I have rebuilt around 1300 2026-03-25 10:01:00 so approx 600 left to go 2026-03-25 10:01:39 I think we can make it before April 2026-03-25 11:11:35 650 aports left to re-build 2026-03-25 12:00:51 ikke: I didn't notice that from the logs, thanks. 2026-03-25 12:23:45 Total left: 602 2026-03-25 12:23:45 Progress: 1140/1742 2026-03-25 14:29:03 ncopa: thanks for updating the script! 2026-03-25 15:26:34 hello, for a while now i have been getting 500 internal server errors trying to open a MR for the 3.22-stable branch. my fork's branch only has a single commit on top, so the diff is not too complex. is gitlab having issues? or is something amiss with my fork? 2026-03-25 15:29:19 bitfehler: is the target_branch included in the url? 2026-03-25 15:31:58 ikke: hm, no, only source branch. does try to diff against master then? 2026-03-25 15:32:20 Yes 2026-03-25 15:32:29 And it then times out 2026-03-25 15:32:33 Which results in the 500 2026-03-25 15:32:56 i see. so i manually have to add that to the URL? 2026-03-25 15:33:50 well, that works instantly, thanks a lot! 2026-03-25 15:34:26 though it would certainly be nice if one could tell gitlab the target branch before it falls over... ¯\_(ツ)_/¯ 2026-03-25 15:34:27 The alternative is to use glab-cli to create the MR 2026-03-25 15:34:32 i see 2026-03-25 15:34:50 thanks a lot for the help! 2026-03-25 15:34:51 If you go to the new MR page, you get to choose 2026-03-25 15:35:12 But the URL that gitlab generates when pushing something assumes the target is the master branch 2026-03-25 15:36:18 oh, if i start blank? that's good to know. i also tried the button that shows up on the fork when you pushed to it, but that has the same url 2026-03-25 15:37:35 Right 2026-03-25 15:38:02 The New merge request page allows you to select the target branch before it goes to the compare page 2026-03-25 15:39:16 Yet another option is to use push options (though I'm not sure if it's possible to just update the target branch 2026-03-25 15:39:35 git push -o merge_request.target=3.22-stable 2026-03-25 15:39:48 I suspect it requires merge_request.create as well 2026-03-25 16:11:53 would be nice if we could make the autogenerated-link page less "helpful" and making you choose first 2026-03-25 20:39:45 the link page? 2026-03-25 20:40:15 ncopa: the url you get back when pushing a branch to create an MR 2026-03-25 20:40:33 But we do not control that 2026-03-25 20:40:39 aha 2026-03-25 20:41:18 i figured you can edit the link manually and set target branch 2026-03-25 20:41:23 gitlab helpfully gives a URL to directly create an MR for that branch, but that page is quite inefficient and times out when the amount of commits it tries to compare is too large 2026-03-25 20:41:47 yes, that's one option. I use glab to directly create an MR instead of going to the webinterface 2026-03-25 20:41:54 understood. i think i have bumped into it once 2026-03-25 20:42:31 And it's only that compare page that's the issue 2026-03-25 22:14:44 TIL about https://kdl.dev/ 2026-03-25 22:15:14 that looks pretty nice as next gen APKBUILDs 2026-03-25 22:30:47 i'm not sure whether we'd ever be able to have APKBUILDs without conditionals or any kind of control structures 2026-03-25 22:32:23 so best case, if APKBUILDs were to switch to some kind of declarative language, that would need a templating engine on top 2026-03-25 22:33:10 something like jinja2 is to yaml, i suppose 2026-03-25 22:37:03 or well, i guess that could also be implemented on top? like GitLab Actions does with yaml, kinda 2026-03-25 23:08:41 jinja2 is actually pretty bad for yaml 2026-03-25 23:09:11 (sorry, useless sidetrack) 2026-03-26 00:29:01 does alpine assume LASX and LSX on loongarch64 or no? 2026-03-26 03:10:14 Quantum_3[m]: loongarch64 assumes LSX and LASX is enabled by default 2026-03-26 03:34:23 DWwanghao: mk, thanks 2026-03-26 06:55:19 py3-dask and py3-distributed have cirular dep, in checkdepends 2026-03-26 06:55:59 introduced by myself 2026-03-26 11:10:40 anyone available to help with py3-cx_freeze? tests fails currently and its blocking the python 3.14 upgrade 2026-03-26 11:10:49 worst case I will delete it 2026-03-26 12:03:47 same with py3-niaarmts and py3-opytimizer 2026-03-26 12:05:31 Total left: 270 2026-03-26 12:05:32 Progress: 1471/1741 2026-03-26 13:01:19 aren't the maintainers of those quite active? 2026-03-26 13:33:30 WhyNotHugo: initial support of pipeline services (no services, ie things that handle events and do something, yet) in aports-qa-bot: https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/149 2026-03-26 15:11:09 ikke: i think https://gitlab.alpinelinux.org/alpine/infra/docker/exec/-/merge_requests/21 is ready... one thing i don't like is the duplicate entrypoint script. could be possible to refactor a bit, ie. to build both docker-image and buildah-image from the same Dockerfile with multi-stage builds to avoid the duplication, but not sure if it's a good idea (would require making the dir in question special wrt. the gitlab-ci jobs) 2026-03-26 15:11:59 Right, thanks for that. I think for now it's fine. We can think about fixing that later 2026-03-26 15:12:32 the duplication might also go away if those scripts need to change for either impl 2026-03-26 15:18:54 Nice, the mechanism used to make the entrypoint script testable now allows you to override the actual command being used :) 2026-03-26 15:19:16 heh :D 2026-03-26 15:20:22 Did you by chance also test building i586 images? Or only amd64? 2026-03-26 15:20:31 Hello 2026-03-26 15:20:34 i686* 2026-03-26 15:20:45 hmm, no, how would i test that again? 2026-03-26 15:21:05 r8169 doesn't load on a old tochiba satellite p200 2026-03-26 15:21:25 gotta investigate myself... 2026-03-26 15:21:29 c u 2026-03-26 15:21:42 MANIFEST_ARCHES, i guess 2026-03-26 15:22:12 lotheac: that's only for the final manifest 2026-03-26 15:22:15 or not, yeah 2026-03-26 15:22:31 https://gitlab.alpinelinux.org/alpine/infra/k8s/ci-cplane-1/-/blob/master/kustomize/apps/gitlab-runner/base/small-x86/config.toml?ref_type=heads#L21 2026-03-26 15:22:32 ARCH then 2026-03-26 15:23:00 https://gitlab.alpinelinux.org/alpine/infra/ansible-playbooks/-/merge_requests/5/diffs 2026-03-26 15:23:09 Yeah 2026-03-26 15:23:31 right, i already forgot about the runtime class too. let me test that real quick 2026-03-26 15:23:50 I'm not sure if that's required 2026-03-26 15:24:19 setting ARCH, which provides DOCKER_DEFAULT_PLATFORM may be enough, if buildah looks at that 2026-03-26 15:26:00 i'm regretting not making a very persistent test env, my container registry stores images in volatile storage so i need to push again to test every now and then :D 2026-03-26 15:26:17 haha, yeah 2026-03-26 15:26:21 know that feeling 2026-03-26 15:28:53 hmm. setting ARCH didn't seem to do the trick, the resulting image still has arch amd64 2026-03-26 15:31:30 i guess DOCKER_DEFAULT_PLATFORM isn't read by buildah 2026-03-26 15:38:17 ok: -> buildah build --pull --no-cache --platform=linux/i386 -t local:ci-notrealsha-i686 . 2026-03-26 15:38:26 (added a commit to the MR) 2026-03-26 15:47:13 MR description is no longer correct :) 2026-03-26 15:47:51 the commit message for the first commit still is... but the second commit makes it not true 2026-03-26 15:48:03 i guess i'll squash them and edit 2026-03-26 15:53:14 Yeah, the MR description is similar to the cover letter of a patch set 2026-03-26 15:55:02 automatically setting the MR description to the commit message the *first time* you create a MR, and then always having to update it manually afterward, is one of my long-standing gripes with github/gitlab 2026-03-26 15:55:36 Yeah, though picking a commit message in general is not even the best option, unless it's single commit change 2026-03-26 15:56:07 right... i tend to prefer single-commit changes, but the problem with gitlab and github is that when you amend those, it becomes harder to review 2026-03-26 15:56:24 to review what changed between the first and second iteration, i mean 2026-03-26 15:56:49 If you do not change the base, then gitlab does make it quite easy to see it 2026-03-26 15:56:54 so the workaround is often "well i pushed a new commit, i'll squash them later after you've taken a look" 2026-03-26 15:57:03 that feature must be eluding me 2026-03-26 15:57:22 https://gitlab.alpinelinux.org/alpine/infra/docker/exec/-/merge_requests/21/diffs?diff_id=1740731&start_sha=4ac3454833b807d34a37c19b7bda2f1eeb29713b 2026-03-26 15:57:26 "Compare with previous version" 2026-03-26 15:57:44 ah, right. yeah, that's good enough 2026-03-26 15:58:04 i might be mixing things up with github. it does have a similar feature but it feels unreliable 2026-03-26 15:58:19 Sadly if you rebase, it will include all the changes from the target branch that were introduced by the rebase 2026-03-26 15:58:30 that's also not great 2026-03-26 16:00:18 In https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/149, I've split a single change up into separate commits, which allows me to add more context in each commit (although, in this case not a lot of extra context). 2026-03-26 16:01:37 sure, i do that too.. sometimes 2026-03-26 16:01:52 Splitting them up makes it easier for reviewerrs 2026-03-26 16:02:00 agreed 2026-03-26 16:03:01 although the ui is a bit clunky if you want to check each commit separately, need a lot more clicks 2026-03-26 16:03:26 There are buttons to navigate through the list though 2026-03-26 16:03:32 (and keyboard shortcuts) 2026-03-26 16:04:27 One wish I had is that you could disable the "Changes" tab 2026-03-26 16:04:35 and force everyone to to through the commits 2026-03-26 16:04:41 i would have less of a problem if there was less than 1.5 sec of latency between clicking next commit and seeing anything :p 2026-03-26 16:06:15 the 32-bit runtimeclass worked fine too, build a i386 image when ARCH was not set 2026-03-26 16:06:19 built* 2026-03-26 16:08:21 Ok, thanks, good to know 2026-03-26 16:12:20 Oh, the image requires itself to build 2026-03-26 16:12:45 bootstrap issue 2026-03-26 16:13:07 heh :) 2026-03-26 16:13:31 that's a bit surprising, i would have thought it uses docker-image to build 2026-03-26 16:14:20 You specified buildah-image 2026-03-26 16:14:22 well, it would have had i defined it that way, heh 2026-03-26 16:14:36 yeah, bit of a mindless :s/docker/buildah/ there 2026-03-26 16:14:43 hehe :) 2026-03-26 16:15:27 if it extends: .build-image, is it even necessary to define the image? 2026-03-26 16:15:29 yeah, `:$DOCKER_IMAGE_VERSION` would not even exist yet untill we created a tag 2026-03-26 16:15:42 no 2026-03-26 16:15:50 You only need to define what's different / missing 2026-03-26 16:16:16 right. all the other jobs specify images (despite being the same as the default), so.. copy-pasto 2026-03-26 16:17:18 I guess a remnant from switching between a tagger version and :latest 2026-03-26 16:18:04 ah, right, :latest vs :$DOCKER_IMAGE_VERSION is actually the difference 2026-03-26 16:18:11 yeah 2026-03-26 16:18:21 But I need to clean that up 2026-03-26 16:18:22 didn't even notice 2026-03-26 16:18:41 maybe because it's 1am :) 2026-03-26 16:18:45 heh 2026-03-26 16:19:47 Ok yeah, by using $CI_REGISTRY_IMAGE, it would not work in a fork 2026-03-26 16:21:45 i can't push branches to the target repo, so had to use a fork. i feel like this isn't the only infra repo where CI doesn't work right from a fork 2026-03-26 16:41:10 pyproject.toml 2026-03-26 16:41:10 39: "standard-aifc; python_version >= '3.13'", 2026-03-26 16:41:24 any volunteer to package py3-standard-aifc? 2026-03-26 16:42:14 Reminder for anyone who's interested, in 20 minutes, the curl distro meeting will be held 2026-03-26 16:46:24 https://github.com/curl/curl/wiki/curl-distro-discussion-2026 2026-03-26 16:47:26 interested, but i gotta prioritize sleep, so not joining this time :) 2026-03-26 16:47:34 yeah, I can imagine :) 2026-03-26 16:50:10 i had too many meetings today 2026-03-26 16:51:22 i made a py3-standard-aifc myself 2026-03-26 17:03:00 meh. I gave up and depeted py3-speechrecognition. it needs py3-audioop-lts and py3-standard-chunk in addition to the aifc stuff 2026-03-26 17:10:06 Total left: 185 2026-03-26 17:10:06 Progress: 1557/1742 2026-03-26 17:18:13 ikke: neat, I'll have a look. I've been looking at translating lint warnings to gitlab code quality warnings. 2026-03-26 17:18:27 THe bot service is hand for relaying soname changes 2026-03-26 17:20:22 There are some steps we need to take before we get to the artifacts 2026-03-26 17:20:31 pipeline -> bridge pipeline -> artifacts 2026-03-26 17:20:40 I'm working on that 2026-03-27 06:43:24 Comments on #18084 are appreciated. 2026-03-27 09:39:18 is the email in ~alpine/devel real? "Dissolving the TSC and improving the technical governance" 2026-03-27 09:40:59 Doesn't seem legit, it's sent with an email from another project 2026-03-27 09:44:26 It is :) Happy to get the confirmation from the Council members in public (they got to approve it before it was sent out) 2026-03-27 09:47:52 pabloyoyoista: Is the approval process public or private? 2026-03-27 09:48:54 You mean if the review process for the conditions and individuals will be public, or only released after approved by the Council? 2026-03-27 09:51:10 > the Council has decided to dissolve the TSC in its current form 2026-03-27 09:52:58 The Council notified all former TSC members last week 2026-03-27 09:53:58 are they former because it has been dissolved? 2026-03-27 09:54:07 Yes 2026-03-27 09:56:21 I know that the TSC was struggling, but now I am a bit anxious 2026-03-27 09:56:57 Anxious in what sense? 2026-03-27 09:57:17 Peoples lives and interests change 2026-03-27 10:02:09 I haven't read the email, I have only just read the few comments here, so I don't know what will take its place 2026-03-27 10:02:51 I've experienced things to be a bit wild and breaky the past twoish years and I worry that that could increase 2026-03-27 10:03:01 We'll propose new members, and new rules to try avoid the situation that just happened (TSC met twice in the last 1.5 years, less than once per release) from repeating 2026-03-27 10:04:03 I would hope making the TSC meet regularly should help fix that :) 2026-03-27 10:07:21 if possible, wish to see the full discussion process on the mailing list or GitLab instead of just one notification 2026-03-27 10:07:34 +1 2026-03-27 10:09:36 I wish for a new TSC to focus on moving slow and fixing things 2026-03-27 10:11:43 I wonder how would a more transparent process help with making the actual decisions given the specific situation here, and that it can get pretty personal 2026-03-27 10:12:49 I'm not saying I disagree, just wondering how could I do better next time 2026-03-27 10:13:39 are you admitting that you have been backroom pushing this too? 2026-03-27 10:15:14 The problems with the TSC not meeting are obvious and public. And nobody did anything in public 2026-03-27 10:15:58 I've been trying to help coordinate the TSC meeting for months in different ways, and unfortunately that didn't happen 2026-03-27 10:16:43 omni: The council enlisted the help of Pablo 2026-03-27 10:26:30 heh this is why I said the council should send :) 2026-03-27 10:27:18 but yes it is official 2026-03-27 10:27:51 pabloyoyoista: it may be useful to summarize those problems for the people who have followed along less in such an email 2026-03-27 10:28:18 that is not at all an accusation just so you know :) just that as an alpine bystander (these days) it's a bit surprising and worrying to receive such an email out of the blue 2026-03-27 10:28:25 or rather, it can come across as surprising/worrying 2026-03-27 10:29:11 honestly, the writing was on the wall, and the e-mail is a sign that things are finally moving 2026-03-27 10:29:24 I just hope they'll be moving in the right direction :) 2026-03-27 10:32:57 All this is very good feedback, thanks! Specially the difference in perspective depending on involvement 2026-03-27 11:03:47 Ariadne, yep :) 2026-03-27 11:35:35 we asked pabloyoyoista and Ariadne help us solve it. I have not had the time and energy to follow up that 2026-03-27 11:36:52 IMO our governance, we have outgrown it, and we last revised it during the COVID period when everyone was at home and thus having meetings was not hard to do 2026-03-27 11:38:24 the situation is not particularly dire we are just pursuing a course correction to ensure that there is more active participation in TSC and that the TSC has a balanced set of perspectives 2026-03-27 11:41:22 weasyprint tests segfault 2026-03-27 11:41:33 wsegfaultprint 2026-03-27 11:41:38 :) 2026-03-27 11:42:24 skarnet: I think this is the right way to see it. things are finally moving 2026-03-27 11:43:23 has taken time to realize that I have to remove myself where I have been unable to move things forward 2026-03-27 11:43:49 to be clear alpine will remain alpine, but one goal is to be more inclusive of downstreams as alpine has grown into a metadistribution 2026-03-27 11:44:39 that said, the plan is that pabloyoyoista and Ariadne comes up with a proposal. The council will decide if its good or not. 2026-03-27 11:45:26 yes also true 2026-03-27 11:45:57 though I think what we are considering is aligned with reality :) 2026-03-27 13:55:29 Is there any reason why !96129 hasn't been merged despite all feedback having been resolved for almost two months? 2026-03-27 13:56:27 Newbyte: lack of time/availability of the people with merge powers 2026-03-27 14:08:51 i currently down prioritize testing. have more than enought with existing stuff and the 3.24 release 2026-03-27 14:09:17 ah okay, makes sense 2026-03-27 14:09:49 merged it 2026-03-27 14:09:51 thanks! 2026-03-27 14:51:13 \o/ i got to the end of python 3.14 rebuilds 2026-03-27 14:51:35 i have 9 packages that I have deleted locally, that still needs to be fixed 2026-03-27 14:53:41 that is main and community only 2026-03-27 14:53:47 I havent even started on testing repo 2026-03-27 14:56:25 nice 2026-03-27 15:00:08 +1 for a new TSC to focus on moving slow and fixing things 2026-03-27 15:00:32 Python 3.14 can be merged even with (partially) broken testing, no? it doesn't block 3.24. 2026-03-27 15:00:54 WhyNotHugo: yes, that's ncopa's plan 2026-03-27 15:02:57 https://gitlab.alpinelinux.org/alpine/aports/-/issues/18025 2026-03-27 15:03:14 I have listed the missing packages. I would like to delete those of fix them before I merge 2026-03-27 16:06:15 reuse needs an update but tests are failing 2026-03-27 16:06:26 im giving up 2026-03-27 16:09:20 ncopa: I removed python from unit so it should not be a blocker, waiting last pipeline 2026-03-27 16:33:30 thank you! 2026-03-27 16:55:26 hi 2026-03-27 16:55:54 i have a problem with services on hyperv, can someone can help me ??? 2026-03-27 17:04:58 could maintainers please take a look at !98783, !98323, and !98824 ? Thanks! 2026-03-27 17:20:28 craftyguy[m]: on it 2026-03-27 17:21:15 thank you :D 2026-03-27 19:38:20 I think I'm gonna push python 3.14 now 2026-03-27 19:39:45 it will take some time to rebuild 2026-03-27 19:43:18 I pushed python 3.14 2026-03-27 19:55:25 rv64 builder is still awol 2026-03-27 22:47:07 people probably know, but i didn't see anything in gitlab... vim was forked into vim-classic: https://drewdevault.com/2026/03/25/2026-03-25-Forking-vim.html 2026-03-27 23:47:29 the NeoVim link with the "AI Assisted" search shows 0 results 2026-03-27 23:47:39 i wonder if they removed the labels 2026-03-27 23:48:16 the Vim link is worse, in a way - the comment he links to was hidden (but you can open it) 2026-03-27 23:49:51 https://github.com/neovim/neovim/pulls?q=is%3Apr+label%3A%22AI+assisted+%F0%9F%A4%96%22+ 2026-03-27 23:50:38 huh. i don't even know why yours works when the linked one doesn't 2026-03-27 23:50:48 also, thanks for the data. also, ugh 2026-03-27 23:51:05 it was issues vs prs 2026-03-27 23:51:44 right. github does a weird mix of "the thing in the path matters but the predicates in the search bar also matter" 2026-03-28 04:16:20 Habbie: if you click on "Labels", github says there are 9 issues, but if you try to filter, it shows zero. Sounds like their UI being broken. 2026-03-28 04:16:26 The Vim commits really do look like shit 2026-03-28 07:32:19 Can someone have a look at !99674 !99297 !99221 please 2026-03-28 07:32:37 raspbeguy: just mention on sanlock that the pkgrel bump got lost 2026-03-28 07:32:53 mentioned* 2026-03-28 07:33:18 (because it was bumped in master) 2026-03-28 07:34:30 Do you mean I have to increase pkgrel in the MR ? 2026-03-28 07:35:19 yes, you had it before, but due to the rebase, it got absorbed with a previous pkgrel bump 2026-03-28 07:36:09 Got it 2026-03-28 07:36:23 Done 2026-03-28 07:52:28 mio: thank you very much for helping me cleaning up after python 3.14 rebuilds 2026-03-28 09:10:38 Hi 2026-03-28 09:11:00 I'm starting an upgrade and apk wants to remove a bunch of pyc packages (without replacing them) 2026-03-28 09:11:05 Is that expected? 2026-03-28 09:11:11 (On Edge) 2026-03-28 09:16:22 WhyNotHugo, ack 2026-03-28 10:29:34 quinq: lots of packages are being rebuilt on python 3.14 right now so I'd avoid upgrading for a bit 2026-03-28 10:47:29 Hello elagost, ok thank you for confirming it :) 2026-03-28 13:48:19 oh, then I guess I have the answer to the question I was just going to ask 🙂 2026-03-28 13:49:44 (error after rebasing one of my branch that was building fine before https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/2277409) 2026-03-28 13:50:00 yes, related 2026-03-28 17:59:01 ncopa, I am seeing an update for ansible-core, to 2.20.4 on 25 March but I do not see the package pushed yet. Is there a general wait on the move to python 3.14? 2026-03-28 18:04:24 smcavoy: builders are still rebuilding for the python 3.14 upgrade 2026-03-28 18:05:02 packages will be pushed when the rebuild in community/ is completed 2026-03-28 21:00:02 mio, thanks for the info 2026-03-28 21:02:59 smcavoy: you're welcome 2026-03-29 09:49:13 Pretty sure it does but just to be sure, if abuild downloaded some dependencies it caches them to /var/cache/apk and reuses them where possible right? Or does that need configuring first? Asking because I'm atm working on mobile connection on a train and I'd like to save data 😅 2026-03-29 10:00:44 puretryout[m]1: it does that by default 2026-03-29 10:01:02 Awesome 👍 2026-03-29 10:01:07 One of the reasons you need to be in the abuild group 2026-03-29 10:10:53 Yeah makes sense 2026-03-29 10:10:55 I just noticed /var/cache/apk is taking up 60GB on this machine atm, I should clear that out at some point... 2026-03-29 10:11:48 Although I suppose it'd be nice to prevent the need to be in the abuild group it would be nice to have an abuild version of /var/cache/apk somewhere in $HOME. Anyway, irrelevant really, if you need to do it without root it's easy enough to just setup a devcontainer or something 2026-03-29 10:46:06 Hello 2026-03-29 12:31:21 i think, but have not checked, that it required the creation of /etc/apk/cache -> /var/cache/apk symlink at one point to be active 2026-03-29 12:32:36 or maybe i'm talking about a different thing 2026-03-29 12:46:52 lotheac: that's the cache where apk will put packages it downloads 2026-03-29 12:46:59 What puretryout[m]1 mentions is source archives 2026-03-29 12:47:12 Both would be beneficial though 2026-03-29 12:47:35 or maybe I read it wrong and that's exactly what puretryout[m]1 meant 2026-03-29 12:49:46 maybe it's not great to use the same dir for both 2026-03-29 12:49:51 if that's the case 2026-03-29 12:50:26 /var/cache/distfiles is used for source archives 2026-03-29 12:50:38 And /etc/apk/cache for apk files 2026-03-29 12:51:18 [@puretryout:postmarketos.org](https://matrix.to/#/@puretryout:postmarketos.org) It seems you basically want my abuild config :) https://codeberg.org/sertonix/aports/src/branch/main/custom/0+abuild/abuild.conf.in 2026-03-29 12:53:09 I would like to upstream most of the changes I have included there but it is difficult to do without breaking existing setups too much 2026-03-29 13:21:04 Packages will be pushed all at once when the entire rebuild is done? 2026-03-29 13:40:29 WhyNotHugo: yes, per repo 2026-03-29 20:21:30 dumb question: why isn't there a linter for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99738#note_595927 ? And where/how can/should I implement one? 2026-03-29 23:10:44 jvoisin: I'm not sure how you'd programatically determine that a makedepends is not truly required. 2026-03-29 23:12:58 for that specifically, you could read pyproject.toml 2026-03-29 23:39:57 am I the only one to see a bunch of -pyc, -doc and -completion packages being purged on package upgrade? 2026-03-29 23:42:55 omni: that's because the latest available package is built with python3.14, but your system can't upgrade to that due to conflict, and the -doc and -pyc packages for the old package are gone upstream. 2026-03-29 23:43:08 AFAIK, it should only happen if you use `-a` 2026-03-29 23:43:25 s/upstream/from the repositories/ 2026-03-29 23:43:44 hmm.. ok... 2026-03-29 23:44:26 omni: try `apk add --simulate python3~3.14` to see what's blocking your upgrade 2026-03-29 23:44:36 Of course, it's likely mirror propagation 2026-03-29 23:46:18 I currently use alpine.global.ssl.fastly.net that should be up-to-date, no? 2026-03-29 23:47:43 but your command helped identify aports 2026-03-30 01:19:51 Any reservations on !91039? 2026-03-30 01:52:10 Can we make the lack of a -pyc subpackage an error rather than a warning? 2026-03-30 02:12:11 Shouldn't libarchive and 7z provide that if built with that option? 2026-03-30 07:43:21 if you mean "a tool to decompress rar" then sure, they do 2026-03-30 07:44:08 but 7z nor libarchive provide unrar CLI tool which is used in e.g. KDE Ark 2026-03-30 07:44:53 and it's annoying because it's 1 of 2 possible backends for rar unpacking (other being unarchiver) 2026-03-30 07:45:43 I seem to have lost some USB ports after upgrade, somehow 2026-03-30 10:15:13 Hello \o/ 2026-03-30 10:15:18 :D 2026-03-30 10:16:05 I'm now working fulltime on fork to train myself... and because I have the time... 2026-03-30 10:16:41 I'm declared shyzo... so don't be surprised sometimes i'm weird 2026-03-30 10:16:56 I've also ADHD 2026-03-30 10:19:00 well the actual problem is that I'm using 3.21.6 to build aports-v3.21/main/dtc... and I get A weird func missing an argument... 2026-03-30 10:19:49 I'm okay to fill it with "1" as it is looking for an int... but i feel like wrong doing it. 2026-03-30 10:20:51 the that pop error is SWIG_Python_AppendOutput(resultobj, val); with a missing argument 2026-03-30 10:21:48 the declaration is SWIG_Python_AppendOutput(PyObject* result, PyObject* obj, int is_void) which is obviously missing an argument "is_void" 2026-03-30 10:24:29 someone has an hint for me? how do I determine that is_void? do I need to check up the entire declaration? or maybe someone can help? 2026-03-30 10:25:49 I know how to patch and add them cuz you can't write on source and rebuild using abuild -r... I think I need use a parameter to do that... :) 2026-03-30 10:27:51 Oh I'm in aports edge! well my patch! first contrib to alpine linux accepted! few months ago! 2026-03-30 10:33:41 WhyNotHugo: the issue was the ordering of the dependencies, which seems toe be alphanumerical instead of random 2026-03-30 10:35:36 First step would to codify it in https://gitlab.alpinelinux.org/strophy/aports/-/blob/master/CODINGSTYLE.md 2026-03-30 10:35:44 And then we can add it in https://gitlab.alpinelinux.org/alpine/infra/atools-go 2026-03-30 10:43:24 (In aports/alpine/CODINGSTYLE.md for the record) 2026-03-30 10:43:33 alpine/aports* 2026-03-30 10:52:39 by looking to declaration I see that it is a determining subject as it is part a condition that change the behavior. 2026-03-30 10:53:13 aports.3.21-stable/main/dtc/src/dtc-1.7.0/./pylibfdt/libfdt_wrap.c:1259 => SWIG_Python_AppendOutput(PyObject* result, PyObject* obj, int is_void) 2026-03-30 10:54:26 I've to check all use from that last... :| 2026-03-30 10:55:09 fortunately only used 3 times... 2026-03-30 10:56:13 I'm wondering something weird... how do the maintainer produced the package itself if it doesn't build? 2026-03-30 10:56:47 Is it a test that I fully passed!? :D 2026-03-30 10:59:20 I think It would be nice to push developers to use abuild -r a little much... 2026-03-30 11:01:18 well okay... that was cool... to talk with you... you literally spin the best linux distribution I used in my life... have a good day!!! 2026-03-30 11:13:02 I believe there's nothing left in main/ to be rebuilt against python 3.14 and that only py3-simframe and reuse are left in community/ 2026-03-30 11:13:57 those two have failing tests (I haven't looked into) 2026-03-30 11:14:29 yup can verify these are the last two for community 2026-03-30 11:16:00 achill: you're working on what's left in testing/ does that also include those that depend on libpython3.12.so.1.0? 2026-03-30 11:16:05 yes 2026-03-30 11:16:23 cool 2026-03-30 13:57:59 Guess what! 2026-03-30 13:58:08 I found a pach! 2026-03-30 13:58:32 in fact wrong function been used... 2026-03-30 13:58:42 that's just that... 2026-03-30 13:59:31 I don't remember how I did provide patch last ttime to aports... it's gonna be another combat to suffer... 2026-03-30 14:00:17 \o/ 2026-03-30 14:00:26 :) 2026-03-30 14:01:09 see you... I can't stay I'm mad person... 2026-03-30 14:32:21 the signal-desktop APKBUILD downloads a 1.3GB source tarball from https://ayakael.net/api/packages/mirrors/generic/webrtc/ ? 2026-03-30 14:32:33 amazing. 2026-03-30 14:33:10 I feel that check() functions which trigger upstream's full tests _including_ reuse to check licences are present in the source repository are a bit much :P 2026-03-30 14:47:12 they still haven't addressed the /tmp noexec problem ... probably just going to get worse over time 2026-03-30 14:49:44 IIRC signal (and other electron) require both executable /tmp AND suid capablities. 2026-03-30 14:50:27 This from a team which proclaims that encrypting secrets at rest is impossible for a messaging client, while others have done so for over a decade. 2026-03-30 14:51:11 it really feels like Signal Desktop isn't meant to be packaged at all, sigh 2026-03-30 14:53:09 I think it's one of those "we provide binaries for macOS, what else do you want?" kind situations. 2026-03-30 14:55:29 i think most of this electron software is actually harmful. it might be a good question whether it belongs 2026-03-30 14:55:39 It's one of those I just wouldn't bother packaging and get the Flatpak... 2026-03-30 14:56:25 in the case of marooned signal-desktop users, we could just point them to pidgin or something. 2026-03-30 14:56:48 ikke so on my laptop it definitely uses the cache in `/var/cache/apk` but it's not on my desktop. I don't see any relevant change I made to abuild.conf, neither system-wide nor per user. What could cause that? 2026-03-30 15:00:31 WhyNotHugo: i don't think we have purple-presage packaged, but might be a better place to spend effort than signal-desktop 2026-03-30 15:01:11 yeah, the "just use completely different chat platform" advice is really great and helpful to people 2026-03-30 15:02:04 pj: what's that in response to? 2026-03-30 15:02:11 I've been looking at an XMPP gateway for signal, since I already have an XMPP client anyway and also have a gateway for Matrix too. 2026-03-30 15:04:00 all the signal-desktop team is going to say, forever, is "due to limited resources, we can't..." 2026-03-30 15:04:17 jvoisin: Yeah it's definitely not 2026-03-30 15:04:45 what is wrong with scli or the other terminal frontend in rust? 2026-03-30 15:05:23 a tui doesn't replace a gui 2026-03-30 15:05:48 which is why i mentioned pidgin (with the purple-presage plugin, we we haven't packaged yet) 2026-03-30 15:06:03 i don't know if it even works, it's just an idea. 2026-03-30 15:06:40 s/we we/which we/ 2026-03-30 15:09:30 gurk-rs was the rust-based one. 2026-03-30 15:10:13 TUIs get weird quickly for signal, where I handle a lot of media. 2026-03-30 15:10:35 Much as this interests me, it's a better fit for #alpine-offtopic 2026-03-30 15:10:47 btw i didn't get the requirement being a gui, when we don't have even a client in alpine. from zero to hundred this would be a compromise 2026-03-30 15:13:12 p_6f3Ik7Suw: signal-desktop is in testing. Hence my comment on the APKBUILD above. 2026-03-30 15:14:02 uh, my bad. #EMORESCROLLBACK 2026-03-30 19:12:22 hello, can https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96377 be reviewed (and potentially merged)? 2026-03-30 19:38:04 Flare works great for my usage of signal 2026-03-31 01:14:12 small pkging regression from the push to update to python 3.14: !99838 2026-03-31 01:17:03 hmm, guess the patch is wrong afterall 2026-03-31 02:57:52 WhyNotHugo: Indeed, it's a big file. I improved the situation by setting up a workflow that throws a bunch of cores on compression, and I am likely due for a new exclusion list to remove any prebuilt tools Google or, god help me, a whole ass rootfs. 2026-03-31 02:59:24 ayakael: it's not possible to download just a git-archive for a specific commit from upstream, is it? 2026-03-31 03:00:42 WhyNotHugo: No, unfortunately webrtc can only be pulled via depot_tools 2026-03-31 03:01:00 The workflow in question: https://ayakael.net/mirrors/signal-desktop/src/branch/ci/.forgejo/workflows/generate-webrtc.yml 2026-03-31 03:01:11 ayakael: really? The index for each commit has a link to a tgz: https://webrtc.googlesource.com/src/+/f1c55505df567d20868076c3c3284cfd63da3fb4 2026-03-31 03:02:48 WhyNotHugo: the build process for webrtc expects a bunch of other stuff afaik that isn't available in the tgz. That said, I havn't revisited this since I took maintainership of the package, so maybe the process got saner 2026-03-31 03:05:44 Like, a bunch of submodules or something? 2026-03-31 03:06:11 Memory serves, yes. 2026-03-31 03:06:18 I don't blame you: it's quite understandable that one wouldn't want to sink time into reverse engineering this :P 2026-03-31 03:06:45 Yeah, it's too cursed and I'm just happy signal-desktop keeps working every time I update it. 2026-03-31 03:07:07 Thank you for that XD 2026-03-31 03:07:19 I can't even figure out how to map 7444g to the actual commit. I don't see tags on the uI 2026-03-31 03:08:11 Yeah, although this is probably the 3rd time someone mentions that electron (and related) is too cursed to keep packaged, and I wonder if I should just drop it from aports. 2026-03-31 03:08:20 3rd time in the last couple months* 2026-03-31 03:09:17 A super annoying quirk is that migrating to another client loses all history too 2026-03-31 03:09:35 I have a few ideas on how to get it to community (adding a test suite, for example), but so far the off-hand comments havn't give me much faith that it'd be worth the trouble 2026-03-31 03:10:13 Would suck to sink a bunch of energy in improving packaging the electron ecosystem just for it to be dropped at a later date. 2026-03-31 03:11:16 I only just noticed we don't have anything electron in community. 2026-03-31 03:13:09 Yeah, two things need to be done (imo) for electron to be in community: 2026-03-31 03:13:09 2) a test suite 2026-03-31 03:13:09 1) version the packages (i.e electron30, electron31 - so that packages use the electron version they were built for, or at least there is a grace period between two versions) 2026-03-31 03:13:09 In all cases, infra is the bottleneck. 2026-03-31 03:13:30 infra? 2026-03-31 03:13:50 build infrastructure, electron takes forever to build 2026-03-31 03:15:56 So adding a test suite + having multiple versions on edge and maybe just one on stable + the 2-week release cycle for electron makes for busy builders 2026-03-31 03:16:40 (security releases are done at least every two weeks) 2026-03-31 03:16:45 And I'm sure we'd basically be re-building chromium, instead of re-using the existing build. Plus a bunch of depends. 2026-03-31 03:16:52 If only this were designed to be distributable! 2026-03-31 03:17:30 xD yeah everything about it is cursed and I think I keep doing this because of sunk cost fallacy. 2026-03-31 03:18:27 I don't know what I'd do if you dropped signal-desktop right away 😅 2026-03-31 03:19:08 Hahaha well for now it doesn't take that much time out of life to keep it maintained, just havn't done much in terms of improving things. 2026-03-31 03:20:01 I would love to get in community, though. It's just my last attempt at getting versions packaging going was never reviewed (likely due to aformentionned infra considerations and no one wanting to make the call) 2026-03-31 03:20:21 versionned* 2026-03-31 03:21:40 and god, the electron source code is even worse: https://ayakael.net/mirrors/-/packages/generic/electron/v40.8.5 3.5gb!! 2026-03-31 03:22:22 Due for an audit, really, they keep sneaking in ubuntu rootfs-es and a fully-built gcc suite. 2026-03-31 03:22:54 (depot_tools pulls necessary stuff like submodules and cursed stuff like prebuilt compilers) 2026-03-31 03:22:57 there's also android sdk, ios stuff, etc. Apparently you can fetch a single directory at a time tho, trying to understand it now 2026-03-31 03:24:57 It's horrible that we resent the frameworks are tools depend on 2026-03-31 03:25:04 our tools* 2026-03-31 11:56:12 ayakael: Re: versioned Electron, do you know how's the schedule gonna be for Electron when Chromium starts releasing fortnightly, though? 2026-03-31 12:29:01 is Ariadne still sometimes around here? 2026-03-31 12:36:39 yes. 2026-03-31 13:18:37 hi 2026-03-31 13:24:26 aparcar[m] :? 2026-03-31 13:25:13 Ariadne: i sent you a PM earlier, did you receive it? Matrix might be acting up agian 2026-03-31 13:26:00 I did not 2026-03-31 13:36:05 will the edge riscv builder be unstuck soon? 2026-03-31 13:41:47 no idea, sadly 2026-03-31 13:42:40 it looks like it is catching up, but it is very slow and the python rebuild was very large 2026-03-31 13:43:24 It's currently offline, we wait for it to be restarted 2026-03-31 13:43:35 In other news, we need more stable hw for riscv64 2026-03-31 13:44:35 what hardware is available? :p 2026-03-31 13:53:45 No clue :) 2026-03-31 13:59:51 And it so happens to come back 2026-03-31 14:01:29 thats what i mean, it was building gcc as of like 30 min ago according to build.al.o 2026-03-31 14:02:14 well it showed that since yesterday 2026-03-31 14:02:18 and now, perl i guess 2026-03-31 14:02:20 hehe 2026-03-31 14:26:03 The builder just rebooted 2026-03-31 14:26:48 14:26:29 up 33 min 2026-03-31 15:05:59 emulation in qemu isn't an option? 2026-03-31 15:06:11 or crosscompiling rather 2026-03-31 15:07:30 qemu is extremely slow 2026-03-31 15:22:23 abby: probably would be less slow than the current riscv64 hw 2026-03-31 15:48:19 ping ncopa ? Vinyl Cache maintainer here, dne brought me 2026-03-31 15:53:14 Guest6272: you should probably just ask your question ;) 2026-03-31 15:55:07 ncopa, do you still need alpine/ in pkg-vinyl-cache https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache/src/branch/main/alpine ? See also here https://code.vinyl-cache.org/vinyl-cache/pkg-vinyl-cache/issues/191#issuecomment-60525 2026-03-31 16:00:58 related to !99274 2026-03-31 16:01:58 (also the "other side" of the vinyl/varnish split: !99204) 2026-03-31 16:16:05 dne I have asked for being allow listed 2026-03-31 16:16:14 to comment on that 2026-03-31 16:17:17 allowlisted where? 2026-03-31 16:19:33 ikke I am sorry, I got confused, that was for arch (probably the worst sin here, I apologize) 2026-03-31 16:19:43 np 2026-03-31 16:19:46 thx 2026-03-31 16:53:28 dne I have my nick back :) 2026-03-31 18:09:50 is it just me, or is alpine gitlab a little slow the past few minutes? 2026-03-31 18:10:34 I don't see an increase in response time 2026-03-31 18:10:41 i got a 500 in the meantime 2026-03-31 18:10:47 but now seems to have calmed down 2026-03-31 18:13:49 Too brief for our monitoring to pick up 2026-03-31 18:35:42 any comments on !99747 ? 2026-03-31 18:36:17 if my guessing is correct, it could shave some time off of the 3.24 bulk rebuilds of rust aports 2026-03-31 18:54:42 WhyNotHugo (and anyone else interested in python): i had this weird idea, comments welcome !99883 2026-03-31 23:17:22 \o/ 2026-03-31 23:17:53 The voice in my head told me not to join IRC... 2026-03-31 23:18:14 I'm a badass I did anyway 2026-03-31 23:19:11 I repaired dtc for 3.21... meanwhile but you cannot test the package now... it breaks 2 tests 2026-03-31 23:20:15 well just that... anyway nah much talk these days... it's the collapse of minds... 2026-03-31 23:20:28 c u next times