2026-09-01 00:17:07 <andar1an[m]> Reverting didn't fix, don't think it is firmware.
2026-09-01 02:22:40 <WhyNotHugo> eudev-dev, libudev-zero-dev and any other API-compatible package should all provide udev-dev. Packages which depends on "any udev implementation" should depend on udev-dev, not on either of those specifically.
2026-09-01 02:22:47 <WhyNotHugo> Downstream distributions may of course have other providers.
2026-09-01 02:23:01 <WhyNotHugo> I opened !107674 and !107673 to that effect.
2026-09-01 07:26:14 <ekatwired> Oh no libudev zero, getting flashbacks. I sure love when people put more work into writing conspiracies into readme than writing good software. Cannot even hotplug keyboard ffs.
2026-09-01 07:52:01 <ncopa> WhyNotHugo: I am not convinced that is a good idea
2026-09-01 09:07:14 <WhyNotHugo> ncopa: why so?
2026-09-01 09:11:57 <ncopa> because they are not really API compatible. they are not even ABI compatible
2026-09-01 10:04:35 <lindsay> ekatwired: I think what you need is mdev configuration, not for libudev-zero. I have some helper scripts might be helpful: https://git.lin.moe/aports/lin/mdev-helper.html
2026-09-01 10:47:56 <skarnet> lindsay: did you expand the scripts from mdev-like-a-boss? Do you know what happened to the project?
2026-09-01 11:00:48 <lindsay> skarnet: yes, from mdev-like-a-boss. This GitHub repository has been archived for a long time. I also just noticed it has now been deleted.
2026-09-01 11:02:22 <skarnet> yes, it has been deleted, and the existing copies aren't as complete, it seems like your scripts are clearly more maintained
2026-09-01 11:03:17 <skarnet> your repository is labelled as Alpine-specific though, do your scripts rely on Alpine-specific assumptions?
2026-09-01 11:03:40 <skarnet> because if not I would like to link to them in the mdevd documentation
2026-09-01 11:08:51 <lindsay> skarnet: If you'd like, I can create a separate repository for this. Some of the changes are from eweos. I can contact the maintainers of eweos to maintain it together.
2026-09-01 11:10:42 <skarnet> it's all good. If it works on two distros then it's not too specific :)
2026-09-01 11:21:00 <jvvv> For reference, I found eweos' busybox and mdev stuff here: https://os-build.ewe.moe/package/show/eweOS:Main/busybox
2026-09-01 11:57:08 <Sertonix[m]> WhyNotHugo: Do we really need this over eudev-dev?
2026-09-01 12:32:18 <abby> eudev and (systemd-)udev have identical ABI, i checked recently
2026-09-01 13:19:32 <WhyNotHugo> libudev-zero does too; that's intentional
2026-09-01 15:19:17 <andar1an[m]> Will the previous version of a package in edge ever be considered to keep in registry? Generally it is only latest version right?
2026-09-01 15:19:41 <unvFK9I3vgc> yes
2026-09-01 15:20:11 <andar1an[m]> yes to considered? Or yes to only latest haha? I worded that bad
2026-09-01 15:20:33 <ikke> andar1an[m]: it takes a huge amount of storage
2026-09-01 15:20:41 <andar1an[m]> Ah ok
2026-09-01 15:20:44 <ikke> We tried it briefly, but quickly had to discontinue
2026-09-01 15:21:04 <andar1an[m]> I have been using a stable branch with a revert tag with great success
2026-09-01 15:21:10 <andar1an[m]> And can always build locally
2026-09-01 15:22:15 <andar1an[m]> Was just wondering if there could be a regression repo that is just a cache of the previous version of whatever is in edge. What amount of storage does edge consume?
2026-09-01 15:22:54 <andar1an[m]> Maybe it doesn't need to be alpine infra
2026-09-01 15:23:12 <andar1an[m]> Maybe on local machine, an upgrade caches previous version locally?
2026-09-01 15:23:58 <ikke> if you enable caching, yes
2026-09-01 15:25:00 <andar1an[m]> Enabling caching would require it to have been enabled with previous version though, right?
2026-09-01 15:25:09 <ikke> yes
2026-09-01 15:25:34 <omni> but it can be a life saver to have configured
2026-09-01 15:25:41 <ikke> You can check /var/cache/apk/pkgs
2026-09-01 15:25:42 <andar1an[m]> what if upgrade specifically could have a flag to collect files and archive in apk prior to adding new apk
2026-09-01 15:25:43 <omni> that and/or filesystem snapshots
2026-09-01 15:26:07 <andar1an[m]> Yes i have it configured
2026-09-01 15:26:11 <andar1an[m]> This is more for other users who may not build or cache
2026-09-01 15:26:29 <andar1an[m]> Ah true ikke
2026-09-01 15:27:07 <andar1an[m]> Just trying to think if there is a ux optimization for reversions that can be part of apk tools
2026-09-01 15:28:10 <andar1an[m]> I also have to see of upgrades are logged somewhere specific. But it seems that this is already possible
2026-09-01 15:29:07 <andar1an[m]> I guess it doesn't really matter for stable either
2026-09-01 15:29:55 <andar1an[m]> I always imagine edge being best for a user facing machine though
2026-09-01 15:44:23 <elagost> I use a combination of `grub-btrfs` and `snapk` on edge, it works nicely :)
2026-09-01 16:32:52 <andar1an[m]> Noice. I use a uki with secure boot and have been working towards an atomic manifest that i can distribute and update over pxe. Also use btrfs snapshots, though i have been exploring subvolumes per sevice structures also.
2026-09-01 16:33:37 <andar1an[m]> I actually find it pretty awesome when it comes to isolating and backing up services
2026-09-01 16:33:55 <andar1an[m]> Only have 1 service like that so far though, will explore more soon
2026-09-01 16:34:40 <andar1an[m]> Actually recently figured out finally how to make a usbkey for the uki which was pretty awesome
2026-09-01 16:35:08 <andar1an[m]> But so highlighted some updates we can make to nlplug-findfs and initramfs-init
2026-09-01 16:35:24 <andar1an[m]> Sertonix already has an issue tracking all kinds of cool stuff though
2026-09-01 16:35:57 <andar1an[m]> s/but also. Sorry, gym tired
2026-09-02 05:55:16 <lindsay> skarnet: Splited mdev helpers repository we talked yesterday: https://github.com/eweOS/mdev-helpers
2026-09-02 11:01:29 <skarnet> lindsay: nice! but is the previous URL still available? I had changed my links to them, and I'd rather not link to github if I can avoid it ^^'
2026-09-02 12:22:14 <WhyNotHugo> If mkinitfs starts mdevd isntead of using mdev, it can listed to nlgroup=4 for already-processed events, and avoid one fork+exec per device node. Isn't that lighter, simpelr and less code?
2026-09-02 12:32:48 <skarnet> it definitely would be
2026-09-02 12:34:47 <WhyNotHugo> mdev is 12bytes (by virtue of beign a busybox symlink) and mdevd is 33.8K+207.3K… I hope that won't be an issue 😬
2026-09-02 12:36:14 <skarnet> the fact that busybox embeds so much code is certainly an incentive to keep using it
2026-09-02 12:37:16 <skarnet> but if it's for the initramfs, I suppose the busybox is specifically tailored for it and mdev would be removed, gaining a little space
2026-09-02 12:37:48 <skarnet> also for an initramfs mdevd would be statically linked, avoiding pulling the whole skalibs .so
2026-09-02 12:38:26 <skarnet> the static mdevd binary is still ~128kB
2026-09-02 12:57:01 <WhyNotHugo> mkinitfs copies the system busybox, but in theory we could have a custom-tailored one stripped down to the necessary bits — this needs extreme care tho, it's very easy to break niche setups.
2026-09-02 13:02:35 <WhyNotHugo> skarnet: mdevd-static (dynamically linking only musl) is 46.1K :)
2026-09-02 13:04:03 <skarnet> yeah if you link musl dynamically even on an initramfs it can help :)
2026-09-02 13:05:07 <skarnet> niche setups? I thought the point of an initramfs is that it was hidden from users (less tinkerable) and generic because it needs to be able to mount every possible rootfs
2026-09-02 14:49:04 <invoked> what's the initramfs size constraint for the smallest install target?
2026-09-02 14:49:57 <invoked> (better question: what are we optimizing size for?)
2026-09-02 15:11:26 <WhyNotHugo> invoked: I'm not aware of specific constraints, but ideally we'd avoid bloating it for non-functional changes.
2026-09-02 15:43:39 <invoked> was just curious. if building everything static there doesn't break any targets, i'm not sure what is being solved. (sorry if that sounds argumentative)
2026-09-02 15:45:04 <skarnet> I'm in favor of building everything fully static in an initramfs anyway, but AIUI disk space constraints are a *big* factor in getting a change to be integrated in Alpine
2026-09-02 15:45:23 <skarnet> but maybe that's true for the rootfs, which is used in containers, more than for the initramfs, which isn't
2026-09-02 15:47:10 <WhyNotHugo> What I'm starting to wonder if why we really need mdev here, since we're handling netlink events directly
2026-09-02 15:47:21 <WhyNotHugo> The rootfs would later run mdev/udev/mdevd/etc anyway
2026-09-02 15:49:18 <skarnet> I'm not sure what exactly you're trying to solve, but if you want to add a "sync" mechanism to nlplug-findfs, that's certainly an option too
2026-09-02 15:55:41 <WhyNotHugo> this is tangential to the issue I was fixing; I noticed the fork+exec mdev for each uevent, and starting thinking that this could be optimised while also making it simpler.
2026-09-02 16:35:08 <skarnet> well, that's the point of mdevd, yes
2026-09-02 16:48:48 <WhyNotHugo> Yeah, but with devtmpfs (which we already have), I tihnk we don't even need mdev(d) any more; busybox now resolves UUID/labels/etc itself, and nlplug-findfs already does kmod.
2026-09-02 16:49:09 <WhyNotHugo> Will have to do some heavy testing.
2026-09-02 17:30:49 <Sertonix[m]> It could break compatibility with systems without devtmpfs.
2026-09-02 18:14:36 <WhyNotHugo> Yes, devtmpfs would become mandatory
2026-09-02 18:46:14 <skarnet> note that the kernel only creates a very minimal amount of devices with no extra work at all, extracting the relevant information from /sys and doing (among other things) the adequate transformations in /dev is the point of mdev/mdevd/udev, so if you remove the device manager to rely on devtmpfs, make sure your initramfs can work with the basic stuff the kernel does
2026-09-02 20:32:34 <WhyNotHugo> skarnet: it works for the setups I've tried so far. My uncertainty is with RAID/network setups.
2026-09-03 05:56:28 <hexed> Hi all :) I submitted an issue for a package upgrade a week ago, but I think the package maintainer is inactive for a long time now. are pull requests welcomed in these situations, or would I be wasting time? I have no prior gitlab history.
2026-09-03 12:43:50 <ncopa> do you have an url?
2026-09-03 12:45:27 <ikke> hexed already left
2026-09-03 13:02:40 <omni> is mpolanski anywhere on irc?
2026-09-03 13:08:13 <bitfehler> ncopa: would it be possible to get some kind of comment on https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/311 ? if it's a no, that's cool, we'd have to (somehow) deal with it in arch-install-scripts, but it would at least help us move on from the current "package installation is broken" situation. thx in advance <3
2026-09-03 13:09:51 <hexed> ncopa: do you mean a link for the gitlab issue I filed? if so https://gitlab.alpinelinux.org/alpine/aports/-/work_items?show=eyJpaWQiOiIxODQxMyIsImZ1bGxfcGF0aCI6ImFscGluZS9hcG9ydHMiLCJpZCI6MzU3Njg4fQ%3D%3D
2026-09-03 13:11:34 <hexed> I will likely disconnect again, but no worries I'll check the irc logs later for responses
2026-09-03 13:26:12 <invoked> hexed: send a PR, it's fine
2026-09-03 13:31:36 <omni> MR ;)
2026-09-03 13:31:45 <omni> yes, that's always fine
2026-09-03 22:23:13 <omni> WhyNotHugo: I think we may need to lift skopeo to something later in 3.24-stable, it's kinda out of sync with podman, buildah and cri-o wrt containers-common expectations
2026-09-03 22:24:18 <omni> and then do something simliar to what we recently did, containers-common -> container-libs
2026-09-03 22:26:13 <omni> it should unbreak some things, but I want to be careful not to introduce breakage
2026-09-03 23:58:49 <WhyNotHugo> omni: shouldn't 3.24 stay on podman 5.x?
2026-09-04 00:13:34 <omni> WhyNotHugo: yes, but the 3.24 packaged versions of podman, buildah and cri-o has moved to expect the new monorepo for common, image and storage, container-libs, whereas the packaged version of skopeo would still expect the old containers-common
2026-09-04 00:30:01 <omni> I think any version of skopeo after 1.20.x would do to be able to splace containers-common with container-libs, but looking at their release list I don't follow their release strategy https://github.com/podman-container-tools/skopeo/releases
2026-09-04 00:31:57 <omni> perhaps the answer is what's packaged in IBM RedHat®
2026-09-04 03:09:27 <hexed> invoked: mate-menus 1.28.1 was released 9 months ago on their git (https://github.com/mate-desktop/mate-menus/releases/tag/v1.28.1), but their release archive only has up to 1.28.0 (https://pub.mate-desktop.org/releases/1.28/mate-menus-1.28.0.tar.xz), and the alpine APKBUILD currently pulls from this source. Is it appropriate to change the source to their git release? This is what arch does 
2026-09-04 03:09:33 <hexed> (https://gitlab.archlinux.org/archlinux/packaging/packages/mate-menus/-/blob/main/PKGBUILD).
2026-09-04 03:12:31 <hexed> I guess that opens a wider question of, should all the mate-desktop sources be pulled from their git releases?
2026-09-04 03:13:11 <hexed> Or maybe I should bug upstream to make new releases to their archive.
2026-09-04 03:18:25 <hexed> I also ran into an issue (can't recall the exact details at the moment) with mate-utils that is fixed by newer source release on their git.
2026-09-04 03:20:56 <hexed> Oh, mate-utils 1.28.1 fixes mate-screenshot unable to save, that's what it was.
2026-09-04 10:28:41 <telmich> I've a question regarding the planning of Alpine 3.25 - are we going to ship with Linux 7.x? I'm asking, because the recent Ceph CVE (https://rook.io/docs/rook/latest-release/Storage-Configuration/Advanced/cephx-key-rotation/#rbd-mirror-peer-keys) requires Linux 7..x to fix kubernetes CSI mounts.
2026-09-04 11:56:24 <ikke> telmich: probably the next lts kernel, which is usually the last kernel released in the year.
2026-09-04 11:56:49 <omni> so it looks like it'll be a 7.x one
2026-09-04 12:33:46 <invoked> hexed_: that's a question for one of the staff. my personal opinion is no, it's not appropriate except in special circumstances. if there is a git tag without a release tarball, maybe.
2026-09-04 12:37:36 <invoked> (if i'm parsing you correctly -- i'm assuming you want to use a release tag, which i think would be fine for this)
2026-09-04 12:38:24 <invoked> but if it's a git snap from head, that's why i said no.
2026-09-04 12:51:14 <hexed> invoked: I think you're parsing me correctly. mate-utils has this tagged release on their git since 9 months ago: https://github.com/mate-desktop/mate-menus/releases#release-v1.28.1
2026-09-04 12:51:15 <omni> what am I not following? I see 1.28.1 here https://github.com/mate-desktop/mate-menus/releases
2026-09-04 12:51:30 <hexed> But they have not released to their website / package archive
2026-09-04 12:51:41 <hexed> Alpine currently pulls from their website / package archive
2026-09-04 12:52:00 <hexed> I think they are going through a transitionary period where they may not have full control of their website.
2026-09-04 12:52:26 <hexed> Is it appropriate to change the APKBUiLD to pull from the git release instead of their website / package archive. That was my question.
2026-09-04 12:52:31 <omni> many projects have lag like that, or worse
2026-09-04 12:52:38 <hexed> yeah.
2026-09-04 12:53:17 <omni> I'd do it, it's a bugfix "FIx failure of mozo to start with newer glib versions due to introspection issue"
2026-09-04 12:54:31 <hexed> Ok, I'll proceed. Appreciate you guys.
2026-09-04 13:43:01 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/107830
2026-09-04 13:49:13 <invoked> hexed: ^
2026-09-04 15:21:53 <Noisytoot> could someone please review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/106210?
2026-09-04 15:23:22 <ikke> !106210
2026-09-04 15:59:39 <midasi> could someone please review !105939 and !107207 I just rebased them
2026-09-04 18:40:40 <omni> fossdd: you don't need to bump testing/ aports in stable branches, they won't build on anything but edge anyways
2026-09-04 18:40:59 <achill> ah damn yeah usually i manually remove the commit
2026-09-04 18:42:30 <omni> thought it was something like that, no biggie
2026-09-04 18:43:57 <omni> telmich: btw, you know that you can use the kernel linux-stable on the latest stable branch? that's 7.1.x in 3.24-stable
2026-09-04 20:50:20 <telmich> omni: Ohh...I did forget about that! That's very helpful actually! Merci
2026-09-05 01:24:40 <omni> achill: perhaps we could skip rebuilding chromium on go security upgrades, it is upgraded frequently enough and takes forever to build
2026-09-05 01:25:36 <omni> I first thought it was !107849 that had gotten in before !107814
2026-09-05 13:00:09 <hexed> thanks n.copa that worked
2026-09-06 11:11:02 <f_> hey, can I get review/merge for !103336 ? It updates the remaining package that depended on botan2 and finally drops botan2 as a result ^^ (cc ncopa)
2026-09-06 11:11:49 <f_> hopefully biboumi becomes viable again for community afterwards :)
2026-09-06 11:38:42 <jvoisin> mhm, would be nice to have a linter yelling when pkgver is bumped but pkgrel isn't reset to zero