2025-12-01 00:31:00 <socksinspace> looks like you got your wish, 6.18 is out as of ~2h ago
2025-12-01 00:49:20 <Ariadne> abby: merge-usr is problematic, it breaks apkdb.
2025-12-01 00:50:53 <Ariadne> as a tool for experimenting with merged /usr setup, it is fine (as long as you know the risks), but making the system no longer consistent with apkdb is not ok for production use
2025-12-01 00:51:25 <abby> well aware, i've been reading the discussion
2025-12-01 00:52:13 <abby> (<- not an alpine user)
2025-12-01 00:54:04 <Ariadne> well, given that this is #alpine-devel, the assumption is going to be that people are using alpine
2025-12-01 01:36:26 <lotheac> ncopa: if you mean NETFILTER_XTABLES_LEGACY, i am pretty sure it's still needed for docker
2025-12-01 01:37:03 <lotheac> 100% sure it was a month ago when i made this MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92255
2025-12-01 01:37:35 <Ariadne> yes, docker itself does not support containerd nft backend yet as far as i know
2025-12-01 01:38:14 <Ariadne> i would love to be wrong on that, but i haven't heard anything indicating otherwise...
2025-12-01 01:38:37 <lotheac> unless something significant changed in the last month, you're not wrong :)
2025-12-01 06:07:59 <Saijin_Naib[m]> thanks achill and Biswa96for helping bump some of my packages. I'm being kept really busy (aside from year-end/holiday season stuff) with trying to get heat and hot water in my house haha
2025-12-01 08:11:24 <ncopa> do we also need CONFIG_IP_NF_IPTABLES_LEGACY?
2025-12-01 08:11:37 <ncopa> This is not needed if you are using iptables over nftables
2025-12-01 08:14:03 <lotheac> that one seems to be =m on -stable
2025-12-01 08:15:05 <lotheac> (in terms of /boot/config.*, not the config fed to the kernel build)
2025-12-01 08:15:58 <lotheac> it's "default m if NETFILTER_XTABLES_LEGACY" so
2025-12-01 08:16:36 <lotheac> or did you want to make it =n explicitly?
2025-12-01 08:23:40 <ikke> Didn't the latest version gain nftables support, or is it only partially?
2025-12-01 08:24:01 <ikke> Ftr, tomalok did upgrade docker recently
2025-12-01 08:24:39 <lotheac> well, i can disable the config option locally and test if you want
2025-12-01 08:25:15 <lotheac> but i don't think docker is the only thing that still needs (needed?) that
2025-12-01 08:26:13 <lotheac> docker engine 29.0.0 release notes say: "Experimental support for nftables can now be enabled by setting Docker daemon's firewall-backend option to nftables. For more information, see Docker Engine docs."
2025-12-01 08:26:57 <lotheac> if it has to be opted into, then i don't think it's such a good idea to drop the kernel support
2025-12-01 08:30:20 <ncopa> yeah. bummer
2025-12-01 08:30:51 <ncopa> I suppose we also need the IP_NF_NAT and IP_NF_TARGET_MASQUERADE and all that stuff
2025-12-01 08:31:40 <lotheac> that all will get picked up by just NETFILTER_XTABLES_LEGACY, no need to be explicit
2025-12-01 08:32:05 <ncopa> they are n with olddefconfig
2025-12-01 08:32:15 <ncopa> Legacy ARPTABLES support (IP_NF_ARPTABLES) [N/m/?] (NEW) 
2025-12-01 08:32:28 <ncopa> can we drop legacy ARP tables?
2025-12-01 08:32:45 <lotheac> does your olddefconfig actually have NETFILTER_XTABLES_LEGACY=m in it
2025-12-01 08:33:41 <lotheac> docker's working fine on linux-stable and i have all the options you've mentioned thus far as =m because of just that
2025-12-01 08:33:50 <ncopa> ok
2025-12-01 08:34:02 <lotheac> it's largely those "default m if NETFILTER_XTABLES_LEGACY"
2025-12-01 08:34:22 <lotheac> and similar
2025-12-01 08:38:52 <lotheac> NETFILTER_XTABLES_LEGACY sets the default for all of the legacy tables, i suppose we could dig into more selective enablement of those, but there's more potential for breakage
2025-12-01 08:39:41 <lotheac> not sure exactly which ones docker actually needs right now, and not sure what other software needs them either
2025-12-01 09:19:05 <ncopa> ok. lets get rc2 out asap with 6.18 kernel and test
2025-12-01 09:58:33 <ncopa> hum
2025-12-01 09:59:56 <ncopa> $ zcat /proc/config.gz | grep CONFIG_NETFILTER_XTABLES_LEGACY
2025-12-01 09:59:56 <ncopa> # CONFIG_NETFILTER_XTABLES_LEGACY is not set
2025-12-01 09:59:56 <ncopa> hello from docker
2025-12-01 10:00:21 <ncopa> let me do that again
2025-12-01 10:00:28 <ncopa> hello from docker
2025-12-01 10:00:28 <ncopa> # CONFIG_NETFILTER_XTABLES_LEGACY is not set
2025-12-01 10:00:28 <ncopa> $ zcat /proc/config.gz | grep CONFIG_NETFILTER_XTABLES_LEGACY && docker run --rm alpine:edge sh -c "echo hello from docker"
2025-12-01 10:01:22 <lotheac> right, but does traffic between that container and outside of your machine work
2025-12-01 10:02:10 <ncopa> $ (zcat /proc/config.gz | grep CONFIG_NETFILTER_XTABLES_LEGACY && docker run --rm alpine:edge sh -c "ping -c1 vg.no") | tpaste
2025-12-01 10:02:10 <ncopa> https://tpaste.us/8Bqg
2025-12-01 10:02:15 <ncopa> looks like it does
2025-12-01 10:02:19 <lotheac> hmm
2025-12-01 10:02:36 <ncopa> but maybe inbound portforward does not?
2025-12-01 10:02:38 <ncopa> i dont know
2025-12-01 10:02:49 <ncopa> but yeah. humm indeed
2025-12-01 10:03:01 <lotheac> i had some more obvious breakage than port-forwarding which is why i had to enable the option in stable
2025-12-01 10:03:24 <lotheac> so maybe i'll try to flip the option off and retry whatever i'm doing with docker and see if it works
2025-12-01 10:06:26 <lotheac> will take a bit of time to compile but i'll get back to you in an hour or something
2025-12-01 11:17:21 <chinesespydrone[m]> On the 3.23.0 edge release device access seems to be broken for any process started by a non-root user, including openrc daemons.
2025-12-01 11:20:33 <chinesespydrone[m]> * openrc daemons, thus breaking everything that depends on /dev/null, /dev/zero and /dev/random.
2025-12-01 11:37:24 <lotheac> ncopa: dockerd doesn't even start for me if i disable NETFILTER_XTABLES_LEGACY (on top of linux-stable). failed to start daemon: Error initializing network controller: error creating default "bridge" network: Failed to Setup IP tables: Unable to enable NAT rule:  (iptables failed: iptables --wait -t nat -I POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE: Warning: Extension MASQUERADE revision 0 not supported, missing kernel module?
2025-12-01 11:37:24 <lotheac> iptables v1.8.11 (nf_tables):  RULE_INSERT failed (No such file or directory): rule in chain POSTROUTING
2025-12-01 11:39:00 <lotheac> i could try 6.18 i suppose, just not on this machine
2025-12-01 11:39:12 <ikke> lotheac: what version of docker?
2025-12-01 11:39:24 <lotheac> docker-29.1.1-r0
2025-12-01 11:47:06 <ncopa> achill: do you remember why bpftool was needed? 
2025-12-01 11:47:12 <ncopa> # Generate vmlinux.h
2025-12-01 11:47:12 <ncopa>                 bpftool btf dump file vmlinux format c > vmlinux.h
2025-12-01 11:47:29 <ncopa> I mean, what is vmlinux.h needed for?
2025-12-01 11:51:18 <achill> to build ebpf modules for the kernel
2025-12-01 11:54:02 <ncopa> ok
2025-12-01 11:54:09 <ncopa> im moving linux-tools to main
2025-12-01 11:54:22 <achill> lgtm
2025-12-01 11:56:27 <chinesespydrone[m]> <chinesespydrone[m]> "On the 3.23.0 edge release..." <- Nevermind, that applies for all files regardless of permissions.
2025-12-01 11:56:59 <chinesespydrone[m]> * Nevermind, that applies to all files regardless of permissions, not just devices.
2025-12-01 12:13:27 <chinesespydrone[m]> <chinesespydrone[m]> "Nevermind, that applies for..." <- On the most recent one only file access is broken.
2025-12-01 12:27:09 <ncopa> achill: what do you think about keep linux-stable on 6.17 til we have stestd linux-lts 6.18 a bit?
2025-12-01 12:27:15 <ncopa> nice to have a fallback kernel while testing
2025-12-01 12:38:55 <elibrokeit> Ariadne: it's understandable if a migration script breaks the database, but you can also Just Not Support That
2025-12-01 12:39:16 <lotheac> same issue with docker on linux 6.18.0 NETFILTER_XTABLES_LEGACY=n. ncopa: i officially have no idea why it would work for you
2025-12-01 12:39:26 <lotheac> unless you configured it to use nftables?
2025-12-01 12:39:44 <lotheac> or your docker is actually podman in disguise
2025-12-01 12:41:08 <elibrokeit> the /use merge itself shouldn't be at all fragile (with per package issues)
2025-12-01 12:55:54 <wen> Help, would a committer test this MR and commit it if it is OK, then I can continue the follow-up work: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93592
2025-12-01 13:38:01 <achill> ncopa: sounds good
2025-12-01 16:49:08 <Ariadne> elibrokeit: alternatively we could just not cut corners and do things correctly
2025-12-01 17:02:09 <Ariadne> a migration for packages that have not been fixed may be necessary, but it should be done by the package manager (which would presumably ensure apkdb is correct)
2025-12-01 17:05:05 <Ariadne> (this is already somewhat in flight, although the migration tool is still detached from apk itself)
2025-12-01 21:46:41 <elibrokeit> Ariadne: sure. just if the alternative is a genuine concern about human deaths, it's not the worst idea in the world to say "out of an abundance of caution -- please reinstall" :P
2025-12-01 21:48:22 <elibrokeit> I know that back in 2012 or thereabouts when archlinux migrated, they rebuilt all packages for the change and then the package manager was able to cross-check that after the transaction, zero packages would still be using the pre-migration paths. as long as that constraint was upheld, you could migrate simply by performing an all-in-one full system upgrade 
2025-12-01 21:50:00 <elibrokeit> (the alternative is it throws a file conflict and refuses to do anything at all, it's consistent either way)
2025-12-01 21:51:08 <Sertonix[m]> That one is missing files that need manual moving and software breakage due to the changed contents of search paths.
2025-12-01 21:53:24 <Sertonix[m]> (the latter is not even fixed through a reinstall)
2025-12-01 21:53:36 <elibrokeit> packaged files don't need manual moving, and unpackaged files do not belong in /lib or /bin. if you had unpackaged files anyways then it would be a file conflict and you'd need to fix that before proceeding
2025-12-01 21:54:43 <elibrokeit> software breakage due to the changed contents of search paths is a) solved by the symlink, b) part of the upstream software, which currently works on arch/Debian/fedora/Gentoo and many others
2025-12-01 21:55:27 <ncopa> i pushed 6.18.0 kernel
2025-12-01 21:55:57 <ncopa> I will tag rc2 tomorrow
2025-12-01 21:56:06 <ncopa> then we need to write release notes and release
2025-12-01 21:56:25 <ncopa> any volunteers to create a MR with 3.23 release notes?
2025-12-01 21:58:53 <elibrokeit> the exception being as always, CMake. which uses windows style relocatable installs and calculates the location of /usr/include, as ${cmake_binary}/../include and therefore if /bin is first in $PATH but is a symlink, will result in /bin/cmake running, and produce a variety of strange errors while trying and failing to find /include
2025-12-01 22:00:44 <Sertonix[m]> elibrokeit: I would prefer to not have to repeat this every time somebody wants thinks to have a better solution: Sysadmin installed files in /lib/firmware are needed for some devices and alpine provided scripts sometimes have to create extra files, symlinks or even mount points there.
2025-12-01 22:02:14 <elibrokeit> package the firmware as an apkbuild, that is what people on every other distro do?
2025-12-01 22:04:01 <Sertonix[m]> The search paths also caused qtwebengine to crash and some mariadb scripts to break. And that is just the reports from the few people who tested this so far  and provide feedback
2025-12-01 22:06:22 <elibrokeit> are these issues with the migration or with "the whole concept of the /usr Merge"?
2025-12-01 22:08:23 <Sertonix[m]> My point is that for existing setups there isn't a path that only needs packages to change.
2025-12-01 22:09:09 <Sertonix[m]> It varies between the issues I mentioned if they happen on new installs or only on the mogration
2025-12-01 22:43:33 <mio> ncopa: on it, please give me an hour to MR an initial draft
2025-12-01 23:22:31 <elibrokeit> Sertonix[m]: the qtwebengine issue etc. is because of a generalized issue of preferring e.g. /lib over /usr/lib, which I agree was always wrong
2025-12-01 23:28:10 <mio> ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/114
2025-12-01 23:32:04 <achill> also: if anyone has something to add for https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.23.0, now is the best time
2025-12-01 23:33:31 <mio> yes, will check the wiki page later and update release notes accordingly
2025-12-01 23:36:02 <mio> now would be a good time to add to the wiki
2025-12-01 23:37:25 <achill> dont think there will be anything new major to add for the main blog post, but general stuff would be nice
2025-12-01 23:37:52 <achill> also there are a few TODO stubs someone can update, otherwise ill do that when i have the time
2025-12-02 00:22:31 <mio> sounds good, thanks!
2025-12-02 00:56:36 <Kladky> The KDE Plasma version on the notes needs to be added to 6.5.3
2025-12-02 00:57:21 <Kladky> Honestly, all the versions should probably be double-checked before release
2025-12-02 01:00:08 <lotheac> ncopa: docker-29.1.1-r0 confirmed working (including port forwards from host) on 6.18.0-0-lts. i guess you enabled just the right configs :)
2025-12-02 05:24:57 <Saijin_Naib[m]> 6.18 seems fine thus far!
2025-12-02 05:31:57 <Cannabinoids[m]>  Advert Advert 🚨🚨🚨... (full message at <https://matrix.org/oftc/media/v1/media/download/AUQfWjAmr7pY6-ksMc3ZcP9tlJzJszeBSm47DNRqlPWmiyT814-B8dUQTyjqQLBUetqlM8E0DovrJFjbGoJr5lBCebJaTSnwAG1hdHJpeC5vcmcvQ3pLQ3hqS1hKSE5Oc3lVblRBcEV4bmJo>)
2025-12-02 05:41:35 <Saijin_Naib[m]> It does look like linux-lts might be missing some XFS kernel modules/options to support xfs online scrub/repair, which should be default to On in kernel 6.18
2025-12-02 05:42:03 <Saijin_Naib[m]> doas xfs_scrub -xvT / yields error messages
2025-12-02 05:42:35 <Saijin_Naib[m]> Info: /: Kernel metadata repair facility not detected. Error: /: Kernel metadata repair facility is not available.  Use -n to scrub. Info: /: Scrub aborted after phase 1.
2025-12-02 05:56:21 <Saijin_Naib[m]> Looks like we need to tweak CONFIG_XFS_ONLINE_REPAIR=y instead of unset
2025-12-02 05:56:25 <Saijin_Naib[m]> Open an MR?
2025-12-02 07:07:35 <ncopa> mio: big thanks!
2025-12-02 07:07:50 <ncopa> lotheac: i was lucky I guess... :)
2025-12-02 07:08:30 <ncopa> Saijin_Naib[m]: I'm on it. Also need to do an emergency fix for loongarch64
2025-12-02 07:19:59 <huajingyun> Thanks!
2025-12-02 07:24:11 <Saijin_Naib[m]> ncopaawesome. thanks so much!
2025-12-02 07:24:30 <Saijin_Naib[m]> 6.18 is a decent about 10% performance uplift on my machine vs prior LTS, so I am happy!
2025-12-02 07:25:09 <ncopa> oh cool
2025-12-02 07:25:24 <ncopa> i hope that does not come from unintentional disabling of security features :) 
2025-12-02 08:07:40 <ncopa> pushed -r1
2025-12-02 08:07:59 <ncopa> emergency fix with ext4 enabled and xfs online repair
2025-12-02 08:08:23 <lotheac> oh, how did ext4 get disabled?
2025-12-02 08:08:52 <quinq> Some butterfs activists sabotaged it
2025-12-02 08:45:32 <ikke> Saijin_Naib[m]: How do you measure that performance increase?
2025-12-02 08:47:02 <Saijin_Naib[m]> @ikke benched with hardinfo2 on 6.12 and compared
2025-12-02 08:47:37 <Saijin_Naib[m]> Had old bench for testing other distros
2025-12-02 08:48:25 <Saijin_Naib[m]> Felt faster in Evolution and LibreWolf, so I tested my perceptiion
2025-12-02 08:49:14 <ikke> Cool, interesting.
2025-12-02 08:50:02 <Saijin_Naib[m]> Not tested on good/modern hardware, so it may not scale
2025-12-02 08:50:43 <Saijin_Naib[m]> I think it might be all the swap/memory improvements at work
2025-12-02 08:57:36 <ncopa> don't know hoe ext4 got disabled. It happened first time on my x86_64 desktop, but I think that was due to I used the savedefconfig from 6.12 kernel. but due to that I did an olddefconfig on 6.12 tree, copied the full 6.12 config and did olddefconfig from there to 6.18
2025-12-02 08:57:48 <ncopa> but I must have messed up somewhere in the process
2025-12-02 08:59:57 <lotheac> i had a similar train of thought yesterday when i built 6.18.0 manually with the -stable configs and booted a vm on it. "what, failed to mount root? ok, i guess i screwed up, let's enable ext4 explicitly"
2025-12-02 09:00:27 <lotheac> maybe it's something new in 6.18 that causes it to not be enabled by default anymore
2025-12-02 09:00:49 <ncopa> could be, but I would have expected it to be enabled with the full config from 6.12
2025-12-02 09:01:04 <lotheac> i would too, but it wasn't (and ext4 is not explicitly enabled in the 6.12 configs)
2025-12-02 09:01:27 <ncopa> i mean in the full config it should be either on or off
2025-12-02 09:01:40 <lotheac> ah, right, you used that as olddefconfig
2025-12-02 09:01:49 <lotheac> well that's definitely weird
2025-12-02 09:01:54 <lotheac> maybe a dependency of it is not enabled or something
2025-12-02 09:02:21 <lotheac> sounds worth tracking down the root cause... but i don't have time right now
2025-12-02 09:02:39 <ncopa> same
2025-12-02 09:02:50 <ncopa> thanks for helping with it though
2025-12-02 09:04:32 <maribu> Hi. I was wondering why libasan is part of edge (see https://pkgs.alpinelinux.org/contents?file=libasan.a&path=&name=&branch=edge&repo=&arch=) but not part of v3.22 (see https://pkgs.alpinelinux.org/contents?file=libasan.a&path=&name=&branch=v3.22&repo=&arch=)? Is that deliberate, or is this an oversight?
2025-12-02 09:26:46 <Imbus64> What will be the fate of bcachefs in alpine? Any work needed on this, or is it out of the question for now? Arch packs dkms https://gitlab.archlinux.org/archlinux/packaging/packages/bcachefs-tools/-/blob/main/PKGBUILD
2025-12-02 09:40:17 <ncopa> as I understand bcachefs is out of mainline kernel so it will be off in linux-lts
2025-12-02 09:40:32 <ncopa> there is no current work with building it as a 3rd party module as far I know
2025-12-02 09:41:09 <Ariadne> ncopa: there is dkms now for bcachefs, we can probably do akms
2025-12-02 09:41:20 <ncopa> in other words, no plans for bcachefs
2025-12-02 09:41:53 <Ariadne> well, we ship zfs which is out of tree
2025-12-02 09:41:58 <Ariadne> why not also bcachefs?
2025-12-02 09:42:20 <ncopa> we ship zfs because we have people willing to maintain it
2025-12-02 09:42:46 <ncopa> if someone wants maintain bcachefs, then sure
2025-12-02 09:43:15 <ncopa> im just slightly skeptical due to it was removed from mainline kernel
2025-12-02 09:43:15 <Ariadne> i would but i already moved my NAS back to zfs
2025-12-02 09:43:17 <Ariadne> :D
2025-12-02 09:44:03 <ncopa> getting kicked out from mainline kernel is usually not a good sign (yeah, i saw why it happened and I know it was not for technical reasons)
2025-12-02 09:44:35 <Ariadne> oh no, if that is how he works with people, i wish whoever maintains bcachefs luck
2025-12-02 09:45:19 <Ariadne> i mostly mention dkms could be maintained in the same way as zfs in case anyone is actually using it and doesn't want to migrate away
2025-12-02 09:45:59 <ncopa> speaking of zfs, would be nice if someone could test if zfs works at all with the 6.18 kernel
2025-12-02 09:46:16 <ncopa> i wouldnt run it with anything important yet
2025-12-02 09:46:40 <Ariadne> i will upgrade my NAS in morning
2025-12-02 09:46:47 <ncopa> i hope you have backup
2025-12-02 09:47:02 <ncopa> we use zfs 2.4.0-rc something
2025-12-02 09:47:12 <ncopa> so maybe just test in a VM or so first
2025-12-02 09:52:19 <lotheac> i tried running bcachefs about a year ago and it wasn't anywhere close to a real replacement for zfs for my use. ymmv of course, but i need eg. send/receive and that just did not exist
2025-12-02 09:52:58 <lotheac> and also yes there's all the ... stuff on the mailing lists that did not exactly inspire confidence
2025-12-02 09:53:20 <lotheac> ncopa: i've been running zfs on my aarch64 laptop with 6.18 since rc2 or something
2025-12-02 09:53:29 <lotheac> (patched META locally to make it build)
2025-12-02 09:54:00 <lotheac> it may be risky though, i didn't check anything since this particular laptop doesn't contain any important data
2025-12-02 09:54:31 <lotheac> but nothing is obviously wrong
2025-12-02 09:54:34 <ncopa> ah, nice
2025-12-02 09:54:35 <ncopa> thanks!
2025-12-02 09:54:56 <ncopa> very good
2025-12-02 09:55:36 <ncopa> i think we should have a check() function in kernel packages that verifies the most important stuff
2025-12-02 09:56:11 <ncopa> we could start with ext4, ipv4 and ipv6 for example
2025-12-02 09:56:29 <lotheac> for clarity... my zfs is at commit dcada084b95e994f3bd6452148e51959f2933862 plus the META change
2025-12-02 09:57:01 <lotheac> may need these https://github.com/openzfs/zfs/pull/17842#issuecomment-3424044265 
2025-12-02 09:57:49 <ncopa> i think they are included in zfs-2.4.0-rc4
2025-12-02 09:57:55 <lotheac> ncopa: i was thinking earlier that we should have check() also verify that the final config does, in fact, contain all the lines specified in the input config
2025-12-02 09:58:05 <ncopa> ah. good idea
2025-12-02 09:58:58 <ncopa> i am considering use the full config instead of the savedefconfig
2025-12-02 09:59:02 <lotheac> or maybe it should be before make, not in check()
2025-12-02 09:59:06 <quinq> 10:45:59 @ncopa$ speaking of zfs, would be nice if someone could test if zfs works at all with the 6.18 kernel
2025-12-02 09:59:09 <quinq> Yes please :D
2025-12-02 09:59:21 <ncopa> the current way we do it with savedefconfig is cumbersome
2025-12-02 09:59:22 <quinq> I run Alpine/Edge/zfs on my work laptops (FDE)
2025-12-02 09:59:43 <ncopa> quinq: see above ^^^ looks like it does work
2025-12-02 10:00:08 <ncopa> but there is a reason I did the savedefconfig. the full config is also cumbersome
2025-12-02 10:00:18 <lotheac> also i just realized i've been running 6.18.0 on my desktop all day with alpine-packaged zfs and it works fine
2025-12-02 10:00:30 <ncopa> awesome
2025-12-02 10:00:36 <lotheac> so kinda pointless about the laptop above, but anyway!
2025-12-02 10:00:42 <ncopa> :)
2025-12-02 10:00:55 <quinq> ncopa, thank you, didn't want to make some unnecessary noise in here :D
2025-12-02 10:01:31 <ncopa> $ ./scripts/diffconfig /boot/config-6.17.10-0-stable /boot/config-6.18.0-1-lts | tpaste
2025-12-02 10:01:31 <ncopa> https://tpaste.us/N51w
2025-12-02 10:05:47 <quinq> lotheac, jaja, I didn't realize either that the kernel has *already* been bumped, and it's in /boot here too (just haven't rebooted yet)
2025-12-02 10:06:37 <quinq> Just babling here without nothing contrete to give out, but I think it'd be benefical to Alpine having a different kernel update management, like not overwriting current kernel by default and let the user manage it
2025-12-02 10:07:01 <quinq> Though AFAIK it's not a hard no, just need somebody to do the work
2025-12-02 10:07:02 <lotheac> i _did_ realize it's been bumped, i explicitly switched my desktop from -stable to 6.18.0-lts 9 hours ago and rebooted :D but the thought did not somehow enter my mind that i'm using zfs rootfs here too
2025-12-02 10:12:31 <ylli> hi
2025-12-02 11:00:21 <achill> <ncopa> there is no current work with building it as a 3rd party module as far I know
2025-12-02 11:00:21 <achill> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93473
2025-12-02 11:17:37 <liske> ncopa: I've tested 6.18.0 on some (hardware-based) diskless hosts, and so far everything looks good :)
2025-12-02 11:32:51 <omni> it works here too
2025-12-02 11:34:59 <omni> btw, the other day I had a hard freeze of a system and I found no way to get out of it - a very long time since that happened to me and not sure I've experienced it in alpine before
2025-12-02 11:40:32 <ncopa> omni: what kernel was it?
2025-12-02 11:40:49 <ncopa> liske: good to hear. thanks!
2025-12-02 11:42:46 <adrian> yup, 6.18.0 works fine on ppc64le as well
2025-12-02 11:42:56 <ikke> adrian: thanks for testing!
2025-12-02 11:46:38 <ncopa> awesome!
2025-12-02 11:46:50 <ncopa> i didnt know anyone was actually using ppc64le :)
2025-12-02 11:48:27 <adrian> I'm sure that I'm not the only one, but I don't think there's many of us :D
2025-12-02 11:55:59 <omni> ncopa: 6.12.59 or maybe .58 (forgot exactly when it happened)
2025-12-02 11:57:15 <ncopa> huh. weird
2025-12-02 12:02:12 <Habbie> remind me, is the riscv64 runner real or qemu?
2025-12-02 12:03:22 <achill> they are all real ones
2025-12-02 12:03:26 <Habbie> ok
2025-12-02 12:03:28 <achill> riscv64 is just terribly slow
2025-12-02 12:03:39 <Habbie> yeah
2025-12-02 12:03:49 <Habbie> we have some tests (in community/dnsdist) that fail on really slow machines
2025-12-02 12:03:54 <Habbie> usually i get away with a retry
2025-12-02 12:28:47 <achill> yeah if it fails because of it being slow, you can also skip it for riscv64. flaky tests are not why we're running tests in alpine
2025-12-02 12:29:21 <Habbie> ack
2025-12-02 12:57:51 <Habbie> retry worked :)
2025-12-02 13:42:03 <ncopa> I'm gonna tag -rc2 as soon the builders are idle https://build.alpinelinux.org/
2025-12-02 13:42:56 <ncopa> drats
2025-12-02 13:43:03 <ncopa> Host is unreachable
2025-12-02 13:45:20 <Habbie> 'then surely they are also idle'
2025-12-02 13:45:46 <ncopa> mre like dead
2025-12-02 14:27:53 <Habbie> and after the working retry i noticed a complaint from the apkbuild linter :>
2025-12-02 14:48:18 <adrian> FYI the BTF debuginfo enablement increased the linux-lts size on ppc64le quite a bit - from 79MiB to 355MiB
2025-12-02 14:48:33 <adrian> as far as i can tell the default /boot partition size setup-disk creates is 256MiB
2025-12-02 14:48:45 <adrian> so it will run out of space on those installs now
2025-12-02 14:49:52 <haesbaert> did anything else ride with the BTF enablement? I'm surprised it jumped by that much
2025-12-02 14:50:02 <adrian> it's really just debuginfo that bloats it so much
2025-12-02 14:50:58 <adrian> 6.18.0-r1 was 80MiB, 6.18.0-r2 is 355
2025-12-02 14:52:42 <adrian> I nuked the 4G swap that get created by default so I could extend my /boot, but this is not particularly great
2025-12-02 14:52:54 <ncopa> aw
2025-12-02 14:53:10 <ncopa> i think its needed for eBPF programs
2025-12-02 14:53:23 <adrian> Yeah IIRC it is
2025-12-02 14:53:42 <ncopa> i thought that dwarf5 should make it usuable
2025-12-02 14:53:46 <haesbaert> it is, it's basically a description of every function/argument/structure/offset of the kernel
2025-12-02 14:54:08 <haesbaert> wait, when you say debuginfo, you're not saying that vmlinuz-lts is now 355MB right?
2025-12-02 14:54:13 <ncopa> doesnt make sense with 355MB
2025-12-02 14:54:20 <ncopa> the x86_64 kernel size is
2025-12-02 14:54:26 <ncopa> linux-lts-6.18.0-r2 installed size:
2025-12-02 14:54:26 <ncopa> 141 MiB
2025-12-02 14:54:35 <adrian> apk info says installed size is 355MiB
2025-12-02 14:54:42 <ncopa> we should be able to get the ppc64le kernel down similar size
2025-12-02 14:54:43 <adrian> and I do get out of space errors when upgrading
2025-12-02 14:55:19 <haesbaert> also, do we really care about btf in ppc64le? since we don't have systemd bpf probes, bpf usage is mostly confined to specific things, and a lot of probes are written with amd64/arm64 in mind.
2025-12-02 14:55:33 <ncopa> can you try find out what we can do to reduce the size? I suppose we can always disable btf?
2025-12-02 14:55:40 <lotheac> out of that 355MiB some (most?) should be in /lib/modules, not /boot, no?
2025-12-02 14:55:48 <adrian> let me check
2025-12-02 14:56:11 <ncopa> there may be some config knob to reduce size similar to x86_64
2025-12-02 14:56:26 <ncopa> or we can disable BTF til someone asks for it
2025-12-02 14:56:29 <haesbaert> I'd point out that we had no btf for awhile and no one noticed, it might make sense to just zap it
2025-12-02 14:56:30 <ncopa> it was off before
2025-12-02 14:56:34 <ncopa> yeah
2025-12-02 14:56:41 <adrian> 317M Dec  2 12:40 vmlinuz-lts*
2025-12-02 14:56:47 <haesbaert> whooot
2025-12-02 14:56:50 <haesbaert> something is off
2025-12-02 14:57:02 <ncopa> i enabled to so it would be more in sync with the rest of the kernels
2025-12-02 14:57:03 <haesbaert> are there no modules in ppc64le?
2025-12-02 14:57:05 <adrian> after strip:
2025-12-02 14:57:06 <adrian> 41M Dec  2 15:57 vmlinuz-lts*
2025-12-02 14:57:07 <lotheac> yeah... my amd64 vmlinuz-lts is 14M
2025-12-02 14:57:09 <adrian> so yeah it's debuginfo
2025-12-02 14:57:25 <adrian> there are modules
2025-12-02 14:57:30 <adrian> 38MB of modules
2025-12-02 14:57:46 <haesbaert> exactly, how come is 317M when amd64 is still 14M, both with btf
2025-12-02 14:58:00 <ncopa> its problaby more extensive debug info
2025-12-02 14:58:21 <haesbaert> maybe it uses another dwarf?
2025-12-02 14:59:13 <adrian> so on ppc64le with linux-stable which has the same size problem, i have the following: https://mystb.in/a55136edc4a631138a
2025-12-02 14:59:18 <adrian> what does that look like on x86_64?
2025-12-02 14:59:54 <adrian> oh, zstd compression for debuginfo may help
2025-12-02 14:59:59 <ncopa> ncopa-desktop:~$ grep DEBUG_INFO /boot/config-6.1* | tpaste
2025-12-02 14:59:59 <ncopa> https://tpaste.us/KxB9
2025-12-02 15:00:52 <adrian> i think compressed and/or split debuginfo would probably help
2025-12-02 15:01:07 <haesbaert> looks like the same to me
2025-12-02 15:01:19 <ncopa> i dont think its lack of compression
2025-12-02 15:01:22 <ncopa> its something else
2025-12-02 15:01:26 <adrian> but still, wtf is going on here, x86_64 and ppc64le debuginfo configs look identical
2025-12-02 15:01:49 <haesbaert> there might be a bug, I honestly think "no one" uses btf on ppc64le
2025-12-02 15:02:02 <haesbaert> maybe they're repeating the symbol X times
2025-12-02 15:02:51 <haesbaert> just for kicks, what do you get with:
2025-12-02 15:02:54 <haesbaert> doas bpftool  btf dump id 1 |wc
2025-12-02 15:03:02 <adrian> fedora does use it
2025-12-02 15:03:11 <adrian> https://mystb.in/2ff9f238edb52df348
2025-12-02 15:03:13 <adrian> fedora ^
2025-12-02 15:03:35 <adrian> 63M Nov 24 01:00 vmlinuz-6.17.9-200.fc42.ppc64le
2025-12-02 15:03:39 <adrian> way smaller on fedora too
2025-12-02 15:05:53 <haesbaert> what's the size of /sys/kernel/btf/vmlinux ?
2025-12-02 15:05:59 <haesbaert> I get 4.6M in amd64
2025-12-02 15:06:02 <adrian> haesbaert: with linux-stable:    230831    795666   9299582
2025-12-02 15:06:22 <adrian> 4.1M
2025-12-02 15:06:51 <haesbaert> can you check if there is a pornographic btf size in /sys/kernel/btf/ ? cause vmlinux is basically the only thing that matters
2025-12-02 15:07:21 <haesbaert> 9299582 that's about a bit smaller than my amd64: 10675225, so all good there
2025-12-02 15:07:33 <adrian> looks normal: https://mystb.in/51a62937719635fbf2
2025-12-02 15:07:46 <haesbaert> odd, something is off for sure
2025-12-02 15:10:09 <ncopa> is the x86_64 kernel stripped?
2025-12-02 15:11:02 <ncopa> is the ppc64le kernel compressed?
2025-12-02 15:12:57 <ncopa> maybe we should split the debuginfo to a linux-lts-dbg?
2025-12-02 15:13:33 <lotheac> well - config DEBUG_INFO_BTF: depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
2025-12-02 15:14:24 <lotheac> seems to me splitting is incompatible with btf
2025-12-02 15:14:50 <adrian> i'm actually not so sure how to tell whether the kernel is compressed
2025-12-02 15:15:28 <adrian> since it would be self decompressing i guess
2025-12-02 15:15:48 <adrian> but from what i can see in binwalk, it doesn't seem to be compressed
2025-12-02 15:17:06 <adrian> ah yeah binwalk on x86_64 only sees gzipped data in the vmlinuz
2025-12-02 15:20:44 <Habbie> a nice trick to see if something is compressed is to try to compress it
2025-12-02 15:20:44 <lotheac> CONFIG_KERNEL_GZIP=y is not set?
2025-12-02 15:21:08 <adrian> it is set on ppc64le
2025-12-02 15:24:35 <mick_ibm> hey im online here... i have a contact on the kernel team at ibm that can assist with future issues on ppc64le. what is the current issue with power right now?
2025-12-02 15:34:17 <clandmeter> for the record, if anyone wants to take over any of my aports, please go ahead. I'm too busy to follow them up on the tracker. /cc mio 
2025-12-02 15:35:09 <adrian> https://github.com/torvalds/linux/blob/master/arch/powerpc/boot/Makefile#L437
2025-12-02 15:35:25 <adrian> i think zImage is just a symlink to the first kernel image built, aka vmlinux?
2025-12-02 15:35:40 <adrian> so it ends up being uncompressed, and there's multiple compressed variants for different targets like pseries
2025-12-02 15:36:08 <adrian> though my makefile-fu is not particularly great so i may be wrong
2025-12-02 15:43:40 <ncopa> mick_ibm: we enabled DEBUG_INFO_BTF on ppc64le kernel config and size became 355MB. on x86_64 it is 141MB. we would like to know why, and if we can get it down to a size corresponding to x86_64
2025-12-02 15:44:03 <ncopa> alternatively we can disable BTF on ppc64le (like we do on 32 bit kernels)
2025-12-02 15:49:19 <mick_ibm> i think disabling it is ok for now. im waiting for response from others with more bpf experience because this seems familiar to something that happened on fedora coreos kernels on power
2025-12-02 15:51:11 <mick_ibm> from my "limited" knowledge, the primary use case for alpine on ppc64le is ci/cd and i dont know anyone using bpf on alpine on ppc64le
2025-12-02 15:56:50 <haesbaert> as someone with no stakes on ppc64, but that does bpf at $dayjob for a living, I think disabling is likely ok, a good chunk of probes end up only working on tested architectures anyway
2025-12-02 15:57:30 <ncopa> ok. will do
2025-12-02 15:57:34 <ncopa> after rc2
2025-12-02 16:00:49 <ncopa> please hold any bigger builds til rc2 is out. I'm waiting for the build-3-23-riscv64 to complete its build
2025-12-02 16:21:39 <ncopa> 216 passed, 432 warnings in 1740.71s (0:29:00)
2025-12-02 16:21:51 <ncopa> the installer script works
2025-12-02 16:22:04 <mick_ibm> ncopa : what target level of power hardware are you building on? power9 or power10?
2025-12-02 16:22:19 <ncopa> how do I check? i think its power9
2025-12-02 16:22:46 <ncopa> cpu             : POWER9, altivec supported
2025-12-02 16:25:39 <mick_ibm> ok thanks
2025-12-02 16:26:03 <quinq> mick_ibm, provide Alpine with access to some Power10 hardware, and maybe it could happen ;)
2025-12-02 16:26:39 <mick_ibm> haha i wish i could help there :) 
2025-12-02 16:29:16 <mick_ibm> well, does it have to be a bare metal power machine? because osu has p10's available with kvm enabled if that helps... i think they are LPARs with KVM. another engineer mentioned btf size drops significantly on p10 but i dont know why
2025-12-02 16:32:54 <ncopa> we probably want build kernel so it can run on power9 as well
2025-12-02 16:36:00 <socksinspace> Saijin_Naib[m]: thanks for the inspiration to run some benchmarks, apparently sysbench memory is 1.3 times as fast and sysbench threads 1.7 times as fast, comparing 6.12 and 6.18 on my EeePC
2025-12-02 16:36:26 <achill> i think power9 is fine if we're not lifting the baseline anyway
2025-12-02 16:39:59 <socksinspace> is power9 still the newest that is available to "regular" people (with deep pockets)
2025-12-02 16:45:13 <ikke> Some were happy we still provided p9
2025-12-02 16:46:45 <mick_ibm> https://osuosl.org/services/powerdev/
2025-12-02 16:49:09 <mick_ibm> also p9 and p10 machines are available in github actions as self-hosted runners too 
2025-12-02 16:50:52 <socksinspace> i meant available as in "i don't need to sell both my kidneys to have the hardware" :P
2025-12-02 17:02:10 <ncopa> 10/49 packages to build on riscv64 ...
2025-12-02 17:02:22 <ncopa> i hope I reach tag rc2 later tonight
2025-12-02 17:04:24 <achill> FYI a new go security release came out, i would like to rebuild all go packages after rc2 is tagged
2025-12-02 17:06:21 <achill> also i think ill disable cosmic on riscv64, at least temporarily, otherwise we can forget the rc2 today
2025-12-02 17:34:25 <Saijin_Naib[m]> socksinspacePretty freaking sweet, right?! I knew it felt significantly faster since doing my work is pretty painful on this machine, so I _had_ to check and make sure I wasn't just placebo'ing myself
2025-12-02 17:35:44 <Saijin_Naib[m]> Also, ncopa, thank you for the XFS Online Scrub/Repair fix. Works brilliantly and makes me breathe easier about the machines I maintain for my family now that I can keep the FS a bit more healthy without direct intervention
2025-12-02 19:50:20 <Noisytoot1> does ppc64le alpine run on power8?
2025-12-02 19:52:21 <Ariadne> yes
2025-12-02 20:31:04 <ncopa> build-3-23-riscv64 is slow....
2025-12-02 20:31:51 <ikke> especially single-core..
2025-12-02 20:32:56 <ncopa> it runs on same pioneer machine as build-edge-riscv64
2025-12-02 20:33:22 <ncopa> i think im gonna try this lxc-freeze command and see what it does to build-edge-riscv64....
2025-12-02 20:33:58 <ncopa> oh yarr is single core build...
2025-12-02 20:41:43 <mick_ibm> ncopa where is the kernel configs for ppc64le? just curious if youre using CONFIG_DEBUG_INFO_BTF or CONFIG_DEBUG_INFO_REDUCED
2025-12-02 20:42:10 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-lts/lts.ppc64le.config
2025-12-02 20:42:22 <mick_ibm> thanks
2025-12-02 20:44:56 <ncopa> that is not full config. its the base for make olddefconfig
2025-12-02 20:46:41 <ncopa> the full config is here: curl --silent https://cdn.alpinelinux.org/v3.23/main/ppc64le/linux-lts-6.18.0-r2.apk | tar -zx -O - boot/config-6.18.0-2-lts
2025-12-02 20:47:11 <ncopa> I use CONFIG_DEBUG_INFO_BTF. I think it depends on !CONFIG_DEBUG_INFO_REDUCED
2025-12-02 20:47:50 <mick_ibm> i think you can have both =y , CONFIG_DEBUG_INFO_REDUCED=y 
2025-12-02 20:48:55 <ncopa> i think not. https://cateee.net/lkddb/web-lkddb/DEBUG_INFO_BTF.html
2025-12-02 20:48:58 <Antiz> Hi, allow me to repost my question from #alpine-linux here (maybe a more appropriate channel):
2025-12-02 20:49:08 <Antiz> I see that atools (Leo/atools) is archived and that the shell apkbuild-lint script it ships has been marked as deprecated in the package of the same name.
2025-12-02 20:49:17 <Antiz> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/atools/APKBUILD#L36
2025-12-02 20:49:20 <ncopa> depends on: (! CONFIG_DEBUG_INFO_SPLIT && ! CONFIG_DEBUG_INFO_REDUCED ) 
2025-12-02 20:49:31 <Antiz> As far as I understand, atools-go (infra/atools-go) is now the preferred source. Question is, is there any technical reason why the former / deprecated atools package is still distributed in the repo?
2025-12-02 20:49:43 <Antiz> For the context, I'm about to push atools-go to the Arch Linux repository but I'm wondering if I should still keep the deprecated atools package around for some reason (as currently done in Alpine) or if I can just drop it (and have atools-go replacing it)?
2025-12-02 20:52:49 <ncopa> cool that you are packaging atools to Arch. I don't know
2025-12-02 20:53:33 <mick_ibm> ncopa: haha thanks for that link, busted! XD ok ill keep digging into this. waiting for others to come online 
2025-12-02 20:53:41 <ikke> Antiz: atools-go is not a complete replacement for atools yet
2025-12-02 20:53:52 <ikke> It only provides apkbuild-lint at the moment
2025-12-02 20:54:35 <Antiz> ncopa: Thanks :) I've packaged a bunch of Alpine packaging tooling, allowing people to build / maintain Alpine packages directly from an Arch Linux system (see https://wiki.archlinux.org/title/Abuild)
2025-12-02 20:54:53 <ikke> So for the other scripts, and the man-pages, you still need atools
2025-12-02 20:55:53 <Antiz> ikke: Ah, okay that makes sense. Thanks! I'll guess I'll keep the two around for now then.
2025-12-02 21:00:16 <achill> yeah this is really cool indeed
2025-12-02 21:00:36 <achill> already got to use it a couple of time
2025-12-02 21:01:00 <Antiz> achill: Nice 😄
2025-12-02 21:01:26 <Antiz> I'm also using it to maintain my Alpine packages 👼
2025-12-02 21:48:13 <ncopa> >>> rust-analyzer: Build complete at Mon, 24 Nov 2025 17:00:42 +0000 elapsed time 1h 6m 19s
2025-12-02 21:48:19 <ncopa> 1 hour to build rust-analyzer
2025-12-02 21:48:29 <ncopa> i dont think i will wait that long. need to sleep
2025-12-02 21:48:30 <ncopa> :-(
2025-12-02 21:48:43 <ncopa> this looks dark
2025-12-02 21:48:52 <ncopa> will likely not get the 3.23 out before I go on vacation
2025-12-02 21:52:00 <achill> we can kick rust-analyzer and disable it, tag rc, enable it again
2025-12-02 21:52:25 <ncopa> there are still 19 packages to build...
2025-12-02 21:52:45 <achill> yeah i dont know which and how long they take
2025-12-02 21:57:56 <ncopa> started Tue, 02 Dec 2025 21:14:17 +0000
2025-12-02 21:58:04 <ncopa> it will probably need another 20 mins
2025-12-02 21:58:12 <ncopa> for rust-analyzer
2025-12-02 22:01:19 <ncopa> those are the packages left to build https://tpaste.us/j1Bo
2025-12-02 22:07:35 <ncopa> i think it will need at least two more hours
2025-12-02 22:07:56 <ncopa> i better go to bed now and try get up early instead
2025-12-02 22:12:29 <achill> yeah thats reasonable, sleep well!
2025-12-02 22:13:36 <ncopa> i htink im gonna push kernel rebuild first, so linux-lts -r3 is done tomorrow morning
2025-12-02 22:15:45 <socksinspace> very reasonable indeed, should probably do that too
2025-12-02 22:15:48 <ncopa> achill: if you want to help, can you look over issues and MRs with target 3.23?
2025-12-02 22:15:55 <ncopa> or anyone else
2025-12-02 22:16:11 <ncopa> and move everythign that is not absolute blockers for 3.23 to target 3.24
2025-12-02 22:17:34 <ncopa> then we may be able to do both -rc3 and release tomorrow. or we do 3.23.0 thursday
2025-12-02 22:22:17 <achill> yup will do that
2025-12-02 22:28:43 <ncopa> i already did
2025-12-02 22:28:55 <ncopa> but can you check static pies in releas notes? https://gitlab.alpinelinux.org/alpine/aports/-/issues/17294#note_524739
2025-12-02 22:29:54 <ncopa> I dont know if we want solve this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15409#note_547110
2025-12-02 22:47:04 <quinq> Out of curiosity, why changing the lts kernel to mainline (instead of contiuning on longterm)
2025-12-02 22:52:23 <ncopa> the last kernel each year ends up as LTS
2025-12-02 22:52:32 <ncopa> so 6.18 is expected to be the next LTS
2025-12-02 22:53:33 <quinq> Ah, didn't know that, thanks :)
2025-12-02 22:53:55 <ncopa> if the builders are not idle tomorrow morning im gonna nuke stuff
2025-12-02 23:03:34 <omni> is it intentional that landlock is not configured for loongarch64 and riscv64?
2025-12-02 23:13:07 <achill> ncopa: btw we now have zfs userspace tools 2.3 with zfs 2.4 built against -lts, i have to say im not really a fan of it
2025-12-02 23:13:57 <achill> i think i'll then backport 2.4.x to 3.23, once it comes out, since that will most likely do less issues that right now
2025-12-02 23:23:33 <omni> oh, uhm... I thought those should be kept in sync...
2025-12-02 23:24:40 <omni> I did read from todays FreeBSD 15.0-RELEASE Announcement that they ship with zfs 2.4.0-rc4
2025-12-02 23:24:45 <omni> https://www.freebsd.org/releases/15.0R/announce/
2025-12-03 01:44:21 <tomalok> ncopa: there is a docker 29.1.2 that fixes CVEs, i will try to get that updated tonight (us/pacific) hopefully before 3.23 is cut
2025-12-03 05:00:14 <tomalok> docker-29.1.2's all merged
2025-12-03 06:05:22 <ncopa> morning
2025-12-03 06:05:30 <ncopa> oh we need zfs upgraded as well
2025-12-03 06:08:24 <ncopa> and I think xtables-addons as well
2025-12-03 06:42:57 <ncopa> alright -rc2 tagged
2025-12-03 06:46:18 <moha-al> Hi! Wanted to ask whether there is a Docker image with the RC1 for 3.23 available? (Didn't see one on Docker Hub)
2025-12-03 06:47:26 <ikke> moha-al: We don't generate docker images for RCs
2025-12-03 06:48:05 <ikke> moha-al: You could import the minirootfs in the image though: https://cdn.alpinelinux.org/v3.23/releases/x86_64/alpine-extended-3.23.0_rc1-x86_64.iso.sha512
2025-12-03 06:48:23 <ikke> https://cdn.alpinelinux.org/v3.23/releases/x86_64/alpine-extended-3.23.0_rc1-x86_64.iso
2025-12-03 06:49:05 <moha-al> Thanks, I'll give that a try!
2025-12-03 07:47:21 <ncopa> i think the correct url is: https://cdn.alpinelinux.org/v3.23/releases/x86_64/alpine-minirootfs-3.23.0_rc2-x86_64.tar.gz
2025-12-03 07:51:18 <ikke> sorry, yes
2025-12-03 07:56:50 <moha-al> Yes, figured that out based on https://github.com/alpinelinux/docker-alpine/blob/v3.22/x86_64/Dockerfile . Building the image locally works just fine, thanks again!
2025-12-03 10:01:53 <omni> do I need to rebuild a apk database or something? I occasionally have odd dependency issues, like missing -doc subpackages
2025-12-03 10:02:20 <omni> and it seem to differ between installations
2025-12-03 10:04:24 <omni> and now it got corrected by an additional `apk -aU upgrade`..
2025-12-03 10:21:12 <omni> I wonder if a "merge-conflict" tag would be useful, I know that there is "mr-needs-rebase" but think it is less specific but still useful for when there is no merge conflict
2025-12-03 10:22:21 <ikke> omni: Could you make an MR against infra/gitlab-tf?
2025-12-03 10:31:07 <ncopa> do we accept packages that will rmmod and modprobe stuff from post-install? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92787
2025-12-03 10:33:44 <omni> feels a bit like restarting services...
2025-12-03 10:34:19 <ncopa> exactly
2025-12-03 10:34:21 <omni> I also have a few other questions wrt that MR
2025-12-03 10:34:51 <Sheila> my opinion is "tell the user to restart or reload $xyz modules" rather than doing it automatically.
2025-12-03 10:35:03 <omni> like, should it not be two aports? is the license valid also for the file taken from firmware-nonfree?
2025-12-03 10:35:23 <omni> Sheila: I agree
2025-12-03 10:37:03 <omni> why not the upstream name raspberrypi-sys-mods?
2025-12-03 10:37:12 <ncopa> no idea
2025-12-03 10:37:22 <ncopa> ask in the MR
2025-12-03 10:37:29 <ncopa> its not ready for merging
2025-12-03 10:37:29 <omni> yeah
2025-12-03 10:37:38 <omni> I'll do that
2025-12-03 10:40:48 <Sheila> I don't understand why this can't just be included alongside the APKBUILD: https://github.com/RPi-Distro/firmware-nonfree/blob/trixie/debian/rpi-brcmfmac.conf
2025-12-03 10:42:55 <Sheila> like, if the options change in a future version of raspi's firmware-nonfree, you'd need to update to point to the new file anyway so you're not saving any time by doing it this way.
2025-12-03 10:54:36 <ncopa> oh no 300+ packages to build
2025-12-03 10:57:19 <ikke> ..
2025-12-03 10:57:42 <Sheila> re copyright: I don't think the brcmfmac.conf would be copyrightable material since it's not expressive in any way; the documentation provided in the commit that added it to that repo would be, but it's not included (and really should be given that otherwise a user won't understand what this is doing).
2025-12-03 10:58:34 <omni> if only we had a way to know what golang aports to rebuild for a community/go security upgrade
2025-12-03 10:59:04 <ncopa> this is a nightmare
2025-12-03 10:59:11 <ncopa> i was hoping to get 3.23 out today
2025-12-03 10:59:24 <ncopa> but i think the ship may have sailed for tomorrow as well
2025-12-03 10:59:37 <ncopa> which means earliest next week wednesday
2025-12-03 10:59:44 <ncopa> unless someone else does the release
2025-12-03 11:01:42 <ncopa> i suppose I could nuke all the go packages
2025-12-03 11:02:00 <ncopa> and let users use go install like they are supposed to
2025-12-03 11:03:39 <Sheila> `go install it_yourself` :v
2025-12-03 11:12:52 <ncopa> ok. how do we solve this so we get the release out today?
2025-12-03 11:14:05 <ncopa> im reverting go fix
2025-12-03 11:19:37 <ncopa> maybe that was a mistake
2025-12-03 11:19:40 <ncopa> i dont knwo what to do
2025-12-03 11:22:21 <ncopa> im stopping all edge builders
2025-12-03 11:25:20 <omni> take a step back and breathe
2025-12-03 11:25:53 <ncopa> problem is that builders continue build
2025-12-03 11:25:57 <ncopa> need to stop them first
2025-12-03 11:26:56 <omni> can someone else?
2025-12-03 11:26:59 <omni> ikke: ?
2025-12-03 11:27:20 <ncopa> they are stopped now
2025-12-03 11:27:29 <ikke> How can I help?
2025-12-03 11:28:51 <ncopa> dunno yet
2025-12-03 11:29:00 <ncopa> lets tag the release 3.23 now. ready or not
2025-12-03 11:29:07 <ncopa> here is the plan
2025-12-03 11:29:15 <ncopa> i mean here is the status
2025-12-03 11:29:31 <ncopa> go secfix was pushed + 597 rebuilds
2025-12-03 11:29:39 <ncopa> that is gonna take 2+ days on riscv64
2025-12-03 11:29:50 <ncopa> so I reverted the update and rebuilds
2025-12-03 11:30:00 <ikke> Yes, I saw that
2025-12-03 11:30:09 <ncopa> problem is that edge was continue building
2025-12-03 11:30:16 <ncopa> so i stopped all edge machines
2025-12-03 11:30:24 <ikke> ack
2025-12-03 11:30:31 <ncopa> the plan is to keep edge stopped til 3.23 is branches
2025-12-03 11:30:53 <ncopa> then they will continue build where they left off
2025-12-03 11:31:05 <ncopa> and we need to bacport the secfixes to 3.23 after its branched
2025-12-03 11:31:42 <ncopa> so now we just drop everythign in our hands and get 3.23 out the door. keep edge builders off til that is done
2025-12-03 11:33:00 <ncopa> im gonna take 10mins
2025-12-03 11:38:00 <ikke> Lets build everything static, they said, it's fine, they said
2025-12-03 11:42:59 <skarnet> isn't it?
2025-12-03 11:49:12 <ikke> Rebuilding close to 600 packages to fix a security issue in a module with packages where lots of tests constantly fail doesn't sound like quite feasible to me
2025-12-03 11:50:44 <omni> the problem here is that security updates to go warrant rebuilds of some aports but we have no way of tracking when what aport needs to be rebuilt for a given security fix, so we rebuild all of them
2025-12-03 12:42:01 <Kladky> I've always wondered, why does every go package get rebuilt when there is a go upgrade, when the same doesn'r seem to apply for rust?
2025-12-03 12:44:58 <achill> because rusts stdlib is smaller and has less CVEs
2025-12-03 12:53:09 <Kladky> Ah, so when there is a CVE, the same thing would need to happen?
2025-12-03 12:54:09 <Kladky> It's kinda surprising though, since it feels like go packagss are rebuilt with every go upgrade.
2025-12-03 12:54:35 <adrian> the go standard library is massive
2025-12-03 12:54:43 <adrian> amongst other things it includes crypto and tls
2025-12-03 12:54:54 <adrian> which is particularly prone to CVEs
2025-12-03 12:54:55 <achill> about every second go release there are new CVEs, i cant remember when rust had their last one
2025-12-03 12:55:08 <adrian> rust has no crypto or tls in the standard library
2025-12-03 12:56:21 <omni> some SBOM tracking would be good
2025-12-03 12:57:26 <omni> not just for this but I also have the "feeling" that there are a lot of dependencies that have security issues and could/should be bumped in go.{mod,sum}
2025-12-03 13:17:00 <ncopa> I apologize for the meltdown earlier
2025-12-03 13:17:20 <ncopa> and I should have been clearer in the communication
2025-12-03 13:17:32 <ncopa> we need to get 3.23 out today and absolutely latest tomorro
2025-12-03 13:19:59 <ncopa> i think the only thing I am aware of that needs fixing was something with docker image. there is a test that fails when building docker image
2025-12-03 13:20:07 <ncopa> it fails due to some missing directory
2025-12-03 13:21:34 <ncopa> I think the problem is that /var/cache/apk is missing
2025-12-03 13:53:26 <ikke> 6.18 cobfirme lts
2025-12-03 13:54:12 <ikke> https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=b9ea3472ee1d973f4c27d075c7e4445afa7ade89
2025-12-03 14:03:53 <ncopa> phew... \o/
2025-12-03 15:34:43 <mick_ibm> ncopa unfortunately i no longer have a machine at osu to test alpine. im working on getting some hardware for our internal dev/testing. talking about the kernel configs on ppc64le, did you compare the size with DEBUG_INFO enabled? I saw the last commit removed DEBUG_INFO_BTF. the kernel team recommended DEBUG_INFO=y and DEBUG_INFO_BTF disabled
2025-12-03 15:36:01 <ncopa> i did not compare with DEBUG_INFO=y and DEBUG_INFO_BTF=n
2025-12-03 15:36:18 <ncopa> disabled it for now til someone has time to work on it
2025-12-03 15:47:00 <ncopa> im tagging 3.23.0 now
2025-12-03 16:01:55 <dne> \o/
2025-12-03 16:09:24 <ncopa> build-edge-* machines are now back online
2025-12-03 16:11:39 <ikke> ncopa: lmk if I can help
2025-12-03 16:12:06 <ncopa> lets finish up the release notes
2025-12-03 16:16:07 <ikke> "Users with / and /usr on separate filesystems (which is unsupported) will need to take special care" is this still the case, or has that to do with changes to mkinitfs?
2025-12-03 16:16:17 <ikke> initramfs*
2025-12-03 16:21:06 <mio> left that line in as wasn't sure what the current status is on usr-merge advisory for users
2025-12-03 16:21:13 <ikke> ncopa: we also already announced usr-merge, I suppose we need to update that?
2025-12-03 16:21:14 <mio> please feel free to change :)
2025-12-03 16:21:19 <ikke> https://alpinelinux.org/posts/2025-10-01-usr-merge.html
2025-12-03 16:24:26 <ncopa> ikke: yes special care is needed because various tools moved from /sbin or /bin to /usr
2025-12-03 16:24:47 <ncopa> which means they will not be available unless /usr is mounted
2025-12-03 16:25:26 <ncopa> i think it should "just work", but it is good that they need to be extra careful
2025-12-03 16:25:59 <ikke> The wiki page does not mention those details
2025-12-03 16:26:20 <ncopa> oh and https://alpinelinux.org/posts/2025-10-01-usr-merge.html is not fully updated
2025-12-03 16:26:29 <ikke> yes, I just linked to it
2025-12-03 16:26:48 <ncopa> it says new installs from 3.23 will be usr-merged, which is no longer the case
2025-12-03 16:26:52 <ncopa> we need to update that
2025-12-03 16:27:17 <ikke> I can work on that
2025-12-03 16:27:25 <ncopa> thanks!
2025-12-03 16:41:04 <ikke> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/115
2025-12-03 16:47:58 <ncopa> im not sure it is accurate. the exact migration plan is still under work
2025-12-03 16:48:06 <ikke> Right
2025-12-03 16:48:16 <ncopa> i think from 3.24 everythign will be usr-merged
2025-12-03 16:48:35 <ncopa> but I think we can leave it as that for now
2025-12-03 16:50:33 <ncopa> maybe we should write tat we are working on adjusting the migration plan so migration to usr-merge can happen without leaving apk db broken
2025-12-03 16:50:36 <ncopa> or something
2025-12-03 16:51:40 <ikke> Maybe we can leave out release versions and just mention the milestones
2025-12-03 16:52:09 <ncopa> yeah, and something that we are still working out the details
2025-12-03 16:55:04 <ncopa> ikke: can you help with: Invalidate /alpine/latest-stable/* on dl-cdn
2025-12-03 16:55:09 <ikke> yes
2025-12-03 16:55:11 <ncopa> i have updated the latest-stable symlink
2025-12-03 16:56:21 <ikke> Good
2025-12-03 17:03:18 <ikke> ncopa: it's running
2025-12-03 17:04:36 <ikke> I have updated https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/115
2025-12-03 17:04:43 <ncopa> thanks!
2025-12-03 17:04:54 <ncopa> I'm working on registry img
2025-12-03 17:05:24 <ncopa> ikke: can you please review this? https://gitlab.alpinelinux.org/img/alpine/-/merge_requests/10
2025-12-03 17:06:15 <ikke> ncopa: yes, checking
2025-12-03 17:08:23 <ncopa> oh there is also: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/113
2025-12-03 17:09:22 <ikke> ohj
2025-12-03 17:20:09 <ncopa> sigh... what we do about it
2025-12-03 17:21:00 <ncopa> seems like we have tonight to come up with an official announcement about usr-merge project
2025-12-03 17:21:08 <ikke> yup
2025-12-03 17:21:47 <ncopa> alright
2025-12-03 17:23:05 <ncopa> maybe something like: "we have previously announced that 3.23 should be usr-merged, but that has been postponed. We are still working on the [details]( https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/113)."
2025-12-03 17:59:47 <Ariadne> thanks :)
2025-12-03 18:01:04 <ncopa> does this look good now? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/9902fe4e648a90163d2c51597c23fae7c9db743b/posts/Alpine-3.23.0-released.md
2025-12-03 18:03:22 <ikke> "The package manager has been transitioned" -> "The package manager has been upgraded". Sounds a bit more natural to me
2025-12-03 18:04:22 <mio> ncopa: sorry, might have overwrote your latest change
2025-12-03 18:04:30 <mio> was trying to update the sponsors list
2025-12-03 18:04:36 <ncopa> ha
2025-12-03 18:04:46 <ncopa> no worries i did a push -f as well :)
2025-12-03 18:04:49 <ncopa> i have it locally
2025-12-03 18:05:10 <mio> okay, thanks :)
2025-12-03 18:06:05 <ncopa> well I had it. apparently git pull --rebase deletes it locally 
2025-12-03 18:06:40 <ikke> ncopa: reflog
2025-12-03 18:06:49 <ikke> git log -g <branchname>
2025-12-03 18:10:13 <ncopa> thanks
2025-12-03 18:10:18 <ncopa> they should be back now
2025-12-03 18:10:59 <ncopa> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/efd3d9f6904cdc1cbd15b4239060d40517947848/posts/Alpine-3.23.0-released.md
2025-12-03 18:24:11 <ncopa> some more spelling fixes and wording: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/68c970610f9f823ee1ef21b6fc0b1a64aed42118/posts/Alpine-3.23.0-released.md
2025-12-03 18:24:24 <ncopa> that should be final i think
2025-12-03 18:30:29 <ikke> ncopa: the announcement link is dead
2025-12-03 18:30:36 <ikke> "We previously announced that 3.23"
2025-12-03 18:30:52 <ikke> Unless you plan to push that
2025-12-03 18:31:26 <ikke> But I suppose you want to link to https://alpinelinux.org/posts/2025-10-01-usr-merge.html
2025-12-03 18:32:24 <ikke> Oh, it's a relative link
2025-12-03 18:40:26 <ncopa> if text is ok i'll merge it
2025-12-03 18:40:43 <ncopa> i merged it to master
2025-12-03 18:41:11 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.23.0-released.html
2025-12-03 18:41:14 <ikke> I just added a comment
2025-12-03 18:41:34 <ikke> the git log link is broken
2025-12-03 18:44:20 <ikke> ncopa: I can push a fix
2025-12-03 18:45:27 <ncopa> I already pushed sorry :)
2025-12-03 18:45:36 <ikke> np
2025-12-03 18:45:39 <ncopa> ok. im stepping out for a couple of hours
2025-12-03 18:45:45 <ncopa> feel free to upgrade gitlab
2025-12-03 18:46:02 <ikke> ack
2025-12-03 18:46:02 <ncopa> im gonna merge the post to prod later
2025-12-03 18:46:22 <ncopa> thank you very much for your help so far
2025-12-03 18:51:22 <mio> ikke: will you update for proofread suggestions in #-linux as well? could open a new MR to collect edits, whichever you prefer
2025-12-03 18:51:39 <ikke> Yes, I was just fixing that
2025-12-03 18:51:42 <ikke> from achill
2025-12-03 18:51:52 <mio> great, thanks
2025-12-03 18:54:25 <ikke> gitlab will be restarted in 5 minutes to upgrade to 18.6
2025-12-03 18:54:32 <ikke> Beware, the interface will change slightly
2025-12-03 19:05:23 <ikke> gitlab upgrade has finished
2025-12-03 19:07:32 <Biswa96[m]> greeted with AI feature :(
2025-12-03 19:07:43 <achill> its not enabled in our gitlab ^^
2025-12-03 19:07:59 <f_> achill: that's because our gitlab is old
2025-12-03 19:08:20 <achill> and because we dont have premium/ultimate: https://docs.gitlab.com/subscriptions/subscription-add-ons/#gitlab-duo-core
2025-12-03 19:08:24 <ikke> We neither
2025-12-03 19:08:37 <ikke> But gitlab still advertises it
2025-12-03 20:01:45 <Ermine> gitlab advertises it on all instances, no matter the tier
2025-12-03 20:05:52 <achill> when are we deploying the blog post on main?
2025-12-03 20:05:56 <achill> the docker image is alreayd out
2025-12-03 20:06:13 <ikke> achill: When ncopa is back today I suppose
2025-12-03 20:06:23 <achill> ah alright
2025-12-03 20:38:30 <ncopa> im back
2025-12-03 20:38:36 <ncopa> lets merge it
2025-12-03 20:38:46 <ncopa> unless there is more to fix
2025-12-03 20:38:59 <ikke> There was one issue that I fixed, let's ship it
2025-12-03 20:39:12 <ncopa> pushed
2025-12-03 20:39:27 <ncopa> mercy boco
2025-12-03 20:39:34 <ikke> 0https://alpinelinux.org/posts/Alpine-3.23.0-released.html
2025-12-03 20:39:45 <f_> woohoo!
2025-12-03 20:39:52 <mio> \o/
2025-12-03 20:40:24 <ncopa> \o/
2025-12-03 20:40:28 <ncopa> thank you everyone
2025-12-03 20:40:35 <ncopa> and thank you for your patience with me
2025-12-03 20:42:07 <durrendal> \o/ thank you everyone for all the hard work! 
2025-12-03 20:43:24 <Ermine> 
ACTION throws release confetti

2025-12-03 20:54:58 <socksinspace> oh, there is a toggle to get the old gitlab ui back, good
2025-12-03 20:55:59 <ikke> For now I suppose :P
2025-12-03 20:56:09 <ikke> I must say that I like the new interface
2025-12-03 20:56:48 <achill> o/
2025-12-03 20:59:11 <socksinspace> if i didn't change it back i probably would gotten used to it within a few days, but the continuous "inverted L" shape of the side and top bar just feels weird to me for some reason
2025-12-03 21:00:27 <socksinspace> or maybe it's the searchbar always taking up space, pushing the content down
2025-12-03 21:18:58 <ikke> oof, 70 pending CI jobs
2025-12-03 21:21:30 <ncopa> im gonna push the go update as well now
2025-12-03 21:21:38 <ncopa> 300+ packages to build
2025-12-03 21:22:59 <ikke> ncopa: wasn't that already reverted? Or for 3.23?
2025-12-03 21:23:12 <ncopa> for 3.23
2025-12-03 21:23:14 <ikke> ok
2025-12-03 21:24:08 <ncopa> so we get all the errors from edge i suppose
2025-12-03 21:24:36 <ncopa> i was planning to celebrate now but its kinda late
2025-12-03 21:28:55 <achill> i have tomorrow no real lectures and no assignments to do so for me it doesnt matter if its getting late :DDD
2025-12-03 21:30:14 <ncopa> alright lets celebrate then! \o/ \o/ \o/
2025-12-03 21:30:49 <ikke> I've been celebrating already
2025-12-03 21:31:11 <ikke> armv7 is the winner with 18 pending jobs
2025-12-03 21:45:54 <ncopa> thats what you get for stopping the train for a day
2025-12-03 21:46:39 <achill> https://www.phoronix.com/news/Alpine-Linux-3.23
2025-12-03 21:46:41 <ncopa> we have had some ups and downs to get this release out
2025-12-03 21:46:55 <ncopa> but I think we have a pretty awesome team
2025-12-03 21:47:01 <ncopa> and an awesome community
2025-12-03 21:54:18 <Saijin_Naib[m]> Congrats to all!
2025-12-03 22:48:53 <liske> \o/
2025-12-03 22:49:18 <Habbie> congrats!
2025-12-03 22:51:58 <tyler82_Desktop> I have some issue with creating a merge request on gitlab.alpinelinux.org. The wiki looks outdated. What is the correct procedure now?
2025-12-03 22:54:29 <tyler82_Desktop> if i want select my source, https://gitlab.com/tyler820201/aports  on gitlab.alpinelinux.org it does not show up.
2025-12-03 22:54:42 <Ermine> tyler82_Desktop: do you mean wiki.alpinelinux.org ? If yes, then it's independent of gitlab, you need to register another account there and edit its page
2025-12-03 22:54:51 <Ermine> ah
2025-12-03 22:55:08 <Ermine> you use wrong gitlab
2025-12-03 22:55:13 <Ermine> gitlab.alpinelinux.org
2025-12-03 22:55:35 <tyler82_Desktop> i know. i have both accounts now. gitlab and gitlab.alpinelinux as well. 
2025-12-03 22:56:40 <Ermine> https://gitlab.alpinelinux.org/tyler820201/aports doesn't exist
2025-12-03 22:57:13 <Ermine> alpine's gitlab doesn't integrate with gitlab.com, so they have different repositories
2025-12-03 22:58:19 <tyler82_Desktop> https://gitlab.alpinelinux.org/Kukuchai/aports  this is my alpinelinux one
2025-12-03 22:58:56 <Ermine> Okay, I don't see it either. Maybe it's private fork?
2025-12-03 22:59:14 <tyler82_Desktop> ohh...yes. is that an issue?
2025-12-03 22:59:37 <Ermine> Hm, it shouldn't be, but idr
2025-12-03 23:00:36 <Ermine> but maybe you want to change your fork's visibility in settings-general-visibility. Try and see if that works
2025-12-03 23:01:06 <tyler82_Desktop> i was asking ai it says using gitlab is not possible. i have to push it on github then use the github branch as source and the gitlab.alpinelinux one as target. But i dont believe on AI...
2025-12-03 23:01:22 <tyler82_Desktop> Ok.  will try then
2025-12-04 00:50:13 <omni> trying to figure out why my network interface is gone after upgrade, glad I can rollback to a previous snapshot
2025-12-04 00:51:07 <omni> this time around I've been too busy and missed opportunities to try release candidates before the release
2025-12-04 00:56:28 <socksinspace> hmm, i can see how the lack of a network interface might be problematic in this day and age
2025-12-04 01:01:23 <omni> at least I got my socks
2025-12-04 01:05:44 <omni> ah, the firmware moved from linux-firmware-other to linux-firmware-intel
2025-12-04 01:05:51 <omni> we should probably write someting about this
2025-12-04 01:06:41 <omni> and also fix whatever it is that still installs linux-firmware-{dell,hp,lenovo} when you add linux-firmware-intel
2025-12-04 01:12:26 <socksinspace> i have written down an idea that has been bouncing around in my head the last few days #17768
2025-12-04 01:15:17 <socksinspace> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17768
2025-12-04 01:19:49 <socksinspace> probably slightly incoherent, i really should go sleep
2025-12-04 01:30:54 <omni> so.. at one point after 3.22-release iwlwifi*.ucode moved from linux-firmare-other to linux-firmware-intel...
2025-12-04 01:39:14 <omni> ugh.. trying to write something in the wiki but am a bit tired..
2025-12-04 01:48:17 <omni> there https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.23.0#iwlwifi_firmware_has_moved_from_linux-firmware-other_to_linux-firmware-intel
2025-12-04 01:49:00 <omni> please move or rephrase as you see fit, I just wanted the information out
2025-12-04 01:50:29 <omni> I'm guessing something changed upstream and this change got in with an upgrade
2025-12-04 02:07:07 <omni> I have rebased and updated !65712
2025-12-04 02:07:22 <omni> algitbot: ?
2025-12-04 02:07:29 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65712
2025-12-04 02:18:43 <omni> ok, fail, will look at it another day
2025-12-04 02:39:45 <skarnet> I'm late to the party, but congratulations for the release!
2025-12-04 02:49:37 <lotheac> congrats from me as well, good job everyone :)
2025-12-04 05:17:34 <Saijin_Naib[m]> For ZSWAP (thanks again for enabling it @ncopa), is there any reason to not enable other compressors like LZ4 or ZSTD? They should have significantly higher speeds than LZO (thus lower latency) and should compress about as well or better.
2025-12-04 05:18:35 <Saijin_Naib[m]> Like, does enabling a different compressor bloat the kernel because now that needs to be enabled kernel-wide, so adding LZ4 or ZSTD is too much of an increase when LZO is presumably already used elsewhere?
2025-12-04 07:57:02 <caskd> Saijin_Naib[m]: zstd is enabled though
2025-12-04 07:57:08 <caskd> i am using it right now
2025-12-04 07:58:01 <caskd> it just isn't the default
2025-12-04 08:03:12 <Imbus> Im writing a thesis, and stumbled over a rockchip based SBC called radxa 3c. Since i run exclusively alpine on my pi's, i contemplated the possibility of porting alpine to it (as my thesis). I wrote a mail to copa about it but im sure hes busy.
2025-12-04 08:04:03 <Imbus> Now, this might be trivial, as in pulling their kernel patches, dts and u-boot special sauce
2025-12-04 08:05:01 <Imbus> Is this a good idea? Is this something that may be of interest upstream, like a dedicated release?
2025-12-04 08:05:41 <caskd> If the kernel requires patches and doesn't work purely on mainline it might require enough interest to have it upstreamed 
2025-12-04 08:05:53 <Imbus> I know that maintaining these types of ports arent free, but at this time, running anything else on an SBC seems like heresy to me
2025-12-04 08:06:30 <Imbus> Yeah of course caskd
2025-12-04 08:06:53 <caskd> You are free to always pick up the alpine SDK and build your own custom kernel/u-boot version which you can mix with rest of alpine upstream
2025-12-04 08:07:17 <caskd> and i highly recommend even publishing your work
2025-12-04 08:07:39 <Imbus> Im not married to radxa either. It would absolutely be nice to focus on a board with the original promise of the rpi's (cheap, available and capable)
2025-12-04 08:08:08 <Imbus> I hear you
2025-12-04 08:08:54 <Imbus> My experience in alpine is rather limited. This doesnt mean i cannot figure things out myself, but some guidance would be appreciated
2025-12-04 08:09:01 <caskd> SBCs are often a special case, i did build custom alpine images for 4 boards previously
2025-12-04 08:09:16 <caskd> I can assist you if you need help
2025-12-04 08:09:18 <Imbus> Which ones if you dont mind me asking?
2025-12-04 08:10:47 <caskd> rockpro64, bananapi m2b and m2z, zero3
2025-12-04 08:10:55 <Imbus> And caskd, is this enough work to back a thesis in your opinion?
2025-12-04 08:11:08 <Imbus> Got any sources or documentation on that process?
2025-12-04 08:11:22 <caskd> oough, the documentation part is always very sketchy
2025-12-04 08:11:42 <caskd> it heavily depends on the board manufacturer and platform
2025-12-04 08:11:46 <Imbus> Perhaps writing documentation *is* the work i could do here
2025-12-04 08:12:05 <caskd> that is something that is great
2025-12-04 08:12:19 <caskd> but if its enough to back a thesis is beyond me
2025-12-04 08:13:26 <Imbus> Some of these boards load funky firmware from /boot
2025-12-04 08:13:29 <Imbus> like pi and so on
2025-12-04 08:13:50 <Imbus> Im not even sure what stuff they patch in the kernel
2025-12-04 08:14:38 <caskd> If you have the kernel fork you can find the common ancestor commit and look at the changes on top of that
2025-12-04 08:14:48 <caskd> git is your friend
2025-12-04 08:14:51 <Imbus> Yeah, im aware
2025-12-04 08:15:24 <Imbus> But given that you already did a few boards, howcome those are not available?
2025-12-04 08:16:01 <caskd> because they were special cases and i don't own or use any of them anymore to actively maintain and test their support 
2025-12-04 08:16:54 <caskd> sometimes broken or outdated information can be worse than none
2025-12-04 08:17:19 <Imbus> Im aware that these may not be as well tested as regular releases
2025-12-04 08:17:44 <Imbus> Still would be nice to have images on a best-effort basis available
2025-12-04 08:17:54 <caskd> i agree on that
2025-12-04 08:18:28 <Imbus> Debian has one developer that does unofficial debian builds for rpi
2025-12-04 08:18:31 <caskd> maybe someone from the aports team can chime in on this  
2025-12-04 08:18:43 <caskd> and share their thoughts
2025-12-04 08:18:50 <Imbus> puts them on his private http server with disclaimers and so on
2025-12-04 08:21:21 <Imbus> Would be super cool tbh
2025-12-04 08:21:34 <caskd> Yeah, i think it would be great
2025-12-04 09:29:23 <ncopa> hi Imbus! sorry I haven't respond to the email. was thinking of it this morning
2025-12-04 09:29:50 <ncopa> i was thinking respond that we usually dont maintain board specific kernels
2025-12-04 09:29:58 <ncopa> or we try to avoid
2025-12-04 09:30:45 <ncopa> due to it adds maintenance burden
2025-12-04 09:31:14 <ncopa> that said, it is usually not that complicated to build a kernel, as long as you find the proper patches
2025-12-04 09:31:36 <ncopa> and the proper patches for the boot loader
2025-12-04 09:31:58 <lotheac> and dtb
2025-12-04 09:32:16 <ncopa> and dtb (usually goes with the kernel patches I guess)
2025-12-04 09:32:36 <lotheac> sorta yes, but you have to load the board-specific dtb somehow by configuring your bootloader to find it
2025-12-04 09:33:05 <ncopa> we try avoid add stuff that requires patches on top. upsteam usually have goo reasons to not include the patches (low quality, no long term maintenance plan etc)
2025-12-04 09:33:50 <ncopa> getting those patches in upstream is a good goal, and may be challenging (dealing with kernel devs may be challenging)
2025-12-04 09:34:35 <ncopa> I also think that risc-v is a more interesting architecture than ARM, in general
2025-12-04 09:34:45 <ncopa> arm has become mainline and is kinda boring :)
2025-12-04 09:35:49 <ncopa> risc-v is an open architecture, so you have usually more insight in low level stuff
2025-12-04 09:51:26 <Imbus> Yup, checked out the milk-v boards as well, mars has a quad core 1.5ghz with GC extensions. The radxa stuff interests me mostly because its cheap & available
2025-12-04 09:53:22 <Imbus> Maybe just slap a mainline kernel on a board and see if it works
2025-12-04 09:53:34 <ncopa> never heard of radxa before. how is performance?
2025-12-04 09:53:52 <ncopa> yeah, mainline kernel, which now is 6.18 may or may not work
2025-12-04 09:54:07 <Imbus> Its pretty fast i think, also a quadcore
2025-12-04 09:54:23 <ncopa> fast as in rpi5 or intel i9?
2025-12-04 09:54:47 <Imbus> havent done any benchmarks, but from my understanding should be comparable to pi4 at least
2025-12-04 09:55:12 <ncopa> ok, not impressively great IOW
2025-12-04 09:55:31 <Imbus> there are faster versions, but those are priced out of its intended application imo
2025-12-04 09:55:45 <Imbus> its an RK3566
2025-12-04 09:55:48 <Imbus> in the 3c
2025-12-04 09:57:14 <Imbus> the rock 5c beats pi5 iirc
2025-12-04 10:00:03 <ncopa> RK3588S2 yeah I'd expect that to be decent
2025-12-04 10:02:25 <ncopa> i would actually think that mainline kernel should work?
2025-12-04 10:03:18 <socksinspace> postmarketos already supports some rk3566 boards, might be worth to see if their rockchip kernel just works
2025-12-04 10:03:30 <socksinspace> if mainline doesn't end up working
2025-12-04 10:10:25 <caskd> true, i should've mentioned that
2025-12-04 10:10:42 <caskd> postmarketos often targets such special SBCs
2025-12-04 10:10:52 <caskd> and they might already have stuff that alpine doesn't
2025-12-04 10:12:35 <ncopa> the rock 5T looks interesting. support for 32G ram, and storage
2025-12-04 10:18:25 <Imbus> they have this case as well: https://radxa.com/products/accessories/metal-case-1290/
2025-12-04 10:19:07 <Imbus> But yeah, looking at ~400 eur total
2025-12-04 10:28:11 <omni> it was the 20250917 upgrade that moved iwlwifi ucode files from linux-firmware-other to linux-firmware-intel !90513 https://build.alpinelinux.org/buildlogs/build-edge-x86/main/linux-firmware/linux-firmware-20250917-r0.log
2025-12-04 10:34:25 <omni> perhaps it's easier to let iwlwifi stay in linux-firmware-intel, unless we think it's a problem that it grew more than four times in size
2025-12-04 10:34:49 <omni> on the up side, linux-firmware-other is pretty small now
2025-12-04 10:36:13 <omni> 79.2 MB -> 5.3 MB
2025-12-04 10:36:43 <ncopa> Saijin_Naib[m]: re zswap, i think the kernel config only selects the default compressor to be lzo (from upstream defconfig)? Can't you configure it to use zstd?
2025-12-04 10:52:08 <ncopa> Seems to be lots of build failures everywhere now
2025-12-04 10:53:11 <omni> but post 3.23.0!
2025-12-04 11:16:25 <omni> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/94206
2025-12-04 11:18:24 <omni> to be backported before more people run into missing wlan after upgrading from 3.22 to 3.23
2025-12-04 11:31:15 <ncopa> i think the only way to guard yourself against that kind of thing is to install all firmware. apk add linux-firmware
2025-12-04 11:31:25 <ncopa> when did iwlwifi move to intel?
2025-12-04 11:32:10 <ncopa> we could also doc how to get the needed firmware after kernel upgrade
2025-12-04 11:32:12 <ncopa> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/b3ead09e510e8555e81c405e53760f1b2432b805/setup-disk.in#L421
2025-12-04 11:32:52 <omni> I said above
2025-12-04 11:35:59 <omni> I've updated the commit message and MR description
2025-12-04 11:38:14 <omni> in my other MR you suggested that my then proposed linux-firmware-iwlwifi subpackage should depend on linux-firmware-other for backwards compability https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65712#note_416098
2025-12-04 11:38:22 <omni> but now the damage is already done
2025-12-04 11:39:45 <omni> the other way around, that linux-firmware-other should depend on linux-firmware-iwlwifi
2025-12-04 11:41:21 <omni> now that this has already happened, I don't think linux-firmware-other should depend on linux-firmware-intel (or a -iwlwifi, if we would have that) as it is rather large
2025-12-04 11:50:35 <ncopa> do we even need the iwlwifi now
2025-12-04 11:50:43 <ncopa> i think we dont
2025-12-04 11:51:08 <omni> I seemed to need it
2025-12-04 11:51:24 <omni> because upgrading to 3.23 left me without my wlan interface
2025-12-04 11:51:44 <omni> (I'm glad that I use snapshots and can easily roll back)
2025-12-04 14:04:23 <Saijin_Naib[m]> @ncopa at runtime, yes, but at boot it seems lz4 is a module and not loaded yet, so any pages in zswap as lzo stay and occupy space as a separate pool until fully discarded
2025-12-04 14:04:55 <Saijin_Naib[m]> @caskd you have it enabled at boot by kernel commandline? I need to try that, then! 
2025-12-04 14:06:05 <Saijin_Naib[m]> zstd might be a bit poky on my N3450, but it should still beat lzo
2025-12-04 14:06:09 <caskd> nope, you can also override it later
2025-12-04 14:06:38 <Saijin_Naib[m]> Yeah, at runtime I know, but I mentioned why that is a bit of an issue above
2025-12-04 14:06:42 <caskd> via /sys/module/zswap/parameters/compressor
2025-12-04 14:06:55 <caskd> oh
2025-12-04 14:07:52 <Saijin_Naib[m]> Yeah. Setting it at boot prevents pool fragmentation and losing limited memory to another pool
2025-12-04 14:08:04 <caskd> well, i enable it after setting the compressor at a later stage
2025-12-04 14:08:10 <caskd> not during boot
2025-12-04 14:08:33 <caskd> so i boot > have sysfs and modules loaded > set the compressor > enable zswap
2025-12-04 14:08:34 <Saijin_Naib[m]> Ah, okay, I set it all at boot
2025-12-04 14:08:47 <caskd> that should prevent it
2025-12-04 14:09:39 <caskd> in general i try to avoid setting anything during early boot except stuff that must be done then
2025-12-04 14:10:04 <caskd> such as IOMMU or kexec
2025-12-04 14:13:21 <Saijin_Naib[m]> If we change the zswap default compressor to lz4, it will match zram and be more performant
2025-12-04 14:14:56 <caskd> as it is right now it is matching the kernel default
2025-12-04 14:15:16 <caskd> i wonder why lzo is the default if lz4 is more performant
2025-12-04 14:16:09 <Saijin_Naib[m]> Great question. Slightly better compression ratio?
2025-12-04 14:16:52 <caskd> that might be it considering usually zswap or swap overall is meant to be a "overflow" memory in many cases
2025-12-04 14:16:57 <caskd> where speed matters less
2025-12-04 14:17:27 <caskd> in many cases IO latency might be way more significant than compression
2025-12-04 14:19:16 <Saijin_Naib[m]> So, the theory I read is to use the best compression to avoid swapping at all
2025-12-04 14:19:31 <caskd> i guess
2025-12-04 14:19:51 <Saijin_Naib[m]> In m case, swapping is a given, so I want the best speed/lowest latency and CPU overhead, hence lz4 or zstd
2025-12-04 14:20:36 <caskd> well, for that you can always override it
2025-12-04 14:22:32 <Saijin_Naib[m]> I dont know how without intervention since it needs elevation to set
2025-12-04 14:23:06 <Saijin_Naib[m]> I use this on my and family machines, so having it at boot means I can set it up once and forget about it
2025-12-04 15:15:53 <aj_> hi folks i try to build ceph v20.2.0 on alpine and had to aupgrade boost and recompile apache-arrow (with the new boost)
2025-12-04 15:16:53 <aj_> i crated a new MR for boost (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93942) however i'm new to work upstream on alpine so i would love to vae some comments
2025-12-04 15:21:27 <caskd> why not just upgrade the existing boost instead?
2025-12-04 15:21:42 <lotheac> achill: thanks for merging the binutils stuff, i was out busy. <3
2025-12-04 15:21:52 <ikke> ftr: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90458
2025-12-04 15:22:00 <achill> no thank you for the rebuilds! :3
2025-12-04 15:22:42 <ikke> the ceph maintainer seems to have it built with the existing boost
2025-12-04 15:23:13 <caskd> oh there is a MR for thos
2025-12-04 15:23:24 <caskd> i wonder if i should bite the bullet and test it
2025-12-04 15:23:39 <ikke> Oh: DWITH_SYSTEM_BOOST=OFF \
2025-12-04 15:26:38 <aj_> i was able to then build ceph with "my" new boost version, just wanna help and get ceph packes out the door
2025-12-04 15:31:51 <ncopa> anybody know why arti fails on 3.23 but not on edge? https://build.alpinelinux.org/buildlogs/build-3-23-armhf/community/arti/arti-1.8.0-r0.log
2025-12-04 15:32:45 <ikke> "
2025-12-04 15:32:47 <ikke> Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.
2025-12-04 15:32:49 <ikke> "
2025-12-04 15:32:56 <ikke> "OS can't spawn worker thread: Resource temporarily unavailable (os error 11)"
2025-12-04 15:34:22 <ncopa> is it flakiness?
2025-12-04 15:39:59 <ikke> https://stackoverflow.com/questions/62409492/how-to-solve-pthread-create-error-11-resource-temporarily-unavailable
2025-12-04 15:40:09 <ikke> stack exhaustion?
2025-12-04 15:40:56 <ikke> https://github.com/rust-lang/rust/issues/69140
2025-12-04 18:18:51 <ncopa> weird that we have so many build errors in 3.23 but they appear to pass in edge
2025-12-04 18:18:56 <ncopa> its not that big difference now
2025-12-04 19:45:32 <angeloverlain[m]> 
ACTION wonders why we have `-lang` subpkg and not subpkgs for each language... (e.g. `-lang-en_US`, `-lang-fr`, etc...) like fedora does

2025-12-04 19:45:33 <angeloverlain[m]> installing ALL languages when I really want one language is a bit... weird
2025-12-04 19:45:37 <angeloverlain[m]> see https://packages.fedoraproject.org/pkgs/langpacks/
2025-12-04 19:47:18 <Saijin_Naib[m]> How would they get split out?
2025-12-04 23:54:02 <iggy> aj_: (you're not here, but maybe you'll see this somehow) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/90458
2025-12-05 00:18:54 <omni> no sure who to assign #17771 to
2025-12-05 00:19:10 <Habbie> !17771
2025-12-05 00:19:14 <omni> "rsyslog crashes with "Segmentation fault" on v3.23" https://gitlab.alpinelinux.org/alpine/aports/-/issues/17771
2025-12-05 02:24:31 <Sheila> got another spurious version bump notif from aditya for nheko-0.12.1 due to someone pushing '0.12.1-1', whee.
2025-12-05 03:01:36 <Saijin_Naib[m]> At least your email host delivers them 🤣 I get nothing, ever
2025-12-05 05:37:45 <qaqland> aaudit's license is "unknown" https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aaudit/APKBUILD#L9
2025-12-05 07:37:21 <ikke> qaqland: Could you open an issue? Need to ask Fabled to license it
2025-12-05 08:55:33 <ncopa> 3.23 builds has still 275 packages to build. I’m glad I reverted the go build before tagging release
2025-12-05 08:58:01 <qaqland> ikke: #17776
2025-12-05 08:58:41 <qaqland> 
ACTION bot ..zZZ

2025-12-05 11:58:29 <omni> is algitbot muted or something in this channel?
2025-12-05 12:36:12 <omni> it would be interesting to know more about this https://lobste.rs/s/70rhjl/alpine_linux_3_23_0_released_apk_tools_v3#c_udqhyw
2025-12-05 12:36:34 <ikke> No, just stuck / hanging / not- functional until I restart it
2025-12-05 12:37:18 <omni> ok
2025-12-05 12:37:47 <omni> I saw that it worked elsewhere
2025-12-05 12:43:08 <ikke> sircbot consists of multiple components 
2025-12-05 15:33:29 <socksinspace> i love the modern, scaped-to-death internet, waiting half an hour for abuild to fetch sources is my favourite pasttime :cry:
2025-12-05 15:53:38 <pltrz[m]> question regarding the aports merge process - if I made a MR to upgrade a package version and I am not the listed maintainer/asignee: do I need to request any action from the listed maintainer for it to become approved? it seems like the gentleman is not active on GitLab. !94263
2025-12-05 15:55:23 <ikke> !94263
2025-12-05 21:07:02 <socksinspace> achill: since you removed the binutils-gold dependency in go, do you think we can already/finally remove binutils-gold? the patch to go is the only thing i still see referencing binutils-gold at all in edge.
2025-12-05 21:19:41 <achill> <socksinspace> achill: since you removed the binutils-gold dependency in go, do you think we can already/finally remove binutils-gold? the patch to go is the only thing i still see referencing binutils-gold at all in edge.
2025-12-05 21:19:41 <achill> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87043
2025-12-05 21:23:25 <socksinspace> ah, helps if i actually use my eyes, sorry :D
2025-12-06 11:18:37 <ikke> I've enabled new kubernetes x86 runners. Please let me know if you notice any issues
2025-12-06 14:38:41 <omni> a lot of "ERROR: Job failed (system failure): prepare environment: waiting for pod running: timed out waiting for pod to start."
2025-12-06 14:39:21 <omni> also for generate-build-jobs and lint
2025-12-06 16:17:11 <ikke> I'm tweaking things to improve the situation
2025-12-06 16:29:33 <mio> seeing the same error on runner #246 (p-2MOw_n) https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2129869 after 3 attempts. let me know whether/when to help test or retry later
2025-12-06 16:29:46 <mio> lol thanks algitbot
2025-12-06 16:32:02 <ikke> I restart these jobs regularly to test
2025-12-06 16:34:39 <mio> okay :)
2025-12-06 20:28:51 <ikke> mio: is it better now?
2025-12-06 20:29:09 <mio> ikke: yes, thanks :)
2025-12-06 20:29:11 <ikke> Have to see it when there's a lot of jobs, though
2025-12-06 21:36:04 <socksinspace> oh neat, i can do "abuild rootbuild" cross-architecture to SuperH now
2025-12-06 21:38:59 <socksinspace> finally i'm free of my yanky selfmade chroots
2025-12-06 23:14:55 <socksinspace> seems like the ci runners are still unhappy if my abuild MR is anything to go by
2025-12-07 01:31:51 <jvvv> achill: i was looking at !94319 and noticed a few aports i must have missed when i've perused for abandoned ones. would you prefer that i reintroduce them after the MR is committed before I take over maintainership of the ones i'm interested in? that way you won't need to modify the MR?
2025-12-07 05:38:58 <Ariadne> vixalien[m]: the problem is that abuild has a "don't do magical things" design philosophy, and langpacks are something that would require automatic expansion in order to not be tedious
2025-12-07 05:56:20 <elibrokeit> LANGS="en de fr ja it" doesn't sound unduly burdensome nor automagic. you'd need some way to define hook functions that run once for each language and take the name of the language to process for, but that shouldn't be too hard
2025-12-07 06:59:51 <Ariadne> elibrokeit: cool, take it up with ncopa who does not want this type of automation in abuild
2025-12-07 07:01:18 <elibrokeit> I don't have any stake in this, e.g. I don't use language packs to begin with :P
2025-12-07 07:02:02 <elibrokeit> just saying, I can understand the argument of avoiding automation, but not the argument of it being *magical* :P
2025-12-07 07:02:35 <Ariadne> i am just stating the position of the abuild maintainer whenever anyone proposes anything like this
2025-12-07 07:15:27 <HarryN[m]> There could be a meta-package for a user's defined language and have an install condition similar to shell completions
2025-12-07 07:15:39 <HarryN[m]> It's a bit messy, but it's an easy solution imo
2025-12-07 07:25:19 <elibrokeit> HarryN[m]: the question seems rather, how to write an APKBUILD that produces the subpackages in the first place 
2025-12-07 07:28:20 <HarryN[m]> I don't really have any ideas except for hooks or macros either
2025-12-07 07:29:08 <HarryN[m]> Personally, I would rather have something purge the unneeded language files after installation since that's easier on the maintainers
2025-12-07 11:32:32 <Sertonix[m]> One would need to agree on a language naming format. Only some packages will follow this so names would need to be transformed on a pre-package basis. And in some cases there are language files which don't quiet match the dialect but would still be better than english which isn't really feasable to represent.
2025-12-07 11:45:52 <socksinspace> any news on the ci runners? the pipeline in abuild!472 seems to always try to run the jobs on the same runner (247) unsuccessfully
2025-12-07 11:46:29 <socksinspace> you tried, good bot
2025-12-07 13:13:18 <ikke> socksinspace: that runner was not functional yet
2025-12-07 13:14:53 <socksinspace> should i hit retry then?
2025-12-07 15:04:56 <Imbus> ls
2025-12-07 19:35:21 <HarryN[m]> <Sertonix[m]> "One would need to agree on a..." <- Using ISO 639 with the dialect added similarly to IETF language tags should be good
2025-12-07 19:49:36 <HarryN[m]> I think a good compromise is having just the ISO 639 code and having all the dialects in a singular package
2025-12-07 19:50:51 <HarryN[m]> It’s easier than having dialectal information along with possible writing system variants
2025-12-07 20:45:01 <Newbyte> Do you have any idea why this happens: https://unix.stackexchange.com/q/801905/324625
2025-12-07 20:53:28 <Newbyte> Also, is it just me or is this just not enough information to figure out what's going wrong as a user? To get the provider priority I had to look at the relevant APKBUILDs which doesn't seem to me like something a regular user should have to do.
2025-12-07 21:01:33 <Sertonix[m]> apk query can output the provider priority?
2025-12-07 21:04:07 <Sertonix[m]> And I think there is a long standing bug which makes conflicting constrains in depends with --available to sometimes break like that but I was never able to figure out a reproducer and therefor never opened an issue about it. CC fabled
2025-12-07 21:08:35 <Newbyte> <Sertonix[m]> "apk query can output the..." <- Not exactly intuitive 
2025-12-07 21:09:06 <Newbyte> And I see, thanks
2025-12-07 21:09:24 <Newbyte> Is there any way I can help provide information about it?
2025-12-07 21:11:52 <Sertonix[m]> You could compile apk-tools with solver debugging enabled and post the logs in a new issue.
2025-12-07 21:12:54 <Sertonix[m]> (As long as you can still reproduce the error)
2025-12-08 00:31:20 <jvvv> having an issue with CI for riscv64 failing on download of the source, https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/2131627
2025-12-08 00:31:24 <JustSouptheyhe[m]> Is there anything I can do to push [this MR](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87750) forwards? Its been stuck waiting for security review since July, which isn't a problem (security over speed and all that), but I am worried it might get lost.
2025-12-08 00:35:08 <jvvv> nvrmnd, not it passed
2025-12-08 00:38:49 <jvvv> s/not/now/
2025-12-08 03:32:47 <jvvv> i'm preparing to abandon 3 aports that i maintain. i no longer use them and actually think they shouldn't be packaged (just my opinion). should a submit an issue before preparing an MR? i can't decide if i should have them removed (they are all in testing) or just unmaintained.
2025-12-08 04:34:57 <qaqland> jvvv: which aports
2025-12-08 04:49:18 <jvvv> qaqland: testing/{nvim-plenary,nvim-web-devicons,nvim-lualine}
2025-12-08 09:08:47 <fabled> Newbyte, Sertonix[m]: sounds bug. I think it is related to the order on how the packages are selected. Do you have a minimal reproducer command sequence in docker or something similar?
2025-12-08 11:18:26 <pltrz[m]> kindly pinging request to review package upgrade MR !94263
2025-12-08 12:36:51 <Habbie> aports currently has pdns-recursor 5.3.1, which fixes two CVEs. Those are noted under secfixes: attached to 5.3.0. now i am abumping to 5.3.3 because .2 was not publicly released. both .2 and .3 fix a CVE
2025-12-08 12:36:57 <Habbie> do i attach those CVEs to .1 in secfixes?
2025-12-08 12:37:09 <Habbie> related: where is secfixes documented? I looked but cannot find it
2025-12-08 13:05:16 <ikke> Habbie: You specify the version of the alpine package that was published
2025-12-08 13:05:28 <Habbie> ack
2025-12-08 13:05:37 <Habbie> so i tie both secfixes to .1
2025-12-08 13:05:44 <Habbie> which keeps confusing me because they were -not fixed- in .1 :)
2025-12-08 13:06:36 <Habbie> thanks ikke
2025-12-08 13:21:18 <ikke> Yw
2025-12-08 13:21:32 <ikke> The format has no formal specification 
2025-12-08 14:34:03 <haesbaert> so to my sadness, the installer doesn't have the firmware I need for my wifi card, but we do have the firmware in linux-firmware-intel, is there a quick and dirty way for me to make an iso with that firmware included?
2025-12-08 14:35:12 <haesbaert> oh there is osmething on the wiki, I'll try there, at any point we should include the iwl entries for the luna lake chips in the installer
2025-12-08 15:34:56 <Newbyte> fabled: No, not really, do you have any ideas how I could produce one? I tried just installing postmarketos-ui-base-gnome and tuned-ppd in a fresh chroot but it doesn't exhibit this issue.
2025-12-08 15:35:22 <Newbyte> I have this issue on a proper long-running postmarketOS/Alpine installation
2025-12-08 15:38:13 <fabled> Newbyte: can you send your /etc/apk/world and /lib/apk/db/installed? Either create a ticket and attach to it, or just send it to me via email. Thanks.
2025-12-08 16:04:31 <Newbyte> fabled: Done: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11170
2025-12-08 16:11:11 <fabled> Newbyte: thanks. Forgot, can you still attach also /etc/apk/repositories*
2025-12-08 16:25:32 <Newbyte> fabled: Updated the issue
2025-12-09 05:13:12 <qaqland> ncopa: i want to upgrade libgit2 in !94330 and !94375
2025-12-09 13:23:06 <raspuser9> hi there, just ran into the issue that alpine on raspberrypi4 doesnt work well with its usb controller, i found this post and wanted to ask if this is still true (looks like it) https://raspberrypi.stackexchange.com/a/102299
2025-12-09 13:38:15 <strophy> I use Alpine on RPi Zero devices with no USB issues, I don't think those customizations are needed anymore. Are you using the Raspberry Pi builds from https://www.alpinelinux.org/downloads/ ?
2025-12-09 13:51:04 <raspuser9> @strophy yes official builds from the website + the headless overlay
2025-12-09 13:54:48 <strophy> Can you describe the problem you are getting in more detail, are there any error messages in dmesg output for example? @macmpi can probably help here
2025-12-09 13:55:19 <raspuser9> no errors, just that no usb port is working
2025-12-09 13:55:36 <raspuser9> lsusb shows no output, dmesg shows that usb drivers are loaded though
2025-12-09 14:03:40 <strophy> I have a Pi Zero with 3.22.2 running in front of me, my USB dmesg output shows `dwc_otg 3f980000.usb: DWC OTG Controller` on startup and lsusb shows `Bus 001 Device 001: ID 1d6b:0002 Linux 6.12.51-0-rpi dwc_otg_hcd DWC OTG Controller` plus a camera I have connected..
2025-12-09 14:06:01 <strophy> I don't seem to have anything special in /boot/cmdline|config|usercfg.txt files other than my dtoverlay for the GPU and camera, sorry I can't help much more
2025-12-09 14:07:05 <strophy> I also installed from the RPi image + headless overlay, I documented my steps here: https://github.com/macmpi/alpine-linux-headless-bootstrap/discussions/54
2025-12-09 14:11:29 <raspuser9> yeah i find it pretty odd aswell, other distros working just fine
2025-12-09 14:11:45 <raspuser9> but thanks
2025-12-09 14:30:39 <jvoisin> https://www.freexian.com/blog/usr_move/ debian completed the move
2025-12-09 14:39:25 <invoked> 1500 hours.
2025-12-09 21:00:28 <logan2611> For !93473, since Alpine's oldest offered kernel is now 6.18, is the AKMBUILD issue even relevant anymore?
2025-12-10 08:30:33 <qaqland> do i still need to set env like GOCACHE for go package now?
2025-12-10 08:37:14 <Sertonix[m]> Not needed anymore
2025-12-10 08:42:51 <qaqland> thanks, i would delete them
2025-12-10 10:33:15 <ncopa> PureTryOut: there is a circular dep in kcodecs -> xwayland-run -> .... kconfigwidgets -> kcodecs
2025-12-10 13:19:13 <PureTryOut> ah that explains it 😱 although xwayland-run should in no way have a dep on anything KDE... Looking into it
2025-12-10 13:21:19 <jahway603[m]> Is there anything funny going on with the build-riscv64 build pipeline for 3.23-stable? That specific pipeline was successful in edge (!94453), but then failed in 3.23-stable (!94454).
2025-12-10 13:21:38 <PureTryOut> wait, how does it? I don't see xwayland-run depend on anything like that. It only depends on weston, xauth and xwayland. None of which depends on anything KDE
2025-12-10 13:26:27 <PureTryOut> doing apk add -i xwayland-run in a clean docker.io/alpine:edge container shows no KDE packages being pulled in
2025-12-10 19:44:36 <realroot[m]> can somebody fix qt-creator?
2025-12-10 20:11:05 <Biswa96[m]> it would be helpful if you could explain the actual issue.
2025-12-10 22:30:34 <pltrz[m]> trying to do a simple upgrade on a rust pkg (community/gitu). updated version and checksum; but abuild check (cargo test) fails. what's strange is that if I clone the project repo from github, checkout the same tag, and invoke cargo test, it compiles/passes just fine. any ideas what could be going wrong? (https://pastebin.com/raw/9q9UGCup)
2025-12-10 22:32:00 <pltrz[m]> APKBUILD (https://pastebin.com/raw/QDB4rpEz)
2025-12-10 22:32:17 <pltrz[m]> https://pastebin.com/raw/QDB4rpEz
2025-12-11 02:13:59 <logan2611> Does anyone know why CONFIG_DEBUG_FS is enabled in linux-lts on x86_64 and aarch64 but not riscv64?
2025-12-11 02:14:50 <logan2611> Seems to be implicitly enabled by DEBUG_KMEMLEAK, DEBUG_KERNEL and HAVE_DEBUG_KMEMLEAK, only the last of which is enabled on rv64
2025-12-11 06:48:12 <lotheac> probably an oversight
2025-12-11 07:26:08 <ncopa> my guess is that those was enabled by DEBUG_INFO_BTF and we havent enabled DEBUG_INFO_BTF on riscv64
2025-12-11 07:26:28 <ncopa> it probably blows up the kernel size. at least it did on ppc64le
2025-12-11 07:44:11 <ncopa> logan2611: can you please create an issue if you need a config change
2025-12-11 07:44:57 <logan2611> Already did, #17797
2025-12-11 07:45:25 <logan2611> Turns out it's just a rv64 issue
2025-12-11 08:14:44 <Sertonix[m]> pltrz: The test suite seems to need a git repository. You could create a dummy one in the prepare() step
2025-12-11 10:30:20 <omni> https://codeberg.org/errror/wormhole might be interesting for dovecot users since 305be4be6eb852de83f93bf83517498b9cdf67f9
2025-12-11 10:50:30 <ncopa> logan2611: I'm curious what you want use debugfs for?
2025-12-11 10:51:08 <ncopa> those are the defconfig options related to debugfs: https://tpaste.us/ZKLg
2025-12-11 11:36:42 <socksinspace> I still can't get this pipeline to actually run https://gitlab.alpinelinux.org/socksinspace/abuild/-/pipelines/387412
2025-12-11 14:22:25 <fabricionaweb> uh, the alpine:edge still have nodejs broken, need to run the apk add -U
2025-12-11 16:58:16 <strophy> Hi, friendly request to see if I can get someone to help review and merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/92565 it would be a huge help for an Alpine-based RPi Zero camera project I have going on
2025-12-11 18:28:19 <pltrz[m]> could anyone offer any insight in understanding what's failing in this riscv64 pipeline?
2025-12-11 18:28:22 <pltrz[m]> https://gitlab.alpinelinux.org/pltrz/aports/-/jobs/2136935
2025-12-11 18:49:30 <Habbie> oops. review (and also me) did not notice i did secfixes wrong in pdns-recursor on 3.22-stable the last time around
2025-12-11 19:03:26 <logan2611> ncopa: Well in this specific case I was using it (mostly indirectly through userspace tools) to test !93473 on other architectures. In the past I've also used it to debug weird driver/HW issues, and once had to use it for data recovery.
2025-12-11 19:04:39 <logan2611> I think it's also required to get stats from some of the GPU drivers?
2025-12-11 19:06:05 <logan2611> Not sure about the indirect uses for it though since Alpine is the only distro I've used where it's been disabled
2025-12-11 20:34:09 <craftyguy[m]> fabled thanks a lot for responding to that apk issue I filed. I'm not exactly sure which MR you'd like me to try.. is it this one? https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/379
2025-12-11 20:35:18 <fabled> craftyguy[m]: yes. That one. The static build is also in one of the last comments
2025-12-11 20:35:39 <craftyguy[m]> ok I see it, I'll try it right now
2025-12-11 20:36:54 <craftyguy[m]> yes, the issue seems to be resolved with that MR :D
2025-12-12 02:27:43 <drinksIPA> hi all :D how's everyone?
2025-12-12 02:30:13 <drinksIPA> if you guys downloading from torrent and can't keep up with ratio...try downloading from xdcc bots, you can find a network that serves xdcc packs at https://xdcc-search.com - its all free and servers are running on high bandwidth. Thank me later :D
2025-12-12 07:42:42 <fabricionaweb> again with this
2025-12-12 10:06:51 <mikropono> hi all :D how's everyone?
2025-12-12 10:09:21 <mikropono> if you guys downloading from torrent and can't keep up with ratio...try downloading from xdcc bots, you can find a network that serves xdcc packs at https://xdcc-search.com - its all free and servers are running on high bandwidth. Thank me later :D
2025-12-12 10:31:34 <f_> brings back
2025-12-12 14:47:25 <pltrz[m]> Is there a straightforward way to use cargo-nightly instead of cargo-stable as a builddep for an experimental rust program, to package it for my personal apk repo?
2025-12-12 14:58:20 <pltrz[m]> Also - anyone using container or vm based workflow for easily spinning up blank-slate alpine environments for easily testing/building APKBUILDs? I run into the issue sometimes where I build an APKBUILD, and I think I got all the required build/check/runtime dependencies defined, but I may have missed one in the APKBUILD that I didn't notice since it was already installed on my system. So, naturally, I thought of automating some kind of
2025-12-12 14:58:20 <pltrz[m]> system to spin-up an isolated environment, curious what others use and appreciate any suggestions/resources.
2025-12-12 15:00:38 <durrendal> pltrz[m]: https://krei.lambdacreate.com/t-a-p/tap-tools <- I have a script for managing chroots to test builds for that use case that works pretty well. It's not entirely stateless
2025-12-12 15:01:35 <durrendal> Another suggestion would be incus containers or VMs, you could use the cloud-init based images to spin up a small edge environment pretty quickly
2025-12-12 15:13:08 <pltrz[m]> durrendal: thanks! I'll play with those
2025-12-12 15:17:52 <durrendal> no problem :) if you try krucforgo.sh and run into issues feel free to ping me. 
2025-12-12 15:26:44 <pltrz[m]> durrendal: very kind; I greatly appreciate it.
2025-12-12 15:30:48 <mikropono> hi all :D how's everyone?
2025-12-12 15:33:18 <mikropono> if you guys downloading from torrent and can't keep up with ratio...try downloading from xdcc bots, you can find a network that serves xdcc packs at https://xdcc-search.com - its all free and servers are running on high bandwidth. Thank me later :D
2025-12-12 15:34:14 <Sertonix[m]> pltrz: It seems to me that abuild rootbld would be enough for your use case
2025-12-12 15:44:51 <pltrz[m]> Sertonix: I didn't know about that tool. I'll check that out as well!
2025-12-12 16:33:33 <beepbeep> hi all :D how's everyone?
2025-12-12 18:43:47 <iggy> pltrz[m]: there's also https://gitlab.alpinelinux.org/alpine/docker-abuild
2025-12-12 20:55:58 <pltrz[m]> iggy: thank you as well
2025-12-13 13:51:15 <WhyNotHugo> It's extremely annoying that Alpine's doas package has custom patches to override the default configuration by (1) reading additional rules from another location (2) giving those rules higher precedence (3) shipping such rules as part of doas package.
2025-12-13 13:51:40 <WhyNotHugo> I don't think that such an important security tool should have easter eggs like this.
2025-12-13 14:02:02 <Sheila> where are you seeing alpine ship additional doas config in `/etc/doas.d/`?
2025-12-13 14:05:47 <f_> pretty sure pmOS does ship doas config in doas.d, but alpine doesn't IIRC?
2025-12-13 14:12:26 <qaqland> I have added comments there
2025-12-13 14:14:39 <Sheila> https://git.alpinelinux.org/aports/tree/main/doas/APKBUILD like, I'm not seeing any additional doas config here, and the doas.conf there just refers the reader to the documentation.
2025-12-13 14:14:51 <qaqland> setup-alpine would create one rule
2025-12-13 14:15:28 <qaqland> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-user.in#L171
2025-12-13 14:23:34 <socksinspace> yeah, that confuses me for a bit whenever i try to setup a machine with "permit nopass"
2025-12-13 14:54:17 <ayakael> Good day, could someone take a look at  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87569 It's already been reviewed by a couple of people, but hasn't been merged yet.
2025-12-13 14:55:02 <ayakael> (it is the MR for new koreader aport)
2025-12-13 14:55:16 <ayakael> Also https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80072 (aport for openterface-qt)
2025-12-13 15:00:38 <fabricionaweb> is there a way to use abump with rootbld? I tried but It didnt work
2025-12-13 15:05:57 <WhyNotHugo> Sheila: I just installed Alpine on a new host and had /etc/doas.d/20-wheel.conf
2025-12-13 15:06:44 <Sheila> WhyNotHugo: if you used setup-alpine to do so, see what qaqland said above.
2025-12-13 15:07:30 <WhyNotHugo> Yeah, `permit nopass` in that rule is exactly what locked me out.
2025-12-13 15:08:43 <WhyNotHugo> All these quirks violate the principle of least surprise. Especially for someone who's been using the official doas before.
2025-12-13 16:00:52 <a_> hii
2025-12-13 20:54:57 <ncopa> WhyNotHugo: have a look at the git history for why it was introduced. And if you think it should be reverted, file an issue and explain the details why
2025-12-13 22:48:33 <WhyNotHugo> ncopa: I'll peek further and do so.
2025-12-13 22:49:03 <WhyNotHugo> Currently files in doas.d are read last, and doas has a "last rule wins" design, so the file /etc/doas.d/20-wheel.conf always overrides user configuration.
2025-12-13 23:32:57 <omni> I wonder if there should be an option to opt out of /etc/doas.d/, configurable in /etc/doas.conf
2025-12-13 23:33:34 <omni> I saw that some packages carry doas configuration files https://pkgs.alpinelinux.org/contents?file=*&path=%2Fetc%2Fdoas.d&name=&branch=edge&repo=&arch=x86_64
2025-12-13 23:34:51 <omni> it feels like a "convenience" I, myself, would not want the distribution to do for me
2025-12-14 00:06:12 <lonjil> The tailscale package uses that to allow tailscale to call resolvconf as root without tailscale itself running as root 
2025-12-14 00:15:51 <omni> I get what is done and why but remain a bit conflicted
2025-12-14 00:21:31 <omni> it is for !94560
2025-12-14 00:21:49 <omni> I also wonder why it is taking so much longer than before
2025-12-14 00:24:10 <omni> wrong channel
2025-12-14 09:20:46 <ncopa> achill: thanks for following up on osinfo-db
2025-12-14 11:09:37 <Sertonix[m]> IIRC there was a broken doas patch which read both config locations. I think someone should try to implement that coreectly
2025-12-14 11:11:35 <omni> isn't that what we do?
2025-12-14 11:12:18 <omni> that upstream doas will read either /etc/doas.conf or /etc/doas.d/*.conf, but we patch to do both (in that order, as I understood it)
2025-12-14 11:13:12 <Sertonix[m]> It has been a while but I think upstream only reads /etc/doas.conf, nothing more
2025-12-14 11:13:23 <omni> 40b30d19d63af675de8678549e9704e9e63c1d2f
2025-12-14 14:28:26 <skarnet> /etc/foo.d/*.conf should have an online preprocessor (that's a shell one-liner) catting everything into /etc/foo.conf and that's the only place that should be read
2025-12-14 15:03:13 <abby> omni: upstream doas only reads /etc/doas.conf because that's what the true upstream (bsd) does
2025-12-14 18:07:34 <omni> oh, I read our main/doas/configuration-directory.patch sloppily, it patches README.md twice, first adds commentary about the added --with-doas-confdir, and then updates the comment...
2025-12-14 20:45:39 <logan2611> Can someone review !93473? I think all the outstanding issues have been resolved, and I've been running the package for a few weeks now with no issues.
2025-12-14 20:56:22 <Noisytoot> what happened to the toilet package? if I search aports commit log for it, I see that it was added in 2014 but not when it was removed
2025-12-14 20:56:29 <Noisytoot> I want to re-add it but I don't know when or why it was removed
2025-12-14 22:17:10 <Sertonix[m]> Noisytoot: It was moved to unmaintained which which was removed completely a while back. Missing maintainer might be one reason for that https://git.alpinelinux.org/aports/commit/testing/toilet?id=b6af1e02efe594039707cd882517663d5370f375
2025-12-14 23:15:41 <Noisytoot> meaning unmaintained in alpine (which isn't a problem if I re-add it, since I'll maintain it) or unmaintained upstream?
2025-12-14 23:45:18 <Sertonix[m]> I mean unmaintained in alpine. I have not checked upstream
2025-12-15 19:32:23 <Ariadne> omni: i think we should drop the configuration directory stuff and use something like `capsudo` instead for maintainer scripts
2025-12-15 19:32:59 <Ariadne> however capsudo is not quite ready for that yet