2025-08-02 12:22:28 hmmm upon compiling wayback for development purposes I get this error: 2025-08-02 12:22:29 ERROR: Linker cc does not support sanitizer arguments ['-fsanitize=address,undefined'] 2025-08-02 12:22:42 I suspect it might be caused by the recent gcc upgrade? 2025-08-02 12:23:06 because it worked fine before 2025-08-02 12:23:34 hi all skraito ( God Husband , The Earthquake guy ) your president and prime minister with skraitow ( Lord Jesus Christ skraito wife ) here , how are you all ? ... . 2025-08-02 14:18:51 a program needs libfoo.so but foo package provides only libfoo.so.1. should there be a symlink libfoo.so -> libfoo.so.1? or, the .so file name be patched the program? 2025-08-02 14:19:21 please let me know if the question does not make sense. 2025-08-02 14:23:53 Biswa96[m]: The symlink is usually provided in the -dev subpackage of libfoo 2025-08-02 14:25:31 is depends=gcc-libs nothing in alpine? 2025-08-02 14:29:42 ikke: so, patching the program is the solution / workaround, right? 2025-08-02 14:36:20 If it tries to load libfoo.so at runtime then it should be packaged to load libfoo.so.1 instead. 2025-08-02 14:37:14 abuild -r 2025-08-02 14:37:15 Can't open perl script "zlib": No such file or directory 2025-08-02 14:37:56 realroot: If you mean libgcc then you shouldn't need to specify that manually 2025-08-02 14:38:23 I saw in PKGBUILD that I am porting 2025-08-02 14:40:02 realroot[m]: that was '1' '2' instead of "1 2" 2025-08-02 14:43:01 /usr/bin/abuild: line 18: CFLAGS+= -g1: not found  2025-08-02 14:43:52 abuild uses sh, not bash 2025-08-02 14:44:03 CFLAGS="$CFLAGS -g1" 2025-08-02 17:14:21 WhyNotHugo i was trying to port rocm-llvm, are you doing thw whole stack right? 2025-08-02 17:26:49 ACTION stops working on it 2025-08-02 19:23:21 I have a broken APKBUILD for llvm-rocm, but it's been paused so long that I don't even remember what I was doing. It doesn't build right now. 2025-08-02 19:23:48 Once the core and cmake dependenices are merge, I'll leave a draft in case you want to poke at it, or maybe we can share our different approaches 2025-08-03 08:01:25 https://paste.trom.tf/ezuvubijin.sql 2025-08-03 08:02:04 https://paste.trom.tf/virizupoda.m 2025-08-03 08:04:33 WhyNotHugo this is what I was trying https://paste.trom.tf/ewupimujej.properties. based on arch file it does not build i think i was in the middle of editing it 2025-08-03 09:31:29 plib must be built with -fPIC in this case 2025-08-03 10:44:10 realroot[m]: I had a few more patches on 6.4.1. But a few already made it upstream for 6.4.2 2025-08-04 13:45:15 given that there's no "standard" image for armhf, how would you create a qemu VM for that architecture? 2025-08-04 13:51:19 i think the only reason for armhf is raspberry pi zero's (linux-rpi) and custom kernels (e.g. postmarketos still has some downstream kernels on armhf for historical reasons) 2025-08-04 13:51:52 or you use qemu-user e.g. very easily with podman 2025-08-04 14:00:17 podman run --rm --arch arm --variant v7 -it docker.io/arm32v7/alpine sh 2025-08-04 14:00:18 :) 2025-08-04 14:00:20 thanks 2025-08-04 14:01:30 but it's not armhf 2025-08-04 14:02:36 Is armhf amr32v6? 2025-08-04 14:04:53 Yes 2025-08-04 14:25:47 (note that this is not true for all distributions) 2025-08-04 19:30:38 achill: i think some postmarketOS targets also require armhf instead of armv7, but i forget which ones. 2025-08-04 19:31:00 personally, i would like to eventually EOL armhf 2025-08-04 19:31:19 yeah thats what i said lol 2025-08-04 19:31:21 https://gitlab.com/postmarketOS/pmaports/-/issues/599 2025-08-04 19:32:04 i'd be more than happy to drop it, its just unnecessary trouble 2025-08-04 19:42:02 i think EOL after 3.24, happy to open a TSC proposal for it 2025-08-04 19:42:34 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/66 2025-08-04 19:43:35 ugh according to endoflife.date the armv6 rpi devices got extended again to 2030 2025-08-04 19:43:42 https://endoflife.date/raspberry-pi 2025-08-04 19:43:49 yes 2025-08-04 19:44:13 thanks, i hate it :) 2025-08-04 19:46:19 yea :) 2025-08-04 19:47:47 Then I can still use my rpi B for testing :P 2025-08-04 19:48:10 I still have 2 old rpis lying around 2025-08-04 19:48:30 i think armv6 rpis are *still* being manufactured, sadly. 2025-08-04 19:49:38 this is really crazy 2025-08-04 19:50:04 on one side im happy that they keep the promise and keep manufacturing, but.... its armv6 xd 2025-08-04 19:51:50 That hardware will always be perfectly fine as a UART adaptet 2025-08-04 19:51:57 *adapter 2025-08-04 19:52:07 sure 2025-08-04 23:39:34 hey, i have quite a few "new aport" MRs that have been left open for a while, wondering if anyone can merge or give feedback: !86363 !86091 !86084 2025-08-04 23:39:42 !85946 2025-08-04 23:39:44 !80914 2025-08-04 23:39:51 sent too early haha 2025-08-05 05:16:43 does alpine follow any policy about packaging nftables rules for server software? i see few here https://tpaste.us/pymm . I'm trying to see, if we need to update https://wiki.alpinelinux.org/wiki/Nftables#Packaged_Rules. thanks 2025-08-05 05:19:19 #16177 2025-08-05 06:04:24 thanks @ikke, updated the wiki page https://wiki.alpinelinux.org/wiki/Nftables 2025-08-05 07:10:42 rnalrd: friendly ping about aports#17419. Sorry bother you here, I can not find your gitlab account. 2025-08-05 07:38:15 hi , i have a question using doas apk update and after doas apk upgrade , does not update all my packages. doing doas apk list -u show the upgradable pkgs, its that a normal behavior? thanks 2025-08-05 07:39:58 It can happen if you have orphaned packages that prevent dependencies being upgraded 2025-08-05 07:40:36 im using edge 2025-08-05 07:40:46 and doing apk version i can see them 2025-08-05 07:41:05 Try to provide --available to the upgrade command 2025-08-05 07:42:40 i know that way it work , but way i do not understand 2025-08-05 07:42:50 *why 2025-08-05 07:43:13 its a normal behavior? 2025-08-05 07:59:44 ikke: i have some orphaned pakages yeah, but upgrade that packages will not broke that program i have i.e gpa, i can still use gpa right? 2025-08-05 08:01:41 lindsay replied 2025-08-05 12:58:37 ? 2025-08-05 15:05:44 there was just a public announcement of an unfixed apparent zero day privilege escalation vulnerability on the busybox mailing list: https://lists.busybox.net/pipermail/busybox/2025-August/091665.html in case you want to follow that one 2025-08-05 15:06:16 i don't think a patch is available yet 2025-08-05 15:09:06 eh why did that person just post about it in a public mailing list ... 2025-08-05 15:09:44 and then they say they are happy with an embargo ... 2025-08-05 15:10:41 an accident, obviously. in any case, it's public now 2025-08-05 15:11:21 yeah... 2025-08-05 15:12:21 sh_t happens, best is probably to keep an eye out for a patch dropping and to try to package it timely. hence i linked it here so that you people can keep an eye out if you want to 2025-08-05 15:57:52 el[m]1: fwiw, #alpine-security is a better place to drop these in future so they don't get lost 2025-08-05 18:14:58 I'm looking at https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/testing/vector/APKBUILD and trying to figure out why this works for y'all but not void, and I'm suspicious that its picking up junk from the aports git context that it shouldn't be. Do aports builds run in a context where a build would be able to find its way up to a valid .git directory? 2025-08-05 18:17:15 no 2025-08-05 18:19:17 whats the exact error youre getting 2025-08-05 18:20:01 the very last step of that build calls 'git rev-parse --short HEAD' which cannot exist based on the sources in that APKBUILD 2025-08-05 18:20:23 I'm trying to figure out how this APKBUILD works, on the assumption that it wasn't merged known-broken 2025-08-05 18:29:37 let me try to build it in rootbld 2025-08-05 18:30:19 maldridge: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L702 2025-08-05 18:31:19 btw tomorrow comes a new go cve out, so hopefully this will not suddently silently break binaries and i can push rebuilds on 3.22 2025-08-05 18:54:14 ikke: interesting. I had to patch out the git checks, they're not used in any production vector build, so at some point I'll loop back around to why this works in the aports without patching 2025-08-05 19:27:13 ikke, gg 2025-08-06 06:39:06 hello, can someone have a look at !87884 please? 2025-08-06 07:13:27 Given !88230, should py3-pyo be moved main->community? 2025-08-06 08:03:33 Nice, they're reinventing Clippy 2025-08-06 10:27:19 raspbeguy: AFAIK duplicate maintainer and contributor comments are redundant 2025-08-06 10:28:14 and dont really serve a purpose to both be there on the same file with the same person as both maintainer and sole-contributor; ie maintainer-comment-only may be better 2025-08-06 10:28:53 It's created automatically by newapkbuild 2025-08-06 10:29:35 Also I saw in a wiki that there should be exactly one maintainer and at least one contributor 2025-08-06 10:30:15 nvm then, maybe just me being sleep deprived :P - the rest looks fine to me 2025-08-06 10:31:56 yep im just stupid, my bad 2025-08-06 10:32:25 No worry buddy 2025-08-06 10:45:01 The upcoming new major release of ifstate 2.0 (tool for network configuration) will contain breaking changes. How is this usually handled in Alpine? Should I just print a warning during upgrade if the configuration file is incompatible? 2025-08-06 11:15:56 Does somebody know how are the alpine-builders bootstrapped? 2025-08-06 11:55:55 Can I somehow trigger a CI run without opening an MR? Often times I want to review if builds pass on other architectures before actually opening an MR 2025-08-06 11:59:43 WhyNotHugo : you can open a MR in your own aports fork 2025-08-06 12:00:48 thanks! 2025-08-06 12:01:03 btw: you replies have a huge URL when quoting somebody 2025-08-06 12:01:29 urgh right the bridge fucks up 2025-08-06 12:01:30 pabloyoyoista: what exactly do you mean? did you look at aports/scripts/ ? 2025-08-06 12:04:40 Vaguely related: I've been wanting to put mkimage.sh and related files into the own package, so I can install that package on any alpine host and build installation iamges just with a local package cache (or mirrors) 2025-08-06 12:14:28 scripts/bootstrap.sh is just for bootstrapping a new architecture and not for a new release builder 2025-08-06 12:14:53 i think the infra team just builds they way up to lua-aports and then lets buildrepo do the rest 2025-08-06 12:15:01 (or thats what i remember) 2025-08-06 12:25:01 Thanks both! I was trying to figure out if there's some way the builders could break installs with the /usr-merge 2025-08-06 12:25:04 But seems not :) 2025-08-06 22:10:11 el[m]1: i'm starting to think that the busybox report is actually AI slop 2025-08-06 22:11:04 so i will probably back out that "fix" 2025-08-06 22:11:21 Ariadne: did you see my "fix discussion" response email? i guess it might be true, i argued in there as well that it could be intentional 2025-08-06 22:11:43 yes, because of harald's response, i decided to go back and take another look 2025-08-06 22:12:33 but i still think that at the very least, the option description is wrong. from what i can tell (from reading the code, i didn't do extensive tests) --overwrite doesn't replace files and isn't needed to replace files, even though the help page seems to claim that 2025-08-06 22:12:53 so i feel like the report could be based on a legitimate misunderstanding of the option 2025-08-06 22:13:46 i'm not sure. my instinct is to take all security reports seriously until proven otherwise 2025-08-06 22:13:56 but in this case, i do think we may be chasing AI slop 2025-08-06 22:15:09 the misunderstanding seems logically consistant to me, i went through the code and compared the lines and there's nothing hallucinated there either, from what i can tell. so i'm willing to give the benefit of the doubt and am going to assume it was just a human misunderstanding 2025-08-06 22:15:12 the reason why I say it is AI slop, is because it mentions lstat(2), but busybox does not call lstat(2) when extracting 2025-08-06 22:16:18 Ariadne: it does for the ARCHIVE_EXTRACT_NEWER in the same file in the same section, although that's not directly relevant 2025-08-06 22:16:31 i found the mentioned xopen3() call as well, and the quoted line with the suggested fix 2025-08-06 22:17:26 it's all in src/libarchive/data_extract_all.c with the relevant section starting in line 86 and ending in line 155 (git master branch, not stable) 2025-08-06 22:17:30 i am aware 2025-08-06 22:17:39 i already pushed out new busybox packages with a "fix" 2025-08-06 22:18:28 for what it's worth, if nobody really needs the symlink following behavior of --overwrite perhaps it might be worth keeping the O_NOFOLLOW. while i am thinking it might be intentional, i think especially given the confusing help page there is a legit harm vs use discussion here 2025-08-06 22:20:17 i guess the open question is whether this is an intentional design of --overwrite or not 2025-08-06 22:20:42 yeah, and whether any notable project is relying on that behavior or not 2025-08-06 22:20:58 we haven't heard anything, and i pushed it out to all stable branches :p 2025-08-06 22:21:07 if someone was using this, we would have heard about it by now 2025-08-06 22:21:11 imo 2025-08-06 22:22:01 then my vote would be to keep the symlink following disabled, no matter if it previously was intentional or not. but i'm just a random user so i guess i don't count šŸ˜… but it could be worth some sort of alpine blog post to ask others 2025-08-06 22:22:35 i'll just keep it for now 2025-08-06 22:26:10 is there any back and forth between the busybox maintainers and alpine devs at all? not that it's relevant to this patch question, i'm just curious. i don't think i've seen any of the actual committers active on the mailing list 2025-08-06 22:26:31 not really, denys just kinda does whatever he wants 2025-08-06 22:26:45 at some point, alpine will likely switch to toybox 2025-08-06 22:26:52 or make our own replacement 2025-08-06 22:28:13 ah, interesting! i get that. i was a bit surprised not to see any of the committers respond to the security mail, slop or not 2025-08-06 22:33:44 i am sadly not surprised at this point (which is one of the reasons we will eventually switch to a different userspace) 2025-08-06 22:41:51 Ariadne: I've always heard Alpine was pretty much tied to busybox, it's the first time I hear of a possible switch 2025-08-06 22:42:28 (and if it happens I'm not sure you'll find toybox palatable. I'm pretty sure of the opposite, actually.) 2025-08-06 22:42:40 Ariadne: wasn't toybox as bad as busybox anyway? 2025-08-06 22:42:49 differently so 2025-08-06 22:43:12 afaik it suffers from the same size-coding problems 2025-08-06 22:53:42 we've got enough userlands out there we could almost fill a bingo card 2025-08-06 22:55:10 skarnet: Alpine is tied to a busybox-shaped userland. it does not necessarily mean busybox itself. 2025-08-06 22:57:32 invoked: I don't think I've seen a single one that's considered good. busybox is the closest there is. 2025-08-06 22:57:41 that is the problem 2025-08-06 22:57:56 agreed 2025-08-06 22:57:58 if toybox were ~equivalent to busybox, we would have switched a while ago 2025-08-06 22:58:45 i wouldn't mind if alpine decided to fork busybox 2025-08-06 22:58:56 kinda wished it happened long time ago :> 2025-08-06 22:59:00 i would 2025-08-06 22:59:07 i don't want to clean up that codebase 2025-08-06 22:59:17 i would rather start from scratch 2025-08-06 22:59:41 what's your opinion of stuff like uutils 2025-08-06 22:59:49 no-go 2025-08-06 22:59:58 (not recommending that, just curious) 2025-08-06 23:00:03 i mean, busybox is already being patched, so lets just make it more official and more comfortable for re-usage by other distros 2025-08-06 23:00:15 -rwxr-xr-x 1 root root 6.4M Jul 25 23:09 /usr/bin/uutils 2025-08-06 23:00:32 way less utilities than busybox, and several orders of magnitude larger 2025-08-06 23:00:34 let me guess, Rust? 2025-08-06 23:00:46 indeed 2025-08-06 23:00:51 how did I guess 2025-08-06 23:00:56 but at least they're finishing it 2025-08-06 23:01:06 rust (the language) isn't a problem, all alpine ports must ship with a rust toolchain per the TSC decision a few years ago 2025-08-06 23:01:12 but rust binaries are... 2025-08-06 23:01:20 you can make it small 2025-08-06 23:01:32 that 6.4MB is *after* making it small 2025-08-06 23:01:35 but that's not fun to maintain the same way as it is not fun to maintain C busybox 2025-08-06 23:01:49 show me a uutils binary that is 900kb and we will talk :p 2025-08-06 23:02:10 that's after you build it with telling rust "please tell clang/llvm to be smaller kthxbye" 2025-08-06 23:02:52 yes, that's why it is 6.4mb instead of 16mb 2025-08-06 23:02:53 you can build very small rust stuff if you dive into building everything from scratch :> 2025-08-06 23:03:04 as in, writing all the code 2025-08-06 23:03:07 yes, uutils does not do that :p 2025-08-06 23:03:07 no deps 2025-08-06 23:03:54 i even mocked it on fedi 8 hours ago smh 2025-08-06 23:05:49 hey, i'm gonna give them a point for actually finishing it. not gonna use it, but still. most of these userland projects are half-done or worse. 2025-08-06 23:08:34 it makes sense for ubuntu where those ~6MB does not matter 2025-08-06 23:12:09 if my port of netbsd userland weren't a one-fox project… 2025-08-06 23:13:44 chimerautils exists but it's not a busybox-compatible project 2025-08-06 23:23:28 If I compare the feature set of chimerautils shell and busybox shell then busyboy is in my opinion a lot better. Regardles of compatibility 2025-08-06 23:29:35 such as 2025-08-06 23:31:05 i don't think chimerautils packs into a single binary, does it 2025-08-06 23:31:44 Try "cd " with chimerautils, busybox and bash. The only shell that will not suggest files is busybox. 2025-08-06 23:32:48 (matrix why?, this isn't html) 2025-08-06 23:33:43 for the record, it looks ok on irc 2025-08-06 23:34:24 but next time try grave accent (aka backticks) 2025-08-06 23:34:32 :P 2025-08-06 23:34:55 But then it looks worse on irc... 2025-08-06 23:35:35 I also think that it having slightly different behaviour is fine in comparison to having completely broken TLS or you know, 30 other patches 2025-08-06 23:35:35 depends on your client. 2025-08-06 23:43:13 I have a long list of annoyances with chimerautils compared to busybox. To name a few: tree, find -name foo, ls default color output, jumping whole words in the shell with alt, stat default format 2025-08-07 09:19:41 sbase/ubase? 2025-08-07 11:36:13 what's the fate of !88306 ? 2025-08-07 11:49:54 achill: thanks! as a token of my gratitude, i'll dump the following problem on you: what do you generally think of preserving currently running kernel's /lib/modules during upgrade? i don't think it can be done with a trigger (as that'd be run at the end of the transaction), so will probably have to pre/post-upgrade in linux-stable. 2025-08-07 11:53:46 isnt that somethings like https://gitlab.alpinelinux.org/alpine/aports/-/issues/12157 2025-08-07 11:54:06 tldr: it would be great to have something like this but its not so easy to implement and especially how 2025-08-07 11:55:15 achill: it would more or less mean we would stop tracking the modules with apk, or copy them in place 2025-08-07 11:55:54 I think Ubuntu does something like that, where you have to explicitly clean up old kernels 2025-08-07 11:57:21 Perhaps hardlinking the files to the correct location 2025-08-07 11:57:24 yep, that's exactly it. i think copying with cp -l would be cheap enough 2025-08-07 12:11:38 chimera linux has something more automatic https://github.com/chimera-linux/cports/commit/f856160f78f91d67a807544c172b5df4082bf44c 2025-08-07 15:57:25 hello 2025-08-07 16:03:41 i have a mistery issue. I think our kernel does not have the sched_setscheduler syscall (see https://gitlab.alpinelinux.org/alpine/aports/-/issues/17424) 2025-08-07 16:04:25 when building a kernel for spacemit/riscv64, I got a linker error, that sched_setscheduler symbol was missing 2025-08-07 16:05:07 so I think that there is something in the alpine kernel config that causes the syscall to not build 2025-08-07 16:05:55 comparing with a fedora riscv64 kernel, (which supposedly does build) 2025-08-07 16:19:54 maybe I have found it... 2025-08-07 16:22:55 ncopa: if you have time, need some MR review. 2025-08-07 16:23:14 ok? 2025-08-07 16:33:14 I thought it could be SCHED_CLASS_EXT but that seems not to be the case 2025-08-07 16:34:38 seems like its not in linux's source, most architectures have t in arch/$arch/tools/syscall.tbl, but grepping in arch/riscv has no results 2025-08-07 16:35:06 or im mixing things up 2025-08-07 16:35:22 I have no clue 2025-08-07 16:35:46 There is a kernel/sched/syscalls.c 2025-08-07 16:36:02 but I cannot find what causes the symbol to not build 2025-08-07 16:36:16 hmm yeah i see 2025-08-07 16:39:04 I was able to make it build by using sched_set_fifo_low instead. I found some wifi drivers do that for kernels newer than 5.9. https://github.com/jmontleon/linux-bianbu/issues/11#issuecomment-3164823073 2025-08-07 16:39:35 but I suspect that there is some stupid config knob that disables the sched_setscheduler syscall from our kernel 2025-08-07 16:39:45 yeah likely 2025-08-07 16:41:40 SCHED_CLASS_EXT depends on DEBUG_INFO_BTF 2025-08-07 16:44:10 oh yeah you can enable that. i already did for -stable for the bpf generation 2025-08-07 16:44:39 I think we have DEBUG_INFO_BTF in our lts kernel, but not SCHED_CLASS_EXT 2025-08-07 20:48:36 we should have btf in amd64 and arm64, I fixed it a couple of months ago 2025-08-07 20:49:03 yes 2025-08-07 20:49:39 and in -stable clayton enabled it for all arches which we should do in -lts aswell at some point 2025-08-07 20:49:39 would be nice to have it in riscv, I noticed it was missing just yesterday 2025-08-07 20:49:56 oh noice 2025-08-07 20:50:15 yeah 2025-08-07 20:51:07 so I imagine 6.12.41-r0 has it 2025-08-07 20:51:31 lemecheck 2025-08-07 20:57:48 I can't seem to find it, master and 3.22-stable still don't have BTF 2025-08-07 20:58:05 main/linux-lts/lts.aarch64.config:CONFIG_DEBUG_INFO_BTF=y 2025-08-07 20:58:05 main/linux-lts/lts.s390x.config:CONFIG_DEBUG_INFO_BTF=y 2025-08-07 20:58:07 main/linux-lts/lts.x86_64.config:CONFIG_DEBUG_INFO_BTF=y 2025-08-07 21:00:05 ohhh you mean linux-stable, my bad 2025-08-07 21:01:47 oh yeah sorry :p 2025-08-07 21:02:55 what's the main difference between -stable and -lts? Wiki says "Stable kernel, configured for a generous selection of hardware Only supported in community" 2025-08-07 21:03:20 so there's hardware that is intentionally not supported in lts? 2025-08-07 21:04:24 oh I see, it's actually a different release in linux, nvm, sorry for the noise 2025-08-08 11:34:37 im likely gonna merge !88414 with some fixes i already found after most builders uploaded (sorry riscv) and will fix the remaining ad-hoc 2025-08-08 11:34:51 ~250 packages in ci are a little too much than i expected i guess lol 2025-08-08 11:36:05 guess thats the best way to also check that my packages are all compatible with gcc15 hehe 2025-08-08 11:39:46 I had some proof of concept where large builds could be split in multiple jobs 2025-08-08 11:40:02 Challenge is transferring already built packages 2025-08-08 11:41:01 hmm yeah i see 2025-08-08 11:41:42 i guess having a connection with each other e.g. with mqtt would make them also a bit less stable 2025-08-08 11:41:53 or at least there would be another layer that could influce the stability 2025-08-08 12:16:13 achill: nice that you have achill.org :) 2025-08-08 18:22:48 Is GitHub disabled in "Social accounts" in user profile settings? 2025-08-08 18:23:49 Not explicitly 2025-08-08 18:50:32 heya, can I get some eyes on !87941? No pressure :) 2025-08-09 21:01:48 So, i noticed XRDP no longer works on v3.22 or edge, i assume thats because there's no more xorg? 2025-08-09 21:13:12 xorg is still available 2025-08-09 21:18:25 JohannesJacobs[m]: any chance you can share any additional information about what's wrong? Error messages, logging, any information to reproduce with? 2025-08-09 21:43:00 Let me grab my laptop for a sec :) 2025-08-09 21:49:26 [2025-08-09T22:28:53.739+0200] [ERROR] Error calling exec (excutable: /usr/libexec/Xorg, arguments: /usr/libexec/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log) returned errno: 2, description: No such file or directory 2025-08-09 21:49:26 [2025-08-09T22:28:53.864+0200] [ERROR] A fatal error has occurred attempting to start the X server on display 10, aborting connection 2025-08-09 21:49:26 [2025-08-09T22:29:03.579+0200] [ERROR] waitforx: Unable to open display :10 2025-08-09 21:49:26 [2025-08-09T22:29:03.664+0200] [ERROR] X server failed to start 2025-08-09 21:49:31 i think this is the problem 2025-08-09 21:50:37 because there indeed isnt an /usr/libexec/Xorg 2025-08-09 21:52:06 what i did: i installed alpine v3.21, setup a desktop (KDE), installed xrdp as per the wiki, all worked, then upgraded to edge, and it broke. tried it on v3.22, also broke 2025-08-09 22:02:58 JohannesJacobs[m]: does it run after `apk add xorg-server`? 2025-08-09 22:03:09 hmm, let me try 2025-08-09 22:03:40 mio: that was my thinking too. Perhaps it needs to be a declared depends for xrdp 2025-08-09 22:05:19 Also thanks for the details, especially the reproduction steps. If it still doesn't work I'll setup an env on my end and see what's wrong with the package. 2025-08-09 22:08:21 nope, still doesnt work. i get the connectionlog popup which basicly says its authenticated, session available on display 10, starts connecting, and then it says cant connect to xorg 2025-08-09 22:10:34 but now the logs are different 2025-08-09 22:10:36 [2025-08-10T00:05:38.415+0200] [INFO ] Starting X server on display 10: /usr/libexec/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log... (full message at ) 2025-08-09 22:11:42 let me see what xrdp.log says 2025-08-09 22:13:54 the xrdp.log says this: 2025-08-09 22:13:55 [2025-08-10T00:06:11.458+0200] [ERROR] Error connecting to X server [No such file or directory] 2025-08-09 22:13:55 [2025-08-10T00:06:11.231+0200] [ERROR] xrdp_wm_log_msg: Error connecting to user session 2025-08-09 22:18:39 So you mentioned you're using KDE, in v3.22 only Wayland is supported with KDE now. 2025-08-09 22:19:02 Have you tried using xrdp with a desktop environment still using X? Maybe xfce4? 2025-08-09 22:19:23 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.22.0 2025-08-09 22:20:17 not really... i hate all the other desktop environments ;-) 2025-08-09 22:20:24 but for the sake of testing, i can try 2025-08-09 22:22:51 Totally understandable! Xrdp isn't fully Wayland compatible yet, I think there's a wrdp fork, my knowledge of it is currently fuzzy 2025-08-09 22:24:34 i tried krdp, its in testing branch, but that isnt working either 2025-08-09 22:24:52 now rebooting an xfce test machine, lets see if that works 2025-08-09 22:29:20 xrdp works with xfce on edge, so its def a problem thats KDE related :( 2025-08-09 22:38:06 desktop:~# krdpserver -u user -p test 2025-08-09 22:38:06 qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin. 2025-08-09 22:38:06 qt.qpa.xcb: could not connect to display 2025-08-09 22:38:06 qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. 2025-08-09 22:38:06 This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. 2025-08-09 22:38:08 Available platform plugins are: wayland-egl, eglfs, vkkhrdisplay, minimalegl, offscreen, vnc, xcb, minimal, linuxfb, wayland. 2025-08-09 22:38:08 Aborted 2025-08-09 22:38:10 desktop:~# 2025-08-09 22:38:28 so thats not an option either, unless someone knows how i can fix this :) 2025-08-10 10:21:59 JohannesJacobs[m]: did you install qt6-qtwayland? 2025-08-10 10:22:56 Oh, xfce might actually be a different backend. Not sure what it's called 2025-08-10 10:35:36 maybe some environment variables are needed. for example - WAYLAND_DISPLAY, DISPLAY, XDG_RUNTIME_DIR etc. 2025-08-10 10:36:31 though I have only used krdp in kde 2025-08-10 10:49:32 "Johannes Jacobs: did you install..." <- shouldn't the setup-desktop script do that? let me try.. 2025-08-10 10:49:49 oh, i removed the VM's already :) let me build a new one 2025-08-10 10:51:24 in the meantime, i added a note to the wiki page: https://wiki.alpinelinux.org/wiki/Remote_Desktop_Server 2025-08-10 11:08:59 so, created a new VM running on edge, now executed setup-desktop and choose for plasma 2025-08-10 11:10:47 `` `+-- 2025-08-10 11:10:55 qt6-qtwayland is already installed, so setup-desktop takes care of that somehow 2025-08-10 11:11:00 Sorry 2025-08-10 11:11:33 "though I have only used krdp..." <- on alpine? i can't get it to work on v3.22 or Edge 2025-08-10 12:22:21 sigh.. using setup-desktop means i can't use discover because i keep getting "authorization denied" errors 2025-08-10 12:31:55 never mind, im doing something wrong myself :) 2025-08-10 14:16:44 I'm running into Qt application failing to run now as well 2025-08-10 14:16:47 that's rather anoying 2025-08-10 14:18:44 logs? steps to reproduce? 2025-08-10 14:19:46 https://tpaste.us/RoP5 2025-08-10 14:20:28 Running something like keepassxc or copyq results in that error 2025-08-10 14:20:49 (JohannesJacobs reported that yesterday as well) 2025-08-10 14:38:42 copyq is working fine in postmarketos plasma mobile 2025-08-10 14:39:25 After the last upgrade I did (previous upgrade has been a while ago), I started to get that error 2025-08-10 14:39:41 yeah i had that same error with some other program as well, not just krdp, but ofcourse i forgot :| 2025-08-10 14:39:42 Not sure if it has to do that I have both X11 and wayland (sway) configured 2025-08-10 14:39:50 been so busy getting xrdp to work :| 2025-08-10 14:40:28 so it seems a more general problem then what i reported yesterday with krdp 2025-08-10 14:44:59 #17426 2025-08-10 14:58:00 Does it have to be x session? I have tried both copyq and keepassxc in gnome in alpine edge. 2025-08-11 07:24:02 Could someone please take a look at !78097? It's a MR opened long time ago, and be ready recently. 2025-08-11 07:24:56 there are conflict 2025-08-11 07:24:58 s 2025-08-11 07:26:28 Oh, I see, I'll notify the author. 2025-08-11 07:34:40 Gitlab has been upgraded to 18.1 2025-08-11 08:52:33 Hello, I wish to upgrade one of the package I'm in charge of. Usually upgrade goes smoothly but for this minor upgrade I now have a build error on loongarch64 https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/1967212. I have no idea where it comes from so I would be glad to get some help 2025-08-11 09:03:05 its possibly because of gcc 15.2.0 2025-08-11 09:03:17 cc Ariadne 2025-08-11 09:25:03 raspbeguy: You can also try to ask in #alpine-loongarch 2025-08-11 09:25:16 will do thanks 2025-08-11 16:09:14 achill: nah that is binutils, it's a go program 2025-08-11 16:09:37 oh i see didnt read that properly 2025-08-11 16:39:53 the main concern i have about GCC 15 at the moment is that i've seen a couple of builds where gcc runs out of address space on 32-bit systems, but these seem to have quieted down with gcc-15.1.1_git20250726 and gcc-15.2.0 2025-08-11 16:55:52 hello, may i ask how to merge the MR at aport 2025-08-11 16:55:54 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86362 2025-08-11 16:56:45 the @aports-qa-bot send me here cause `merge request hasn't seen any recent activity` 2025-08-11 17:02:06 yurenchen: I've left some small remarks for cleanups 2025-08-11 17:03:46 thanks, I see them 2025-08-11 17:09:22 @ikke Thanks, I took all the suggestions 2025-08-11 17:11:43 Can you also take a look at the commit style document (https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md)? Specifically in this case all the fixup commits can be squashed into a single commit with the expected commit message 2025-08-11 17:13:42 got it, i'll squash commits 2025-08-11 17:58:28 @ikke commits has been squashed 2025-08-11 20:16:32 yurenchen: It has been merged now :-) 2025-08-11 20:19:00 thank you very much ✨ 2025-08-12 00:11:26 Can someone please merge !88567? aarch is just failing due to being killed, and rebuilds take too long for me to keep retrying 2025-08-12 00:11:55 It's kind of needed to match the recent matrix coordinated security disclosure 2025-08-12 00:19:34 shouldn't matrix-sdk be patched during build 2025-08-12 00:24:03 I did the same thing for some other package 2025-08-12 00:24:25 Plus, then I'd need to vendor it anyways 2025-08-12 00:28:16 stalwart-mail I think 2025-08-12 00:28:46 right but with this approach the patch lives in your matrix-sdk repo 2025-08-12 00:29:01 is that a problem? 2025-08-12 00:29:07 and you need to get into that repo to actually review the changes 2025-08-12 00:31:25 I'm not sure if there is any package that uses patches that way 2025-08-12 00:33:39 stalwart-mail does with ldap3 2025-08-12 00:34:06 so does mailtutan with yewdux 2025-08-12 00:34:45 (all maintained by you) 2025-08-12 00:36:22 i meant as in "unsure if someone did that before" 2025-08-12 00:38:19 idk, I don't look through packages maintained by others much 2025-08-12 00:38:29 I think it's bad on the basis that now the actual patches live outside of aports, and sometimes even on other forge 2025-08-12 01:13:50 There, fixed. 2025-08-12 07:06:39 Kladky: with patching the shit out we're totally in everything-could-break-every-moment territory and is even more unsupported by upstream than we already are 2025-08-12 07:07:12 im not sure whats the best way to tackle this is 2025-08-12 08:10:29 hi all. Can someone please remind me how to workaround the UNTRUSTED signature in a build envirnoment? I've redone my buildenv and when i build a package that remains in /home/fcolista/packages/(main|community|testing) I got this alert. I have the path in /etc/apk/repositories and i have the abuild key in /etc/apk/keys/ 2025-08-12 08:11:36 the *public* key, right? not the private key? 2025-08-12 08:11:41 sure.. 2025-08-12 08:12:18 ok fgured 2025-08-12 08:13:00 the key in /etc/apk/keys was an old one :D the new one was only in the $HOME/.abuild dir 2025-08-12 08:16:24 fcolista: protip, provide -i to abuild-keygen to automatically install it 2025-08-12 08:16:33 (I use abuild-keygen -ain) 2025-08-12 08:17:04 <3 2025-08-12 09:04:07 achill: Nah, it's just clippy lints really. 2025-08-12 09:04:20 Not anything that should change functionality 2025-08-12 09:05:37 I doubt there will be another major release until 3.23 is releases, so... 2025-08-12 09:06:10 so they just bumped the MSRV for no technical reason? 2025-08-12 09:06:18 rust is making life harder and harder 2025-08-12 09:28:22 achill: just to use if-let chains really. 2025-08-12 09:29:23 https://github.com/matrix-org/matrix-rust-sdk/pull/5432 2025-08-12 09:35:57 yes give me all my syntax sugars, compat be damned 2025-08-12 09:52:30 sooo, can we get this merged achill? pretty please? šŸ™ 2025-08-12 10:08:58 I believe !88169 is okay to merge 2025-08-12 15:06:07 help IDENTIFY 2025-08-13 11:09:13 ci builders are not caching distfiles. :-( i'm getting very slow download rates from ftp.gnu.org, resulting in job timeout 2025-08-13 13:34:54 ovf: gnu.org is under a ddos attack as of late 2025-08-13 13:35:14 report issues to #fsfsys on libera 2025-08-13 13:37:03 well, i'm reporting the issue of not caching distfiles here. 2025-08-13 13:37:39 I asked #fsfsys and yep, it's the ddos. They're working on it 2025-08-13 13:39:42 ovf: as for ci iirc it all starts clean everytime 2025-08-13 13:48:51 thanks for checking! 2025-08-13 13:49:11 uh, what's going on here? https://gitlab.alpinelinux.org/ovf/aports/-/jobs/1971598 2025-08-13 13:50:05 something seems to have failed without reporting a problem 2025-08-13 13:51:28 did we even get to abuild? 2025-08-13 13:55:03 oh, typo on my end, sorry. a bit of unfortunate diagnostics 2025-08-13 13:55:17 What was the typo? 2025-08-13 13:56:40 stray " in the middle of source. lint caught it: https://gitlab.alpinelinux.org/ovf/aports/-/jobs/1971587 but the build jobs just suddenly gave up 2025-08-13 13:56:52 * of source="..." in APKBUILD 2025-08-13 13:57:21 s/suddenly/silently/. sorry, today isn't my day 2025-08-13 14:01:52 ovf: syntax errors causes lua aports to fail 2025-08-13 14:02:02 so that would be before abuild even runs 2025-08-13 14:02:08 lua-aports* 2025-08-13 14:04:15 So before CI knows which packages to actually build 2025-08-13 14:22:19 ovf: also see https://github.com/conan-io/conan-center-index/issues/27830#issuecomment-3179784766 re gnu.org ddos 2025-08-13 16:59:04 my first time to patch CVE !88712 :) 2025-08-13 17:18:28 qaqland: looks fine to me 2025-08-13 17:23:12 s/consistant/consistent/ 2025-08-13 17:23:45 huh? 2025-08-14 03:18:34 Ariadne: thx 2025-08-15 07:55:45 If anyone has bandwidth, review+merge for !88082 and !87551 would be great 2025-08-15 08:09:47 i'll look into it in the morning if it hasn't already been processed by then 2025-08-15 09:23:14 Thanks, Ariadne. They arent critical, but they would make life a bit nicer for me, at least 2025-08-15 10:47:14 Hello, who is the author of these patches: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-rpi/APKBUILD#L19 ? 2025-08-15 10:49:00 ncopa is the one who rebases the patches and uploads it to dev.a.o 2025-08-15 10:49:18 the authors are probably github.com/raspberrypi/linux contributors 2025-08-15 10:55:33 Ok, so ncopa is the only person who could upgrade this kernel? 2025-08-15 10:56:59 No 2025-08-15 11:04:35 oh ok, I'll try to do this then 2025-08-15 11:36:06 Hi, I found the fix to use webdav again with apache2. As I'm new to alpine, I don't know if it's enough to post the patch. I posted it here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13112 2025-08-15 11:36:32 What's the proper way to get it into alpine? Thanks for your help. 2025-08-15 12:27:26 opening a merge request in the same repo 2025-08-15 13:30:13 anyone knows if mod_remoteip in apache2 should work? 2025-08-15 17:59:47 psykose: could you maybe commit my fix for apr-util? You were the last to commit to apr-util. Many thanks! 2025-08-15 18:02:37 psykose does not do a lot anymore 2025-08-15 18:39:38 ncopa: as you are the apr-util maintainer, fyi, I opened MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88788 2025-08-15 18:41:37 meiser79: note that ncopa was already assigned, so he received a notification about the MR already 2025-08-15 18:42:27 ikke: ah, ok. thanks for the heads up! 2025-08-15 19:25:08 anyone using mod_remoteip with cloudflare? I really don't get it to work, even though I did it the same way as on Ubuntu. 2025-08-15 19:42:54 If one is using a splitfunc to define a subpackage, is it possible to define a doc subpackage for that subpackage? e.g. "splitfunc" and "splitfunc-doc"? 2025-08-15 19:43:07 not sure how to handle this situtation 2025-08-15 19:43:35 error I get looks like: 2025-08-15 19:43:37 >>> WARNING: krillup*: Found /usr/share/man but package name doesn't end with -doc>>> ERROR: krillup*: Found uncompressed man pages:/home/andar1an/repos/alpine/aports/testing/krill/pkg/krillup/usr/share/man/man1/krillup.1/krillup.1 2025-08-15 19:46:04 andar1an: What does your subpkg line look like? 2025-08-15 19:46:07 subpkgs 2025-08-15 19:48:16 right now: ā–subpackages="$pkgname-openrc $pkgname-doc krillup krillup-doc krillta krillta-doc, but I just added the "-doc" entries 2025-08-15 19:49:00 ok, so the problem is that you have not moved the files to that subpackage 2025-08-15 19:49:34 Because they are still in the main package, the easiest is probably to call default_doc to get the default behavior 2025-08-15 19:49:36 I am using install to do so, is that incorrect? I am new to manpage part 2025-08-15 19:49:56 ah ok, ty. The main docs were fine 2025-08-15 19:50:00 andar1an: probably in the pacakge() func? 2025-08-15 19:50:25 ab 2025-08-15 19:50:25 I did it in the subpkg splitfunc for the non-main package 2025-08-15 19:50:35 ah* 2025-08-15 19:50:45 they are in the krillup subpackage, not krillup-doc 2025-08-15 19:50:49 but now I tried to add a second split func for doc 2025-08-15 19:51:04 ya, and I dk how to define krillup-doc 2025-08-15 19:51:10 I just tried that, and same error 2025-08-15 19:51:26 andar1an: can you share your APKBUILD? easier to tell what you need to do 2025-08-15 19:51:27 do I need to use a different syntax for subpackage like subpkgname:splitfunc 2025-08-15 19:51:38 yes'r, thank you! 2025-08-15 19:51:44 No, you need to make sure the files endup in the correct subpackage 2025-08-15 19:51:56 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86707/diffs 2025-08-15 19:52:26 currently trying: krillup-doc() {install -dm755 "$subpkgdir"/usr/share/man/man1install -Dm644 "$builddir"/doc/krillup.1 -t "$subpkgdir"/usr/share/man/man1/krillup.1} 2025-08-15 19:52:52 the default_doc function looks for man files in the main package, but it does not know what file should belong to what subpackage 2025-08-15 19:53:22 Ya, I have lines to explicitly install those files, but I didn't call default_pkg so it stayed compressed 2025-08-15 19:53:24 trying that now 2025-08-15 19:53:39 sorry, default_doc 2025-08-15 19:53:53 Calling that is good anyway, because it means you get the default behavior 2025-08-15 19:54:08 for example that it automatically installs the -doc subpackages if you install `docs` 2025-08-15 19:54:28 andar1an: I think the version as you shared now should be fine regarding to the location of the files 2025-08-15 19:55:05 it fails the build though, running with default_doc atm. Can update in a sec 2025-08-15 19:55:34 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86707/diffs#fc240c83f20ddb00a94a8846e957870984bac44f_0_86 ??? 2025-08-15 19:55:54 package() is installing manpages, that's why it's erroring. 2025-08-15 19:56:39 …nevermind, ignore me. 2025-08-15 19:57:38 I tried with the subpackage-doc lines, that failed again so I will move default_doc to subpackage split func 2025-08-15 19:57:52 yay iteration haha 2025-08-15 19:57:53 andar1an: just adding that would not fix the location 2025-08-15 19:58:02 so I need a separate func? 2025-08-15 19:58:04 default_doc would do the right thing only for one subpackage 2025-08-15 19:58:20 You _should_ call it, but it would not fix the issue 2025-08-15 19:58:21 so I need to keep install lines in a separate func? 2025-08-15 19:58:32 andar1an: I think you need to rename the -doc functions and do e.g. `krillup-doc::krillup_doc` 2025-08-15 19:58:36 (for the manpages for the subpakg)> 2025-08-15 19:58:47 that's what I was thinking earlier too 2025-08-15 19:58:59 but didn't try that yet, ty Sheila, will try now 2025-08-15 19:59:00 ah yes 2025-08-15 19:59:07 krillup-doc is not a vaild name 2025-08-15 19:59:14 for a function 2025-08-15 19:59:28 per POSIX, function names: In the shell command language, a word consisting solely of underscores, digits, and alphabetics from the portable character set. The first character of a name is not a digit. 2025-08-15 19:59:36 why I asked about naming via subpkgname:splitfunc 2025-08-15 19:59:51 but a 3rd option is just splitfunc, so was confused for doc 2025-08-15 20:00:23 https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap06.html#tag_06_01 for more on 'portable character set' if anyone's curious. 2025-08-15 20:00:24 if you have abc-foo-bar, the function abuild calls would be bar() 2025-08-15 20:01:51 ah, there was even docs about needing that for hyphen, dep. Thank you both so much 2025-08-15 20:01:57 was smacking head against wall there lol 2025-08-15 20:06:40 I think the issue is the postcheck in the splitfunc that shouldn't be installing docs is finding docs and then erring out. Will see if there is a way to ignore or something 2025-08-15 20:08:07 That would mean that the file is in the wrong location 2025-08-15 20:08:57 omg, I have been using -K, maybe that is issue, because I didn't clean up 2025-08-15 20:09:06 abuild first calls package, then each split func in order. The default implementations of various split functions move files from $pkgdir to $subpkgdir 2025-08-15 20:09:51 If you would run abuild -rK, then it would clean up at the start 2025-08-15 20:10:24 -K only matters for a succesfull build 2025-08-15 20:12:18 nice, ty. finally set up direnv aport so don't need rootbuild anymore. These flags make iteration much faster haha 2025-08-15 20:21:31 should I be compressing manpages before moving? or should default_doc or some function handle that? 2025-08-15 20:33:12 nice, just needed to put default_doc after, not before. TY!!! 2025-08-15 21:24:49 ncopa: may I ask you to bump linux-rpi? current patches apply smoothly to .41 2025-08-16 00:53:00 does this indicate that util-linux might need a rebuild? https://gitlab.alpinelinux.org/dne/aports/-/jobs/1975028#L893 2025-08-16 00:57:51 Yes 2025-08-16 02:39:56 Could I get a review on !88082 after addressing achill's feedback? 2025-08-16 02:40:13 Also, I think Rhythmbox might need a rebuild as it crashes constantly unless plugins are disabled 2025-08-16 02:42:19 https://bpa.st/MKYQ 2025-08-16 08:50:52 Hey, could anyone please look at !86091 2025-08-16 08:51:31 !86084 !85946 !86363 !80914 2025-08-16 13:18:17 !88784 too now 2025-08-16 18:11:10 heads up: i removed myself from team/gnome a few days ago; i don't really have the time to review everything gnome-related. (not sure if gitlab notifies about that stuff, so posting it here) 2025-08-16 18:37:55 knuxify: it needs to be updated in the gitlab-tf repo as well, otherwise it would add you back 2025-08-17 00:47:15 uhm, why did an `apk -aU upgrade` just install dracut with dependencies? (no packages were upgraded) 2025-08-17 00:50:01 and `apk info --rdepends dracut` saying it is required by syslinux, linux-lts and grub-xenhost 2025-08-17 00:51:26 but `apk del dracut` didn't complain and removed it with all the dependencies that were previously installed 2025-08-17 01:10:56 hmm... is it because I downgraded mkinitfs and it is, somehow, no longer providing initramfs-generator? 2025-08-17 01:19:17 ok, I think I get it, I guess I'll have to allow the additional packages I won't use, for now 2025-08-17 04:01:44 this update not only fix gcc15, but also introduces some functional changes, which may require more reviews !86627 2025-08-17 04:02:23 https://github.com/bats-core/bats-assert/issues/83 2025-08-17 07:35:44 lnl: chromium apparently has test failures 2025-08-17 07:36:41 3 tests, TrustStoreNSSTest* 2025-08-17 08:25:10 restarting gitlab in 5 minutes to apply security patches 2025-08-17 09:33:52 !88866 2025-08-17 09:42:04 *sigh* now my clipboard is broken? 2025-08-17 09:43:10 as in, I have content whith `wl-paste -p` but not when I do Shift+Insert 2025-08-17 09:43:47 I'm not a fan of just disabling failing tests 2025-08-17 09:48:44 sure, me neither, but it is the only thing I, as the one who merged it, can provide to unblock the builders 2025-08-17 09:49:03 similar tests are already disabled because they failed in CI previously 2025-08-17 09:50:25 omni: Does it happen again and could you try if apk fix removes it as well. 2025-08-17 09:51:59 Sertonix[m]: yes it happens again and `apk fix` does not remove it 2025-08-17 09:52:44 I downgraded mkinitfs by installing an archived apk file, it seems like it doesn't provide initramfs-generator then 2025-08-17 09:54:50 I discovered that it was the reuirement on initramfs-generator from the other packages that installed dracut etc after trying to block mkinitfs from being installed by adding dracut<0 to /etc/apk/world 2025-08-17 10:02:24 [clipboard] some characters made it not pastable with Shift+Insert, `wl-paste -p | strings | wl-copy -pn` works around it 2025-08-17 10:14:09 The provider should work exactly the same when coming from a file. So there might be some apk solver bug involved. 2025-08-17 12:02:15 hi, i want to upgrade py3-zipp in !88712 because there is a CVE. tried to rebuild packages that depend on it, but aws-cli always failed 2025-08-17 12:02:49 !88712 and !88799 2025-08-17 12:03:38 later, i found that even if nothing was changed, aws-cli still check failed 2025-08-17 12:03:51 https://gitlab.alpinelinux.org/qaqland/aports/-/merge_requests/1 2025-08-17 12:05:01 what should i do in this situation :| 2025-08-17 12:06:42 "Terminated" is interesting 2025-08-17 12:37:26 yeah aws-cli's tests are a mess 2025-08-17 12:37:33 they take more and more RAM 2025-08-17 12:38:14 you can set $cores in line 80 to =1, thats even slower than it already is but at least it suceeds 2025-08-17 22:19:49 is the process for taking over an unmaintained package documented anywhere? (I googled and didn't find any info) 2025-08-17 22:40:32 iggy: i dont think its properly documented yet, and thats what im stil working on, but tldr: if nobody maintains it, please do help out! just open a MR with setting yourself as a mainatainer (and bumping pkgrel) or just combine it with a package upgrade. 2025-08-18 02:02:23 the packages I'm looking at technically have a maintainer listed, but he hasn't touched the packages in over a year 2025-08-18 02:04:28 one of them has more total commits from you than from the person listed as maintainer... 2025-08-18 02:18:44 iggy: if that's the case typically you'd try to reach out to the current maintainer, ask them if they are still maintaining it/actively contributing to Alpine's maintenance, and if not if they would mind if you took maintainership of the package in question 2025-08-18 02:19:40 some maintainers don't actively bump packages, or only do so during the lead up to a new stable release 2025-08-18 02:21:40 there have been 2 stable releases since he touched either of these packages, so I doubt that's it 2025-08-18 02:22:18 seems more like he doesn't use either of these packages so just doesn't care 2025-08-18 02:29:59 it's entirely possible, it does happen. Curious, what're the packages you're looking into? 2025-08-18 02:43:47 valkey is one 2025-08-18 02:45:41 ah, well that's one of jirukta's packages, he typically updates his packages in bulk right before a release is cut 2025-08-18 02:46:32 he's very much an active maintainer, so for that one the best move would be to offer to help, and bump the version in edge if you have the time to build and test it 2025-08-18 02:55:58 it just feels like it could use someone who was a little more active on that package... as mentioned earlier achill has more commits on it than he does (and some of those wouldn't be necessary if he was actively updating the package) 2025-08-18 03:08:01 You can send commits without be the main maintainer though 2025-08-18 03:08:08 s/be/being/ 2025-08-18 06:36:59 ncopa: are you available? 2025-08-18 08:44:32 meiser79: occationally. please just ask you question and I'll respond when I get a chance 2025-08-18 09:36:11 ncopa: may I ask you to have a look at MR 88788? 2025-08-18 09:46:17 I was on the waiting list too :-( 2025-08-18 09:48:52 Just have a little patience :) 2025-08-18 09:53:59 I believe !88169 is ready to be merged. 2025-08-18 11:33:31 Biswa96[m]: which is your MR? 2025-08-18 12:05:28 Hummm, some cmake software build complains that it can't find tinyxml2-config.cmake (or tinyxml2Config.cmake) on the system, isn't that supposed to be from tinyxml2-dev or cmake? 2025-08-18 12:07:40 quinq: we compile tinyxml2 with meson so the cmake config files arent generated 2025-08-18 12:08:00 you can probably patch it very easily to read the pkgconf file 2025-08-18 12:11:23 Thanks achill 2025-08-18 12:11:32 Though I really fear going down cmake debugging hellp 2025-08-18 12:11:40 -p 2025-08-18 12:12:13 (subconscious sanity already cried for help) 2025-08-18 13:18:33 ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87988 2025-08-18 15:02:54 Biswa96[m]: CI is red? It is possible to increase the timeout for riscv64. 2025-08-18 15:03:09 but I'm running a build here locally now 2025-08-18 16:35:00 ncopa: thanks a lot for merging!! 2025-08-19 00:50:33 hi, how can i set the Assignee of an issue to me? 2025-08-19 00:54:29 i plan to "watch" issues when i have time 2025-08-19 04:26:57 I cannot access the GitLab instance anymore. Blocked by go-away 2025-08-19 04:28:33 Tried both firefox and ungoogled-chromium 2025-08-19 04:28:43 It happened to me a month ago. But one maintainer fixed it after some time. 2025-08-19 04:29:56 follie: do you get a log id? 2025-08-19 04:30:53 Do you mean the request ID? 2025-08-19 04:31:00 c3a94ac539eddb3685a2560ae3cbfde9 2025-08-19 04:31:36 yes 2025-08-19 04:32:14 Error: access denied: denied by administrative rule c3a94ac539eddb3685a2560ae3cbfde9/a6ce26cde738fca72c1d 2025-08-19 04:32:19 This is the error message btw 2025-08-19 04:35:50 follie: can you try again? 2025-08-19 04:36:31 Thanks! It works now 2025-08-19 04:37:00 Sorry about that 2025-08-19 04:37:51 Some companies abuse residential proxies to bypass measures 2025-08-19 04:38:21 No worries. I understand that AI scrapers are a big problem 2025-08-19 20:14:19 WhyNotHugo: btw i had something in mind to doing a "a ..."/"the ..." check for pkgdesc in abuild itself: https://gitlab.alpinelinux.org/fossdd/abuild/-/commit/298b83eb1b884bd17349c44bd745fef1643d8fd2 2025-08-19 20:14:31 didnt properly test it but it would be nice to havei i think 2025-08-19 20:15:03 the insproration came from cbuild by chimera which does a lot of minor input handling that would be nice to add in aubild 2025-08-19 22:49:49 achill: Since this is more of a codestyle thing I am uncertain if abuild is the right place. Such things are handled in atools-go most of the time. (I am not completely against changing that) 2025-08-20 06:24:59 Sertonix[m]: the good thing about doing this in abuild is that everybody will notice it and things change and will be implemented 2025-08-20 07:26:36 achill: Also "provides…" and "allows…". I've been thinking about adding this to CODESTYLE.md 2025-08-20 07:28:14 Also pkgdesc should typically not say things like "open source package…" 2025-08-20 10:25:54 hello I would like to ask: If I want to contribute to the maintenance and writing of the package, is any review required, or can I directly submit it to testing? 2025-08-20 10:26:42 zhenruyan: All MRs will be reviewed by a developer 2025-08-20 10:31:24 Okay, thank you for your reply. That means my PR will be reviewed after I submit it. 2025-08-20 10:32:11 yes 2025-08-20 12:24:58 Hey, at Greenbone Networks we aim to ingest the secdb content of Alpine to add it to our vulnerability detection system. While investigating this, I noticed one component that seems to me to be an error, another that I'm not entirely sure about: 2025-08-20 12:25:49 (i) certain "secfixes" simply state "0" as the vulnerable version, i.e., no actual vulnerable version can be deduced according to my perspective. 2025-08-20 12:27:59 (ii) certain, though much fewer, packages come without the "-rxyz" suffix. I'm suspecting this *might* be an error due to the rarity, but I'm not certain. We could In that case, my initial guess is that it should be equvalent to assuming "-r0" as the default release, leading to an equivalence between the apk and rpm package regex as far as I can tell. 2025-08-20 12:28:47 For context, case (i) occurs in 178 times, case (ii) just 20 times; measured for versions 3.19-3.22 (including) and edge, for both main and the community repo. 2025-08-20 12:37:20 case i means that we deem the package not have been vulnerable to that CVE 2025-08-20 12:37:26 to not* 2025-08-20 12:38:11 case ii probably means a data entry mistake 2025-08-20 12:38:29 Olav_Lamberts: Do you have examples? 2025-08-20 12:39:23 "edge:main:ghostscript:10.05.1" or "v3.21:community:croc:10.0.11-0", I can post the full list if you want. 2025-08-20 12:39:33 And thanks for the quick response and clarification! 2025-08-20 12:40:05 Yeah, the entries for ghostscript are incorrect 2025-08-20 12:40:08 yeah thats just a typo, i can fix it 2025-08-20 12:40:16 achill: ok, thanks 2025-08-20 12:42:20 from community, it's "croc", "plasma-workspace", "synapse", "vaultwarden". From main it's just "ghostscript", the 20 occurances scattered across the different alpine versions and pkg. versions. 2025-08-20 12:43:00 sweet thx, i'll look over it and find the related pkgrels 2025-08-20 12:43:03 I can mail the community maintainers for the resp. packages if you prefer that. 2025-08-20 12:43:22 nah its fine 2025-08-20 12:43:25 Nice, thanks for taking care of it! 2025-08-20 12:45:19 Is my assumption that any correct pkg matches the rpm regex right? Excluding the already discussed accurances, using {pkg_name}-{pkg-version}.{architecture} matches all other packages posted in the secdb. 2025-08-20 12:46:11 More concretely, that encoding is valid rpm encoding for all packages in the secdb. 2025-08-20 12:47:03 We do not include the architecture 2025-08-20 12:48:10 Not in the secdb, but I map the apkindex to it s.t. I know which architectures a given pkg is actually compiled for. 2025-08-20 12:48:58 I just wanted to know, whether there I should expect package encoding that is not compliant with rpm (ignoring architecture included/exluded) :) 2025-08-20 12:49:47 https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-package.5.scd#L47 this pretty much describes how apk's versions look 2025-08-20 12:50:09 dunno if thats complient with rpom 2025-08-20 12:50:11 Ah, thanks. That will do 2025-08-20 12:50:43 Alpines version scheme is derived from Gentoo 2025-08-20 13:57:59 Synthing 2.x has changed/removed options without any backwords compatibility. Any opinion on just warning on upgrade or patch in some compat options? 2025-08-20 13:58:58 I think patching in compat options could be confusing 2025-08-20 13:59:17 And could also make it harder to keep the package up-to-date 2025-08-20 13:59:47 Sertonix[m]: What options are that? 2025-08-20 14:03:04 I don't have a complete list but these once I noticed: --no-default-folder has been removed due to being the default now. --skip-port-probing was renamed to --no-port-probing. 2025-08-20 14:21:22 If one wants to use apk add -X instead of editing repositories file to point at local packages, it there a flag to update index so command sees pkg? I see an --initdb option, but dk if that would make sense. 2025-08-20 14:22:22 also see --upgrade, but dk if there is just an update 2025-08-20 14:23:30 You probably want to use -U 2025-08-20 14:23:39 merci 2025-08-20 14:24:34 I get: 2025-08-20 14:25:03 doas apk add -U --repository /home/andar1an/repos/alpine/aports/testing/ krill 2025-08-20 14:25:04 WARNING: opening /home/andar1an/repos/alpine/aports/testing/x86_64/APKINDEX.tar.gz: No such file or directory 2025-08-20 14:25:37 I dk if it has to do with being on a branch, with I don't think is the case. But the files are there 2025-08-20 14:26:06 Does that file exist if you check ls? 2025-08-20 14:26:13 yes 2025-08-20 14:26:20 also is visible in file managers 2025-08-20 14:28:47 Could you check with strace whether or not the file is opened succesfully ? 2025-08-20 14:30:00 will do 2025-08-20 14:34:19 thank you, that gave more info 2025-08-20 14:35:07 file opens fine 2025-08-20 14:35:22 just not finding configuration files that would be moved into place with apk add 2025-08-20 14:48:28 has to do with my repo, didn't like it in repositories file either. Will see why. 2025-08-20 14:55:56 I didn't create an apkindex, should one be using apk index command for local testing? Or should that be already happening with abuild? 2025-08-20 14:58:06 it exists from running abuild. Ignore that 2025-08-20 14:58:53 was my mistake. I pointed to build directory instead of outut package dir. Derp 2025-08-20 16:29:19 Sertonix[m]: re syncthing, I think in general, when bumping a major version number, its up to user to figure it out. but we cannot bump that in stable branch 2025-08-20 16:29:38 other option is to add a syncthing2 package 2025-08-20 16:34:53 urgh i dislake that 2025-08-20 16:35:18 maybe a warning in post-upgrade and let the rest up to the user? 2025-08-20 16:35:43 but otherwise yeah if upstream doesnt add compat options its up to the user to figure stuff out 2025-08-20 16:35:55 (maybe also a changelog on the relaese notes) 2025-08-20 22:31:23 I've got a project that builds normally with 'make' but when I make an APKBUILD and run abuild -r I get incompatible type errors on some void pointers (with the same CFLAGS). anyone seen anything like this? is there documentation I can consult on what abuild does to the environment? 2025-08-21 00:23:54 Would anyone mind reviewing !88452 ? it has been sitting for a little bit. 2025-08-21 00:57:47 When someone has bandwidth, a review/test of cobang would be nice, especially anyone in PMOS !88082 2025-08-21 00:58:00 elagostI'd like to have that util :) 2025-08-21 01:08:25 @saijin_naib:matrix.org Tested using mrtest and left a review. 2025-08-21 09:03:44 I think !88456 is ready to be merged. 2025-08-21 11:18:44 Hi! Was surprised to see that there is a difference in the version of Clang 19 shipped in 3.21 (19.1.4) compared to 3.22 and edge (19.1.7). Is that by design? 2025-08-21 11:21:04 Not necessarily 2025-08-21 11:29:40 Hummm, just out of curiosity, why is it surprising that a newer version of Alpine uses a newer version of clang? 2025-08-21 11:29:49 (or maybe I misunderstand the question) 2025-08-21 11:32:54 quinq: I suppose they expected it to be the same 2025-08-21 11:33:17 Because it's a difference in the patch level version only and the 3.21 branch is still actively supported (at least for packages in 'main'). 2025-08-21 11:33:50 So I was expecting it to be the same :) 2025-08-21 11:36:02 Ah you mean you'd expect 3.22 (or edge) clang back-ported to 3.21, could makes sense yeah 2025-08-21 11:36:05 thanks :) 2025-08-21 11:39:05 Exactly. 2025-08-21 11:41:27 Would be happy to file a PR with the backport unless somebody else is already on it. 2025-08-21 11:41:40 I have not seen one yet 2025-08-21 11:44:57 moha: go ahead :) 2025-08-21 11:55:56 can someone test !87929? otherwise if nothing bad happens i guess im gonna merge it this evening (CEST) 2025-08-21 12:52:42 Here we go: !89053 . Builds are still running and might take a while as some of the backported build fixes affect the other clang/llvm packages as well. 2025-08-21 20:59:51 Is there any way to search in buildlogs? I would like to have a list of packages that were build with py3-setuptools 77.0.3-r0. 2025-08-21 21:24:41 Hey I've found a nice package i'd like to contribute an APKBUILD for. Kinda confused about Contributor & Maintainer fields. Contributor is the author of the package, and Maintainer would be myself, right? 2025-08-21 21:32:00 I had similar questions. i think Maintainer is author who create the APKBUILD, if author not Maintainer anymore, he/she become Contributor. I'm not quite sure.. If I understand wrongly, please point it out. 2025-08-21 21:40:59 Now that I think of it (and after grepping exiting APKBUILDS) i think it's the other way around - i.e. Contributor is myself (since i'm the one contributing the APKBUILD) and Maintainer is the author - e.g. main/rust-bindgen reflects this 2025-08-21 21:42:14 maintainer is responsible for ensuring package is healthy, usually maintainer is also one of contributor, and there might be more developers interested to fix/develop the package they submit PRs and contribute 2025-08-21 21:42:49 original author could be the maintainer as well since that just makes sense 2025-08-21 21:43:08 and if things change someone else could assume the role 2025-08-21 21:43:10 etc. 2025-08-21 21:50:33 makes sense, thanks! 2025-08-21 21:54:10 agree with khem, thanks 2025-08-21 22:16:19 If in doubt these fields can be left unchanged 2025-08-21 22:41:37 Will try to capture that in abuild/APKBUILD.5.scd soonish. Gotta finally learn the manpage syntax 2025-08-21 22:43:56 oh, hold on, it's just markdown, how nice. i think i need some sleep. 2025-08-22 15:16:49 howdie all, got a qa bump and just wondering if there is anything further I should do for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87395#note_534945 2025-08-22 15:17:05 can I just leave it? 2025-08-22 15:45:23 andar1an: if you're just waiting for review you do not need to do anything, just ping the people responsible for reviewing 2025-08-22 15:45:41 and it seems that ikke removed the label anyway 2025-08-22 18:11:22 ty 2025-08-22 18:12:01 the qa bot and label being added was why I asked 2025-08-22 18:12:48 andar1an: no need to worry about it if you're done 2025-08-22 19:27:39 achill: question for you, would you mind if I take maintainership of cloud-init? 2025-08-23 04:23:06 https://github.com/libsixel/libsixel is archived while https://github.com/saitoha/libsixel is back 2025-08-23 12:55:27 Is there a reason we still have the (deprecated) raspberrypi-userland package? 2025-08-23 13:50:29 I'm trying learn the whole process of creating merge requests and gitlab since I have patches I would love to contribute; If I create a new branch, add my patches, commit it and push, then inside gitlab create a request from my branch on aports to master on aports, is there anything else I should do? Even if the branch gets out of date, do I simply wait for it to be approved or 2025-08-23 13:50:31 is there something I should actively ensure, like keeping the branch up to date by repeatedly mergeing new changes? 2025-08-23 13:53:00 bulldozer: you don't need to actively keep the branch up to date (especially not by merging in changes) 2025-08-23 13:53:13 Once someone has reviewed it, they will rebase the branch and then merge it in 2025-08-23 13:54:05 So since I've made sure my changes are propperly working and I've created the request. There is nothing I should do unless someone comments on the requests? 2025-08-23 13:54:24 correct 2025-08-23 13:54:49 Thank you. 2025-08-23 14:53:47 I have a failling pipeline because it's trying to build something unrelated. Is it possible to see the job instructions themself to debug this? 2025-08-23 14:54:44 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh 2025-08-23 14:55:26 It compares the branch against the target branch and builds each package where the APKBUILD file changed 2025-08-23 14:56:00 ikke, that's the problem then. 2025-08-23 14:56:28 Not sure what to do then, because one of them has been reverted. 2025-08-23 14:57:00 Which MR? 2025-08-23 14:58:55 I sent via DM, I hope that's okay. 2025-08-23 14:59:27 I see it 2025-08-23 15:00:29 It works better if you keep you branch clean, with only changes that you want to amke 2025-08-23 15:00:31 make 2025-08-23 15:00:41 You merge in all kind of unrelated commits and reverts 2025-08-23 15:02:21 I see. And that is a bad thing. I'm unsure how to correct it. The unreated merges came from clicking merge on gitlab, which you told me now that I don't need to do. I also messed up by using the master branch initially, I understand now I should be using seperate branches. 2025-08-23 15:03:04 yes, each MR should have it's own dedicated branch indeed 2025-08-23 15:03:27 So to fix this: 2025-08-23 15:03:41 I did not know this initally but now I see why that is. This is my fault and I do appoligise for the inconvinience caused by this. 2025-08-23 15:03:42 git remote add upstream https://gitlab.alpinelinux.org/alpine/aports.git 2025-08-23 15:03:54 git fetch upstream 2025-08-23 15:04:21 git rebase --onto upstream/master prosody_upgrade~ prosody_upgrade 2025-08-23 15:05:09 This should result in your prosody_upgrade branch to have only that single commit 2025-08-23 15:05:16 Do I do this on the prosody branch? Also if you don't mind, could you please explain the last command to me so I know how it works in case I may need it in the future. 2025-08-23 15:05:52 It checks out the prosdy_upgrade branch (the last argument) 2025-08-23 15:06:16 It then takes prosdy_upgrade~1..prosdy_upgrade commits 2025-08-23 15:06:23 and applies them --onto upstream/master 2025-08-23 15:07:12 if you do `git log --oneline prosdy_upgrade~1..prosdy_upgrade`, you'll see that one upgrade commit 2025-08-23 15:07:16 Ah I see, so take upstream/master and add last commit to it, discard everything else? 2025-08-23 15:07:22 yes 2025-08-23 15:07:36 Your local master branch still contains everything else 2025-08-23 15:07:41 you can fix that later 2025-08-23 15:08:14 Thank you for explaining, and this may be useful for other fork's master aswell, as you can see I messed up the commit history quite a bit. 2025-08-23 15:09:06 That looks a lot better :) 2025-08-23 15:10:00 Is there a safe way I can test out a rebase without it affecting anything as I would like to this aswell for the master branch, it may be a good idea to clean up the commits I had in that one. 2025-08-23 15:13:01 You can safely do this on your master branch and push that to your fork without messing anythin up 2025-08-23 15:18:30 I was able to roughly figure how to rebase in another case MR. It is now clean like the prosody one. Thank you for teaching about this. 2025-08-23 15:27:05 You're welcome 2025-08-24 09:05:41 hello, I submitted a game long time ago, unfortunatelly I have no time and not alpine linux to keep testing and building packages for it, is anyone interested feel free to check notes here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69804#note_535370 and use this APKBUILD as refenrece: https://codeberg.org/glitchapp/spinny-the-runner/src/branch/main/apk for questions feel free to reach me here on in gitlab 2025-08-24 09:07:51 is anyone interested on automating builds or maintaining packages for alpine, bare in mind assets are quite big the game is around 600mb at the moment, otherwise buidling is straightforward and the game is scripted and can be tested without building from terminal 2025-08-24 17:11:21 Hi there o/ I have a stupid support question regarding Alpine's gitlab. I have contributions to propose in aports, however I'm stuck at the registration phase on gitlab.alpinelinux.org because the confirmation email seems to never land in my mailbox. I suspect spam filtering on my email provider's side (it happened before). Problem is: I can whitelist email addresses but not 2025-08-24 17:11:23 whole domains, and I don't know which email to whitelist to let the confirmation email land in. 2025-08-24 17:12:20 I think it might be gitlab@alpinelinux.org samaingw 2025-08-24 17:14:18 Thanks @f_, I'll try that right now ! 2025-08-24 17:15:32 either that or gitlab@gitlab.alpinelinux.org 2025-08-24 17:15:35 one of them 2025-08-24 17:32:51 Oh, also another question. I'm working on issue 17311 (pkg breakages with gcc15), on the v3.23 roadmap. I'd like to correctly understand the way to provide the fixes. Is the correct way 1) patch the version already packaged, propose the patch upstream, and remove the downstream patchset in a future version of alpine OR 2) first talk with upstream, and if the patches got merge 2025-08-24 17:32:53 "quite quickly" (to be defined), bump the pkg version of the APKBUILD for v3.23 2025-08-24 17:34:47 (typically I have a fix for polybar which just adds `#include ` in one header) 2025-08-26 09:03:01 i think im going to merge ffmpeg7 in the next days and start rebuilding, didn't check all packages if they rebuild but if im not going to do it now it'll get more work when ffmpeg8 is out 2025-08-26 09:03:56 theres gonna be a ffmpeg6 package since a few packages are too old to support ffmpeg 7 and upgrading them is a bit more work 2025-08-26 09:05:10 \o/ 2025-08-26 09:15:35 very nice! thanks! 2025-08-26 09:17:43 I have been thinking of having a "community hours" meeting or similar. The idea is to have an open meeting for anyone to join and be able to talk with alpine devs 2025-08-26 09:18:08 is that something that could be worth doing? 2025-08-26 09:18:27 if you can spare the manpower I think it's a great idea 2025-08-26 09:18:39 community engagement is a good thing 2025-08-26 09:19:15 it could be weekly, bi-weekly or monthly. not sure which makes most sense 2025-08-26 09:19:48 i know other open source projects does that. for example k0s has a monthly open meeting 2025-08-26 09:26:07 ncopa: like, office hours? 2025-08-26 09:26:13 postmarketos does it aswell: https://wiki.postmarketos.org/wiki/Office_hours 2025-08-26 09:26:27 did.. I think ^ 2025-08-26 09:26:39 nevermind 2025-08-26 09:27:15 its very sucessful e.g. for new people to ask questions they wouldn't have asked in chat or so 2025-08-26 09:27:32 and just connecting and realising there are people behind things 2025-08-26 09:27:36 don't tell anyone but I'm considering possibly volunteering for office hours every once in a while 2025-08-26 09:27:47 also llvm's: https://llvm.org/docs/GettingInvolved.html#office-hours 2025-08-26 09:27:53 I realised I really like jitsi'ing 2025-08-26 09:29:29 ncopa: so I think that'd be a good idea for alpine too 2025-08-26 09:29:54 if only just to get in touch and chit-chat in a slightly more natural way than IRC 2025-08-26 09:30:29 yeah 2025-08-26 09:31:00 and for developers also, kinda taking a little break while chit-chatting :) 2025-08-26 09:33:27 11:19 <@ncopa> it could be weekly, bi-weekly or monthly. not sure which makes most sense 2025-08-26 09:33:49 maybe try monthly first and then do bi-weekly if it's extremely successful 2025-08-26 09:34:12 I come to pmos office hours to chit-chat 2025-08-26 09:34:22 Ermine: nice 2025-08-26 09:34:24 It's genuinely cool 2025-08-26 09:34:33 I can see that 2025-08-26 09:40:30 looks like pmos and llvm does office hours for individual devs. in k0sproject we do it with the entire k0s team. so you meet the entire team 2025-08-26 09:40:50 we have k0sproject office hours today 2025-08-26 09:42:23 i was thinking having it as a single open meeting for anyone, devs or users to join 2025-08-26 09:48:47 ncopa: correct 2025-08-26 10:32:57 I love the QGIS project Jitsi meets, and I would join Alpine for sure 2025-08-26 10:33:10 It is great community-building 2025-08-26 10:33:52 Hardest thing for when I tried for OpenDroneMap was picking a timezone that serves everyone as fairly as possible 2025-08-26 13:02:49 i noticed markdown-oxide and dprint are in apk now, so I started to look into other lsps I use. Wondering if an html lsp or svg previewer is also in apk that is common. I have been using superhtml and resvg and am debating making a pr for these. 2025-08-26 18:09:41 Hello 2025-08-26 18:10:05 I fixed the lint issues upon: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79350#note_535139 2025-08-26 18:10:21 should I move to a seperate branch? 2025-08-26 19:15:37 pc_magas: fossdd sent some more review 2025-08-26 19:15:55 (I know they quit but .. the joys of public logs :) 2025-08-26 21:21:43 Looks rv64 builder for 3.22 stuck on PHP imagick 2025-08-27 08:38:49 andypost[m]: seems like its been stuck since 19th aug. I killed php82 and restarted it 2025-08-27 09:00:41 ncopa: thank you 2025-08-27 09:59:41 any feedback for !89116 ? 2025-08-27 13:23:50 !89275 we can create a sample folder in aports, storing softlinks for various languages project 2025-08-27 13:24:40 ACTION don't think this MR itself is meaningful 2025-08-27 13:26:06 newapkbuild is meant for that, no need to store sample projects in aports 2025-08-27 13:28:43 achill: this should fix your issues with zfs 2.3.4 https://github.com/openzfs/zfs/pull/17675 2025-08-27 13:29:06 awesome thank you! 2025-08-27 13:29:25 replaces your current patch in your MR 2025-08-27 13:29:39 yeah it was not a good patch anyway 2025-08-27 13:40:12 abby: i think i still get the same build failure: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1988554 2025-08-27 13:41:29 checking for linux/stat.h... yes 2025-08-27 13:41:29 checking for statx... yes 2025-08-27 13:41:29 checking for STATX_MNT_ID... yes 2025-08-27 13:41:48 you sure you applied the patch? that should say sys/stat.h with my patch 2025-08-27 13:44:34 oh i guess i have to regenerate the autotools stuff 2025-08-27 13:45:24 but i dont think that should matter re the build failre 2025-08-27 13:46:47 it does, because it should be yes, yes, no on musl 1.2 2025-08-27 13:47:56 and yes/yes/no undefines HAVE_STATX_MNT_ID which is what guards the blocks that error 2025-08-27 13:49:17 ohh 2025-08-27 14:20:22 Is there something going wrong with gitlab? Seems really unresponsive to me right now, but not sure if it's my internet connection 2025-08-27 14:26:27 pabloyoyoista: For me, it's showing - HTTP 502: Waiting for GitLab to boot 2025-08-27 14:27:16 Ok, thanks! Seems to be fast again, not sure why I missed that message 2025-08-27 14:27:42 now it's fine. 2025-08-27 14:27:54 I just restarted it. Something is causing load in a way that sustains itself 2025-08-28 08:24:15 i wish there would be a way to make $builddir not include $srcdir 2025-08-28 10:30:10 Why? 2025-08-28 10:46:58 its redudundant without any reason, literally every builddir declaration includes srcdir 2025-08-28 11:01:50 achill: modify abuild to check if builddir starts with srcdir and if it doesn't, automatically prepend that? 2025-08-28 11:02:05 if every existing declaration includes that it should be fully backwards compatibl 2025-08-28 11:02:06 e 2025-08-28 11:57:52 There's one exception: community/rmlmapper/APKBUILD:17:builddir="$pkgname-java-$pkgver" 2025-08-28 11:58:18 I'm surprised it works, I've bad builds fail in mysterious ways when I forgt the leading $srcdir 2025-08-28 12:15:09 achill: I amĀ uncertain how easy builddir="." will be to understand. But on a related note I think we should strip the first path element from tarballs and make builddir="$srcdir" the default. That could make builddir redundant and helps tools like ccache to work better across pkgver bumps. 2025-08-28 12:15:52 agreed 2025-08-28 12:15:55 WhyNotHugo: I am pretty certain that I have a MR to make incorrect builddir a fatal error instead of silently ignoring it 2025-08-28 16:58:04 I think we should publish https://wwwtest.alpinelinux.org/posts/2025-08-27-new-alpine-developers-process.html 2025-08-28 18:31:02 > maintenance burden continues pilling up --- piling* 2025-08-28 18:31:59 > 50 new merge requests make it aports --- to aports* 2025-08-28 18:32:13 ncopa, Ermine: pushed to https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/108 together with a comment from durrendal 2025-08-28 18:33:35 > Provide clear goals and expectations for people willing --- expectations from people? 2025-08-28 18:40:42 For the people applying to understand? 2025-08-28 18:40:55 for is correct 2025-08-28 18:42:57 okay 2025-08-29 03:55:04 Windows 12 and Windows 13 Already Out , Original Coder by [ 0day (xc) Our ] , https://www.worldhacker.org and https://linkedin.com/in/worldhacker ... . 2025-08-29 03:55:25 Windows 12 and Windows 13 Already Out , Original Coder by [ 0day (xc) Our ] , https://www.worldhacker.org and https://linkedin.com/in/worldhacker ... . 2025-08-29 03:56:13 https://www.worldhacker.org/astaraos/ for List of Our OS , https://www.worldhacker.org/current-world-game/ for current worldgame and https://www.worldhacker.org/our-music/ Our Music ... . 2025-08-29 09:06:21 thanks for ffmpeg7 fossdd 2025-08-29 09:39:52 no problem, now we just need to 1. rebuild missing stuff and makedepend on ffmpeg6-dev if it doesn't work 2. if $time passed, do it all over again for ffmpeg 8 2025-08-29 12:11:58 thanks for handling that achill 2025-08-30 07:41:06 its finally published https://alpinelinux.org/posts/2025-08-30-new-alpine-developers-process.html 2025-08-30 07:42:59 nice 2025-08-30 07:46:40 is there supposed to be some text in the new developer issue template? it just gives me an empty textarea 2025-08-30 07:58:14 hum.. looks like that is not yet done 2025-08-30 08:46:34 that's great. hope the number of our MRs can drop from over 700 back to over 300 :) 2025-08-30 08:53:08 good step in the right direction, would also love to see some more formal documentation for people that are inbetween "sent a few version bump MRs" and "full blown committers"... the kind of people that have signed up to maintain a package or three that they use, but have to rely on other committers to actually get anything done 2025-08-30 08:53:34 but maybe that will be less hard with more committers in general 2025-08-30 09:00:56 most MRs are in draft, other ones are new packages (which will take much more time) and other ones are waiting for maintainer approval 2025-08-30 09:01:22 actual MRs that can be merged are really minimal and im always searching the ones 2025-08-30 09:02:10 i see 2025-08-30 11:01:42 Yeah, the MR queue is mostly not a lack of people pressing the merge button 2025-08-30 11:07:32 I tried maintaining ceph for a while (had my name in the maintainer field), but gave up because I was waiting months for my MRs to get merged 2025-08-30 11:10:13 I couldn't really find info on how to get them merged... these days I could probably do a better job 2025-08-30 11:11:38 I just think helping people who actually use certain packages to maintain those packages would be great (vs people who are maintaining packages they don't even use or worse don't even like) 2025-08-30 12:43:13 just ping us here in case we forgot something 2025-08-30 12:43:36 theres so much we need to keep track of and my mails are not really short so a ping here is always appreciated 2025-08-30 12:44:07 achill: you are always appreciated! 2025-08-30 15:20:42 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/cjson/APKBUILD#L27 2025-08-30 15:21:22 it's a little hacking 2025-08-30 15:21:58 when want to use system cjson library with cmake, it always requires me to install cjson-static 2025-08-30 15:52:23 create this one to fix it !89418 2025-08-30 21:49:41 could someone look at !89412 and tell me if the post install script is ok? I didn't do anything to make it clever. Am I able to use variables like $pkgver in a postinstall script? 2025-08-30 21:59:50 Hello. This is a big one, I made the initial MR adding support for initramfs hooks to `mkinitfs`: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/206 2025-08-30 21:59:50 This will enable stuff like plymouth, clevis, unl0kr to work on alpine. more details in the MR and would like some feedback and reviews!! 2025-08-31 03:27:21 angeloverlain, thanks for the notes in https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/206. I'll appreciate if you can add a note/blog/wiki on using plymouth in alpine with this MR . this will be highly appreciated, as currently none exists afaik 2025-08-31 04:47:05 Hello, can someone have a look at !87884 please 2025-08-31 08:15:06 "angeloverlain, thanks for the..." <- Hello. I will add soon all the things needed for this in the MR 2025-08-31 08:18:41 In an openrc user service init script, can I not exclude the full path to the executable in `command`? 2025-08-31 09:35:18 you can, if the executable is in openrc's PATH