2025-10-01 00:40:28 <elagost> q66: updated the webkit2gtk aports MR, I think i added a few of the patches? sorry if it's not correct I'm in a bit of a hurry.
2025-10-01 05:03:37 <jvvv> i have a MR that is awaiting maintainer approval. it has been assigned to the maintainer. the maintainer's email addy bounces. should i ping in the MR comments? is there a better way?
2025-10-01 05:10:14 <jvvv> also, i've found that i need hplip for my printer so i managed to get it to build. is there anything special i should do, other than submit an MR that resurrects hplip with me as maintainer?
2025-10-01 05:12:40 <jvvv> hplip was in community before being moved to unmaintained (which is no more) and then it was removed. can it be submitted for community repo or should it be reintroduced in testing?
2025-10-01 05:26:24 <lotheac> you can leave a comment but you can also mention the MR here and a developer might take a look
2025-10-01 05:27:21 <lotheac> my armchair judgment would be that a bouncing email address for the maintainer is a pretty positive indication that maintainership might be up for grabs
2025-10-01 05:28:18 <lotheac> or were you talking about separate MRs?
2025-10-01 05:35:16 <ikke> lotheac: I recently learned there is one maintainer where the maintainer address bounces, but their gitlab profile has a reachable address
2025-10-01 05:35:24 <ikke> (at least one)
2025-10-01 05:39:41 <lotheac> 
ACTION rolls eyes

2025-10-01 05:39:51 <lotheac> i can only wonder why
2025-10-01 05:45:23 <psykose> good strategy tbh
2025-10-01 05:45:45 <lotheac> to what end?
2025-10-01 05:45:55 <abby> spam >/dev/null
2025-10-01 05:47:21 <lotheac> i've long abandoned the idea that email address obscurity would actually help with spam or remove need for other controls, but to each their own
2025-10-01 05:47:36 <lotheac> if the maintainer email address does not need to work, why would we even require it?
2025-10-01 05:54:30 <jvvv> well, i have to no opinion either way about the email thing, just looking for a way forward. here is the MR: !90745
2025-10-01 05:55:46 <jvvv> i don't think the aport is up for grabs, but would be happy to maintain if it ever gets orphaned...
2025-10-01 05:56:08 <lotheac> 3 days is a bit of a short time to wait, especially considering the maintainer did apparently respond to another mr 4 days ago :)
2025-10-01 05:56:29 <lotheac> so maybe it's that sort of situation where the address bounces but they still get gitlab mail
2025-10-01 05:57:10 <jvvv> both good points
2025-10-01 06:00:12 <lotheac> as for your hplip question, all new packages need to go to testing first and i would consider it a new package if it currently doesn't exist (even if it might have previously)
2025-10-01 06:02:39 <jvvv> ah, that is a fair way to look at it. that is how i will submit it, once i clean up / split up the patch
2025-10-01 06:02:55 <jvvv> thanks for your input
2025-10-01 06:20:26 <ncopa> I'd like to tag an edge release snapshot, but there are build errors
2025-10-01 06:20:29 <ncopa> error: version 'elfv2' in target triple 'powerpc64le-alpine-linux-muslelfv2' is invalid
2025-10-01 06:31:04 <ncopa> I also need tag stable releases
2025-10-01 07:12:49 <achill> we can temporarily disable the firefoxes for ppc64le
2025-10-01 07:13:13 <jvvv> for the firefox-esr build failure, i note that for the -r0 build rust/cargo is at 1.89.0 and for the -r1 build rust/cargo is at 1.90.0
2025-10-01 07:13:25 <achill> bringing them to upload community would be very good
2025-10-01 07:17:49 <achill> ncopa: just so let you know, I would merge !89408 before the builder bootstrap
2025-10-01 07:18:16 <achill> (the ci failure can be ignored)
2025-10-01 07:18:58 <ncopa> ok. will do that
2025-10-01 07:19:07 <ncopa> also need tag abuild release
2025-10-01 07:20:05 <ncopa> are you sure the CI failures can be ignored?
2025-10-01 07:20:10 <ncopa> rust fails to build on aarch64
2025-10-01 07:24:33 <achill> oh didn't saw that, taking a look
2025-10-01 07:25:38 <achill> oh it's just a oom
2025-10-01 07:26:47 <achill> the llvm-runtimes is because the new abuild's default.conf isn't sourced, because its just getting upgraded in the deps step
2025-10-01 08:59:06 <pabloyoyoista> achill I just upgrade to GNOME 49 and got my install locked again
2025-10-01 08:59:25 <pabloyoyoista> Do you have any pointers of something that might have happened lately?
2025-10-01 08:59:49 <achill> uhh interesting, not that i know of
2025-10-01 08:59:53 <pabloyoyoista> Might be network manager this time, but not sure
2025-10-01 08:59:59 <achill> i assume this is a full upgrade right
2025-10-01 09:00:19 <pabloyoyoista> Yes, it is
2025-10-01 09:08:44 <achill> so, i cant reproduce it on a fresh VM, not sure what the issue might be
2025-10-01 10:10:08 <pabloyoyoista> Alright, so gjs failed to upgrade...
2025-10-01 10:10:27 <pabloyoyoista> Guess mistery solved. Thanks for testing it out
2025-10-01 10:23:03 <Sertonix[m]> ncopa: for the ppc64le build failure there is a fix which makes it compile at least: https://github.com/rust-lang/cc-rs/issues/1581
2025-10-01 14:23:53 <qaqland> all work well here, I have completed my "merge-usr"
2025-10-01 14:55:59 <craftyguy[m]> nice!
2025-10-01 14:56:11 <f_> \o/
2025-10-01 15:17:13 <prabu> i'll appreciate if someone can review the MR !90460 and merge it, if found OK. thanks
2025-10-01 15:29:24 <ncopa> the /usr merge article is posted on https://alpinelinux.org/
2025-10-01 16:47:22 <f_> \o/
2025-10-01 16:47:26 <f_> congrats!
2025-10-01 16:55:21 <craftyguy[m]> the first question in the FAQ isn't a question, it's a statement :P
2025-10-01 17:02:02 <psykose> statements can be questions
2025-10-01 17:06:00 <lotheac> frequently asked (question|statement|expression|formulation) would probably not be as catchy
2025-10-01 17:06:25 <lotheac> and i suppose you'd have to modify the verb as well, blowing up the test matrix
2025-10-02 04:29:18 <ikke> seems like mesa needs to switch to llvm21
2025-10-02 04:32:37 <ikke> !90925
2025-10-02 06:10:06 <staceee> is it possible to run abuild with a higher nice level?
2025-10-02 06:10:20 <staceee> so that checks doesn't burn all io or cpu
2025-10-02 06:51:08 <ncopa> nice abuild ...
2025-10-02 06:51:11 <ncopa> should work
2025-10-02 07:45:56 <staceee> ah right, fair enough
2025-10-02 07:46:24 <staceee> I thought maybe a highler default level could be usefull
2025-10-02 10:36:29 <manospitsid> are there minirootfs builds with debug symbols for busybox?
2025-10-02 10:37:35 <ikke> No
2025-10-02 10:38:22 <manospitsid> is there an easy way to build with debug symbols?
2025-10-02 10:38:45 <ikke> manospitsid: add a $pkgname-dbg subpackage to the APKBUILD
2025-10-02 10:38:49 <ikke> (at the beginning)
2025-10-02 10:39:03 <ikke> Then you can install that subpackage to get the symbols
2025-10-02 10:39:34 <manospitsid> I want /bin/busybox to contain debug symbols
2025-10-02 10:39:46 <Sertonix[m]> Last time I tried adding debug symbols to busybox didn't work.
2025-10-02 10:40:11 <manospitsid> aw :( I am trying to debug a segfault in the init process, so I can't attach gdb to it and load dbg symbols from somewhere else
2025-10-02 10:40:59 <Sertonix[m]> To not split them you can set DEBUG=1 without a -dbg subpackage
2025-10-02 10:42:01 <Sertonix[m]> You could try to install gdb in the initramfs
2025-10-02 10:42:01 <manospitsid> hm I haven't built alpine before so that isn't immediately clear to me
2025-10-02 10:42:32 <manospitsid> Sertonix[m]: I'm loading minirootfs as a ramdisk
2025-10-02 10:42:56 <manospitsid> I don't have a functioning userspace, I'm debugging this through gdbstub 
2025-10-02 10:45:41 <manospitsid> For context: I am writing my own aarch64 emulator. I made a ramdisk .cpio of minirootfs to run as init process (launch /sbin/getty). Verified it works with QEMU, but with my emulator it traps and causes a sigsegv so I am trying to figure out where in /bin/busybox that happens
2025-10-02 10:45:58 <manospitsid> I have the location but I don't have the debug symbols
2025-10-02 11:46:00 <manospitsid> is there a dockerfile that can build minirootfs?
2025-10-02 11:50:27 <ikke> alpinelinux/build-base could
2025-10-02 11:50:54 <ikke> But you have to figure out how to invoke the scripts to get the image
2025-10-02 11:51:04 <ikke> the minirootfs I mean
2025-10-02 11:51:33 <manospitsid> hm
2025-10-02 11:51:35 <ikke> clone aports, scripts/mkimage.sh as a starting point
2025-10-02 11:53:12 <ikke> This is what the builders invoke: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build#L84
2025-10-02 12:22:36 <Sertonix[m]> manospitsid: Could you try this build: https://gitlab.alpinelinux.org/sertonix/aports/-/jobs/2036614/artifacts/file/packages/main/aarch64/busybox-1.37.0-r23.apk
2025-10-02 12:23:21 <Sertonix[m]> You can extract the apk file (with tar) and replace the busybox binary
2025-10-02 12:53:36 <j_v> for the DEBUG=1 method, wouldn't it also need 'options=!strip' also?
2025-10-02 12:54:04 <Sertonix[m]> abuild does that already
2025-10-02 12:54:16 <j_v> oh
2025-10-02 15:42:01 <craftyguy[m]> Sertonix anything else for !90693 ? mps said it's good to merge
2025-10-02 15:54:32 <ncopa> achill: do you have any opinion on curl sec fix? do you want upgrade to latest (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90899) or do you want to try backport the fixes (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90894)
2025-10-02 15:54:59 <ncopa> i'd like to include the fix in the upcoming release. curl is included in the extended image
2025-10-02 16:13:25 <achill> dont have a strong opinion. the latest version has api breakages (106a02411488e3f71b9f2085a4a857e4be27b9ea) but no other known regressions.
2025-10-02 16:14:13 <achill> it seems like backporting the patches works out, so i'll jsut merge that then
2025-10-02 16:15:55 <ncopa> good. thanks!
2025-10-02 16:18:06 <achill> thanks for reminding me again, im getting more and more overwhealmed by the email amount
2025-10-02 16:19:55 <ncopa> thats the price we pay. on my laptop it says I have 104876 unread emails
2025-10-02 16:20:41 <ncopa> let me know if I can help in any way
2025-10-02 16:21:30 <ncopa> I can try backport to 3.21-stable etc
2025-10-02 16:23:44 <achill> yeah that would be nice ig
2025-10-02 16:24:03 <achill> they are low severity tho, so no that urgent
2025-10-02 16:39:00 <invoked> i can recommend fdm for helping with the email. i use it heavily for sorting messages in maildir. would go insane without it.
2025-10-02 16:39:27 <invoked> guess it depends on your setup, though
2025-10-02 18:07:23 <caskd> i want to thank the people that have been involved into porting ukify and setting up all the stuff for alpine 
2025-10-02 18:07:43 <caskd> setting up secure boot has been surpsingly easy with all of the work already done
2025-10-02 18:07:45 <caskd> :)
2025-10-02 18:08:53 <caskd> not a recent event, i just had the chance to try it first today
2025-10-03 00:06:48 <Noisytoot1> why is ci so slow on riscv64 compared to other architectures?
2025-10-03 00:07:39 <Noisytoot1> over 21 minutes to complete a build that was done on all other architectures in <3 minutes
2025-10-03 00:08:10 <pj> because riscv64 is slow
2025-10-03 05:57:23 <ncopa> because it runs on real hardware. it should be okish when the build job can be parallelized. but painfully slow when it cant
2025-10-03 05:57:34 <ncopa> the builder has 64 cpu cores, but each core is slow
2025-10-03 06:17:03 <ncopa> I dont know whats wrong with build-3-21-riscv64. now cc1 appears to hang again in zfs configure script
2025-10-03 06:17:07 <ncopa> maybe its a gcc thing?
2025-10-03 06:27:46 <Biswa96[m]> how long should I wait before asking further reviews if there is no reply in a MR?
2025-10-03 06:45:11 <ncopa> which MR?
2025-10-03 06:50:43 <Biswa96[m]> my question was in general way. for example, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90314
2025-10-03 07:42:14 <ncopa> once the maintainer has given LGTM/thumbs-up and the CI is green you can ping us immediately
2025-10-03 07:42:39 <ncopa> no need to wait weeks
2025-10-03 07:55:21 <ncopa> i wonder if someone could follow up the ppc64le stuff?   cargo:warning=clang-20: error: version 'elfv2' in target triple 'powerpc64le-alpine-linux-muslelfv2' is invalid
2025-10-03 07:55:34 <ncopa> im gonna disable ppc64le where it breaks for now
2025-10-03 07:56:32 <ncopa> its this one: https://github.com/rust-lang/cc-rs/issues/1581
2025-10-03 08:04:31 <ncopa> I think we should consider bump gcc 14.3.0 in 3.22-stable and 3.21-stable
2025-10-03 08:29:00 <achill> i dont like upgrading gcc on stable version, it can cause weird kind of incompabilities
2025-10-03 08:29:05 <achill> like with kernel modules and stuff
2025-10-03 08:29:17 <ncopa> yeah, thats the problem. how can we test that?
2025-10-03 08:29:29 <ncopa> but we have an issue with riscv64
2025-10-03 08:29:47 <achill> yeah..
2025-10-03 08:29:54 <ncopa> https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=14.3
2025-10-03 08:30:12 <ncopa> could be this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
2025-10-03 08:30:50 <ncopa> how do we test if it breaks kernel modules and static libs?
2025-10-03 08:32:25 <ncopa> yeah
2025-10-03 08:32:30 <ncopa> it breaks kernel modules
2025-10-03 08:32:40 <achill> urgh not great
2025-10-03 08:33:10 <ncopa> due to gcc plugins
2025-10-03 08:33:22 <ncopa> static libs appears to work
2025-10-03 08:33:22 <achill> yeah likely this one: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17308
2025-10-03 08:34:49 <ncopa> yup. thats the issue. disapointing it happens with 14.2 -> 14.3
2025-10-03 08:35:05 <ncopa> we could consider drop use gcc plugins in kernel
2025-10-03 08:35:29 <ncopa> i dont remember what we use those for
2025-10-03 08:35:45 <achill> me neither 🤷
2025-10-03 08:37:43 <ncopa> we have 4 kernels that may need to be rebuilt: linux-edge, linux-openpax, linux-lts, linunx-rpi
2025-10-03 08:38:54 <achill> all their modules, but that sounds doable
2025-10-03 08:40:19 <ncopa> but I think we should prio get the stable releases out and I have limited time today and this weekend
2025-10-03 08:55:47 <achill> yeah i guess
2025-10-03 08:56:00 <achill> generally speaking i also think this goes against the toolchain freeze
2025-10-03 09:15:09 <ncopa> we could also try backport specific patches
2025-10-03 09:49:49 <ncopa> need to go. will have to finish the release on monday :-/
2025-10-03 09:53:39 <ikke> Ok, we need to keep the builders green 
2025-10-03 13:31:42 <caskd> Question regarding the /usr-merge, for things referred via a absolute path (and where PATH doesn't apply) should they be moved and symlinked or instead wait?
2025-10-03 13:32:02 <caskd> i'm asking here mainly in regards to /sbin/init
2025-10-03 14:04:29 <skarnet> the merge-usr utility should do everything for you (it will be moved and symlinked)
2025-10-03 14:11:31 <caskd> right, but for packaging i want to be proactive and provide it while still providing fallbacks
2025-10-03 14:12:35 <caskd> i've evaluated the options right now and during the transition period the best thing to do is change the initrd to exec /usr/sbin/init
2025-10-03 14:13:29 <caskd> or will apk stop extracting things to /sbin on a usr-merged system?
2025-10-03 14:13:51 <caskd> because that would also make it quite easy
2025-10-03 14:19:01 <skarnet> on a usr-merged system, /sbin is a link to usr/sbin, so everything will work transparently - even if you extract to /sbin it will end up in /usr/sbin
2025-10-03 14:19:59 <caskd> well, then the fallback where this hasn't happened yet still needs a symlink if the package provides them in /usr/sbin
2025-10-03 14:20:22 <skarnet> yes
2025-10-03 14:21:09 <skarnet> but if you do nothing, everything will keep working transparently
2025-10-03 14:21:24 <skarnet> the goal is not for every script to be patched to use #!/usr/bin/sh
2025-10-03 14:21:37 <caskd> so the good question here is, if i provide /usr/sbin/init as a binary and provide /sbin/init as a symlink, is there a possibility of a error or race condition which may cause a overwrite?
2025-10-03 14:22:03 <caskd> since they essentially need to be extracted to the same place in a usr-merged system
2025-10-03 14:22:22 <skarnet> the merge-usr script takes that into account, Pablo and I tested it for execlineb
2025-10-03 14:23:06 <caskd> oh okay
2025-10-03 14:23:13 <skarnet> if you install a link in /sbin at apk add time, you need to check yourself that it won't overwrite your own binary
2025-10-03 14:24:00 <skarnet> but really, especially for init, you shouldn't care about any of this
2025-10-03 14:24:11 <skarnet> the kernel still invokes /sbin/init
2025-10-03 14:24:17 <skarnet> the /sbin link isn't going away
2025-10-03 14:24:36 <skarnet> you can keep using /sbin/init probably forever
2025-10-03 14:25:01 <skarnet> AIUI, the point of merge-usr isn't about deprecating *access*, but *storage* outside /usr
2025-10-03 14:25:10 <caskd> yeah, i get that much
2025-10-03 14:25:54 <caskd> this is mostly about providing compatibility on non-merged systems for the transition period while packaging directly under /usr
2025-10-03 14:26:22 <caskd> after the merge i have no concerns
2025-10-03 14:27:29 <skarnet> my pov is that if you're packaging something providing an init, you shouldn't even bother packaging directly under /usr
2025-10-03 14:28:00 <skarnet> but if you're set on that, you can look at the execline APKBUILD because I had the exact same concerns
2025-10-03 14:28:11 <skarnet> and the stuff I did apparently worked :)
2025-10-03 14:28:13 <caskd> well, then i assume i should ignore the now-warning-future-error /usr message
2025-10-03 14:28:21 <caskd> from abuild
2025-10-03 14:29:03 <caskd> oh thats what i was considering
2025-10-03 14:29:03 <skarnet> bleh
2025-10-03 14:29:07 <caskd> you're forcing it though
2025-10-03 14:29:19 <caskd> i had concerns of race with busybox init
2025-10-03 14:29:45 <caskd> i think i will follow your approach
2025-10-03 14:29:47 <caskd> seems nice
2025-10-03 15:08:28 <caskd> thanks skarnet, it works nicely :D
2025-10-03 15:14:43 <skarnet> great :D
2025-10-03 19:30:44 <Sertonix[m]> The abuild warning is not too important in this case
2025-10-04 10:57:36 <WhyNotHugo> I started splitting udev rules into $pkgname-udev subpackages for several packages, but I noticed there was a great deal of reptitition: the udev() function in each one was identical.
2025-10-04 10:57:49 <WhyNotHugo> I made a quick change to abuild which seems to handle this better: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/443
2025-10-04 11:06:54 <iggy> What is involved in a "security review" ala https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87750 I googled it, but didn't find anything pertinent
2025-10-04 12:04:03 <pj> basically audit by alpine security officer
2025-10-04 13:56:03 <Saijin_Naib[m]> @WhyNotHugo that is amazing! 
2025-10-04 13:56:03 <Saijin_Naib[m]> Will it warn/inform that they are found if not split out like the other splits do for lang/doc? 
2025-10-04 13:56:20 <WhyNotHugo> It will, exactly like those two :)
2025-10-04 14:33:40 <Saijin_Naib[m]> Siiick
2025-10-04 14:46:08 <maribu> Hmm, in !91046 the CI job on s390x fails with a timeout on downloading the source (consistently, 4/4 tries). The URL that fails to download can be downloaded just fine on my machine (did so manually with `wget` copy-pasting the exact URL, just in cast the files is cached in /var/cache/distfiles). Could someone be blocking the CI worker?
2025-10-04 15:44:03 <WhyNotHugo> !88742 is ready to merge
2025-10-04 18:35:05 <DylanVanAssche> I have a server running here which has the package certbot-dns-hetzner installed. This package was available in edge for some time, but it is suddenly gone. I checked the git log but there's no trace of it seems?
2025-10-04 18:55:46 <Sheila> DylanVanAssche: certbot-dns-hetzner has never been packaged in Alpine.
2025-10-04 18:56:08 <ikke> Yeah, my conclusion as well
2025-10-04 19:27:08 <DylanVanAssche> That's really weird, I found it in pkgs.alpinelinux.org like 1-2 weeks agos and installed it from the repos with apk :) will try to find out where apk got it though...
2025-10-04 19:31:16 <f_> yeah no trace of it https://git.alpinelinux.org/aports/log/?qt=grep&q=certbot-dns-hetzner it seems
2025-10-04 19:35:07 <ikke> f_: it could have been a subpackage 
2025-10-04 19:35:29 <f_> Looking for just 'hetzner' also yields nothing
2025-10-04 19:38:02 <f_> and looking at the certbot-dns's history shows that it never existed
2025-10-04 19:38:14 <f_> Even back when it was in testing
2025-10-04 20:57:01 <hjaekel> maribu Can you also look at !87119 please? 
2025-10-05 05:15:13 <maribu> @hjaekel: The CI errors with arrow I also had in !91085 - it took a rebuild of apache-arrow against abseil-cpp to fix.
2025-10-05 05:16:48 <maribu> Other than the CI failing due to an unrelated issue, it looks good to me.
2025-10-05 06:54:05 <DylanVanAssche> [@_oftc_ikke:matrix.org](https://matrix.to/#/@_oftc_ikke:matrix.org) [@_oftc_f_:matrix.org](https://matrix.to/#/@_oftc_f_:matrix.org) it seems I prepared upstreaming it as some point and forgot about it, sorry for the confusing! Will upstream the pkg
2025-10-05 07:45:29 <caskd> ncopa: could you have a look at https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/177 ? It's quite a important feature for enabling proper secure boot support. :D
2025-10-05 08:55:34 <quinq> Hi
2025-10-05 08:55:44 <quinq> elagost, I can see that webkitgtk upgrade failed
2025-10-05 08:56:28 <quinq> Any reason you bumped directly to the next untested major instead of the stable current?
2025-10-05 08:57:34 <quinq> And if it looks like it needs more work, maybe first upgrade to the next stable instead in the meantime
2025-10-05 09:30:35 <fabricionaweb> hi, I need review on these two new aports !90425 and !90398
2025-10-05 11:27:15 <elagost> quinq: I was encouraged to go that route instead of the current version in aports; I probably won't be able to devote much time to it so I'm trying the current version again. 
2025-10-05 11:28:22 <quinq> I see
2025-10-05 11:28:30 <quinq> Thank you for your explanations and your efforts!
2025-10-05 11:30:33 <elagost> yeah latest version would be better, but I just don't think I have time for that in the next few weeks.
2025-10-05 11:31:06 <quinq> It's not exclusive
2025-10-05 11:31:17 <quinq> But it usually involves more porting efforts (sadly)
2025-10-05 11:31:57 <quinq> So yeah, safer starting with the least risky, then continuing on the more effort-prone, when resources are available :) (imo)
2025-10-05 11:51:45 <maribu> heads up texlive users: The version scheme of the packages has been changed from `<date>.<svnrel>` to the version scheme used by upstream. Specifically, 20240210.69778 is the old version, 2025.2 is the new. Running `apk upgrade --available` will get you the newer package (that has the lower version number).
2025-10-05 11:53:28 <ikke> maribu: can you add that to https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.23.0?
2025-10-05 12:19:41 <Ermine> Wasn't there a field for pkg epoch in apkbuild?
2025-10-05 12:21:34 <Sertonix[m]> That was in arch linux as far as I know
2025-10-05 12:22:36 <ikke> yes, no epoch in apk-tools so far
2025-10-05 15:53:44 <quinq> elagost, could see this: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/webkitgtk4/patches/patch-Source_JavaScriptCore_llint_LowLevelInterpreter_asm?rev=1.3&content-type=text/x-cvsweb-markup
2025-10-05 15:53:58 <quinq> Maybe it can help
2025-10-05 16:30:19 <tcc> Does anyone have a good recommendation of sandboxing/chroot environment for package creation?
2025-10-05 16:31:27 <elagost> quinq: thanks! I'll add that.
2025-10-05 16:34:28 <elagost> lol pushed it to my coreboot-tools branch instead, forgot to checkout the other one :(
2025-10-05 16:39:13 <quinq> Happens :>
2025-10-05 19:59:50 <quinq> Hi
2025-10-05 20:00:01 <quinq> How do I retreive objects (packages) from a gitlab build?
2025-10-05 20:00:33 <quinq> I downloaded the “Job artifacts”, but all I get is a zip file, with only logs in it
2025-10-05 20:09:57 <Biswa96[m]> quinq: extract the .apk file from that .zip file
2025-10-05 20:14:50 <quinq> As I just said, there's none
2025-10-05 20:16:00 <Biswa96[m]> could you provide the link of that ci build?
2025-10-05 20:16:24 <Biswa96[m]> did the build succeed?
2025-10-05 20:16:58 <quinq> Sure: https://gitlab.alpinelinux.org/adamthiede/aports/-/jobs/2040797
2025-10-05 20:17:27 <quinq> Yeah, there's a big green “✓ Passed” web button
2025-10-05 20:25:29 <Biswa96[m]> sadly, the log has - "Artifact size 357617664 larger than max (300000000), skipping uploading them"
2025-10-05 20:28:20 <Biswa96[m]> you can create two merge requests for each package upgrade
2025-10-05 20:29:38 <quinq> More than 300MB? oO
2025-10-05 20:30:03 <quinq> Ohhh ok, it builds -dbg packages too
2025-10-05 20:30:29 <quinq> Thanks :)
2025-10-06 07:04:43 <PaoloBarbolini[m]> https://youtu.be/b2F-DItXtZs
2025-10-06 07:05:34 <PaoloBarbolini[m]> Sorry wrong group 😅. I've deleted the message on Matrix
2025-10-06 07:26:17 <quinq> Too late
2025-10-06 10:27:54 <deck> Hi there noticed that the sdl12-compat-static package doesn't contain a libSDL.a file for static linking: https://pkgs.alpinelinux.org/contents?name=sdl12-compat-static&repo=community&branch=v3.22&arch=x86_64
2025-10-06 10:28:38 <deck> is this by design? Checked another distro and it's there: https://packages.fedoraproject.org/pkgs/sdl12-compat/sdl12-compat-static/fedora-42.html#files
2025-10-06 10:29:21 <deck> I hope this is the correct channel for this sort of thing
2025-10-06 11:38:00 <ikke> ncopa: I think we should start soon with the python 3.12
2025-10-06 11:38:16 <ikke> 3.13 upgrade
2025-10-06 12:00:48 <andypost[m]> Maybe 3.14?
2025-10-06 12:38:37 <ikke> Do we have enough time to deal with all the issues
2025-10-06 12:38:40 <ikke> ?
2025-10-06 12:38:59 <ncopa> i dont think we will be able to get python 3.13 before alpine 3.23
2025-10-06 12:39:19 <ncopa> need to get abuild release out asap, and then will start with the 3.23 builders
2025-10-06 12:41:23 <dne> python 3.12 will have security support until 2028-10
2025-10-06 12:41:51 <ikke> Alpine 3.23 until 2027-11
2025-10-06 12:43:51 <achill> I will investigate 3.13/3.14 support for 3.24 maybe even with alternative installations
2025-10-06 12:44:01 <achill> <deck> Hi there noticed that the sdl12-compat-static package doesn't contain a libSDL.a file for static linking: https://pkgs.alpinelinux.org/contents?name=sdl12-compat-static&repo=community&branch=v3.22&arch=x86_64
2025-10-06 12:44:01 <achill> Mind opening a issue?
2025-10-06 12:47:31 <ikke> achill: what do you mean with alternative installation methods?
2025-10-06 12:48:10 <achill> !85770
2025-10-06 13:14:01 <deck> @achill will do. Might take a while since it's my first report.
2025-10-06 13:14:15 <achill> No worries
2025-10-06 14:53:57 <ncopa> Sertonix[m]: do you think we should revert https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/443 for now?
2025-10-06 14:54:54 <Sertonix[m]> It should be fine to keep the commit and fix it later
2025-10-06 14:54:58 <WhyNotHugo> Flutter sends its "telemetry" back upstream for any usages, which is left enabled by default on the Alpine package. As a result, any execution of `abuild rootbld` for flutter packages sends out a usage notificatio to Google. Shouldn't this behaviour be disabled by default?
2025-10-06 14:56:05 <WhyNotHugo> In fact, the message implies that by using flutter one is agreeing to Google's Privacy Policy for this tracking.
2025-10-06 15:04:54 <ikke> WhyNotHugo: yes, it should be disabled
2025-10-06 15:10:40 <Biswa96[m]> I can not login in alpine linux gitlab using github account. Here is the error message: Could not authenticate you from GitHub because "Failed to open tcp connection to github.com:443 (getaddrinfo: try again)". 
2025-10-06 15:14:43 <ikke> Biswa96[m]: let me take a look
2025-10-06 16:01:52 <Biswa96[m]> it's working now. I can log in alpine linux gitlab.
2025-10-06 16:39:20 <Noisytoot1> isn't network access restricted in abuild rootbld?
2025-10-06 16:43:00 <PureTryOut> By default, yes. You can add net to $options to get network access, but it's recommended to try and prevent the need for that
2025-10-06 16:43:53 <PureTryOut> And in regards to Flutter building with abuild rootbld, it is indeed setting net due to getting packages from pub.dev
2025-10-06 17:27:29 <craftyguy[m]> could someone please take a look at / merge !90183 ? thanks :)
2025-10-06 17:32:45 <PureTryOut> That autogen.sh taking over configure and being in prepare is weird... But I see it has been discussed already, so ok 🤷
2025-10-06 17:36:47 <craftyguy[m]> yeah 🤷
2025-10-06 17:36:53 <craftyguy[m]> thanks for merging :)
2025-10-06 19:19:08 <WhyNotHugo> package flutter is older on aarch64 than on x86_64. are builds delayed? where are the logs for the builders?
2025-10-06 19:27:11 <mio> WhyNotHugo: networking issue on arm builders https://fosstodon.org/@alpinelinux/115326841150952703
2025-10-06 19:27:48 <WhyNotHugo> thanks
2025-10-06 21:41:53 <jvvv> could someone with appropriate permissions and available time please assign !91145 to @prspkt ?
2025-10-06 22:12:29 <mio> jvvv: done
2025-10-06 22:18:43 <jvvv> mio: thanks!
2025-10-06 22:19:30 <mio> you're welcome
2025-10-07 05:15:32 <ikke> WhyNotHugo: himitsu-secret-service does not have a provider-priority
2025-10-07 05:15:36 <ikke> that could mess things up
2025-10-07 05:15:42 <ikke> apk query --format json --fields name,provider-priority --match provides dbus:org.freedesktop.Secrets | jq 'sort_by(.["provider-priority"])' 
2025-10-07 05:17:56 <ikke> (all virtual provides should have a provider_priority)
2025-10-07 09:44:47 <WhyNotHugo> ikke: I wasn’t aware of this. abuild should warn about it?
2025-10-07 11:57:42 <WhyNotHugo> I'm thinking of showing a warning when [ -n "$provider" ] && [ -z "$provider_priority" ]. But I think it might mess up with non-virtual provides, right?
2025-10-07 12:09:52 <ikke> Yes
2025-10-07 12:18:37 <staceee> is there known regressions with apk install_if behavior?
2025-10-07 12:40:44 <staceee> ah right, I had something conflicting, so the install_if just swallow it
2025-10-07 13:03:33 <Sertonix[m]> [@_oftc_WhyNotHugo:matrix.org](https://matrix.to/#/@_oftc_WhyNotHugo:matrix.org) We could only do that after traced providers and warnings at that phase are very ineffective. It will likely also have many false positives due to provider_priority being preserved for subpackages by default. I do not want to encourage overwriting things like doc() just to silence a warning.
2025-10-07 13:08:23 <lotheac> achill: re: python, i'm guessing you know but making sure: i have 3.14.0 build passing at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90482
2025-10-07 13:09:26 <lotheac> well, i assume it will pass given that 3.14.0rc3 passed earlier :p
2025-10-07 14:14:42 <ncopa> Sertonix[m]: I'd like to tag a release candidate for abuild, but It may be good to get the apk3 index in first?
2025-10-07 14:14:42 <ncopa> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/425
2025-10-07 14:23:34 <Sertonix[m]> Would be good, but I wouldn't consider the index supported in the stable release (just available for testing)
2025-10-07 14:26:42 <Sertonix[m]> ncopa: Regarding the test failure, I think that the --keys-dir change in https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/427 would fix it.
2025-10-07 14:47:12 <dne> no linux-lts backport to 3.22 (only linux-rpi)?
2025-10-07 14:48:00 <dne> I mean 6.12.51
2025-10-07 15:11:05 <ncopa> I thought I pushed it for 3.22-stable
2025-10-07 15:12:09 <ncopa> but i didnt
2025-10-07 15:12:31 <ncopa> dne: thanks for the ping
2025-10-07 15:12:37 <dne> 👍
2025-10-07 19:30:18 <dne> looks like build-3-22-riscv64 is having trouble unpacking the kernel tarball
2025-10-07 20:48:14 <WhyNotHugo> Sertonix[m]: is there any way to distinguish virtual providers from non-virtual?
2025-10-07 22:02:31 <Sertonix[m]> virtual providers don't have a version and vice versa
2025-10-08 09:26:22 <ncopa> i'm tagging stable releases now
2025-10-08 10:06:06 <ncopa> is this good enough to publish? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/111
2025-10-08 10:31:44 <WhyNotHugo> Sertonix[m]: so we can warn for packages with a versionless provider and not provider_priority
2025-10-08 10:56:44 <ikke> WhyNotHugo: you have to check subpkgs as well
2025-10-08 10:57:44 <ikke> https://gitlab.alpinelinux.org/kdaudt/apkgquery/#provides-virtual-package-without-setting-a-provider_priority
2025-10-08 10:59:52 <dne> ncopa: LGTM
2025-10-08 11:11:56 <ncopa> dne: thanks!
2025-10-08 11:30:23 <ncopa> I'll tag edge release snapshot whenever the servers are idel
2025-10-08 11:30:27 <ncopa> *idle
2025-10-08 11:44:31 <WhyNotHugo> ncopa: does `abuild rootbld` work for you? With abuild-3.15.0-r5 it fails to symlink sources for me
2025-10-08 11:45:26 <WhyNotHugo> Ah, fixed in 3.15.0-r6, that was fast :P
2025-10-08 12:59:08 <Sertonix[m]> [@_oftc_WhyNotHugo:matrix.org](https://matrix.to/#/@_oftc_WhyNotHugo:matrix.org) There are cases where not autoselected providers are intentional. These aren't broken, we just need a good APKBUILD(5) and people reading it.
2025-10-08 13:41:55 <raspbeguy> Hello, could someone have a look at !87884 !90941 !91118 !91143 please?
2025-10-08 14:14:19 <staceee> trying to recipe something but zstd-dev seems to not contain zstdConfig.cmake, 
2025-10-08 14:19:20 <ncopa> ikke: can you help posting a toot about the release? https://alpinelinux.org/posts/Alpine-3.19.9-3.20.8-3.21.5-3.22.2-released.html
2025-10-08 14:19:42 <ikke> Ack 
2025-10-08 14:21:24 <ncopa> thanks!
2025-10-08 14:22:31 <ikke> https://fosstodon.org/@alpinelinux/115338991042820066
2025-10-08 14:22:39 <f_> \o/
2025-10-08 14:36:02 <lanodan> Release reminds me, is there a reason extended iso is only x86_{32,64}? Ended up having to build it for aarch64 some days ago (mostly for zfs-lts but network dependency of standard iso was a bit annoying, had to use an USB-ethernet dongle).
2025-10-08 15:40:17 <elagost> did a recent update to abuild rootbld break it? On 3.22 I can no longer `abuild rootbld`, keeps saying 'ln: <source tarball>: File exists'.
2025-10-08 15:58:48 <ikke> elagost: WhyNotHugo reported it in #alpine-linux as well
2025-10-08 15:59:12 <WhyNotHugo> elagost: it was fixed for me on 3.15.0-r6
2025-10-08 15:59:49 <elagost> Thanks WhyNotHugo, I will test that, are you using 3.22 or edge?
2025-10-08 15:59:54 <WhyNotHugo> edge
2025-10-08 18:12:53 <ikke> Sertonix[m]: can I apply https://tpaste.us/JNB4 for syncthing?
2025-10-08 19:02:19 <durrendal> ncopa: thanks for bumping su-exec, appreciate it!
2025-10-08 19:45:59 <Sertonix[m]> ikke: Yes, thanks for the patch!
2025-10-08 19:49:45 <ikke> soo.. many.. test.. failures..
2025-10-08 19:49:55 <ikke> Just for a rebuild
2025-10-09 09:57:11 <ncopa> so maybe we should backport 1b9cda0483b8c59c3bdabe2de79fee698f0a2c0f to 3.22-stable
2025-10-09 12:22:06 <Sertonix[m]> Should be ok to do that
2025-10-09 18:30:40 <jvvv> !90745 is in kind of weird state. what can be done?
2025-10-09 18:32:24 <zbergus_> First time using IRC sorry if im not doing this properly but am wondering if there is a plan to release a new version of alpine given the criticality of  CVE-2025-49794 CWE-825 (fix was done here https://gitlab.alpinelinux.org/alpine/aports/-/commit/0d2c97255117ab55ddbb8b94be597615be984436) and not included in 3.22.2
2025-10-09 18:35:29 <ikke> zbergus_: Welcome! One thing should avoid is cross-posting (post the same question in multiple channels at the same time)
2025-10-09 18:37:18 <zbergus_> sorry thanks, continuing in orher caht
2025-10-09 21:51:50 <Noisytoot1> is there any particular reason why alpine doesn't have a musl-mimalloc package (like chimera has musl and musl-mallocng), other than that nobody's made one? (if I submitted a PR adding musl-mimalloc would it be likely to be accepted?)
2025-10-09 21:53:38 <Noisytoot1> the reason why I want this rather than just preloading mimalloc is that preloading it breaks audio/video playing in firefox, so I can't do that globally
2025-10-10 09:06:28 <rhizoome> Noisytoot1: I experimented with musl and mimalloc. I don't think mimalloc is going to be the default in alpine and it breaks the browsers if you just switch in a musl version with mimalloc. So there is no point in a package.
2025-10-10 09:10:18 <rhizoome> It actually breaks even more, but the browsers are the obvious reason, that this is not feasable.
2025-10-10 09:35:47 <rhizoome> Of course that is just what I learned.
2025-10-10 13:20:17 <caskd> anyone has any feedback on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76072 ?
2025-10-10 13:20:34 <caskd> been stale for a while and i'm not sure why
2025-10-10 13:20:58 <caskd> that also includes the dependent mr https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76073
2025-10-10 13:27:26 <Noisytoot1> Why does mimalloc break browsers and why aren't they broken on chimera? (or are they?)
2025-10-10 13:42:02 <rhizoome> Noisytoot1: I don't know. There are so many moving parts involed, just look at how many patches chromium has: https://github.com/chimera-linux/cports/tree/master/main/chromium/patches.
2025-10-10 18:51:15 <ikke> gitlab will be restarted in 10 minutes (19:00 UTC)
2025-10-10 18:52:09 <f_> thanks ikke
2025-10-10 19:06:04 <ikke> gitlab is back
2025-10-10 22:11:50 <Ariadne> Noisytoot1: it is on my list of things to look into.
2025-10-10 22:12:14 <Ariadne> but i would rather improve mallocng 
2025-10-11 14:39:51 <haesbaert> can I get some feedback in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87941 - trying to get this in for some time
2025-10-11 14:48:58 <Habbie> haesbaert, it occurs to me (but i don't know much about alpine policy) that you mention privileges (with a typo) are required, but the binaries go into bin, not sbin
2025-10-11 14:49:12 <Habbie> also, does it really only work on those two archs?
2025-10-11 14:49:36 <Habbie> and i suspect you don't need Contributor: if you already list Maintainer:
2025-10-11 14:57:30 <haesbaert> oh thanks for the typo, I'll fix it. It really only works on those two arches, I only have bpf probes for those two arches for now. Why should it be sbin? It's not really a system tool (though I'm not sure the distinction holds these days). Regardin Contributor vs Maintainer, on my previous ports that were merged, it has both so, dunno what's the expected one.
2025-10-11 14:58:01 <Habbie> i believe some distros expect 'root only' tools in sbin, but i have no clue what alpine policy is on that
2025-10-11 14:58:16 <Habbie> for contributor/maintainer, i don't know either. Just telling you what I'm noticing
2025-10-11 14:58:16 <ikke> There's no policy for that
2025-10-11 14:58:43 <pj> those whitespaces there are really unnecessary
2025-10-11 14:59:49 <haesbaert> so should I break line without aligning?
2025-10-11 15:00:04 <haesbaert> I'm assuming you mean the make call
2025-10-11 15:03:57 <haesbaert> oh it's in already \o/
2025-10-11 15:05:25 <haesbaert> ikke: many thanks!
2025-10-11 21:45:49 <Ariadne> heads up: i am updating musl to a git snapshot since there is still no release and there are a lot of fixes i would like to have in 3.23 release
2025-10-11 21:46:22 <Ariadne> i have been running this snapshot for a few weeks on my machines and it has been fine :)
2025-10-11 22:19:15 <Ariadne> Noisytoot1, rhizoome: having dug further into mimalloc, i do not believe it is an appropriate GPA for alpine.  it may be worth using as default allocator in scenarios where the programs are known to be memory safe (e.g. Rust ones), but the main performance trick it has is to defer free() operations until later
2025-10-11 22:22:33 <Ariadne> this is not acceptable for a system-wide GPA in alpine, we want to trap memory safety violations as soon as we become aware of them
2025-10-11 22:23:33 <Ariadne> this is why the toolchain instruments binaries with fortify by default, etc
2025-10-11 22:24:40 <Ariadne> more thought is needed, but make mimalloc the system-wide GPA is not a good choice for alpine
2025-10-11 23:21:07 <omni> Ariadne: I wonder if the musl upgrade broke s390x somehow, I see "Segmentation fault (core dumped)" on `cargo fetch` in CI
2025-10-11 23:23:22 <omni> also the docker upgrade
2025-10-11 23:23:24 <omni> cc1: internal compiler error: Segmentation fault
2025-10-12 00:04:15 <mio> limine failed as well
2025-10-12 00:04:26 <mio> passed in ci 4h ago
2025-10-12 00:07:46 <mio> "configure: error: C compiler cannot create executables"
2025-10-12 00:40:45 <Saijin_Naib[m]> @Ariadne is there room for musl malloc to approach other malloc performance, especially in caching-heavy workloads? 
2025-10-12 00:41:44 <Saijin_Naib[m]> Is work planned to speed it up? If so, is there a budget/pool if orgs want to contribute if they have a need for Alpine to be Alpine, but with a lower performance penalty in mem operations?
2025-10-12 00:44:11 <Ariadne> omni: not sure, will power on my s390x machine and look into it
2025-10-12 00:45:43 <Saijin_Naib[m]> Not sure if you remember, but same thing I was looking to contract you for last year, as we are making (slow) progress
2025-10-12 00:46:41 <Ariadne> this question is complex.  what mem operations?  what language?
2025-10-12 00:47:49 <Saijin_Naib[m]> Right now, seeing a roughly 10% performance penalty in redis 8.0 alpine vs debian docker base
2025-10-12 00:48:07 <Saijin_Naib[m]> Caching mixed data in our photogrammetry pipeline
2025-10-12 00:49:09 <Saijin_Naib[m]> We use a mix of C++, python, js, etc. But most intensive operations should be C++
2025-10-12 00:51:52 <Ariadne> for the general-purpose allocator, there is probably some things we can do.  but trapping memory safety violations at the time they happen requires synchronization in multithread case.
2025-10-12 00:52:54 <Ariadne> for some applications, it may be better to build them against mimalloc
2025-10-12 00:54:03 <Ariadne> we are already investigating this
2025-10-12 00:56:45 <Ariadne> on the musl side, dalias has some ideas about improving the locking which should help
2025-10-12 00:57:41 <Ariadne> the pattern that is most pessimistic is MT scatter-gather operations, e.g. where you spawn a lot of threads to process data in parallel
2025-10-12 01:02:33 <Saijin_Naib[m]> Oof, parallel threads is something we do... hmm, but glad to hear there are spaces for improvement
2025-10-12 01:03:13 <Ariadne> there are some things you might be able to change to close the performance gap
2025-10-12 01:03:38 <Ariadne> it depends on how you architected it, but it would generally improve performance
2025-10-12 01:04:17 <Ariadne> for example, if you load the data before processing it, and then release the memory after rejoining the threads
2025-10-12 01:09:05 <Ariadne> omni: musl 1.2.5 rebuilt with GCC 15 causes segfault too on s390x.  i think it’s a clobbering issue
2025-10-12 01:52:19 <omni> ok, so good that it's caught now then
2025-10-12 02:38:41 <qaqland> !88861 is ready :)
2025-10-12 02:41:04 <Ariadne> seems to be binaries with TLS
2025-10-12 02:49:08 <Noisytoot1> Ariadne: why is malloc-ng so slow compared to mimalloc and glibc's malloc for compiling C programs with GCC? that's singlethreaded
2025-10-12 02:55:33 <abby> because it has design goals other than speed
2025-10-12 02:58:11 <Ariadne> Noisytoot1: because those mallocs have more aggressive preallocation most likely
2025-10-12 02:59:00 <Ariadne> we should make malloc behavior tunable 
2025-10-12 03:01:50 <Ariadne> but also deferring free can help with perf in single threaded case too
2025-10-12 03:02:13 <Ariadne> our goal is not strictly perf though
2025-10-12 03:03:31 <Noisytoot1> does glibc's malloc defer free?
2025-10-12 03:17:00 <Ariadne> no, but mimalloc does
2025-10-12 03:17:14 <Ariadne> glibc mostly justp reallocates a lot
2025-10-12 03:17:47 <Ariadne> you could get the same level of performance out of mallocng if you tuned it to aggressively preallocate too
2025-10-12 03:18:37 <Ariadne> hence why making it tunable would be good
2025-10-12 05:23:18 <iggy> would be nice if other devs saw the malloc situation more sanely (i.e. packages pick their best suited malloc) Saijin_Naib[m] related !64686
2025-10-12 06:27:15 <Ariadne> i should be able to fix s390x clobbering issue in the morning
2025-10-12 06:36:48 <Maxci[m]> I got help from the legit and trusted hacker
2025-10-12 06:36:48 <Maxci[m]> Unlocking of iCloud, bypass and tracking of location he's tested and trustworthy person, contact him for your hacking service .
2025-10-12 06:36:48 <Maxci[m]>  https://t.me/CyberSecurityExpertsHQ2  ON telegram he's very good in hacking work and recovery of all social media, Facebook Instagram Twitter WhatsApp Snapchat etc and recovery of lost files on Microsoft, PayPal bitcoin cash app 
2025-10-12 07:10:38 <maribu> Whoopsie! A segfault in the CI when applying a patch from abuild on s390x: https://gitlab.alpinelinux.org/maribu/aports/-/jobs/2048942#L276
2025-10-12 07:16:43 <maribu> That segfault even is reproducible: 3 out of 3 runs segfaulted when applying the patch, all other arches build fine.
2025-10-12 07:20:29 <sam_> i think it's related to the above discussion (clobber)
2025-10-12 07:28:02 <Ariadne> is caused by https://git.musl-libc.org/cgit/musl/commit/src/thread/s390x?id=6af4f25b899e89e4b91f8c197ae5a6ce04bcce7b
2025-10-12 07:29:12 <Ariadne> lg %r5, 8(%r0) becomes lg %r5, 8
2025-10-12 07:46:54 <fossdd_> Ariadne: any reason why you didnt ask dalias to tag a release?
2025-10-12 07:47:13 <Ariadne> i did, months ago
2025-10-12 07:47:48 <Ariadne> it would not have any impact on this problem
2025-10-12 07:51:34 <Ariadne> i think the path forward for us is to revert 6af4f25 locally
2025-10-12 07:55:45 <fossdd_> yeah i see
2025-10-12 07:58:50 <quinq> Everybody's waiting on a musl release :)
2025-10-12 07:58:55 <quinq> But it'll happen when it happens
2025-10-12 07:59:25 <quinq> It's being worked on though and shouldn't be delayed too much more
2025-10-12 08:02:22 <Ariadne> ikke: s390x builder needs to be fixed, simply downgrade the musl package to v3.22 ones, and then rebuild musl
2025-10-12 08:02:57 <Ariadne> at any rate, even if musl 1.2.6 were released today, this bug would have still been in the release
2025-10-12 08:05:41 <Ariadne> the solution is some sort of integration testing for musl, but alpine only supports a subset of what musl supports
2025-10-12 08:13:39 <Ariadne> quinq: hopefully it happens before alpine 3.23 rebuild.  we wanted to pull in latest musl for alpine 3.23, and right now our option is taking a snapshot.  if 1.2.6 final comes out before 3.23 release, i will upgrade to it :)
2025-10-12 08:14:15 <Ariadne> alpine 3.23 builders are slated to be brought up in a few weeks at the longest, probably sooner...
2025-10-12 08:19:41 <quinq> Yeah, sounds like it won't be ready in time ^^
2025-10-12 08:20:07 <quinq> Ariadne, maybe musl could you release candidates, so that distros like Apline can test a bit more on edge
2025-10-12 08:20:32 <quinq> Though it's a different issue anyway, it's not being released now because things are still to be merged
2025-10-12 08:20:43 <Ariadne> well, i don't mind taking snapshots
2025-10-12 08:21:07 <quinq> ok :)
2025-10-12 08:21:25 <quinq> s/could you/could do/
2025-10-12 08:22:45 <Ariadne> the issue here is that 6af4f25 was not properly tested, the author admitted that the testing procedure was insufficient and has proposed a fix.  i'll test the fix in the morning on my s390x machine
2025-10-12 08:23:20 <Ariadne> 
ACTION zzz

2025-10-12 08:34:12 <Ermine> Is newlocale(3) allowed to return non-null value on nonexistent locales?
2025-10-12 08:34:29 <Ermine> It causes test failure in libxkbcommon
2025-10-12 08:36:32 <Newbyte> apk considers 0.0.1 to be newer than 0.0.1_gitXXXX, right?
2025-10-12 08:36:43 <Ariadne> yes
2025-10-12 08:37:43 <Newbyte> thanks!
2025-10-12 08:39:52 <Ermine> musl newlocale never returns 0 apparenlty
2025-10-12 08:42:50 <Ermine> I guess I can only remove that test suite
2025-10-12 08:45:02 <quinq> It does on error
2025-10-12 08:50:17 <Sheila> it should return NULL on error.
2025-10-12 08:51:25 <Sheila> Ermine: https://elixir.bootlin.com/musl/v1.2.5/source/src/locale/newlocale.c
2025-10-12 08:52:37 <Ermine> newlocale(LC_ALL_MASK, "bullshit", (locale_t)0) != 0
2025-10-12 08:54:21 <Ermine> should be 0 ENOENT for non-existent locales
2025-10-12 08:58:19 <Sheila> yeah, should return 0 and set errno.
2025-10-12 08:59:04 <Sheila> per https://pubs.opengroup.org/onlinepubs/9799919799/functions/newlocale.html, which I notice musl's newlocale() isn't conformant to.
2025-10-12 09:22:49 <Sertonix[m]> [@newbyte:matrix.org](https://matrix.to/#/@newbyte:matrix.org) Try `apk version -t 0.0.1 0.0.1_git0000` and see the apk-package(5). The _git version is considered newer.
2025-10-12 09:24:44 <Newbyte> Sertonix[m]: Thanks, I thought _git behaved the same as _alpha 
2025-10-12 12:12:36 <ikke> Ariadne: done
2025-10-12 12:17:20 <ikke> Newbyte: https://gitlab.alpinelinux.org/alpine/go/-/blob/master/version/doc.go
2025-10-12 12:17:26 <ikke> pre-suffix versus post-suffix
2025-10-12 12:17:59 <ikke> pre < version < post
2025-10-12 14:50:59 <Saijin_Naib[m]> @iggy thanks, iggy. I'm looking at that now. 
2025-10-12 14:53:39 <Saijin_Naib[m]> Ah, never landed... shoot.
2025-10-12 15:21:48 <omni> I get SIGSEGV in qutebrowser when opening gitlab.a.o with musl 1.2.6_git20250919-r1
2025-10-12 15:22:32 <omni> I'll try to get back with more data, but downgrading to 1.2.5-r20 for now
2025-10-12 15:25:49 <omni> (and that's with qt6-qtwebengine, for anyone who remember that I used to stick to qt5-qtwebengine)
2025-10-12 16:54:32 <rhizoome> Ariadne: I am not as impressed with mimalloc as most people. The only thing where it actually shines are big-int libraries that alloc each int. Otherwise mallocng wasn't much worse. For my own programs a use arenas when needed anyways.
2025-10-13 04:00:21 <Ariadne> rhizoome: yes, like i said the speed trick is really from the deferred frees
2025-10-13 04:06:01 <Ariadne> omni: its due to seccomp filter
2025-10-13 04:07:36 <Ariadne> omni: musl i guess has switched to preadv2/pwritev2 and we need to fix the seccomp filter
2025-10-13 04:08:39 <Ariadne> https://git.musl-libc.org/cgit/musl/commit/?id=5370070fded61b569196764673a4fc8440aac79e
2025-10-13 04:34:24 <Ariadne> chromium itself is also affected
2025-10-13 07:12:15 <ncopa> morning. chromium gives me "Aw, snap" today, on basically everything
2025-10-13 07:13:59 <PureTryOut> probably same seccomp filter issue
2025-10-13 07:17:53 <ncopa> i was hoping to get edge snapshot out today but i guess that will have to wait. again.
2025-10-13 07:57:48 <omni> yes, #17608
2025-10-13 07:58:06 <omni> algitbot: ?
2025-10-13 07:58:16 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17608
2025-10-13 08:10:20 <ncopa> ERROR: sqlcipher-libs-4.11.0-r0: trying to overwrite usr/lib/libsqlite3.so.0 owned by sqlite-libs-3.50.4-r1.
2025-10-13 08:14:53 <omni> yes
2025-10-13 08:15:06 <omni> !91418 broke it
2025-10-13 08:27:35 <quinq> Hi
2025-10-13 08:27:43 <quinq> Hi just ran the merge-usr script as requested
2025-10-13 08:27:49 <quinq> Do I need to regenerate the initrd?
2025-10-13 08:28:21 <quinq> (I don't have a separate /usr)
2025-10-13 08:44:31 <PureTryOut> No
2025-10-13 08:45:10 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91423
2025-10-13 08:53:28 <quinq> omni, maybe they provide a configure option to rename the binary
2025-10-13 08:54:55 <omni> maybe, I had a quick look and didn't find it so reverted for now
2025-10-13 08:55:19 <ncopa> omni: thanks!
2025-10-13 08:55:45 <omni> np
2025-10-13 09:48:33 <omni> well, doesn't seem like it was enough? do we also need to remove the broken packages?
2025-10-13 10:26:17 <ikke> q
2025-10-13 10:29:49 <ikke> Yes, otherwise apk will prefer the latest version
2025-10-13 10:29:55 <ikke> Either that, or pin it to the lower version
2025-10-13 10:32:52 <ikke> omni: I've removed the old packages
2025-10-13 13:14:50 <ncopa> Sertonix[m]: do you think we can tag a -rc release for abuild now?
2025-10-13 13:19:16 <Sertonix[m]> I would still like to see abuild!342 merged but otherwise yes
2025-10-13 14:41:55 <ncopa> I tried to revert https://git.musl-libc.org/cgit/musl/commit/?id=5370070fded61b569196764673a4fc8440aac79e but chromium is still aw snap'ing me
2025-10-13 15:37:16 <ncopa> abuild 3.16.0_rc1 has failing test https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2051146
2025-10-13 15:37:37 <ncopa> also looks like replaces.patch was not upstreamed
2025-10-13 15:38:24 <ncopa> maybe we ship alpine 3.23-stable with abuild 3.15? need to get the builders up now
2025-10-13 15:39:21 <ncopa> i wonder if i should also revert the musl upgrade? it seems broken
2025-10-13 18:07:25 <Ariadne> we can return to 1.2.5, but the upgrade itself is fine.  we will have to deal with the seccomp filters eventually but it could wait for 3.24
2025-10-13 18:18:34 <Ariadne> it has happened a few times now where a point release of musl has changed the seccomp behavior, and i wonder if maybe this should be encoded more clearly into the version, e.g. 1.3.0 vs 1.2.6
2025-10-13 18:49:42 <Sertonix[m]> ncopa: I don't care much about the abuild version on the stable release. I am mostly interested in having it on edge. But if it's only the test failure I already opened a MR to fix it.
2025-10-13 20:00:42 <ncopa> Ariadne: yeah, that would probably be good
2025-10-13 20:04:11 <ikke> it was already reverted
2025-10-13 20:59:13 <PureTryOut> hmm rootbld fails to build anything, it complains that the src file already exists when it's trying to link it to/from somewhere
2025-10-14 06:34:01 <ncopa> i'd like to merge the abuild 3.16 today. I need to start set up the 3.23 builders ASAP
2025-10-14 06:34:38 <ncopa> I think we will be able to deal with the bugs popping up as we go
2025-10-14 06:35:25 <ncopa> or do you think we should wait til after 3.23 with abuild 3.16?
2025-10-14 06:35:49 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91433
2025-10-14 08:19:10 <ncopa> Error relocating /usr/lib/libpython3.12.so.1.0: pwritev2: symbol not found
2025-10-14 08:19:10 <ncopa> Error relocating /usr/lib/libpython3.12.so.1.0: preadv2: symbol not found
2025-10-14 08:19:22 <ncopa> on edge riscv64
2025-10-14 08:21:10 <ncopa> sorry, i had to apk upgrade ...
2025-10-14 09:30:10 <ncopa> im investigating build-edge-riscv64 wireplug
2025-10-14 09:30:16 <ncopa> wireplumber*
2025-10-14 11:26:01 <omni> is there a flag for apk to list/append the fetched indexes, as the previous version did, instead of redrawing the line?
2025-10-14 12:50:54 <ncopa> abuild 3.16 was merged
2025-10-14 13:16:03 <ptrc> speaking of rootbld failing, i'm getting this error and i have no idea how that even happens: https://ptrc.gay/UdvCLROS
2025-10-14 13:16:54 <ptrc> as in, why `$HOME` gets set to just "HOME", for some reason
2025-10-14 13:20:42 <ptrc> oh nevermind, i just noticed it was changed in the latest version, i was looking at old code
2025-10-14 13:20:52 <ptrc> someone forgot a dollar sign
2025-10-14 13:24:45 <ptrc> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/451
2025-10-14 14:04:17 <ncopa> I'm working on build-3-22-riscv64
2025-10-14 15:07:52 <ncopa> im bootstrapping 3.23 builders now. this means we are in feature freeze for 'main' repo for noe
2025-10-14 15:07:56 <ncopa> for now*
2025-10-14 15:09:59 <ncopa> musl does not build anymore. it fails to apply some patches
2025-10-14 15:10:12 <ncopa> smells like abuild change
2025-10-14 15:11:41 <ncopa> maybe its POSIXLY_CORRECT=1 that does it
2025-10-14 15:11:51 <ncopa> i think it fails to create missing files
2025-10-14 15:19:23 <raspbeguy> Hello, can someone have a look at !87884 !90941 !91118 !91337 please?
2025-10-14 15:20:31 <raspbeguy> algitbot ?
2025-10-14 15:21:19 <ptrc> algitbot: ping
2025-10-14 15:21:27 <ptrc> yeah it seems down
2025-10-14 15:21:28 <ptrc> weird
2025-10-14 15:29:38 <ikke> w00t
2025-10-14 15:30:59 <ncopa> Sertonix[m]: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/454 we need revert POSIXLY_CORRECT
2025-10-14 15:54:30 <ptrc> huh, apparently there's an upstream source that blocks the curl user-agent, but lets browsers through: https://files.cacti.net/cacti/linux/cacti-1.2.30.tar.gz
2025-10-14 15:55:09 <ptrc> https://ptrc.gay/SwJMFudI
2025-10-14 16:00:46 <ptrc> i don't suppose we can add curl arguments from either APKBUILD or even abuild
2025-10-14 16:02:35 <f_> Might be a good idea to use a descriptive user-agent?
2025-10-14 16:02:58 <Sertonix[m]> If I remember correctly Adelie added an environment variable to overwrite the user agent.
2025-10-14 16:03:22 <fabricionaweb> arent that cacti on github as well?
2025-10-14 16:03:37 <Sertonix[m]> f_: I would consider that an attach vector TBH
2025-10-14 16:04:05 <ikke> good point
2025-10-14 16:13:20 <f_> Sertonix[m]: why?
2025-10-14 16:14:26 <f_> oh, returning a different archive on alpine useragent? Is that what you mean?
2025-10-14 16:15:17 <Sertonix[m]> Yes
2025-10-14 16:18:20 <ptrc> fabricionaweb: yeah, but it's still silly of them to block *curl* of all things, so i'd rather first hear some kind of statements from project devs, and in general let them know this is an issue :p
2025-10-14 16:20:18 <ptrc> also, it's a great point that *technically* a rogue/compromised upstream could return a malicious tarball only when requested with a distro-specific UA
2025-10-14 16:21:22 <ptrc> though personally i'm not sure about the practicality of it - after all, the package maintainers would also fetch the tarballs with abuild, so they would be able to spot something out of place
2025-10-14 16:21:58 <fabricionaweb> yeah I see, well Idk what is the best to be done here, may we use firefox ua 
2025-10-14 16:22:42 <ptrc> that sounds silly
2025-10-14 16:23:51 <ptrc> like, sure, i guess it would work
2025-10-14 16:24:16 <ptrc> but we should work with upstreams and not against them by circumventing checks, even if they don't make much sense
2025-10-14 16:33:47 <PureTryOut> mkdir: can't create directory 'HOME/': Read-only file system. What... is up with rootbld...?
2025-10-14 16:36:01 <invoked> PureTryOut: read ptrc's messages above
2025-10-14 16:36:30 <invoked> from about 3 hrs ago
2025-10-14 16:36:53 <PureTryOut> Ah, lol, ok. Thanks!
2025-10-14 16:37:04 <invoked> np
2025-10-14 17:11:08 <f_> Saijin_Naib in #alpine-linux reports that uutils breaks on merge-usr, ping pabloyoyoista craftyguy[m] 
2025-10-14 17:11:42 <f_> Seems like the same issue as what was reported in #postmarketos a few days ago
2025-10-14 17:11:52 <Saijin_Naib[m]> topgrade failure due to broken uutils coreutils https://bpa.st/H42DU
2025-10-14 17:12:28 <Saijin_Naib[m]> apk upgrade failure due to broken uutils coreutils https://bpa.st/XFZ6I
2025-10-14 17:14:04 <f_> Saijin_Naib[m]: can I have your logs of merge-usr?
2025-10-14 17:14:15 <Saijin_Naib[m]> log showing which chown, apk fix uutils coreutils, apk del uutils coreutils, then running stuff normally
2025-10-14 17:14:16 <Saijin_Naib[m]> https://bpa.st/GYFL4
2025-10-14 17:14:16 <f_> If running apkv3 the full apk logs should be in /var/log
2025-10-14 17:14:33 <Saijin_Naib[m]> Yeah, I should be apkv3, since I hit the apkv3 not caching packages issue haha
2025-10-14 17:15:32 <Saijin_Naib[m]> So, you want /var/log/apk.log
2025-10-14 17:15:38 <f_> I think I might have an idea of the code path you and that other person might be hitting
2025-10-14 17:15:45 <f_> no just the merge-usr logs that are in there
2025-10-14 17:15:49 <f_> grep for merge-usr
2025-10-14 17:16:13 <craftyguy[m]> you have both uutils and coreutils installed? I'm confused about how to reproduce this, I was trying to trigger it in a chroot yesterday but couldn't...
2025-10-14 17:16:44 <f_> In that other person's log I saw this message which looked sus:
2025-10-14 17:16:49 <f_> https://ircb.dersco.re/uploads/funderscore/f2cc5061-f_-paste.txt
2025-10-14 17:16:49 <Saijin_Naib[m]> no, had coreutils isntalled, replaced with uutils, then usr-merged, then hit the issue where a bunch of basic stuff is broken/misisng, then replaced for coreutils
2025-10-14 17:18:36 <f_> coreutils as in, gnu coreutils?
2025-10-14 17:19:01 <Saijin_Naib[m]> yeah
2025-10-14 17:19:07 <f_> ok
2025-10-14 17:19:28 <Saijin_Naib[m]> log grep for merge is pretty useless
2025-10-14 17:19:39 <craftyguy[m]> ya I can't reproduce this at all :/
2025-10-14 17:19:51 <Saijin_Naib[m]> https://bpa.st/4ZXUQ
2025-10-14 17:20:16 <craftyguy[m]> made a fresh alpine chroot, apk add coreutils then apk add uutils-coreutils (which removed coreutils and installed uutils version), then merge-usr and echo, etc work
2025-10-14 17:20:37 <f_> ooooooh, Saijin_Naib[m]: I forgot you ran it manually
2025-10-14 17:20:43 <f_> do you have logs of it still?
2025-10-14 17:21:19 <craftyguy[m]> would be more useful to see the merge-usr output
2025-10-14 17:21:59 <craftyguy[m]> did merge-usr succeed / not return an error?
2025-10-14 17:23:46 <Saijin_Naib[m]> f_no logs I know of -_-
2025-10-14 17:24:00 <Saijin_Naib[m]> craftyguyyeah, succeeded perfectly fine, no warnings during dry-run even
2025-10-14 17:24:10 <craftyguy[m]> ok
2025-10-14 17:24:20 <Saijin_Naib[m]> system is XFS over LVM, just a root/swap volume, no crypt/dmcrypt
2025-10-14 17:24:48 <Saijin_Naib[m]> x86_64 edge, kept current daily
2025-10-14 17:25:05 <craftyguy[m]> was the sequence of events I did above to try and reproduce this largely the same as what you did?
2025-10-14 17:25:50 <Saijin_Naib[m]> yes, basically
2025-10-14 17:25:56 <Saijin_Naib[m]> this system has been extant for like a year, though
2025-10-14 17:26:06 <Saijin_Naib[m]> So, no idea if that matters, or if you need my entire apk world?
2025-10-14 17:26:38 <Saijin_Naib[m]> stuff got really weird, I think when the musl version got bumped the other day?
2025-10-14 17:26:46 <Saijin_Naib[m]> and since then, I think it got reverted?
2025-10-14 17:26:58 <craftyguy[m]> yeah the version was fixed
2025-10-14 17:27:24 <Saijin_Naib[m]> I've not rebooted in a few days, possibly since that change
2025-10-14 17:27:27 <Saijin_Naib[m]> Maybe this is a transient thing from that?
2025-10-14 17:27:34 <craftyguy[m]> someone else hit something similar to you did, here's the log they shared: https://codeberg.org/MultisampledNight/random/src/branch/main/2025-10-13%20doas%20apk%20upgrade
2025-10-14 17:27:55 <craftyguy[m]> wouldn't seem like it would be related to musl pkg changes...
2025-10-14 17:28:23 <craftyguy[m]> (in pmOS we run merge-usr in a trigger now to auto-migrate folks, which is why you see the output in the apk log above)
2025-10-14 17:28:28 <Saijin_Naib[m]> Yeah, I'm out of my depth, just trying to think of major changes that happened recently
2025-10-14 17:29:05 <Saijin_Naib[m]> But for me, things like chown, mv, cp, etc were missing/broken, similar to that user's log
2025-10-14 17:29:23 <craftyguy[m]> ya I'm out of ideas at the moment. would you mind filing an issue about this here?  https://gitlab.alpinelinux.org/postmarketOS/merge-usr
2025-10-14 17:30:09 <craftyguy[m]> yeah something is definitely going sideways... and the fact that someone else hit is suggests it's not some quirk with your particular install :P
2025-10-14 17:34:45 <Saijin_Naib[m]> and my wife's laptop, same hardware, x86_64 edge GNOME (gnu coreutils) did the usr-merge just fine last night, no breakages
2025-10-14 17:37:14 <craftyguy[m]> you and the other person who hit this problem have 'uutils' in common
2025-10-14 18:03:03 <Saijin_Naib[m]> Just recap what I posted here, aggregate the bpa.st links, etc?
2025-10-14 18:09:57 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/postmarketOS/merge-usr/-/issues/3
2025-10-14 18:55:34 <ptrc> https://github.com/Cacti/cacti/issues/6333
2025-10-14 18:55:39 <ptrc> damn, they were quick
2025-10-14 19:22:26 <achill> woa yeah
2025-10-14 19:38:22 <ikke> "ai firewall" 🙃
2025-10-14 19:39:30 <ptrc> i assume "firewall against AI" :p
2025-10-14 19:39:35 <ptrc> rather than "AI-powered firewall"
2025-10-14 19:39:51 <f_> NI-powered firewall here
2025-10-14 19:41:25 <fabled> Is usr-merge forcibly moving files from /bin to /usr/bin etc.? Sound like apk audit will break horribly 
2025-10-14 19:42:14 <fabled> Really. All packages should be rebuilt with binaries in new location.
2025-10-14 19:43:37 <ptrc> why would it break? all the executables are still there under the paths that apk expects
2025-10-14 19:44:10 <f_> fabled: symlinks are being created too
2025-10-14 19:44:23 <f_> Seems working perfectly fine for me
2025-10-14 19:44:42 <ptrc> `apk audit --system` works for me as well
2025-10-14 19:46:31 <fabled> hmm
2025-10-14 19:48:17 <fabled> I would have apk audit to report the packages broken
2025-10-14 19:49:59 <ptrc> what do you mean?
2025-10-14 19:51:31 <Sertonix[m]> apk audit is partially broken, yes. I considered it ok since it's not that many paths/packages
2025-10-14 19:51:42 <fabled> it should report all moved files as broken
2025-10-14 19:51:53 <fabled> that might actually be apk bug that it does not
2025-10-14 19:52:18 <fabled> and this will be a blocker for me to upgrade anything to alpine 3.23
2025-10-14 19:52:42 <Sertonix[m]> Last time I check it did report the created symlinks and moved binaries.
2025-10-14 19:52:58 <fabled> hard blocker for me
2025-10-14 19:53:26 <fabled> ncopa: ^
2025-10-14 19:54:11 <fabled> i have things that form initramfs run 'apk audit --root newroot' with additional controls. if anything fails, the system fails integrity check and becomes a brick
2025-10-14 19:54:12 <Sertonix[m]> Upgrading to 3.23 doesn't necesarily mean runnig merge-usr (although some people seem to not interested in fixing non-/usr-merged systems when they break)
2025-10-14 19:55:16 <fabled> but new installs get symlinks? then those new installs will be broken and different
2025-10-14 19:56:33 <fabled> apk database tracks files based on the path in the .apk; not the actual install dir ends up getting based via injected symlinks
2025-10-14 19:57:06 <Sertonix[m]> Fair, if you use the official installation methods
2025-10-14 19:57:56 <fabled> no, the install is completely custom
2025-10-14 19:58:05 <fabled> so i suppose then i just stay as-is
2025-10-14 19:58:20 <fabled> but in generally, it sounds like a bad idea for new install to generate things where audit breaks
2025-10-14 19:58:38 <fabled> not against the usr merge. just trying to point out that the migration path sounds problematic
2025-10-14 19:59:10 <fabled> there should have been a mass recompile of everything to move everything to right paths withiin the packages
2025-10-14 19:59:30 <Sertonix[m]> fabled: I hope that you don't plan on doing any complex symlink handling. There are quiet a few things that are a bit broken in similar ways and the long term fix is to not have any package with stuff inside of /bin, /sbin, /lib.
2025-10-14 20:02:51 <fabled> yeah, that's the right way to do the merge. make sure the packages don't install anything there. and ideally, ship the compat symlinks in a package too
2025-10-14 20:03:16 <Sertonix[m]> At the moment we can't move everything to /usr to avoid breaking a lot of code that has /bin, /sbin or /lib hardcoded. /bin/sh being the most obvious example
2025-10-14 20:04:07 <ikke> but /bin would be a symlink to /usr/bin when everything has moved, not?
2025-10-14 20:04:55 <Sertonix[m]> Including a compat symlink in a package could be dangerous since apk might replace the actual binary with a compat symlink since apk can't notice that they end up in the samd location
2025-10-14 20:04:59 <jahway603[m]> Can I please get !91515 merged?
2025-10-14 20:05:49 <ncopa> fabled: sorry to hear. pabloyoyoista is this something you can help with?
2025-10-14 20:06:01 <Sertonix[m]> I think there are a few packages which create the symlinks in install scripts which is ok for now but in my opinion too complicated to be used by many packages
2025-10-14 20:06:49 <Sertonix[m]> ikke: Yes but that's not enough to fix all issues
2025-10-14 20:07:04 <ncopa> If I understand correctly, we need a package ship the symlink(s)
2025-10-14 20:07:33 <fabled> ncopa: ideal world: all packages rebuilt with abuild moving bin -> usr/bin etc, + package shipping symlinks
2025-10-14 20:08:16 <fabled> but then again, if the symlinks are currently precreated by alpine installer, i think i can just go on with 3.23 without running usr-merge, and all works in the legacy layout for me
2025-10-14 20:08:32 <fabled> but anyone who has the usrmerge layout, will get apk audit complaining a lot
2025-10-14 20:08:51 <Sertonix[m]> apk-tools is not properly capable of hqving a directory be deleted and a symlink created in it's place in a single transaction.
2025-10-14 20:09:27 <fabled> so basically usrmerged (either via merge script, or new install) will have broken apk audit, until the packing is redone to correct target paths
2025-10-14 20:10:00 <fabled> Sertonix[m]: yes, the current apk cannot atomically transact everyting. that could have been solved in post-install scripts or similar
2025-10-14 20:12:55 <Sertonix[m]> But it would also mean that we would have a ton of edge users with unbootable or otherwise broke  systems cause bugs happen. There are already various open issues and most of them are not related to the fact that we try to support both for a while
2025-10-14 20:14:37 <fabled> so your argument basically is: it is too hard to do usrmerge in packaging correctly. and solution is: lets ship one release where the database/audit is incorrect as installer/usrmerge did stuff under the package manager, and then fix the packaging in the next few releases?
2025-10-14 20:19:09 <fabled> well, at least the caveat is in the announcement that "apk audit --system" will give false positives
2025-10-14 20:19:36 <fabled> perhaps there should be a time line when the mass rebuild is done, and "apk audit" expected to work again?
2025-10-14 20:20:19 <fabled> and a way to opt-out in the installer
2025-10-14 20:23:46 <ncopa> and maybe also a way to silence the usr_merge_nag.sh til this is sorted
2025-10-14 20:24:38 <fabled> add the caveat there also, to determine if the time for usrmerge is now or a bit later
2025-10-14 20:25:21 <fabled> but if its the installer doing the symlinks, and basically things still working in the old layout, i can just keep my installer doing things they way it does, and get the legacy layout
2025-10-14 20:25:29 <fabled> so that should be good for a release or two
2025-10-14 20:25:42 <fabled> but need to figure out the migration path once the transitional time ends
2025-10-14 20:26:10 <ncopa> i think there is a usr merge issue with the steps left
2025-10-14 20:26:46 <Sertonix[m]> Current ETA for only supporting /usr-merged was 3.27. If things get better we could try to do it earlyer.
2025-10-14 20:27:29 <fabled> I think the release when things *must* be /usr-mergeed is more controverial than the preliminary thing
2025-10-14 20:27:51 <fabled> because then people like me need to do an automated unattended installer to managed fleet where magic happens
2025-10-14 20:30:08 <fabled> so initially planned transitional time of 2 years?
2025-10-14 20:30:29 <fabled> i think there should be definitely a way to opt-out of /usr-merged layout on installer currently
2025-10-14 20:30:33 <Sertonix[m]> You probably want to take a look at the MR for the blog post. There is a bit more context why/how things are planned.
2025-10-14 20:30:47 <ncopa> https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16#tab-issues
2025-10-14 20:31:18 <ncopa> the milestone with issues related
2025-10-14 20:33:12 <Sertonix[m]> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/88
2025-10-14 20:35:14 <fabled> looking at the issues, i think the usrmerge warning and push to do the merge was a bit premature. would have made it a "call for testers" at this stage. more of opt-in than opt-out
2025-10-14 20:39:11 <fabled> just my 5cents
2025-10-14 20:39:23 <Sertonix[m]> There has been a short "call for testers" but it could probably be for a bit longer to avoid people expecting more stability than there is
2025-10-14 20:40:47 <ncopa> also it has been tested for months by postmarket os
2025-10-14 20:41:32 <ncopa> but in general, I have had mixed feelings about it
2025-10-14 20:42:22 <ncopa> but it was important for postmarket os, and they have taking the lead and the responsibility for it, which is why I was ok with it
2025-10-14 20:42:51 <ncopa> and I think they have done a generally good job, even if not perfect
2025-10-14 20:43:00 <fabled> i don't mind usrmerge. and i agree, a lot of good work has been done
2025-10-14 20:43:49 <Sertonix[m]> Testing in pmOS not very applicable to alpine due to the different scope.
2025-10-14 20:44:04 <fabled> but i don't think its a good idea to make it forced with known issues and no concrete timeline when the issues are fixed
2025-10-14 20:44:40 <fabled> my complaint is that the migrational time there is stuff broken, and there's no way to opt out, and no published timeline when things are fixed
2025-10-14 20:45:31 <fabled> but i'm probably in the very minority where the broken stuff actually matters a lot
2025-10-14 20:46:57 <fabled> but at the same time, one of the main reasons why i have sponsoring on apk development is to make "apk audit" work securely (that is audit everything using signed manifests)
2025-10-14 20:49:09 <fabled> ok. enough "feedback" for now. i'll go sleep. i'm sure we can get things sorted out on these. and thanks to everyone on keeping alpine up-to-date on all aspects!
2025-10-14 20:50:00 <Sertonix[m]> I think to get these things properly discussed/improved/fixed (and they should!) there needs to be something on gitlab. There is unfortunatly no general discussion issue (yet).
2025-10-15 00:07:40 <craftyguy[m]> fabled we tried the "move everything in packages" approach, and it was untenable. it was waaaay too tricky to try and move musl and some other things without hosing existing installs. it's not too late though if you want to take a shot at it. I mean, it would be nice if eventually all packages in aports actually install to /usr.
2025-10-15 04:52:50 <fabled> craftyguy[m]: congratulation, you have broken the distrubiton for me then
2025-10-15 04:53:00 <fabled> there would be several ways to do it properly
2025-10-15 04:54:00 <fabled> craftyguy[m]: it's "not nice". it is a "hard requirement" for me that packages will install to /usr. and that there is a clear tipping point in edge when this happens. there also needs to be a way to do this in non-attended way
2025-10-15 04:58:21 <fabled> to be clear: i will probably abandon and fork alpine if "apk audit" stops working on it forever.
2025-10-15 04:58:40 <fabled> ncopa, craftyguy[m], pabloyoyoist, Sertonix[m]: ^
2025-10-15 04:59:15 <fabled> for me a proper migration plan sounds something like:
2025-10-15 04:59:23 <fabled>  1. do opt-in for usrmerge with the links
2025-10-15 04:59:34 <fabled>  2. opt-in comes with apk audit broken
2025-10-15 04:59:50 <fabled>  3. update/rebuild all packages that can be without breaking stuff on the legacy layout
2025-10-15 04:59:51 <craftyguy[m]> tbh this has been discussed for over a year now, and it's not like we hid anything about our plans or what we were doing. where were you?
2025-10-15 05:00:12 <craftyguy[m]> there was plenty of time to weigh in on this stuff
2025-10-15 05:00:50 <fabled> craftyguy[m]: busy on apk-tools, family, personal health and other things. i trusted you do proper migration path that does not break apk audit or unattended apk upgrade
2025-10-15 05:01:38 <fabled>  4. declare hard switch-time when all systems in edge / next-stable willr switch over to new layout
2025-10-15 05:02:00 <fabled>  5. do the above by means of alpine-baselayout shipping symlinks, and having .pre-install or apk-tools support to do the file moving
2025-10-15 05:02:59 <craftyguy[m]> sorry, who said audit would be broken forever?
2025-10-15 05:03:04 <fabled> you
2025-10-15 05:03:08 <craftyguy[m]> I did?
2025-10-15 05:03:59 <fabled> sorry, maybe i misread the earlier comment. i read that " it would be nice if eventually all packages in aports actually install to /usr." that its not planned
2025-10-15 05:04:21 <fabled> perhaps the problem for me is that
2025-10-15 05:04:29 <fabled> there is no clear path what happens in the next 2-4 releases
2025-10-15 05:04:37 <fabled> 1. when all packages will be built to /usr
2025-10-15 05:04:52 <fabled> 2. what happens when the time for hard usrmerge time comes. how edge will be switched?
2025-10-15 05:07:55 <fabled> basically even if usrmerge is shipped now without all packages in /usr
2025-10-15 05:08:10 <fabled> there will be a time when that must happen, that all packages should end up there
2025-10-15 05:08:32 <fabled> and then all the worries about symlinks, /bin/sh, etc will come haunt again
2025-10-15 05:08:58 <fabled> when it comes time to produce edge build, with everything /usr. how does that happen?
2025-10-15 05:09:33 <fabled> until you can give a plan for that, I think usrmerge should be opt-in. or as minimum opt-out. rather than enforced
2025-10-15 05:13:43 <fabled> I also *personally* think the migration is problematic if administrator needs to do things. "apk upgrade -a" should be enough. If its not, then apk should be improved so that it is enough. But I believe .pre-install, .trigger or pre-commit/post-hooks could be used in sufficient manner to do this.
2025-10-15 05:25:39 <fabled> in other words, i see forced migration starting, but no end date when the migration period ends. and more importantly, how the migration period ending final switch over is done on edge. and not knowning how the migration end is going to be executed, is worrying me.
2025-10-15 07:07:46 <ncopa> I suppose we should add apk audit to CI
2025-10-15 07:44:24 <vkrishn> what to do when CI does not pass audit?
2025-10-15 07:44:36 <vkrishn> this is kinda more generic discussion,
2025-10-15 07:44:55 <vkrishn> would it make sense to have alpine forum revive again for discussions like this, having a gitlab ISSUE like "how to solve usr_merge for next release" seems kinda not ok
2025-10-15 07:45:04 <vkrishn> i have some non-standard approach here https://tpaste.us/Kxbq , just food for thought
2025-10-15 08:30:19 <pabloyoyoista> fabled thanks for these feedback, sorry it took me a bit to chime in. Based on that, I guess the only thing you might need is an environment variable to skip these two lines https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504/diffs#a173a80c902ea621aa617d57fa8b6f67f912a380_88_89 ?
2025-10-15 08:30:46 <pabloyoyoista> And then, more clarification on the timeline?
2025-10-15 08:32:11 <pabloyoyoista> Regarding why the migration is not forced, and why things are in that weird state: we iterated a lot on the possible design, but I don't think we kept good track of the different paths
2025-10-15 08:32:46 <pabloyoyoista> My initial goal was indeed what you proposed, move everything to /usr in a single recompilation run and for the migration in the meanwhile
2025-10-15 08:34:55 <pabloyoyoista> That was deemed too risky to due to the nature or alpine users, and therefore after a lot of discussion with Sertonix and help from Ariadne that took production systems like yours in consideration, we came to the current situation
2025-10-15 08:35:59 <pabloyoyoista> Make sure the /usr-merge is opt-in so that people with big fleets can try it manually and understand how that impact their systems. It must remain opt-in until 3.22 is EOL
2025-10-15 08:37:00 <pabloyoyoista> After that, then we'll recompile musl and firmware and everything will be in /usr
2025-10-15 08:39:26 <pabloyoyoista> As of how to do the final migration, it would be helpful if people chimed in to https://gitlab.alpinelinux.org/alpine/aports/-/issues/17423
2025-10-15 08:43:14 <pabloyoyoista> Specially regarding your requirements. We could do a few different things (compulsory action taken before, auto-running the script)
2025-10-15 08:44:11 <pabloyoyoista> I've been fixing issues, I'll continue fixing issues until this is polished for everybody, and I'm very happy to write another blog post with clarifications and improvements
2025-10-15 08:44:34 <pabloyoyoista> I'm also happy if we want to hide the nag script, or make it sound less urgent, or point to a timeline
2025-10-15 08:44:59 <fabled> pabloyoyoista: given current state and concern for migration path. I would make installer by default to not add the symlinks. Make it an opt-in on new installs also similar to current edge upgrade.
2025-10-15 08:45:12 <fabled> Perhaps add an installer flag / question 
2025-10-15 08:46:07 <fabled> To clarify, I don't mind if edge is broken temporarily wrt/ APK audit 
2025-10-15 08:46:40 <fabled> But I'd like releases to not be broken by default. If user does not need audit, they can opt-in
2025-10-15 08:47:26 <pabloyoyoista> I would be a bit hesitant to make it opt-in, means even new installs will need to take action, but maybe others think otherwise. Should we move that discussion specifically to an aports issue?
2025-10-15 08:48:16 <fabled> I thinkt it's bad idea to differentiate new install vs upgrade path
2025-10-15 08:49:35 <pabloyoyoista> I think this is the classic situation where I'd like more opinions from multiple people with experience in Alpine. Like, how widespread or important is apk audit in Alpine. Is it a critical feature for a small amount of people, or something relevant for a majority?
2025-10-15 08:50:36 <pabloyoyoista> Maybe opt-in and the nag script could be enough?
2025-10-15 08:51:23 <pabloyoyoista> To be fair, one of the only things I disagree with what you've said and that worries me about opt-in is user testing
2025-10-15 08:51:56 <pabloyoyoista> I'm very, very happy to put extra work to keep things working for others, and make it work for you and others in your situation
2025-10-15 08:52:41 <pabloyoyoista> But we've been something like 1.5 years on this. And we need feedback from the varied pool of alpine users to be able to understand what are the requirements here exactly
2025-10-15 08:53:39 <pabloyoyoista> And unfortunately, everybody is busy and has their own priorities, and without a little bit of disruption nobody really pays attention to it. And then instead of having this discussion in 2025
2025-10-15 08:53:56 <pabloyoyoista> We'd be having this discussion in 2027 when we forced the migration and broke your systems
2025-10-15 08:54:22 <pabloyoyoista> I think we all want to avoid that
2025-10-15 09:01:18 <fabled> pabloyoyoista: Agree. Just to set the foundation right. Thanks for working on this. I think pushing out the notice, and the nag message is good ways to get attention and review, and those are welcome.
2025-10-15 09:01:24 <fabled> what I think is missing:
2025-10-15 09:01:39 <fabled>  1. roadmap: when edge will be rebuilt, when and how the switch will happen on edge
2025-10-15 09:02:08 <fabled>  2. make it first opt-in instead of forced on new installs. this is intrusive feature that will break some features like apk audit, and things if people had /usr on separate mount point
2025-10-15 09:04:07 <fabled>  3. and ideally there should be path for "apk upgrade -a" to do the merge
2025-10-15 09:04:28 <fabled> i don't mind if "edge" is broken for some time
2025-10-15 09:04:50 <fabled> i personally think releases by default should be working for "apk audit" other things
2025-10-15 09:04:58 <pabloyoyoista> Perfect, thanks! 2: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17620
2025-10-15 09:05:53 <pabloyoyoista> 3 should be no issue. Solved downstream: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/main/postmarketos-base/postmarketos-base.post-upgrade?ref_type=heads
2025-10-15 09:06:46 <pabloyoyoista> Could change depending on alpine requirements, but totally doable. The script was made minimal so that it could be added as a core dependency
2025-10-15 09:06:56 <pabloyoyoista> So exactly to solve 3. in an alpine way
2025-10-15 09:07:33 <pabloyoyoista> I'll open another issue for  1. later, gotta leave now
2025-10-15 09:07:39 <pabloyoyoista> And thanks a lot for this feedback, this is greatly welcomed
2025-10-15 09:11:03 <fabled> yeah, that sounds something i can work with
2025-10-15 09:11:21 <fabled> i just really hope all this was in the full migration plan along with the nagscreen/public posting
2025-10-15 09:11:30 <fabled> added my comments on the new ticket
2025-10-15 09:11:34 <fabled> happy to continue converstaion there
2025-10-15 09:12:30 <fabled> and tbh. once the full rebuild is done on edge. and "apk upgrade" works. we can probably drop the old layout sooner. i believe we officially support "apk upgrade" path only to skip one major release branch.
2025-10-15 09:21:04 <fabled> pabloyoyoista: thanks!
2025-10-15 09:44:06 <ncopa> I bumped into this error when bootstrapping 3.23 builders: https://tpaste.us/ox9R
2025-10-15 09:44:20 <ncopa> not sure if this is due to a change in abuild?
2025-10-15 09:45:25 <ptrc> huh, py3-pytest seems to provide `usr/lib/python3.12/site-packages/py.py`
2025-10-15 09:45:44 <ptrc> but that hasn't been picked up before as `provides=py3.12:py` for some reason
2025-10-15 09:48:55 <ptrc> and they don't conflict in practice only because Python itself picks py3-py over the vendored thing within pytest
2025-10-15 09:49:20 <ptrc> ncopa: i'll just put a `rm -f` for the py.py file in pytest, since we have proper py3-py in dependencies anyway
2025-10-15 09:49:22 <ptrc> and that should fix it
2025-10-15 09:50:16 <ncopa> py3-pytest works without py3-py, using the vendored py.py?
2025-10-15 09:50:27 <ptrc> ..kinda, i think?
2025-10-15 09:50:31 <ncopa> we could also make it conditional with ABUILD_BOOTSTRAP
2025-10-15 09:50:54 <ncopa> so if ABUILD_BOOTSTRAP is set, we drop the py3-py dep
2025-10-15 09:51:11 <ptrc> https://ptrc.gay/VGUAYBuI
2025-10-15 09:51:18 <ptrc> this is the entirety of the shim file
2025-10-15 09:51:29 <ptrc> so i guess it works for pytest
2025-10-15 09:51:37 <ptrc> but it wouldn't work for, well, anything else that needs full pylib
2025-10-15 09:51:54 <ptrc> so we should just make pytest stop providing `py3.12:py` and remove the shim
2025-10-15 09:52:07 <ptrc> cc: achill
2025-10-15 09:52:22 <ncopa> # shim for pylib going away
2025-10-15 09:52:40 <ncopa> what is pylib?
2025-10-15 09:52:51 <ptrc> py3-py
2025-10-15 09:53:06 <ptrc> https://pylib.readthedocs.io/en/stable/
2025-10-15 09:53:49 <achill> miau
2025-10-15 09:54:09 <ptrc> hiya, just pinging you since you're the maintainer for py3-pytest
2025-10-15 09:54:23 <achill> yeah yeah Looks good
2025-10-15 09:55:09 <ptrc> oki, dropped a commit in master, thanks for confirmation ^^
2025-10-15 09:55:22 <achill> thank you :3
2025-10-15 09:55:57 <ncopa> Thanks for fixing it so fast!
2025-10-15 09:56:26 <ptrc> you're welcome c:
2025-10-15 11:07:03 <pabloyoyoista> Does anybody now of a reason why openrc is not upgraded to 0.63?
2025-10-15 11:13:02 <ncopa> probably because the maintainer is lazy
2025-10-15 11:20:33 <pabloyoyoista> Doubt lazyness is a reason for anybody to do or not do voluntary work :P But maybe the question was badly worded. More if there are known blockers
2025-10-15 11:20:54 <achill> not that i know of :p
2025-10-15 11:21:43 <achill> !91552
2025-10-15 11:32:54 <ncopa> I started to look at it and the VRF support is blocking, as achill mentions in the above MR
2025-10-15 11:36:07 <Sertonix[m]> ptrc: The py.py provider exists since https://gitlab.alpinelinux.org/alpine/abuild/-/commit/0f7ea33c72a4329428d223ab8ca7d4692ba351b7
2025-10-15 11:37:55 <ncopa> I wonder if it would make sense to add an option to exclude given provides. eg something like: py_provides_exclude="py.py"
2025-10-15 11:38:06 <ncopa> or '.*/py.py'
2025-10-15 11:41:26 <Sertonix[m]> A conflicting provider like this means that there are 2 files which could be refered to by import and only one is chosen. Sounds like it should conflict to me
2025-10-15 11:45:54 <Sertonix[m]> As I noted in abuild#10084 our python provider detection mechanism is a bit broken at it's core.
2025-10-15 11:46:22 <vkrishn> btw, how does audit work in alpine v3.21? never got any output  if i change/removed some /bin/?
2025-10-15 11:47:31 <Sertonix[m]> Have you used apk audit --full ?
2025-10-15 11:48:07 <ncopa> Sertonix[m]: https://ptrc.gay/VGUAYBuI comments shows that they depend on preference
2025-10-15 11:48:13 <ptrc> Sertonix[m]: ah, so that's why it didn't show up on edge, makes sense :3
2025-10-15 11:48:43 <ptrc> ncopa: it's still wrong to have two packages providing differing implementations of the same thing, so i'd say the packages conflicting is correct here
2025-10-15 11:48:56 <ptrc> even though it works on a technicality 
2025-10-15 11:50:11 <vkrishn> yup, thank, got .. X bin/?
2025-10-15 11:50:21 <Sertonix[m]> !tracedeps would likely be enough in such case
2025-10-15 11:52:07 <Sertonix[m]> vkrishn: Have you used merge-usr?
2025-10-15 11:57:24 <raspbeguy> Hello, can someone have a look at !87884 !90941 !91118 !91337 !91546 please?
2025-10-15 12:08:27 <vkrishn> Sertonix[m]: not yet, got busy updating my php stuffs, will try
2025-10-15 12:08:55 <Sertonix[m]> That doesn't fix it!
2025-10-15 12:09:57 <Sertonix[m]> X generally means that the file was deleted which seems odd. merge-usr is known to confuse apk audit, that's why I asked
2025-10-15 12:14:57 <vkrishn> Sertonix[m]: yes, i got that, i tried that by removing a file from /bin/, and did `apk audit /bin' (nothing), but 'apk audit --full' showed
2025-10-15 12:16:39 <vkrishn> i think man pages should have some examples at bottom
2025-10-15 12:18:01 <vkrishn> got it, apk audit --system /bi
2025-10-15 12:18:23 <vkrishn> apk audit --system /bin
2025-10-15 12:28:24 <vkrishn> yippee, i have only diskless installs, i don't need to bother a lot
2025-10-15 12:28:50 <vkrishn> "If you are using diskless installations and relying on apkovl files to persist configuration across reboots, you do not need to do anything" 
2025-10-15 13:31:06 <fabled> pabloyoyoista: also as another migration path option. what we did with the uclibc -> musl upgrade. make a new 'edge-usrmerge' repository and force abuild to rewrite packages on those packages. then we have a way to systemically test the transition from one repository to the other. though, I suspect the repository is now huge compared to what we had back in uclibc days. so perhaps make it an overlay that replaces only the core 
2025-10-15 13:31:06 <fabled> packages that should be done last in one go.
2025-10-15 13:44:57 <fabled> Maybe community/testing can be just repackaged, and do the separate build for main only?
2025-10-15 13:47:15 <pabloyoyoista> I mean, the only thing that really matters and cannot be moved without the symlinks is /bin/sh, musl, and firmware
2025-10-15 13:47:37 <pabloyoyoista> I'm trying to recap the latest discussions and getting it into an issue
2025-10-15 14:03:59 <ncopa> ptrc: seems like wasi-libc fails to build now due to it fails to find clang
2025-10-15 14:04:24 <ncopa> maybe we should chage the llvm version to 21?
2025-10-15 14:05:32 <ncopa> or we need to set the clang version: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91570
2025-10-15 14:07:49 <fabled> pabloyoyoista: if the core package set needing atomic change is identified, doing a main-usrmerge repo for those should be simple. They could just source the apkbuild from main and amend pkgver with _p1. Or keep the apkbuild in main to generate both depending on some variable set
2025-10-15 14:09:14 <fabled> Then matter of enabling usr-merge is just adding the overlay repository. And would work the same for new installs.
2025-10-15 14:10:21 <fabled> Happy to also add some apk-tools features if needed and it'd simplify things a lot
2025-10-15 14:12:13 <ncopa> we'd only need separate packages for /bin/sh, musl and firmware?
2025-10-15 14:13:34 <fabled> And I think the usr-merge script/binary should installed by default during transitional time. Needing to install/remove it is extra step. Perhaps even make it part of some core package (directly or as a dependency)
2025-10-15 14:16:51 <fabled> ncopa: yes sounds like the set of packages needing atomic change is fairly small
2025-10-15 14:19:12 <ncopa> i wonder if we could build them as subpackages, eg musl-usr-merge, with lower provides priority, and have a usr-merge package with hard deps on those
2025-10-15 14:19:30 <fabled> Also an option 
2025-10-15 14:20:03 <ncopa> would probably be easier to maintain than a separate repo
2025-10-15 14:21:03 <pabloyoyoista> fabled: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17624
2025-10-15 14:22:08 <pabloyoyoista> I see the possibility of those alternatives. But: there were some strong opinions against having the merge-usr script installed by default in all installs
2025-10-15 14:22:39 <pabloyoyoista> And also against automatic migration paths
2025-10-15 14:24:49 <pabloyoyoista> IIRC the problem with the provides idea is timing between musl being installed, and the symlinks being in place
2025-10-15 14:25:10 <fabled> Automatic migration is a must for unattended upgrades. There needs to be a way to do it, if not automatic. And some safety to abort if /usr is different mount point.
2025-10-15 14:25:30 <fabled> We can do a small static binary to do the core swap if needed
2025-10-15 14:25:54 <pabloyoyoista> I mean, that's what we do right now
2025-10-15 14:26:20 <fabled> I mean there needs to be a way to allow fully automatic upgrade without admin running manually things 
2025-10-15 14:26:48 <fabled> Even if it's just touch /etc/alpine/do-user-merge
2025-10-15 14:27:45 <pabloyoyoista> What's the difference between touch /etc/alpine/do-user-merge and merge-usr?
2025-10-15 14:27:52 <pabloyoyoista> See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504#note_521847 for background
2025-10-15 14:29:10 <fabled> So what happens when non merged usr is not supported. And the user who did not follow instructions do APK upgrade on edge?
2025-10-15 14:30:04 <fabled> I'd rather attempt automatic usr-merge rather than blow up the system
2025-10-15 14:30:20 <pabloyoyoista> And the problem with the provides is the ordering of actions. The links must be in place before musl-merge-usr is installed. And I did not find a way to establish ordering with packages without dependencies (e.g: alpine-baselayout and musl). Maybe an apk feature here would indeed help
2025-10-15 14:31:54 <pabloyoyoista> The suggestion by Ariadne was to not do it (see v3.27 in https://gitlab.alpinelinux.org/alpine/aports/-/issues/17624). But maybe indeed attempting it in 2 years, would be acceptable if somebody ignored messages for that long
2025-10-15 14:32:38 <fabled> But I think it's important to be consistent with new install and upgrade path
2025-10-15 14:32:57 <fabled> For me, default install should be opt-in until edge has transitioned
2025-10-15 14:33:23 <fabled> Once the automatic transition works on edge. It works between release upgrade also 
2025-10-15 14:34:37 <pabloyoyoista> How do you know the state of "edge has transitioned"? Like, if 90% of users have transitioned and 10% haven't
2025-10-15 14:35:15 <fabled> I mean we should have "APK add usr-merge" do automatically the thing
2025-10-15 14:35:24 <fabled> And replace to correct packes
2025-10-15 14:35:46 <fabled> Once that works. No hack script is needed to be ran manually. And we know the upgrade path works
2025-10-15 14:36:42 <fabled> I'd rather have the nag screen give warning/error if the /usr is separte mount. And say this system will be soon unsupported 
2025-10-15 14:37:55 <pabloyoyoista> I sank a considerable amount of time on the APK add usr-merge approach. Not with provides, but directly moving packages. So same logic, less complexity, and I did not manage to make it work
2025-10-15 14:38:19 <fabled> Then you should not do it
2025-10-15 14:38:57 <fabled> I'm that annoyed with the usr-merge hack script and breaking audit
2025-10-15 14:39:28 <pabloyoyoista> I'm not sure if being annoyed is a reason to be disrespectful
2025-10-15 14:40:02 <pabloyoyoista> Not just to me, but to others that spent time on that. Can give you a long list of "people that should not do it"
2025-10-15 14:40:03 <fabled> No disrespect intended 
2025-10-15 14:42:22 <achill> fabled: The MR/issues with the approuch has been open a long time, and there was enough time to discuss it, and it was mulitple times redrafted. now changing things again after the whole thing got discussed and merged it kinda too late
2025-10-15 14:43:04 <achill> automatic upgrades are not really supported anyway between major versions or on edge
2025-10-15 14:43:16 <pabloyoyoista> achill: I have no problem with rethinking the solution to improve it
2025-10-15 14:43:41 <pabloyoyoista> But we need to come to an agreement and document it
2025-10-15 14:43:59 <fabled> to reiterate: i want a plan that says when "apk audit" is working again as expected
2025-10-15 14:44:06 <fabled> and ideally "apk upgrade" should upgrade to that
2025-10-15 14:44:18 <fabled> achill: "upgrade" is supported between major version
2025-10-15 14:44:27 <achill> yes but not fully automatic
2025-10-15 14:44:45 <achill> i.e. a admin still has to supervise it and check for the apk log etc
2025-10-15 14:44:49 <fabled> those have been truly exceptions, and so far I've been able do upgrade with "apk ugprade -a" for most things
2025-10-15 14:47:42 <achill> and it still works if you just do "apk upgrade -a". at some point it will be a automatic merge-usr, until then the system should technically still work as expected
2025-10-15 14:48:17 <fabled> yes, that's what i really want
2025-10-15 14:48:18 <pabloyoyoista> We have 2 years until apk upgrade -a breaks according to the current timeline
2025-10-15 14:48:28 <achill> yeah
2025-10-15 14:48:53 <fabled> "apk upgrade -a " should eventually do the upgrade autmatically, and there should be release tipping point when upgrading to release 3.Y it also happens automatic
2025-10-15 14:49:00 <pabloyoyoista> So let's take this with a bit more time
2025-10-15 14:49:06 <pabloyoyoista> I'll try to do a patch this week for opting-out on install
2025-10-15 14:49:17 <fabled> thanks
2025-10-15 14:49:18 <fabled> yes
2025-10-15 14:49:30 <fabled> i think also 2 years transitional time when "apk audit" is broken on default install is too long
2025-10-15 14:49:39 <pabloyoyoista> If nobody beats me to it. And then we can discuss opt-in or whatever
2025-10-15 14:51:10 <pabloyoyoista> Is there a time limit you'd find acceptable?
2025-10-15 14:51:45 <fabled> I don't mind if edge is broken for a time period (say months)
2025-10-15 14:52:05 <pabloyoyoista> Like, 6 months? 1 year?
2025-10-15 14:52:05 <fabled> I generally try to upgrade to every other major release (once a year)
2025-10-15 14:52:32 <fabled> so having one release broken is probably not a deal breaker for me. but having it broken for more than a year is becoming painful
2025-10-15 14:52:47 <fabled> but ideally no more than 6 months
2025-10-15 14:52:55 <pabloyoyoista> Ok, let's take that into account
2025-10-15 14:53:26 <pabloyoyoista> Hopefully there's something we can do about it
2025-10-15 14:53:58 <pabloyoyoista> Let's talk next week on a call
2025-10-15 14:54:07 <fabled> There is no gurantee that "apk upgrade" from stable 3.X to 3.Y works if Y>X+2
2025-10-15 14:54:11 <fabled> that has been the rule
2025-10-15 14:54:44 <fabled> But I also really would hate if a stable release may or may not be usr-merged depending if its new install or upgrade path
2025-10-15 14:54:48 <pabloyoyoista> Is that documented somewhere? Might wanna add it to the docs somewhre
2025-10-15 15:13:42 <achill> thats just a loosely rule
2025-10-15 15:15:00 <achill> usually compat is kept for multiple release if it doesn't bug enough (e.g. the py-xxx providers) but other compatabilities may be removed at least after a single release
2025-10-15 15:15:21 <achill> thats the reality what happens in aports
2025-10-15 15:17:27 <achill> but that is also part of my developer documentation im trying to draft up
2025-10-15 15:24:16 <p_6f3Ik7Suw> is there an tested/mature upgrade path to merge seperate / and /usr partitions on lvm devices while in use on a running system?
2025-10-15 15:26:18 <pabloyoyoista> root and /usr in different partitions has not been supported by the installer for many, many years, and last time we discussed with ncopa, we considered it an unsupported configuration. So it's not tested. But we put the work to make sure /usr can be mounted from the initramfs. So I would try to run merge-usr --dryrun and move things as conflicts arise
2025-10-15 15:28:18 <p_6f3Ik7Suw> it has worked always without breaking so far until usr-merge
2025-10-15 15:28:22 <p_6f3Ik7Suw> even if unsupported
2025-10-15 15:28:58 <pabloyoyoista> Right, that's the risk of unsupported configurations. They work until they don't
2025-10-15 15:29:41 <pabloyoyoista> I'm pretty sure the changes we did to the initramfs should make it continue be supported
2025-10-15 15:30:33 <pabloyoyoista> But testing it is not extensive
2025-10-15 15:31:17 <pabloyoyoista> I'm happy to help fix issues or come to compromises, but I cannot test a setup that is not installable
2025-10-15 15:32:54 <p_6f3Ik7Suw> so was the transition from supported to unsupported ever announced? and why do you say it is not installable? take 3.16 or so install that. why would that not work?
2025-10-15 15:33:32 <p_6f3Ik7Suw> my question is specifically about merging split partitions, if that was not clear.
2025-10-15 15:33:42 <p_6f3Ik7Suw> to get to a supported stated from unsupported
2025-10-15 15:35:48 <p_6f3Ik7Suw> i understand the answer is no, and there is no plan to change that iiuc
2025-10-15 15:36:16 <pabloyoyoista> I'm a bit confused as of whether that's related to the usr-merge or not
2025-10-15 15:36:23 <rhizoome> do I understand that right. initramfs-init supports mounting /usr (https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in?ref_type=heads#L793) but it is unsupported in terms of: does it actually work?
2025-10-15 15:37:12 <pabloyoyoista> We did at least a few successful tests, including or a real system when adding that patch. But it does not get further testing
2025-10-15 15:38:19 <p_6f3Ik7Suw> it works for me this initram mounting /usr - although it fails the fsck for /usr since it is mounted rw
2025-10-15 15:41:27 <p_6f3Ik7Suw> but now i'm also confused pablo, maybe usr-merge also works on split partitions. i'm just to scared to try it out on production systems
2025-10-15 15:42:30 <ikke> p_6f3Ik7Suw: Can you test it on non-production systems?
2025-10-15 15:45:16 <pabloyoyoista> There is no reason it should not work on split partitions. There's only one place where we use hardlinks, and that has a fallback to copy the files
2025-10-15 15:46:34 <pabloyoyoista> So in that sense, yes, the merge-usr script should be compatible with different partitions
2025-10-15 15:56:53 <rhizoome> I mount /usr on a "diskless" system (ie booting from usb stick but not without disks) to save RAM space. my migration process will be to stop mounting /usr, updating and then wipe the /usr disk and try to mount it again.
2025-10-15 17:01:59 <Ariadne> fabled: regarding abusing commit hooks, it’s because packages don’t have anywhere else to put “system” commit hooks.  a few other packages also abuse the commit hooks for this purpose, the nag script is just the most visible.  maybe we should add a “system commit hook” path?
2025-10-15 17:02:53 <Ariadne> i personally agree they should not live in /etc/apk for the reasons you state, and also because it’s not configuration data
2025-10-15 17:09:38 <fabled> Ariadne: there was a comment on a closed ticket requesting this. But it probably slipped through my Todo. Adding commit hooks and few others in the alternative system paths sounds ok. PR or issue is welcome 
2025-10-15 17:13:27 <Ariadne> i’ll do it this evening :)
2025-10-15 17:23:21 <Ariadne> for what it’s worth, i don’t think anyone wanted to do the usr-merge the way it has been implemented.  we need to balance the needs of many different projects and users
2025-10-15 17:25:12 <achill> yeah finding a plan that suits everyone is basically impossible with our size in mind ;)
2025-10-15 17:33:49 <p_6f3Ik7Suw> ikke: i don't have a a non-production system, all i have is these 3 decade+ (possibly even 2 decades old, dunno when my predecessor started) old legacy systems that i operate for a local charity for socially challenged people
2025-10-15 17:59:01 <Biswa96[m]> would it be possible to review/merge !84382 ? It's been 5 months since created.
2025-10-15 17:59:22 <ikke> Biswa96[m]: I was casually starting to review it
2025-10-15 18:02:56 <Saijin_Naib[m]> oh wow, that's exciting! I loved Budgie on Solus. Nice mix of GNOME, Cinnamon, and XFCE-like UX
2025-10-15 18:03:12 <Saijin_Naib[m]> I tried early on and was way over my head, haha
2025-10-15 18:51:12 <f_> yay!
2025-10-15 18:51:18 <f_> I also loved budgie :D
2025-10-15 18:51:32 <f_> (and love real budgies too)
2025-10-15 19:10:09 <piner> > initramfs-init supports mounting /usr... but it is unsupported in terms of: does it actually work?
2025-10-15 19:10:13 <piner> Here's something fun to think about. Why would /usr need to be mounted by the initramfs in the first place?
2025-10-15 19:10:17 <piner> $ ldd /bin/mount | grep /usr
2025-10-15 19:10:20 <piner> libeconf.so.0 => /usr/lib/libeconf.so.0 (0x7efd3d237000)
2025-10-15 19:11:42 <ikke> grep -r /usr /etc/mkinitfs/features.d/
2025-10-15 19:16:11 <piner> I think what you're showing is files that get copied from /usr into the initramfs.
2025-10-15 19:17:11 <piner> What I'm showing is that if you switch_root into the rootfs without a /usr, you can't run things in /bin that were linked against things in /usr/lib.
2025-10-15 19:17:50 <piner> And "mount" is one of those things, laugh
2025-10-15 19:43:02 <Saijin_Naib[m]> Now we need Cinnamon 🤔
2025-10-15 19:43:21 <Saijin_Naib[m]> I also tried packaging that and woooo, I am not ready
2025-10-15 19:47:50 <ncopa> anyone has idea why gnome-software-plugin-apk2 fails on riscv64? 1/1 gs-self-test-apk FAIL            2.48s   killed by signal 6 SIGABRT
2025-10-15 19:48:21 <ncopa> we stil lhave not been able to tag edge snapshot because we push updates faster than the builders manage to build
2025-10-15 19:48:55 <achill> would just skip tests until its idling again tbh
2025-10-15 19:49:36 <achill> i think last time we also did a gitlab warning to not push new commit, that was nice i think, but ideally the timespan isn't too big where no new commits can be pushed
2025-10-15 19:55:52 <ikke> ERROR:tests/gs-self-test-apk.p/gs-self-test.c:403:apk_plugin_test_gs_plugins_apk_updates: 'gs_app_has_quirk (_tmp13_, GS_APP_QUIRK_IS_PROXY)' should be FALSE
2025-10-15 19:59:49 <ikke> I've added a message for developers
2025-10-15 20:14:44 <ncopa> vectorscan needs to be fixed
2025-10-15 20:15:23 <ikke> It's in a unittest apparently
2025-10-15 20:15:35 <ncopa> i dont think i can wait for chromium to finish build need to go to bed soonish
2025-10-15 20:15:49 <ncopa> I suppose we could let the message stay over night?
2025-10-15 20:17:26 <ikke> I have set it for multiple dsays
2025-10-15 20:17:28 <ikke> days
2025-10-15 20:18:03 <ikke> Would `int dummy = 0;` fix the uninitialized error?
2025-10-15 20:18:38 <ikke> https://tpaste.us/Drvq 
2025-10-15 20:19:21 <ikke> achill: ^
2025-10-15 20:24:55 <ncopa> i pushed the fix
2025-10-15 20:25:09 <ncopa> from here: https://github.com/VectorCamp/vectorscan/pull/352
2025-10-15 20:26:12 <ikke> 👍
2025-10-15 20:27:17 <ncopa> interesting. rust failed on build-3-23-x86_64
2025-10-15 20:27:23 <ncopa> rustc-LLVM ERROR: out of memory       
2025-10-15 20:27:23 <ncopa> rustc exited with signal: 6 (SIGABRT)
2025-10-15 20:27:23 <ncopa> Allocation failed                       
2025-10-15 20:27:56 <ncopa> the machine only has 256G ram
2025-10-15 20:28:41 <achill> noice thanks, really great that the CI didnt had a issue with it
2025-10-15 20:29:05 <ncopa> weird
2025-10-15 20:32:09 <ncopa> great. now I get  internal compiler error: Segmentation fault when building clang 21 on build-3-23-riscv64
2025-10-15 20:36:09 <achill> wut
2025-10-15 20:36:13 <achill> maybe just retry it?
2025-10-15 20:36:22 <achill> compiler segfaults are really the best
2025-10-15 20:41:57 <ncopa> yeah, im retrying
2025-10-15 20:49:12 <ncopa> the release script is broken. update-kernel fails:
2025-10-15 20:49:15 <ncopa> install: omitting directory '/tmp/update-kernel.BiPGZT/root/lib/firmware/ath11k/WCN6855/hw2.0/nfa765
2025-10-16 06:03:33 <ncopa> builders are idle but I can tag because update-kernel is broken with the current linux-firmware. need to fix that first
2025-10-16 06:20:26 <ncopa> i know why update-kernel breaks
2025-10-16 06:21:54 <ncopa> modinfo -F firmware may return a glob, with a *, and that works fine as long as the expanded file points to a file
2025-10-16 06:22:02 <ncopa> ath11k/WCN6855/hw2.1/*
2025-10-16 06:22:10 <ncopa> expands to a directory
2025-10-16 06:22:20 <ncopa> i wonder how the kernel handles that?
2025-10-16 06:28:33 <ncopa> modinfo ath11k_pci -F firmware
2025-10-16 07:07:30 <raspbeguy> Hello, can someone have a look at !87884 !90941 !91118 !91337 !91546 please?
2025-10-16 08:22:01 <ncopa> I have a reproducer: https://tpaste.us/bQeM
2025-10-16 08:47:06 <vkrishn> ncopa: seems ath11k's  -F firmware might also help #16838
2025-10-16 08:47:16 <vkrishn> if its something happening in block https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/update-kernel.in?ref_type=heads#L309
2025-10-16 08:48:12 <vkrishn> then maybe something like this, https://tpaste.us/7oYB 
2025-10-16 08:48:22 <ncopa> yes. what happens is that the glob expands to a directory, but current code assumes it is a file: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/update-kernel.in?ref_type=heads#L319
2025-10-16 08:48:43 <vkrishn> https://tpaste.us/7oYB 
2025-10-16 08:49:03 <ncopa> exactly
2025-10-16 08:49:33 <vkrishn> line 316 to 320 might need a bit rethinking
2025-10-16 08:50:08 <ncopa> i would say think 309-322
2025-10-16 08:50:24 <ncopa> first step was to get the testsuite to catch it though
2025-10-16 08:50:40 <ncopa> and it does: https://tpaste.us/1yP0
2025-10-16 08:52:55 <ncopa> I suppose we can temp work around it by excluding the directory: https://tpaste.us/py5W
2025-10-16 08:53:04 <ncopa> at least so we can tag a snapshot
2025-10-16 08:53:18 <ncopa> the ath11k driver may be broken for that though
2025-10-16 08:57:26 <vkrishn> i hope, there isn't something like, ath11k/WCN6855/*/*
2025-10-16 09:02:06 <vkrishn> how about build(pkg) modules->firmware mapped sqlite db?
2025-10-16 09:02:16 <vkrishn> that abuild can use
2025-10-16 09:05:06 <vkrishn> possibly more uses 
2025-10-16 09:40:04 <ncopa> vkrishn: i fixed it: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/268
2025-10-16 09:43:38 <ncopa> edge snapshot is done. thank you for holding back your merges!
2025-10-16 09:46:01 <ncopa> c++ on riscv64 still gives internal compiler error: Segmentation fault
2025-10-16 10:05:09 <ncopa> seems like s390x edge builder is a bit broken
2025-10-16 10:05:33 <ncopa> s390-tools-2.23.0-r3[so:libfuse3.so.3]
2025-10-16 10:06:38 <ncopa> im gonna make a hack
2025-10-16 10:25:53 <ncopa> do we have any s390x maintainers? tmhoang is still listed as maintainer for main/s390-tools
2025-10-16 10:25:59 <ncopa> we need fix s390-tools
2025-10-16 10:36:19 <ncopa> another issue I currently have: the docker image for the new edge snapshot failed in tests, due to /var/cache/apk was missing
2025-10-16 10:36:49 <ncopa> there is a test that verifes that it is empty, but it assumes that the directory exists
2025-10-16 10:38:11 <ikke> tmhoan left IBM
2025-10-16 10:39:00 <ikke> ncopa: do you still have the "Change of IBM contact point for Alpine Linux s390x on IBM Z" email?
2025-10-16 10:41:14 <ncopa> found it
2025-10-16 10:43:13 <vkrishn> has anyone given thoughts how merge-usr will be useful on tiny-miny wearable/fashionable (stitched on clothes) devices
2025-10-16 10:43:53 <ikke> That'
2025-10-16 10:44:01 <ikke> That's quite a specific application
2025-10-16 10:45:18 <ikke> Some of the benefits the folks at pmos try to achieve apply to embedded applications as well
2025-10-16 10:45:56 <vkrishn> its will evolve, designs are open ground
2025-10-16 10:51:52 <ncopa> ok. current blckers for 3.23 builders: 1) gcc's c++ segfaults when building clang21.  2)  itstool fails to build (reproducible with abuild rootbld)
2025-10-16 11:27:51 <ncopa> the gcc ICE is non-fun
2025-10-16 11:28:17 <ncopa> seems like its not deterministic, and only happens when the CPU or memory is preasured
2025-10-16 11:28:33 <ncopa> when building the file alone, without parallelism, it appears to pass
2025-10-16 11:28:48 <ncopa> so it is probably not a bug in gcc that triggers it
2025-10-16 11:28:56 <ncopa> its usually hardware issue
2025-10-16 13:08:32 <eletrotupi> hello! one of the packages I'm working on depends solely on coreutils, such as cat, env, mkdir, grep, awk and vi, so how should I package them? should I add any line on depends or leave it empty? maybe should ask for a cmd: that provides any of these, regardless of being the busybox one or other relevant coreutils package?
2025-10-16 13:09:05 <Habbie> not an expert, but cmd: sounds nice to me
2025-10-16 13:09:46 <Habbie> ah, and plenty of ports depend on cmd: things
2025-10-16 13:10:06 <Habbie> 'vi' is not a 'coreutil' i think btw? as in, it's not in coreutils. it's in busybox i guess :)
2025-10-16 13:10:07 <eletrotupi> really? my git grep skills requires sharpening I guess
2025-10-16 13:10:42 <eletrotupi> yeah, that's why I think that adding as a explicit dependency is better, I guess
2025-10-16 13:10:47 <Habbie> testing/ssh-tools/APKBUILD:depends="bash perl colordiff cmd:ssh cmd:ssh-keygen cmd:ssh-keyscan cmd:column"
2025-10-16 13:12:27 <eletrotupi> i think that adding cmd:cat for example sounds a bit silly
2025-10-16 13:12:38 <Habbie> yeah, i bet there is a base set that is useless to mention
2025-10-16 13:13:21 <eletrotupi> i'll add just cmd:vi, cmd:grep and maybe cmd:awk
2025-10-16 13:13:31 <eletrotupi> which I suppose can be replaced by other packages 
2025-10-16 13:13:40 <Habbie> yeah
2025-10-16 13:13:47 <Habbie> assuming, of course, that you don't care which implementation you get
2025-10-16 13:15:39 <eletrotupi> oh, there are no packages for vi
2025-10-16 13:16:01 <eletrotupi> I think the author of the package means it'll just require an EDITOR
2025-10-16 13:16:03 <eletrotupi> whatever that is
2025-10-16 13:16:32 <eletrotupi> >The dependencies are a POSIX system
2025-10-16 13:16:46 <Habbie> ah
2025-10-16 13:17:06 <Habbie> note that many minimal OS installs are not full POSIX systems
2025-10-16 13:17:10 <Habbie> (i don't know if Alpine always is)
2025-10-16 13:17:27 <eletrotupi> yeah, I'm aware
2025-10-16 13:30:56 <skarnet> bb always provides a vi, there's also a vim package if you want more functionality
2025-10-16 14:10:36 <Saijin_Naib[m]> @skarnet what package for busybox vim? 
2025-10-16 14:55:52 <skarnet> "busybox vim" is not a thing :D it's either busybox vi, called with "vi", and you have it by default because it's provided by busybox; or vim, from the vim package.
2025-10-16 15:45:41 <Sertonix[m]> Gonna work on busybox neovim :)
2025-10-16 15:47:25 <ncopa> lol
2025-10-16 15:47:50 <ncopa> i actually considered add a busybox lua applet
2025-10-16 15:48:13 <ncopa> a decade ago or so
2025-10-16 16:17:54 <iggy> what about uutils?
2025-10-16 16:18:15 <iggy> speaking of which, when is someone going to rewrite busybox in rust?
2025-10-16 16:25:48 <f_>  15:30 <skarnet> bb always provides a vi, there's also a vim package if you want more functionality
2025-10-16 16:25:52 <f_> Not fully implemented
2025-10-16 16:28:20 <Saijin_Naib[m]> skarnetI totally misread what you wrote haha
2025-10-16 18:00:30 <ikke> gitlab is being upgraded and briefly unavailable
2025-10-16 18:05:43 <ikke> Done
2025-10-16 18:18:43 <Biswa96[m]> I can not delete a repository. It shows "500: We're sorry, something went wrong on our end" Request ID: 01K7Q3VA48NS84PFWVMTYRQZRY
2025-10-16 18:20:51 <ikke> Biswa96[m]: Should be fixed in a minute
2025-10-16 18:20:56 <ikke> can you try again?
2025-10-16 18:23:59 <Biswa96[m]> it worked. big sus. how do you know always what happens in the gitlab server :-)
2025-10-16 18:25:37 <ikke> I ran into an issue which had the same underlying cause :)
2025-10-16 20:32:12 <ncopa> libyuv has a checksum error
2025-10-16 20:43:32 <ikke> Seems to be metadata only
2025-10-16 21:19:08 <omni> iggy: uuitils is pretty big, as rust binaries often seem to be, sometimes you want something tiny like busybox (or toybox)
2025-10-16 21:23:15 <Habbie> i wonder if one day we'll see a turn back to dynamic linking for the post-C languages like Rust and Go :)
2025-10-16 21:25:53 <omni> we build dynamically linked rust and go binaries
2025-10-16 21:37:46 <Habbie> does that work for the actual rust/go deps?
2025-10-16 21:50:48 <omni> oh, I see, we do *some* linking..
2025-10-16 21:55:53 <omni> there's rustybox, btw, but that hasn't moved in a while
2025-10-16 22:41:56 <Arnavion> You can dynamically link Rust binaries, but the ABI is unstable, so you have to make sure to rebuild the world when any one lib changes. I believe that's what Android does for its Rust userspace
2025-10-17 05:55:03 <ncopa> sigh... we need to do something about libuv. the checksum changes for every download
2025-10-17 05:56:11 <ncopa> sorry libyuv
2025-10-17 06:51:56 <ncopa> git tests fails. dunno why. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91632
2025-10-17 06:53:10 <sam_> is it the ssh test ncopa?
2025-10-17 06:53:28 <sam_> can you link it?
2025-10-17 06:56:48 <lotheac> looks to me like the builds are succeeding for that MR
2025-10-17 06:59:06 <ncopa> interesting
2025-10-17 06:59:24 <ncopa> # passed all remaining 215 test(s)
2025-10-17 06:59:24 <ncopa> 1..216
2025-10-17 06:59:24 <ncopa> make: *** [Makefile:63: test] Error 2
2025-10-17 06:59:24 <ncopa> make[1]: Leaving directory '/home/buildozer/aports/main/git/src/git-2.51.0/t'
2025-10-17 06:59:24 <ncopa> make: Leaving directory '/home/buildozer/aports/main/git/src/git-2.51.0/t'
2025-10-17 06:59:26 <ncopa> >>> ERROR: git: check failed
2025-10-17 06:59:29 <ncopa> happens on all builderes
2025-10-17 06:59:33 <ncopa> 3.23 builders
2025-10-17 07:04:53 <ncopa> maybe it only happens with APORTS_BOOTSTRAP=1
2025-10-17 07:05:04 <lotheac> 2.51.0 vs 2.51.1 maybe? i just tried locally on aarch64 and abuild 2.51.0 did fail tests for me too
2025-10-17 07:05:18 <ncopa> maybe
2025-10-17 07:13:55 <lotheac> or maybe not, since 2.51.1 failed on builders too
2025-10-17 07:14:35 <ncopa> apparently the tests passed on s390x
2025-10-17 07:14:39 <ncopa> as the only arch
2025-10-17 07:16:15 <lotheac> make[1]: *** [Makefile:82: t7528-signed-commit-ssh.sh] Error 1
2025-10-17 07:16:57 <sam_> ok, yeah, so the ssh test
2025-10-17 07:17:12 <sam_> i'm seeing that as well in gentoo, i've assumed it's new openssh as it's the only thing which changed (old git fails now too)
2025-10-17 07:17:16 <sam_> i haven't debugged it yet
2025-10-17 07:17:33 <ncopa> sounds like the issue at hand
2025-10-17 07:20:46 <ncopa> build-3-23-s390x is up and running
2025-10-17 07:23:21 <lotheac> unix_listener_tmp: path "/home/lotheac/src/aports/main/git/src/git-2.51.1/t/trash directory.t7528-signed-commit-ssh/.ssh/agent/s.90LLkt7juY.agent.8WYaxsitP2" too long for Unix domain socket
2025-10-17 07:23:28 <lotheac> so... this https://lore.kernel.org/all/4e2952e512afc780b621d2c153b3e6e4eb7ed89a.camel@xry111.site/
2025-10-17 07:29:57 <lotheac> although there is also this error: "sh: you need to specify whom to kill" which i guess is because eval $(ssh-agent) is not setting SSH_AGENT_PID (maybe it was on earlier ssh?)
2025-10-17 07:30:40 <lotheac> https://termbin.com/zdpn full(er) log of ./t7528-signed-commit-ssh.sh -v
2025-10-17 07:31:56 <lotheac> don't have time right now to check my hypothesis but maybe that unix socket length issue was always there, and the test was passing regardless - this would match what https://lore.kernel.org/all/20251017070912.GA4068463@coredump.intra.peff.net/ is saying
2025-10-17 07:32:28 <lotheac> so just a wild guess, but maybe the only thing that changed is SSH_AGENT_PID not getting set and the "kill" error failing the test, dunno
2025-10-17 07:33:06 <lotheac> looks hairy anyway :)
2025-10-17 07:33:27 <sam_> thank you!
2025-10-17 07:34:08 <ncopa> thanks!
2025-10-17 07:34:16 <ncopa> need to step out for a few hours
2025-10-17 07:34:25 <ncopa> feel free to push any fix/workaround
2025-10-17 07:35:17 <lotheac> probably won't have time in the next few hours
2025-10-17 07:38:28 <lotheac> and i am guessing this is related to why it's happening now: https://www.openssh.com/txt/release-10.1 "ssh-agent(1), sshd(8): move agent listener sockets from /tmp to under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets in sshd(8)."
2025-10-17 07:49:46 <ncopa> Makes sense
2025-10-17 08:00:38 <ncopa>  -T makes ssh-agent put the socket back in /tmp.
2025-10-17 08:01:14 <ncopa> maybe we can add that to the test for now
2025-10-17 08:02:25 <ncopa> similar to the diff here: https://lore.kernel.org/all/20251017070912.GA4068463@coredump.intra.peff.net/
2025-10-17 09:47:04 <lotheac> looks like celeste did just that, already. i think i'll send a reply to that git mailing list thread
2025-10-17 09:54:35 <lotheac> did that
2025-10-17 10:58:33 <ncopa> Thanks, both of you
2025-10-17 12:30:52 <ncopa> 3.23 builders are up!
2025-10-17 12:31:04 <ncopa> we are now effectively in a feature freeze
2025-10-17 12:33:05 <ikke> ncopa: what did you do for libyub?
2025-10-17 12:33:09 <ikke> libyuv*
2025-10-17 12:33:57 <ncopa> nothing
2025-10-17 12:34:13 <ncopa> i figured it wasnt needed for bootstrapping the builders
2025-10-17 12:34:18 <ikke> ah ok
2025-10-17 12:34:28 <ikke> But we still need to fix it then
2025-10-17 12:34:48 <ncopa> the solution was to set APORTS_BOOTSTRAP when calculating dependencies
2025-10-17 12:34:53 <ncopa> not only when building
2025-10-17 12:34:55 <ncopa> yes
2025-10-17 12:35:09 <ncopa> i tried to update the checksum, but it changes every download
2025-10-17 12:35:26 <ikke> yeah
2025-10-17 12:35:32 <ncopa> so we need to make a copy to archive.a.o or similar
2025-10-17 12:35:51 <ncopa> but at least the builders are running now
2025-10-17 12:35:57 <ncopa> which was my priority
2025-10-17 12:36:03 <ikke> yup, understood
2025-10-17 12:37:33 <ncopa> i think it would be good to keep an eye on build-3-23-riscv64, and prioritize that it is progressing
2025-10-17 12:37:42 <ncopa> its the bottleneck for the release
2025-10-17 12:38:39 <ikke> right, but the constant builder retrying currently in place may drown out issues
2025-10-17 13:57:04 <ikke> Ariadne: Are you still planning to provide the macos-shell runner again? Has been offline for more than 6 months
2025-10-17 16:30:53 <Ariadne> yes
2025-10-17 17:16:31 <Ariadne> ikke: i need some manual intervention on the builders: temporarily delete /lib/apk/commit_hooks.d/usr_merge_nag.sh
2025-10-17 17:16:46 <ikke> ok
2025-10-17 17:17:08 <Ariadne> there is a hardcoded path that we missed for commit hooks :(
2025-10-17 17:52:30 <Ariadne> i reworked it to use the provided directory fd, which fixes running hooks from /lib/apk
2025-10-17 18:24:53 <ikke> There's a dependency loop between freebidi and muon
2025-10-17 18:28:58 <Sertonix[m]> ikke: I forgot to follow up on my comment: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91106#note_547447
2025-10-17 18:33:12 <Sertonix[m]> I wanted to do something like https://gitlab.alpinelinux.org/sertonix/aports/-/commit/7b40919bc59b30c6311a44d515a8ad09b502f1a5 (the patch is a bit broken since the checkdepends line should have been removed as well)
2025-10-17 19:18:09 <ikke> Sertonix[m]: would you mind making an MR for that?
2025-10-18 08:17:36 <ncopa> i wonder if we can delete perl-exporter. appears to be bundled with perl since 5.8.3.
2025-10-18 08:58:37 <Biswa96[m]> /lib/modules-load.d were moved to /usr/lib/modules-load.d. but some are also in /etc/modules-load.d. should those be moved to /usr/lib ?
2025-10-18 10:11:03 <qaqland> could I download uncomplete job files from !91692, all work well on my local side
2025-10-18 10:52:48 <ikke> ncopa: amavis builds without it
2025-10-18 10:52:54 <ikke> So I think so
2025-10-18 10:53:23 <ikke> although, no checks, so no idea if it's a runtime dep
2025-10-18 13:35:23 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/758b135ca9cff12726cf15fa7349ce40d42b18dc breaks zfs
2025-10-18 13:35:47 <ikke> zfs includes arch binary files in the udev subpkg
2025-10-18 13:55:19 <ikke> set the arch to all for that subpackage
2025-10-18 14:16:33 <M136258[m]> Get in touch with this platform for greatness you’ll definitely thank me later 
2025-10-18 14:16:33 <M136258[m]> Get in touch with this platform for greatness you’ll definitely thank me later 
2025-10-18 14:16:33 <M136258[m]> ℹ️❤️.   
2025-10-18 14:16:33 <M136258[m]> https://t.me/+pa-CiKYv9-5lNWM8
2025-10-18 14:16:33 <M136258[m]> ℹ️❤️.   
2025-10-18 14:16:34 <M136258[m]> https://t.me/+pa-CiKYv9-5lNWM8
2025-10-18 15:45:00 <knuxify> could someone remove me from teams/gnome?
2025-10-18 15:59:58 <ncopa> knuxify: can you please create an issue for infra? https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues
2025-10-18 16:02:32 <knuxify> ncopa: done, https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10859
2025-10-18 16:06:15 <f_> omni: do you mind if I take over maintainership of testing/meli and move it to community?
2025-10-18 16:08:37 <f_> it would be one package less to have to look after for you ^^
2025-10-18 16:14:15 <ncopa> I need help from someone who can help me get this over the finish line: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87303
2025-10-18 16:17:45 <ikke> knuxify: I was already wondering why it tried to add you back 
2025-10-18 16:28:20 <eforge> Hello, I created a new package merge request here -> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/89964 and I received a stale bot warning.
2025-10-18 16:28:36 <eforge> I'm not sure what I need to do to move the merge request forward?
2025-10-18 16:31:10 <f_> You need to wait :)
2025-10-18 16:31:35 <f_> the folks with merging perms are oftentimes extremely busy and there's a whole lot of MRs that get opened everyday so it's hard to keep up with all of them
2025-10-18 16:33:05 <eforge> OK, thanks.  That's what I suspected, but the bot message made it sound like I needed to do something or the MR would be deleted.
2025-10-18 16:33:58 <f_> eforge: in the meantime I sent some review comments
2025-10-18 16:36:29 <eforge> Thank you again.  I just saw your comments and will fix those.
2025-10-18 16:53:10 <f_> Yw!
2025-10-18 17:10:35 <caskd> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91709 this is important for merge-usr
2025-10-18 17:12:38 <caskd> i freaked out when execlineb was not working for me anymore ~.~
2025-10-18 18:28:27 <skarnet> I'm sorry, what?
2025-10-18 18:29:37 <skarnet> caskd: what happened? the scripts worked for me when I tested them across merge-usr
2025-10-18 18:30:34 <caskd> well, it's a problem when it checks if already usr-merged because merge-usr symlinks bin/ -> usr/bin
2025-10-18 18:30:48 <caskd> and the check is for "/usr/bin" not "usr/bin"
2025-10-18 18:30:50 <caskd> :P
2025-10-18 18:30:57 <caskd> so it overwrites the binary
2025-10-18 18:31:00 <caskd> with the force
2025-10-18 18:31:10 <caskd> or the other symlink more exactly
2025-10-18 18:31:16 <skarnet> ooooh
2025-10-18 18:31:17 <skarnet> I see
2025-10-18 18:31:25 <caskd> yeah
2025-10-18 18:31:45 <skarnet> sure, use realpath instead
2025-10-18 18:32:15 <skarnet> I generally shy away from realpath because I like the possibility of having posix directories be symlinks to places like /mnt/something/usr
2025-10-18 18:32:23 <skarnet> but I guess no Alpine installation uses that
2025-10-18 18:32:41 <caskd> well, one could realpath both
2025-10-18 18:32:44 <caskd> and compare then
2025-10-18 18:32:45 <caskd> :P
2025-10-18 18:33:14 <caskd> but there is a simpler approach recommended by Sertonix[m] i used
2025-10-18 18:33:19 <skarnet> no
2025-10-18 18:33:22 <skarnet> that one's not good
2025-10-18 18:33:24 <caskd> why?
2025-10-18 18:34:03 <skarnet> because the test will never fail
2025-10-18 18:34:23 <skarnet> there is always a /bin/execlineb
2025-10-18 18:34:40 <skarnet> that's the point, the link exists even before usrmerge
2025-10-18 18:35:10 <skarnet> it's just handled by execline before the merge, and by the distro after the merge
2025-10-18 18:35:25 <caskd> so, realpath both?
2025-10-18 18:35:38 <skarnet> or readlink and compare to usr/bin
2025-10-18 18:35:54 <skarnet> if that's the guaranteed setup after merge-usr
2025-10-18 18:36:03 <caskd> that i'm not aware
2025-10-18 18:36:11 <caskd> but it's the current behaviour
2025-10-18 18:36:52 <skarnet> ask Pablo, it should be guaranteed everywhere
2025-10-18 18:37:03 <skarnet> I prefer that to realpath tbh
2025-10-18 18:50:55 <skarnet> I'm pretty upset that it broke for you tbh, it worked for me and I was convinced it was working overall
2025-10-18 18:51:27 <caskd> welp
2025-10-18 18:51:35 <caskd> good i caught it before it caused any chaos
2025-10-18 18:51:36 <caskd> :P
2025-10-18 18:51:52 <skarnet> in theory I should have installed a new VM and tested all the possible configs
2025-10-18 18:52:16 <skarnet> but merge-usr wasn't even ready when I wrote these scripts :P
2025-10-18 18:52:28 <skarnet> yeah, thank you for early testing
2025-10-18 18:52:31 <caskd> np
2025-10-18 18:52:37 <caskd> that's why i'm on edge
2025-10-18 18:52:41 <caskd> :)
2025-10-18 18:52:51 <skarnet> I'm on edge too
2025-10-18 18:52:54 <skarnet> very on edge
2025-10-18 18:53:27 <caskd> better catch these before they land on stable and they break my hypervisors (i would be very grumpy if that happened)
2025-10-18 18:53:51 <Sertonix[m]> skarnet: I don't understand why never failing is bad?
2025-10-18 18:56:53 <skarnet> well it's not exactly never failing
2025-10-18 18:56:54 <skarnet> it's just
2025-10-18 18:57:29 <skarnet> I wanted to test whether the merge has been done or not
2025-10-18 18:57:39 <skarnet> with the test you cannot know that
2025-10-18 18:57:51 <skarnet> with the executability of /bin/execlineb, I mean
2025-10-18 18:58:23 <skarnet> so yeah it probably works for this case, actually
2025-10-18 18:58:41 <Sertonix[m]> I think what we actually want is to make sure that both /bin/execlineb and /usr/bin/execlineb works. Don't need to care about anything else
2025-10-18 18:59:18 <skarnet> not quite
2025-10-18 18:59:36 <skarnet> previous versions installed the binary in /bin and the symlink in /usr/bin
2025-10-18 18:59:59 <skarnet> there is an upgrade path that ends up in a symlink loop with no binary at all
2025-10-18 19:00:09 <skarnet> if what you test is [ -e /bin/execlineb ]  :)
2025-10-18 19:01:12 <Sertonix[m]> I don't think so. First execline upgrade then merge-usr works obviously. The other way around the merge-usr script should choose the binary over the symlink and the install script is a noop
2025-10-18 19:01:45 <skarnet> maybe
2025-10-18 19:02:04 <skarnet> again, when I wrote it the script didn't exist yet
2025-10-18 19:02:24 <skarnet> readlink is safe and works all the time (except when I botch the target of the link)
2025-10-18 19:04:54 <Sertonix[m]> Except when one needs a custom migration script and uses absolute symlinks instead of relative ones :)
2025-10-18 19:05:10 <skarnet> exactly ^^"
2025-10-18 20:03:12 <f_> I'm sure I asked about this before, but how can I fix this error when running abuild rootbld?
2025-10-18 20:03:32 <f_> ln: /home/fun/Documents/code/alpine/aports/testing/meli/src/meli-0.8.12.tar.gz: File exists
2025-10-18 20:03:34 <f_> >>> ERROR: meli: symlinksrc failed
2025-10-18 20:03:37 <f_> >>> ERROR: meli: rootbld failed
2025-10-18 20:03:39 <f_> >>> meli: Cleaning up build chroot
2025-10-18 21:13:13 <ncopa> The gcc issue when compiling zsh https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122012
2025-10-18 21:40:13 <Sertonix[m]> f_: abuild uses ln -f so such an error should be impossible. Do you have more information about the issue?
2025-10-18 21:44:29 <f_> not really ... :(
2025-10-18 22:01:34 <mio> ncopa: probably the same patch as https://gcc.gnu.org/pipermail/gcc-patches/2025-October/697848.html via https://gitlab.alpinelinux.org/alpine/aports/-/issues/17416#note_538821
2025-10-18 22:02:17 <mio> upstream will backport it shortly, not sure if you wanted to wait
2025-10-18 23:30:37 <AdeOpe[m]> ☑️ Cashapp Service Available 7/24... (full message at <https://matrix.org/oftc/media/v1/media/download/Ae9KQujOLZ6B-vJaRbbl_Tu967rCbOs0BXdu-ob9m2rgCh4aZQfjgwKvXbnk-ERvwZRKHMPqABUfMLzNOFx77iBCeaQcIxugAG1hdHJpeC5vcmcvbHZPSlBHd1dRUWxJZGxTdmZDcUlxT1Rv>)
2025-10-19 02:55:19 <Noisytoot1> amk: could you please have a look at/approve !90679?
2025-10-19 02:56:43 <Noisytoot1> !90679
2025-10-19 02:56:59 <Noisytoot1> is the bot dead? anyway, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90679
2025-10-19 07:46:53 <ncopa> mio: it applies clean, and it appears to solve the issue. I'm backporting it. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91736
2025-10-19 08:29:17 <amk> Noisytoot1: sorry i thought id approved that already, lgtm
2025-10-19 08:35:33 <ikke> Noisytoot1: Still need to bump pkgrel
2025-10-19 10:50:47 <ikke> sadly zsh is still failing
2025-10-19 12:48:48 <ncopa> i gcc is no upgraded until main completes
2025-10-19 12:49:49 <ncopa> so we have to manually upgrade gcc, which I have done now on all 3.23 except riscv64 and ppc64le
2025-10-19 13:15:58 <ncopa> py3-pexpect deadklocks occationally
2025-10-19 13:16:14 <ncopa> ppc64le was stuck. i rebooted it
2025-10-19 13:20:59 <mio> x86_64 could use a go bootstrap?
2025-10-19 18:12:05 <WhyNotHugo> !87912 was stale due to zsh breakage with gcc15 but is now ready for review/merge
2025-10-19 18:12:47 <ikke> !87912
2025-10-19 18:59:35 <ikke> WhyNotHugo: something is failing in the split functions 
2025-10-19 19:08:15 <WhyNotHugo> Fixed. Forgot to stage some changes.
2025-10-19 19:10:54 <ikke> sourceforge is not cooporating
2025-10-19 20:17:28 <ikke> annoying, abuild fetch now also runs verify
2025-10-19 20:21:09 <ikke> This makes it a lot more cumbersom to verify what changed in archives
2025-10-19 20:41:19 <buinb> I had a problematic upgrade, because disk was full
2025-10-19 20:41:34 <buinb> I was then able to make some space, upgrade again, and apk-fix tells everything's fine
2025-10-19 20:42:01 <buinb> Can I trust this, as in first upgraded packages should be consistent?
2025-10-19 22:03:31 <Sertonix[m]> ikke: I wanted to make abuild fetch less of a pit fall. Diffing archives is something which should be easily doable. I couldn't really figure out a way to do it even before the change so if you would mind to share what you do I could try to make it work again or figure out some other way that is easy enough.
2025-10-19 22:07:46 <Sertonix[m]> buinb: I think it would be better to check something like apk audit --full (not everything listed there is an issue)
2025-10-19 22:15:47 <buinb> Well do that, thanks :)
2025-10-19 22:15:53 <buinb> s/Well/Will/
2025-10-19 22:27:04 <buinb> I have ~400 “Added” files
2025-10-19 22:27:54 <buinb> I'm not sure what that means though, documentation just says “The changes detected are: A   File added”
2025-10-19 22:28:15 <buinb> As in it's not from a package and I can remove them safely?
2025-10-19 22:35:54 <buinb> $ doas apk fix busybox
2025-10-19 22:35:57 <buinb> And I get a bunch of
2025-10-19 22:35:58 <buinb> busybox-1.37.0-r24.post-upgrade: rm: can't remove 'usr/sbin/pivot_root': No such file or directory
2025-10-19 22:36:13 <buinb> Though it's on disk
2025-10-19 22:37:15 <buinb> $ ls -l /usr/sbin/pivot_root
2025-10-19 22:37:15 <buinb> lrwxrwxrwx    1 root     root            12 Oct 20 00:36 /usr/sbin/pivot_root -> /bin/busybox
2025-10-19 22:37:33 <buinb> oops, looks like the merge-usr script didn't do a full job
2025-10-19 22:37:46 <buinb> It didn't give any error though
2025-10-19 22:39:07 <buinb> INFO: Already a symlink: '/bin'
2025-10-19 22:39:53 <buinb> It looks like it didn't fix the symlinks correctly, but doesn't detect it either :/
2025-10-19 22:41:33 <buinb> $ apk info -W /usr/bin/rc-status
2025-10-19 22:41:33 <buinb> ERROR: /usr/bin/rc-status: Could not find owner package
2025-10-19 22:41:42 <buinb> :/
2025-10-19 22:41:48 <buinb> wth is happenning
2025-10-19 22:43:01 <buinb> I reinstalled openrc with apkfix, still the same problem
2025-10-19 22:46:51 <buinb> How can I fix that?
2025-10-19 23:29:14 <Sertonix[m]> apk is using the paths as they are found in the package so I think it's apk info -W /bin/rc-status
2025-10-19 23:34:42 <Sertonix[m]> buinb: Can you create an issue for the busybox post-upgrade script double counting symlink which can lead to the rm error you have seen (and ideally ping me)
2025-10-20 08:49:20 <fabled> pabloyoyoista: I was looking at the merge-usr script, and seems I can rewrite it in C in small enough time to do it if it helps the migration. I should be able to schedule the time for it by latest early next month (after next week)
2025-10-20 10:06:12 <buinb> Sertonix[m], seems like something's not consistant here, either some packages need to be reworked, or apk-audit has to be fixed to deal with the removal of /bin,/sbin,/lib
2025-10-20 10:06:36 <buinb> fabled, out of curiosity, what for?
2025-10-20 10:06:52 <buinb> (sorry if I missed some previous conversation here)
2025-10-20 10:08:33 <fabled> buinb: for context, we had a conference call few hours ago where we discussed some options on how to make "apk upgrade" work, and one problem was that the merge-usr is split to shell+C. one option is to rewrite it in C completely to allow it running without fork/exec for tooling.
2025-10-20 10:08:57 <buinb> Thank you :)
2025-10-20 10:09:46 <fabled> buinb: as related note we are looking into making the merge-usr be runabble as part of pre-upgrade script directly from "apk upgrade". the most viable option currently looks like adding of apk index level pre/post-commit hooks, see https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11148
2025-10-20 10:12:39 <buinb> I have no idea what I'm talking about, but apk is already able to upgrade itself separated from the rest of the packages when needed
2025-10-20 10:12:47 <buinb> Is that something that's currently not usable for other packages?
2025-10-20 10:13:06 <buinb> Like having the same for alpine-base, for pushing the usr-merge
2025-10-20 10:13:21 <buinb> s/alpine-base/&layout/
2025-10-20 10:13:56 <fabled> yes and no. "apk-tools" is handled specially in that regard. but the idea with index level hooks is that they could abort the upgrade if the migration tool says its not safe
2025-10-20 10:16:56 <fabled> and in general, there has been an occasional need for the index hook. at least I would have needed it in few instances for my managed fleet.
2025-10-20 10:17:28 <buinb> Right, so taking the opportunity to get that generic feature in :)
2025-10-20 10:17:31 <buinb> Good luck!
2025-10-20 10:53:11 <WhyNotHugo> !88742 not stale; it's ready to merge
2025-10-20 12:47:25 <andar1an> Hey all, this has happened to me on 2 machines now, so I created an issue in case others are experiencing: https://gitlab.alpinelinux.org/alpine/aports/-/issues?show=eyJpaWQiOiIxNzY0MSIsImZ1bGxfcGF0aCI6ImFscGluZS9hcG9ydHMiLCJpZCI6MzU1MjYxfQ%3D%3D
2025-10-20 12:48:02 <andar1an> I have had 2 machines now where symlinks break when uutils-coreutils is installed, post usr-merge, and run an apk upgrade 
2025-10-20 12:48:31 <andar1an> I am less believing that it is something specific to me at the moment, and it may affect others too.
2025-10-20 12:48:48 <andar1an> I think it is pretty severe as if you restart after this, system won't boot 
2025-10-20 12:49:29 <andar1an> if you see lddtree fail, uninstalling uutils-coreutils and rebuilding initfs corrects issue immediately 
2025-10-20 12:49:45 <andar1an> but if you don't do this and restart, it is a pain in the bit
2025-10-20 12:49:48 <andar1an> *butt
2025-10-20 12:51:04 <andar1an> I honestly haven't dug into it yet, I just know this didn't happen pre usr-merge, so am making an initial assumption 
2025-10-20 12:55:57 <andar1an> I am not sure if /lib/modules was always a symlink to /usr/lib/modules either off top of head
2025-10-20 12:56:51 <andar1an> i don't know how that would affect busybox symlinks though, I haven't read lddtree yet
2025-10-20 13:09:35 <andar1an> gonna jump off irc now, but if this is relevant link to issue is there. I can try to troubleshoot more on Wed or Sunday if applicable
2025-10-20 13:29:39 <Biswa96[m]> may I ask for some reviews in my MRs? those are just trivial changes https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/?sort=created_date&state=opened&author_username=Biswa96&first_page_size=20
2025-10-20 13:58:17 <andypost[m]> I need to move php82 to testing from community before 3.23 release but there's few packages still depend on it, is there ideas how to deal with all of them ? bereos and baculum + a few https://pkgs.alpinelinux.org/package/edge/community/x86_64/php82
2025-10-20 14:24:49 <pabloyoyoista> fabled: that sounds pretty positive! Thanks a lot for that, would be good to see such a solution if it helps considerably combined with the pre-commit from the index
2025-10-20 14:32:59 <achill> andypost[m]: id try to use a newer php and try to build them -> if they fail, notify maintainers -> if they dont give response or dont have the time to fix it -> move it to testing aswell
2025-10-20 15:25:21 <bl4ckb0ne> is there a way to downgrade npm for a specific package? jellyfin-web has issue with the npm version installed
2025-10-20 15:25:43 <bl4ckb0ne> we have 11.6.1 but the requirement is `"npm":">=9.6.4 <11.0.0"`
2025-10-20 15:29:26 <ikke> You'd have to create a separate npm package for that version
2025-10-20 15:33:29 <bl4ckb0ne> hm, seems annoying just for jellyfin-web
2025-10-20 15:33:35 <bl4ckb0ne> maybe a I can bump that limit
2025-10-20 15:36:50 <achill> yeah these limits are very often artifical
2025-10-20 15:37:07 <bl4ckb0ne> is there a flag to ignore it?
2025-10-20 15:37:19 <achill> not that i know of, i'd just patch it out
2025-10-20 16:27:23 <ptrc> huh, seems like sourcehut changed some tarball mechanics?
2025-10-20 16:28:21 <ptrc> https://ptrc.gay/oftJxQtC
2025-10-20 16:28:37 <ptrc> ( uses weird unicode blocks, best viewed in a terminal )
2025-10-20 16:32:08 <ptrc> cc: ahills, since it seems to be your package
2025-10-20 16:35:05 <ptrc> also, unrelatedly, community/hermes seems to have been unmaintained since 2016, with only random drive-by fixes by other contributors, and now the upstream has once again gone down
2025-10-20 16:35:20 <ahills> what is actually different in the before and after there?
2025-10-20 16:35:45 <ahills> ah, the "v" prefix on the version number
2025-10-20 16:36:15 <ptrc> yes
2025-10-20 16:36:18 <ptrc> and that's the only change
2025-10-20 16:36:57 <ptrc> we can just invalidate the cached tarball by putting a `-1` in the filename ( e.g. `$pkgname-$pkgver-1.tar.gz::[url`
2025-10-20 16:37:17 <ptrc> in this case, that is
2025-10-20 16:37:38 <ptrc> but it raises the question of whether anything else from srht is broken in the same way
2025-10-20 16:38:37 <ptrc> ah, wait, it was already updated in 3b4e9bb88e627e3892dd44a7c2b96e1834267421
2025-10-20 16:38:49 <ptrc> my local branch was ever so slightly out of date
2025-10-20 16:39:42 <ptrc> and it was actually my mistake, as i switched the source from the removed github repo and forgot to check whether they changed ;w;
2025-10-20 16:40:04 <ptrc> my bad
2025-10-20 16:40:59 <ahills> I can submit aports patches later
2025-10-20 16:48:30 <ptrc> nah, all's good now
2025-10-20 17:21:11 <ahills> thank you for taking care of that :)
2025-10-20 17:22:09 <ahills> you should add yourself to contributors, you've done more work than me on the package at this point
2025-10-20 17:38:33 <ahills> it looks like 2ff62bbb9f7b2c82a826d7b159c1bc482aa8f0bd moved it to community back in 3.5, how far back is reasonable for backports for a change like this? (project URL change)
2025-10-20 17:39:30 <ikke> I'd keep it to supported releases
2025-10-20 17:39:53 <ikke> which, for community, is only the latest stable release
2025-10-20 17:40:47 <ahills> would you reject patches for 3.19-stable – 3.21-stable?
2025-10-20 17:42:12 <ikke> We are currently focusing on releasing alpine 3.23, so it would be appreciated not to
2025-10-20 17:42:44 <ahills> ack, thanks!
2025-10-20 18:06:14 <socksinspace> https://tpaste.us/XvoB I've been staring at this for ages now, and it just doesn't make any sense to me. Happens during the bootstrap for all architectures that i have tried so far.
2025-10-20 18:07:41 <WhyNotHugo> How is the builder's environment set up? I'd like to reproduce it to understand failures for !88742
2025-10-20 18:07:52 <WhyNotHugo> both CI and rootbld build fine, and this is very sandbox-specific.
2025-10-20 18:08:14 <ikke> WhyNotHugo: an lxc container, executed through mqtt-exec
2025-10-20 18:11:31 <ikke> WhyNotHugo: Apparently they disable a bunch of tests in gitlab
2025-10-20 18:11:37 <ikke>  @unittest.skipIf("GITLAB_CI" in os.environ, "Test fails on CI environment")
2025-10-20 18:15:49 <WhyNotHugo> ikke: yeah, this tests tinkering with priviledges. Some tests fail in CI, others in rootbld. It depends on the details of the exact sandbox.
2025-10-20 18:16:02 <WhyNotHugo> I'll try setting up LXC and add some quivalent skipIf.
2025-10-20 18:16:20 <ikke> I ran it in my container, and the seccomp test failed there
2025-10-20 18:16:51 <ikke> But that's part of your answer, the builders do not set GITLAB_CI, so it runs more tests
2025-10-20 18:16:58 <WhyNotHugo> It's really curious how different tests fails in different sandboxes — it implies that they block quite different capabilities/priviledges/syscalls.
2025-10-20 18:17:32 <ikke> docker vs lxc, each with their own profiles
2025-10-20 18:19:03 <ikke> check /usr/share/lxc/config/alpine.common.conf and /usr/share/lxc/config/common.conf
2025-10-20 18:20:47 <ikke> The builders also have:
2025-10-20 18:20:49 <ikke> lxc.cap.drop = sys_admin
2025-10-20 18:20:52 <ikke> lxc.cap.drop = sys_ptrace
2025-10-20 18:20:55 <ikke> lxc.cap.drop = setpcap
2025-10-20 18:44:51 <ahills> there is a dramatic performance difference between riscv64 shared runners nld-bld-2 and lambda.kdaudt.alpinelinux.org…
2025-10-20 18:46:10 <ikke> Yes
2025-10-20 18:46:26 <ikke> milk-v pioneer versus banapi f3
2025-10-20 18:50:20 <ahills> ah yes, quite a big leap
2025-10-20 18:52:52 <ikke> With a bit of luck, we should have some rv64 VMs that can provide CI
2025-10-20 18:52:59 <ikke> soon*
2025-10-20 18:53:08 <ahills> 🍀
2025-10-20 18:53:43 <achill> 🍀
2025-10-20 20:57:59 <vkrishn> should be fun to read and experiment, https://wiki.insteps.net/AlpineLinux/Boot-dance-everything-in-usr-folder
2025-10-21 05:00:20 <ikke> py3-cachecontrol keeps hanging, can reproduce it locally
2025-10-21 05:01:04 <ikke> Seems like a deadlock
2025-10-21 05:07:28 <ikke> Traceback (most recent call last):
2025-10-21 05:07:30 <ikke>   File "/usr/lib/python3.12/threading.py", line 1624, in _shutdown
2025-10-21 05:07:32 <ikke>     lock.acquire()
2025-10-21 07:38:25 <ncopa> i have verified that 3.23 builders did not have ocaml-4 without this fix: https://git.alpinelinux.org/aports/commit/?id=0175273b6aede5862e87d47bb51e88bf3f9ac3c8
2025-10-21 07:38:33 <ncopa> will restart the builders
2025-10-21 09:45:17 <PatriciaMcCleary[m]> Hey there... (full message at <https://matrix.org/oftc/media/v1/media/download/AVfIulFgoZ5BfD8YuQd23Y1P4mS6neGxh7kTuZYYD_c9egms2mNwFWju0W1k3PkIokcwTKHz7X_D6dhQw_SquJVCeaTkGqtwAG1hdHJpeC5vcmcvTEpvWEx5U2ZTVUdxR3NrVHlYaWFxZFVH>)
2025-10-21 10:08:15 <ncopa> there was an upstream issue for ppc64le elvf2 on rust something. I cannot find it again
2025-10-21 10:08:47 <ncopa> IIRC it was merged upstream, but it does not look like we have backported it
2025-10-21 10:23:07 <PatriciaMcCleary[m]> Are you looking for a way?
WE RISE BY LIFTING OTHERS
This telegram channel Has Changed The Life Of Lives out there. Don't Miss This Great Opportunity, It May Never Be There Again.
Hurry up Join The Winning Teams And Enjoy Yourself
👇👇👇👇👇👇👇👇
2025-10-21 10:23:07 <PatriciaMcCleary[m]> inviting you to join this on tele.. he’s doing a great job 🥰 join with this link below
2025-10-21 10:23:07 <PatriciaMcCleary[m]> Hey there
Are you looking for a way? A telegram game changer is here🥰 be a part of the change while the opportunity still stands!
2025-10-21 10:23:07 <PatriciaMcCleary[m]> https://t.me/+jLJNhUzVTUphODVk
2025-10-21 10:23:07 <PatriciaMcCleary[m]> Join the telegram channel by clicking now
📣🎊❤️
2025-10-21 10:36:00 <achill> ncopa: https://github.com/rust-lang/cc-rs/pull/1596
2025-10-21 10:36:19 <achill> but we have to backport this change basically to every package that fails
2025-10-21 10:36:39 <achill> alternatively we could revert the rust change to expose the suffix
2025-10-21 11:06:49 <ncopa> right. the benefits of rust ecosystem
2025-10-21 11:18:27 <achill> yeah...
2025-10-21 13:10:28 <Biswa96[m]> may I ask for some reviews in my MRs? those are just trivial changes https://gitlab.alpinelinux.org/alpine/aports/-/merge\_requests/?sort=created\_date&state=opened&author\_username=Biswa96&first\_page\_size=20
2025-10-21 15:11:12 <PureTryOut> Wrong link
2025-10-21 18:56:08 <Noisytoot> Biswa96[m]: don't escape the underscores because it relays as-is to IRC and breaks the link
2025-10-21 20:29:16 <dne> would someone like to review/merge? !90070 !91553 !91688
2025-10-21 20:56:17 <tokyovigilante> hi, I tried the /usr merge on a WSL2 system (edge), and got this warning - INFO: Migrating files from '/lib' to '/usr/lib' ERROR: Mountpoint '/lib/modules/6.6.87.2-microsoft-standard-WSL2' is in '/lib', which will be removed. Please unmount or move it before attempting the merge. Is there a fix or workaround?
2025-10-21 21:47:50 <Arnavion> Mount it at /usr/lib/modules/... , unmount it from /lib/modules/... , run the usr-merge, and hope that nothing needs to load a kmod until the /lib -> /usr/lib symlink is created
2025-10-22 02:36:39 <ptrc> btw, what's the plan for KDE on 32-bit x86?
2025-10-22 02:36:54 <ptrc> since qt6-qtwebengine-dev, half of KDE can't really build
2025-10-22 02:40:09 <ptrc> ah no, it's actually been mostly disabled
2025-10-22 02:42:11 <Sheila> ptrc: awilfox has been plotting to make it work for us, but since she has a day job…
2025-10-22 02:42:32 <Sheila> ('us' as in 'Adélie', although I'd be surprised if that work wouldn't be useful to Alpine.)
2025-10-22 02:43:01 <ptrc> 
ACTION nods

2025-10-22 03:17:21 <khem> qt6webengine has chromium inside so 32bit support is going to be rotting over time 
2025-10-22 03:24:16 <khem> IIRC it needed 64-bit Nodejs when I was messing it to build for 32bit, I was on cross-compile env (yocto) so technically it should have been possible to use 64bit build host and nodejs-native from it but it did not work 
2025-10-22 04:21:46 <tokyovigilante> Arnavion: thanks, will give it a go.
2025-10-22 08:42:50 <ptrc> achill: apparently we've got a circular dependency on the jupyter stuff
2025-10-22 08:43:00 <ptrc> jupyter-nbconvert -> py3-jupyterlab_pygments -> jupyterlab -> jupyter-notebook-shim -> jupyter-server -> jupyter-nbconvert
2025-10-22 08:43:06 <achill> ahhh yes, i forgot about that
2025-10-22 08:43:09 <achill> ill look at it
2025-10-22 08:43:12 <ptrc> okie, thanks :3
2025-10-22 08:43:27 <achill> probably just disabling checks on some package because they are mostly checkdepends
2025-10-22 09:30:43 <qaqland> is there a script to batch rebuild package like abump?
2025-10-22 09:32:51 <ikke> apkgrel -a
2025-10-22 09:33:22 <ikke> It only increases the pkgrel though, you still have to rebuild it 
2025-10-22 09:36:16 <qaqland> got it
2025-10-22 09:40:32 <achill> i have something like https://tpaste.us/4vNZ in my .profile, so i can mass commit rebuilds with rebuild_against_dep_commit_repos so:libphonenumber.so.9 "libphonenumber 9.0.11"
2025-10-22 09:41:01 <achill> although it sometimes bumps the pkgrel multiple times, if multiple subpackages depend on the same $1
2025-10-22 09:46:42 <ptrc> that's why there's a `-g` toggle for apkgrel :p
2025-10-22 09:48:45 <achill> ohh true, thats a good one
2025-10-22 09:52:36 <PureTryOut> achill: would be nice to have such kind of scripts in some kind of Alpine development utilities package so everyone can benefit from them and there are solid solutions for common problems like these
2025-10-22 09:53:04 <achill> yeah totally, like in abuild similar to abump and apkgrel
2025-10-22 09:53:39 <achill> i wanted to do a proper monoscript that handles most of aports operations, but thats a lot and didnt start it 🙃
2025-10-22 09:54:20 <qaqland> :)
2025-10-22 09:54:58 <PureTryOut> You can start small and do a single thing, then expand over time or let others help 😉
2025-10-22 10:43:10 <ptrc> tbh i'd contribute as well, i've got some scripts worked out in 
2025-10-22 10:43:18 <ptrc> https://gitlab.alpinelinux.org/ptrcnull/aports-go-tools/
2025-10-22 10:43:21 <ptrc> s/scripts/tools/ i guess
2025-10-22 10:44:22 <ptrc> as well as a more robust version of abump that automatically builds the package in a separate git worktree + commits it
2025-10-22 10:45:02 <ptrc> though for some smaller scripts the code is janky as hell sometimes and i can't be bothered to clean it up and post it
2025-10-22 10:45:46 <ptrc> https://ptrc.gay/RdOraqCp
2025-10-22 10:45:55 <ptrc> also some smaller shell functions
2025-10-22 11:22:39 <kpcyrd> omni: thanks for merging the uutils{,-coreutils} update and backporting to 3.22, I'm using this now to work around a munin<->busybox bug <3
2025-10-22 11:23:17 <kpcyrd> also really cool alpine let's me switch between different coreutils just like that
2025-10-22 12:37:55 <omni> kpcyrd: thanks for the appreciation <3
2025-10-22 13:51:39 <bl4ckb0ne> i wonder if it could be relevant to report the npm upper limit issue to jellyfin-web
2025-10-22 14:19:34 <achill> 🤷 probably worth doing
2025-10-22 14:53:28 <ncopa> I have a `rebuild-since` script that I use: https://tpaste.us/MYq1
2025-10-22 14:54:21 <craftyguy[m]> achill: do you have any suggestions for working around this riscv64 CI timeout in !91891 ? It apparently takes >8hrs to build that branch 😞
2025-10-22 14:56:30 <achill> Yeah it's annoying, just merged it, I'll disable packages if build failures occur on the builders
2025-10-22 15:16:24 <vkrishn> don't know if problem can be dealt in security aware distro like AL, but should be fun to read, https://wiki.insteps.net/Unknown/Social-engineering-simple
2025-10-22 15:18:43 <ikke> "immediately backdoor logs in Alice' computer"
2025-10-22 15:18:58 <ikke> That means the computer was already compromised
2025-10-22 15:19:52 <ikke> The social engineering part only helps to expedite it
2025-10-22 15:20:42 <craftyguy[m]> achill: ok, thank you :)
2025-10-22 15:22:08 <ikke> craftyguy[m]: if it happened to be scheduled on the bananapi f3 runners, then the builders at least should be a bit faster
2025-10-22 15:23:22 <craftyguy[m]> looks like it the CI job was scheduled on: shared-runner pioneer1 (riscv64) JZnuypS7T, system ID: r_TaK2ET0XIXsO
2025-10-22 15:23:41 <ikke> oh
2025-10-22 15:23:55 <vkrishn> but can backdoor login get firefox loging credintials ?
2025-10-22 15:24:16 <vkrishn> immediately?
2025-10-22 15:24:44 <vkrishn> banks have extra layers, like time logouts.. etc
2025-10-22 15:24:48 <ikke> It can probably steal existing sessions, if they exist
2025-10-22 15:25:00 <ikke> Like I said, it expedites the process
2025-10-22 15:25:28 <vkrishn> ok :)
2025-10-22 15:27:13 <vkrishn> thanks for input, improved it a bit
2025-10-22 17:08:49 <bl4ckb0ne> i think jellyfin-ffmpeg is broken on edge
2025-10-22 17:08:58 <bl4ckb0ne> anything transcoded on my server gets a playback error
2025-10-22 17:20:08 <bl4ckb0ne> maybe linked to ffmpeg 8
2025-10-22 18:55:26 <ikke> gitlab will be restarted in 5 minutes for a security update
2025-10-22 19:05:06 <ikke> gitlab is back
2025-10-22 19:10:52 <Habbie> yay
2025-10-22 19:31:48 <lnl> Could someone make some more disk space on the armv7 builder?
2025-10-22 19:43:54 <ikke> you mean CI host
2025-10-22 19:48:44 <ikke> lnl: done
2025-10-22 20:22:44 <lnl> Thanks
2025-10-22 20:47:07 <Habbie> omni, hey, !91968, that's awesome, thanks. i had it on my list for tomorrow :)
2025-10-22 23:14:33 <omni> =)
2025-10-22 23:15:02 <omni> Habbie: I try to look at getting security fixes/upgrade in for stable releases immediately, when I see them, so that they aren't forgotten and missed
2025-10-23 00:49:55 <Noisytoot1> can someone please increase the pkgrel on gwenview and okular? they need to be rebuilt for kde plasma 6.5
2025-10-23 00:56:09 <Noisytoot1> I MR'd it. !91978
2025-10-23 07:53:33 <Habbie> omni, very good
2025-10-23 08:28:10 <caskd> did zsh autocompletions break?
2025-10-23 08:28:42 <caskd> i have this phenomenom on edge on 2 machines now and i'm confused
2025-10-23 08:29:49 <caskd> oh it was just the cache
2025-10-23 19:46:35 <realroot[m]> I am using qtcreator since some time now and for waht I do it's working fine.
2025-10-23 19:46:35 <realroot[m]> what's the process to get it out of testing?
2025-10-23 19:47:19 <realroot[m]> The following packages are no longer available from a repository:
2025-10-23 19:47:19 <realroot[m]> nm-tray ^
2025-10-23 19:47:19 <realroot[m]>   networkmanager-qt5
2025-10-23 20:26:11 <Sertonix[m]> The nm-tray package on alpine edge doesn't depend on networkmanager-qt5 anymore. You need to provide alpine version and used repositories to allow identifying the issue
2025-10-24 06:02:01 <qaqland> just find craftyguy forget to set him/herself as maintainer in 89a6388128b52394ab6 :D
2025-10-24 06:58:46 <realroot[m]> <Sertonix[m]> "The nm-tray package on alpine..." <- sorry i thought it was from testing but it's local rebuild
2025-10-24 06:59:18 <realroot[m]> how do I check if email about F2FS bug has reached upstream?
2025-10-24 06:59:36 <Bella[m]> I AM DOING LEGIT AND TRUSTED TRANSFER and MONEY LOADING & FLIPS TO ALL COUNTRIES And money orders available... (full message at <https://matrix.org/oftc/media/v1/media/download/Af69I5P_551QJqqvL2VRS2Wivx3KqFxLTCN7xyxyfQe2t-FbdLl0ORGo1B3ut6nEpiq1MPd-0IeMMhf9l9wb1_pCeaXR0MxwAG1hdHJpeC5vcmcvZ3lSeXZtVGpFVklxUXhTQlVhd0thSUNt>)
2025-10-24 06:59:45 <realroot[m]> pj
2025-10-24 07:00:19 <realroot[m]> i can see it as sent successfully to linux-f2fs-devel@lists.sourceforge.net
2025-10-24 09:11:36 <pabloyoyoista> Could somebody with merge rights add the /usr-merge milestone to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91806 and the 2 related MRs?
2025-10-24 11:59:47 <ptrc> done for aports, can't do it for the other two repos
2025-10-24 12:01:47 <pabloyoyoista> Thanks!
2025-10-24 12:24:58 <vkrishn> wanted to do this on wiki.a.o, https://wiki.insteps.net/AlpineLinux/True-diskless-boot
2025-10-24 12:25:17 <vkrishn> but would need few dev's yes so i can make a draft,
2025-10-24 12:25:38 <vkrishn> as these methods needs to be supported officially, open to suggestions
2025-10-24 13:52:50 <Sertonix[m]> realroot: you can search in https://lore.kernel.org/linux-f2fs-devel/
2025-10-24 15:07:11 <craftyguy[m]> qaqland ya I forgot :P
2025-10-24 17:17:43 <omni> ikke: remember that wayland/sway lagginess issue I described once?
2025-10-24 17:18:15 <omni> I think I may have solved it with ~/.config/sway/config: output * adaptive_sync off
2025-10-24 20:05:24 <raspbeguy> Hello, can someone merge these MR please? !87884 !90941 !91118 !91337 !91546 !91572 !92117 
2025-10-24 22:15:23 <Saijin_Naib[m]> Shoutout to everyone. In our early testing, Alpine-base docker images for valkey 9.x outperforms debian-base, and same for pgsql
2025-10-24 22:16:40 <Saijin_Naib[m]> Filesize for the images are also a good bit smaller, which rocks.
2025-10-24 22:28:52 <WhyNotHugo> 455 packaged had GOCACHE, GOTMPDIR, GOMODCACHE explicitly defined to the same value as abuild. I hope this does't need approval from all maintainers 😬
2025-10-24 22:53:12 <omni> ikke: perhaps not fully =/ no I set my hope to max_render_time 15 (above that and I can reproduce some issues
2025-10-24 23:41:34 <Sertonix[m]> WhyNotHugo: I forgot that these were sheduled for removal. I think the best we can do is to ping most maintainers and set a deadline when consent is implied.
2025-10-24 23:43:23 <WhyNotHugo> bot won't auto-tag with so many involved? !92123
2025-10-24 23:45:51 <Sertonix[m]> Unfortunatly no
2025-10-25 00:07:18 <Sertonix[m]> But thanks for working on it!
2025-10-25 10:18:10 <elagost> could someone look at this MR? I think it's ready to go. !91113
2025-10-25 10:31:58 <omni> 🏹⌒
2025-10-25 11:36:37 <qaqland> Sertonix[m]: i think we need to establish a regular "consent pool"
2025-10-25 11:38:23 <qaqland> use for manage MRs without approve from maintainer
2025-10-25 12:31:32 <ikke> omni: sorry, don't recall that
2025-10-25 13:39:06 <KatePatrick[m]> Hey there
Are you looking for a way? A telegram game changer is here🥰 be a part of the change while the opportunity still stands!
inviting you to join this on tele.. he’s doing a great job 🥰 join with this link below
Are you looking for a way?
WE RISE BY LIFTING OTHERS
This telegram channel Has Changed The Life Of Lives out there. Don't Miss This Great Opportunity, It May Never Be There Again.
Hurry up Join The
2025-10-25 13:39:06 <KatePatrick[m]> Winning Teams And Enjoy Yourself
👇👇👇👇👇👇👇👇
https://t.me/+jLJNhUzVTUphODVk
Join the telegram channel by clicking now
📣🎊❤️
2025-10-25 13:43:10 <elagost> weird how I only ever see spam from matrix users.
2025-10-25 13:56:02 <KatePatrick[m]> Hey there
Are you looking for a way? A telegram game changer is here🥰 be a part of the change while the opportunity still stands!
inviting you to join this on tele.. he’s doing a great job 🥰 join with this link below
Are you looking for a way?
WE RISE BY LIFTING OTHERS
This telegram channel Has Changed The Life Of Lives out there. Don't Miss This Great Opportunity, It May Never Be There Again.
Hurry up Join The
2025-10-25 13:56:02 <KatePatrick[m]> Winning Teams And Enjoy Yourself
👇👇👇👇👇👇👇👇
https://t.me/+jLJNhUzVTUphODVk
Join the telegram channel by clicking now
📣🎊❤️
2025-10-25 14:02:00 <andypost[m]> ikke: looks build-3-23-ppc64le build has stuck on community/nickel for another day
2025-10-25 15:05:07 <KatePatrick[m]> Hey there
Are you looking for a way? A telegram game changer is here🥰 be a part of the change while the opportunity still stands!
inviting you to join this on tele.. he’s doing a great job 🥰 join with this link below
Are you looking for a way?
WE RISE BY LIFTING OTHERS
This telegram channel Has Changed The Life Of Lives out there. Don't Miss This Great Opportunity, It May Never Be There Again.
Hurry up Join The
2025-10-25 15:05:08 <KatePatrick[m]> Winning Teams And Enjoy Yourself
👇👇👇👇👇👇👇👇
https://t.me/+jLJNhUzVTUphODVk
Join the telegram channel by clicking now
📣🎊❤️
2025-10-25 23:20:09 <omni> I prefer cooperating teams and that we all make it
2025-10-26 12:53:46 <WhyNotHugo> !90773 and !90808 both fix running services with supervise-daemon, the upstream recommendation from openrc
2025-10-26 13:12:35 <strangePerson> hi everyone! I wrote an APKBUILD for rust-rpxy (https://github.com/junkurihara/rust-rpxy/) but stuck with a problem: the repository itself contains submodules and they are not included in the release tarball. what do I do about it? I can just clone the repo in prepare(), but I don't think it is a good way to go. because checksums will not be calculated. I'm currently stuck
2025-10-26 13:29:33 <WhyNotHugo> strangePerson: consider including tarballs for the submodules in the sources= array.
2025-10-26 13:29:39 <WhyNotHugo> They left :/
2025-10-26 13:34:21 <strangePerson> submodules are not provided as tarballs. should I ask the developer?
2025-10-26 13:38:11 <strangePerson> ok, I got that I can just download the source code as a .zip. thank you, WhyNotHugo
2025-10-26 13:40:26 <WhyNotHugo> strangePerson: I'd use the tarballs that the git hosting repository auto-generates.
2025-10-26 13:40:46 <WhyNotHugo> Check for APKBUILDs which download github archives with tagged commit, for example.
2025-10-26 13:41:15 <WhyNotHugo> `cd aports; ag 'github.*_commit'
2025-10-26 13:48:21 <Kladky> ppc64le seems to fail it's tests due to OOM for !89120, what should I do?
2025-10-26 13:51:44 <strangePerson> WhyNotHugo: woah, I didn't know about ag. that's actually so cool, thanks!
2025-10-26 18:23:31 <strangePerson> rpxy doesn't build with cargo auditable, but with regular cargo. I found a relative issue: https://github.com/rust-secure-code/cargo-auditable/issues/124 - is it acceptable to build a package in the testing repository using regular cargo while it is not fixed?
2025-10-26 21:39:49 <angeloverlain[m]> which person would I have to poke to update the mediawiki instance at wiki.alpinelinux.org?
2025-10-26 22:31:18 <achill> probably someone at #alpine-infra
2025-10-27 03:24:49 <qaqland> sorry for no time to deal with #17558 #17499 ...
2025-10-27 07:27:19 <omni> can we, please, avoid bypassing CI?
2025-10-27 07:35:32 <lotheac> are you referring to something specific?
2025-10-27 07:43:11 <omni> pushing directly something that fails to build, blocking the builders, that could have been caught in CI pipelines
2025-10-27 07:47:05 <lotheac> i was more wondering if there was some recent push that caught your attention in that way. i mean i would think we are already (trying to) avoid those things
2025-10-27 07:53:41 <omni> one would think so
2025-10-27 08:11:49 <omni> going through gitlab also has other benefits (in addition to making sure that things build in CI before merging) in that people get notified and MR pages are good for follow-ups
2025-10-27 08:15:05 <dne> are build-3-22-armv7 and build-3-22-riscv64 stuck or just behind? neither has built the updated main/bind packages from 4 days ago
2025-10-27 10:33:56 <dne> nvm it seems build-3-22-armv7 finally finished building dotnet… (started on tuesday)
2025-10-27 11:02:26 <ncopa> I think they may been stuck
2025-10-27 17:39:29 <jahway603[m]> Can I get !92039 merged please?
2025-10-27 18:31:59 <eletrotupi> hm, how to address package out of date notifications for LTS releases? 
2025-10-27 20:33:29 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-10-28 04:22:56 <lillianb> hey, how is the qemu-xen package built? I'm trying to enable the libusb feature in xen's HVM qemu. I added the --enable-libusb flag in aports/community/qemu/APKBUILD next to the other xen flags, and rebuilt both qemu and xen, but there was no change
2025-10-28 04:23:29 <lillianb> it looks like xen-qemu is a subpackage and I'm not sure how those get built or how to correctly add a configure flag to it
2025-10-28 04:25:49 <lillianb> well, to be more precise... I found the qemu() function in xen's APKBUILD. but I do not actually see a build section for it
2025-10-28 05:43:45 <Arnavion> The qemu function *is* the build function for the xen-qemu subpackage
2025-10-28 05:44:43 <Arnavion> You can see `$pkgname-qemu` is listed in the `subpackages` string, which tells apk to look for a function named `qemu` by default to construct that subpackage
2025-10-28 06:18:21 <Sertonix[m]> lillianb: most subpackage function just move files out of the main package into the subpackage. Did you make sure that you installed the compiled packages?
2025-10-28 07:27:07 <omni> suddenly worried about !92285 that I merged
2025-10-28 07:27:30 <omni> also upgrades py3-fido2 to 2.0.0
2025-10-28 07:27:46 <omni> https://github.com/Yubico/python-fido2/releases/tag/2.0.0
2025-10-28 07:27:52 <omni> https://github.com/Yubico/python-fido2/blob/main/doc/Migration_1-2.adoc
2025-10-28 07:39:51 <omni> !92303
2025-10-28 07:42:29 <omni> ok, tests seem to pass, less worried
2025-10-28 07:44:10 <omni> but someone may want to look into and verify that py3-solo1 still works as expected, it doesn't run tests and has a fido2-1.0-compat.patch
2025-10-28 09:43:24 <prabu> Can I get !90460 merged please?
2025-10-28 15:09:26 <qaqland> imo, now the community wlroots could be renamed to wlroots-0.19 (?)
2025-10-28 15:10:14 <qaqland> 
ACTION -> wlroots0.19

2025-10-28 15:11:40 <bl4ckb0ne> why? It's the latest one
2025-10-28 15:12:02 <bl4ckb0ne> we could make wlroots0.19 when 0.20 is released and if there's still compositors stuck on that rev
2025-10-28 15:17:49 <lillianb> Sertonix[m], I have not installed the qemu package on my build machine, it is just in ~/packages. I have also not installed the main qemu package on my server and just the qemu-xen subpackage copied from my build server.
2025-10-28 15:18:07 <lillianb> where do I need to install qemu for the xen-qemu subpackage to pick up the changes?
2025-10-28 15:18:32 <lillianb> (sorry, I keep confusing qemu-xen and xen-qemu... the latter is the correct name)
2025-10-28 15:31:19 <omni> it is a bit confusing..
2025-10-28 15:32:20 <omni> xen-qemu is a xen subpackage that contains a build of a qemu snapshot of their choosing
2025-10-28 15:34:20 <omni> it has files under /usr/share/qemu-xen
2025-10-28 15:34:59 <omni> and some under /usr/lib/xen/bin/ to be used by xen
2025-10-28 15:36:24 <lillianb> yeah, I understood this, but where is the source of the build?
2025-10-28 15:36:30 <omni> for example /usr/lib/xen/bin/qemu-system-i386 (also on aarch64? hmm..) to be used by hvm DomUs
2025-10-28 15:36:41 <lillianb> the qemu() function in xen package copies files, but it is not clear to me from what
2025-10-28 15:40:24 <omni> from the build (=
2025-10-28 15:40:32 <omni> (sorry, give me a minute)
2025-10-28 15:44:27 <omni> lillianb: not exactly sure what you are looking for or why, but you may want to download the Xen tarball (or checkout their git repository) and look at QEMU_UPSTREAM_* in Config.mk
2025-10-28 15:45:22 <omni> but our qemu, that is more up-to-date, is also build with Xen support
2025-10-28 15:46:21 <lillianb> ah, I'm trying to enable the libusb feature to get usb-host support
2025-10-28 15:46:25 <omni> so you can use /usr/bin/qemu-system-x86_64 provided by the qemu-system-x86_64 subpackage as device_model_override if you want
2025-10-28 15:46:38 <qaqland> bl4ckb0ne: starting from 0.18, multi-versions wlroots would coexist
2025-10-28 15:46:46 <omni> (then remember to set device_model_version = "qemu-xen")
2025-10-28 15:47:05 <qaqland> 
ACTION s/would/could

2025-10-28 15:47:38 <bl4ckb0ne> yes i know, what im saying is that we have multiple older versions for compositors that are stuck on older rev, but the most recent one doesnt need that pattern
2025-10-28 15:47:55 <omni> note however that qemu was moved from main/ to community/ and is only supported (with bug/security fixes) throughout the latest stable release of alpine
2025-10-28 15:49:40 <lillianb> let me try that
2025-10-28 15:50:12 <omni> (I am under the impression that QEMU now maintain several release branches and could be moved back to main/ and we could, eventually, get rid of the xen-qemu subpackage)
2025-10-28 15:52:35 <lillianb> hm... I have built alpine's qemu package with the --enable-libusb flag, and my domU is using that binary, but I am still not able to use usb-host...
2025-10-28 15:52:39 <lillianb> I'll poke at it more later
2025-10-28 16:30:36 <vkrishn> for folks who wanna revive a not-so-old device with 2Gb ram, https://wiki.insteps.net/AlpineLinux/Diskless-install-on-devices-with-2gb-ram
2025-10-28 16:31:50 <vkrishn> using diskless method :-)
2025-10-28 17:00:54 <qaqland> bl4ckb0ne: you are right :)
2025-10-28 17:33:14 <Ariadne> is it a known issue that build.a.o is down?
2025-10-28 17:37:11 <omni> it has been on and off over the past week, I think
2025-10-28 17:37:38 <ptrc> the builders seem somewhat down as well..? pushing a message over mqtt propagates just fine to other subscribers, but the builders don't respond to it
2025-10-28 17:38:30 <ptrc> normally the failed ones ( e.g. build-3-23-x86 ) would restart building again and post stuff like "pulling git"
2025-10-28 17:42:11 <Ariadne> different builders are in different locations, but yes, seems to be a major outage for our infrastructure in general
2025-10-28 17:42:42 <Ariadne> i will just cross-compile the package i need ;)
2025-10-28 19:48:32 <strangePerson> I'm trying to write init script for rpxy for the whole day. currently it looks like this: https://privatebin.net/?3563245fd5fcd031#99xmniK4NfXBLqPeEMgZyF3n1NjbmN9vUkaw97stsi76 - if I run it using `rc-service -d rpxy start` it prints "rpxy is already starting" and nothing more. I can start it using `doas -u rpxy /usr/bin/rpxy --config /etc/rpxy/rpxy.toml` and it starts, actually. I've tried to use "supervise-daemon", b
2025-10-28 20:11:40 <strangePerson> well, that was just a skill issue.
2025-10-28 20:58:54 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-10-29 15:45:32 <strangePerson> how do I check if my APKBUILD actually builds for different architectures? when I create a merge request it creates a pipeline automatically - how can I do something simillar on my local machine? I don't want to spam commits and MRs
2025-10-29 15:47:08 <strangePerson> I have only amd64, by the way. maybe I can create a pipeline somehow without creating a MR?
2025-10-29 15:49:33 <lotheac> you can create an MR with the target branch in your own fork
2025-10-29 16:02:21 <strangePerson> got it, thank you
2025-10-29 16:04:21 <PureTryOut> `CBUILD=<some arch> abuild rootbld` does the trick, assuming you've setup binfmt for the target architecture
2025-10-29 16:44:58 <strangePerson> seems like I have to install qemu-* for architectures I want to use this way. anyway, I'll try it out, thanks 
2025-10-29 18:06:38 <Ariadne> this openblas thing is puzzling.  it builds on my ppc64le system
2025-10-29 18:20:11 <Ariadne> oh, its test failure
2025-10-29 18:23:18 <jahway603[m]> Can I please get these MRs merged? !92362 !92363
2025-10-29 18:29:41 <Noisytoot> Could someone please merge !91272? It's been approved by the maintainer
2025-10-29 18:38:13 <Ariadne> Noisytoot: done
2025-10-29 18:45:07 <Noisytoot> thanks
2025-10-29 20:06:35 <HerryJames[m]> Hey there... (full message at <https://matrix.org/oftc/media/v1/media/download/AZJGTrJbfEXyY2d1lyATOIqS9QFiPQ8miafgQMFvAyR3rPjJorMpNxcW8Nd7EX2QfzEjZbqSO0GeNBnyG6fF-h5Ceaea0-_AAG1hdHJpeC5vcmcvVlFwbG1NWnJvQWFnWGNzdlJHeHdHcUta>)
2025-10-29 20:30:12 <achill> > 
2025-10-29 20:30:12 <achill> As a heads up, WebKitGTK is going to hard require a Swift toolchain. How long until then is to be determined but I'm going to guess sooner rather than later, 2.52 or maybe 2.54
2025-10-29 20:30:13 <achill> fun
2025-10-29 20:30:36 <abby> o.O
2025-10-29 20:30:44 <abby> where is that from?
2025-10-29 20:30:51 <achill> the gnome release matrix channel
2025-10-29 20:33:11 <Sheila> they should really stick to Vala, imo.
2025-10-29 20:44:38 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-10-29 20:57:06 <Ariadne> Sheila: it is probably the webkit side itself that requires swift
2025-10-29 21:02:45 <quinq> achill, the heck
2025-10-29 21:06:45 <achill> afaik it's because of apple and not gnome
2025-10-29 21:06:46 <achill> yeah
2025-10-30 00:52:24 <jvvv> i'm unclear why the eudev APKBUILD has 'provides="udev=176"' when the upstream udev version referenced in the eudev source is 251
2025-10-30 00:54:19 <jvvv> nvrmnd, i see now that the 176 was the version chosen when udev was replaced by eudev
2025-10-30 02:03:15 <qaqland> i want to move some of my maintained testing package to the community, can i just open one single MR?
2025-10-30 11:52:01 <omni> I did a glab mr checkout on an MR with <username>/aports:master and I think that didn't use to be possible, now it messed up my local sh^wgit
2025-10-30 12:03:19 <omni> git branch -D master && git checkout --track origin/master
2025-10-30 12:03:31 <omni> could probably have been sorted some other way, but that was how I did it
2025-10-30 13:24:48 <Newbyte> Is there any way to make abuild use a different user agent or something like that to avoid Anubis?
2025-10-30 13:29:18 <xe> Newbyte: what is its current user-agent?
2025-10-30 13:29:24 <Newbyte> no idea
2025-10-30 13:29:35 <Newbyte> why?
2025-10-30 13:29:43 <xe> and/or can you make it hit https://halone.within.lgbt/random-uuid so I can write an allow rule?
2025-10-30 13:30:28 <Newbyte> sure, one second
2025-10-30 13:32:50 <Newbyte> xe should I send the downloaded file or do you have logs already?
2025-10-30 13:34:48 <xe> Newbyte: my server should upload the signatures to object storage in a few minutes, i'll use that JSON document to make a rule and PR it
2025-10-30 13:35:08 <Newbyte> thanks, nothing more that I need to do right now then?
2025-10-30 13:35:18 <xe> nope, thanks for the info <3
2025-10-30 13:35:27 <xe> does it have mozilla in its user-agent?
2025-10-30 13:35:37 <Newbyte> thank you too!!
2025-10-30 13:35:45 <Newbyte> xe: yes
2025-10-30 13:35:59 <xe> ah, it should probably not do that
2025-10-30 13:36:08 <Newbyte> or actually
2025-10-30 13:36:21 <Newbyte> sorry, I was looking at the wrong file 🤦
2025-10-30 13:36:32 <Newbyte> the user agent is just Wget
2025-10-30 13:36:47 <Newbyte> verbatim
2025-10-30 13:37:48 <xe> what git forge were you failing to download from?
2025-10-30 13:37:53 <lotheac> actually it *is* just curl or wget. https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-fetch.c?ref_type=heads
2025-10-30 13:38:17 <Newbyte> xe https://git.hadrons.org/cgit/debian/
2025-10-30 13:38:59 <xe> oh good uhhhh
2025-10-30 13:38:59 <Sheila> you should be able to set ABUILD_USER_AGENT to specify one.
2025-10-30 13:39:18 <xe> my honeypot server hasn't been reporting data for a few days because DNS broke lol
2025-10-30 13:39:18 <Newbyte> Sheila: thanks, but I guess that would still fail in the CI then?
2025-10-30 13:40:12 <lotheac> Sheila: what? i don't think the code has any support for that
2025-10-30 13:40:27 <lotheac> or is that a feature request or something
2025-10-30 13:40:50 <Sheila> ah. sorry, I was looking at Adélie's version. it is indeed not possible in Alpine's, so never mind.
2025-10-30 13:41:04 <xe> 
ACTION goes to run system updates, reboot, and pray

2025-10-30 13:44:39 <Newbyte> if anyone can think of a workaround that wouldn't trigger Anubis in the meantime I'm all ears
2025-10-30 13:45:56 <Sheila> won't help for CI, but download manually?
2025-10-30 13:46:31 <Newbyte> yeah, I guess that'll have to do for now, thanks
2025-10-30 13:47:01 <xe> i think abuild needs to be patched to not have mozilla in it's user-agent string
2025-10-30 13:47:36 <Newbyte> xe: that was just me looking at the wrong file, the user agent is actually just Wget 
2025-10-30 13:47:50 <lotheac> or curl, if you have it installed...
2025-10-30 13:48:02 <lotheac> that might work for a workaround btw :p
2025-10-30 13:53:42 <Newbyte> tried installing Curl, same issue unfortunately
2025-10-30 13:54:38 <Newbyte> it seems to still use Wget
2025-10-30 18:36:57 <raspbeguy> Hello, can someone merge those MRs please? !87884 !90941 !91118 !91337 !91546
2025-10-31 10:37:57 <caskd> ncopa: nagging again about https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/177
2025-10-31 10:58:07 <nic> Is there any particular reason why Clang packages depend on GCC?
2025-10-31 11:07:50 <sam_> libstdc++ and libgcc i imagine
2025-10-31 11:07:52 <sam_> and indeed https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/clang16/APKBUILD#L121
2025-10-31 11:09:59 <nic> I see
2025-10-31 11:10:05 <nic> That's unfortunate though
2025-10-31 11:11:05 <nic> I can't speak for others, but the reason I use Clang is to avoid GCC
2025-10-31 11:11:36 <sam_> if you're fine with ABI incompatibility then go nuts
2025-10-31 11:11:42 <sam_> rip it out and use libc++
2025-10-31 11:13:49 <nic> I could get over having libgcc on my system, but GCC itself is unnecessary in my case
2025-10-31 11:13:58 <nic> libgcc-dev, that is
2025-10-31 11:14:30 <achill> you might be interested in chimera linux which is a llvm-based musl distro with bsd userland and stuff
2025-10-31 11:14:43 <nic> I already am :)
2025-10-31 11:14:55 <nic> But Alpine is still nice
2025-10-31 15:26:20 <Igel_> happy halloween.. i write about v3.23 and the paths eg ://mirror/v3.22/releases/*/netboot* vs. ://mirror/v3.23/releases <-- missing ... i am curious where those ipxe/netboot friendly data went? hmm... thanks in advance if you know or heard of this
2025-10-31 15:28:12 <Igel_> (sorry is it because it is not yet released? oops...)
2025-10-31 15:31:17 <Igel_> re: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.23.0 ... word! .. happy friday mfs.. 
2025-10-31 17:17:29 <khem> there is llvm-libgcc too which is drop-in replacement for libgcc 
2025-10-31 17:17:45 <khem> I have made it work for yocto lately 
2025-10-31 17:53:05 <WhyNotHugo> How would an upgrade to Python 3.14 work exactly? Does a single MR need to bump all Python packages? Or do we upgrade python3 to 3.14 and then wait for packagers to fix dependnat packages?
2025-10-31 17:55:03 <ikke> WhyNotHugo: both are generally pushed at the same time
2025-10-31 17:55:53 <ikke> generally a branch is created to contain the immediate result until all issues are fixed
2025-10-31 18:02:27 <eletrotupi> hello, can someone merge !91617 
2025-10-31 18:02:34 <eletrotupi> just another smol mr
2025-10-31 18:02:51 <eletrotupi> (also pinging Sertonix[m])
2025-10-31 18:26:12 <ahills> hey, would anyone be willing to merge !91812 (a backport from edge to 3.22)? it is a quite trivial change
2025-10-31 18:26:25 <ahills> there is no rush, I have just already used a bit of runner time rebasing it
2025-10-31 20:02:19 <Ariadne> ahills: done
2025-10-31 22:42:41 <ahills> thank you!