2026-06-01 00:50:45 <WhyNotHugo> Can somebody provide some insight regarding  update_config_sub on #18225
2026-06-01 01:00:55 <mio> el[m]1: not sure about the cause, sorry
2026-06-01 01:09:11 <infinitywisdom[m]> Ok so it is definitely the GNOME section of the setup-desktop script that is broken
2026-06-01 01:09:40 <infinitywisdom[m]> I just did a manual installation of gnome and it worked.
2026-06-01 01:10:07 <infinitywisdom[m]> Although I will say that there is a lot of gnome packages missing doing it manually and some of them are not even loading right.
2026-06-01 01:10:20 <infinitywisdom[m]> Like gnome terminal for instance. that won't even start.
2026-06-01 01:16:49 <infinitywisdom[m]> Does anyone know who is in charge of gnome for alpine linux, or the setup-desktop script?
2026-06-01 01:19:03 <longnoserob[m]> team/gnome
2026-06-01 01:19:35 <longnoserob[m]> best is probably if you document your findings in an aports issue
2026-06-01 01:21:15 <infinitywisdom[m]> What is the best way to get in touch with them in real time?
2026-06-01 01:23:26 <longnoserob[m]> maybe check the alpine-devel channel?
2026-06-01 01:23:39 <infinitywisdom[m]> Is thatr bridged to matrix too?
2026-06-01 01:23:54 <infinitywisdom[m]> s/thatr/that/
2026-06-01 01:23:57 <longnoserob[m]> guess so
2026-06-01 01:25:53 <infinitywisdom[m]> longnoserob[m]: Found  it
2026-06-01 01:25:54 <infinitywisdom[m]> thank you
2026-06-01 01:32:48 <longnoserob[m]> good
2026-06-01 06:09:14 <ptrckd> Hey folks. I'm noticing that my window manager gets a dbus session bus under /tmp due the dbus session.conf file (and being launched via dbus-run-session) and another dbus session bus gets created under /run/user due to the openrc user config file. It's causing some issues due to programs getting different addresses depending on how they are launched. Have I set this up wrong?
2026-06-01 06:21:17 <realroot[m]> I do not use dbus-run-session but tinydm
2026-06-01 06:42:28 <ptrckd> I'm wondering if dbus-run-session is redundant with the user service creating one. It is a well known path so maybe I can have greetd provide it to the wm. 
2026-06-01 06:45:11 <realroot[m]> i think so
2026-06-01 06:49:48 <realroot[m]> with the user service is redundant
2026-06-01 08:17:19 <grawity> ptrckd: that's basically how it went in systemd – the user bus was originally for background stuff, but eventually having two became an issue, and the user bus became used as the one and only session bus (with the "one GUI session per UID" limit arising from that)
2026-06-01 08:18:25 <grawity> I don't know how far openrc implements user services, but either way, once you have a user-wide bus, it's *probably* better to use that for everything, and dbus-run-session then becomes redundant
2026-06-01 10:04:18 <Sertonix[m]> WhyNotHugo: Maybe a missing cd thing. Will take a look later
2026-06-01 10:07:34 <ptrckd> Okay, that worked. I used a wrapper script similar to what greetd says to do for sway and sourced the address from the openrc dbus user config.
2026-06-01 10:17:47 <ptrckd> One other thing I stumbled on when cleaning up my neovim config... The neovim pkg symlinks the tree-sitter parsers from /usr/lib/tree-sitter such that neovim can find it but it doesn't do something similar for the tree-sitter queries in /usr/share/tree-sitter. Is that intentional? If not I'd be interested in trying to submit a fix if someone could give me some idea of what I'd need to do.
2026-06-01 10:18:45 <Sertonix[m]> There is an open issue describing the issues for that
2026-06-01 10:29:47 <ptrckd> Thanks! I see #18217. 
2026-06-01 11:18:21 <runxiyu_> uhhh
2026-06-01 11:18:24 <runxiyu_> im outside right now
2026-06-01 11:18:31 <runxiyu_> but if it hasnt been merged yeti 
2026-06-01 11:18:43 <runxiyu_> please dont merge the arahli version bump
2026-06-01 11:18:56 <runxiyu_> theres an issue i spotted that ill need to fix when i get back home
2026-06-01 11:18:59 <runxiyu_> thanks!
2026-06-01 11:19:20 <runxiyu_> if it has been merged its fine too, just might be a hassle for reviewers to review another ME
2026-06-01 11:19:22 <runxiyu_> mr*
2026-06-01 11:44:13 <kopernic> gday, question: when is 2.24 planned?
2026-06-01 11:45:39 <ikke> kopernic: ASAP. We're blocked by the riscv64 builder, which hasn't finished building all packages yet
2026-06-01 11:46:52 <runxiyu_> 2.24?
2026-06-01 11:47:19 <runxiyu_> Oh, Alpine 3.24?
2026-06-01 11:47:43 <kopernic> (typo, yes, 3.24)
2026-06-01 11:56:48 <penguinz_rule[m]> i may have asked this before but is .24 moving to kernel 7.0
2026-06-01 11:57:12 <runxiyu_> IIRC 7.0 is not LTS?
2026-06-01 11:59:35 <penguinz_rule[m]> i thoufht there might have been an 7.x LTS, but i am apprehensive due to AI code ingestion
2026-06-01 12:01:33 <runxiyu_> I mean, after all Alpine uses Linux as the kernel
2026-06-01 12:01:43 <runxiyu_> If you get my point
2026-06-01 12:05:27 <cve> hey
2026-06-01 12:05:43 <cve> has anyone experience in launching an alpine install iso/image from kexec?
2026-06-01 12:06:20 <cve> I want to install alpine on my vserver using this, as I cannot upload custom ISOs there, similar to how one can do this with OpenBSD's bsd.rd
2026-06-01 12:06:26 <ewo> cve: I don't but I know zfsbootmenu does it
2026-06-01 12:06:36 <ewo> well, not images but it uses kexec
2026-06-01 12:07:59 <ewo> https://wiki.alpinelinux.org/wiki/Kexec
2026-06-01 12:08:02 <ewo> might be of use
2026-06-01 12:12:03 <cve> fwiw, the vserver is currently on NixoS
2026-06-01 12:25:32 <ewo> cve: hope someone else can help you, I'm not too clued up on it
2026-06-01 13:07:58 <durrendal> cve: not kexec, but I have used extlinux to overwrite the /boot partition on a remote Debian VPS then boot from the virt iso using that. Similar processish
2026-06-01 13:08:51 <durrendal> https://wiki.alpinelinux.org/wiki/Replacing_non-Alpine_Linux_with_Alpine_remotely <- essentially what's outlined here
2026-06-01 13:29:50 <cve> durrendal: is it possible to wipe the boot partition during the process? like does it load the image fully into memory first?
2026-06-01 13:30:51 <durrendal> note that it's a sample size of like 2, but at least in my experience I was able to unmount my /boot partition and wipe/reinstall it as part of the process
2026-06-01 13:31:21 <durrendal> I'd recommend practicing on a VM if you can recreate a facsimile of your target environment
2026-06-01 13:33:50 <yeti> """11:18:31 runxiyu_ │ but if it hasnt been merged yeti"""  <<<  and I really do not expect to get merged.  far too buggy!  ;-P
2026-06-01 15:35:38 <frag> does busybox tar invcrementaly update, eg if i backup 250GB dir to fil.tar every month?
2026-06-01 16:04:37 <el[m]1> i'm on a postmarketOS system (hence feel free to send me away if this is too off-topic) and it seems like there's either an install user error on my behalf or a packaging issue with the out of tree drivers, and "akms build all" just hangs with no CPU load. is there some akms expert here who could help me extract a better error message so i can figure out if it's my fault or what might be going on? sorry again if this is the wrong room or
2026-06-01 16:04:37 <el[m]1> not a useful thing to try
2026-06-01 17:31:56 <personman> hii
2026-06-01 17:32:18 <personman> hii dude is anyone here
2026-06-01 17:33:38 <personman> hello
2026-06-01 17:41:44 <el[m]1> 🫣
2026-06-01 18:01:58 <frag> dude, wheres my chan?
2026-06-01 18:06:43 <f_> el[m]1: postmarketOS doesn't really support akms
2026-06-01 18:12:43 <jvvv> el[m]1: perhaps try`akms build -k all`?
2026-06-01 18:13:32 <jvvv> or maybe `akms build -k all all`
2026-06-01 18:13:45 <jvvv> been a while since I used akms
2026-06-01 18:15:10 <el[m]1> f_: i think this device was set up to use it, it uses the raspberry pi 5 alpine kernel. so it's not a pmOS kernel
2026-06-01 18:17:42 <el[m]1> jvvv: i tried this now: `# akms build --kernel all all` but sadly it just hangs as well. no output, no cpu usage, no internet usage (i checked with nethogs)
2026-06-01 18:19:02 <jvvv> el[m]1: just to be sure, you did that as root or with doas/sudo/su ?
2026-06-01 18:19:41 <jvvv> ok, i now see the '# ', so guessing yes
2026-06-01 18:21:05 <el[m]1> yeah it's running as root
2026-06-01 18:21:45 <el[m]1> when i check ps aux, it kind of looks like it's just a shell doing nothing but perhaps i grepped the list poorly
2026-06-01 18:22:05 <jvvv> I wonder if namespace support is built into the kernel
2026-06-01 18:27:47 <el[m]1> okay so it seems like `apk fix akms` actually finally said something: https://github.com/jirutka/akms/issues/22 and it says the AKMBUILD file is somehow broken. so i suggested here that the error message is improved
2026-06-01 18:27:55 <el[m]1> jvvv: is there some way i could check?
2026-06-01 18:31:16 <jvvv> el[m]1: you could `ls /proc/self/ns`
2026-06-01 18:31:44 <el[m]1> # cat /boot/config-6.12.85-0-rpi  | grep USER_NS
2026-06-01 18:31:44 <el[m]1> CONFIG_USER_NS=y
2026-06-01 18:31:44 <el[m]1> # ls /proc/self/ns
2026-06-01 18:31:44 <el[m]1> cgroup             net                time               uts
2026-06-01 18:31:44 <el[m]1> ipc                pid                time_for_children
2026-06-01 18:31:45 <el[m]1> mnt                pid_for_children   user
2026-06-01 18:32:36 <jvvv> yeah, they are all there
2026-06-01 18:33:05 <jvvv> another think to double check is that overlayfs is available
2026-06-01 18:34:18 <el[m]1> 
ACTION sent a code block: https://matrix.org/oftc/media/v1/media/download/AWi9FltjOPsGpIxO6Lp52PTrX-W3v2bmmgSbM_Gi3Jb70T2py_VMJ9CveTCb9eI8XevlhdwQsIaZAGLkUXw-tjRCeezJAg7AAG1hdHJpeC5vcmcvQ3VsdFBTeUN0VUxGRERXQ1NjVlhCanpu

2026-06-01 18:34:21 <el[m]1> looks like it is
2026-06-01 18:35:12 <jvvv> lsmod | grep overlay ; ls /lib/modules/$(uname -r)/kernel/fs/overlayfs
2026-06-01 18:35:46 <jvvv> sorry, links like that are painful for me to try to reconstruct from copy/paste in irc
2026-06-01 18:39:17 <el[m]1> #  ls /lib/modules/$(uname -r)/kernel/fs/overlayfs
2026-06-01 18:39:17 <el[m]1> overlay.ko.xz
2026-06-01 18:39:33 <el[m]1> it looks like it's loaded. i didn't need to load it so i assume it was loaded from the start
2026-06-01 18:40:11 <jvvv> yeah, that shouldn't be it. just trying to eliminate low hanging fruit
2026-06-01 18:40:34 <el[m]1> thank you, i appreciate it!
2026-06-01 18:42:26 <jvvv> I am looking at the scripts: /usr/sbin/akms and /usr/libexec/akms/akms-runas and /usr/libexec/akms/akms-build to see if there is a way turn on more verbosity
2026-06-01 18:44:05 <jvvv> akms has the --verbose (or -v) option
2026-06-01 18:45:28 <jvvv> that would be a start to try to see where it is hanging
2026-06-01 18:47:35 <el[m]1> ```
2026-06-01 18:47:35 <el[m]1> # akms build -v all
2026-06-01 18:47:35 <el[m]1> apparently it hangs immediately at the start, no output 😅
2026-06-01 18:47:35 <el[m]1> ```
2026-06-01 18:56:16 <jvvv> el[m]1: I think this may be an issue with akms. I just installed a -src pkg and akms hangs like you describe. I actually need this working in the near future so will be looking at this.
2026-06-01 18:56:45 <el[m]1> oh you mean it's just generally broken on alpine edge? fascinating
2026-06-01 18:56:55 <el[m]1> well i'm glad i reported something useful then
2026-06-01 18:57:26 <el[m]1> if you want me to test out some experimental variant of it, ping me any time. i have good backups
2026-06-01 18:57:37 <jvvv> paging my ps output, it looks like there is something funky going on.
2026-06-01 18:58:09 <jvvv> yeah, cool, that would be good. I'll let you know if/when I narrow down the issue.
2026-06-01 18:59:00 <el[m]1> so if you want something tested where it may render the machine unbootable or break the entire install beyond repair, i'm the right person to ask
2026-06-01 19:00:02 <jvvv> I don't think we will have to worry about breaking anything, but backups and recovery methods are always good
2026-06-01 19:35:42 <jvvv> el[m]1: see https://github.com/jirutka/akms/pull/21 ... that should fix it
2026-06-01 19:38:00 <jvvv> el[m]1: I will put in an MR for this shortly
2026-06-01 19:42:46 <el[m]1> jvvv: neat! i think pmOSes mrtest can directly test out alpine merge requests, so i should be able to easily try it out that way
2026-06-01 19:52:58 <f_> mrtest in general is available on alpine, it's not a pmOS-only thing :)
2026-06-01 19:53:20 <ikke> f_: I haven't gotten it to work on alpine (probably due to the child pipelines)
2026-06-01 19:53:59 <f_> it seems working fine for me if I add `-a`
2026-06-01 19:54:25 <ikke> Yeah, I did add -a
2026-06-01 19:55:52 <el[m]1> f_: oh oops i didnt know, lol
2026-06-01 19:57:59 <el[m]1> ikke: i guess we'll see in a few minutes if i can get it to work on pmOS with alpine packages or if it's just generally broken with that 😮
2026-06-01 20:14:41 <jvvv> el[m]1: see !103348
2026-06-01 20:52:37 <el[m]1> jvvv: ok it seems like mrtest cant do it:
2026-06-01 20:52:37 <el[m]1> Download https://gitlab.alpinelinux.org/api/v4/projects/alpine%2Faports/merge_requests/441837
2026-06-01 20:52:37 <el[m]1> # mrtest add -a 441837
2026-06-01 20:53:00 <el[m]1> perhaps the best way to test would be for me to apply the fix in the shell script source code manually
2026-06-01 20:53:48 <jvvv> el[m]1: That was what I did initially to test the fix.
2026-06-01 20:55:27 <el[m]1> can confirm it builds now. fix works for me. it's no longer stuck
2026-06-01 20:57:07 <jvvv> thank you for confirming
2026-06-01 20:57:33 <el[m]1> the build finishes successfully! all the modules built! thank you so much for finding this fix
2026-06-01 20:58:03 <jvvv> you are very welcome
2026-06-01 21:06:42 <jvvv> btw mrtest worked fine for me: mrtest add -a 103348
2026-06-01 21:07:46 <jvvv> the number you used was the pipeline number i think. i used the MR number, then i just had to answer a bunch of questions
2026-06-01 21:09:33 <jvvv> maybe the pipeline would have worked also, but the one that you used 441837 failed becuase i had forgotten to fix up the checksums after adding the Patch-Source to the patch
2026-06-01 21:13:21 <jvvv> no, using the pipeline number failed also
2026-06-01 22:14:45 <detly> I'm seeing that backreferences don't work (or maybe have different syntax?) in Alpine's Busybox vs. Busybox on something like Ubuntu or Debian (I tried Alpine 3.2x so far). I'm definitely familiar with various RE features being disabled to save space or limit dependencies on various systems, but does anyone know (a) where I can find alpine-specific docs for the utilities it ships with, and (b) is this a disabled feature or does it have a 
2026-06-01 22:14:45 <detly> different syntax?
2026-06-01 22:15:01 <detly> An example command is: echo 'A A' | sed -E 's!^(\w+) (\1)!matched \1 \1!g'
2026-06-01 22:15:27 <detly> (I meant to say, "backreferences in sed using extended regular expressions", sorry.)
2026-06-01 22:19:47 <quinq> Where is the busybox documentation that explains that this extensions is supposed to work, and how?
2026-06-01 22:20:26 <quinq> Also busybox sed non-conformant option to indicate it has to parse an ERE is -r
2026-06-01 22:23:37 <quinq> Ah sorry, they have updated their inline documentation, but not their online one
2026-06-01 22:23:49 <quinq> “-r,-E   Use extended regex syntax”
2026-06-01 22:30:37 <quinq> They gitweb is down too https://git.busybox.net/busybox/log/?h=1_38_stable
2026-06-01 22:40:21 <detly> quinq: I'm using the -E flag there. But I honestly don't know where the docs would be. It's easy to find man pages for generic utils, but I don't know where Alpine's are without installing them on a running distro every time.
2026-06-01 23:02:19 <detly> quinq: I generally go off this comment in the Busybox manual: "The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts." So running that command with GNU sed does the replacement.
2026-06-02 00:39:51 <detly> (It actually differs between eg. the busybox:1.37.0 docker image, and alpine:3.23 which uses busybox 1.37.0. So even the busybox docs wouldn't really help me here, I'd need the documentation for alpine's build options to busybox, or what features it uses.)
2026-06-02 01:05:51 <detly> Turns out backreferences in sed work just fine *without* the -E (and adjustments for syntax). So there's no feature disabled, it's just... different. I can't find anything in the APKBUILD that would account for that, either. Wild.
2026-06-02 03:42:35 <quinq> they' tripin'
2026-06-02 05:15:27 <Sertonix[m]> My first guess would be to check what behaviour is expected by POSIX
2026-06-02 06:41:42 <detly> Sertonix[m]: I will groan inwardly and check the standard then. But what caught me out was that there's no change in "behaviour" as in, backreferences still work. It's only a change in syntax. And it works in the same version of busybox in busybox's docker image.
2026-06-02 06:42:04 <detly> I can understand behavioural changes from compilation options eg. disable backreferences; but I don't get why the same syntax would be accepted as valid but do something different.
2026-06-02 06:46:51 <detly> POSIX says the syntax should be accepted as an ERE: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap09.html#tag_09_05_03
2026-06-02 06:49:40 <detly> Er, okay, it also says that backreferences are a BRE-only thing: https://pubs.opengroup.org/onlinepubs/9799919799/
2026-06-02 06:50:36 <detly> So... does Alpine's implementation of Busybox patch this out of the upstream version? Where is that introduced?
2026-06-02 06:57:16 <detly> Rationale is here, too: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap09.html#tag_21_09_04 ("rejected by the standard developers as likely to decrease consensus").
2026-06-02 06:57:49 <detly> I really wish there was some kind of "really truly POSIX-only" reference implementation of the standard that I could test against, instead of having to memorise the entire thing.
2026-06-02 11:55:44 <Sertonix[m]> I wonder if this could be a difference in glibc.
2026-06-02 23:46:20 <ptrc> anyone using Firefox on 3.23, i'd appreciate if you could upgrade (151.0.3 should be available any moment now on the mirrors) and test whether everything still works correctly
2026-06-03 01:20:39 <Saijin_Naib[m]> prabu do you know if switching to limine from grub is documented, or have you done that yourself yet?
2026-06-03 02:31:58 <WhyNotHugo> I realise there's no wiki entry for limine, should have made one when I set it up long ago :(
2026-06-03 04:56:30 <Saijin_Naib[m]> Ah, leshit
2026-06-03 04:56:50 <Saijin_Naib[m]> I do not wish to footgun/brick more family computers testing how to transition from grub to limine
2026-06-03 04:58:23 <ikke> bricking implies broken without feasibly recovery
2026-06-03 04:58:34 <ikke> feasible*
2026-06-03 04:59:08 <Saijin_Naib[m]> Soft-brick?
2026-06-03 04:59:15 <Saijin_Naib[m]> Trash?
2026-06-03 05:07:30 <ikke> Break boot?
2026-06-03 05:18:14 <bloink> !user
2026-06-03 05:19:19 <longnoserob[m]> user?
2026-06-03 05:49:39 <prabu> Saijin_Naib, it was not me who referred to liminine. i use refind. i did test limine, but it doesn't support my configuration. i place kernels/initrams inside /boot folder of each of my btrfs subvolumes(@,@rescue etc) and my efi partition is mounted at /boot/efi 
2026-06-03 05:54:34 <prabu> ptrc, i'm using firefox on 3.23 and the upgrade to 151.0.3 (64-bit) went smoothly. I don't see any regressions. Thanks for maintaining this.
2026-06-03 05:58:13 <Saijin_Naib[m]> prabu thanks for confirming, and WhyNotHugo, same for you. I guess I'll dig and try when I have some time and a bootable recovery drive haha
2026-06-03 07:46:03 <habs> good day:  alpine 64bit 3.23.4   curl 8.19.0 (x86_64-alpine-linux-musl) libcurl/8.19.0 OpenSSL/3.5.6 zlib/1.3.2 brotli/1.2.0 zstd/1.5.7 c-ares/1.34.6 libidn2/2.3.8 libpsl/0.21.5 nghttp2/1.69.0      no firewall settings (everything open)  trying to curl to sycn.afraid.org  is not working for us here, is this a c-ares issue we read about please or something else ?
2026-06-03 07:50:19 <habs> sorry sync.afraid.org  - which curl resolves to ip 69.42.215.252  and then just hangs:  curl -v -4 "http://sync.afraid.org/u/mytokenhere/address?u=anon&p=anon&d=anon.anon"   - works fine on slackware if that helps
2026-06-03 07:51:17 <habs> mytokenhere  - is whre a real token would go
2026-06-03 08:54:06 <habs> is anyone home that might be able to help my earlier posted question ?  thank you   
2026-06-03 10:05:04 <comk> habs have patience, people sleeping and stuff
2026-06-03 10:42:19 <realroot[m]> mozangle won't compile when building servo-fetch
2026-06-03 10:42:47 <realroot[m]> Can i fix it? https://paste.trom.tf/ketikukoji.sql
2026-06-03 11:32:13 <f_> habs: all I can guess is network issues
2026-06-03 11:41:27 <habs> f:  no not network issues ... all other comms is fine, just via curl as described .... gnu curl is fine.  any way dont worry ... apparently im too impatient so i will go elsewhere.   peace and best wishes to all (sincerely)
2026-06-03 12:09:13 <jnn> "gnu curl"... wget?
2026-06-03 17:27:50 <shadow> we may never know.
2026-06-03 22:38:44 <y1nz> Hello all! I have a thing I'm stuck on. I'm trying to make a daily-driveable text-only system using linux
2026-06-03 22:39:56 <noodle> i think you'll miss utf8
2026-06-03 22:40:08 <y1nz> Everything is going great, but I can't for the life of me figure out how to change the cursor from the underline (ideally to a full block, which is much more visibile). The console_codes man page had lots of helpful info about palette stuff, but doesn't mention cursor appearance at all. I'm willing to recompile the whole OS over this btw
2026-06-03 22:40:29 <noodle> oh ig you're in insert mode
2026-06-03 22:40:50 <noodle> nvm you just wanna customize it
2026-06-03 22:41:42 <y1nz> noodle: yeah I always want block cursor I think. Also I haven't missed utf8 so far, what would that be like emojis ig?
2026-06-03 22:42:10 <noodle> yeah and other langs if you have to deal with em
2026-06-03 22:43:27 <y1nz> huh. That's kind of surprising for some reason
2026-06-03 22:47:38 <noodle> i mean ascii stands for american standard code for information exchange :b first 127 codepoints do english and the remaining 127 in a byte can be packed with non-standard symbols like accented characters for support for some european languages
2026-06-03 22:47:53 <noodle> but that's all, typically you'd swap charsets if you want more iirc
2026-06-03 22:48:13 <noodle> s/exchange/interchange/
2026-06-03 22:50:22 <y1nz> yeah, that explains why some of the system fonts have greek or cyrillic
2026-06-03 22:50:49 <y1nz> but smth like japanese or arabic just Can't fit in that encoding ig
2026-06-03 22:51:21 <noodle> yeah
2026-06-03 22:52:06 <noodle> i mean arabic has 28 characters, i bet representing all the ligatures would take lotas codepoints tho. idk. never tried it
2026-06-03 22:52:12 <Nivex> Even in western languages, the first time you need to talk about Mötley Crüe you're in trouble :P 
2026-06-03 22:52:42 <y1nz> hm, your umlauts are showing up fine for me!
2026-06-03 22:52:51 <Nivex> 👍
2026-06-03 22:53:02 <y1nz> I think that sent as a tofu, what's it supposed to be?
2026-06-03 22:53:11 <Nivex> thumbs up emoji
2026-06-03 22:53:51 <ThatGingerGuy> Hello!
2026-06-03 22:53:51 <y1nz> ah. Yeah that must be what tofus look like on here haha
2026-06-03 22:56:20 <ThatGingerGuy> Anyone have Samba server set up on their Alpine server?  I'm having some trouble connecting from my Gentoo box and I'm 99% sure it's a server side issue.
2026-06-03 22:56:57 <Nivex> What makes you say that?
2026-06-03 22:58:02 <ThatGingerGuy> It's always an "NT_STATUS_BAD_NETWORK_NAME" error message
2026-06-03 22:58:25 <noodle> y1nz: i looked up the sequence for getting a blinking bloc at https://www.invisible-island.net/xterm/ctlseqs/ctlseqs.html and it don't work in my alpine tty, i guess TERM=linux is not vt520-capable?
2026-06-03 22:58:47 <noodle> should be echo -ne '\e[5 q'
2026-06-03 22:58:56 <noodle> sorry, 1
2026-06-03 23:00:42 <ThatGingerGuy> This is the result from "testparm -s"# Global parameters
2026-06-03 23:00:42 <ThatGingerGuy> [global]
2026-06-03 23:00:42 <ThatGingerGuy> 	dos charset = cp866
2026-06-03 23:00:42 <ThatGingerGuy> 	allow insecure wide links = Yes
2026-06-03 23:00:42 <ThatGingerGuy> 	idmap config * : backend = tdb
2026-06-03 23:00:42 <ThatGingerGuy> 	force user = <username>
2026-06-03 23:00:44 <ThatGingerGuy> [shared]
2026-06-03 23:00:46 <ThatGingerGuy> 	path = /media/storage
2026-06-03 23:00:48 <ThatGingerGuy> 	read only = No
2026-06-03 23:00:50 <ThatGingerGuy> 	wide links = Yes
2026-06-03 23:02:20 <y1nz> noodle: yeah, I had found the same thing. Didn't work, which makes sense given it's not on the console_codes man page
2026-06-03 23:02:50 <noodle> i guess
2026-06-03 23:04:06 <noodle> o found it
2026-06-03 23:04:29 <noodle> y1nz: from https://www.kernel.org/doc/html/latest/admin-guide/vga-softcursor.html
2026-06-03 23:05:01 <noodle> weird but seems kernel console has it's own escape sequences for setting cursor shape
2026-06-03 23:08:31 <y1nz> I had also found that, and it also didn't work :(
2026-06-03 23:09:36 <noodle> weird. it worked on my vm
2026-06-03 23:09:53 <noodle> echo -e '\033[?6c'
2026-06-03 23:10:11 <y1nz> yeah, nothing!
2026-06-03 23:10:23 <noodle> wild. maybe reset it first?
2026-06-03 23:10:28 <y1nz> reset it?
2026-06-03 23:10:53 <noodle> ya like, i remember there being a sequence/command to reset a terminal to a default good state
2026-06-03 23:10:57 <y1nz> I mean I'm currently on the machine in question, also running mtm (to have multiple vts open)
2026-06-03 23:11:17 <noodle> oh. idk wats that but try it first on a plain tty
2026-06-03 23:11:46 <noodle> like i have the one i boot into before i start wayland
2026-06-03 23:11:47 <y1nz> here I have another machine to try on, just to sanity-check myself haha
2026-06-03 23:11:56 <noodle> nice
2026-06-03 23:11:57 <y1nz> I also have this one tricked out with lightmode colors 8)
2026-06-03 23:12:05 <noodle> dam
2026-06-03 23:12:07 <y1nz> so testing without that is a good idea
2026-06-03 23:12:09 <y1nz> too
2026-06-03 23:12:22 <noodle> plan9 already comes with light mode by default :b
2026-06-03 23:12:27 <noodle> mhm remove all customizations ig
2026-06-03 23:12:41 <y1nz> WAIT WTF it worked on my other machine??
2026-06-03 23:12:44 <noodle> to match my state. i just got a default uncustomized terminal
2026-06-03 23:12:46 <noodle> oh
2026-06-03 23:12:50 <noodle> nice :)
2026-06-03 23:12:57 <y1nz> uhh.. Hm.
2026-06-03 23:13:08 <noodle> gotta eliminate possible stuff interfering with it now
2026-06-03 23:13:13 <y1nz> Might leave and see if this works in a freshly logged-in version of this terminal
2026-06-03 23:13:20 <noodle> sounds good ya
2026-06-03 23:13:25 <y1nz> I bet it's my multiplexer hosing something up >.>
2026-06-03 23:13:33 <y1nz> see yall on the flip
2026-06-03 23:13:36 <noodle> gl
2026-06-03 23:17:02 <noodle> but
2026-06-03 23:17:05 <noodle> wrong buffer sor
2026-06-03 23:19:59 <y1nz> noodle: OK im back. so it DOES work on this system, although weirdly then vim resets it to the stinky underline cursor. As does mtm.....
2026-06-03 23:20:19 <noodle> y1nz: sad
2026-06-03 23:20:48 <noodle> i think it's just too stupid to restore that bit of state when exiting? idk
2026-06-03 23:21:14 <noodle> buut ya ig vim ppl would know
2026-06-03 23:21:25 <y1nz> nah, on entry! vim is the main place I want to have a more visible cursor haha
2026-06-03 23:21:33 <noodle> o ya, maybe it's dropping it?
2026-06-03 23:21:39 <y1nz> this is at least good progress though haha. <3
2026-06-03 23:21:53 <noodle> yea :)
2026-06-03 23:22:04 <y1nz> it seems like vi respects it, but vim does not
2026-06-03 23:22:05 <noodle> what about vi? (it's superior)
2026-06-03 23:22:07 <noodle> see?
2026-06-03 23:22:11 <noodle> that's why it's superior
2026-06-03 23:22:15 <y1nz> hmmmmmmmm you make a strong case....
2026-06-03 23:22:19 <noodle> :b
2026-06-03 23:22:24 <y1nz> I just really would miss the pretty colors :(
2026-06-03 23:22:44 <y1nz> and my nice colorcolumn at 80.......
2026-06-03 23:23:01 <noodle> i don't believe in line limits anymore
2026-06-03 23:23:10 <noodle> i just make code shor if it's too long
2026-06-03 23:23:16 <noodle> and ya syntax hilighting is hard to give up on
2026-06-03 23:23:21 <noodle> took me a while
2026-06-03 23:24:07 <y1nz> huh, I've heard similar from other people. Do you think it was worth the switch? Like did you get back to the same speed of comprehension as you had with colors?
2026-06-03 23:24:11 <noodle> alsois mtm like tmux?
2026-06-03 23:24:12 <noodle> wats it do
2026-06-03 23:24:19 <noodle> yeah
2026-06-03 23:24:34 <noodle> i mean i don't remember, been years, but i think i make more readable code now
2026-06-03 23:24:50 <y1nz> yes! mtm is Minimal Terminal Multiplexer, suckless-recommended, ~1000 lines of C. I'm actually sorta messing with editing it for my own preferences rn lol
2026-06-03 23:24:57 <noodle> without color cues you gotta focus more on good formatting / style
2026-06-03 23:25:08 <noodle> oh fair
2026-06-03 23:25:20 <y1nz> I already am extremely staunch about my formatting haha
2026-06-03 23:25:42 <y1nz> you know what, maybe this is the opportunity. Perhaps I will give vi a shake
2026-06-03 23:26:15 <noodle> yea. if you're already strict about formatting i think you won't miss syntax hilighting much
2026-06-03 23:26:27 <noodle> but, gotta admit, text does melt into eachother a bit, especially on irc
2026-06-03 23:27:22 <y1nz> yeah, I *really* like my colors in other places lol
2026-06-03 23:27:32 <noodle> mhm
2026-06-03 23:27:57 <y1nz> I wonder if I could get *some* colors into vi without having to deal with The Entirety of Vim...
2026-06-03 23:28:16 <noodle> not sure u can do that
2026-06-03 23:28:26 <y1nz> Like coloring paired brackets or keywords
2026-06-03 23:30:06 <y1nz> noodle: can u resend me that link you had before? to the documentation of the cursor mess
2026-06-03 23:30:25 <noodle> y1nz: the xterm one?
2026-06-03 23:30:36 <noodle> https://www.invisible-island.net/xterm/ctlseqs/ctlseqs.html
2026-06-03 23:30:36 <y1nz> the one with the 3 parameters, that ended up working
2026-06-03 23:30:39 <y1nz> ya that
2026-06-03 23:31:26 <noodle> o 3 parameters?
2026-06-03 23:32:06 <y1nz> ah no, the ohter
2026-06-03 23:32:34 <y1nz> that talked about the linux-term-specific control sequence, like ESC[?6c
2026-06-03 23:32:47 <noodle> o
2026-06-03 23:32:52 <noodle> it's in the backlog silly :3
2026-06-03 23:33:18 <noodle> https://www.kernel.org/doc/html/latest/admin-guide/vga-softcursor.html
2026-06-03 23:33:41 <y1nz> i dont have the backlog bc im stupie D:
2026-06-03 23:33:50 <noodle> aw :C
2026-06-03 23:34:24 <y1nz> do u just connect directly, or do u have a server do it somehow?
2026-06-03 23:34:28 <y1nz> like to save the backlogs
2026-06-03 23:35:03 <noodle> *hands them a "-s oftc" to add to their catgirl commandline*
2026-06-03 23:35:11 <noodle> oh
2026-06-03 23:35:33 <noodle> i thought u meant ur client doesn't save backlog when you quit/rejoin. i don't use a bouncer
2026-06-03 23:36:11 <noodle> also -l flag saves chat to disk in a format good for grepping
2026-06-03 23:36:23 <y1nz> wow yeah. It does have that option huh
2026-06-03 23:37:05 <y1nz> It should be illegal for a program to have more than like 5 command-line options >.>
2026-06-03 23:37:19 <noodle> lmao. catgirl can use a config file
2026-06-03 23:37:34 <y1nz> I also hate config files
2026-06-03 23:38:46 <noodle> u hate everything lol
2026-06-03 23:38:48 <noodle> twinz
2026-06-03 23:39:12 <y1nz> Yeah that's why I like alpine and suckless and stuff. Less things = less to hate
2026-06-03 23:39:19 <noodle> mhm
2026-06-03 23:39:39 <y1nz> I have the utopian dream to someday touch all of the code I regularly interact with
2026-06-03 23:40:27 <noodle> you hate commandline options? here's how i connect to just oftc "ircrc -t '#some,#channels' irc.oftc.net | tee -a /mnt/mq/irc /tmp/oftc"
2026-06-03 23:42:06 <noodle> also u can do it
2026-06-03 23:42:54 <noodle> i choose simple software for the same reason. i think it's good to run software you know you can study easily
2026-06-03 23:43:15 <y1nz> I had used ii and lchat originally, but it was too cumbersome. It's a tricky balance
2026-06-03 23:43:31 <noodle> ii has really cool concepts
2026-06-03 23:43:49 <y1nz> I'll def give ircrc a try. I'm mostly just intimidated bc I haven't gotten around to figuring out what tee does yet
2026-06-03 23:44:00 <noodle> separating the server connection from the UI is neat
2026-06-03 23:44:29 <noodle> and with a file ui. it's very unix-philosophy i think
2026-06-03 23:44:35 <noodle> oh
2026-06-03 23:44:39 <noodle> tee is just a T pipe
2026-06-03 23:44:57 <noodle> water goes in one end and comes out 2 ends instead of a regular pipe 
2026-06-03 23:45:36 <noodle> 2 or more, but that's the basic idea, the extra ends are the filenames you specify, otherwise it writes to stdout
2026-06-03 23:46:02 <y1nz> huh, what does the -a do?
2026-06-03 23:46:10 <noodle> o it appends instead of truncating the file
2026-06-03 23:46:13 <y1nz> ah
2026-06-03 23:47:18 <y1nz> when I used lchat, I found it pretty cumbersome to keep track of the state of things. That was *very* early on though, maybe I'll hack on it more later
2026-06-03 23:47:26 <y1nz> it's on my list lol
2026-06-03 23:47:36 <noodle> o yeah. keeping track of mentions was painful on it for me
2026-06-03 23:47:58 <noodle> you need like an extra window with mentions on it
2026-06-03 23:48:22 <noodle> but to pipe all dms/server/etc stuff to that window idk how to
2026-06-03 23:48:48 <y1nz> yeah lol, cumbersome
2026-06-03 23:49:11 <noodle> there should be like, both a master pipe for catching hilights, and readable files for reading individual buffers
2026-06-03 23:49:14 <noodle> but ya gl on it
2026-06-03 23:49:35 <noodle> i want to add ii's concepts to ircrc sometime
2026-06-03 23:49:37 <noodle> would be nice
2026-06-03 23:49:39 <y1nz> Tbh even something like just flattening the dir structure might have helped. Like channel1.nick-serv.in channel2.nick-serv.out etc all in one dir..
2026-06-03 23:50:02 <noodle> idk. i like the hierarchy
2026-06-03 23:50:35 <noodle>  makes it easier to find stuff without doing lotsa string comparison
2026-06-03 23:51:02 <y1nz> if it was all one dir, ls shows everything. Then you just grep whatever you're looking for
2026-06-03 23:51:15 <noodle> but youll have to ls | grep
2026-06-03 23:51:17 <noodle> which is bleh
2026-06-03 23:51:19 <y1nz> maybe that plus a mechanism for tracking mentions/updates...
2026-06-03 23:51:26 <noodle> no need i think
2026-06-03 23:51:34 <noodle> master output can be grepped/filtered
2026-06-03 23:51:47 <y1nz> whys that bleh? I love my ls | grep :C
2026-06-03 23:52:01 <noodle> i wouldn't run that in a loop
2026-06-03 23:52:02 <noodle> or somth
2026-06-03 23:52:09 <noodle> only wait
2026-06-03 23:52:12 <noodle> wait*
2026-06-03 23:52:16 <y1nz> wait**
2026-06-03 23:52:21 <y1nz> (waiting)
2026-06-03 23:52:23 <noodle> i forgor what we're try do
2026-06-03 23:52:23 <noodle> hm
2026-06-03 23:52:59 <noodle> ya ig it might be fine bc i don't think you'd have to search for available buffers, the user will specify them themselves
2026-06-03 23:53:14 <noodle> but, still, representing a namespace via dirs/files is more natural imo
2026-06-03 23:54:25 <y1nz> I often find that replacing '/'s in directory structures with '.'s is a pretty one-to-one substitution
2026-06-03 23:54:50 <y1nz> like semantically i mean lol
2026-06-03 23:56:50 <noodle> but
2026-06-03 23:57:13 <noodle> time to have all your files under / with .'s  :3
2026-06-03 23:58:25 <y1nz> ya
2026-06-04 00:00:08 <Sertonix[m]> y1nz: I think if you want to reliably change something like the (default) cursor format you would need a program that processes all output. Could probably be done with a custom patch for mtm.
2026-06-04 00:03:38 <y1nz> Sertonix: yeah, I think that's the move here
2026-06-04 00:06:34 <y1nz> Anyway, i must go, thanks all for the helps <3
2026-06-04 05:23:50 <rnkn> what is alpine's plan once gitlab is 100% enshittified?
2026-06-04 05:27:59 <quinq> 100% sounds like a very high bar
2026-06-04 05:30:51 <runxiyu> self-hosted forgejo sounds fine?
2026-06-04 05:30:56 <rnkn> quinq: that sounds like a challenge
2026-06-04 05:31:15 <quinq> or the opposite ^^
2026-06-04 05:31:26 <runxiyu> Though yeah I'd like to know what Alpine wants from a forge
2026-06-04 05:31:40 <rnkn> runxiyu: I quite like forgejo but it's not me who needs to deal with it every day
2026-06-04 05:31:45 <rnkn> I feel for the devs
2026-06-04 05:31:53 <runxiyu> Makes sense
2026-06-04 05:31:54 <runxiyu> I mean
2026-06-04 05:32:04 <runxiyu> GitLab is also much heavier on hardware and other resources, IIRC
2026-06-04 05:32:28 <runxiyu> Though, of course there are a lot of things that could be improved with Forgejo etc such as better delta reuse when serving packs...
2026-06-04 05:32:31 <ikke> Good and flexible CI important
2026-06-04 05:32:32 <runxiyu> well, I guess that's more of Git's job
2026-06-04 05:33:16 <ikke> One thing I miss as well in forgejo is nested projects
2026-06-04 05:33:24 <ikke> (namespaces)
2026-06-04 05:34:14 <runxiyu> good point yeah
2026-06-04 05:34:25 <runxiyu> i mean, among the large ones, basically only gitlab does it properly iirc?
2026-06-04 05:34:29 <runxiyu> (cgit doesn't count)
2026-06-04 05:34:36 <ikke> That I'm aware of
2026-06-04 05:34:43 <runxiyu> yeah
2026-06-04 05:35:36 <runxiyu> I'm not sure, and I'd prefer a dev to correct me or something, but from what I can see it appears that Alpine doesn't need flexible/complex code review workflows for most cases?
2026-06-04 05:36:21 <rnkn> ikke: are namespaces different to organisations?
2026-06-04 05:36:31 <ikke> rnkn: gitlab can nest groups
2026-06-04 05:36:47 <ikke> afaik, you only have flat organizations in forgejo
2026-06-04 05:36:54 <ikke> ie, all repos live in level 2
2026-06-04 05:37:38 <runxiyu> if anyone has okular installed, can you try to open a PDF, highlight something with the yellow highlighter, click in the highlight to open the popup, type in some text, and save the PDF?
2026-06-04 05:37:43 <runxiyu> seems to reliably crash okular for me
2026-06-04 05:37:50 <runxiyu> currently rebuilding with -dbg
2026-06-04 05:38:06 <ikke> runxiyu: I recall similar issues
2026-06-04 05:38:15 <ikke> was a while ago already
2026-06-04 05:39:01 <runxiyu> https://u.runxiyu.org/ce107f241562b91137e531099890fe2175305b4d140261e7d797e3c862527a22-screenshot_2026-06-04_05-38-35.png
2026-06-04 05:39:13 <runxiyu> 500 on gitlab when accessing my aports fork
2026-06-04 05:39:34 <ikke> Can you copy that request id?
2026-06-04 05:39:46 <runxiyu> 01KT8HZM6EZ8BCG0JJR5DJRQV7
2026-06-04 05:39:48 <runxiyu> thanks!
2026-06-04 05:42:04 <ikke> gitaly timeout
2026-06-04 05:43:02 <runxiyu> hmm
2026-06-04 05:44:18 <ikke> Seems to work (now) for me
2026-06-04 05:46:46 <runxiyu> gitlab or okular?
2026-06-04 05:46:51 <runxiyu> well gitlab works for me too
2026-06-04 05:46:56 <ikke> gitlab
2026-06-04 05:48:38 <ikke> runxiyu: I can type in the popup
2026-06-04 05:49:02 <runxiyu> save it
2026-06-04 05:49:08 <runxiyu> save the file*
2026-06-04 05:49:41 <runxiyu> something wrong with saveAs and kio causing gcc's stack clash detection to trigger...
2026-06-04 05:49:48 <ikke> right, segfault
2026-06-04 05:50:02 <ikke> maybe related to https://gitlab.alpinelinux.org/alpine/aports/-/work_items/16690?
2026-06-04 05:50:32 <runxiyu> likely so
2026-06-04 05:53:54 <runxiyu> alright, i think i know the issue now, writing up a patch
2026-06-04 05:54:29 <runxiyu> ikke: apparently kio puts a 512kib object on the stack, and musl has small stacks
2026-06-04 05:55:31 <ikke> ah yes, that would explain
2026-06-04 05:58:06 <runxiyu> 4-line patch
2026-06-04 05:58:07 <runxiyu> testing
2026-06-04 05:59:26 <runxiyu> [131/925] Building CXX object src/core/CMakeFiles/KF6KIOCore.dir/askuseractioninterface.cpp.o
2026-06-04 05:59:28 <runxiyu> poor laptop
2026-06-04 06:03:24 <noodle> rip
2026-06-04 07:16:26 <runxiyu> ikke: my fix appears to work. opening an MR soon
2026-06-04 07:17:52 <ikke> Cool, thanks
2026-06-04 07:18:50 <runxiyu> ikke: should i bump the rel for okular in the same commit?
2026-06-04 07:21:04 <ikke> Yes
2026-06-04 07:21:36 <runxiyu> commitstyle seems to want one commit to patch kio, and another commit to bump okular's pkgrel, if im reading it right
2026-06-04 07:21:36 <runxiyu> ikke: not really sure how to write the commit message
2026-06-04 07:22:11 <ikke> oh, I misunderstood
2026-06-04 07:22:20 <ikke> one commit per package, yes
2026-06-04 07:22:27 <runxiyu> ah
2026-06-04 07:23:12 <ikke> Does okular need to be rebuilt for this?
2026-06-04 07:24:04 <runxiyu> actually, good point. im not sure
2026-06-04 07:24:43 <ikke> if ABI stays the same, I assume not?
2026-06-04 07:24:54 <runxiyu> yeah, i dont think there'll be any ABI changes
2026-06-04 07:24:55 <ikke> (But this is not my expertise)
2026-06-04 07:28:01 <runxiyu> I should probably submit it to KDE
2026-06-04 07:28:09 <ikke> Yes, that would be good
2026-06-04 07:28:31 <runxiyu> registering an account now
2026-06-04 07:35:03 <runxiyu> wait they have a mailing list...
2026-06-04 07:35:07 <runxiyu> anyways
2026-06-04 07:39:28 <runxiyu> https://invent.kde.org/frameworks/kio/-/merge_requests/2257
2026-06-04 08:41:39 <runxiyu> ikke: merged upstream! \o/
2026-06-04 08:42:31 <ikke> Nice, that was fast
2026-06-04 15:29:46 <longnoserob[m]> WhyNotHugothanks for the help with the MR, much appreciated!
2026-06-04 15:30:07 <longnoserob[m]> now I need to find time to actually do something with my ch32v boards
2026-06-04 16:01:24 <kroovy> if i wannt to send a patch for some aports, do i have to create a gitlab account and click a merge request, or can i also just send a patch to the maintainer? :o
2026-06-04 16:02:33 <ikke> kroovy: You _can_ try to send a patch to the maintainer, but most would prefer a merge request
2026-06-04 16:05:47 <kroovy> i understand. it makes sense to me to only have *one* way of handling it.
2026-06-04 16:06:50 <kroovy> i'm just not a fan of clicking in gitlab :c
2026-06-04 16:07:00 <ikke> glab-cli may be of help
2026-06-04 16:07:06 <kroovy> oha!
2026-06-04 16:07:08 <ikke> (but you would need to have an account first)
2026-06-04 16:07:17 <invoked> ikke: https://codeberg.org/forgejo/forgejo/issues/9550 tldr nesting doesn't seem likely to happen anytime soon. but i've seen people do stuff around multiple instances.
2026-06-04 16:07:28 <ikke> invoked: Yeah, i've been looking through issues
2026-06-04 16:07:29 <noodle> didn't now about glab-cli. thx :)
2026-06-04 16:07:37 <kroovy> :]
2026-06-04 16:07:46 <ikke> I create all my MRs to aports using glab cli
2026-06-04 16:08:14 <invoked> i can't imagine why you would not use glab, the webui is punishing
2026-06-04 16:10:52 <ikke> I find it a bit pity forgejo and co focused on duplicating github
2026-06-04 16:11:58 <noodle> ya. it don't even load as much pages as github witthout js ☠
2026-06-04 16:15:57 <noodle> btw hi ikke :3
2026-06-04 16:16:30 <ikke> noodle: hi, though I don't remember in what context we have met before
2026-06-04 16:20:16 <noodle> i vaguely remember dming a bit
2026-06-04 16:20:29 <noodle> might've been someone else. srry if not
2026-06-04 16:21:04 <ikke> Don't have any history, but no worry
2026-06-04 16:21:25 <noodle> rad
2026-06-04 16:24:35 <noodle> i should backup my logs better. i keep losing them when i recover from backups. rip
2026-06-04 16:25:18 <Biswa96[m]> is lightdm working for anyone in x86_64?
2026-06-04 16:33:51 <alexaandru> hi all! In the light of https://byteiota.com/github-cli-cve-2026-48501-token-leak/ any idea whom could I ping to take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103094 ? Thank you :-) 
2026-06-04 16:45:30 <ikke> alexaandru: do you perhaps wish to take over maintainership?
2026-06-04 16:51:48 <alexaandru> Sure, I could do that. Alpine is my home now, and I like to keep my tools up to date anyway...
2026-06-04 16:55:54 <ikke> Author indicates in their profile that they're busy and open for someone else to take over
2026-06-04 16:56:00 <ikke> Maintainer*
2026-06-04 16:59:21 <alexaandru> much appreciated! So what's the etiquette on taking over maintainership? Do I check with current maintainer or do I just submit a MR... ?
2026-06-04 16:59:43 <ikke> You can make an MR, then we can ask the maintainer if it's okay
2026-06-04 17:02:17 <alexaandru> sounds good. I see in the git log lots of "upgrade to X.Y.Z and take over maintainership"... I guess I'll do the same and couple that request with the next upgrade, less noise. You guys already have enough MRs as is :-) 
2026-06-04 17:09:57 <ivanpollak> hi, how can i add a startup script that runs as root? i tried it in /etc/local.d/xdg.start but it doesnt work. It is a simple bash script from https://man.sr.ht/~kennylevinsen/seatd/#using-simple-scripts
2026-06-04 17:15:38 <alexaandru> that should do. Did you make it executable?
2026-06-04 17:16:26 <ikke> also make sure the local service is enabled 
2026-06-05 04:48:07 <rnkn> invoked: reading through that issue I still can't see what benefit groups/projects represent, just organise repos cleanly
2026-06-05 04:50:11 <rnkn> like, the idea of re-architecting forgejo just to avoid setting repo permissions an extra couple of times?
2026-06-05 04:50:59 <ikke> Consistency
2026-06-05 04:52:30 <rnkn> what are the things need to be kept consistent?
2026-06-05 04:53:07 <ikke> permissions
2026-06-05 04:53:17 <ikke> in gitlabs case, CI/CD variables
2026-06-05 04:55:41 <rnkn> those things can't just be set per-repo? I know it's probably annoying but compared to those in that issue asking to re-architect forgejo...
2026-06-05 04:57:34 <ikke> Having to set them in each repo and keep in sync is annoying and leads to inconsisntency
2026-06-05 05:00:20 <rnkn> fair enough
2026-06-05 05:44:04 <rnkn> is the dump utility not in aports?
2026-06-05 05:44:12 <rnkn> https://linux.die.net/man/8/dump
2026-06-05 05:50:43 <invoked> e2fsprogs-extra
2026-06-05 05:52:18 <invoked> except in there the binary is 'dumpe2fs' because there are other dumps. the dump(8) you linked to is for ext2/3
2026-06-05 05:59:21 <jeibnds> sdf
2026-06-05 06:26:58 <rnkn> invoked: ty
2026-06-05 06:42:41 <rnkn> okay dumpe2fs displays file system information, it's not the backup tool
2026-06-05 06:57:37 <rnkn> apk search cmd:restore turns up nothing too
2026-06-05 06:57:41 <rnkn> I think I am outta luck
2026-06-05 07:23:17 <invoked> rnkn: oops
2026-06-05 07:23:30 <invoked> i thought that was it, sorry.
2026-06-05 07:23:45 <invoked> you can poke around with 'apk search cmd:dump'
2026-06-05 07:24:04 <invoked> 
ACTION herding cats

2026-06-05 07:30:05 <rnkn> I think I can see why it's missing; from debian: "This is a port of the 4.4BSD filesystem backup suite."
2026-06-05 07:30:37 <rnkn> wondering if I should just use tar
2026-06-05 07:59:15 <rnkn> busybox tar does have the one-filesystem flag, hrmm
2026-06-05 07:59:22 <rnkn> doesn't*
2026-06-05 12:10:15 <WhyNotHugo> aelin: do you use selinux on Alpine?
2026-06-05 13:51:41 <penguinz_rule[m]> i have the weird issue on armhf pi0w where it cannot connect to either ssid of the extended home wifi network, but will connect to the a hotspot off my phone strangely enough
2026-06-05 13:51:55 <penguinz_rule[m]> because i yoloed the edge upgrade i did not record what upgraded 
2026-06-05 13:52:05 <penguinz_rule[m]> but it was ~3 months ago to now 
2026-06-05 14:02:02 <ikke> penguinz_rule[m]: if you already had apk-tools v3, there is /var/log/apk.log (or something like that)
2026-06-05 14:05:36 <penguinz_rule[m]> will send pastebin of soon, thanks
2026-06-05 15:47:11 <witcher01> rnkn: if busybox tar is a hard requirement you could try using busybox find's -xdev flag in combination with it, which doesn't descend into directories of other filesystems
2026-06-05 17:15:33 <bloink> penguinz_rule[m]: pis rule
2026-06-05 17:15:52 <penguinz_rule[m]> ?
2026-06-05 18:03:59 <wing> raspberry pi, i assume, though i did read it as piss rule at first
2026-06-06 14:34:14 <penguinz_rule[m]> internet resolved itself lol
2026-06-06 21:41:55 <bleb> does anyone have an up to date guide for how to get yt-dlp working on alpine?
2026-06-06 21:42:15 <bleb> since the last time I used it, it has started to require a javascript runtime
2026-06-06 21:42:58 <bleb> I did apk add deno
2026-06-06 21:43:03 <bleb> then pipx install --force 'yt-dlp[default]'
2026-06-06 21:43:48 <bleb> but yt-dlp still claims "No supported JavaScript runtime could be found."
2026-06-06 21:47:11 <runxiyu> i mean, yt-dlp 2026.03.17 is packaged
2026-06-06 21:53:00 <bleb> I see
2026-06-06 21:53:27 <bleb> can I get it without upgrading to 3.23
2026-06-06 22:09:01 <penguinz_rule[m]> venv probably
2026-06-06 22:09:05 <penguinz_rule[m]> unless python is too old on that machine
2026-06-06 22:09:29 <penguinz_rule[m]> actually nvm
2026-06-06 22:28:11 <WhyNotHugo> Should be feasible to backport yt-dlp-2026.03.17 to 3.22
2026-06-06 22:28:36 <WhyNotHugo> Or clone aports and `abuild -r` just that package if you're willing.
2026-06-06 22:29:15 <WhyNotHugo> Er, actually, don't do that, it might rebuild dependencies and get you into an ugly state. Backporting is the way.
2026-06-07 03:06:14 <Dicess> How can I change my nickname any help please
2026-06-07 03:07:28 <noodle> Dicess: try /nick yournewnickhere
2026-06-07 03:09:22 <Dicess> Can I message you directly am lost
2026-06-07 03:10:05 <noodle> Dicess: sure, #oftc can provide help too
2026-06-07 03:10:47 <Dicess> Can you join me to other good irc networks
2026-06-07 03:11:01 <Dicess> Pm first I can't do it myself thank you
2026-06-07 03:12:04 <noodle> sure, pming
2026-06-07 03:12:52 <Dicess> Where am I going to see it 
2026-06-07 03:14:00 <noodle> no worries, found you
2026-06-07 11:40:16 <stureplan> Hello, I would like to replace GRUB with an EFI stub. I've created a new bootentry using efibootmgr, but when I reboot I still get show the GRUB menu before linux boots. I would've expected that this would skip GRUB, and directly boot vmlinuz. Maybe I've gotten it wrong and this is not to be expected, truthfully I don't have such deep understanding of the linux boot process.
2026-06-07 11:40:24 <stureplan> https://paste.sr.ht/~ludv/2875e7c8edda79c2177b2d10b8479719b20949ec
2026-06-07 12:04:28 <WhyNotHugo> stureplan: BootCurrent: 0002 indicates that it has booted from entry 0002, which is labelled EFISTUB.
2026-06-07 12:18:14 <jvvv> I am wondering if the '--loader /vmlinux-lts' should maybe be '--loader /boot/vmlinuz-lts'? Also, not sure if there should be some backslashes before the foreward slashes.
2026-06-07 12:20:16 <jvvv> I don't know the disk layout involved here, but my gpt layout is: part1=root part2=efi part3=swap . This puts /boot in the main root partition so there wouldn't be a /vmlinux-lts for me.
2026-06-07 12:35:08 <WhyNotHugo> jvvv: those paths are relative to the ESP (which I presume to be /boot in this case). And it's backslashes since EFI uses win/dos conventions.
2026-06-07 12:50:48 <stureplan> WhyNotHugo: Yes, I renamed "Alpine Linux" -> "Alpine Linux EFISTUB" between the two attempts, they are both EFI stubs, sorry for the confusion. Yes, it has has booted the correct bootentry (0002), but I don't understand why GRUB is still being executed.
2026-06-07 12:54:45 <jvvv> I tried adding an entry similar to stureplan, but adjust paths for my /boot directory being located on my root partition (initrd entrys and kernel).
2026-06-07 13:04:39 <jvvv> That entry came up but failed with notice that secureboot was not enabled. I enabled it and it failed anyways. Will have look into it.
2026-06-07 13:26:29 <WhyNotHugo> stureplan: I don't see any obvious indication either, sorry.
2026-06-07 13:43:07 <runxiyu> anything up with the riscv64 builder?
2026-06-07 14:00:46 <jvvv> stureplan: Ok, I figured out what is going wrong for efistub.
2026-06-07 14:06:38 <jvvv> First, the kernel and initramfs images need to be on the efi system partition. Some efi implementations require the loader (the kernel) to have an .efi suffix. The 'initrd=...' portion of the commandline must have unescaped backslashes instead of foreward slashes: 'initrd=\EFI\initrd.img'. I copied my to kernel, initramfs, and ucode images to my /boot/efi/EFI and made sure they
2026-06-07 14:06:40 <jvvv> all met the old dos 8+3 filename req.
2026-06-07 14:08:26 <jvvv> The backslashes for the initrd= paths, if inside double quotes, need to be doubled (\\EFI\\initrd.img).
2026-06-07 14:09:40 <jvvv> Not sure the dos 8+3 filenaming rules are necessary or not, could depend on efi implementation.
2026-06-07 14:14:31 <y1nz> ninjin: did u work out ur stagit ideas?
2026-06-07 14:15:27 <jvvv> For my laptop, the kernel doesn't need to end in .efi and the initrd files did not need to follow the dos 8+3 rule.
2026-06-07 14:17:45 <jvvv> stureplan: After copying kernel + initrd images to /boot/efi/EFI, this was my efibootmgr cmdline: efibootmgr -c -L "efistub" -d /dev/nvme1n1 -p 1 -l '\EFI/vmlinuz-lts' -u 'root=UUID=be739bea-cb2f-4dbf-bb48-40fecba918b2 ro modules=sd-mod,usb-storage,ext4,nvme quiet rootfstype=ext4 initrd=\EFI\intel-ucode.img initrd=\EFI\initramfs-lts'
2026-06-07 14:19:53 <jvvv> Getting a setup like this to correctly get updated on kernel upgrades and ucode upgrades is TODO.
2026-06-07 15:12:45 <bananicorn> Hi there :) I use a ThinkPad X220 and have been successfully using it with Bluetooth headphones but it just doesn't see my new Bluetooth mouse or keyboard. is there something I might be missing software wise or is it just that the X220's Bluetooth module is too old?
2026-06-07 15:14:09 <bananicorn> Basically with bluetoothctl and bluetuith they just don't show up when scanning, other devices do though
2026-06-07 15:14:27 <bananicorn> And the keyboard and mouse work fine via Bluetooth with other devices
2026-06-07 15:23:26 <monotux[m]> are they in pairing mode?
2026-06-07 15:23:36 <bananicorn> Yup, definitely
2026-06-07 15:23:51 <bananicorn> Other devices recognise them at the same time that the X220 doesn't
2026-06-07 15:39:37 <quinq> bananicorn, could be, checking for compat should be pretty easy
2026-06-07 16:06:36 <bananicorn> I thought Bluetooth was backwards compatible but I guess it's not 😅
2026-06-07 16:07:34 <bananicorn> So software wise there is nothing specific needed for Bluetooth mouse/keyboard devices?
2026-06-07 16:29:29 <stureplan> jvvv: Thank you so much, it works now! I changed the slashes. My ESP is mounted at /boot, and instead of moving vmlinuz and intramfs to /boot/EFI, i just edited the command. I also noticed that I didn't have any ucode installed, so I installed amd-ucode and edited "intel-ucode.img" -> "amd-ucode.img" in the command. 
2026-06-07 16:31:18 <stureplan> Might (aswell as the slashes) also have been the missing ucode that was causing trouble?
2026-06-07 21:11:13 <jvvv> stureplan: Glad you got it working. Not sure about the ucode causing failure... maybe. But good thing is we both learned some stuff today.