2026-07-01 15:07:35 <bdprom> this might be a stupid question, but which runlevel should networking services like dhcpcd, chrony, unbound, wg-quick be added to? 'boot' sounds like its for deeper hardware level services, so i assume these go into 'default', but the wiki seems to suggest adding networking to 'boot'
2026-07-01 15:07:41 <bdprom> maybe it doesnt even matter so much
2026-07-01 15:14:20 <grawity> I don't know the openrc flow well, but my guess would be, if it's not mandatory for the system to work -- e.g. you don't need chrony when doing some rescue tasks -- then I would put it in 'default'
2026-07-01 15:16:30 <PureTryOut> I have networking in general (I don't use the "networking" service but NetworkManager) on default. I have no need for networking during boot
2026-07-01 15:18:30 <bdprom> networking only configures lo for me, so i put it in boot (along with nftables), everything else in default seems to work
2026-07-01 18:03:00 <WhyNotHugo> I'm not a fan of that boot/default distinction: individual services should declare their individual dependencies, on have phases for ordering.
2026-07-01 18:03:27 <WhyNotHugo> I now there are other usages for runlevels, but most setups don't care about that distinction.
2026-07-01 18:37:12 <bdprom> agreed, they're kinda arbitrary it seems, which is why i was confused
2026-07-01 18:37:23 <bdprom> and they do declare their dependencies btw
2026-07-01 18:37:39 <bdprom> via need/use/after/before, etc
2026-07-01 18:41:13 <dwfreed> they aren't that arbitrary
2026-07-01 19:07:38 <bdprom> dwfreed: "kinda" :p.. it is a little confusing though, the wiki says "boot runlevel are those which deal with the mounting of filesystems, setting the initial state of attached peripherals" - does this mean networking config of NICs/wifi cards? and the wiki says to add 'networking' to boot, but other networking services to default
2026-07-01 19:08:24 <bdprom> so how do i know which goes in boot and which in default? dhcpcd in boot maybe? chrony in default i guess makes sense? unbound is dns, so maybe boot?
2026-07-01 19:08:35 <bdprom> ¯\_(ツ)_/¯
2026-07-01 19:08:38 <Sertonix[m]> For some stuff is easier to represent with entire barriers. Eg. when locking down the kernel you don't want any "untrusted" service to be running before the lockdown has finished. But these barriers are typically very configuration specific which causes sysinit/boot/default to loose most of their semantics. For sysadmins it might be best to place everything into defaulg or later. Leaving sysinit/boot for the distro to deal with and
2026-07-01 19:08:38 <Sertonix[m]> "default" as "I don't care" runlevel.
2026-07-01 19:08:44 <dwfreed> all networking should be in default runlevel
2026-07-01 19:09:34 <bdprom> including networking? the wiki says `# rc-update add networking boot`
2026-07-01 19:09:42 <bdprom> Sertonix[m]: that makes sense
2026-07-01 19:09:59 <Sertonix[m]> The wiki says a lot of stuff...
2026-07-01 19:10:22 <bdprom> i think i've figured it out now but maybe it'd be useful to include a directive in the init.d scripts saying which recommended runlevel they go in, or soemthing 
2026-07-01 19:13:03 <dwfreed> In my personal opinion, the wiki is wrong about that part
2026-07-01 19:14:11 <Sertonix[m]> I suspect that "networking" is not used as intended. IIRC in gentoo you ether create networking.<iface> symlinks for static configurations or add something like dhcpcd for more dynamic stuff. Then you can make sure lo is set up early and networking with other machines does not block anything. And you can then make services depend on specific ifaces being setup
2026-07-01 19:16:04 <Sertonix[m]> *alpine does not use "networking" as intended by gentoo
2026-07-01 19:24:40 <bdprom> that's basically what i'm doing now, 'networking' configures lo only, i.e. the bare minimum, dhcpcd starts in default does the rest (along with wpa_supplicant/iwd)
2026-07-01 19:25:06 <bdprom> maybe the wiki needs tweaking a little to explain this better, but i guess openrc is flexible enough that it doesnt matter too much *shrug*
2026-07-01 19:40:35 <dwfreed> if networking only configures 'lo', that should be in boot runlevel
2026-07-01 19:40:58 <dwfreed> (gentoo does the same, net.lo is in boot runlevel, net.<anything else> goes in default runlevel)
2026-07-01 19:41:51 <dwfreed> basically the distinction between boot and default is basically "should this service be started regardless of what our target runlevel is"; yes -> boot, no -> default/whatever
2026-07-01 19:44:40 <bdprom> dwfreed: excellent, so i'm on the right track then
2026-07-01 19:44:45 <bdprom> thanks :)
2026-07-01 22:31:14 <WhyNotHugo> lnl: are you selfisekai on gitlab?
2026-07-01 22:31:44 <lnl> Yet
2026-07-01 22:31:47 <lnl> Yes
2026-07-01 22:32:07 <WhyNotHugo> Do you think it's feasible to package rolldown in a similar way to rollup, or is it a world of pain to try and do so?
2026-07-01 22:36:37 <lnl> Haven't looked into it yet, possibly?
2026-07-01 22:36:46 <lnl> What are you looking at that uses it?
2026-07-02 05:19:38 <fabricionaweb> I think its possible i tried it but I felt down to a recursive dependency 
2026-07-02 05:20:43 <fabricionaweb> They use another 2 or 3 dependency to build it
2026-07-02 05:27:26 <fabricionaweb> vite8 if I recall correctly uses it, and they (rolldown) only provide musl bin for x64
2026-07-02 06:05:05 <maduncle94[m]> Would you guys check for /usr/lib/pkgconfig/libfyaml.pc file ? At 9th line there two words (none and Required) and those would make compilation of appstream failed.
2026-07-02 06:06:29 <maduncle94[m]> *there are
2026-07-02 06:21:47 <Biswa96[m]> yup, I can try to create a merge request to fix it.
2026-07-02 06:44:11 <maduncle94[m]> That would be great, Biswa96.
2026-07-02 07:30:09 <Biswa96[m]> appstream also need an update.
2026-07-02 08:18:45 <Biswa96[m]> this will fix the issue https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104799
2026-07-02 09:55:50 <maduncle94[m]> <Biswa96[m]> "this will fix the issue https..." <- Turns out, switch from "configure-make" build to cmake build (with -DENABLE_LIBCLANG=false) fix the issue.
2026-07-02 09:56:04 <maduncle94[m]> libfyaml 0.9.6.
2026-07-02 11:15:44 <WhyNotHugo> lnl: !104787 !104608, and at least one other open MR
2026-07-02 11:22:58 <runxiyu_>     required by: kleopatra-26.04.2-r0[so:libKPim6Mime.so.6]
2026-07-02 11:22:58 <runxiyu_> ERROR: unable to select packages:  so:libKPim6Mime.so.6 (no such package):
2026-07-02 11:23:00 <runxiyu_> uhhhhhh?
2026-07-02 11:23:02 <runxiyu_> aarch64 edge
2026-07-02 11:36:30 <fabricionaweb> WhyNotHugo if you have interest I can push what I've done to rolldown, tho you probably know more, idk if it helps I can check where I got stuck
2026-07-02 11:58:58 <WhyNotHugo> fabricionaweb: I can have a look, but I doubt I know more.
2026-07-03 04:12:45 <Case_Of> will there be xfwl4 in edge soon ?
2026-07-03 09:49:45 <ionxt_> mesa 26.1.1 has an awful bug on older intel graphics, can someone from the alpine team build the package from a newer version please?
2026-07-03 09:58:09 <ionxt_> There are 3 new versions since 26.1.1 for mesa but no new package for alpine edge. Are there to few resources to build new packages for the main repository?
2026-07-03 20:35:34 <ultro404> hello
2026-07-03 21:03:14 <jvvv> If I add a firmware file path to a *.files file in /etc/mkinitfs/features.d directory, is that file supposed to be in the initfs or in a modloop image?
2026-07-03 21:06:49 <jvvv> Ah, I see it now! The initfs_firmware function removes it!
2026-07-03 21:07:14 <jvvv> Comical
2026-07-03 22:28:47 <Habbie> am i seeing right that diffoscope, packaged in aports, is useless for .apk?
2026-07-03 22:55:00 <Habbie> dwfreed points out that i can just use tar to unpack the apk before
2026-07-03 22:55:07 <Habbie> but direct/native support would be cooler :)
2026-07-03 22:55:33 <dwfreed> Habbie: and indeed, diffoscope has no support for Alpine APKs (apparently neither v2 nor v3)
2026-07-03 22:56:00 <dwfreed> I suspect 'file' reports it as an Alpine APK rather than "just" a tarball
2026-07-03 22:56:10 <Habbie> ack. i suspected as much after it churned for 25 minutes and then showed me the tail end of a hexdump diff in my terminal ;)
2026-07-03 22:56:24 <Habbie> /home/peter/packages/community/x86_64/dnsdist-2.1.0-r0.apk: gzip compressed data, max compression, from Unix, original size modulo 2^32 9134080
2026-07-03 22:56:26 <dwfreed> so diffoscope doesn't use the "just a tarball" mode
2026-07-03 22:56:34 <dwfreed> hmm, add -z
2026-07-03 22:56:43 <Habbie> gzip -cd | file says POSIX tar
2026-07-03 22:56:49 <dwfreed> odd
2026-07-03 22:56:53 <Habbie> /home/peter/packages/community/x86_64/dnsdist-2.1.0-r0.apk: POSIX tar archive (gzip compressed data, max compression, from Unix, original size modulo 2^32 9134080)
2026-07-03 22:56:55 <Habbie> TIL file -z
2026-07-03 22:57:10 <dwfreed> also file -r --keep-going is nice too
2026-07-03 22:57:46 <Habbie> that one doesn't spot the tar
2026-07-03 22:58:14 <dwfreed> yeah, it doesn't peek into compression, but is useful for other things that match multiple magics
2026-07-03 22:58:26 <Habbie> ah right
2026-07-03 22:58:36 <dwfreed> like a "DOS/MBR boot sector" that is followed by an ExFat filesystem...
2026-07-03 22:59:17 <dwfreed> I kind of wanted to know about the ExFat and not the boot sector, but okay file, have it your way
2026-07-03 22:59:21 <Habbie> :)
2026-07-03 23:01:22 <Sertonix[m]> I have used diffoscope to compare v2 apk-tools packages multiple times. Maybe the commands that diffoscope needs for this analysis are not installed?
2026-07-03 23:02:07 <Habbie> Sertonix[m], interesting
2026-07-03 23:02:41 <Habbie> do you happen to know what commands those would be?
2026-07-03 23:04:37 <Sertonix[m]> In a clean alpine edge VM I just installed diffoscope and could compare the busybox and busybox-static packages from cdn.
2026-07-03 23:04:46 <Habbie> ah. i now tried diffoscope on two very small packages, and it turns out the hexdump diffs are in fact of files inside the package
2026-07-03 23:05:18 <Habbie> so it does work, if slowly, and not at all useful to me in the way pkgdiff output is
2026-07-03 23:05:22 <Habbie> thanks for the poke, Sertonix[m] 
2026-07-03 23:06:23 <dwfreed> aha
2026-07-03 23:06:25 <Sertonix[m]> diffoscope probably has a way to disable hexdump diff above a specific file size.
2026-07-03 23:06:44 <Habbie> i bet
2026-07-03 23:07:02 <dwfreed> and can probably be avoided with the right optional tools installed, depending on what is being diffed
2026-07-03 23:07:05 <Habbie> i guess it comes down to default behaviour, where what i've gotten used to in pkgdiff is not the default behaviour of diffoscope
2026-07-04 12:20:53 <dmi> is there a way to disable apk-tools 3 syncing disks behavior? I find it to be incredibly hostile on machines with more than one drive
2026-07-04 12:30:34 <Sertonix[m]> Yes, --sync=no or --no-sync or into /etc/apk/config a sync=no line should work
2026-07-04 12:30:52 <dmi> thanks!
2026-07-04 15:36:19 <prabu> dmi, i'll appreciate if you can share more information on the difficulty faced with apk v3 in machines with multiple drives, so this issue can be documented properly in wiki. i checked gitlab for any open issues, couldn't find any. appreciate if you can share more information..
2026-07-04 17:30:15 <dmi> prabu quit but i'll write it down anyways: if you run apk during large block copies (i.e. with dd), it will hang until the dd has finished. which in multiple cases meant that I needed to force kill *something* because otherwise I wouldn't be able to run whatever I had just installed. this is especially nonsensical when running from RAM, which I often do when I netboot to copy a hard drive or something
2026-07-04 17:30:59 <dmi> ideally, apk should use the sync syscall specifying the rootfs (fsync? i don't remember), not just sync outright
2026-07-04 17:32:27 <dmi> it's also just annoying if you have a lot of IOPS on a machine and suddenly you have to wait for it to flush everything to disk before you can continue. takes apk from "oh my gosh, I can't believe how much faster than everything else this feels!" to "oh ffs, i have to wait 15 seconds AGAIN!?"
2026-07-04 18:46:43 <Swirly> small heads up: the `schismtracker` module is out of date (packaged version is 20251014 while https://schismtracker.org says latest is 20260524)
2026-07-04 19:07:58 <Biswa96[m]> @Swirly do you have any test cases for that?
2026-07-04 19:08:37 <Swirly> sorry?
2026-07-04 19:09:30 <Biswa96[m]> could you provide some tests for the new version of that program?
2026-07-04 19:09:49 <Biswa96[m]> Or, could you test the new version?
2026-07-04 19:10:07 <Swirly> i can do that yeah
2026-07-04 19:22:24 <Swirly> 20260524 seems to work just fine
2026-07-04 19:31:18 <Sertonix[m]> dmi, prabu: I wonder if we should be proposed to remove the sync call again, it added 5 minutes per commit in some of my cases: https://gitlab.alpinelinux.org/alpine/apk-tools/-/work_items/11167#note_565692
2026-07-04 19:38:52 <Biswa96[m]> Swirly: I have created a merge request to update it https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104891
2026-07-04 19:41:14 <Swirly> amazing
2026-07-04 22:57:35 <dmi> Sertonix[m]: btw `sync=no` in the config throws `WARNING: config: unrecognized option 'sync=no'` now that i tried it...
2026-07-04 22:57:47 <dmi> apk-tools 3.0.6-r0
2026-07-04 23:45:04 <Sertonix[m]> I may have misremembered the syntax. I use this: https://codeberg.org/sertonix/aports/src/branch/main/custom/0+base/apk.config
2026-07-05 03:02:09 <prabu> dmi, the syntax was not correct. i've updated wiki here. https://wiki.alpinelinux.org/wiki/Alpine_Package_Keeper#Sync_option  please feel free to add/edit as appropriate
2026-07-05 03:05:20 <prabu> Sertonix, i use alpine only on 3 devices and have not issues with sync option. Since it affects only certain use cases, leaving this documented is a better option than disabling it.
2026-07-05 03:07:00 <Sertonix[m]> apk-tools didn't call sync for a long time and I have never seen anybody having issues due to that.
2026-07-05 03:36:26 <saarrdt[m]> Hello is this alpine linux
2026-07-05 03:40:10 <longnoserob[m]> hello
2026-07-05 08:08:12 <frag> can links -dump include linked to urls?
2026-07-05 08:46:39 <lopid> what does its doc say?
2026-07-05 08:49:11 <frag> i didnt find anything about it
2026-07-05 09:33:33 <quinq> What is a linked to urls?
2026-07-05 09:36:20 <frag> hyperlink
2026-07-05 09:39:49 <quinq> Ah, links?
2026-07-05 09:40:57 <frag> yeees
2026-07-05 09:42:19 <quinq> Try with -html-numbered-links
2026-07-05 09:42:31 <quinq> (I just read the man-page)
2026-07-05 09:48:03 <frag> oh nice, was sure that was only for browsing, like pentadactyl
2026-07-05 10:01:55 <lopid> quinq = llm
2026-07-05 10:02:55 <noodle> local linux manpage?
2026-07-05 10:22:20 <HappMacDonald> Good day 🙂
2026-07-05 10:24:11 <HappMacDonald> I would like to be able to send the syslog messages from my Alpine Linux server to a remote rsyslog address. Is that something the built-in busybox syslog can do or do I need the rsyslog package? One reason I ask is that I notice that the https://pkgs.alpinelinux.org/package/edge/main/x86/rsyslog shows the version number in red (which.. there is no legend but I interpret that as meaning "out of date" or "unmaintained" or s
2026-07-05 10:24:17 <quinq> low-level monitor
2026-07-05 10:24:38 <HappMacDonald>  and the instructions from https://www.rsyslog.com/alpine-repository/ say to use an external repo, but that external repo appears to be stuck at Alpine 3.7 somehow?
2026-07-05 10:25:16 <quinq> That sounds like bad recommendation from them :/
2026-07-05 10:26:13 <quinq> Current Alpine version is 8.2604.0 against upstream 8.2606.0, doesn't look too bad
2026-07-05 10:27:29 <quinq> Error resolving “git.adiscon.com”: Name does not resolve
2026-07-05 10:27:45 <quinq> Apparently they have Internet issues
2026-07-05 10:27:55 <HappMacDonald> That's nice to know, thank you quinq. Any idea why the version number is shown in red? Does that indicate something other than 'danger' of any variety on this page?
2026-07-05 10:29:13 <quinq> https://raw.githubusercontent.com/rsyslog/rsyslog/refs/heads/main/ChangeLog apparently 8.2606.0 is actually unreleased 
2026-07-05 10:29:46 <quinq> Ah no, wait
2026-07-05 10:30:29 <quinq> There is 8.2606.0, and more recent is 8.2604.1
2026-07-05 10:30:36 <quinq> So is 8.2604.* some sort of LTS?
2026-07-05 10:32:43 <quinq> Yeah, the red is, I think, a result of being automatically tagged as out-of-date by a bot from https://release-monitoring.org/project/4218/
2026-07-05 10:32:59 <quinq> Anyway, that's not your actual issue
2026-07-05 10:36:05 <quinq> HappMacDonald, the busybox “man-page” says syslogd can log to a remote host
2026-07-05 10:38:19 <lopid> /msg quinq /models
2026-07-05 10:39:19 <quinq> 
ACTION strips off lightly

2026-07-05 10:39:27 <lopid> /quit!
2026-07-05 10:39:50 <HappMacDonald> Nice, I will investigate doing that first then. It is also helpful to know that the alpine package for rsyslog is most likely maintained and up to date (and that the advice from rsyslog.com is out of date) as in a week or so I'm liable to rebuild our rsyslog host to also run on Alpine instead of Debian. 🙂
2026-07-05 10:40:10 <quinq> noiiice
2026-07-05 10:40:44 <quinq> Stick around though if you can, I've never tested that featureof busybox, hopefuly somebody else with actual experience on this can give some better feedback :)
2026-07-05 10:41:06 <quinq> But yeah, trying it out yourself is most of the time a requirement and a good way to learn/make sure anyway
2026-07-05 10:42:26 <HappMacDonald> I've added `-R <rsyslog.server.IP>:<port> -L` to SYSLOGD_OPTS in /etc/conf.d/syslog and run `rc-update add rsyslog`, and I can now confirm that the log entries are being posted remotely so that bit seems to work out quite well 😎
2026-07-05 10:42:41 <quinq> noiiice
2026-07-05 10:42:59 <quinq> (^--- lame llm)
2026-07-05 10:45:13 <HappMacDonald> It's mostly a kvetch, and I don't know if it's really a problem with Debian or with Linux Kernel in general, but on my airgapped network I had a bunch of Debian Stretch servers ticking along smoothly for ten years or so running things like Perl scripts using Parallel ForkManager to spin up different monitoring processes on hosts with 512MB of RAM
2026-07-05 10:46:38 <HappMacDonald> When I upgraded them to Trixie (through all of the intermediate steps, isn't that always fun) suddenly they have problems where oomkiller comes in and murders the processes or sometimes the spawning daemon. I can never see the memory getting full so whatever spooks oomkiller must be spiky, and even increasing RAM to 4GB per host does nothing to stop it 😕
2026-07-05 10:47:53 <HappMacDonald> Among my longshot hopes is that rebuilding those servers on Alpine might change that behavior. But if it was a shift in Linux Kernel memory management itself then that might not be helpful either 🤷‍♂️
2026-07-05 10:49:38 <HappMacDonald> Could be something more fine grained like "running out of kernel memory" or stuff being paged badly or newer fangled NUMA concerns like "ran out of memory local to that vCPU instance" or heaven knows what. I miss the days when RAM was more like a gas tank 😋
2026-07-05 10:53:41 <quinq> Yeah, Linux memory management is crazy
2026-07-05 10:54:39 <HappMacDonald> If it gets bad enough I am keeping the idea of researching BSD in the wings, but I have no guarantee that it is any less crazy over there 😓
2026-07-05 10:57:04 <HappMacDonald> (squints at message above) s/rc-update add rsyslog/rc-service syslog restart/ ... I pasted the wrong line from my bash history into that message lol
2026-07-05 17:13:31 <witix> I've been looking around for a solution online but failed miserably so I'm just going to ask here if okay ^^" Some QT applications, notably KeepassXC, don't follow the system color scheme's background color and instead use this weird, slightly blue-tinted light theme. I'm pretty sure it's a matter of installing some package from the repository, since I had the same issue with programs in the Debian chroot and managed to fix this by installing the whole 
2026-07-05 17:13:33 <witix> kde-plasma-desktop package. Has anyone had a similar problem and managed to find the package that needs to be installed, or just has a gut feeling what it might be?
2026-07-05 17:24:18 <lopid> i don't see what package as qt5ct
2026-07-05 17:42:12 <quinq> witix, Internet hints at qadwaitadecorations, maybe
2026-07-05 18:21:27 <f_> lopid: I guess it was purged as part of the Qt5 purge
2026-07-05 19:35:26 <lopid> t'was for witix
2026-07-06 06:12:18 <EamonBurns[m]> Hello 👋 
2026-07-06 06:12:18 <EamonBurns[m]> Direct firmware load for iwlwifi-QuZ-a0-hr-b0-77.ucode failed with error -2
2026-07-06 06:12:18 <EamonBurns[m]> ```
2026-07-06 06:12:18 <EamonBurns[m]> I am trying to setup Alpine, but my Wifi card doesn't seem to be detected. `ip link` only shows `lo` and `eth0`, and `dmesg | grep iwlwifi` shows the message
2026-07-06 06:12:18 <EamonBurns[m]> Detected Intel(R) Wi-Fi 6 AX201 160MHz
2026-07-06 06:12:19 <EamonBurns[m]> no suitable firmware found!
2026-07-06 06:12:19 <EamonBurns[m]> ```
2026-07-06 06:12:58 <f_> EamonBurns[m]: install firmware
2026-07-06 06:13:08 <f_> apk add linux-firmware-iwlwifi iirc
2026-07-06 06:14:01 <EamonBurns[m]> No Ethernet access unfortunately. Would I be able to download an APK file?
2026-07-06 06:15:05 <f_> yes
2026-07-06 06:20:15 <jvvv> package is linux-firmware-intel for that ucode file
2026-07-06 06:35:02 <EamonBurns[m]> Got it, thanks. I have the .apk on a USB and I'm now just waiting for it to boot
2026-07-06 06:43:27 <EamonBurns[m]> I'm getting a bunch of errors when running `apk add --force-non-repository /path/to/linux-firmware-intel-*.apk`, all in the format:
2026-07-06 06:43:27 <EamonBurns[m]> ```
2026-07-06 06:43:27 <EamonBurns[m]> ERROR: linux-firmware-intel-*: failed to extract lib/firmware/<filename>: Read-only file system
2026-07-06 06:43:27 <EamonBurns[m]> ```
2026-07-06 06:43:27 <EamonBurns[m]> I'm guessing this is because it's a live boot, but I'm not sure how to fix it
2026-07-06 06:48:09 <ikke> You need to chroot into your installation and install it then
2026-07-06 06:48:59 <EamonBurns[m]> That would be after I go through setup-alpine?
2026-07-06 06:54:24 <jvvv> Would it be possible to copy the modloop contents to temporary location, umount the modloop, mv the copied directories from the modloop to where they belong, then install the firmware package?
2026-07-06 06:56:19 <jvvv> I'm guessing it depends on how much memory that the machine has since it is operating in initramfs space
2026-07-06 06:59:25 <jvvv> Seems like I've done something like that before, but if it worked I'm pretty sure the system had 32gib of ram, maybe more. Wish I could remember that better.
2026-07-06 07:01:29 <jvvv> Another option would be to mount an overlayfs that had /lib as the lowerdir
2026-07-06 07:05:17 <EamonBurns[m]> That sounds like a bunch of fancy words that I should learn more about. But, it's midnight now, and I need to wake up for work tomorrow 🤣
2026-07-06 07:05:17 <EamonBurns[m]> Thank you everyone for the help, but I'm going to bed now 🫡
2026-07-06 07:09:26 <jvvv> good night
2026-07-06 07:14:11 <jvvv> ikke: I think it would be enough to run 'mkdir /tmp/upper /tmp/work; mount -t overlay overlay -olowerdir=/lib/firmware,upperdir=/tmp/upper,workdir=/tmp/work /lib/firmware', then the installed files would physically end up in /tmp/upper, but would also be visible in /lib/firmware
2026-07-06 08:54:37 <Habbie> can i get openrc working (just for init script testing purposes) in an alpine container?
2026-07-06 09:00:45 <Habbie> ah, people have made images that solve this
2026-07-06 16:25:07 <TBB_> okay, which one of you took my openssh init script and can I have it back please?
2026-07-06 17:27:54 <jvvv> TBB_: it is right where you left it, probably near you  car keys
2026-07-06 17:31:27 <TBB_> but, but
2026-07-06 17:31:39 <TBB_> I don't keep my car keys in /etc/init.d/ :(
2026-07-06 17:35:02 <jvvv> Well, I guess that explains why it is never good to leave the gate open to your /etc/init.d
2026-07-06 19:07:31 <TBB_> I seem to have multiple problems with 3.24.1, but then, I can't really tell whether I'm also having hardware problems at the same time. I used to be able to make a fully manual install with my eyes closed but it didn't feel like that yesterday anymore
2026-07-06 19:57:52 <Sertonix[m]> TBB_: Do you mean that something has changed with how /etc/init.d is handled? There has been a similar report of update-conf -i not overwtiting files. I wonder if there is some unintended apk-tools change involved.
2026-07-06 20:11:24 <EamonBurns[m]> jvvv: jvvv: the overlayfs worked!
2026-07-06 20:15:44 <jvvv> EamonBurns[m]: Nice! I thought it might.
2026-07-06 20:20:37 <qbit> anyone running on the old IMX mnt reform? :D
2026-07-06 20:29:26 <dmi> could we get linux-lts bumped to 6.18.38 to mitigate https://www.openwall.com/lists/oss-security/2026/07/06/7 ?
2026-07-06 20:36:45 <dwfreed> it'll presumably get bumped by security soon
2026-07-06 20:37:18 <ellyqw> aw, and i smelled an opportunity to send my first MR
2026-07-06 20:37:40 <dwfreed> I mean, you could do the MR anyway, I'm sure they wouldn't mind somebody doing their work for them
2026-07-06 20:39:36 <dwfreed> actually it's already there
2026-07-06 20:39:59 <dwfreed> edge is the one lacking
2026-07-06 20:41:39 <ellyqw> huh? I don't see an open MR nor git log: https://gitlab.alpinelinux.org/alpine/aports/-/commits/master/main/linux-lts/APKBUILD
2026-07-06 20:43:10 <dwfreed> like I said, edge is the one lacking
2026-07-06 20:43:14 <dwfreed> it is there in 3.23 and 3.24
2026-07-06 20:47:24 <ellyqw> alka@sakamoto:~$ ll /mnt/alpine/alpine/v3.24/main/x86_64/linux-lts*
2026-07-06 20:47:24 <ellyqw> -rw-r--r-- 1 ci ci 139M Jul  5 18:01 /mnt/alpine/alpine/v3.24/main/x86_64/linux-lts-6.18.38-r0.apk
2026-07-06 20:47:37 <ellyqw> you're right, i guess i'm too used to how pmOS does stuff
2026-07-06 20:48:38 <ellyqw> cc: dmi you can just install the pakigde, no need to build
2026-07-06 20:49:20 <dmi> ellyqw: lmao, it must have went up between me upgrading and me starting to build
2026-07-06 20:49:52 <dmi> wait. is it in 3.24 but not in edge?
2026-07-06 20:50:01 <ellyqw> yeah, that sounds... weird
2026-07-06 20:50:24 <ellyqw> i would've assumed it would show in git history, get built in edge and then backported, just how pmOS does it
2026-07-06 20:51:04 <dmi> added `/mnt/alpine/alpine/v3.24/main` to /etc/apk/repositories and that resolved it *shrug*
2026-07-06 20:51:09 <dmi> weird glitch
2026-07-06 20:51:18 <ellyqw> freakin' computers
2026-07-06 20:57:44 <EamonBurns[m]> I am trying to install Alpine into a single partition on my existing Linux laptop, and just add a bootloader entry for it. The sys option in setup-alpine prompts to erase my whole disk. Is there a different option I can use for this?
2026-07-06 20:58:58 <ellyqw> i don't recall exactly which options alpine-installed has, but i'm certain one of them allows you to specify partitions
2026-07-06 22:06:08 <EamonBurns[m]> Looking at the Dualbooting Wiki page, it looks like I need to select none and then continue manually
2026-07-06 22:07:35 <TBB_> I've just finished a 2 hour manual install session. How quickly one forgets all the little things...
2026-07-06 22:11:52 <quinq> TBB_, that's why you install once, never throw away
2026-07-06 22:13:04 <TBB_> I thought I had all this solved, I wrote an entire Alpine Linux installer once
2026-07-06 22:13:14 <TBB_> but I forgot how to use it :D
2026-07-06 22:28:36 <TBB_> well, the setup works now, and I couldn't replicate the missing /etc/init.d/sshd script
2026-07-07 07:24:05 <rnkn> damn it busybox why don't you have md5
2026-07-07 07:32:23 <rnkn> can I get md5 without installing all of coreutils?
2026-07-07 07:32:45 <rnkn> oh wait, doesn't openssl have md5...
2026-07-07 07:33:38 <aron> afaik busybox has md5sum
2026-07-07 07:34:07 <rnkn> oh
2026-07-07 09:52:10 <Arthur_> Following instructions from https://wiki.alpinelinux.org/wiki/Distrobox to set up a rootless distro container doesn't seem to work OOB: (error: exit status 1; output: potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/gshadow: invalid." I should probab
2026-07-07 09:52:40 <Arthur_> I am running labwc however, so it could be I set up labwc environment wrong
2026-07-07 10:10:43 <Sertonix[m]> The "rootless" container uses a setuid binary to map multiple uid/gid in the user namespace. That configuration needs to be done with root priviledges in the mentioned /etc/subuid, /etc/subgid files
2026-07-07 10:17:44 <prabu> Arthur_, https://wiki.alpinelinux.org/wiki/Podman#Running_in_rootless_mode - the linked page has instructions to configure rootless mode
2026-07-07 10:21:37 <ikke> ftr, Arthur_ already lefrt before Sertonix[m] reply
2026-07-07 10:33:37 <prabu> thanks @ikke for the note. i too login to irc only to respond as i read the logs mostly. https://wiki.alpinelinux.org/wiki/Distrobox page updated
2026-07-07 11:11:43 <Arthur_> Hi, I'm back and read the logs. Y'all are being very helpful, thankyou. I noticed my initial message was cut off, perhaps because it was too long.
2026-07-07 11:13:03 <Arthur_> Or I litterally forgot to type that part.. I was in a rush so I wouldn't be surprised
2026-07-07 11:16:16 <ikke> Probably truncated given the length
2026-07-08 06:57:21 <sogaiu[m]> Eamon Burns: fwiw: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/work_items/10646
2026-07-08 13:20:35 <Arthurium> I'm going to say it right now: the workflow of setting up my own script to execute a root command on startup on OpenRC actually feels normal, not systemD where services are not really scripts and I need to point a service with specific syntax buried deep in /etc/ at my script in /opt/ and it takes me twice as long.
2026-07-08 13:20:56 <Arthurium> Or 3 times as long
2026-07-08 13:23:29 <Arthurium> Like, the wiki only had to give me 3 sentences to explain how to do it. That is telling. https://wiki.alpinelinux.org/wiki/OpenRC#Runlevels
2026-07-08 13:24:50 <Arthurium> Oh I meant to link this: https://wiki.alpinelinux.org/wiki/OpenRC#Local_service
2026-07-08 13:26:20 <lopid> you said it 
2026-07-08 21:17:28 <Noisytoot1> mpv is currently broken in edge: libavcodec: build version 62.28.102 incompatible with runtime version 62.28.101
2026-07-08 21:23:09 <quinq> Noisytoot1, worksforme, on which arch?
2026-07-08 21:23:48 <Noisytoot1> quinq: x86_64
2026-07-08 21:25:36 <quinq> I don't get that error, how to reproduce it?
2026-07-08 21:26:28 <Noisytoot1> > mpv
2026-07-08 21:26:30 <Noisytoot1> libavcodec: build version 62.28.102 incompatible with runtime version 62.28.101
2026-07-08 21:26:36 <Noisytoot1> literally just running mpv is enough
2026-07-08 21:26:49 <quinq> Maybe try apk upgrade -a
2026-07-08 21:30:04 <Noisytoot1> that fixed it
2026-07-08 21:30:12 <quinq> nice
2026-07-09 06:41:25 <Ozymandias42> morning. question: What's the recommended way of modifying openrc service files? On systemd it is to NOT do so and instead make use of override files but I don't think openrc has that and simply modifying a file that is set -and potentially overridden on upgrade- by a package feels wrong.
2026-07-09 06:51:17 <ikke> Ozymandias42: depending on what you want to modify, some things can be set in the corresponding /etc/conf.d/ file
2026-07-09 06:52:55 <Ozymandias42> in my case there is no such file
2026-07-09 07:03:38 <ikke> You can create it
2026-07-09 07:03:58 <ikke> The name should match the init.d file
2026-07-09 07:04:26 <Ozymandias42> will do. thx
2026-07-09 07:07:22 <TBB_> that, of course, requires that the corresponding init.d script actually uses the conf.d file
2026-07-09 07:07:50 <TBB_> hello ikke, still in Alpine action I see
2026-07-09 07:18:03 <ikke> TBB_: openrc automatically sources the conf.d file 
2026-07-09 07:19:04 <ikke> And you can use it to adjust openrc settings through variables even if the init.d file does not refer directly to variables in the file
2026-07-09 07:23:29 <TBB_> variables, yes. code? I haven't tried that. but then, the original question wasn't very specific about the type of modifications
2026-07-09 07:25:06 <TBB_> but if I remember correctly, if you modify an init.d script and the package owning that script is updated, the script doesn't get overwritten. there was some logic to it that I can no longer remember (I've been away from active Alpine operations for 7 years now)
2026-07-09 07:25:46 <TBB_> was it that the new version gets added as .apk-new or something like that?
2026-07-09 07:40:58 <ikke> Yes
2026-07-09 07:41:05 <ikke> Files in /etc are protected 
2026-07-09 09:53:12 <aud2ks6l3> audit_aud2ks6l3_1783590792
2026-07-09 09:53:42 <aud2ks6l3> link_aud2ks6l3 https://google.com
2026-07-09 09:57:06 <aud7wmcr6> audit_aud7wmcr6_1783591026
2026-07-09 09:57:36 <aud7wmcr6> link_aud7wmcr6 https://google.com
2026-07-09 10:17:15 <JustSouptheyhe[m]> Saw these weird bots in the pmOS room too. After banning the two of them, new bots didn't come in, so that might be enough.
2026-07-09 10:49:13 <panekj> 
ACTION shrugs

2026-07-09 10:51:11 <ikke> It's the same IP every time
2026-07-09 10:51:44 <panekj> yes, from Belarus
2026-07-09 10:51:55 <panekj> could just ban the IP instead of usernames
2026-07-09 10:51:59 <ikke> which is what I did
2026-07-09 10:52:24 <panekj> I meant for pmOS channels
2026-07-09 19:17:01 <Lord> dl-cdn.alpinelinux.org is dead ?
2026-07-09 19:18:09 <Arthurium> I'm having an issue with starting SDDM. New install, graphics drivers set up, network set up, then did setup-desktop Plasma. Could have been an update because my old install still had a working SDDM, with the same setup except labwc as a secondary desktop.
2026-07-09 19:18:26 <Arthurium> @Lord still works for me
2026-07-09 19:18:26 <efahl> Lord: Looks ok to me.  I'm California so exit node is probably LA.
2026-07-09 19:25:35 <Arthurium> OpenRC tells me "* Starting Display Manager" but it has an issue it seem because it's not starting it, even after a reboot 
2026-07-09 19:32:27 <jvvv> Arthurium: I just fixed similar sounding issue with sddm on my wife's laptop. Trying to remember what it was and how I fixed it. I do recall that the fix was really easy, like adding or adjusting one line in the sddm.conf file I think
2026-07-09 19:35:08 <Arthurium> I will try out a few SDDM options. It seems to not find my laptop's display, possibly a simple variable will fix it. I will mess around with that. Thanks
2026-07-09 19:36:49 <jvvv> I'm booting my wife's laptop now so I can look at it and maybe jog my memory
2026-07-09 19:38:18 <jvvv> But it is having other unrelated issues, so might be some time before I get to it, idk
2026-07-09 19:39:04 <Arthurium> ITS FIXED
2026-07-09 19:40:01 <Arthurium> I added "QT_QPA_PLATFORM=Wayland". Then rebooted
2026-07-09 19:40:42 <Arthurium> Initially restarted the sddm service after that addition, but that didn't make it start. But the reboot did somehow
2026-07-09 19:41:10 <jvvv> Yes, that jogs my memeory enough. Same fix here
2026-07-09 19:41:44 <jvvv> Required reboot also
2026-07-09 19:42:27 <Arthurium> Ah okay
2026-07-09 19:46:54 <jvvv> It was frustrating, I remember that... I tried a whole slew of things, even other display managers (I got them to work, but I knew wouldn't be OK for my wife). I wish I had fixed it a quickly as you did... I felt very silly once I got it fixed with that addition to the config after spending so much time
2026-07-09 19:47:15 <jvvv> s/a quickly/as quickly/
2026-07-09 19:50:49 <Arthurium> By coincidence I knew that variable from trying to run QT apps with wayland-based fractional scaling on my small 1440p laptop display. It's the only way I got Krita to not be blurry on Labwc fractional scaling.
2026-07-09 19:52:58 <jvvv> Glad you got it fixed. Sddm is good... except when it isn't. I like my setup just using startx, but that's my preference and not one I push around
2026-07-09 19:55:09 <Arthurium> Understandable
2026-07-09 19:56:01 <jvvv> When I have tried various wayland compositors, I have used seatd-launch which I find similarly straight forward. The approach isn't for everyone, but I have found it stable
2026-07-09 19:57:00 <jahway603[m]> Arthurium: this fix may be worth adding to the SDDM page on the Alpine wiki at https://wiki.alpinelinux.org/wiki/SDDM
2026-07-09 19:57:04 <Arthurium> I'm only recently getting into "DIY desktops" and display managers. I still have much to learn. Alpine seems to be a great place to do that
2026-07-09 19:58:03 <Arthurium> jahway603, indeed, others might encounter the same
2026-07-09 19:58:13 <Arthurium> I will
2026-07-09 19:58:33 <jvvv> jahway603[m]: Very cool. I should have done that myself... excuses are pointless. Good on you
2026-07-10 04:42:58 <cpanceac> hello. the documentation say: System or sys Disk Mode is the traditional hard-disk install. Alpine Linux can be installed to an entire hard disk using setup-alpine script or to a partition using setup-disk script. 
2026-07-10 04:43:37 <cpanceac> does this mean i have to run setup-alpine, skip the disk install, then run setup-disk to complete install to a partition?
2026-07-10 04:44:09 <cpanceac> https://wiki.alpinelinux.org/wiki/Installation
2026-07-10 04:52:33 <jvvv> cpanceac: You can do that by mounting your intended partition to /mnt then running something like: DISKOPTS="-m sys /mnt" setup-alpine
2026-07-10 04:55:05 <cpanceac> nice, thank you jvvv . but in the meantime i completed setup-alpine (with 'none' at setup disk). so will now running setup-disk allow me to complete the alpine install to partition?
2026-07-10 04:55:51 <jvvv> I've never tested that
2026-07-10 04:56:35 <cpanceac> thank you jvvv . maybe it's simpler to just folow your advice
2026-07-10 04:58:20 <jvvv> I have used the suggestion I gave many times, so I think that should be safe
2026-07-10 05:00:46 <jvvv> But answering 'none' when setup asks for disk means it is a diskless install
2026-07-10 05:01:31 <jvvv> I should test out what you are asking about, just won't be tonight
2026-07-10 05:02:47 <jvvv> Or this morning, I guess
2026-07-10 05:06:19 <cpanceac> much appreciated jvvv . but now i'm wondering if the partition should be formatted before passing it to setup-alpine. ig yes. i wonder how is setup-alpine doing it since e2fsprogs seem to be not present
2026-07-10 05:06:51 <cpanceac> ....how, in case of full disk, ....
2026-07-10 05:08:51 <cpanceac> ok, i see vfat is supported
2026-07-10 05:17:25 <cpanceac> ok, but maybe i should have mounted the efi partition too ....
2026-07-10 05:19:51 <cpanceac> install failed. mounting uuid on /sysroot failed: no such file  or directory.gotta investigate now. 
2026-07-10 05:25:46 <cpanceac> to clarify: install gave error related to /EFI, but completed. after reboot, i get the /sysroot error
2026-07-10 05:26:18 <cpanceac> on the other hand, maybe i need to regenerate debian's grub.
2026-07-10 05:33:04 <jvvv> cpanceac: Alpine's EFI install does not add an boot entry into the efivars (ie, like with efibootmgr), so probably if you have an parallel install that does osprober, that will probably help you (ie, your debian's grub.cfg).
2026-07-10 05:35:16 <cpanceac> indeed, in grub.cfg there was the old uuid. after fixing that, all works. thank you for support jvvv 
2026-07-10 05:35:33 <jvvv> yw
2026-07-10 05:35:41 <jvvv> Glad you got it sorted
2026-07-10 05:35:47 <EamonBurns[m]> > does this mean i have to run setup-alpine, skip the disk install, then run setup-disk to complete install to a partition?
2026-07-10 05:35:47 <EamonBurns[m]> I remember this being similar to what it says to do in the Dual Booting wiki.
2026-07-10 05:35:47 <EamonBurns[m]> Looking at it further, that is just the `setup-disk` installation: https://wiki.alpinelinux.org/wiki/System_Disk_Mode
2026-07-10 05:37:09 <jvvv> Yeah, I've looked at that... I think that page could use some updating, though. I'll try to get to it if someone doesn't beat me to it
2026-07-10 05:37:37 <cpanceac> EamonBurns[m], right , but it also says: "after completing the base configuration" . This, i assume is running setup-alpine. Please correct me if i'm wrong,i'm new to Alpine
2026-07-10 05:39:39 <jvvv> That sounds like the right way, I just have had ugly times trying to do it peice meal
2026-07-10 05:41:13 <cpanceac> now i'm afraid to try again to add a desktop interface. even if, now i have a better way to re-install . still not clear what to do with the efi partition, but i'm better today than yesterday
2026-07-10 05:42:54 <cpanceac> (bbl)
2026-07-10 06:07:24 <cpanceac> a curious thing, reboot: operation not permitted. CTRL_ALT_DEL, rebooting system ...
2026-07-10 06:36:06 <cpanceac> ok, so setup-disk was all that i need. great
2026-07-10 06:36:30 <cpanceac> sorry, setup-desktop, i mean
2026-07-10 06:42:47 <cpanceac> hmm, pipewire is installed but no sound in my usb haedphones
2026-07-10 06:45:59 <cpanceac> oops, it was not installed. how can i check if something is installed or not?
2026-07-10 07:01:41 <cpanceac> to use ACF, do i need a different user ? (not the Alpine user...)
2026-07-10 07:15:07 <telmich> Recently when running apk upgrade -aU the keyboard input language is reset during the update. It happened on 4 devices so far, I wonder if that is considered to be a bug in xorg
2026-07-10 13:20:38 <Arthurium> Hi, I'm having an issue with UID/GID userspace mappings, trying to create a Distrobox container as non-root, and followed the instructions on the wiki, and this time I did properly set up podman to run in rootless mode (tested that using the wiki example: podman run --rm hello-world). I'm running KDE Plasma.
2026-07-10 13:26:00 <Arthurium> I have logged in and out again but I will try a reboot as well now
2026-07-10 13:30:54 <jvvv> Arthurium: have you verified that /etc/subuid and /etc/subgid are correct and that you have the shadow-subids package installed?
2026-07-10 13:41:24 <jvvv> I haven't messed with distrobox, though I am aware of its existence and purpose (generally). But looking at our wiki page for it, I see one possible problem that could come up is that if there are multiple entries in /etc/sub{u,g}id, then you must ensure that the numerical subordinate id is unique for each and that the different entries don't overlap
2026-07-10 13:42:48 <Arthurium> jvvv: This is embarrasing, because I typed over the command manually, I made a typo and only mapped GID and not UID. Now it works, after having mapped GID too using the wiki command!
2026-07-10 13:43:28 <jvvv> Good deal. I thought that would be a good place to start checking
2026-07-10 13:46:12 <jvvv> If you ever add another entry to those files, be sure that middle value does not fall withing the range of any other entry. Range being subid + count
2026-07-10 13:47:59 <jvvv> I only ever write one of those files manually, then copy that to the other so that they match (I find that easier to manage)
2026-07-10 13:48:00 <Arthurium> Oh all right
2026-07-10 13:48:31 <Arthurium> I'm not sure if I'll ever touch it again but in case I do I'll try to remember
2026-07-10 13:53:42 <Arthurium> Added a note to the podman wiki page, that I had to re-log in for the UID/GID mapping to apply
2026-07-10 13:53:55 <prabu> Arthurium, thank you for your contributions to Alpine Linux wiki. They will greatly benefit future users.
2026-07-10 13:56:07 <Arthurium> Well no problem, I like Wiki stuff as it seems I can improve things even though my knowledge doesn't reach very far. If you ever see something I write that seems a little lacking on verifiviability, feel free to add notices about that
2026-07-10 20:49:28 <Arthurium> sddm behavior on a Plasma setup with setup-desktop is very inconsistent at the moment. Sometimes it doesn't start, sometimes it does. When it doesn't start, I check my usual workaround: QT_QPA_PLATFORM=Wayland in /etc/sddm.conf, and restarting elogind and sddm. Didn't help. Only after a second reboot it worked. I have an external display connected now, but I had the same behavior earlier today without.
2026-07-10 20:52:43 <Arthurium> It's a bit puzzling, because I try something else to fix it, like restarting elogind and sddm, and sometimes that works. First time that worked I thought it would be a consistent workaround, but perhaps the 2 workaroudns I've made have been coincidentally lining up with it working when it did.
2026-07-10 20:54:14 <Arthurium> For now I will setup labwc as a temporary solution. It's blazing fast anyway and I'm pretty comfortable with it but I haven't figured out yet how to get sound working on there.
2026-07-10 21:56:43 <kento2_> hey chat! is it possible to specify a local archive in the source-field of an APKBUILD?
2026-07-10 21:57:47 <kento2_> id like to maintain some modified packages using apk, so that i have the source code at /usr/apk/myfork along with a packagefike