2025-07-01 06:32:30 <PureTryOut> Can a package have multiple replaces? Just space-divided like all other variables?
2025-07-01 07:32:53 <pabloyoyoista> PureTryOut: yes, check postmarketos-base for an example
2025-07-01 11:23:47 <ncopa> achill: did you report the execinfo.h kernel build issue upstream?
2025-07-01 11:24:04 <ncopa> I'm about to send an email to stable
2025-07-01 11:24:32 <achill> i did even fix it
2025-07-01 11:25:57 <ncopa> I saw you sent the fixing patch, but i cant find the report
2025-07-01 11:32:36 <achill> i didnt report it, i just tried sending the patch.
2025-07-01 11:32:46 <achill> it got picked by andrew morton but now it got dropped again
2025-07-01 11:33:22 <ncopa> ok
2025-07-01 11:33:31 <achill> i'm gonna ask again because right now the workflow is really not friendly
2025-07-01 11:37:40 <ncopa> I'm reporting it too
2025-07-01 11:38:42 <achill> sending a patch to the kernel is even worse than i expected it to be
2025-07-01 11:45:44 <achill> https://lore.kernel.org/stable/DB0OSTC6N4TL.2NK75K2CWE9JV@pwned.life/T/#t
2025-07-01 11:51:45 <ncopa> thanks
2025-07-01 11:51:55 <ncopa> there was a tool to find the right maintainer for a given file
2025-07-01 11:52:19 <achill> yeah but the file is maintained by nobody 🙃
2025-07-01 11:53:26 <achill> ➜  linux git:(linux-6.15.y) ./scripts/get_maintainer.pl tools/include/linux/kallsyms.h
2025-07-01 11:53:26 <achill> linux-kernel@vger.kernel.org (open list)
2025-07-01 11:53:35 <ncopa> scripts/get_maintainer.pl 
2025-07-01 11:54:36 <fossdd> gentoo sam recommended me to cc andrew, and also i've red that andrew merges stuff without a maintainer, but somehow he also doesnt "care"
2025-07-01 11:55:18 <ncopa> I'm trying to get Greg's attention
2025-07-01 11:56:59 <fossdd> yeah funnily enough greg responded to my v1 and said i need something more in the commit message, but apparently didnt red my v2..
2025-07-01 11:57:49 <ncopa> the amount of emails and patches they have to deal with is insane
2025-07-01 11:58:12 <f_> so many patches yet so few maintainers to take care of all of them
2025-07-01 11:58:15 <fossdd> thats true indeed
2025-07-01 12:08:29 <liske> ncopa: about linux-rpi - According to upstream https://www.raspberrypi.com/documentation/computers/linux_kernel.html they state that their offical rpi kernel may lag behind vanilla linux. So I wonder if it would be OK for alpine to also lag behind linux-lts (so we don't have to bother with merge conflicts downstream)
2025-07-01 12:18:51 <ncopa> I soppse we dont have much choice if we dont have time to deal with the conflicts
2025-07-01 12:19:22 <ncopa> alright, linux kernel report sent. now its time to merge apk 3
2025-07-01 12:20:36 <liske> the latest kernel package on rpios is 6.12.25 and based on the stable_20250428 tag
2025-07-01 12:21:45 <achill> looks like rpi-6.12.y is already rebased on .35
2025-07-01 12:21:45 <liske> git head seems to get patches all the days long - IMHO it doesn't look stable without a official tag
2025-07-01 12:22:15 <liske> achill: yes but there are some rpi specific patches and reverts on top
2025-07-01 12:40:38 <omni> I'd appreciate to be in the loop of changes to aports I'm the maintainer of, the exception I'm fine with being non-breaking security fixes
2025-07-01 12:44:08 <achill> sure
2025-07-01 12:57:22 <ncopa> omni: thanks for letting us know
2025-07-01 12:57:36 <ncopa> and thanks for taking good care of the packages you maintain
2025-07-01 13:37:39 <ncopa> I merged apk-tools 3
2025-07-01 14:17:42 <ncopa> PureTryOut: Do you think you can help follow up the breeze-icons? you need backport the two(?) patches listed here: https://tpaste.us/5Qej
2025-07-01 14:53:13 <jvvv> trying to determine how to replicate abuild check errors that happen on builders, but can't reproduce here or in CI
2025-07-01 14:53:33 <jvvv> it's weird how consistent the errors are on the builders
2025-07-01 14:56:34 <ikke> jvvv: which package?
2025-07-01 14:56:56 <jvvv> tree-sitter-vimdoc
2025-07-01 14:58:54 <PureTryOut> ncopa: oh there are fixes for it upstream already? nice!
2025-07-01 15:20:30 <PureTryOut> ncopa: I backported those commits and it fixed it, the builders are working through the rest of the queue now
2025-07-01 15:32:29 <ncopa> thanks!
2025-07-01 16:21:27 <henrix> achill: I've just replied to your kernel patch.  FWIW this issue could be fixed by simply disabling CONFIG_X86_DECODER_SELFTEST in the config
2025-07-01 16:21:56 <henrix> (but you probably already knew that :-) )
2025-07-01 16:22:44 <jvvv> fossdd: hey, chill out
2025-07-01 16:23:30 <jvvv> i already saw the build fail and am working on it
2025-07-01 16:23:49 <jvvv> my toes are starting to hurt
2025-07-01 16:25:56 <achill> oh no pressure, i had hoped -vim would work, but ehh
2025-07-01 16:26:16 <achill> hopefully with abuild rootbld on a new builder setup we can have builds more reproducible
2025-07-01 16:26:27 <achill> this different setup between builder and ci is really annoying
2025-07-01 16:26:54 <achill> henrix: didnt knew that, but also didnt look since its an actual issue that should get fixed
2025-07-01 16:29:30 <henrix> achill: ah, yes, absolutely! I'm just not sure it's worth having it enabled for distro kernels, since it's a debug thing AFAIU
2025-07-01 16:32:32 <achill> > 
2025-07-01 16:32:32 <achill> Perform x86 instruction decoder selftests at build time.
2025-07-01 16:32:32 <achill> decoder code.
2025-07-01 16:32:32 <achill> idk sounds useful if its only at build time and doesnt effect the user
2025-07-01 16:32:32 <achill> This option is useful for checking the sanity of x86 instruction
2025-07-01 16:44:07 <henrix> yeah, maybe. definitely not my area.  I know it's not enabled at least in some distros (debian for ex)
2025-07-01 16:44:24 <henrix> ... and if x86 instructions aren't being properly generated, that's something that will be easily picked by other means :-)
2025-07-01 16:44:41 <henrix> 
ACTION goes back under is rock

2025-07-01 16:52:20 <nusgul[m]> Hello, is here an appropriate place to ask questions about apk-tools codebase ?
2025-07-01 17:47:34 <pabloyoyoista> Congrats everybody on the APKv3 getting merged 🥳
2025-07-01 17:56:01 <sam_> fossdd: oh, you tried that and got nowhere? ugh
2025-07-01 17:56:15 <sam_> fossdd: I can try ping as well (not that I'm special, but it may look better if someone else does it in short order)
2025-07-01 18:42:58 <achill> yeah that might help i guess
2025-07-01 19:06:04 <sam_> will do
2025-07-01 19:08:20 <achill> thanks
2025-07-01 19:08:47 <f_>  18:52 <nusgul[m]> Hello, is here an appropriate place to ask questions about apk-tools codebase ?
2025-07-01 19:09:02 <f_> there's ircs://irc.oftc.net/#apk-tools for that
2025-07-01 19:09:27 <f_> but I think here is fine too
2025-07-01 19:09:55 <sam_> weird that andrew picked it up and it got lost??
2025-07-01 19:10:07 <sam_> he normally sends an email when he has to do that
2025-07-01 19:10:11 <f_> "OK, thanks for the reminder, I restored this."
2025-07-01 19:10:23 <sam_> oh sick
2025-07-01 19:10:24 <f_> https://lore.kernel.org/stable/DB0OSTC6N4TL.2NK75K2CWE9JV@pwned.life/T/#m859d45c920cd84afee4d3ff58d1ae875133d5616
2025-07-01 19:10:26 <sam_> amazing timing
2025-07-01 19:10:41 <sam_> (page was cached for me, shows up on refresh)
2025-07-01 19:10:44 <f_> :-)
2025-07-01 19:11:30 <achill> oh nice
2025-07-01 19:11:50 <f_> sam_: probably lost in some rebasing or something
2025-07-01 19:37:00 <nusgul[m]> thanks _f. I managed to find an answer to my questions but i've joined #apk-tools just in case for the future
2025-07-02 11:40:44 <achill> ncopa: btw akpm picked it into mm-hotfixes-unstable again, idk how it will get into linus' tree, but i think its on its way up there
2025-07-02 12:00:20 <ncopa> I saw this https://lore.kernel.org/stable/20250701120920.49cd122526b3032a4db1e218@linux-foundation.org/ yes
2025-07-02 12:00:29 <ncopa> I wonder where I can find it restored?
2025-07-02 12:01:04 <achill> here https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kallsyms-fix-build-without-execinfo.patch or https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-hotfixes-unstable&id=03f24c814303ac27575ddfa7c285719ce3f1c981
2025-07-02 12:02:10 <ncopa> alright. seems like they will accept your fix. which is good
2025-07-02 12:04:57 <achill> yea
2025-07-02 12:20:45 <sam_> the scary part is not them rejecting it
2025-07-02 12:20:50 <sam_> it's that patches can and do fall through the cracks somehow
2025-07-02 12:20:53 <sam_> in the biggest foss project we have
2025-07-02 12:20:58 <sam_> it's all MLs and bandages
2025-07-02 12:21:00 <sam_> crazy
2025-07-02 12:44:46 <achill> yeah, until its in linus tree, i dont get too excited
2025-07-02 12:45:12 <achill> it makes me wonder if that happend before and nobody noticed
2025-07-02 13:05:45 <henrix> well, if something falls through the cracks and nobody notices... it's probably because it wasn't very important in the first place :-)
2025-07-02 13:08:43 <achill> not if people rely and trust on the subsystem maintainer to get stuff upstream and dont drop it without further notice
2025-07-02 13:09:53 <henrix> sure, I agree the process can fail (specially with stable kernels).
2025-07-02 13:10:05 <henrix> and things work differently depending on the subsystems
2025-07-02 13:11:48 <henrix> there's code that don't even have a maintainer assigned ;-)
2025-07-02 14:22:32 <lotheac> i don't think it's at all unlike any other large carefully curated collection of code, like say a distribution
2025-07-02 14:23:01 <lotheac> processes differ, things happen, releases eventually get made anyway
2025-07-02 14:24:32 <lotheac> "nobody's perfect" is my point (:
2025-07-03 10:35:23 <machoskraito> hi all
2025-07-03 10:42:33 <ncopa> hi
2025-07-03 10:43:02 <machoskraito> <machoskraito> yay kid i am just been elect back as United Nations Chief Executive Board
2025-07-03 10:43:03 <machoskraito> <machoskraito> hi bkil
2025-07-03 10:43:03 <machoskraito> <machoskraito> so how are you all here
2025-07-03 10:43:03 <machoskraito> <machoskraito> We are releasing AstaraOS-FreeBSD-v15 now
2025-07-03 10:43:03 <machoskraito> <machoskraito> my name is yohanes patra aka skraito
2025-07-03 10:43:04 <machoskraito> <machoskraito> nice to meet you all 
2025-07-03 10:43:06 <machoskraito> hi ncopa
2025-07-03 10:43:27 <machoskraito> nice to meet you all
2025-07-03 11:51:35 <machoskraito> hi all back ... .
2025-07-03 12:13:33 <ncopa> any ideas why tree-sitter-vim fails on the builders?
2025-07-03 12:20:07 <ncopa> I am not able to reproduce it
2025-07-03 12:33:04 <ncopa> i am losing my mind. why am i not able to reproduce the tree-sitter-vim check error?
2025-07-03 12:33:09 <ncopa> it happens on all builders
2025-07-03 13:00:10 <lnl> The `Substitute command` test wasn't even run in MR CI, what the hell
2025-07-03 13:02:56 <mio> same, tried locally and the two tests that failed didn't run for me
2025-07-03 13:03:46 <mio> as in, it didn't run at all, total count at the end was 269, not 271 as the numbering suggests is the total number of tests
2025-07-03 13:06:11 <mio> the tests were supposed to be skipped though from the APKBUILD
2025-07-03 13:07:57 <lotheac> "Substitute command" does not even exist in tree-sitter-vim-0.5.0.tar.gz
2025-07-03 13:08:23 <lotheac> oh, my tree is out of date *facepalm*
2025-07-03 13:14:37 <lotheac> those failing tests are supposedly disabled in check() https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/tree-sitter-vim/APKBUILD?ref_type=heads#L20-L22
2025-07-03 13:20:00 <lotheac> i can get the failure to happen locally with aports at 5bd4139d669427b41a683011ef167045cce08c03 (but not at master -- 0.6.0-r0 was reverted and re-updated between 5bd413 and master)
2025-07-03 13:20:49 <lotheac> so... is it possible that the builders' aports checkout is behind?
2025-07-03 13:24:37 <lotheac> !86374 - reverted in 033444aeef559bd30b5e43b523e69c6b156e105b - redone (with test disabling) in !86392
2025-07-03 14:36:41 <achill> ncopa: the log is still from a few days ago and not updated
2025-07-03 14:36:56 <ncopa> I know what going on and I will push a fix soon
2025-07-03 14:37:00 <achill> ah nice
2025-07-03 14:37:22 <ncopa> tree-sitter stores in XDG .cache
2025-07-03 14:37:30 <ncopa> builders keept old state
2025-07-03 14:37:33 <ncopa> and goes boom
2025-07-03 14:37:37 <ncopa> CI is clean and passes
2025-07-03 14:37:40 <achill> oh wow
2025-07-03 14:37:44 <ncopa> yeah
2025-07-03 14:37:55 <ncopa> got help from tree-sitter-vim dev on matrix
2025-07-03 14:38:09 <achill> in the future(tm) we'll hopefully be able to build in rootbld
2025-07-03 14:38:19 <ncopa> we need to set HOME or XDG_somthing in abuild-tree-sitter
2025-07-03 14:38:36 <ncopa> we should probably also consider set HOME in abuild
2025-07-03 14:38:41 <ncopa> or at least XDG_HOME
2025-07-03 14:39:03 <ncopa> but for now: we need to set HOME or XDG_somthing in abuild-tree-sitter
2025-07-03 14:39:09 <ncopa> i need a 10 min break
2025-07-03 14:43:27 <achill> yeah you deserved it
2025-07-03 14:43:43 <achill> but that the logs at build.a.o are out-of-date is really annoying
2025-07-03 14:58:27 <ncopa> its a "break" to deal with other urgent matters
2025-07-03 15:08:24 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86501 we probably need to do this for all tree-sitter-*
2025-07-03 15:08:49 <ncopa> build-edge-armv7 [~/aports/community/tree-sitter-vim]$ ls ~/.cache/tree-sitter/lib
2025-07-03 15:08:49 <ncopa> php.so        query.so      vim.so        yaml.so
2025-07-03 15:08:49 <ncopa> hcl.so        php_only.so   terraform.so  vimdoc.so
2025-07-03 15:12:18 <ncopa> not sure we should set XDG_* in abuild
2025-07-03 15:18:42 <achill> maybe together with MOVE_CACHES
2025-07-03 15:24:05 <jvvv> ncopa: thank you for looking into tree-sitter build issues
2025-07-03 15:24:56 <ncopa> jvvv: no worries. I think we may need to similar hack for the other tree-sitter-* packages til we have this sorted out properly in abuild
2025-07-03 15:26:03 <jvvv> i can get mine right now. if the other tree-sitter-* maintainers don't mind, i can work adjusting more
2025-07-03 15:26:26 <ncopa> or we can wait til they also break... :)
2025-07-03 15:27:51 <jvvv> i'm ok with that... i see you mentioned maybe putting it in abuild-tree-sitter, so i am in no hurry, just have available time
2025-07-03 15:28:43 <ncopa> I was wrong. the tests does not run with abuild-tree-sitter, so we cant fix it there
2025-07-03 15:29:06 <jvvv> ah, true, it's 'tree-sitter test ...'
2025-07-03 15:29:13 <achill> but we can export the XDG_.. vars in abuild where we also define e.g. the go cache
2025-07-03 15:29:23 <ncopa> yeah
2025-07-03 15:29:44 <ncopa> we could consider override HOME ...
2025-07-03 15:29:53 <ncopa> from abuild
2025-07-03 15:30:31 <jvvv> just my opinion, but i think fixes like this are better in the APKBUILD's themselves, otherwise the 'issue' is glossed over
2025-07-03 15:33:56 <realroot[m]> in waht folder of aports there is libx11-dev?
2025-07-03 15:34:16 <achill> the apkbrowser is your friend: https://pkgs.alpinelinux.org/packages?name=libx11-dev&branch=edge&repo=&arch=x86_64&origin=&flagged=&maintainer=
2025-07-03 15:34:26 <achill> its main/libx11
2025-07-03 15:35:09 <realroot[m]> thanks but often the link is the whole aport
2025-07-03 15:35:45 <achill> what? sorry, i dont understand what you mean
2025-07-03 15:36:34 <realroot[m]> the link in Git repository 	Git repository
2025-07-03 15:36:37 <ncopa> have a look at "Origin"
2025-07-03 15:37:36 <ncopa> `apk policy libx11-dev` will tell you which repo it comes from (eg main or community)
2025-07-03 15:37:46 <achill> the subpackages e.g. libx11-dev are built with the APKBUILD of the origin package (here libx11) which is also the name of the directory in aports
2025-07-03 15:38:36 <ncopa> `apk search --origin libx11-dev` will tell you the aport pkgname the (sub)pkg came from. the "origin"
2025-07-03 15:40:58 <ncopa> there is also a git hash in the apk meta data. you can also use that to find the directory in aports tree
2025-07-03 15:41:33 <ncopa> but I dont know if apk exposes the git hash anywhere
2025-07-03 15:43:52 <ncopa> git show $(apk fetch --stdout libx11-dev | tar -zx -O .PKGINFO | awk '$1 == "commit" {print $3}')
2025-07-03 15:43:56 <ncopa> hackish :)
2025-07-03 15:45:52 <realroot[m]> thanks. FYI here fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
2025-07-03 15:47:19 <ncopa> the git thingy kinda assumes you have the aports tree checked out already
2025-07-03 16:59:16 <Ariadne> has anyone made a tool to translate the isc dhcpd leases file to the format used by another dhcp server yet?
2025-07-03 17:29:38 <ncopa> i dont know any such tool
2025-07-03 17:30:32 <ikke> Habbie perhaps?
2025-07-03 17:31:38 <Habbie> hi
2025-07-03 17:31:42 <Habbie> i have not
2025-07-03 17:32:31 <Habbie> It is, of course, possible to rewrite the configuration file manually; however, ISC has developed the Kea Migration Assistant (or "KeaMA") tool to make it easier for users to translate their configuration files from one format to the other. (See below for more details about KeaMA.)
2025-07-03 17:32:38 <Habbie> is this anything?
2025-07-03 17:32:45 <pabloyoyoista> Hi! Regarding the /usr merge, would some of the alpine devs have thoughts about how to move forward with the implementation: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504#note_521743 ? 
2025-07-03 17:33:01 <pabloyoyoista> There's basically a decision to make, on whether migrations should be automatic or manual
2025-07-03 17:33:10 <pabloyoyoista> And then the work would be different
2025-07-03 17:33:18 <pabloyoyoista> ncopa: this one's probably good for you to have a look
2025-07-03 17:33:25 <Habbie> it is, at least, a more standalone version of the isc dhcpd config parser
2025-07-03 17:33:43 <Habbie> and the output is JSON. Maybe not the JSON you want, but JSON is always a good start
2025-07-03 17:35:22 <Ariadne> i cobbled this together: https://gist.github.com/kaniini/821a9eedee96e060ad46fe44393f5148
2025-07-03 17:35:32 <Ariadne> i don't want to use Kea
2025-07-03 17:35:40 <Habbie> i figured
2025-07-03 17:35:53 <Habbie> you want to use dnsmasq?
2025-07-03 17:36:06 <Ariadne> yes
2025-07-03 17:36:11 <Habbie> i was not expecting that
2025-07-03 17:36:28 <Ariadne> why?  it's small
2025-07-03 17:37:43 <Habbie> yes, it is. i also found it to not be very good for DHCP. IIRC it can, depending on settings, give out IPs at a max rate of one per 3 seconds
2025-07-03 17:38:01 <Habbie> i like odhcpd, but it's very tied to openwrt
2025-07-03 17:38:21 <Ariadne> if i find myself dissatisfied, i can always change it again :p
2025-07-03 17:39:07 <Habbie> yes
2025-07-03 17:39:22 <Habbie> anyway, so, the kea migration assistant looks like a standalone tool, that emits JSON
2025-07-03 17:39:58 <Ariadne> i already swapped to dnsmasq
2025-07-03 17:40:17 <Ariadne> kea is basically the direct opposite of what i want in a dhcp server, it seems very Enterprise
2025-07-03 17:40:22 <Habbie> i feel there is some miscommunication. I'm not suggesting Kea. I'm suggesting the tool might be useful for your conversion
2025-07-03 17:40:32 <Habbie> but looking at timestamps, I think you cobbled it together after you asked here
2025-07-03 17:40:37 <Habbie> and thus there is nothing left to be done
2025-07-03 17:40:44 <Ariadne> right :)
2025-07-03 17:41:20 <Habbie> but for next time i get this question, i'll now know about the kea converter :D
2025-07-03 17:41:37 <Habbie> i migrated from isc dhcpd to kea once, but i did not know about the tool. i did not have static leases anyway
2025-07-03 17:42:55 <Ariadne> oh this was just for dynamic ones, i just don't want the IPs to change
2025-07-03 17:43:13 <Habbie> oh wait. i totally skipped that part of the question
2025-07-03 17:43:17 <Habbie> not even sure the kea tool handles that then
2025-07-03 19:08:58 <pabloyoyoista> Ariadne: if you got time after fixing your network, I think your feedback on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504#note_521743 might also be very useful
2025-07-03 20:24:35 <Ariadne> pabloyoyoista: i responded but you probably won't like my vote
2025-07-03 20:25:23 <Ariadne> in general, i am hesitant to automatically force merged /usr on pre-existing installations, there's too many unknowns to have any confidence in the safety of that approach
2025-07-03 20:28:35 <craftyguy[m]> the whole reason for creating a test suite for the merge script, having the script in testing, and so on is so that we can find these unknowns and get confidence that this works
2025-07-03 20:29:00 <pabloyoyoista> I mean, in a way if you all think it's better for alpine users to take ownership of their migration like this, that's fine. But that also assumes that if issues araise, or people don't read the release notes and things go south, then we don't take ownership of those failures
2025-07-03 20:29:12 <Habbie> how did Debian handle th is?
2025-07-03 20:29:14 <Habbie> *this
2025-07-03 20:29:45 <craftyguy[m]> go look it up :P
2025-07-03 20:29:48 <pabloyoyoista> You could do it manually for a while, but then was forced on you
2025-07-03 20:29:56 <Habbie> right
2025-07-03 20:30:27 <pabloyoyoista> Or maybe upgrade failed at some point if you hadn't done it?
2025-07-03 20:30:47 <craftyguy[m]> are we at the "you can do it manually" phase?
2025-07-03 20:31:18 <pabloyoyoista> Don't think so, since the design is not finalised
2025-07-03 20:32:35 <pabloyoyoista> But anyway, Ariadne thanks for your answer
2025-07-03 20:34:46 <Ariadne> craftyguy[m]: i support the existence of the script, but not the automatic use of it.
2025-07-03 20:35:41 <Ariadne> the reality is, people don't read release notes, and people make modifications to their systems which break assumptions *already*
2025-07-03 20:35:45 <craftyguy[m]> so we need to support Alpine installs that never have usr merge?
2025-07-03 20:37:26 <pabloyoyoista> Ariadne: but then I'm confused. If people don't read release notes, then the responsibility cannot be placed on the users?
2025-07-03 20:37:27 <Ariadne> we have to provide partial support for those installs anyway for at least 4 release cycles
2025-07-03 20:37:50 <Ariadne> because it won't be backported to previous releases
2025-07-03 20:38:25 <Ariadne> my suggestion: new installs are merged-usr, old installs can be merged-usr if users want that.
2025-07-03 20:38:55 <pabloyoyoista> Forever?
2025-07-03 20:39:05 <Ariadne> of course not
2025-07-03 20:39:19 <craftyguy[m]> so if not forever, then... until when? :P
2025-07-03 20:39:36 <Ariadne> until there are no actively supported branches where merged-usr isn't the default
2025-07-03 20:40:15 <craftyguy[m]> but if we aren't auto-merging existing installs then isn't that "forever" ?
2025-07-03 20:40:34 <Ariadne> what i propose is: if you start on alpine 3.23, you are in a merged-usr world.  if you upgrade from 3.{19-22} to 3.23, then you decide when you want to enter that merged-usr world.
2025-07-03 20:40:48 <Ariadne> once those branches are EOL, then merged-usr is required
2025-07-03 20:40:53 <craftyguy[m]> like if you have 3.22 on your system, and 4 years from now still haven't run merge-usr, then your system is still not /usr merged even if new installs for every supported release is producing merged usr installs
2025-07-03 20:41:28 <craftyguy[m]> ok when merged usr is required.. then do we auto-merge? or just put it in the release notes that this is now required and hope folks read it?
2025-07-03 20:41:42 <Ariadne> the latter IMO.
2025-07-03 20:41:50 <Ariadne> pmOS, can of course, do whatever it wants
2025-07-03 20:42:06 <craftyguy[m]> yaa I'm talking specifically about Alpine, since this is alpine-devel :D
2025-07-03 20:42:07 <Ariadne> and we can use that data to gauge the safety of auto-merge over time
2025-07-03 20:42:28 <craftyguy[m]> this seems reasonable to me
2025-07-03 20:42:55 <Ariadne> basically what i am saying is auto-merge is not a good idea at this time, lets revisit it in 2 years once we fully understand the risks
2025-07-03 20:43:00 <craftyguy[m]> debian kinda had a disaster trying to support merged and non-merged installs at the same time, but maybe it'll be OK on Alpine
2025-07-03 20:43:35 <Ariadne> define support?
2025-07-03 20:43:41 <craftyguy[m]> https://lwn.net/Articles/890219/
2025-07-03 20:43:52 <Ariadne> i think it is okay for non-merged installs to have degraded experience
2025-07-03 20:44:44 <craftyguy[m]> IIUC there was some bug with building packages on merged usr systems that broke unmerged systems, but tbh that lwn article kinda breaks my brain (their style of writing is hard for me to follow sometimes 😅)
2025-07-03 20:45:34 <craftyguy[m]> anywho, I guess there could be some weirdness that comes up from trying to not break unmerged systems 🤷‍♂️
2025-07-03 20:45:52 <Ariadne> i think it is acceptable to say "if you have problems, switch to merged-usr"
2025-07-03 20:45:57 <Ariadne> during the transition period
2025-07-03 20:46:09 <achill> yeah this sounds reasonable
2025-07-03 20:46:17 <craftyguy[m]> yeah ^^
2025-07-03 20:46:27 <Ariadne> my point is that the system administrator should provide explicit consent to having their filesystem layout changed
2025-07-03 20:46:33 <Ariadne> since it has risks
2025-07-03 20:47:28 <craftyguy[m]> yeah that makes sense. I think we understand that, but at the same time we don't want to forever "support" unmerged installs. I think what you described is a good compromise
2025-07-03 20:48:35 <Ariadne> for example, i am aware of an alpine deployment in the field that involves tens of thousands of embedded ARM boards with cellular modems collecting telemetry
2025-07-03 20:48:56 <Ariadne> if we break those deployments, someone has to go out into the rainforest to fix it
2025-07-03 20:49:15 <Ariadne> times whatever thousands of sensors they have at this point
2025-07-03 20:49:45 <Ariadne> on the other hand, that research was funded by the US government, and maybe the entire project is abandoned now since it was related to climate change tracking
2025-07-03 20:49:57 <craftyguy[m]> oof
2025-07-03 20:50:02 <Ariadne> but there's many more examples of that sort of deployment
2025-07-03 20:50:04 <f_> 😂
2025-07-03 20:51:08 <craftyguy[m]> ya, as someone with a background in supercomputing stuff, I totally understand your concern there...
2025-07-03 20:52:02 <skarnet> I had an interview question once about designing a system for a remote update on the Moon
2025-07-03 20:52:19 <skarnet> I don't remember the details but it was pretty tricky to get right
2025-07-03 20:52:24 <craftyguy[m]> was the correct answer "you don't"? :P
2025-07-03 20:52:55 <skarnet> that's obviously the first thing I said but they asked me to proceed like it wasn't an option :P
2025-07-03 20:53:02 <craftyguy[m]> I feel like I'd fail that question because I'd volunteer to go to the moon to fix a computer 🤣
2025-07-03 20:53:16 <Ariadne> not on a starship...
2025-07-03 20:53:20 <f_> brb going to the moon to upgrade alpine linux
2025-07-03 20:53:36 <craftyguy[m]> oh yeah, dust off a saturn V
2025-07-03 20:53:42 <f_> flying cars
2025-07-03 20:53:51 <pabloyoyoista> Thanks a lot for your thoughts. The way you've put it indeed makes sense to me. Specially the responsibilities and expectations
2025-07-03 20:53:57 <skarnet> sorry, usrmerge failed, the moon is now planned to crash on Earth in a couple million years
2025-07-03 20:54:29 <pabloyoyoista> We should totally document that. So that if people complain about their degraded experience after moving to v3.23, we can point them somewhere
2025-07-03 20:54:32 <f_> oh there's still time to fix the usrmerge on the moon
2025-07-03 20:54:35 <craftyguy[m]> actually we never have to worry about that due to tidal forces "pushing" the moon away from us
2025-07-03 20:54:57 <Ariadne> i think i still have one of the prototype sensor boards for that experiment somewhere around here
2025-07-03 20:55:10 <Ariadne> i had to hand-solder like 100 of them :D
2025-07-03 20:56:36 <f_> If only it were in the alps really :p
2025-07-03 20:56:46 <craftyguy[m]> yikes. smd?
2025-07-03 20:57:20 <Ariadne> nah, it was just fixing some GPIO pins that were not included on the board from factory
2025-07-03 20:57:28 <Ariadne> because the requisition got screwed up
2025-07-03 20:57:45 <Ariadne> they thought the pins were nostuff initially
2025-07-03 20:58:12 <craftyguy[m]> ah, so rework stuff. still brutal
2025-07-03 20:58:23 <f_> oof.
2025-07-03 20:58:32 <achill> pabloyoyoista: we should add a warning to some prominent places (e.g. homepage of alpinelinux.org) to have a global warning for everyone who uses alpine
2025-07-03 20:59:08 <Ariadne> so basically, lets not start with auto-merge, but we can incrementally work towards it over releases
2025-07-03 20:59:14 <achill> yeah
2025-07-03 21:00:53 <pabloyoyoista> One thing that this makes a bit harder, is that we have to wait 2 years to drop lots of packaging hacks
2025-07-03 21:01:13 <pabloyoyoista> But that's just me being impatient 🤣
2025-07-03 21:01:21 <Ariadne> not really
2025-07-03 21:01:37 <craftyguy[m]> we can drop then in edge, if the intent is to support merged usr in 3.23?
2025-07-03 21:01:54 <Ariadne> like i said, i think it is valid to say "if you don't switch to merged-usr and it doesn't work for you, then switch to merged-usr"
2025-07-03 21:02:24 <Ariadne> what is not valid is doing something automatically which could break prod
2025-07-03 21:02:38 <Ariadne> because "prod" is different for every site
2025-07-03 21:03:13 <f_> but isn't just dropping packaging hacks and mostly not supporting split-usr very well (recommending folks to go the merged-usr route) also possibly breaking prod?
2025-07-03 21:03:16 <Ariadne> and so teams need to evaluate and test the impact of switching to merged-usr, e.g. lab it and then implement it in prod
2025-07-03 21:03:43 <Ariadne> f_: yes, but the larger risks are mitigated
2025-07-03 21:04:10 <Ariadne> if someone accidentally upgrades prod, they should still be in a recoverable state, where they can downgrade or switch to merged-usr
2025-07-03 21:05:23 <pabloyoyoista> OK, so that means that outside /lib/firmware and musl, we could move busybox scripts to /usr
2025-07-03 21:05:31 <Ariadne> yes
2025-07-03 21:05:43 <pabloyoyoista> That makes me feel a lot more at ease
2025-07-03 21:08:45 <craftyguy[m]> Ariadne: as always, your feedback and patience is amazing, thank you :)
2025-07-03 21:09:12 <pabloyoyoista> It means we can promise to fix most of the packaging bugs, without committing to still be here in 2.5 years, and thus not risk dumping the issue to you
2025-07-03 21:09:12 <pabloyoyoista> +1
2025-07-03 21:09:35 <Ariadne> i don't want to see us here in 0.5 years much less 2
2025-07-03 21:10:09 <Ariadne> but i also don't want to see broken deployments ;)
2025-07-04 11:54:10 <Habbie> this MR adds support for an extra arch to a port. I suspect this wants a pkgrel bump, is that right? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86005/diffs#note_522067
2025-07-04 12:01:10 <ikke> For just adding an extra arch, that's not necessary
2025-07-04 12:01:14 <Habbie> ah
2025-07-04 12:01:22 <Habbie> will it get built?
2025-07-04 12:02:00 <ikke> Yes, since the builder will notice the package is missing 
2025-07-04 12:02:07 <Habbie> ah, that's a neat approach
2025-07-04 12:02:12 <Habbie> thanks. I've approved the MR
2025-07-04 12:50:18 <Habbie> and the user has marked it as ready :)
2025-07-04 13:14:30 <pabloyoyoista> Could somebody add these 3 MRs to the /usr merge milestone?
2025-07-04 13:14:31 <pabloyoyoista> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504
2025-07-04 13:14:31 <pabloyoyoista> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/205
2025-07-04 13:14:41 <pabloyoyoista> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/260
2025-07-04 13:21:28 <pabloyoyoista> And we got 3 related and simple MRs to fix packaging bugs still pending in https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16#tab-merge-requests if somebody wanna have a look
2025-07-04 13:28:44 <achill> dont have permissions for mkinitfs or alpine-conf, but added the aports MR to the milestone
2025-07-04 17:49:32 <qaqland> how can i test package https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17311
2025-07-04 17:49:46 <qaqland> is there an existing gcc15 pcakage for testing?
2025-07-04 18:08:50 <achill> you can use mrtest for !86313 or download the artifcats and manually install it
2025-07-04 19:07:29 <hjaekel> achill, what I do not understand is: How can this missing rebuild leak from edge into 3.22? Are the packages for a new major release just taken from edge without a new build?
2025-07-04 19:16:30 <achill> no, but once the package is re-built on 3.22, commits from master still land in 3.22 until its branched off
2025-07-04 19:25:36 <hjaekel> now I understand thank you. The package upgrade was merged on 10 May, and 3.22 was released 12 May. 
2025-07-04 19:28:06 <hjaekel> Maybe your script could be added to the CI pipeline to detect missing rebuilds. This does not help if the pipeline is skipped, but some cases will be found
2025-07-05 12:03:18 <achill> if someone is bored, here is a list of missing rebuilds (https://tpaste.us/waJ9). it would be nice to rebuild them and get figure out how they were missed in the first place
2025-07-05 13:18:51 <sertonix[m]> It seems to be common to not check revdeps when bumping libraries. Also apk dot --errors is underrated
2025-07-05 13:23:15 <sertonix[m]> I think we should try to make the CI fail when something isn't provided anymore but still used
2025-07-05 16:23:55 <achill> oh didnt know about apk dot --errors
2025-07-05 16:23:57 <achill> thats nice
2025-07-05 17:28:49 <Kladky> enabling tests for all tree-sitter grammars: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57359#note_522457
2025-07-06 02:38:31 <machoskraito> hi all cartel here ... . how are you all ... .
2025-07-06 14:03:19 <sj_> Hey, I was just wondering if there are plans for a minor release within v3.22. Not trying to be pushy or anything, I'm just planning to do a fresh install and I've figured that it would be worth waiting for the next release
2025-07-06 14:06:43 <Sheila> all minor releases do is add a snapshot of the current state of particular packages, so there's no reason to wait.
2025-07-06 14:07:08 <sj_> I see, thanks!
2025-07-06 14:34:06 <pj> and they are created only for security patches
2025-07-06 15:13:45 <achill> <pj> and they are created only for security patches
2025-07-06 15:13:45 <achill> on the very base package set e.g. preinstalled on a docker image
2025-07-06 15:13:53 <achill> or for the ISOs
2025-07-06 15:14:18 <achill> thats basically the only reason the the minor releases, so they get rebuild with security fixes.
2025-07-06 15:54:44 <Saijin_Naib[m]> If I want to upgrade vtk and enable more build options, drop some unneeded patches, and drop the largedata archive, do I need to submit in the same MR bumps for freecad and other things that depend upon vtk, or does the builder automatically bump them?
2025-07-06 15:55:11 <Saijin_Naib[m]> I'm working with one of the main devs of vtk to get our package current so I can package F3D and Exhibit 3D model viewers
2025-07-06 16:00:25 <achill> yeah you need to bump the pkgrel of the packages linking against vtk's libs in the same MR
2025-07-06 16:04:15 <Saijin_Naib[m]> mmm, okay. And in pkgs.alpinelinux.org for VTK under the field that shows required by, that covers all of the ones I need to hit?
2025-07-06 16:16:07 <achill> in this case, yeah. basically only freecad, opencascade. and in testing, gdcm and pcl
2025-07-06 16:17:26 <achill> for packages in testing/ its fine if the rebuild is delayed e.g. in another MR, i think gdcm is currently broken because i forgor
2025-07-07 06:04:57 <Saijin_Naib[m]> How do I add reviewers/assignees for the packages affected by a package bump I'm doing?
2025-07-07 06:05:07 <Saijin_Naib[m]> Do I just at them if I know their handle?
2025-07-07 06:05:17 <Saijin_Naib[m]> !86759
2025-07-07 06:06:29 <Saijin_Naib[m]> holy, that s390x runner is fast
2025-07-07 06:18:25 <ikke> Saijin_Naib[m]: you'd have to ping them
2025-07-07 06:51:59 <Saijin_Naib[m]> that will be a challenge, I don't know any of them, haha
2025-07-07 06:55:48 <Saijin_Naib[m]> I can't find maintainers @ on gitlab for freecad and pcl
2025-07-07 06:55:54 <Saijin_Naib[m]> pinged the other two
2025-07-07 07:26:32 <Saijin_Naib[m]> maribudo you have a chance to look at bumping mangohud? It does not seem to work for me locally, and bumping to v0.8.1 fails because meson complains that vulkan-headers is not buildable
2025-07-07 07:30:15 <maribu> I sadly do not have the time right now to look into it. I wonder why it was not flagged out of date. https://release-monitoring.org/project/138139/ does display that 0.8.1 is the most recent version and Alpine is shown in there
2025-07-07 07:38:30 <Saijin_Naib[m]> I just added the mapping a few minutes ago when I attempted to build ir
2025-07-07 07:38:53 <Saijin_Naib[m]> I try and make sure any aport I touch has a mapping
2025-07-07 07:57:33 <maribu> Thanks for doing that. Getting a mail when packages are in need of updates is really helpful :)
2025-07-07 09:18:59 <ncopa> i'm merging the llvm split from llvm20. the symlinks for default llvm is now in a separate subpackage
2025-07-07 09:19:11 <ncopa> sorry a separate package/APKBUILD
2025-07-07 10:04:38 <achill> nice
2025-07-07 14:18:50 <Saijin_Naib[m]> @maribu its the least I can do if the package is too difficult for me to help with
2025-07-07 18:23:05 <angeloverlain[m]> Hello everyone! I wish to work towards adding support to alpine for initramfs hooks (like arch, postmarketos, systemd), so we may be able to have nice things like automatically decrypting devices with TPM using clevis, having a nice splash screen with plymouth or even having a touch screen input for unlocking encrypted LUKS devices with unl0kr. I will be showing my progress here, and if you like you can point me to any
2025-07-07 18:23:05 <angeloverlain[m]> resources that may be useful. thanks :)
2025-07-07 18:24:16 <ikke> angeloverlain[m]: I suppose it may be a good idea to discuss this with the maintainer (ncopa) so that your ideas align with his
2025-07-07 18:24:46 <angeloverlain[m]> okay sure. how may I contact him? I hear he's a busy person
2025-07-07 18:25:16 <ikke> He responds here, mainly during CE(S)T working hours
2025-07-07 18:25:43 <ikke> One thing that would be very welcome is to improve the current test suite
2025-07-07 18:26:08 <ikke> Which is what would help gaining confidence in accepting changes
2025-07-07 18:26:09 <angeloverlain[m]> anyway, a bit of background with this, I wanted to just add support for clevis (https://wiki.alpinelinux.org/wiki/User:Vixalien/Clevis) and plymouth (WIP), but I figured having something extendable would be nicer.
2025-07-07 18:26:22 <angeloverlain[m]> ikke: okay. maybe they shall see this tomorrow.
2025-07-07 18:27:00 <angeloverlain[m]> about the test suite, I will definitely work on them, but currently I have not looked into how the current testsuite in mkinitfs is...
2025-07-07 18:27:35 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/tests/initramfs-init.test
2025-07-07 18:28:17 <ikke> Basically a lot of mocking and verifying initramfs-init does the right thing
2025-07-07 18:32:11 <angeloverlain[m]> I will look at them tomorrow, thanks! I wonder what needs improvement in the test suite
2025-07-07 19:01:34 <Saijin_Naib[m]> @angeloverlain that all sounds great! 
2025-07-07 19:01:56 <angeloverlain[m]> Saijin_Naib: thanks!
2025-07-07 19:07:33 <realroot[m]> nice! now alpine somehow supports dracut now i think cause it's in repo
2025-07-08 07:34:36 <Saijin_Naib[m]> If anyone gets a chance, !86799 would be nice for the vtk upgrade
2025-07-08 09:28:57 <tw_> The clang-doc package seems to be broken seeing as I cannot install it on edge with apk3
2025-07-08 09:29:23 <tw_> The package manager cannot even find it despite it being in the repos
2025-07-08 10:24:45 <ikke> tw
2025-07-08 10:24:51 <ikke> They just left
2025-07-08 18:14:13 <nusgul[m]> Hello, i've setup an aports folder in my abuild user home directory, copied .rootbld-repositories into the aports/mirror folder. I've then cloned a package folder into this mirror folder and attempted abuild-rootbld. However the chroot is unable to download the dependencies
2025-07-08 18:14:51 <nusgul[m]> s/abuild-rootbld/abuild rootbld
2025-07-08 19:10:55 <ikke> nusgul[m]: what error message do you get?
2025-07-08 20:02:51 <realroot[m]> I am trying to package rocm for ollama and maybe more?
2025-07-08 20:02:51 <realroot[m]> >I think the binaries that use libraries from /opt/rocm/lib should just have that path in their rpath. Putting it somewhere else means all binaries will try to load libraries from that directory. Depending on the contents of /opt/rocm/lib they could also rust be moved to /usr/lib
2025-07-08 20:02:51 <realroot[m]> first one is https://gitlab.archlinux.org/archlinux/packaging/packages/rocm-core/-/blob/main/PKGBUILD I think
2025-07-08 20:03:34 <realroot[m]> `install -Dm644 rocm-ld.conf "$pkgdir/etc/ld.so.conf.d/rocm.conf"` how solve that?
2025-07-08 20:12:34 <Ariadne> is rocm even open source?
2025-07-08 20:12:59 <Ariadne> huh.  i guess it is
2025-07-08 20:18:10 <nusgul[m]> ikke: Error: unable to select packages: it then list all the dependencies with (no such packages)
2025-07-08 20:18:39 <nusgul[m]> and finally `>> ERROR: my_awesome_package: rootbld failed`
2025-07-08 20:19:18 <nusgul[m]> I tried to use -v but no more insight.
2025-07-08 20:31:38 <ikke> nusgul[m]: what is the contents of the .rootbld-repositories file?
2025-07-08 20:38:28 <nusgul[m]> ikke: thanks for asking me this question. I miscopied the "$mirror/$version/main"
2025-07-08 20:38:40 <nusgul[m]> It works now
2025-07-08 20:41:31 <p_6f3Ik7Suw>  realroot[m] i don't think that those files are needed on musl-based linuxen
2025-07-08 20:44:12 <Ariadne> they are.  musl still has a configured search path
2025-07-08 20:45:06 <Ariadne> but using /opt for this purpose violates alpine packaging policy and abuild will warn loudly about it
2025-07-08 20:52:46 <p_6f3Ik7Suw> where and how is the ld search path set on musl?
2025-07-08 20:52:50 <p_6f3Ik7Suw> TIL
2025-07-09 00:42:43 <Saijin_Naib[m]> Sorry for the builder churn on the vtk upgrade, but building it takes many hours locally and I'm playing whack-a-mole with trying to update it
2025-07-09 05:24:55 <Saijin_Naib[m]> maribu, do you think you can tackle bumping OpenCascade to 7.9.1? It is broken currently when being rebuilt as it complains about cmake version, and that is putting a wrench in my vtk upgrade
2025-07-09 05:25:16 <Saijin_Naib[m]> I tried locally, and it looks non-trivial as some of the patches didn't apply cleanly
2025-07-09 05:25:33 <Saijin_Naib[m]> But, it would be a huge help for my vtk update
2025-07-09 05:45:20 <maribu> OpenCascade is a bit of a pain in the ass to update. I will soonest be able to look this weekend, sadly.
2025-07-09 05:58:05 <Saijin_Naib[m]> Yeah, totally understandable. I'm hoping to fix all the other vtk issues outside of that before then
2025-07-09 05:59:00 <realroot[m]> <p_6f3Ik7Suw> "where and how is the ld search..." <- https://wiki.musl-libc.org/faq#Q:-Where-is-%3Ccode%3Eldconfig%3C/code%3E?
2025-07-09 05:59:47 <realroot[m]> do I make apk hook that append to file /opt/rocm?
2025-07-09 06:01:25 <realroot[m]> "/opt/rocm/" not sure now
2025-07-09 06:02:00 <realroot[m]> file is /etc/ld-musl-$ARCH.path
2025-07-09 09:39:47 <aparcar[m]> hello, I'd like to setup a new builder similar to https://build.alpinelinux.org but for a different architecture. is there some documentation available? I only find find the bootstrap.sh from aport, however I'd be curious to know about this active service
2025-07-09 09:42:52 <aparcar[m]> speking of it, i found it, sorry for the noise https://gitlab.alpinelinux.org/alpine/infra/docker/aports-build
2025-07-09 10:01:04 <ncopa> I wonder if we have anyone who can help follow up the osinfo-db for alpine?
2025-07-09 10:01:08 <ncopa> https://gitlab.com/libosinfo/osinfo-db/-/issues/180
2025-07-09 10:01:13 <ncopa> we also need add alpine 3.22
2025-07-09 12:31:55 <jvvv> ncopa: https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/840 ?
2025-07-09 12:32:54 <jvvv> i realize that only covers the latter and not the former
2025-07-09 12:50:37 <ncopa> ok. we only need to wait for a release tag. annoying
2025-07-09 13:41:13 <jvvv> ncopa: i'm familiarizing myself with libosinfo and am logged in there... will submit an mr to update the relavent versions asap
2025-07-09 15:27:41 <ncopa> thanks!
2025-07-09 15:31:45 <ncopa> incus edge image build fails now. I think it may be related apk3: https://jenkins.linuxcontainers.org/job/image-alpine/lastFailedBuild/architecture=amd64,release=edge,variant=default/console
2025-07-09 15:32:57 <ncopa> can be reproduced: docker run alpine:edge sh -c "apk upgrade -U -a; apk add linux-virt grub"
2025-07-09 15:33:48 <ncopa> with 3.22 it exited with success (0)
2025-07-09 15:34:01 <ncopa> i think we may need to fix the trigger script
2025-07-09 15:47:45 <dne> anyone up for merging !85261 and !85260? simple version bumps, ready to merge for ~1 month
2025-07-09 16:07:40 <dne> thanks ikke :)
2025-07-09 19:58:42 <candrews> Can someone please take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85220 community/npm: upgrade to 11.4.1 ? It's been patiently waiting for over a month.
2025-07-09 20:21:29 <f_> hi, anyone tried packaging torbrowser-launcher?
2025-07-09 20:22:11 <abby> it won't work on musl
2025-07-09 20:22:25 <f_> huh
2025-07-09 20:22:27 <f_> oh right
2025-07-09 20:22:33 <abby> part of the point of it is using the same binary as everyone else, which is compiled against glibc
2025-07-09 20:22:33 <f_> the binaries it downloads are glibc
2025-07-09 20:49:54 <Ermine> gcompat ftw
2025-07-09 20:50:11 <f_> For now I installed it from flatpak
2025-07-09 20:51:14 <Ermine> (you kind of can have your own binary, but they argue against it for privacy reasons)
2025-07-09 21:48:20 <Wyk72> hello ppl
2025-07-09 21:49:38 <Wyk72> I have to report a nasty regression with a freshly updated Alpine 3.22: pci-passtrough via VFIO-PCI to QEMU  stopped working on ALL my servers
2025-07-09 21:49:58 <Wyk72> kernel 6.12.36-0-lts
2025-07-09 21:50:24 <Wyk72> used to pass realtek NICs to virtual OpenWRT istances
2025-07-09 21:50:43 <Wyk72> worked fine, tonight I upgraded to latest-stable 
2025-07-09 21:51:27 <Wyk72> and in the virtual machines NICs segfaulted with TX timeout
2025-07-09 21:52:37 <Wyk72> I had to pass the NICs via a software bridge instead, but it's far from optimal
2025-07-09 21:55:41 <Wyk72> dmesg reports a lot of these errors:
2025-07-09 21:55:42 <Wyk72> rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100)
2025-07-09 21:55:58 <Wyk72> and segfaults (into the virtual machine)
2025-07-10 01:02:32 <qaqland> hi, i test !86577 locally, it works well
2025-07-10 01:06:17 <qaqland> i'm planning to bring over some tools from debian :)
2025-07-10 02:46:05 <Ariadne> what tools and why
2025-07-10 02:47:32 <Ariadne> isn’t debootstrap already packaged
2025-07-10 04:46:45 <qaqland> Ariadne: there are mmdebstrap, sbuild and so on. i would test them one by one
2025-07-10 04:50:04 <qaqland> why: want to create deb packages on my daily used system
2025-07-10 06:01:26 <Ariadne> why not use a container for that purpose?
2025-07-10 06:22:20 <quinq> Put a whole computer in your computer!
2025-07-10 06:28:25 <ncopa> thats the thing with containers. you only put the apps part there, and share the kernel with host
2025-07-10 06:32:49 <quinq> So whole user space, and only share the kernel
2025-07-10 06:33:24 <lotheac> and that sometimes fails when your host kernel is ancient enough for your radically new userland ,)
2025-07-10 06:49:49 <pj> but for building packages for a system that uses completely different libc it should be fine
2025-07-10 06:49:50 <pj> or so I've heard
2025-07-10 06:56:09 <Ermine> so far i failed to run pbuilder successfully in a container
2025-07-10 06:58:41 <pj> giving more caps probably would help
2025-07-10 06:59:27 <pj> You want to run fully privileged chroot
2025-07-10 07:17:27 <lotheac> right, don't get me wrong, containers are immensely useful
2025-07-10 07:23:31 <ikke> Alpine is completely built inside containers 
2025-07-10 11:46:54 <qaqland> for building package, chroot == container (?)
2025-07-10 11:50:17 <lotheac> maybe in some simple cases things might work in both chroot and container, but they're very different concepts and there's tons of differences
2025-07-10 14:00:18 <user0> hi, could somebody add the aports:add tag to !86822? thanks!
2025-07-10 14:03:01 <user0> also, why is the pipeline taking so long for s390x
2025-07-10 14:06:23 <ikke> There's some long-running CI jobs
2025-07-10 14:13:03 <user0> ah
2025-07-10 17:52:12 <jvvv> ncopa: i submitted https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/846 yesterday ... waiting on approval
2025-07-10 18:03:44 <ncopa> jvvv: Thank you!
2025-07-11 06:49:52 <Saijin_Naib[m]> Thanks for the review & merge, mio
2025-07-11 07:55:08 <raspbeguy> Hello, can someone have a look at !86918 please?
2025-07-11 11:53:19 <caskd> I'm soon about to be able to give public access to my rsync alpine pkg mirror, but i don't think the performance would be great... Should i publicly advertise it or would it be a bad idea? (GW would be hosted at hetzner but the storage would be hosted at my home which unfortunately has only 50Mb upload)
2025-07-11 12:41:13 <mio> Saijin_Naib[m]: you're welcome!
2025-07-11 16:36:31 <Ariadne> caskd: i would not recommend this, tbh
2025-07-11 20:13:28 <caskd> okay
2025-07-11 20:13:33 <caskd> yeah, just wondering
2025-07-11 20:13:50 <caskd> i've been keeping a offline mirror just in case as i have a lot of hosts locally
2025-07-12 02:24:32 <worldhacker> hi all
2025-07-12 11:21:12 <aparcar[m]> hi again, can i use abuild but bring my own toolchain? ideally i don't rely on bootstrap.sh?
2025-07-12 12:01:24 <sertonix[m]> Yes you can. You might need to set some environment variables depending on your toolchain
2025-07-12 12:23:17 <aparcar[m]> Sertonix: i tried it a bunch but keep on running into abuild complaining that some meta packages are not available. could you kindly give me some pointers?
2025-07-12 12:23:31 <aparcar[m]> Sertonix: spoiler, i want to use the openwrt toolchain
2025-07-12 12:24:55 <ikke> aparcar[m]: do you have example of what abuild complains about?
2025-07-12 12:26:14 <aparcar[m]> ikke:   build-base-mips (no such package):
2025-07-12 12:26:37 <aparcar[m]> from my understanding I want to supply this build-base by bringin by own toolchain?
2025-07-12 12:26:59 <ikke> ah, you're cross-compiling
2025-07-12 12:27:34 <ikke> aparcar[m]: can you try to set BOOTSTRAP=no?
2025-07-12 12:27:43 <aparcar[m]> oh yea sure, we support to many archs to do it all native
2025-07-12 12:27:50 <ikke> aparcar[m]: yeah, that's understood
2025-07-12 12:28:42 <aparcar[m]> mips-alpine-linux-musl-mips-openwrt-linux-musl-gcc  -Wall -W -O2 --sysroot=/home/builduser/sysroot-mips/ -Os -fstack-clash-protection -Wformat -Werror=format-security -c -o buffer.o buffer.c
2025-07-12 12:28:47 <aparcar[m]> seems like I'm getting somewhere... wild
2025-07-12 12:29:01 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2431
2025-07-12 12:29:09 <aparcar[m]> this is my current env https://gist.github.com/aparcar/499d777a75467d9730ab02f32783ffac
2025-07-12 12:31:17 <aparcar[m]> i guess /usr/share/abuild/functions.sh is not happy with my env
2025-07-12 12:34:09 <aparcar[m]> oh it should be CTARGET not CHOST, working on it... 
2025-07-12 12:35:48 <sertonix[m]> You can disable abuild's dependency handling by using -d. For regular cross compiling you want to set CBUILD and CHOST (not CTARGET)
2025-07-12 12:36:50 <aparcar[m]> so CBUILD=mips and CHOST=mips is already ok?
2025-07-12 12:36:53 <sertonix[m]> You probably want to set CROSS_PREFIX to disable abuilds logic for that
2025-07-12 12:38:01 <sertonix[m]> I would recommend using full triplets in your case. Otherwise it should work
2025-07-12 12:39:18 <sertonix[m]> The default logic (when CROSS_PREFIX isn't set) is to prepend the CHOST triplet to the toolchain (only CC and CXX, others are not handled by abuild)
2025-07-12 12:44:34 <aparcar[m]> okay getting there... 
2025-07-12 12:44:34 <aparcar[m]> >>> ed*: Tracing dependencies...
2025-07-12 12:44:34 <aparcar[m]> ERROR: /lib/ld-musl-aarch64.so.1: Could not find owner package
2025-07-12 12:45:12 <aparcar[m]> so ed-doc is already created, big win. the ed package itself is compiled but then the lib check fails
2025-07-12 12:45:46 <sertonix[m]> If you don't want abuild's dependency tracing you can add options="!tracedeps" (or similar, check the APKBUILD man page)
2025-07-12 12:46:40 <sertonix[m]> abuild's dependency tracing requires a sysroot managed by apk-tools in case you wan't the dependency tracing
2025-07-12 12:47:38 <aparcar[m]> mhh good question. I guess i do want that. so that means i need to modify bootstrap.sh to work with my custom toolchains?
2025-07-12 12:49:53 <Sheila> yes. bootstrap.sh is necessary if you want to create a new toolchain managed by apk, and it needs to get you to the point where you can build your toolchain with itself.
2025-07-12 12:50:21 <sertonix[m]> You don't have to use bootstrap.sh. In this case you need to build an apk package for musl and then do something like echo $PWD/packages > sysroot/etc/apk/repositories && apk add --root sysroot/ --initdb musl
2025-07-12 12:52:45 <aparcar[m]> long story short, I want to check alternatives for openwrt package building. we support more archs then alpine, so i figured to take the existing openwrt toolchain but use abuild to generate those packages. converting openwrt package makefile to apkbuild is straight forward'ish. the missing bit is teach abuild using my openwt toolchain
2025-07-12 12:53:18 <aparcar[m]> so if modifying bootstrap.sh to create the special openwrt toolchains I'll look into that
2025-07-12 12:53:52 <aparcar[m]> if passing triplets if fine, great. ideally the lib tracking works, though
2025-07-12 12:54:22 <sertonix[m]> I see. Note that tooling around abuild is in my opinion worse when it comes to orchestrating multiple builds. I plan to fix that some day
2025-07-12 12:54:46 <aparcar[m]> multiple builds as in multiple versions of the same package?
2025-07-12 12:56:15 <aparcar[m]> with options="!tracedeps" the ed package builds just fine, nice :)
2025-07-12 12:56:16 <sertonix[m]> I mean things like "I wan't to build X, please build all recurisive makedepends yourself". Not sure about multiple versions
2025-07-12 12:57:54 <aparcar[m]> okay that seems to be a bit of a similar problem as what we have. right now openwrt rebuilds $world aka all packages once a day. i'd prefer some smarter tracking, your mqtt setup looks much nicer
2025-07-12 12:58:13 <aparcar[m]> however if it breaks due to ABI changes etc...?
2025-07-12 12:59:15 <sertonix[m]> We rely on upstream soname changes + manual pkgrel bumps to handle ABI changes.
2025-07-12 13:00:57 <aparcar[m]> okay that sound fine to me
2025-07-12 13:01:20 <aparcar[m]> could you kindly give me a recommendation how to proceed?
2025-07-12 13:10:31 <sertonix[m]> Maybe an issue on the abuild or openwrt repo would be useful for further discussions on this? abuild cross compiling isn't really documented but I can answer questions about it. I think abuild might be able to benefit from some cross compiling experience of openwrt. Feel free to ping me in any related discussion!
2025-07-12 13:31:43 <aparcar[m]> Sertonix: btw, abuild does APK v2 right?
2025-07-12 13:34:10 <aparcar[m]> Sertonix: https://github.com/openwrt/openwrt/issues/19386
2025-07-12 16:48:45 <realroot[m]> how do this in apk? `source=("git+https://github.com/jaraco/${_pkgname}.git#tag=v${pkgver}")` it needs that the archive won't work
2025-07-12 16:49:03 <realroot[m]> "missing metadata"
2025-07-12 16:50:54 <ikke> abuild does not support that
2025-07-12 16:51:04 <Sheila> what you actually want is `giturl` and related functionality
2025-07-12 16:51:21 <ikke> aparcar[m]: abuild indeed still builds apkv2 packages
2025-07-12 16:52:04 <realroot[m]> gitulr is not in repo it seems
2025-07-12 16:52:25 <realroot[m]> if you have do fetch that file is there a way with abuild?
2025-07-12 16:52:36 <Sheila> no, you set `giturl="whatever" reporev="whatever"` in APKBUILD and use `abuild snapshot`
2025-07-12 16:52:36 <realroot[m]> *to
2025-07-12 16:53:19 <Sheila> > This abuild hook will checkout an svn or git repository by specifying $giturl in APKBUILD. You can checkout a specific branch in git by adding -b $branch in $giturl. $reporev will select the correct commit, revision or tag for you. If you specify $disturl your distfile will automatically be uploaded with rsync to the url provided. Base version defaults to 0 except if specified
2025-07-12 16:53:21 <Sheila> by $verbase.
2025-07-12 16:53:32 <Sheila> (from a comment in `abuild` script)
2025-07-12 16:53:57 <ikke> It's just automation around cloning, creating an archive and uploading that somewhere else
2025-07-12 16:54:07 <ikke> but github already provides archives, so you can directly refer to that
2025-07-12 16:54:29 <ikke> https://github.com/jaraco/keyring/archive/refs/tags/v25.6.0.tar.gz for example
2025-07-12 16:55:11 <realroot[m]> https://github.com/jaraco/configparser
2025-07-12 16:55:18 <realroot[m]> pkgver=7.2.0
2025-07-12 16:55:31 <ikke> https://github.com/jaraco/configparser/archive/refs/tags/v7.2.0.tar.gz
2025-07-12 16:55:35 <ikke> https://github.com/jaraco/configparser/releases/tag/v7.2.0
2025-07-12 16:55:48 <realroot[m]> I tried the latter and the commit
2025-07-12 16:56:41 <Sheila> use the tarball; newapkbuild is smart and will do the needful.
2025-07-12 17:02:51 <realroot[m]> first does not work too
2025-07-12 17:02:58 <realroot[m]> >Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
2025-07-12 17:03:34 <realroot[m]> for some reason apk does not extract it and i have to do it manually
2025-07-12 17:04:02 <realroot[m]> >For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
2025-07-12 17:07:17 <realroot[m]> 
ACTION ran git clone in build()

2025-07-12 17:08:41 <realroot[m]> is newapkbuild apk v3? I am running stable
2025-07-12 17:26:10 <achill> newapkbuild has nothing todo with apk
2025-07-12 18:58:40 <realroot[m]> 
ACTION sent a code block: https://matrix.org/oftc/media/v1/media/download/ASR3BlD5fndHfY0MHJsPI6rardyUqO2NfsWtVDpbwE7eDcHFBZjhEH-BALtT3l58tGGWQGxS6iICC-i_T3agrOdCeYSBoAbgAG1hdHJpeC5vcmcvaWJBbUFKVm5tSGVBYVhyeXpGRGNsQ3Fn

2025-07-12 18:59:42 <realroot[m]> copy ruinded the 1st line is `...="https://github.com/jaraco/configparser.git"`
2025-07-12 19:15:39 <realroot[m]> https://paste.trom.tf/wakekuxane.js
2025-07-12 19:15:45 <realroot[m]> do I use /usr/share ?
2025-07-12 19:16:30 <Sheila> --prefix=/usr
2025-07-12 19:20:20 <realroot[m]> it will install in /usr/lib LICENSE and all
2025-07-12 19:20:35 <realroot[m]> --prefix=/usr/share/rocm maybe ?
2025-07-12 19:22:00 <Ermine> then it will install *everything* into /usr/share/rocm/*
2025-07-12 19:23:23 <realroot[m]> sorry i misread it
2025-07-12 19:24:18 <realroot[m]> -- Installing: /rocm-core/pkg/rocm-core/usr/.info/version
2025-07-12 19:24:25 <realroot[m]> that one looks odd
2025-07-12 19:25:00 <realroot[m]> https://paste.trom.tf/valoqodoba.js
2025-07-12 19:28:35 <realroot[m]> how execute "apk hook" to append text to `/etc/ld-musl-$ARCH.path` ?
2025-07-12 19:30:20 <Sheila> you shouldn't need to.
2025-07-12 19:30:50 <realroot[m]> will musl find "/usr/rocm/lib" automatically for rocm so?
2025-07-12 19:31:07 <Ermine> no
2025-07-12 19:31:07 <Sheila> you should not be using --prefix=/usr/rocm.
2025-07-12 19:31:32 <realroot[m]> I used --prefix=/usr as you said, i misread it sorry
2025-07-12 19:32:05 <Ermine> try --libdir=/usr/lib
2025-07-12 19:32:20 <Sheila> anyway, you should have a line `rm -r "$pkgdir"/usr/.info` in `package()`.
2025-07-12 19:33:29 <realroot[m]> Ermine is for https://wiki.musl-libc.org/faq#Q:-Where-is-%3Ccode%3Eldconfig%3C/code%3E?
2025-07-12 19:34:54 <Ermine> You shouldn't mess with this file
2025-07-12 19:35:35 <Ermine> packages should install libs in /usr/lib, where musl will find it by default
2025-07-12 19:36:04 <Ermine> /etc/ld-musl-$ARCH.path is for users
2025-07-12 19:38:04 <realroot[m]> ah. "$pkgdir/etc/profile.d/rocm.sh":... (full message at <https://matrix.org/oftc/media/v1/media/download/AbYr5Bpc4nW-8IO6eib4vPeuGXHWgLFbjTs_r7UgPeL3njlv-dDXeXxk7uVS9Vf80ywScVeLwctOJL2VFmywM-5CeYSD4T9QAG1hdHJpeC5vcmcvaHRFTW90d3lTclR1bXFzTHl5a3VSbUpi>)
2025-07-12 19:39:04 <Ermine> Once again, /usr/rocm is incorrect path and nothing should be installed there
2025-07-12 19:40:41 <realroot[m]> that file is generated by cmake --install build --prefix=/usr
2025-07-12 19:41:30 <realroot[m]> i am not sure if it is needed
2025-07-12 19:42:57 <realroot[m]> let me check
2025-07-12 19:43:24 <realroot[m]> sorry it's external https://gitlab.archlinux.org/archlinux/packaging/packages/rocm-core/-/tree/main
2025-07-12 19:43:39 <realroot[m]> is it needed here?
2025-07-12 19:57:37 <Ermine> it's not needed
2025-07-12 19:58:00 <Ermine> they install to /opt because it's not an official arch linux package
2025-07-12 19:58:31 <Ermine> you need to figure out how to make it install files in appropriate locations
2025-07-12 19:59:38 <realroot[m]> i guess moving them
2025-07-12 19:59:38 <realroot[m]> https://gitlab.archlinux.org/archlinux/packaging/packages/rocm-cmake/-/blame/main/PKGBUILD#L51 `/usr/rocm` here?
2025-07-12 20:00:49 <Ermine> You need -D CMAKE_INSTALL_PREFIX=/usr
2025-07-13 06:53:48 <realroot[m]> SPAM/SCAM ^
2025-07-13 06:58:46 <realroot[m]> do I move /usr/.share in /usr/share ?  https://paste.trom.tf/numagexixe.lua
2025-07-13 08:42:52 <f_> realroot[m]: ?????? I don't see any spam
2025-07-13 08:44:42 <Ermine> f_: it was on matrix probably
2025-07-13 08:44:59 <f_> oh well
2025-07-13 09:09:23 <achill> <realroot[m]> do I move /usr/.share in /usr/share ?  https://paste.trom.tf/numagexixe.lua
2025-07-13 09:09:23 <achill> you misred its /usr/./share which is /usr/share
2025-07-13 09:47:12 <realroot[m]> oh thanks!
2025-07-13 09:57:57 <realroot[m]> pj
2025-07-13 09:58:12 <realroot[m]> ikke
2025-07-13 14:37:48 <achill> ncopa: fyi https://github.com/torvalds/linux/commit/a95743b53031b015e8949e845a9f6fdfb2656347 finally landed and greg is already backporting it to the stable trees
2025-07-13 17:32:35 <achill> sertonix[m] <https://matrix.to/#/%40oftc_sertonix%5Bm%5D%3Apostmarketos.org>: i guess it makes sense to rebuild all go packages on riscv64 and s390x now again right?
2025-07-13 19:47:08 <sertonix[m]> In my opiniom it only makes sense to revert the changes that disabled pie in some cases. All go packages will be rebuild on the next go upgrade anyways.
2025-07-13 19:51:38 <achill> makes sense
2025-07-13 19:51:55 <achill> especially for go, i dont feel like blocking the builder for another few days
2025-07-13 19:57:52 <sertonix[m]> Regarding blocking builders, loongarch64 builder hasn't uploaded any packages for a long time
2025-07-13 19:58:19 <sertonix[m]> cause of qt6-qtwebengine failing all the time
2025-07-13 20:02:05 <ikke> DWanhao said he would look into it
2025-07-13 20:02:38 <hjaekel> Is qt6-qtbase for armhf, armv7, loongarch64 and riscv64 stuck somewhere in the builders?
2025-07-13 20:07:15 <achill> <sertonix[m]> cause of qt6-qtwebengine failing all the time
2025-07-13 20:07:15 <achill> maybe it makes sense to disable it for the time being?
2025-07-13 20:13:30 <ikke> In about 15 minutes gitlab will be upgraded to 18.0 and will be offline for a couple of minutes
2025-07-13 20:15:02 <achill> ack
2025-07-13 20:17:31 <achill> also i think ruff's tests on riscv64 can just get disabled at this point
2025-07-13 20:17:52 <achill> its not a issue with ruff itself but with the environment
2025-07-13 20:24:11 <ikke> I tried raising ulimits
2025-07-13 20:27:55 <achill> yeah i saw that
2025-07-13 20:30:20 <ikke> Upgrade in progress
2025-07-13 20:42:11 <ikke> gitlab is back :-)
2025-07-14 10:33:25 <ikke> FYI, I enabled the metadata database for our container registry. Let me know if you notice any issues
2025-07-14 12:09:34 <Kladky> I think there needs to be a policy for how long a package maintainer has to respond to an MR before they can be ignored, to prevent stuff like !72313 being open for 9 months...
2025-07-14 12:11:19 <Kladky> Or just a policy for being stripped of maintainership of a package, e.g. if they don't respond to a bump MR within a week or something
2025-07-14 12:15:51 <achill> yeah it needs some clarification what maintainership actually means
2025-07-14 12:16:49 <achill> you dont hold ownership over it, but youre responsible to keeping it up to date and if it breaks
2025-07-14 12:17:19 <achill> 1 week of no response sounds reasonable
2025-07-14 12:17:57 <achill> Kladky: would you like to bring that as a issue to the TSC so this doesnt get lost in the chat?
2025-07-14 12:18:22 <Kladky> Sure :D
2025-07-14 12:20:21 <achill> thanks
2025-07-14 12:23:10 <Kladky> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/96
2025-07-14 12:23:13 <Kladky> achill: 
2025-07-14 12:37:57 <Kladky> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87175#note_525123 :thinking:
2025-07-14 12:40:01 <Sheila> what is there to think about? changing maintainership should be discussed with existing maintainer.
2025-07-14 12:40:27 <Kladky> The existing maintainer wasn't able to keep the package up to date, even when it was trivial
2025-07-14 12:40:35 <Kladky> to upgrade
2025-07-14 12:40:56 <Kladky> and the latest release was over a month ago
2025-07-14 12:41:22 <Sheila> entirely irrelevant.
2025-07-14 12:42:00 <Kladky> I don't know about you, but as someone who maintains software which is packaged in distros, it's very frustraiting that they often take very long to update, even when the update itself is trivial
2025-07-14 12:43:09 <Ermine> > but youre responsible to keeping it up to date --- so what if someone else ends up updating it? 
2025-07-14 12:43:41 <achill> i think if someone else who has more time to dedicate package maintainership then the current maintainer, its safe to move maintainership over. since again, you dont own it.
2025-07-14 12:43:44 <Sheila> as a package maintainer, I assure you that it is *not important* who actually performs the updates. there is no reason to change maintainership of a package merely because the listed maintainer hasn't updated it in a while.
2025-07-14 12:44:18 <skarnet> it's just good practice to check with the maintainer for approval of the changes, but then again if the maintainer doesn't answer timely... oh well
2025-07-14 12:44:41 <Kladky> It needlessly delays the package being updated, since the general policy is that the package maintainer has to approve every change, even when it's trivial
2025-07-14 12:45:05 <Sheila> there can be reasons for the listed maintainer to not be doing the work, e.g. I have executive dysfunction issues.
2025-07-14 12:45:16 <Sheila> or they're dealing with personal crises. or whatever.
2025-07-14 12:45:30 <Kladky> then why not let someone else maintain it then?
2025-07-14 12:45:41 <Sheila> that is why you *talk to them* first.
2025-07-14 12:45:42 <achill> Sheila: and thats fine, we all have a life, but then it should be fine for someone else to take over
2025-07-14 12:45:48 <achill> sure
2025-07-14 12:45:59 <Kladky> I mean, look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87177#note_525129
2025-07-14 12:46:40 <Sheila> that conversation started *after* the attempt to yank maintainership away.
2025-07-14 12:46:41 <Kladky> The say they are too busy to keep the package up to date, even when the release was weeks ago, but then turn around and refuse to allow someone else to do it for them
2025-07-14 12:47:00 <Sheila> you can update people's packages without claiming maintainership. people do it regularly.
2025-07-14 12:47:21 <Sheila> why do you care that your name is on the package so much? is it not enough that it's being updated?
2025-07-14 12:47:22 <Kladky> Sheila: yes, because at least of recently, I have observed Jakub Jirutka has been very slow to respond to messages
2025-07-14 12:47:38 <achill> yeah its not the first time
2025-07-14 12:47:45 <Kladky> I don't care if it has my name or not, I just want to have packages as up-to-date as possible
2025-07-14 12:48:03 <Sheila> then it shouldn't be a problem to just leave maintainership alone.
2025-07-14 12:48:25 <Kladky> When I don't, it means that updates have to wait on that maintainer that is slow to respond
2025-07-14 12:48:31 <Kladky> That's why i take over maintainership
2025-07-14 12:48:37 <Kladky> Not to have my name on it
2025-07-14 12:48:54 <Sheila> that conversation needs to happen separately from a package bump.
2025-07-14 12:49:09 <achill> waiting weeks or so for upgrades is really fine, but if you cant rely on it getting upgraded it can get really annoying to deal with
2025-07-14 12:49:34 <Kladky> The reason I do it with the package update is that it's the motivation for taking over maintainership in the first place.
2025-07-14 12:50:47 <Sheila> you still don't have a right to just yoink maintainership.
2025-07-14 12:50:59 <Kladky> Why not?
2025-07-14 12:51:11 <Kladky> It's a privlidge
2025-07-14 12:51:23 <Kladky> Not something you should have just because you were there first
2025-07-14 12:51:24 <skarnet> no, it's a responsibility
2025-07-14 12:51:30 <Kladky> That too
2025-07-14 12:51:40 <skarnet> because every package has its way of doing things and the maintainer may know things you do not
2025-07-14 12:51:48 <skarnet> in most cases it won't matter, but sometimes it does
2025-07-14 12:52:02 <Kladky> With complicated packages like build tools, sure
2025-07-14 12:52:14 <skarnet> so, yeah, please try to do things in the *collaborative* way, not the confrontational way
2025-07-14 12:52:18 <Kladky> But here we're talking about simple to package cli utilities
2025-07-14 12:52:24 <achill> it has no benefit if the maintainer is basically unreachable
2025-07-14 12:52:35 <skarnet> of course, if after a month you don't get an answer from the maintainer, feel free to update things
2025-07-14 12:52:48 <Sheila> as a maintainer, I am responsible for ensuring that the changes people make to my package won't break it or put users at risk, and it's not something I would want to hand over to someone I don't know and have no experience with merely because I don't have time to do it.
2025-07-14 12:53:21 <Kladky> But here, it seems they have the time to refuse the package takeover, but not the time to actually upgrade the package...
2025-07-14 12:53:37 <skarnet> that's why you talk to them
2025-07-14 12:53:40 <Sheila> you are spending more time arguing about this than it would take to undo that specific change.
2025-07-14 12:53:56 <Kladky> Well I explained why in the comments, but they just didn't care
2025-07-14 12:54:05 <achill> Sheila: its not about this single change
2025-07-14 12:54:26 <Sheila> again, the conversation about maintaining that package needs to happen separately form this update.
2025-07-14 12:54:42 <Kladky> Sheila: I could undo that single change, but that will just continuously lead to the package being needlessly outdated for no real reason
2025-07-14 12:54:58 <Sheila> I am not telling you that you cannot have that conversation.
2025-07-14 12:55:11 <achill> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/?sort=updated_desc&state=opened&assignee_username%5B%5D=jirutka&draft=no&first_page_size=20
2025-07-14 12:55:13 <Sheila> I am telling you that that conversation *should not be blocking the update*.
2025-07-14 12:55:15 <Kladky> Since the maintainer takes very long to respond, but refuses to let someone else take over who is able to respond much more quickly
2025-07-14 12:55:20 <achill> 88 open MRs, im sorry thats just rude
2025-07-14 12:55:54 <Sheila> right, so…have that conversation in a more appropriate venue than the comments section of one particular MR.
2025-07-14 12:56:53 <achill> Sheila: where do you recommend it. jirtuka is not on IRC, and the only way to reach them is per MRs
2025-07-14 12:57:34 <Sheila> I don't actually know; I don't have a leadership role here.
2025-07-14 12:57:52 <achill> we have a good track record of holding open MRs needlessly, and we can change that. we just need more stricter policies
2025-07-14 12:58:24 <Kladky> This could also maybe be helped by allowing multiple package maintainers, like nix does
2025-07-14 12:58:31 <achill> yeah
2025-07-14 12:58:57 <achill> thats also something that could help, but we need to get this into action. so thanks for opening the TSC issue. this has been on my mind for a long while now
2025-07-14 12:59:08 <Sheila> shrug. regardless, forcing a maintainership change in this instance is non-productive.
2025-07-14 13:00:01 <Kladky> And ik you weeks isn't that long achill, but compared to how I usually get bump MRs open within 24 hours of the actual project updating, it's a massive difference
2025-07-14 13:00:33 <Sheila> I don't disagree that someone else should probably take charge of this package, under the circumstances, it's just that the conversation about that needed to happen before that specific change.
2025-07-14 13:00:55 <pj> "that's why you talk to them"
2025-07-14 13:01:17 <pj> if someone doesn't talk for 9 months then they should concede their maintainership over package
2025-07-14 13:01:46 <Kladky> Yes, we can talk in the MR comments. The whole point is that it's a merge **request**. I request this change, and they can discuss it in the comments if they disagree.
2025-07-14 13:02:26 <skarnet> pj: yes. that's what I'm saying.
2025-07-14 13:03:27 <pj> sorry, both you and Sheila appear purple for me here :)
2025-07-14 13:03:38 <Kladky> What's most interesting is that they closed the bump + take over MRs, but I wonder if they will actually cherry-pick the bump commit now, or just ignore it. 🤔
2025-07-14 13:05:21 <ptrc> probably not, see https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87175#note_525135
2025-07-14 13:06:10 <ptrc> imho we should revisit once again what's expected from package maintainers, and how much leeway they should get
2025-07-14 13:06:23 <achill> yea excatly
2025-07-14 13:06:26 <ptrc> we've already had people who disabled linter rules because "it's my package so i can disregard the project coding style"
2025-07-14 13:06:46 <Kladky> And remember the whole helix-tree-sitter fiasco?
2025-07-14 13:07:21 <pj> tbh tree-sitter is a fiasco
2025-07-14 13:07:30 <ptrc> keeping packages broken because it's the "minimal" way to do it... is also an ongoing issue i'd say
2025-07-14 13:08:15 <lotheac> gotta agree on that
2025-07-14 13:08:21 <ptrc> but this means we should improve the processes in Alpine, and not fight with individual maintainers
2025-07-14 13:08:33 <Kladky> 100%
2025-07-14 13:09:04 <ptrc> and it's not productive to open petty MRs with "actually, i'll take this package" :p
2025-07-14 13:09:27 <f_> always talk to the current maintainer before taking over
2025-07-14 13:09:38 <f_> Unless the maintainer has been inactive for 8 months (which was not the case here)
2025-07-14 13:09:49 <ptrc> or, well, it doesn't seem productive to me, because the outcome was somewhat predictable
2025-07-14 13:09:52 <Kladky> Like I said, a merge request is just that, a request
2025-07-14 13:10:08 <f_> I mean, talking to the person before a MR
2025-07-14 13:10:13 <Kladky> Personally, I'd be glad for someone to take over my packages if they can keep them up to date better than me
2025-07-14 13:10:35 <Sheila> an MR should not be the first port of call when you want to take maintainership.
2025-07-14 13:10:36 <pj> it would help if maintainer was on irc (:
2025-07-14 13:10:41 <ptrc> f_: here there's an issue of "you can't really reach the maintainer, except for fedi and *maybe* email
2025-07-14 13:10:52 <f_> with jirutka it's probably a little harder yes because he's not on irc
2025-07-14 13:10:55 <Kladky> Sheila: but why not?
2025-07-14 13:11:15 <f_> any reason why he's not on irc btw? I think I saw him in chatlogs before
2025-07-14 13:11:26 <panekj> doesn't use irc
2025-07-14 13:11:28 <Sheila> because it's an explicit expenditure of resources at the project level?
2025-07-14 13:11:31 <Ermine> what about extending Maintainer: line with additional contact data?
2025-07-14 13:11:43 <achill> Ermine: dont think that helps in this case
2025-07-14 13:11:43 <ptrc> also, iirc we had guidelines that mentioned sending an email to the maintainer as well as CCing the alpine-devel ML
2025-07-14 13:11:54 <ptrc> which was a mess in and of itself
2025-07-14 13:11:58 <Kladky> Sheila: what do you mean by that?
2025-07-14 13:12:30 <ptrc> Ermine: imho a reachable email is good enough for this, though we also have a few emails in aports that are autogenerated GitLab/GitHub ones...
2025-07-14 13:12:31 <Ermine> achill: yeah, it's a digression
2025-07-14 13:12:32 <Sheila> Kladky: every MR kicks off the builders to trybuild your changes.
2025-07-14 13:13:11 <Kladky> I don't think that's the main concern here. I thought it was about being rude or something.
2025-07-14 13:13:12 <panekj> Sheila: it's almost nothing
2025-07-14 13:13:46 <Sheila> it's *also* rude, yes.
2025-07-14 13:14:00 <Kladky> But how is it rude?
2025-07-14 13:14:01 <ptrc> it could be rude to some, i'd say
2025-07-14 13:14:23 <Kladky> I'd rather not maintain any packages personally, it's a burden
2025-07-14 13:14:31 <ptrc> personally i would not find it rude if someone tried to take over a package for me, but with a MR like this, especially considering the previous context, you're implying "you can't take care of your packages"
2025-07-14 13:14:34 <Kladky> But I also want packages I use to be up to date
2025-07-14 13:14:41 <achill> tbh its more rude to keep ~100 MRs open and not merged, because of "basically nothing"
2025-07-14 13:14:57 <ptrc> Kladky: sure, and that's your point of view, but other people can see their packages differently
2025-07-14 13:15:20 <Kladky> ptrc: the reason I add that message is for people who have merge permissions like you can understand the context quickly, and not think it's just taking over for the sake of it
2025-07-14 13:15:34 <Sheila> communication: famously an act involving only one person. (sarcasm)
2025-07-14 13:15:54 <panekj> imo, there's way too much focus on "this is my package, there is no package like this one..." as opposed to "aports is a collective goal of packages in alpine"
2025-07-14 13:16:03 <Kladky> yes
2025-07-14 13:16:03 <achill> panekj: yea exactly
2025-07-14 13:16:12 <Sheila> different people are going to have different opinions regarding their maintainership, and it's simply good practice to talk to them before trying to take their packages.
2025-07-14 13:16:39 <panekj> MR is also an attempt at communication
2025-07-14 13:16:45 <ptrc> panekj: but packages should also be maintained by people who can actually check if a version bump isn't breaking anything, even subtly
2025-07-14 13:16:54 <Kladky> panekj: that's the way I see it, yeah
2025-07-14 13:16:56 <panekj> I think I'm not the only one that dislikes emails
2025-07-14 13:17:06 <panekj> and reachability of certain devs...
2025-07-14 13:17:40 <Kladky> People have been fine with it in the past: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85361#note_514988
2025-07-14 13:17:41 <ptrc> also, Kladky: "Release was over 2 weeks ago now." is definitely on the rude side of messages you can put in a takeover MR
2025-07-14 13:17:41 <panekj> ptrc: i think we can throw away at least half of aports with that assumption
2025-07-14 13:18:18 <Kladky> ptrc: what do you think would be a better message? I can use something else if people would be happer with that.
2025-07-14 13:18:45 <ptrc> a question directed to the package maintainer, at least
2025-07-14 13:18:59 <ptrc> i don't think a package being outdated for 2 weeks warrants just going "someone please move this package from the current maintainer to me"
2025-07-14 13:19:30 <panekj> yes, that doesn't sound nice
2025-07-14 13:19:34 <ptrc> however, you can *ask* "hey @maintainer, i see you have a lot of stuff on your head, do you mind if i take this over?"
2025-07-14 13:20:26 <Kladky> Sure, I can do something like that from now on
2025-07-14 13:24:17 <Kladky> ptrc: I'd personally say that 2 weeks for minor releases with maybe just a handfull of commits is a bit long, especially when someone else is offering to do upgrades within 24 hours
2025-07-14 13:24:59 <Kladky> Especially when it is an impactful fix, that you'd want to get to as many people as fast as possible
2025-07-14 13:25:47 <achill> then say it in the MR and i'll merge it as a critical-fix
2025-07-14 13:26:01 <achill> :)
2025-07-14 13:41:17 <Kladky> Anyways, does anyone know why CI for !85665 is failing on x86? Honestly, I only maintain the package because someone asked me to, and I would be happy for someone with more knowledge of wine to do so instead
2025-07-14 13:41:38 <f_> algitbot: you ok?
2025-07-14 13:42:14 <Kladky> Draft: testing/wine-staging: upgrade to 10.12: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85665
2025-07-14 13:42:47 <panekj> wait a minute...
2025-07-14 13:54:39 <Kladky> Does the following seem more reasonable: #17359 ?
2025-07-14 13:54:56 <Kladky> community/zoxide: request to take over maintainership: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17359
2025-07-14 13:56:52 <f_> Kladky: see that's better ^^
2025-07-14 16:09:28 <henrix> Q: what do I need to do to remove the "status:mr-stale" label from a MR, once I push a new version of a port?
2025-07-14 16:09:45 <henrix> or I simply shouldn't care about that?
2025-07-14 16:10:12 <henrix> 
ACTION assumes people will ignore MRs with that label, hence the question

2025-07-14 16:32:23 <sertonix[m]> In my experience that labe is not too important. You may ping some dev if no one looks at the MR.
2025-07-14 16:33:18 <f_> yeah don't care too much about it
2025-07-14 17:26:11 <henrix> ack, thanks sertonix[m] f_ 
2025-07-14 19:36:37 <ncopa> achill: seems like something is broken with community/reuse
2025-07-14 19:37:06 <ncopa> No module named 'findpython'
2025-07-14 19:37:18 <ncopa> google says that findpython is cmake something?
2025-07-14 19:46:10 <ptrc> henrix: some devs explicitly look at the stale stuff, because it doesn't necessarily mean no activity, just that it's been a long time since it was opened :p
2025-07-14 19:48:27 <henrix> ptrc: great, good to know. thanks!
2025-07-14 19:49:16 <Sheila> ncopa: the makefile invokes poetry, so it might be an issue on poetry's end or with the makefile provided by reuse.
2025-07-14 19:55:49 <achill> ncopa: yeah ill look at it
2025-07-14 19:56:46 <achill> henrix: its just the bot message that needs to be adjusted :)
2025-07-14 20:10:41 <achill> ncopa: i recently upgraded poetry and it seems it has a new dep: https://github.com/frostming/findpython
2025-07-14 20:10:53 <achill> i'll add it in a minute
2025-07-14 20:25:28 <ncopa> thank you!
2025-07-15 01:49:54 <teebuthot[m]> Get in touch with this platform for greatness you’ll definitely thank me later... (full message at <https://matrix.org/oftc/media/v1/media/download/Ae4-qdx0lgCyWywuUBxy5WJJ194SFZ0kz5CQROQ3JzG5Uoe3DM_Wq78JOUPNOKRClzQwrYCwxsg4yMg4wrxKVIVCeYU98w7gAG1hdHJpeC5vcmcvYmhUSEhwVERya3hMeUJIVGplYXV1VmJs>)
2025-07-15 01:50:33 <teebuthot[m]> Get in touch with this platform for greatness you’ll definitely thank me later... (full message at <https://matrix.org/oftc/media/v1/media/download/AeB1evt2TJK_-xFo44-zHAmUq2td5l0fpUzfaBgNWcBf_GtXWZRl8gUJnrRjBARMj1cZQxSi2R2rRA15MLGtH_5CeYU9_RQwAG1hdHJpeC5vcmcvRUNRUHlocnZGZklZT2NQS1dQSklNdXFX>)
2025-07-15 09:50:56 <ncopa> I'm gonna do stable releases now https://gitlab.alpinelinux.org/alpine/aports/-/issues/17362
2025-07-15 09:55:40 <achill> ack
2025-07-15 09:56:59 <Habbie> good luck
2025-07-15 09:57:51 <achill> i hope i can get edge-loongarch64 to upload community soon
2025-07-15 10:58:14 <ncopa> Can I please get some help with reviewing release notes? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/105
2025-07-15 10:59:21 <Habbie> i see no obvious mistakes
2025-07-15 10:59:44 <Habbie> unless the length of the === bar on line 7 counts
2025-07-15 11:00:20 <achill> the openssl cve is only relevant for 3.22
2025-07-15 11:00:37 <achill> and its low severity so noone should feel to be forced to upgrade
2025-07-15 11:27:04 <ncopa> I'm open to suggestions
2025-07-15 11:27:15 <ncopa> we also include ca-certificates update
2025-07-15 11:33:03 <MrBeedellRokeJulianLockhartRJL> Per https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/3739#note_491181, I'm co-ordinating with the developers of postmarketOS to acquire a MITRE CPE ID for them. I've done some basic research (like ascertaining that it's not a URN), but the registration process isn't incredibly well-documented. Because Alpine Linux appears to have almost every release included in the CPE dictionary, does anyone here
2025-07-15 11:33:03 <MrBeedellRokeJulianLockhartRJL> have any advice on pitfalls they experienced during the registration process?
2025-07-15 11:33:03 <MrBeedellRokeJulianLockhartRJL> I've not asked at https://lists.alpinelinux.org/~alpine/devel because IDK how well that works with e-mail middleman like https://github.com/anonaddy/anonaddy/releases/tag/v1.3.3. Would I have more luck if I did...?
2025-07-15 11:34:38 <ncopa> 1
2025-07-15 11:34:52 <ncopa> wrong win
2025-07-15 12:06:00 <ikke> MrBeedellRokeJulianLockhartRJL: afaik, we do not manually provide that to mitre
2025-07-15 12:20:12 <MrBeedellRokeJulianLockhartRJL> <ikke> "Mr. Beedell, Roke Julian..." <- Aha. That means that they're added by the CPE Community. Thanks.
2025-07-15 14:14:56 <WhyNotHugo> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/391 is ready to be merged
2025-07-15 14:47:36 <Saijin_Naib[m]> Sweet!
2025-07-15 14:47:47 <Saijin_Naib[m]> abuild getting smarter and smarter
2025-07-15 15:19:56 <realroot[m]> pj
2025-07-15 17:37:03 <Ariadne> MrBeedellRokeJulianLockhartRJL: you don't register CPEs formally.  the publisher of the security advisory can add them, or they can be added through enrichment, usually by way of either CISA's vulnrichment project or NIST's "national vulnerability database" (there's also an EU one, but nothing seems to make use of it yet)
2025-07-15 17:43:16 <Ariadne> MrBeedellRokeJulianLockhartRJL: what is your goal here?  scanners should already mostly know that pmOS uses same security data as alpine.  if we want to start tracking security vulnerabilities in pmOS directly (e.g. in the overlay repo) then we should start publishing a secdb for pmOS.  from there, getting the scanners to recognize it is easy enough... the main FOSS ones have fully open ingestion pipelines
2025-07-15 17:43:23 <Ariadne> (see also #alpine-security)
2025-07-15 18:18:38 <PureTryOut> Is there someone that can moderate the Matrix channel? @jaykiller:matrix.org is spamming badly
2025-07-15 18:18:57 <PureTryOut> (money scam)
2025-07-15 18:21:22 <f_> PureTryOut: they've been klined from oftc a long while ago, did they not get kicked out as a result?
2025-07-15 18:21:41 <f_> panekj probably can clean it up I think
2025-07-15 18:22:04 <PureTryOut> It seems they didn't no, they literally send a message right after I've send the previous message
2025-07-15 18:22:16 <f_> Well then I don't see any of their messages
2025-07-15 18:22:30 <PureTryOut> That doesn't help us...
2025-07-15 18:22:57 <f_> Unless pj doesn't have perms on Matrix I just pinged them a few minutes ago..
2025-07-15 18:23:07 <PureTryOut> they do
2025-07-15 18:23:12 <f_> ok
2025-07-15 18:25:02 <f_> I wonder if it could help having jonathan's matrix account in here
2025-07-15 18:25:17 <f_> jonathan is the pmOS crossbanning bot
2025-07-15 18:52:30 <achill> Ariadne: yeah i think right now it has little to no benefit to us and is mostly more work
2025-07-15 18:53:53 <Ariadne> that's my general read of the situation too.  i don't think there is really anything in the pmOS overlay which needs a full security lifecycle like we have in alpine
2025-07-15 18:54:48 <Ariadne> thats why i ask about it... because CPEs are almost entirely intended for scanners
2025-07-15 18:55:45 <Ariadne> and at least last time i asked syft to generate an SBOM for a pmOS image (about a year ago), it identified the pmOS image as an alpine image... so scanners would use the alpine secdb data
2025-07-15 19:28:36 <MrBeedellRokeJulianLockhartRJL> <Ariadne> "thats why i ask about it..." <- I've used them for everything, since they're a more standardised way to refer to OSes and DEs. If registration requires constant maintenance, indeed, it's not worth the hassle.
2025-07-15 19:28:36 <MrBeedellRokeJulianLockhartRJL> However, considering the amount of work in PMOS's `aports`, there'd be some usefulness in having CVEs tracked specific to there.
2025-07-15 19:32:21 <Ariadne> there isn’t any “registration” as noted already…
2025-07-15 19:33:21 <Ariadne> and the overlay repo does not really have much other than kernels that are CVE relevant.  maintaining security lifecycle data for all of those kernels is going to be a nightmare
2025-07-15 19:36:19 <achill> yeah you cant consider our shipped kernels secure, a lot aren't even running the latest point release of the kernel release
2025-07-15 19:36:39 <achill> ("out" being postmarketos)
2025-07-15 19:39:47 <achill> my unducated opinion would be using alpine's cpe for postmarketos, should cover most matter
2025-07-15 21:25:17 <Ariadne> achill: that's what scanners already do generally.  they see /etc/alpine-version and go off that.
2025-07-15 23:48:55 <pj> PureTryOut: f_: cleaned up but I'm not sitting 24/7 on matrix to monitor stuff
2025-07-16 00:16:19 <sertonix[m]> The repository of community/paper-gtk-theme got deleted. Should we just continue to ship the version from distfiles?
2025-07-16 09:13:39 <PureTryOut> pj: there are more mods, would be nice if anyone was active enough to clear up that stuff. Otherwise perhaps more moderators should be added
2025-07-16 12:08:57 <pj> PureTryOut: all moderation is on irc, I was graciously given power since I sit here a lot and have to deal with exact same spam across various rooms
2025-07-16 12:09:17 <pj> I agree more mods might make it better, but I also think cutting of matrix would be best
2025-07-16 12:09:29 <pj> off
2025-07-16 12:11:09 <ikke> Note that the last spammer (i think) was k-lined by a server op
2025-07-16 12:15:53 <achill> the message can still get deleted from the matrix channel
2025-07-16 12:52:33 <pj> ikke: the problem is people using matrix only since most of the spammers get beaned from irc side anyway but the chatlogs remain in matrix
2025-07-16 12:56:03 <ncopa> who is responsibel for the Matrix channel? I don't think it was alpine ppl who set it up?
2025-07-16 12:57:28 <pj> it's automatic OFTC bridge
2025-07-16 12:58:07 <pj> all channels are accessible via #oftc prefix like #oftc#alpine-devel:matrix.org
2025-07-16 12:58:27 <pj> thank you matrix 
2025-07-16 12:58:44 <achill> btw im from matrix and im often hefr, so i'm fine with removing this stuff. in some spam waves, i'm alrady doing it in postmarketos too
2025-07-16 12:58:46 <panekj> #_oftc_ & #_oftc_#alpine-devel:matrix.org
2025-07-16 14:34:15 <sertonix[m]> Is it be possible for the OFTC bridge to mirror some moderation?
2025-07-16 14:41:23 <invoked> nobody is working on the bridge from what i know
2025-07-16 14:43:03 <abby> matrix would rather see you switch to matrix
2025-07-16 14:43:12 <abby> the bridges are a recruitment tool
2025-07-16 14:43:38 <invoked> https://github.com/matrix-org/matrix-appservice-irc/pull/1832
2025-07-16 17:36:01 <achill> ncoap: do you mind taking a look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/388?
2025-07-16 17:41:14 <pepijndevos[m]> It seesms like the ARM builders might be stuck? There haven't been any ARM builds since 8 in the morning
2025-07-16 17:41:32 <pepijndevos[m]> For example https://pkgs.alpinelinux.org/packages?name=glslang&branch=edge&repo=&arch=&origin=&flagged=&maintainer= shows all the arm architectures outdated
2025-07-16 18:43:49 <pepijndevos[m]> s390x is updated now, but ARM still outdated
2025-07-16 19:37:30 <userdocs> do you need to do anythign specifc when using these https://pkgs.alpinelinux.org/package/edge/main/x86/fortify-headers or will they be picked up automatically when using D_FORTIFY_SOURCE
2025-07-16 19:49:57 <ikke> pepijndevos[m]: the builder is currently unreachable. The hoster indicated the router has a hardware bug and will be replaced 
2025-07-16 19:51:06 <ikke> You don't have to do anything (at least, with the default toolchain). Alpine builds everything with fortify-headers 
2025-07-16 20:03:29 <pepijndevos[m]> <ikke> "pepijndevos: the builder is..." <- ok so it's known and being worked on good
2025-07-16 20:05:50 <userdocs> i was using checksec to check but i get the same result with alpine toolchain or my own. is there another way to check?
2025-07-16 21:50:03 <Ariadne> userdocs: fortify in alpine is very different from glibc fortify
2025-07-16 21:50:20 <Ariadne> in alpine, fortify checks are inlined
2025-07-16 21:50:38 <Ariadne> checksec looks for public symbols relating to glibc's fortify implementation internals
2025-07-16 22:09:44 <userdocs> this is why i was wondering if there was another way to verify it, i figured checksec was not really helping here
2025-07-16 22:10:46 <userdocs> the tools i see seem to be glibc based
2025-07-16 22:26:05 <Ariadne> sadly since the checks are inlined, it's hard
2025-07-16 22:42:13 <userdocs> if i build an mcm cross compiler would i need to use this patch? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0016-add-fortify-headers-paths.patch
2025-07-16 23:02:26 <Ariadne> in general, i would not recommend that
2025-07-16 23:02:41 <Ariadne> instead you should use -isystem /path/to/fortify/headers when building with a cross-toolchain
2025-07-16 23:07:52 <userdocs> then i'd need to also do that with things i build with the toolchain?
2025-07-16 23:17:38 <Ariadne> yeah
2025-07-16 23:18:07 <userdocs> ok, thanks. i'll do that and see how it goes.
2025-07-17 04:37:55 <Saijin_Naib[m]> Is this issue known/verified by anyone else? setup-desktop xfce-wayland fails with creating an invalid path
2025-07-17 04:38:03 <Saijin_Naib[m]> /usr/sbin/setup-desktop: line 113: can't create //etc/greetd/environments: nonexistent directory
2025-07-17 04:38:14 <Saijin_Naib[m]> I'm on x86_64 edge
2025-07-17 04:38:20 <Saijin_Naib[m]> If not, I can file the issue
2025-07-17 15:43:50 <qaqland> https://forgejo.org/docs/v12.0/admin/release-schedule/
2025-07-17 15:44:41 <qaqland> it is too short to port non-LTS editions into aports/stable
2025-07-17 15:44:50 <qaqland> only 3 months
2025-07-17 15:51:27 <achill> as the one who recetly does the upgrades, the security patches are really trivial to backport to "unsupported" releases
2025-07-17 15:51:45 <achill> but in case someone rather wants the LTS there is community/forgejo-lts
2025-07-17 15:52:21 <achill> (and currently in alpine 3.22 community/forgejo is even on the lts version by accident :p)
2025-07-17 16:18:30 <pj> frogejo
2025-07-17 17:05:27 <achill> 🐸ejo
2025-07-18 00:12:13 <jvvv> i've been thinking about dropping testing/nvim-lualine. after some consideration, i wonder if removing it would be a better solution.
2025-07-18 02:33:56 <andar1an[m]> Thank you [@jahway603:meowchat.xyz](https://matrix.to/#/@jahway603:meowchat.xyz) 
2025-07-18 02:34:31 <andar1an[m]> Hi all, Is there a way other than adding net option to handle spurious network errors for cargo during build of pkgs? I've just been doing that when i hit then but dk if that is correct way.
2025-07-18 07:23:08 <ncopa> jvvv: I have been thinking of nvim plugins as packages lately
2025-07-18 07:23:42 <ncopa> i'd like nvim plugin packages that are auto-enabled with apk add
2025-07-18 07:24:24 <ncopa> for example, a meta package nvim-auto-plugins (name can change)
2025-07-18 07:24:45 <ncopa> with a set of subpackages with install_if
2025-07-18 07:25:17 <ncopa> so that if you install for example go, the go LSP will automatically be installed and enabled
2025-07-18 07:27:04 <ncopa> so that you can enable plugins with a simple apk add
2025-07-18 07:40:37 <lotheac> that'd be nice :)
2025-07-18 08:03:41 <Biswa96[m]> Would it be possible for abuild to remove systemd directories from packages internally? There are many APKBUILDs with rm -rf "$pkgdir"/usr/lib/systemd
2025-07-18 09:07:57 <ncopa> Biswa96[m]: yes. there is a draft  mergerequest for that, but we are still discussing implementation details
2025-07-18 09:08:31 <ncopa> basically the idea is that you add a subpackages="$pkgname-systemd" to the APKBUILD
2025-07-18 09:11:35 <Biswa96[m]> Thank you. That subpackage would be very helpful for packages which just install service files without linking with systemd libraries. e.g. in postmarketos
2025-07-18 09:24:25 <ncopa> thats the idea yes
2025-07-18 10:48:31 <vmignot> 23
2025-07-18 11:25:41 <qaqland> ncopa: i think nvim-plugins should be installed in user mode, not global..
2025-07-18 11:29:27 <ncopa> qaqland: how do you mean?
2025-07-18 11:29:47 <ncopa> you mean in users home direcotory, not system-wide?
2025-07-18 11:31:11 <ncopa> I'd like to be able to install/enable nvim plugins with apk https://gitlab.alpinelinux.org/alpine/aports/-/issues/17371
2025-07-18 12:25:18 <ncopa> jvvv: I wonder why nvim-lualine is installed in /usr/share/nvim/site/pack/dist/opt
2025-07-18 12:38:01 <qaqland> ncopa: yes
2025-07-18 12:39:34 <qaqland> i can use apk on other distros to install vim plugins :)
2025-07-18 12:39:44 <qaqland> 
ACTION wish

2025-07-18 12:42:30 <abby> how's apk supposed to know what user to install it as?
2025-07-18 12:43:41 <abby> also the nvim plugin space is so volatile, it's probably a sysiphean task package even the plugins du jour
2025-07-18 12:53:14 <userdocs> when build static binaries, i noticed alpine ld does this by default? https://sourceware.org/binutils/docs-2.44/ld/Options.html#index-_002d_002dbuild_002did
2025-07-18 12:53:31 <userdocs> where is that set? my mcm was not doing it unless i added the linker flag
2025-07-18 12:58:15 <userdocs> nvm, i think i foudn it: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/APKBUILD#L372
2025-07-18 12:58:31 <userdocs> i was looking at binutils.
2025-07-18 14:41:00 <jvvv> ncopa: tbh, the trouble with nvim plugins is that they are often a fast moving target, often with no releases and little to demarc transitions... that was why i asked about nvim-lualine... it hasn't tagged a release in almost 3 years and it changes often
2025-07-18 14:43:10 <abby> most plugin managers just follow master/main/trunk by default
2025-07-18 14:43:22 <jvvv> yes
2025-07-18 14:44:21 <jvvv> i keep good eye on nvim-treesitter, but it is consistent about releases (more than most)
2025-07-18 15:07:00 <proycon> There're issues with the gitlab server still I think? I get:  remote: rpc error: code = Unavailable desc = The git server, Gitaly, is not available at this time. Please contact your administrator.
2025-07-18 15:07:00 <proycon> r
2025-07-18 15:22:45 <nusgul[m]> Hello, is the gitlab down ?
2025-07-18 15:24:12 <Biswa96[m]> yes, I can not access it.
2025-07-18 15:25:38 <sertonix[m]> [@andar1an:matrix.org](https://matrix.to/#/@andar1an:matrix.org) Adding the net option doesn't change anything on the CI and builders. So at the moment it's just retrying.
2025-07-18 15:59:41 <nusgul[m]> I've observed that the [hyprutils package](https://pkgs.alpinelinux.org/package/edge/community/x86_64/hyprutils) is marked as up to date (7.1) despite a new version being available (8.1). There is an Anitya mapping for it reporting 8.1: https://release-monitoring.org/project/374420/. It's been 3 weeks since 8.0. Why isn't it detected ?
2025-07-18 16:17:23 <sertonix[m]> Anitya also needs to know the name of the alpine package. I added that now
2025-07-18 16:30:53 <nusgul[m]> Thanks
2025-07-18 16:41:05 <caskd> has anyone used apk-audit for backing up hosts?
2025-07-18 16:41:18 <caskd> if yes, any issues that have occured at all?
2025-07-18 16:41:43 <caskd> looking to maybe slim down backups by limiting the scope
2025-07-18 16:54:43 <invoked> interesting use of apk-audit. i like it. i guess the risk would be if /lib/apk/db/ stuff got messed up somehow.
2025-07-18 16:59:59 <caskd> i wouldn't back up the db
2025-07-18 17:00:21 <caskd> in general i would want to restore via the world even if it's not a 1:1 restore
2025-07-18 17:26:24 <sertonix[m]> Might be useful to look at the lbu code to check if there are any special cases
2025-07-18 17:27:36 <nusgul[m]> Where is documented the .rootbld-repositories file format ? I'm trying to add a local repository to it but without success.
2025-07-18 17:29:32 <nusgul[m]> * Where is the .rootbld-repositories file format documented ? I'm trying to add a local repository to it but without success.
2025-07-18 18:18:44 <ikke> gitlab should be back for now
2025-07-18 20:06:46 <pepijndevos[m]> <ikke> "pepijndevos: the builder is..." <- Are arm builders still offline or backlogged?
2025-07-18 20:37:05 <Biswa96[m]> this shows the status of builders https://build.alpinelinux.org/
2025-07-18 21:16:01 <pepijndevos[m]> <Biswa96[m]> "this shows the status of..." <- Glslang is still outdated on arm though
2025-07-18 21:16:07 <pepijndevos[m]> https://pkgs.alpinelinux.org/packages?name=glslang&branch=edge&repo=&arch=&origin=&flagged=&maintainer=
2025-07-18 21:16:26 <pepijndevos[m]> Even though the builders show idle
2025-07-18 21:56:55 <andar1an[m]> Thank you [@sertonix:mozilla.org](https://matrix.to/#/@sertonix:mozilla.org)  . I have found it is fairly consistent with the spurious network errors without, and doesn't correct even with rootbld locally sometimes. Will try to remove again and see if it happens
2025-07-18 22:15:50 <sertonix[m]> nusgul: there is no documentation. If you use abuild rootbld it's preprocessed with envsubst and then used as apk repositories file. When using abuild without rootbld I would recommend not using it and and repositories to /etc/apk/repositories insteay.
2025-07-19 04:20:55 <qaqland> hi, i'm building a perl port. it says Can't locate syscall.ph in @INC (did you run h2ph?)
2025-07-19 04:21:10 <qaqland> how could i fix this error?
2025-07-19 05:57:07 <Biswa96[m]> did you look for h2ph ? https://metacpan.org/search?q=h2ph
2025-07-19 05:58:35 <qaqland> thanks cece, it works after calling h2ph -d :)
2025-07-19 05:59:15 <qaqland> Biswa96[m]: thank you too
2025-07-19 09:43:31 <zzy> 奥伦奥伦奥伦奥伦
2025-07-19 14:33:52 <weechat11k> https://filehost.0bin.xyz/FgyiRqcs4b20.zip
2025-07-19 14:45:56 <skarnet> I am so going to click that link
2025-07-19 14:46:56 <panekj> well, I've banned them on matrix but I lost op on irc it seems so yay
2025-07-19 14:48:02 <panekj> relayed to #oftc about spammer and someone pinged dwfreed in #freedesktop
2025-07-19 16:24:10 <kapad> have adelie and alpine any relation ? dont mean like `business` model, but rather like distros ?
2025-07-19 16:28:17 <Sheila> kapad: Adélie and Alpine are mostly unrelated; Adélie uses some of the same tooling that Alpine does, and makes use of some build recipes from Alpine, but we are our own thing.
2025-07-19 16:31:58 <kapad> just land there, and seems the same minimal like alpine. i met alpine some months before and i like the approach. `minirootfs` are my favorite, but i also use it on a pi4 for 2-3 months now, runs ok! ok, that was all. Sheila, thanks.
2025-07-19 16:35:34 <kapad> Sheila: another question about alpine. is there any know issues with qt in alpine. i try to build Psi that uses qt and gstreamer but gstreamer, dont seems to work ok, the program cannot enumarate my devices. is something know about that ?
2025-07-19 16:36:45 <Sheila> no idea, sorry.
2025-07-19 16:37:14 <Biswa96[m]> try with gdb for some hints
2025-07-19 16:37:38 <kapad> i tried it on 3.21, and i just preparing a clean rootfs to documented the whole process and to write down the exact deps from a clean system
2025-07-19 16:37:44 <kapad> ok.
2025-07-19 16:44:23 <kapad> this is what i prepare: https://ua3.anondns.net/im/p/ba58b0/a363/alpine-psi-build.md It works fine, except what said, so av calls dont work. so i'm going to validate that, that are the minimal and enough dependencies, then it's gonna be ready. may also try on 3.22 to see...
2025-07-19 16:46:12 <Sheila> note that gstreamer packages plugins separately.
2025-07-19 16:46:48 <kapad> yes thats how are on debian too
2025-07-19 16:50:04 <kapad> is it easy to transform this in a apkbuild `version` ?
2025-07-19 18:57:07 <siemon[m]> hi
2025-07-19 23:59:39 <kapad> 
ACTION 0:00:00.043297937 2327243 0x7f0f6ffd4620 WARN GST_ELEMENT_FACTORY gstelementfactory.c:712:gst_element_factory_make_with_properties: no such element factory "vp8enc"! | Unable to load element 'vp8enc'. |GStreamer thread completed (error)GStreamer thread completed (error)|glib event loop failed to initialize

2025-07-20 01:47:55 <jvvv> kapad: not sure but i think that vp8 stuff should come from libvpx and be made available to gstreamer via gst-plugins-good
2025-07-20 01:52:02 <kapad> i have found the code, that makes a loop over gstreamer elements, and i also have the opinion that should be provided by the gst-plugins. I also ask in the devs, but i think is a matter of gst-plugins. 
2025-07-20 01:54:31 <kapad> QStringList reqelem = { "opusenc", "opusdec", "vorbisenc", "vorbisdec",  "vp8enc", "vp8dec","rtpopuspay","rtpopusdepay","rtpvp8pay", "rtpvp8depay", "filesrc", "decodebin",     "jpegdec","oggmux", "oggdemux", "audioconvert", "audioresample", "volume", "level",      "videoconvert", "videorate", "videoscale","rtpjitterbuffer", "audiomixer", "appsink" };
2025-07-20 01:57:01 <kapad> that is the string, as said **really** not an expert, but think that are things that plugins should provide, no matter what will happen next. i think the error i see, is that no element exist, not that something is not work when tried. but...
2025-07-20 02:00:09 <kapad> 
ACTION also building now against v3.22 to see... I have a really slow machine, so...

2025-07-20 02:21:54 <kapad> v3.21, https://ua3.anondns.net/im/p/54a6e7/7a00/psimedia-demo-works-disable-a-lot-gst-elements.png as the title says. program not crashed, and finally enumerate my devices
2025-07-20 02:22:24 <kapad> ^ also, what title says, https://ua3.anondns.net/im/p/54a6e7/8c72/psi-multimedia-plugin-works-if-psimedia-hacked.png
2025-07-20 02:26:54 <kapad> i also had disable the `v4l2` element that even in qt clearly works https://ua3.anondns.net/im/p/54a6e7/37d6/qv4l2-just-works.png
2025-07-20 02:29:41 <kapad> sorry, for the flood, i just want to have safe conclusion that, if this happen because of the gst-plugins, or because some other deps missing.  i really think the 1st, but dont have the tech background to support this
2025-07-20 02:46:07 <kapad> So yes, is a matter of the plugins build. here the proof: https://ua3.anondns.net/im/p/54a6e7/c712/apt-cache-show-gstreamer1.0-plugins-good.log
2025-07-20 03:28:47 <kapad> that dont work either: https://ua3.anondns.net/im/p/54a6e7/f2a6/run-psimedia-on-alpine-v3.22.log, seems have to play with the plugins...
2025-07-20 06:11:14 <LargeLanguageModel> [LargeLanguageModel] Corpus Loaded With 815 Messages
2025-07-20 06:11:16 <LargeLanguageModel> [LargeLanguageModel] Training Neural Network...
2025-07-20 06:13:48 <LLM> [LLM] Deplorables Anonymous
2025-07-20 06:15:59 <LLM> [LLM] lag free
2025-07-20 06:18:38 <LLM> [Chat] It's so quiet
2025-07-20 06:19:20 <LLM> [LLM] Walking is better
2025-07-20 06:20:21 <LLM> [LLM] Family Friendly Christian server!
2025-07-20 06:22:51 <LLM> [LLM] a Bring roar joining time, the down
2025-07-20 06:24:19 <LLM> [LLM] Singleplayer with quality actors and feel blessed...
2025-07-20 06:25:00 <LLM> [Chat] If it becomes/is to "spammy", I can limit how fast it can send messages in-between each-other
2025-07-20 06:25:44 <LLM> [Chat] Just lmk
2025-07-20 06:27:31 <LLM> [Chat] What're y'all doin?
2025-07-20 06:28:57 <LLM> [LLM] This MOTD
2025-07-20 06:31:31 <LLM> [LLM] plos help i felt lonely
2025-07-20 06:33:19 <LLM> [LLM] be the really most dupe shoot people This
2025-07-20 06:33:57 <LLM> [LLM] read I and blaze hip-hop peer Not is THAW above)
2025-07-20 06:34:39 <LLM> [Chat] Whoops, did /sayrandom the same moment it had generated a msg LOL
2025-07-20 06:35:43 <LLM> [LLM] I'm just stacked up
2025-07-20 06:36:52 <LLM> [LLM] Pain and check'd.
2025-07-20 06:38:37 <LLM> [LLM] Design around, still the in Steve facial stars.
2025-07-20 06:42:15 <LLM> [LLM] a won't FIGURED
2025-07-20 06:43:32 <LLM> [LLM] God warning. soon just mullvad Lord That's by really a
2025-07-20 06:45:01 <LLM> [LLM] there every cent sensual; what
2025-07-20 06:46:14 <LLM> [LLM] One of three you
2025-07-20 06:46:50 <LLM> [LLM] ahead true, Nobody always ask you
2025-07-20 06:47:28 <LLM> [Chat] Funny how wrong you are
2025-07-20 10:54:14 <JesusChrist> [Chat] Disabled auto-message sending, I've officially moved the bot to #llm
2025-07-20 15:04:09 <invoked> sertonix[m]: does tor-browser have any chance of being merged if i worked on it (vaguely approaching it the same way openbsd does)
2025-07-20 15:15:25 <achill> well the "if it worked" is a big one
2025-07-20 15:15:37 <achill> but if it does, i think we can manage the additional cpu resources
2025-07-20 15:21:01 <invoked> i don't think getting it to work is a problem. getting past objections on whether it's safe enough is what i'm asking about
2025-07-20 15:22:35 <invoked> but if it's not of interest (for any reason) then i wouldn't bother, my time is limited
2025-07-20 15:23:36 <invoked> but i know we can do better than flatpak installs.
2025-07-20 15:33:42 <sertonix[m]> I think doing this correctly takes a lot of time. But I am not against starting the effort.
2025-07-20 15:38:29 <invoked> it would be good to know what testable criteria it needs to meet to make it into testing. i can say that the openbsd port works very well in my experience. yes they have pledge/unveil/etc but i don't think that stuff should be a blocker here.
2025-07-20 15:38:46 <invoked> they also turn on forkserver.
2025-07-20 18:16:09 <ovf> fossdd: should sdl2-compat provide sdl2?
2025-07-20 18:16:47 <ovf> or achill: ^, whichever is you
2025-07-20 18:18:43 <achill> yes it should already with the so: provider
2025-07-20 18:18:55 <achill> (both are me, fossdd is at irc, achill at matrix, but pinging both or either is fine)
2025-07-20 18:19:03 <sertonix[m]> invoked: We need to check all the mozconfig options regarding fingerprinting. For example --with-system-icu is fingerprintable. It looks like OpenBSD doesn't do this correctly, maybe someone should test that? Otherwise it would probably be reading through tor-browser-build to ensure that we don't end up doing anything differently.
2025-07-20 18:31:12 <ovf> achill: there are a few packages that depend on 'sdl2', e.g. sdl12-compat.
2025-07-20 18:32:01 <ovf> achill: also, i haven't figured why yet but pc:sdl2 also doesn't pick up sdl2-compat, so .e.g sdl2_image-dev tries to pull in the original sdl2-dev
2025-07-20 18:34:32 <ovf> well, the 'why' is simply because sdl2-compat provides pc:sdl2-compat only...
2025-07-20 18:36:57 <sertonix[m]> sdl12-compat should probably not depend on sdl2 but rather the so: provider. I am a bit cnfused why abuild didn't trace that
2025-07-20 18:41:24 <achill> yeah pulling in pc:sdl2 or sdl2-dev in makedepends is fine since both so names are abi complient
2025-07-20 18:44:26 <ovf> sertonix[m]: somewhat sensibly, sdl12-compat is loading sdl2 dynamically: https://github.com/libsdl-org/sdl12-compat/blob/main/src/SDL12_compat.c#L1315
2025-07-20 18:47:02 <ovf> (sensibly because they probably wanted an upstream build of sdl12-compat to be droppable into any sdl12-using thing, rather than expected every used to install it on their system) 
2025-07-20 18:52:09 <sertonix[m]> The sdl12-compat dependency should be changed to so:libSDL2-2.0.so.0 then.
2025-07-20 18:54:14 <achill> just thinking but it should also be fine if we add a sdl2 provider for sdl2-compat, or?
2025-07-20 18:59:22 <ovf> achill: and likewise for -dev. 
2025-07-20 18:59:25 <sertonix[m]> I think we should only do that when sdl2 was removed. Otherwise it's very difficult to tell apk that you want the actual sdl2
2025-07-20 18:59:35 <achill> fair enough
2025-07-20 19:01:48 <ovf> the gold standard of stability, archlinux seem to have made the transition fine
2025-07-20 23:06:00 <invoked> sertonix[m]: re tor-browser fingerprinting. yeah i do agree about fingerprinting, and it should be testable/measureable to be considered
2025-07-20 23:07:11 <invoked> i'll ping the appropriate people this week and see what they suggest
2025-07-21 04:47:26 <Saijin_Naib[m]> achill, thanks for bumping sonicradio for me
2025-07-21 04:47:30 <Saijin_Naib[m]> I'm queueing up kew now
2025-07-21 04:55:10 <Saijin_Naib[m]> How is the feeling about packaging stuff like ioquake?
2025-07-21 04:55:21 <Saijin_Naib[m]> Fine, right? OSS, compatible license, but meant for proprietary data
2025-07-21 04:55:36 <Saijin_Naib[m]> I want to try WarFork first, thoguh
2025-07-21 06:12:35 <Saijin_Naib[m]> https://bpa.st/3SLQ
2025-07-21 06:12:47 <Saijin_Naib[m]> Is this part of apkv3 and merged usr stuff happening?
2025-07-21 06:13:04 <Saijin_Naib[m]> What is the proper path forward here, so I can bump kew to v3.4.0?
2025-07-21 06:19:00 <ikke> No, that had always been the case 
2025-07-21 06:19:19 <Saijin_Naib[m]> Hmm... I don't think they changed anything on their end, and prior builds succeeded
2025-07-21 06:19:28 <ikke> You need to configure it to not install under /usr/local but under /usr
2025-07-21 06:22:25 <Saijin_Naib[m]> thanks, ikke
2025-07-21 06:35:30 <Saijin_Naib[m]> 
ACTION uploaded an image: (179KiB) < https://matrix.org/oftc/media/v1/media/download/AWh9LUrU-AUI_CWkTHk-L7Ds0NAWrm-KuIZ4xV9Wv9N2ki7nvSjD2ooP3FDPDtc6McBqY-qcXTwhw6tg1VVqQ8ZCeYc8rZ8QAG1hdHJpeC5vcmcvUXlsaUNOQmJYRnVKcHFscVNsT1VqR1hV >

2025-07-21 06:35:40 <Saijin_Naib[m]> kew is getting pretty cool
2025-07-21 06:36:07 <Saijin_Naib[m]> Now I just need to dig and see if vte3 finally landed sixels in the stable branch, so that I can then in turn enable it in xfce4-terminal after it is enabled in vte3
2025-07-21 07:28:25 <Saijin_Naib[m]> If anyone gets bored, I can finally package Formiko, though I need to fixup my m2r2 aport
2025-07-21 07:28:29 <Saijin_Naib[m]> !87551
2025-07-21 07:29:14 <Saijin_Naib[m]> This makes my work so much easier
2025-07-21 07:29:22 <Saijin_Naib[m]> The tooling around rST sucks so bad, but this one is neat
2025-07-21 09:25:41 <el[m]1> for what it's worth, spotted a CVE issue on gitlab just now: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17377
2025-07-21 14:29:39 <realroot[m]> how do you handle same source and multiple things to build? subpacakges and amove?
2025-07-21 14:29:48 <realroot[m]> https://gitlab.archlinux.org/archlinux/packaging/packages/rocm-llvm/-/blob/main/PKGBUILD?ref_type=heads
2025-07-21 14:32:22 <Biswa96[m]> > subpacakges and amove?
2025-07-21 14:32:22 <Biswa96[m]> yes, that's used mosly.
2025-07-21 14:32:29 <Biswa96[m]> s/mosly/mostly/
2025-07-21 14:33:16 <realroot[m]> do you have an example maybe?
2025-07-21 14:34:31 <Biswa96[m]> grep -ir amove in aports directory will provide those examples.
2025-07-21 14:34:41 <Biswa96[m]> s//`/, s/ir/r/, s//`/
2025-07-21 14:35:09 <Biswa96[m]> at least, that's how I find most of the things :)
2025-07-21 14:39:21 <invoked> sertonix[m]: so, i think flatpak tor-browsers on alpine are ending up in a new anonymity set anyway.
2025-07-21 14:40:12 <invoked> sertonix[m]: so what i'll probably do is build tor-browser on alpine, 1st pass, and compare the fingerprinting bits and compare/share the results
2025-07-21 14:42:24 <invoked> if there's something else you suggest, considering your experience in the browser world, lemme know.
2025-07-21 14:44:43 <realroot[m]> i am looking pipewire it seems that subpackages have to start with package e.g. pipewire
2025-07-21 14:45:02 <ikke> That's not a requirement 
2025-07-21 14:45:46 <realroot[m]> how do I call the function `subpackages="rocm-device-libs comgr"`
2025-07-21 14:46:23 <realroot[m]> *function for. I see jack() in pw that makes pipewire-jack i guess
2025-07-21 14:47:02 <ikke> It uses the last part after splitting on -
2025-07-21 14:47:25 <ikke> And you can override the function name
2025-07-21 14:47:31 <Biswa96[m]> this explains how subpackages variable and function is related https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#subpackages
2025-07-21 15:15:26 <realroot[m]> when somebody makes a new aport MR who is maintanier in apkbuild?
2025-07-21 15:17:17 <ikke> In most cases, they are
2025-07-21 15:19:57 <realroot[m]> even for users like me that are not alpine devs?
2025-07-21 15:23:31 <invoked> if you've submitted and/or took over maintaining a package, that's you
2025-07-21 15:24:03 <invoked> you don't need to be in the alpine org to be a maintainer
2025-07-21 15:24:29 <realroot[m]> new aport, rocm
2025-07-21 15:26:58 <Sheila> I'm not part of the Alpine org and I have several recipes, some of them in main/.
2025-07-22 03:16:22 <Saijin_Naib[m]> Anyone have any thoughts on how one might approach packaging WarFork for Alpine?
2025-07-22 03:17:15 <Saijin_Naib[m]> Other distros just package/unpack the provided tgz and the binaries (glibc, obvs), but we'd need to build then fetch the data...
2025-07-22 03:17:32 <Saijin_Naib[m]> I think it might be beyond me, but I'd really like to play it so I've been doing a bit of digging
2025-07-22 13:36:37 <ncopa> k9s checksum fails
2025-07-22 13:42:26 <achill> see !87604
2025-07-22 14:15:30 <raspbeguy> hello, I can't make loongarch64 work on !87344 and I don't know how to fix that
2025-07-22 14:17:05 <raspbeguy> also, if someone could merge these two previously reviewed PRs 🙂 !86918 !82823
2025-07-22 14:20:28 <ncopa> algitbot: hi
2025-07-22 16:08:53 <andar1an[m]> If one uses dracut or booster for their initramfs, what happens when Aports updates trigger mkinitfs?
2025-07-22 16:10:22 <ncopa> no idea
2025-07-22 16:17:25 <andar1an[m]> Me neither haha. Can always try. Ty
2025-07-22 16:24:17 <andar1an[m]> Cool, looks like a user can disable trigger in mkinitfs.conf.
2025-07-22 16:32:28 <ncopa> raspbeguy: https://build.alpinelinux.org/buildlogs/build-edge-s390x/testing/plakar/plakar-1.0.2-r0.log
2025-07-22 16:32:35 <ncopa> seems like it fails to build now for some reason
2025-07-22 16:33:13 <achill> i would guess because of a new go
2025-07-22 16:33:48 <ncopa> probably yes
2025-07-22 17:54:28 <raspbeguy> ncopa: the only error I can see is: libfakeroot internal error: payload not recognized!
2025-07-22 20:29:16 <ffoss> Perhaps wlroots could be built with libliftoff support? All other optional dependencies already seem to be used. I'm not too familiar with libliftoffs progress though
2025-07-22 20:29:53 <ffoss> But I see both hyprland and gamescope have it as a dependency already
2025-07-22 20:30:03 <achill> sounds fine, do you mind opening a issue or even a MR?
2025-07-22 20:32:20 <ffoss> Sure, Ill give it a go
2025-07-22 20:32:32 <achill> nice!
2025-07-22 21:02:30 <ffoss> !87638
2025-07-22 21:02:43 <ffoss> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87638
2025-07-22 21:02:59 <ffoss> Managed to skip some pipeline though
2025-07-22 21:40:19 <achill> we got below 700 MRs again o/
2025-07-23 01:12:34 <sertonix[m]> andar1an: waydroid also requires a kernel paramter and it's just mentioned in the documentation.
2025-07-23 01:37:33 <andar1an[m]> Thank you, I think that is best way. Will get to learn how to define several packages and docs with this which is cool. Just need to figure out best way to break it down
2025-07-23 11:20:59 <ffoss> I notice I can't uninstall both busybox-ifupdown and ifupdown-ng? And when busybox is upgraded, busybox-ifupdown is purged and ifupdown-ng is automatically installed
2025-07-23 11:21:45 <ffoss> Is this expected behavior?
2025-07-23 11:25:02 <ikke> ffoss: What alpine release?
2025-07-23 11:26:55 <ffoss> ikke: edge
2025-07-23 11:35:59 <sertonix[m]> openrc has a dependency on ifupdown-any due to it's networking service. And ifupdown-ng has a higher provider priority so it is selected by default. It seems to be expected to me
2025-07-23 11:46:35 <quinq> Well, busybox-ifupdown being purged and ifupdown-ng automatically installed sounds suspect, but maybe that's not a correct description
2025-07-23 11:48:37 <ikke> Unless the system has not been updated for a very loing time
2025-07-23 11:49:24 <ffoss> Thats really what seems to happen, but I cant remember if i had busybox-ifupdown in world, or if it was just installed automatically after uninstalling ifupdown-ng
2025-07-23 11:50:41 <ffoss> probably the latter
2025-07-23 11:51:16 <ffoss> has happened a few times now
2025-07-23 19:52:49 <andar1an[m]> Sorry if silly question, but is there an argument or method to hold abuild rootbld open to do manual testing within that chroot instead if needing to create one?
2025-07-23 19:54:23 <andar1an[m]> I dk if that language makes sense, but I hope the gist does
2025-07-23 19:59:19 <Biswa96[m]> I use abuild -K to keep the files but did not test with rootbld.
2025-07-23 20:00:11 <andar1an[m]> Will look into that, thank you
2025-07-23 20:01:05 <andar1an[m]> Just wanna try to make sure the dependencies on my system don't interfere with depends of build
2025-07-23 20:33:28 <clandmeter> rootbld runs in a container, so your system deps should not matter
2025-07-23 20:42:50 <andar1an[m]> I understand, but I dont know how to manually test in it. I see an argument 'rootpkg'. 
2025-07-23 20:42:50 <andar1an[m]> I know I have the correct dependencies on my system because I am running the service now, but I did that a while ago and don't know best way to verify efficiently. 
2025-07-23 20:42:50 <andar1an[m]> Not quite sure what the best workflow is to make sure what I define in 'depends' in APKBUILD is correct . 
2025-07-23 20:43:54 <ikke> rootpkg and rootbld are unrelated
2025-07-23 20:43:59 <andar1an[m]> I can piece together dependencies from the same package in gentoo and arch, just want to make sure it is only what is needed.
2025-07-23 20:44:23 <ikke> rootbld would be a good way to figure out if you are missing anything
2025-07-23 20:44:35 <andar1an[m]> ikke: That's what it seemed in manpages, as rootpkg doesnt site abuild - rootbuild but I wasn't sure yet
2025-07-23 20:45:03 <andar1an[m]> ikke: For the runtime dependencies?
2025-07-23 20:45:13 <andar1an[m]> I know the makedepends are correct
2025-07-23 20:45:18 <ikke> ack
2025-07-23 20:45:37 <ikke> rootbld is not meant to create an environment to run things in
2025-07-23 20:46:00 <andar1an[m]> Haha that's how I feel. Jurutka has a good script for getting a chroot up quick. Just wondering what best way is
2025-07-23 20:46:27 <ikke> If you want to test services, then you would need openrc running
2025-07-23 20:46:35 <andar1an[m]> I could use that and just abuild in it, but thought there may be a way to use rootbld to do similar
2025-07-23 20:47:18 <ikke> rootbld is really meant to create a new chroot from scratch, run abuild, extract the packages, and cleanup everything again
2025-07-23 20:47:18 <andar1an[m]> Ya, and that I think I can get with the chroot setup script. Just not sure yet
2025-07-23 20:48:02 <andar1an[m]> ikke: That's what I usually do. Just didn't know if there was more to it for testing convenience 
2025-07-23 20:48:54 <andar1an[m]> Would be kinda cool for validating runtime dependencies, but I think with the chroot setup script it wouldn't be much different
2025-07-23 20:49:09 <ikke> It's a bit out of scope
2025-07-23 20:49:19 <andar1an[m]> Ya, agreed.
2025-07-23 20:49:30 <andar1an[m]> Was just being lazy haha
2025-07-23 20:50:49 <andar1an[m]> May be possible to use something like direnv with chroot setup script to make that testing part brainless
2025-07-23 20:51:26 <andar1an[m]> Will tinker. Thanks for help
2025-07-23 20:54:58 <andar1an[m]> abuild-roottest haha
2025-07-23 21:00:31 <andar1an[m]> I did see documentation somewhere about checking dependencies and showing with graphviz that would probably be awesome here too
2025-07-23 21:00:40 <ikke> apk dot
2025-07-23 21:06:00 <andar1an[m]> So cool! Haha
2025-07-23 21:06:18 <andar1an[m]> Diagrams make the heart happy haha
2025-07-23 21:09:34 <andar1an[m]> Ldd seems to only say it requires musl, which threw me
2025-07-23 21:09:56 <andar1an[m]> But also needs dynamic linking
2025-07-23 21:11:15 <andar1an[m]> Nvm, was querying daemon and not application. My bad
2025-07-23 21:28:38 <andar1an[m]> Are the `depends_` references in APKBUILD reference exhaustive? 
2025-07-23 21:28:39 <andar1an[m]> Can I define `depends_headless`?
2025-07-23 21:28:39 <andar1an[m]> If one makes a custom subpackage name like `$pkgname-headless`
2025-07-23 21:30:01 <andar1an[m]> Or would a second APKBUILD be desired
2025-07-23 22:00:03 <sertonix[m]> you could set depends in the split function:... (full message at <https://matrix.org/oftc/media/v1/media/download/AXZFiVb-HIR1CUpGkkslNnddbIJNn-Onklip0HsPKnbELfV_MXRL2t8fDR5CayeIlRKTjRVuDC4NawlvyydcZfdCeYgWYCyAAG1hdHJpeC5vcmcvWEFYYUVMS1BRbnJFY2RWSHdCRVRtcktl>)
2025-07-23 22:05:21 <andar1an[m]> Oops, I made separate packages. Will revert. Ty
2025-07-24 11:38:29 <raspbeguy> hello, can someone have a look at !81429 please?
2025-07-24 11:39:07 <raspbeguy> (which I just marked as ready)
2025-07-24 14:57:40 <realroot[m]> I made a branch to make a MR.
2025-07-24 14:57:40 <realroot[m]> I made it using the link from terminal when I `git push ` but it wants to merge all commits from other branches too
2025-07-24 14:57:55 <realroot[m]> can I remove other branches/commits?
2025-07-24 14:58:31 <ikke> The link that gitlab gives after you push only creates an MR, not a branch
2025-07-24 14:58:39 <ikke> The branch you would already have to create before that
2025-07-24 14:58:46 <ikke> (before you push)
2025-07-24 15:00:30 <realroot[m]> 1. I made a new branch to make a MR.
2025-07-24 15:00:30 <realroot[m]> 2. After git push --set"upstream new_branch" terminal gave me a link to MR
2025-07-24 15:00:30 <realroot[m]> 3. MR has all branches, unrelated too https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87560
2025-07-24 15:01:47 <achill> the mr can only contain a single source branch, you just have multiple comits there which are heads of your other branches
2025-07-24 15:02:33 <achill> and dont use git merge, we keep a flat history so please use git rebase eg. for rebasing against master
2025-07-24 15:03:02 <realroot[m]> i did not use git merge. what do I do now?
2025-07-24 15:05:28 <realroot[m]> not manually at least, sorry
2025-07-24 15:17:42 <realroot[m]> i think that i find out how
2025-07-24 15:20:56 <realroot[m]> how check why aports | Failed pipeline for testing/rocm-core | 8198cd58 ?
2025-07-24 15:21:35 <realroot[m]> ah i think that it's Merge request must not be draft. and Unresolved discussions must be resolved.
2025-07-24 18:41:29 <rhizoome> I discovered that a package I maintain uses c++26 with the new version I wanted to bump to and therefore needs gcc-15. Is that something that is coming? I am in no hurry, I just had this kind of problem the first time.
2025-07-24 18:42:22 <Biswa96[m]> which one?
2025-07-24 18:43:18 <rhizoome> !87741
2025-07-24 18:44:05 <rhizoome> they pretty heavly use c++26, there is no workaround.
2025-07-24 18:53:18 <Biswa96[m]> maybe, std::string(filename) in hyprctl/main.cpp:271:78
2025-07-24 19:07:54 <achill> rhizoome <https://matrix.to/#/%40oftc_rhizoome%3Apostmarketos.org>: you could temporarily use clang
2025-07-24 19:42:46 <Biswa96[m]> there is another compiler error in https://github.com/hyprwm/Hyprland/commit/b49d0ca20e4378db1e9abeb661d72f4c8c070db9. the project may need many changes for gcc 14 compatibility. 
2025-07-24 19:46:29 <rhizoome> achill: I thought about that. I that acceptable for alpine?
2025-07-24 19:47:24 <rhizoome> Biswa96[m]: people tried it and gave up, after all gcc-15 is out, just not wideley available yet.
2025-07-24 20:00:56 <achill> yeah sure thats fine
2025-07-24 20:01:11 <achill> i hope i'll get some motivation looking into gcc15 again
2025-07-24 20:10:36 <Biswa96[m]> is it required to pass every package build with gcc15 before updating it?
2025-07-24 20:24:27 <Ariadne> no
2025-07-24 20:24:52 <Ariadne> i might work on gcc15 this weekend
2025-07-24 20:53:47 <userdocs> rhizoome: would Alpine clang version 19.1.7 work?
2025-07-24 20:55:07 <rhizoome> userdocs: it should, but we are at clang20 already on edge, https://pkgs.alpinelinux.org/package/edge/main/x86_64/clang20
2025-07-24 20:55:35 <userdocs> rhizoome: that is the version zig cc shows
2025-07-24 20:55:54 <userdocs> which is a drop in for gcc
2025-07-24 20:56:35 <rhizoome> userdocs: 19 had partial integration of c++26 and clang 20 has full integration.
2025-07-24 20:56:47 <rhizoome> userdocs: I don't see a connection to zig.
2025-07-24 20:57:30 <userdocs> you can build it with zig
2025-07-24 20:59:06 <rhizoome> userdocs: build what with zig?
2025-07-24 20:59:43 <userdocs> hyprland, to see if it works with zig
2025-07-24 21:01:26 <rhizoome> no it doesn't
2025-07-24 22:25:19 <sertonix[m]> Generally it's best to use the latest clang version available in main.
2025-07-25 15:16:36 <invoked> i don't think zig is trying to replace mainstream compilers. it's adding value, potentially, if you have your own stuff in c that you want to reuse around a zig project.
2025-07-25 18:04:44 <Ariadne> gcc15 in edge :)
2025-07-25 18:08:48 <Biswa96[m]> that was quick. thank you <3
2025-07-25 18:11:06 <Ariadne> well a lot of rebuilds need to be done
2025-07-25 18:11:16 <Ariadne> cause gcc15 broke libstdc++ ABI :|
2025-07-25 18:13:12 <ikke> fun
2025-07-25 18:15:28 <ikke> "CC 15 changes the default language version for C compilation from -std=gnu17 to -std=gnu23." I suppose this will also have an impact
2025-07-25 18:15:40 <achill> yea quite a big and good one
2025-07-25 18:16:02 <achill> i tihnk im gonna rebuild all kernels since otherwise building modules e.g. with akms is broken
2025-07-25 18:16:15 <achill> see https://gitlab.alpinelinux.org/alpine/aports/-/issues/17308
2025-07-25 18:17:33 <Biswa96[m]> are new compiler or C/C++ changes fixed with patches or -Wno-foo-bar compiler flags?
2025-07-25 18:19:09 <ikke> Generally the former
2025-07-25 18:22:24 <skarnet> heads up: gdb fails to build with gcc 15 because of gnu23
2025-07-25 18:24:46 <Biswa96[m]> gdb 16 should not have that error
2025-07-25 18:27:08 <Ariadne> actually
2025-07-25 18:27:15 <Ariadne> i think i am going to back out gcc 15 for the moment
2025-07-25 18:27:23 <Ariadne> we had an abi break in libstdc++
2025-07-25 18:27:56 <ikke> should I kick the builders?
2025-07-25 18:31:12 <ikke> I think so
2025-07-25 18:31:46 <skarnet> Biswa96[m]: this is gdb 16.3, so unfortunately it has it
2025-07-25 18:32:35 <Ariadne> i think there is a bug where libstdc++ does not get built with TLS.
2025-07-25 18:34:14 <skarnet> that... would be bad
2025-07-25 18:34:29 <Ariadne> yes, i agree :)
2025-07-25 18:34:38 <Ariadne> hence the revert ;)
2025-07-25 18:35:00 <achill> ikke: did you kick the electron build on aarch64 aswell? xdd
2025-07-25 18:35:12 <ikke> yes, accidentally
2025-07-25 18:35:26 <achill> haha happens i guess
2025-07-25 18:45:11 <Ariadne> indeed... c++config.h on gcc 15 has: /* #undef _GLIBCXX_HAVE_TLS */
2025-07-25 18:45:30 <Ariadne> let me figure out why
2025-07-25 18:54:16 <sam_> yeah, indeed, no break is intended (or known to me)
2025-07-25 19:07:26 <Ariadne> hmm...
2025-07-25 19:07:34 <Ariadne> Segmentation fault
2025-07-25 19:07:34 <Ariadne> configure:26217: ./conftest
2025-07-25 19:07:40 <Ariadne> this is probably related :D
2025-07-25 19:08:02 <Ariadne> maybe this is loongarch-specific
2025-07-25 19:11:10 <Ariadne> #0  0x00000000000006d0 in ?? ()
2025-07-25 19:11:10 <Ariadne> #1  0x00007ffff7fc098c in libc_start_init () at src/env/__libc_start_main.c:64
2025-07-25 19:11:12 <Ariadne> hmmmmmm
2025-07-25 19:11:39 <Ariadne> 0x6d0 seems sus, possibly NULL+0x6d0
2025-07-25 19:14:06 <Ariadne> indeed, libc_start_main.c is just iterating over constructors
2025-07-25 19:28:34 <Ariadne> i flagged #alpine-loongarch for now :)
2025-07-25 21:08:10 <andar1an[m]> Hi all, smashing head against wall with this one
2025-07-25 21:08:13 <andar1an[m]> error: failed to run custom build command for `serde v1.0.219`
2025-07-25 21:08:13 <andar1an[m]>   process didn't exit successfully: `/home/andar1an/repos/alpine/aports/testing/lact/src/LACT-0.8.0/target/debug/build/serde-1d76c05eec658529/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
2025-07-25 21:08:13 <andar1an[m]> Caused by:
2025-07-25 21:08:29 <andar1an[m]> I have no idea why I am getting segfault in Abuild, but not locally with cargo
2025-07-25 21:09:16 <andar1an[m]> I don't think it is my memory (grabbed memtest to test), but if it is not segfaulting with just cargo build, I don't think it is memory
2025-07-25 21:09:41 <andar1an[m]> tried with rootbld too
2025-07-25 21:11:04 <andar1an[m]> I have seen some reference of setting lto = true to false in cargo.toml, but I don't know why that would change anything when it works on same system I am building with
2025-07-25 21:16:56 <andar1an[m]> I think I forgot a --locked on 1 line, nvm
2025-07-25 21:17:30 <andar1an[m]> nope, same issue. :(
2025-07-25 21:24:48 <andar1an[m]> dmesg:... (full message at <https://matrix.org/oftc/media/v1/media/download/AWCSDls1itcjL2Qja_13uJeUY7PZe_whGgc1sos_lnScVm5eb_47p67vnShV8vVl1qyAUSz5rCz2sr3IIyFwIRZCeYi5J1lQAG1hdHJpeC5vcmcvT3RtRW1LVVhhTndjY1JkbFdydkV6RmRX>)
2025-07-25 21:25:08 <andar1an[m]> different cores usually
2025-07-25 21:29:11 <Kriss[m]> Hey there
Are you looking for a way? A telegram game changer is here🥰 be a part of the change while the opportunity still stands!
inviting you to join this on tele.. he’s doing a great job 🥰 join with this link below
Are you looking for a way?
WE RISE BY LIFTING OTHERS
This telegram channel Has Changed The Life Of Lives out there. Don't Miss This Great Opportunity, It May Never Be There Again.
Hurry up Join The
2025-07-25 21:29:11 <Kriss[m]> Winning Teams And Enjoy Yourself
👇👇👇👇👇👇👇👇
https://t.me/+Cnk97ig86vUzNWZk
Join the telegram channel by clicking now
📣🎊❤️
2025-07-25 21:32:19 <skarnet> I'm looking for a way to get rid of spam forever
2025-07-26 00:07:48 <Timmy[m]> Greetings to all great minds in the room 🤗... (full message at <https://matrix.org/oftc/media/v1/media/download/AcZiI8XksAhYvSsDr_6ydhU-EhZM2O-_Zx8t8t3s_sSvX1SKYpILmg024amjd1bWRLrpqLpl-YJoXILjXVcBlrZCeYjCexUQAG1hdHJpeC5vcmcveGRLZ2prR1pna1RCRHFCcU5jUnppVEtx>)
2025-07-26 00:34:47 <roselandgoose> ugh
2025-07-26 07:50:02 <Ariadne> ikke: x86 passes this time, it was caused by patchset cleanup
2025-07-26 07:50:16 <Ariadne> i'm just validating that i unbroke static PIE now ;)
2025-07-26 07:50:21 <ikke> :)
2025-07-26 07:51:03 <Ariadne> (that was caused by 3 AM rebasing work that probably should have waited until morning)
2025-07-26 09:48:53 <Ariadne> ugh i hate ada
2025-07-26 10:16:05 <Ariadne> at some point i should get ada running on loongarch :)
2025-07-26 10:16:35 <Ariadne> i will still hate it but at least it will be more easily monitored
2025-07-26 11:20:26 <ovf> oh wow, gcc15. that must have been a lot of effort. congrats!
2025-07-26 11:24:21 <Ariadne> i can't identify any reason why ada isn't on loongarch.  we will need to cross-build it, but we can enable it there
2025-07-26 11:24:50 <Ariadne> 
ACTION will experiment later this weekend

2025-07-26 15:32:02 <Saijin_Naib[m]> Is it possible for the wxwidgets packages to be built with/against sdl2-compat instead of regular sdl2?
2025-07-26 16:01:25 <achill> <Saijin_Naib[m]> Is it possible for the wxwidgets packages to be built with/against sdl2-compat instead of regular sdl2?
2025-07-26 16:01:25 <achill> probably yes but i dont see any benefit tbh
2025-07-26 16:01:34 <achill> we should try to build against sdl3 directly if possible
2025-07-26 16:03:44 <andar1an[m]> Is there a non-iterative way to verify build targets that should be used when compiling? E.g is there something I can reference for architectures and supported features?
2025-07-26 16:04:29 <andar1an[m]> Right now I just grep Aports, and can learn a lot, but dk if that is best
2025-07-26 16:08:15 <achill> what do you mean by build targets
2025-07-26 16:12:03 <andar1an[m]> Sorry, architectures. Which is precursor to target for rust
2025-07-26 16:12:15 <andar1an[m]> I conflated
2025-07-26 16:13:16 <andar1an[m]> How do you go about determine architectures to build for? Just iteratively?
2025-07-26 16:13:40 <Biswa96[m]> like this one? cargo fetch --target="$CTARGET" --locked
2025-07-26 16:13:43 <achill> yeah usually the goal is to build for every arch
2025-07-26 16:14:17 <achill> for some architectures like s390x gui applications dont make the most sense but if it builds then it doesnt hurt to even enable this
2025-07-26 16:14:32 <andar1an[m]> Ya, I think that was causing segfaults for me yesterday, didnt Even think to iterate architectures until this morning
2025-07-26 16:15:28 <andar1an[m]> But is it mostly, if it builds for it build for it? Or should one take license like maybe some architectures are unlikely to use this package?
2025-07-26 16:15:49 <achill> yeah if it builds enable it
2025-07-26 16:16:15 <achill> usually only disable it if it fails to build or fails to run, or otherwise makes no sense e.g. some hardware depending stuff
2025-07-26 16:16:17 <andar1an[m]> achill: That is where I was leanin, ty
2025-07-26 16:16:43 <achill> yeah i'll try to document it more
2025-07-26 16:27:25 <andar1an[m]> It prbly is, I'm not the best reader haha
2025-07-26 16:35:07 <andar1an[m]> Does anyone know if renamemeat2 is in anything other than zfs-scripts?
2025-07-26 16:58:23 <ikke> Upgrading + rebooting the gitlab server
2025-07-26 17:03:07 <andar1an[m]> Are rename2 patches still necessary for fakeroot?
2025-07-26 17:06:28 <Saijin_Naib[m]> @achill I'm trying to package darkradiant for the Dark Mod, and it builds against wxwidgets, but that is conflicting on sdl2 soname, so I was hoping the sdl2-compat would fix that
2025-07-26 17:18:55 <Saijin_Naib[m]> I'll see if sdl3-dev can be a drop-in
2025-07-26 17:38:59 <achill> sdl2-compat and sdl2 have the same soname
2025-07-26 18:35:37 <Saijin_Naib[m]> Shoot, so using sdl2-compat will not fix the conflict?
2025-07-26 18:36:35 <Saijin_Naib[m]> https://bpa.st/XYMA
2025-07-26 18:37:31 <Saijin_Naib[m]> Oh god, wxwidets is way behind
2025-07-26 18:37:40 <Saijin_Naib[m]> We are shipping 3.2.5 and upstream is 3.3.1
2025-07-26 18:37:54 <achill> Saijin_Naib[m]: just use abuild rootbld in this case
2025-07-26 18:48:46 <Saijin_Naib[m]> I have never had that work for me, and I don't understand why
2025-07-26 18:48:52 <Saijin_Naib[m]> I'll try again
2025-07-26 19:15:54 <Ariadne> hi
2025-07-26 19:35:41 <achill> meow
2025-07-26 19:45:43 <mason> Hey all. I just went to open up a bug report, and I realized I needed to spin up an account. If there's something with access to the gitlab mail queue, I'm curious what tripped up. I never got the confirmation email. It would have been to: mason@blisses.org
2025-07-26 19:45:54 <mason> s/something/someone/
2025-07-26 19:46:17 <ikke> mason: let me check
2025-07-26 19:46:21 <mason> ikke: ty
2025-07-26 19:54:16 <ikke> gitlab is apparently using the wrong outgoing ipv6 address when sending the mail and relay is rejected, checking
2025-07-26 19:55:50 <mason> ikke: Oh, interesting. I only have MXes with IPv4 addresses, so I assume this is some internal pathing.
2025-07-26 19:56:00 <ikke> yes
2025-07-26 19:56:10 <ikke> It's not limited to just you
2025-07-26 19:58:54 <mason> ikke: No rush on my end, but if you ping me when it's working, I'll be happy to confirm the whole process completing from a new-account perspective.
2025-07-26 19:59:14 <ikke> ack
2025-07-26 20:00:14 <Ariadne> bootstrapping ada on loongarch64
2025-07-26 20:02:38 <ikke> hmm, since when is docker doing NAT for ipv6?
2025-07-26 20:12:47 <sam_> Saijin_Naib[m]: 3.3.x is a development release
2025-07-26 20:15:27 <Ariadne> ikke: will you have a few minutes to facilitate installing bootstrap ada packages on the loongarch64 edge builder?
2025-07-26 20:15:45 <ikke> yes
2025-07-26 20:16:05 <Ariadne> cool, it's almost done :)
2025-07-26 20:18:15 <Saijin_Naib[m]> @sam_ ah, indeed. 3.2.8 is what we should have. I'll see how that behaves alongside sdl3-dev
2025-07-26 20:45:11 <ikke> mason: did you by chance already receive something?
2025-07-26 20:53:01 <mason> ikke: looking
2025-07-26 20:53:28 <mason> Not seeing anything yet. I'll whack the "resend" button.
2025-07-26 20:54:12 <mason> I just hit resent. Watching the logs to see what comes in.
2025-07-26 20:54:18 <mason> s/resent/resend/
2025-07-26 20:54:30 <Ariadne> moving forward, i would like to require new architectures to have full gcc bootstrap of all languages as an acceptance criteria
2025-07-26 20:54:47 <Ariadne> (all languages we ship, that is)
2025-07-26 20:54:53 <ikke> mason: milter-reject: END-OF-MESSAGE from unknown
2025-07-26 20:55:05 <mason> ikke: That's not from my system.
2025-07-26 20:55:08 <Saijin_Naib[m]> achill, here goes nothing !87826
2025-07-26 20:55:11 <Ariadne> having to go back and rebootstrap later is annoying...
2025-07-26 20:55:34 <ikke> mason: no, just showing that it's still rejected for some reason
2025-07-26 20:55:42 <mason> ikke: Ah, ah, gotcha.
2025-07-26 20:57:10 <Ariadne> i am seeing no ipv6 connectivity to gitlab.a.o incidentally
2025-07-26 20:57:43 <ikke> Ariadne: yes, that's what I'm trouble shooting
2025-07-26 20:58:02 <ikke> Ariadne: It seems like docker (un)helpfully decided to add nat support for ipv6
2025-07-26 20:58:06 <ikke> which breaks the setup I have
2025-07-26 20:58:10 <Ariadne> thanks docker :(
2025-07-26 20:58:22 <mason> ikke: While I realize it's not strictly my fault, I'm still sorry for derailing your Saturday.
2025-07-26 20:58:36 <ikke> I'm happy you brought it up though
2025-07-26 20:58:43 <mason> Yeah, useful to know.
2025-07-26 20:58:57 <ikke> Can you try it one more time, I've whitelisted the IP now in the milter
2025-07-26 20:59:05 <mason> sure, half a sec
2025-07-26 20:59:42 <mason> ikke: That worked.
2025-07-26 20:59:48 <ikke> cool
2025-07-26 20:59:57 <ikke> It's a work-around, but at least sending mails works again
2025-07-26 21:01:31 <mason> ikke: While I've got your ear, is there a particular project that would be appropriate for the zfs issue?
2025-07-26 21:01:52 <ikke> mason: most likely aports
2025-07-26 21:02:02 <ikke> what zfs issue?
2025-07-26 21:02:03 <mason> aports it is - thank you again
2025-07-26 21:02:25 <mason> It's the thing I mentioned in the main channel - the Alpine ZFS package doesn't seem to ship compatibility files.
2025-07-26 21:02:49 <mason> Oh, meant for that to be here.
2025-07-26 21:02:50 <mason> ikke: see https://bpa.st/PE6Q
2025-07-26 21:03:51 <mason> Won't be a problem in many cases, but I end up using compatibility levels here since I ship datasets between various OSes with potentially different OpenZFS versions, so I lock down the compatibility set I want everywhere, so everything is happy.
2025-07-26 21:04:07 <mason> It's bitten me in the past.
2025-07-26 21:12:03 <Saijin_Naib[m]> If I bump wxwidgets, does everything that uses it need a rebuild too>
2025-07-26 21:12:16 <Saijin_Naib[m]> Or is it one of those things that doesn't matter once the other program is built?
2025-07-26 21:13:09 <Ariadne> should be fine to just bump
2025-07-26 21:13:22 <Saijin_Naib[m]> Awesome, thanks
2025-07-26 21:13:44 <Saijin_Naib[m]> As an aside, what is the x86_64 builder? That thing is monstrously fast compared to my craptop
2025-07-26 21:33:35 <ikke> some HP server, nothing too fancy
2025-07-26 21:53:35 <haesbaert> Is `abuild check` somehow making a `make test` run in parallel?  have some tests that run as if someoned passed -j$(nproc), is there some job server chicanery I'm missing?
2025-07-26 21:56:02 <achill> the default MAKEFLAGS in the abuild conf is set to -j $JOBS or something
2025-07-26 21:56:41 <haesbaert> oh thanks, that answers it
2025-07-26 22:56:17 <userdocs> i am trying to build iperf2, but it i have linux-headers installed make errors out, i see this https://0x0.st/854d.txt
2025-07-26 22:56:48 <userdocs> for v2.2.1, is this the fix in master? https://sourceforge.net/p/iperf2/code/ci/a25566dd66fb0ca951b3b6f6fa5a4bfaac276c71/tree/src/checksums.c?diff=86786471f578bdb1d59b3769178d6d1b72d4b88d
2025-07-26 22:56:57 <userdocs> because master builds fine
2025-07-26 22:58:30 <userdocs> i can build v2.2.1 if i don't install linux-headers.
2025-07-27 00:12:20 <Ariadne> userdocs: looks promising
2025-07-27 00:12:58 <Ariadne> looks like build.a.o is broken again
2025-07-27 02:25:28 <Saijin_Naib[m]> Can anyone sanity-check !87826 for me? This is a bigger one for me to touch
2025-07-27 02:27:27 <sam_> why not 3.2.8.1 btw?
2025-07-27 02:31:23 <Saijin_Naib[m]> Ah, crap
2025-07-27 02:32:23 <Saijin_Naib[m]> Because that wasn't on the wxwidgets.org site
2025-07-27 02:32:31 <Saijin_Naib[m]> Fixing now, thanks for the heads up
2025-07-27 02:36:17 <sam_> np
2025-07-27 06:45:48 <ikke> I need to restart gitlab really quick to make some network related changes
2025-07-27 06:56:07 <ikke> yay, ipv6 for gitlab is working again
2025-07-27 06:57:27 <ikke> om.docker.network.bridge.gateway_mode_ipv6: routed
2025-07-27 06:57:30 <ikke> com.docker.network.bridge.gateway_mode_ipv6: routed
2025-07-27 06:58:22 <ikke> 
ACTION should read docker changelogs :P

2025-07-27 07:13:59 <Biswa96[m]> testing changes in production on weekend? 😰
2025-07-27 07:15:07 <ikke> The weekends is when I have most time, and when relatively few people are actively doing work (especially sunday morning)
2025-07-27 07:54:10 <userdocs> iperf2 master requires linux headers whereas 2.2.1 will fail if present. i guess a chaneg that will effect the recipe on next release.
2025-07-27 09:49:43 <ffoss> After talking with a maintainer, or former maintainer (forgot his name), the other day, we concluded on suggesting a "no-ifupdown" package to prevent installing any ifupdown-any package for they who do not want one
2025-07-27 09:51:04 <ffoss> Should I open an issue for this or can i just go straight to submitting an mr?
2025-07-27 09:51:59 <ffoss> Also, no-ifupdown vs ifupdown-none
2025-07-27 10:13:02 <achill> there already exists busybox-ifupdown
2025-07-27 10:19:07 <Ariadne> ffoss: why not `apk add -t ifupdown-any` ?
2025-07-27 10:21:48 <ffoss> Ariadne: oh, I guess that solved it
2025-07-27 10:24:15 <ffoss> achill: couldn't delete both busybox-ifupdown and ifupdown-ng at the same time. and if I stuck with busybox-ifupdown, it would be replaced by ifupdown-ng on openrc upgrade
2025-07-27 10:24:53 <ffoss> as openrc depends on ifupdown-any and, and ifupdown-ng provides ifupdown-any with a higher priotiry than busybox-ifupdown
2025-07-27 11:48:02 <ajhalili2006> Hi, I am trying to access gitlab.al.o but got blocked for being flagged as scrapper even though it's not the case(request ID: bceced70cc602f727e2b1a4fb1025267)
2025-07-27 11:49:03 <ikke> ajhalili2006: let me check
2025-07-27 11:50:41 <ajhalili2006> ikke: for context, I am on my home ISP (Globe at Home Fiber) w/o anything in between (i.e. Cloudflare WARP) when trying to access it
2025-07-27 11:51:00 <ikke> It's not rejecting you based on ISP
2025-07-27 11:51:32 <ajhalili2006> might be a temporary hiccup while on Chrome mobile, but thanks for note
2025-07-27 11:51:40 <ikke> ajhalili2006: Are you blocking cookies?
2025-07-27 11:52:23 <ajhalili2006> ikke: just third-party cookies, but I can allowlist them on my side if needed
2025-07-27 11:52:37 <ikke> Should be a first-party cookie
2025-07-27 11:53:38 <ajhalili2006> ikke: now working on my side w/o problem, thanks again
2025-07-27 11:54:24 <haesbaert> Say I need root priviledges for a check() in APKBUILD? They're tests that install bpf probes and whatnot, not file accesses, so fakeroot(1) is not an option, what's the common approach?
2025-07-27 11:54:47 <ikke> You cannot get it
2025-07-27 11:55:03 <haesbaert> fair enough, so just manual testing I guess
2025-07-27 11:55:50 <ikke> ajhalili2006: alright, and sorry for the annoyance
2025-07-27 11:58:53 <rhizoome> Ariadne: thanks, the package using c++26 features builds and works now with gcc-15.
2025-07-27 13:34:24 <ikke> Hmm, the build-edge-s390x container is not starting properly. It seems /bin/init is in a busyloop (100% cpu, no strace output)
2025-07-27 13:47:23 <ikke> Ariadne: I have a feeling something is wrong with musl on s390x 
2025-07-27 13:47:27 <ikke> after the upgrade
2025-07-27 13:57:24 <ikke> Yup, the container works again after restoring musl from -r14
2025-07-27 14:04:48 <ikke> So I suspect b959c09512b88b39bd9e5d16c94b863f4c89abf0 broke s390x
2025-07-27 14:05:05 <ikke> I've pinned musl to -r14 for now
2025-07-27 15:09:59 <sertonix[m]> Ariadne: regarding languages enabled with gcc, should we backport my fixes for dlang on 32-bit musl before upstream merges them? https://github.com/dlang/dmd/pull/21249
2025-07-27 15:10:54 <sertonix[m]> Or do you have any idea on how to get upstream to accept the changes
2025-07-27 20:27:13 <Ariadne> ikke: weird.  i will see if i can reproduce.  i don't know why that would break s390x.
2025-07-27 20:28:04 <ovf> out of interest, who's running alpine on s390x, if that's public information?
2025-07-27 20:54:29 <achill> i do lol
2025-07-28 06:37:30 <prabu> nmeum, can you please confirm if the configuration file locations for OpenRC user services mentioned in https://wiki.alpinelinux.org/wiki/OpenRC#User_services are correct. I saw bugs reported by Xorg users. So, i've made changes by testing with dwm 
2025-07-28 06:53:33 <raspbeguy> Hello, I'm trying to build https://github.com/ovh/shai (release 0.1.0) but I encounter this error https://termbin.com/pb27 (I explained further in #alpine-rust)
2025-07-28 07:13:40 <Biswa96[m]> raspbeguy: that similar error happened with below https://github.com/facebookincubator/below/issues/8229
2025-07-28 07:14:00 <raspbeguy> yep I linked it in the other room
2025-07-28 07:14:30 <Biswa96[m]> probable workaround https://github.com/termux/termux-packages/pull/19930/files
2025-07-28 07:15:45 <Biswa96[m]> I am not familiar with rust, just recalled that from the error.
2025-07-28 07:52:30 <raspbeguy> yep that way it work. however I'm curious about whether it's related to musl/glibc difference or not
2025-07-28 10:10:15 <userdocs> i tested binutls 2.45 it already has the riscv64 static-pie patch.
2025-07-28 11:40:46 <achill> i kinda think we should start to think of a policy regarding AI, contributions aswell as packages
2025-07-28 11:41:30 <achill> maybe ill open a tsc issue
2025-07-28 12:07:16 <roselandgoose> achill: have there been many (probable) LLM-written/assisted contributions yet?
2025-07-28 12:07:30 <achill> if only we'd know
2025-07-28 12:09:01 <andar1an[m]> I saw an article about similar for linux kernel policy last week
2025-07-28 12:09:03 <roselandgoose> ill take that to mean that there hasnt been any super obviously low-effort LLM spam attempts yet, at least
2025-07-28 12:09:46 <achill> now that i know of
2025-07-28 12:09:49 <achill> *not
2025-07-28 12:10:15 <andar1an[m]> https://lwn.net/Articles/1031473/
2025-07-28 12:13:28 <andar1an[m]> May I please squeeze in a quick question to just get direction if possible? 
2025-07-28 12:13:28 <andar1an[m]> Is it common for fake root patches still when encountering renameat2 build errors? If so I will look into today, just dont wanna waste time if bad direction.
2025-07-28 12:15:46 <userdocs> the ai configuration files is a good idea. probably more likely to achieve a desired outcome than hoping people delcare they used it.
2025-07-28 12:16:12 <userdocs> bypassing the middle man and workign direct with AI :D
2025-07-28 12:16:34 <achill> or just dont work with ai
2025-07-28 12:18:02 <userdocs> the lwn link is as good an approach as you will get. try to configure the ai as best you can on a project level, even if they don't delcare it, more chance to be a better patch?
2025-07-28 12:18:49 <userdocs> they do decalre it, it needs mroe resources to review. if that is a net negative over time i guess they'd ban it.
2025-07-28 12:19:29 <andar1an[m]> Brains are neural networks too. If AI is going to be worked with, there needs to be a pipeline of individual contributor development too, otherwise in 10 years who will be able to assess what is good or not. Have no idea how one would do that in open source
2025-07-28 12:20:34 <userdocs> probably the most usefull thing is ending up with some massive ai config file per project.
2025-07-28 12:20:59 <userdocs> all the do's and don't, gotchas and stuff.
2025-07-28 12:22:00 <userdocs> the linux idea, tells the ai to decalre itself in the patch note. that will probably work more most examples.
2025-07-28 12:22:15 <userdocs> instead of hoping the user does it.
2025-07-28 12:22:24 <andar1an[m]> And it doesn't allow sign off
2025-07-28 12:23:21 <andar1an[m]> Requires a human to sign off. My worry becomes in x years as reviewers change, how will the quality of those sign offs change
2025-07-28 12:24:35 <userdocs> i think the lwn approach makes sense. you can't stop it, but you can try to configure the ai to do things you other rely on the user to do.
2025-07-28 12:27:52 <andar1an[m]> I felt it seemed reasonable too, but I didn't look into in depth. And it worries me that ability of humans to sign off in future isn't a factor. I just don't know how one would or could make that a factor. With linux kernel maybe they could use foundation to develop contributors to make sure there are people capable of doing so. But without a people pipeline I dk.
2025-07-28 12:30:46 <userdocs> i don't know about that, in the here and now it seems sensible to bypass the user and config the ai directly for conistency of outcome
2025-07-28 12:32:02 <andar1an[m]> Are you talking about the configuration of the ai or signing off on commits and tracking commits that are developed with AI to be merged?
2025-07-28 12:33:03 <andar1an[m]> The lwn approach has 2 patches that address these issues separately
2025-07-28 12:35:26 <andar1an[m]> I dk what lwn is, is it better to say the proposed linux kernel approach? That was just a link the showed it cleanly when I searched
2025-07-28 12:37:05 <donoban> hi, is there some problem with gitlab? I get an error when trying to send a pull request
2025-07-28 12:42:37 <ikke> donoban: probably means the target branch on your fork is too outdated 
2025-07-28 12:51:06 <donoban> ah, makes sense sorry
2025-07-28 12:58:11 <userdocs> andar1an[m]: the config, the signing off seems to be a different issue and says "it represents a legal certification" which is this? https://developercertificate.org 
2025-07-28 13:00:23 <andar1an[m]> Ya, I agree with config part, kinda like having an editorconfig for llm
2025-07-28 13:00:35 <userdocs> a maclicous actor won't care about any of this anyway right? it's more about consistency of outcome when it comes to submissions.
2025-07-28 13:01:36 <andar1an[m]> ya, my biggest concern about AI has been rate of change, and down stream issues that will arise. And one of the big issues I feel is relevant is the ability of someone to sign off. 
2025-07-28 13:01:54 <andar1an[m]> (in the future)
2025-07-28 13:02:29 <userdocs> that seems like a liability concern for the lawyers?
2025-07-28 13:02:46 <userdocs> god know, they need the work.
2025-07-28 13:02:47 <andar1an[m]> I think it is a distribution concern for quality 
2025-07-28 13:03:05 <andar1an[m]> How do do make sure that you have people that are able to make quality sign offs in 5 years? 
2025-07-28 13:03:10 <andar1an[m]> 10 years?
2025-07-28 13:03:36 <andar1an[m]> Is there some requirement other than a human needing to sign off for example
2025-07-28 13:04:42 <andar1an[m]> maybe you need multiple sign offs for AI, maybe needs to be after x amounts of merges? All hypothetical and probably stupid, but the question I don't think is silly. 
2025-07-28 13:05:30 <andar1an[m]> (like signer needs to have made x manual merges)
2025-07-28 13:06:04 <userdocs> i don't know about that, maybe the ai should declare all sources used in assistance. i know claude has links to sources when providing info. mostly a git repo it used.
2025-07-28 13:06:11 <ikke> Alpine Linux does not have a sign-off requirement, so that part is less of a concern 
2025-07-28 13:06:42 <andar1an[m]> In my experience with llms, there is so much that looks right, but it is more often than not incorrect
2025-07-28 13:07:00 <andar1an[m]> RAG is not well implemented yet
2025-07-28 13:07:22 <andar1an[m]> and traceability is a problem
2025-07-28 13:07:45 <userdocs> i had claude trying to pacth gcc 15 and it was using a git repo that was patching same file but in gcc 5 abotu 8 years ago.
2025-07-28 13:07:55 <andar1an[m]> so it may site links, but it may not be giving accurate information or conflated information from various links
2025-07-28 13:08:04 <andar1an[m]> cite? my bad
2025-07-28 13:08:21 <andar1an[m]> oh no, haha
2025-07-28 13:08:38 <andar1an[m]> my first questions are always, what is todays date, and show me a factory pattern in rust haha
2025-07-28 13:08:47 <andar1an[m]> one day RAG may make those better
2025-07-28 13:11:04 <userdocs> so i guess this really what someone wants to know when seeing an ai commit, which ai did it, did it follow basic project rules and maybe which sources it used to assist.
2025-07-28 13:11:06 <andar1an[m]> i personally ideated thoughts of mirror neuron implementation for a royalty system which could also be used for traceability. I saw OpenAI experiment with something like that after, but I didn't follow up to see if it was feasible. 
2025-07-28 13:11:37 <andar1an[m]> but sources are hard
2025-07-28 13:11:49 <andar1an[m]> it isn't just retrieving data from a table right now
2025-07-28 13:13:49 <andar1an[m]> unless you mean code context 
2025-07-28 13:15:24 <userdocs> i see claude provide sources for certain examples. mostly git repos.
2025-07-28 13:16:33 <andar1an[m]> The factory pattern question I referenced often regurgitates rust book doc example. But how can you tell what version? what date? what commit hash? 
2025-07-28 13:17:02 <andar1an[m]> does claude do that? would that be part of commit message?
2025-07-28 13:17:59 <userdocs> i only use it through vscode via copilot. maybe ask it for the reference details?
2025-07-28 13:18:14 <andar1an[m]> I only do local llm
2025-07-28 13:18:38 <andar1an[m]> but then that comes in with, linux kernel reference for example is supporting more than claude 
2025-07-28 13:20:13 <andar1an[m]> so how in Alpine is it constrained so that all integrated models do this?
2025-07-28 13:21:09 <andar1an[m]> I guess maintainers could just pick 1 to start
2025-07-28 13:23:11 <andar1an[m]> that doesn't seem the Alpine way though
2025-07-28 18:26:10 <Saijin_Naib[m]> Is that kernel rebuild coming so AKMS modules can build, or just wait until next stable kernel point release later this week>
2025-07-28 18:28:47 <ikke> ncopa is away for a while
2025-07-28 19:20:47 <Saijin_Naib[m]> Alright, not critical
2025-07-28 19:31:54 <Quantum_3[m]> if im making a APKBUILD is it required to have maintainer/contributor filled out
2025-07-28 19:32:20 <ikke> maintainer is required, yes
2025-07-28 19:34:22 <Quantum_3[m]> can i keep name/email private or no
2025-07-28 19:39:18 <ikke> You have to use a roubable email address. The name can be a nickname
2025-07-28 19:39:28 <ikke> routable*
2025-07-28 19:40:40 <Quantum_3[m]> so i could have like a email alias that forwards to my main email?
2025-07-28 19:40:52 <ikke> yes
2025-07-28 19:43:43 <Quantum_3[m]> ok thanks
2025-07-28 22:01:30 <achill> <Saijin_Naib[m]> Is that kernel rebuild coming so AKMS modules can build, or just wait until next stable kernel point release later this week>
2025-07-28 22:01:30 <achill> oh right i wanted to do that after the gcc upgrade
2025-07-28 22:01:45 <achill> ehh idk if i'll do that today
2025-07-28 23:18:31 <Saijin_Naib[m]> Fair enough!
2025-07-29 00:41:44 <sertonix[m]> lanodan: Currently the source of testing/py3-pygelbooru is broken, could you maybe take a look at finding a replacment?
2025-07-29 01:12:54 <lanodan> How broken? GitHub seems down… https://www.githubstatus.com/
2025-07-29 03:38:26 <qaqland> any example here? https://docs.alpinelinux.org/governance/0.1a/Teams/developers.html#_requirements 
2025-07-29 03:38:27 <qaqland> New applicants must have actively contributed to Alpine in a meaningful way during the last 6 months.
2025-07-29 09:30:55 <Biswa96[m]> build-s390x failed for some reason https://gitlab.alpinelinux.org/Biswa96/aports/-/jobs/1951670
2025-07-29 09:36:18 <ikke> There is a regression in the musl package 
2025-07-29 10:14:38 <pabloyoyoista> qaqland: There are some in the template, that unfortunately is not yet in the Council repo, we're slowly working towards it
2025-07-29 10:15:17 <pabloyoyoista> Some examples:
2025-07-29 10:15:17 <pabloyoyoista> providing support to others on the issue tracker or chat rooms
2025-07-29 10:15:17 <pabloyoyoista> submitting patches to projects under Alpine Linux
2025-07-29 10:15:17 <pabloyoyoista> fixing build failures
2025-07-29 10:15:17 <pabloyoyoista> performing code reviews
2025-07-29 10:15:18 <pabloyoyoista> making accessibility improvements
2025-07-29 10:16:16 <pabloyoyoista> But these are my personal craft. Maybe I can add some of those to https://gitlab.alpinelinux.org/alpine/docs/governance/-/merge_requests/2
2025-07-29 10:16:25 <pabloyoyoista> So they can get reviewed by the Council
2025-07-29 10:17:52 <pabloyoyoista> Until that is done, you could ask people that you'd consider possible endorsers
2025-07-29 10:18:26 <pabloyoyoista> They might have their own personal opinions and could help figure that out
2025-07-29 10:24:47 <qaqland> looking back at my commits, most of them are bump-versions :/
2025-07-29 10:35:13 <userdocs> bring systemd to alpine. that'll do it.
2025-07-29 10:49:55 <pabloyoyoista> qaqland: If you want to become an Alpine dev talk with some developers, they may have ideas :)
2025-07-29 11:00:58 <achill> <userdocs> bring systemd to alpine. that'll do it.
2025-07-29 11:00:58 <achill> its not like there is a technical blocker right now
2025-07-29 11:01:14 <achill> so most stuff needed is communication with humans :)
2025-07-29 11:06:23 <f_> systemd-alpined: alpinelinux becomes a systemd daemon
2025-07-29 11:08:38 <qaqland> pabloyoyoista: thx
2025-07-29 11:09:09 <f_> (I'm joking of course, would be neat to see systemd in aports though)
2025-07-29 11:09:14 <f_> 04:38 <qaqland> New applicants must have actively contributed to Alpine in a meaningful way during the last 6 months.
2025-07-29 11:09:32 <f_> Hmm, what does "meaningful" mean?
2025-07-29 11:12:45 <f_> Hm, "New applicants must be willing to share personal details and go into a call with video with members of the Council. This information must remain private within the Council, but can be seen akin of a background check. Examples of information requested might be legal name, phone number, address, or similar."
2025-07-29 11:13:18 <f_> interesting
2025-07-29 11:29:11 <qaqland> i have no objection to the background check.
2025-07-29 13:14:43 <andar1an[m]> Is Alpine dev a volunteer role? 
2025-07-29 13:15:31 <andar1an[m]> Will there be any blockers to trying to contribute without being an alpine dev? Is there like alpine fan roles haha
2025-07-29 13:18:15 <andar1an[m]> I learn a lot from alpine, and would be open to background check if it meant more trust when trying to contribute, but I don't think I am good enough to be an alpine dev yet
2025-07-29 13:18:45 <achill> its totally fine not being a "developer" per se, you can always contribute just as much without the role
2025-07-29 13:18:54 <andar1an[m]> cool
2025-07-29 13:19:25 <achill> i mean youre still a developer but without commit access then, developer always sounds like a different type of role
2025-07-29 13:19:46 <achill> but it is more like "developer + commit access" or "commiter" or something like that
2025-07-29 13:41:05 <userdocs> is s390x platform broken on edge? i am getting stuck on busy box https://0x0.st/8Ren.txt
2025-07-29 13:41:16 <userdocs> this is locally and on github actions.
2025-07-29 13:49:40 <achill> yeah
2025-07-29 13:49:42 <achill> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87945
2025-07-29 13:52:16 <userdocs> it was only s390x that hung, my workflows runs all arches in the matrix.
2025-07-29 13:52:23 <userdocs> just for context
2025-07-29 13:52:25 <achill> yes
2025-07-29 13:52:40 <achill> a conditional patch would just make things harder imo
2025-07-29 13:52:50 <achill> might even fall off the radar
2025-07-29 14:07:34 <userdocs> achill: is this the same thing what ikke mentioned: @ikke | Hmm, the build-edge-s390x container is not starting properly. It seems /bin/init is in a busyloop (100% cpu, no strace output)
2025-07-29 14:07:42 <achill> yes it is
2025-07-29 14:08:07 <achill> the bogus commit is now reverted
2025-07-29 14:09:05 <userdocs> ok. thanks
2025-07-29 14:13:53 <achill> oh apparently this did not fix it what
2025-07-29 14:18:43 <userdocs> (╯°□°)╯︵ ┻━┻ 
2025-07-29 14:19:37 <achill> i guess maybe the rebuild with gcc15 caused that
2025-07-29 14:19:39 <achill> idk
2025-07-29 14:21:46 <userdocs> if these stubs are removed, rebuild gcc 15 will fail?
2025-07-29 14:22:15 <userdocs> feels like ending up back on gcc 14 is the end of this thread
2025-07-29 15:51:06 <achill> no before i'd do that i'd waste my entire evening looking into it
2025-07-29 15:51:30 <achill> maybe its the binutils upgrade
2025-07-29 15:52:23 <ikke> possibly
2025-07-29 15:53:01 <achill> ah no that was after the musl thingy
2025-07-29 15:53:36 <userdocs> binutils 2.45?
2025-07-29 15:54:29 <userdocs> that has 3 of your 4 patches included btw
2025-07-29 15:54:31 <achill> yeah but that was after the broken musl got built, maybe its the static-pie patch. idk i could bisect it but i would have to start over a new chroot if it fails :))
2025-07-29 15:54:42 <achill> i know
2025-07-29 15:54:56 <ikke> I fixed the chroot by manually extracting the -r14 package on it
2025-07-29 15:55:00 <ikke> I still have it if you need it
2025-07-29 15:55:09 <achill> yeah that would be helpful
2025-07-29 15:55:13 <ikke> (s/chroot/edge build container)
2025-07-29 15:57:30 <ikke> achill: https://dev.alpinelinux.org/~kevin/musl-r14-s390x/
2025-07-29 15:59:30 <achill> thx
2025-07-29 16:16:11 <henrix> ptrc: hi! I was wondering if you remember the details on community/xapian-bindings being disabled
2025-07-29 16:16:20 <henrix> and if I can expect it to be enabled again soon, of course :-)
2025-07-29 16:16:50 <ptrc> henrix: there's a comment on there, it was blocked by uvicorn and thus didn't build
2025-07-29 16:17:33 <ptrc> uvicorn is still disabled though, so it might take a while
2025-07-29 16:18:52 <henrix> yeah, I saw the comment.  ok, so nothing soon.  thanks for the update ptrc 
2025-07-29 16:19:08 <userdocs> achill: in the issue comment you say not sure why it was added, i remember this from the other day https://i.imgur.com/5IeLx3x.png
2025-07-29 17:03:21 <haesbaert> is s390x being funny in the CI?
2025-07-29 17:03:59 <haesbaert> I have a port that is marked as amd64/arm64 only but it's still yellow on s390x: "the build has not started yet"
2025-07-29 17:07:14 <ikke> haesbaert: yes, there's a bug 
2025-07-29 17:07:15 <achill> not just in CI but the musl package is broken on s390x entirely
2025-07-29 17:07:31 <achill> you can ignore it
2025-07-29 17:13:40 <haesbaert> awesome
2025-07-29 18:05:52 <Ariadne> the static-pie patch is from musl-cross-make itself
2025-07-29 18:07:47 <Ariadne> i don’t think it’s that fwiw
2025-07-29 18:12:34 <achill> yeah see https://gitlab.alpinelinux.org/alpine/aports/-/commit/522c06b923f112f520221f01123677a68f73fc40
2025-07-29 18:12:55 <achill> apparently randomly accusing patches doesnt help lol
2025-07-29 18:15:44 <Biswa96[m]> Just one alphabet fixed the issue ⸜( •ᴗ• )⸝
2025-07-29 18:17:47 <Ariadne> achill: i think this patch is correct, but to be certain i've powered up my s390x machine
2025-07-29 18:19:47 <userdocs> this is in musl master? https://git.musl-libc.org/cgit/musl/commit/arch/s390x/reloc.h?id=5be920e9103fb7c7e492af7cd8bf56a71ae0b2c6
2025-07-29 18:21:23 <Ariadne> yes, it is the same patch
2025-07-29 18:24:16 <userdocs> would that effect mcm? i only build from master so i wonder if i missed it.
2025-07-29 18:24:36 <Ariadne> yes, mcm needs the patch too
2025-07-29 18:26:01 <userdocs> all version fo 14 + 15?
2025-07-29 18:26:30 <Ariadne> just period, the code in musl is defective
2025-07-29 18:26:38 <Ariadne> it is not a GCC defect
2025-07-29 18:27:19 <userdocs> ok, thanks
2025-07-29 18:28:11 <userdocs> i just realised i was thinking to patch gcc not musl. oops
2025-07-29 18:32:57 <achill> <Ariadne> achill: i think this patch is correct, but to be certain i've powered up my s390x machine
2025-07-29 18:32:57 <achill> yeah ive verified it already on my VM
2025-07-29 18:33:25 <fossdd> urgh my matrix-bridge really messes these kind of replies up
2025-07-29 18:33:28 <fossdd> fucking matrix
2025-07-29 18:34:00 <Ariadne> also, please do not blindly commit ABI-breaking changes to musl in future :p
2025-07-29 18:35:42 <achill> yeah shouldve probably avoided that
2025-07-29 18:39:47 <userdocs> ok, so why did this patch mention gcc 14 but the issue only occured on gcc 15 here?
2025-07-29 18:41:57 <userdocs> that's why i confused gcc14/15 with the mcm question
2025-07-29 18:43:50 <Ariadne> because gcc 14 introduced the optimization
2025-07-29 18:44:09 <Ariadne> we probably did not hit it in 14 due to our CFLAGS
2025-07-29 18:53:40 <Ariadne> achill: confirmed on real hardware that 522c06b fixes it
2025-07-29 18:53:47 <Ariadne> achill: thanks for digging :)
2025-07-29 19:02:53 <userdocs> there was talk of a 1.2.6 being almost ready.
2025-07-29 19:18:48 <ikke> upgraded the builder now to -r17
2025-07-29 19:34:27 <userdocs> docker s390x works for me again, so thanks for that.
2025-07-30 11:38:59 <LeslieLevy[m]> Hey there! I wanted to let you know that I have a Telegram channel where I share some amazing Verified sauce and soft cashout... (full message at <https://matrix.org/oftc/media/v1/media/download/Aa4xIeULiCqeBWZxBeeLdlh3ngGrs1P7xLbPNjzt4h6WD-GLz93i-IAkB6pL6JRTFWAUlmsG-zLRjRx1ZQsGXKVCeYoznvBgAG1hdHJpeC5vcmcvVkl1eHdxWVJDWFJrZmxweExVWlRTY05u>)
2025-07-30 14:47:35 <andar1an[m]> I am having trouble understanding the current state of musl related to renameat2. May I please have some help.... (full message at <https://matrix.org/oftc/media/v1/media/download/ASaoKeWxhYzR5XdI_80P7nRmqSamPynjznbrpQ7u-PnHeHM8YlT0MYOHrUOiM76HabKeqV9SspNj0YaKUgsYgYNCeYo-aYzwAG1hdHJpeC5vcmcvdFB2UXp0aVVEWkFkeEJxTWJERm9HV3Rv>)
2025-07-30 14:48:35 <pj> andar1an: don't post long messages
2025-07-30 14:48:44 <pj> they don't send over to irc
2025-07-30 14:48:44 <andar1an[m]> sorry
2025-07-30 14:48:52 <f_> "long": >=3 lines
2025-07-30 14:49:01 <andar1an[m]> understood
2025-07-30 14:49:13 <f_> pj: Maybe you could perhaps raise the limit (assuming you still have mod on matrix)
2025-07-30 14:49:14 <andar1an[m]> in nutshell, is musl expecting a version bump soon
2025-07-30 14:49:27 <f_> to something like 10
2025-07-30 14:49:49 <f_> https://matrix-org.github.io/matrix-appservice-irc/latest/room_configuration.html
2025-07-30 14:49:51 <pj> I mean, generally such questions should be asked in #musl
2025-07-30 14:50:19 <andar1an[m]> If I use IRC client, can I just type away without concern? I have Halloy
2025-07-30 14:50:26 <f_> of course
2025-07-30 14:50:32 <andar1an[m]> I understand, but it is related to abuild
2025-07-30 14:50:46 <andar1an[m]> will go to that channel though
2025-07-30 14:51:09 <andar1an[m]> was trying to search for musl matrix, assume that is irc?
2025-07-30 14:52:21 <pj> it is irc
2025-07-30 14:52:29 <f_> yes
2025-07-30 14:52:34 <f_> #musl on Libera.Chat
2025-07-30 14:52:43 <andar1an[m]> ty
2025-07-30 14:52:46 <pj> I am having trouble understanding the current state of musl related to renameat2. May I please have some help.... (full message at <https://matrix.org/oftc/media/v1/media/download/AYgAnWrvlteOkm7o39QH40K322jNTDCR5W_4ZqviMuLbNFEniHknemd22THIb41VIDrLMgHleeGT0WdldT72XF9CeYo-tWCQAG1hdHJpeC5vcmcvREtTVXBZb3piaHJRb1FHYmJJY1FiWFZk>)
2025-07-30 14:53:00 <pj> f_: nope, did not work lol
2025-07-30 14:53:06 <f_> you sure?
2025-07-30 14:53:08 <f_> one moment
2025-07-30 14:53:10 <andar1an[m]> I saw something
2025-07-30 14:53:17 <andar1an[m]> it deleted though
2025-07-30 14:53:24 <pj> i sent the appservice event and it did not change the mssage on irc
2025-07-30 14:53:34 <f_> try again
2025-07-30 14:54:00 <f_> I don't see any org.matrix.appservice-irc.config state event
2025-07-30 14:54:01 <pj> I am having trouble understanding the current state of musl related to renameat2. May I please have some help.... (full message at <https://matrix.org/oftc/media/v1/media/download/AXLZP1HDrGQFYU3Vntze2E4olZwcRfrg6w8_nTZFrqqrzsLbj9a6m6Cv51fdPst8M7r16yi-K-d-nG0dGx2AQpxCeYo-x88AAG1hdHJpeC5vcmcvbVRzZnNtRG92ZXJ5aENhTGxxTVlEaGJu>)
2025-07-30 14:54:10 <f_|mo> It needs to be a state event
2025-07-30 14:54:32 <pj> state event is sent: https://matrix.to/#/!TYrhTimzOkAVxHIlXe:matrix.org/$1753887131495PNLdB:matrix.org?via=matrix.org&via=postmarketos.org&via=envs.net
2025-07-30 14:54:43 <f_|mo> Go in /devtools then send state event of type org.matrix.appservice-irc.config with state-key empty and content { "lineLimit": 10 }
2025-07-30 14:54:51 <f_|mo> anything over 10 won't work fyi
2025-07-30 14:55:04 <f_> pj: can't see the link
2025-07-30 14:55:22 <f_|mo> and I don't see the event in the room state
2025-07-30 14:55:40 <pj> me neither
2025-07-30 14:55:45 <pj> :3
2025-07-30 14:55:59 <sertonix[m]> andar1an: A new musl release is planned soon as far as I know
2025-07-30 14:56:38 <andar1an[m]> It may not make sense to push a patch for renameat2 then, because that wrapper will be in next version.
2025-07-30 14:56:59 <andar1an[m]> I still want to learn though, because it is important to understand
2025-07-30 14:58:10 <andar1an[m]> I am just poor at understanding the workflow as it is net new. I know what needs to be patched, just not sure how to do in aports yet
2025-07-30 15:01:13 <pj> sorry for spam
2025-07-30 15:01:13 <pj> this is big message test
2025-07-30 15:01:13 <pj> f_: i blame you
2025-07-30 15:01:13 <pj> sorry for spam
2025-07-30 15:01:32 <pj> yay works now
2025-07-30 15:02:17 <pj> f_: this also means that the telegram spam will get meaningfully forwarded tho :3
2025-07-30 15:02:47 <f_> why not +q *Telegram*bridge*[m]!*@* :P
2025-07-30 15:03:15 <pj> there is no telegram bridge
2025-07-30 15:03:25 <f_> I know
2025-07-30 15:03:26 <f_> also
2025-07-30 15:03:29 <f_> "Current room version: 1."
2025-07-30 15:03:34 <pj> dont ask
2025-07-30 15:03:36 <f_> Giant oof
2025-07-30 15:03:59 <f_> I heard #_oftc_#debian is increasingly broken because of that
2025-07-30 15:04:10 <pj> sounds fun
2025-07-30 15:04:13 <f_> anyways feel free to rince/repeat for the others :P
2025-07-30 15:04:38 <pj> I posted about this in #alpine-infra but I don't know what to do exactly, those are not "matrix.org" rooms but appservice rooms
2025-07-30 15:04:42 <andar1an[m]> once I figure out sasl I can switch to irc, but it is hating me atm lol
2025-07-30 15:05:05 <pj> and with changes that are coming in v12 rooms, room creator is BDFL
2025-07-30 15:05:22 <ikke> note that irc does have message length limits, though, most clients will spread it over multiple messages then
2025-07-30 15:05:29 <pj> currently the only room admin is oftc-irc
2025-07-30 15:05:50 <pj> i was supposed to ask oftc about that, so thanks for reminding me
2025-07-30 15:41:19 <f_> andar1an[m]: note for OFTC SASL does not work
2025-07-30 15:41:35 <f_> pj: OFTC can't do anything about it.
2025-07-30 15:41:40 <f_> They don't own nor run the bridge
2025-07-30 15:41:44 <f_> Ask matrix.org instead
2025-07-30 15:41:49 <pj> i realised that already
2025-07-30 15:41:58 <f_> OFTC merely just said "why not" back in 2015 and now regret it :P
2025-07-30 15:42:14 <pj> I was under the impression that the bridges are somewhat cooperative with network admins
2025-07-30 15:42:32 <f_> your expectations are way too high /j
2025-07-30 15:42:43 <andar1an[m]> what is OFTC, I see it a lot, but don't know if I ever learned it
2025-07-30 15:42:45 <pj> it is my fault unfortunately
2025-07-30 15:42:51 <f_> andar1an[m]: IRC network
2025-07-30 15:42:54 <pj> it's the IRC network
2025-07-30 15:42:55 <f_> https://oftc.net/
2025-07-30 15:42:58 <pj> oftc.net
2025-07-30 15:43:15 <andar1an[m]> Oh, so even generating keys to use external sasl won't work?
2025-07-30 15:43:27 <f_> andar1an[m]: certfp works but not through SASL
2025-07-30 15:43:29 <andar1an[m]> I dk how to connect then, I just get sasl rejections 
2025-07-30 15:43:41 <andar1an[m]> will look into that
2025-07-30 15:43:41 <f_> Disable SASL for OFTC
2025-07-30 15:43:44 <andar1an[m]> ty
2025-07-30 15:44:59 <andar1an[m]> oh great, I did have that set up already
2025-07-30 15:45:14 <f_> let's move this elsewhere btw
2025-07-30 15:45:15 <andar1an[m]> just need to configure irc client properly, I always went through web
2025-07-30 15:45:22 <andar1an[m]> sorry
2025-07-30 15:45:34 <f_> nah it's my fault
2025-07-30 15:45:49 <Biswa96[m]> q. are all builds in aports done native machine i.e. not cross compiling ?
2025-07-30 15:45:50 <pj> #alpine-offtopic :>
2025-07-30 15:46:29 <f_> Biswa96[m]: yes as far as I know
2025-07-30 15:46:36 <achill> yes they are
2025-07-30 15:51:15 <Biswa96[m]> riscv and loongarch always finish last.
2025-07-30 15:51:27 <achill> because the hardware is just slow
2025-07-30 15:51:42 <achill> especially riscv64 is like 10x slower than s390x
2025-07-30 15:52:19 <achill> there is just no powerful enough hardware for riscv on the market yet
2025-07-30 16:08:31 <henrix> ptrc: sorry for bothering again, but still regarding xapian-bindings being disabled due to py3-sphinx-autobuild -> uvicorn:
2025-07-30 16:08:34 <henrix> because only the python bindings cause issues, would there be an easy way to disable only that package?
2025-07-30 16:08:42 <henrix> or maybe it would be better to split into several different aports...?
2025-07-30 16:09:44 <henrix> 
ACTION would like to have public-inbox lei working locally without having to also build xapian-bindings locally

2025-07-30 18:16:50 <Ariadne> Biswa96[m]: loongarch is on 32-core 3c5000l server, which is a somewhat slow machine (though not nearly as slow as our risc-v builder).  hopefully we can upgrade to newer 3c6000 machine soon, which is performance-competitive.
2025-07-30 18:40:04 <Ariadne> sertonix[m]: re: D, i pinged them, maybe it will convince some movement
2025-07-30 18:41:22 <Ariadne> if they do not move on it, i have no objection to integrating the patches locally
2025-07-30 18:42:06 <Ariadne> but GDC seems mainly useful for bootstrapping the DMD compiler, so enablement on 32-bit archs will require patching in multiple places imo
2025-07-31 05:44:18 <cely> I maintain DMD and LDC, so it would be nice if i could be pinged before any large changes arrive (i check #-loongarch and #-riscv64 more often than i check here, ping me there so i won't miss it)
2025-07-31 05:46:35 <cely> There is also another repo you could try upstreaming your changes to, they may be a bit more receptive: https://github.com/opendlang/opend
2025-07-31 15:38:55 <qaqland> !87936 is ready