2026-06-01 00:00:23 <elibrokeit> I'm not saying hold a secret vote that nobody knows about and then make up whatever you want about what people would have voted if they'd known there was a vote
2026-06-01 00:00:28 <el[m]1> i'm sad to hear that comk and sorry that wayland didn't do that better
2026-06-01 00:00:41 <elibrokeit> where is this "assuming how people would vote"
2026-06-01 00:00:57 <comk> ....is dropping xorg on the charts el[m]1?
2026-06-01 00:01:01 <comk> for alpine i mean
2026-06-01 00:01:34 <iggy> it isn't, but nobody has voted on anything, there's just been a bunch of people giving their opionin or parroting the anti-AI talking points ad-nauseum on a gitlab issue (sorry work item)
2026-06-01 00:02:25 <el[m]1> comk: i wouldn't know
2026-06-01 00:03:06 <skarnet> when I agree with it, it's a perfectly rational argument that I have studied and made mine and that is valid. When I disagree with it, it's a talking point and you are just parroting.
2026-06-01 00:03:49 <skarnet> I don't particularly want to be hostile here, but man, could we please stick to intellectual honesty
2026-06-01 00:16:27 <elibrokeit> given I'm the actual individual who is being directly accused of something, I suppose I can also find it personally amazing that I'm being told *I* have assumed how people will vote because I said "having a vote is perfectly viable and people who abstain from voting have declared that they don't believe their input should be used to sway things one way or another"
2026-06-01 00:16:56 <iggy> I feel like anyone who blanket bans anything can't be intellectually honest by definition
2026-06-01 00:17:01 <elibrokeit> but whatever, apparently now it's not actually me assuming anything "because nobody has voted yet"
2026-06-01 00:17:23 <elibrokeit> iggy: ok, I blanket ban murder
2026-06-01 00:17:40 <elibrokeit> is that intellectually dishonest, and if so, why
2026-06-01 00:18:25 <iggy> you forgot "are obviously okay with a ban" in your quote there
2026-06-01 00:19:24 <elibrokeit> comk: btw that is a fascinating and excellent article. (speaking as a boring person who uses xorg still, solely because his desktop environment of choice only supports xorg, so, no real personal experience in accessibility, but sympathetic to the fact that most people don't seem to talk or care about it)
2026-06-01 00:19:55 <el[m]1> iggy: for what it's worth, society blanket bans a lot of things
2026-06-01 00:20:15 <elibrokeit> el[m]1: nonono, that's intellectually dishonest. stoppit immediately 
2026-06-01 00:21:40 <iggy> one could argue killing Osama bin Laden was murder, but there's plenty of people okay with it
2026-06-01 00:22:34 <ewo> 
ACTION puffs their joint and reminisces about studying anthropology

2026-06-01 00:23:35 <elibrokeit> "the crime of unlawfully and unjustifiably killing a person", "to kill (a person) unlawfully and unjustifiably with premeditated malice"
2026-06-01 00:24:52 <ewo> One could argue that, on the topic of intellectually dishonest, LLMS/AI slop by their very nature
2026-06-01 00:25:24 <ewo> are intellectually dishonest themselves due to the scraping of people's data
2026-06-01 00:25:53 <ewo> The socio-economical and political nature they/AI are being used now today
2026-06-01 00:26:01 <ewo> not to mention the ethical hurdles
2026-06-01 00:26:38 <Sheila> who is calling for a blanket ban, anyway? all I've been hearing about is a moratorium.
2026-06-01 00:27:10 <elibrokeit> seems like a good thing to blanket ban. with particular note to "unjustifiably".
2026-06-01 00:27:47 <elibrokeit> Sheila: a moratorium trivially reads as a "limited duration ban, which is blanket until it expires"
2026-06-01 00:33:09 <comk> blanket ban on using LLMs for generating("helping with") alpine contributions? the sentiment i got in the thread was "technically that's already the case under other rules but worth clarifying by making it explicit" 
2026-06-01 00:33:53 <comk> the contention seems to be use for translations of human language for reviews & comments
2026-06-01 00:34:16 <comk> wheres blanket banning LLM-assistedgenerated code seems uncontroversion
2026-06-01 00:34:21 <comk> uncontroversial*
2026-06-01 00:43:40 <invoked> it should be uncontroversial. worth noting: this thing, that only came into existence recently (in its current form, which is predominantly commercial) is now something that's immediately turned into people feeling wronged/oppressed when anything gets in the way of their use of it.
2026-06-01 00:49:21 <lotheac> i don't think it's unreasonable for someone to feel inconvenienced or frustrated if they get told "no, you cannot use that tool", regardless of whether that tool is an LLM or something else. but i would not describe that reaction as "oppressed"
2026-06-01 00:57:44 <invoked> lotheac: https://gitlab.alpinelinux.org/alpine/council/-/work_items/697#note_615878 the context. this went from being a tool, to being a group
2026-06-01 00:58:17 <invoked> it's strange that not everyone recognizes how absurd this situation is.
2026-06-01 01:00:29 <invoked> if harming open source through ai scraping and flooding the zone with ai bug reports wasn't enough, now we have people wondering about their employment contracts and this debate dividing what was otherwise fine before this tool arrived.
2026-06-01 01:02:12 <invoked> i'd argue that the use of claude/etc is fundamentally antithetical to the spirit of open source most people have been operating under for the past few decades.
2026-06-01 01:02:46 <lotheac> imho the issue is quite nuanced. not everyone who uses these tools is involved or complicit in the negative effects, i think.
2026-06-01 01:03:27 <invoked> gas pipelines to ai datacenters that are also draining reservoirs. any use is complicit.
2026-06-01 01:04:00 <lotheac> i understand and respect that position, but personally i don't like taking such hardline stances in general
2026-06-01 01:04:37 <invoked> that's not a stance, that's the objective reality
2026-06-01 01:04:59 <lotheac> arguing in that way is not productive, i feel like :)
2026-06-01 01:05:10 <lotheac> so let's stop
2026-06-01 01:05:26 <invoked> 
ACTION sighs

2026-06-01 01:07:27 <omni> I currently don't have the bandwith to participate in this discussion (read all of the backlog etc) but, fwiw, I'm beind a ban on "AI" contributions, there's enough to review as it is, I do this as a hobby and I want to interact and work with people
2026-06-01 01:08:46 <lotheac> i'm not opposed to a ban or moratorium, but something about the way it is being pushed does bother me a bit
2026-06-01 01:10:09 <lotheac> maybe that's just because the issue is important for those against it and i'm reading too much into it
2026-06-01 01:11:13 <skarnet> the way people tend to scream and be angry when they say "destroying everything we know and love is bad" makes me want to vote against them, because how dare they scream in my ears
2026-06-01 01:11:53 <lotheac> yeah, that's a perfectly accurate strawman :)
2026-06-01 01:12:27 <lotheac> i don't think being vocal should automatically mean someone's right
2026-06-01 01:12:37 <skarnet> it doesn't
2026-06-01 01:12:53 <skarnet> but it might be a good idea to consider the possibility that they might be, and get informed
2026-06-01 01:13:05 <lotheac> absolutely
2026-06-01 01:26:22 <infinitywisdom[m]> Hello everyone. Who heads up the gnome team on alpine linux and is responsible for package management?
2026-06-01 01:29:03 <infinitywisdom[m]> Im trying to get in contact with them to report that the setup-desktop script is broken.
2026-06-01 01:30:27 <ewo> infinitywisdom[m]: not sure if this is correct - maintainer="team/gnome <newbyte@postmarketos.org>"
2026-06-01 01:30:39 <ewo> https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/gnome
2026-06-01 01:30:51 <ewo> that's the maintainer in the APKBUILD
2026-06-01 01:30:53 <lotheac> infinitywisdom[m]: reporting an issue with details would be a good way https://gitlab.alpinelinux.org/alpine/aports/-/work_items
2026-06-01 01:31:19 <lotheac> (gitlab renamed issues to work items, so i guess "reporting a work item"?)
2026-06-01 01:32:05 <comk> lotheac > i don't think being vocal should automatically mean someone's right 
2026-06-01 01:32:06 <comk> ^ yes but also the opposite: a stupid angry mob pushing for or against something doesn't mean they're wrong in case either
2026-06-01 01:32:07 <durrendal> lotheac: "Creating work for someone else"
2026-06-01 01:32:47 <comk> re the "perfect strawman". i noticed this as a  communit vulnerability where flooding the zone leads some people to double down in the other direction for emotional reasons
2026-06-01 01:33:30 <infinitywisdom[m]> lotheac: I'll have to wait until later to setup an account. I am on a spare computer with no access to any of my emails. 
2026-06-01 01:33:55 <comk> even a single annoying issue-insister can cause a manitainer to go "ok thats it i will stop supporting this so i dont have to deal with ppl like you"
2026-06-01 01:34:07 <infinitywisdom[m]> ewo: Do you know if they come in here and if so what is their screen name?
2026-06-01 01:34:54 <shield[m]> hello can someone explain to me how builddir is set in an abuild? I see other abuilds dont manually set it but abuild complains that it is unset when I dont
2026-06-01 01:35:03 <elibrokeit> well, the apkbuild lists Newbyte and that is already the name of someone on this channel, infinitywisdom[m] 
2026-06-01 01:37:55 <elibrokeit> shield[m]: what's the build system used by the package? e.g. for Meson packages I see them write out a random dirname as an argument to meson
2026-06-01 01:38:28 <elibrokeit> for configure scripts you can build in-source, so can "some" cmake projects, and most open-coded Makefiles
2026-06-01 01:39:56 <shield[m]> elibrokeit: Im building chromium but am applying a lot of patches on top of it
2026-06-01 01:40:27 <shield[m]> im just looking at the chromium apkbuild and im getting different results
2026-06-01 01:41:46 <lotheac> infinitywisdom[m]: if you'd like to describe the details of the issue here i can create the work item for you
2026-06-01 01:42:20 <shield[m]> shield[m]: nvm I see in abuild
2026-06-01 01:42:33 <shield[m]> manually setting it in my case is probably correct
2026-06-01 01:46:25 <infinitywisdom[m]> lotheac: When installing GNOME via the setup-desktop script the software installs, but after openrc starts and gets to the part where gdm is supposed to take over and start up. It does not work. Tried switching to lightdm and was unable to get either x11 or wayland versions of gnome to start. I would login and get kicked backed to the display manager every time. After spending several hours trying to troubleshoot we narrowed it
2026-06-01 01:46:25 <infinitywisdom[m]> down to a possible elogind issue Error activating login1 session: GDBus.error:org.freedesktop.login1.NoSuchSession: No session 'c4' known 
2026-06-01 01:46:44 <infinitywisdom[m]> Trying to get it to start manually also did nothing.
2026-06-01 01:47:41 <infinitywisdom[m]> In order to see if this was a setup-desktop issue vs hardware issue. I manualy installed gnome without the setup-desktop script
2026-06-01 01:49:02 <infinitywisdom[m]> Gnome starts with a manual configuration of gdm setup-xorg-base setup-wayland-base and adding gdm via openrc. However that method, while it works, is missing a buttload of packages. I am now trying to just get a terminal application installed correctly.
2026-06-01 01:49:23 <ewo> infinitywisdom[m]: no idea sorry
2026-06-01 01:49:40 <infinitywisdom[m]> It's ok. Just trying to report the issue.
2026-06-01 01:49:50 <infinitywisdom[m]> See if anyone can duplicate it.
2026-06-01 01:50:06 <infinitywisdom[m]> I am on a gen 2 ryzen 7 thinkpad.
2026-06-01 01:52:26 <shield[m]> also is there a way to develop an abuild without having to reinstall 600 packages each rebuild 😓
2026-06-01 01:53:16 <elibrokeit> and why do you have to reinstall 600 packages 
2026-06-01 01:53:35 <shield[m]> when the build ends it purges the packages
2026-06-01 01:53:38 <shield[m]> to clean the env
2026-06-01 01:53:45 <shield[m]> or fails
2026-06-01 01:55:18 <lotheac> infinitywisdom[m]: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/work_items/10652
2026-06-01 01:55:53 <elibrokeit> shield[m]: I am not convinced that's an accurate description of the problem space
2026-06-01 01:56:34 <shield[m]> elibrokeit: is there a way to simply install all the dependencies from an abuild?
2026-06-01 01:56:48 <shield[m]> permanently
2026-06-01 01:57:28 <elly> `abuild deps`
2026-06-01 01:57:45 <shield[m]> thanks
2026-06-01 02:00:18 <infinitywisdom[m]> lotheac: Thank you kindly
2026-06-01 03:17:16 <shield[m]> sorry another question, whats the properly way to run a bash script from an APKBUILD
2026-06-01 03:17:36 <shield[m]> sorry source
2026-06-01 03:18:02 <shield[m]> I wanted to source a bash script to get the functions, but variables dont pass through into the bash subshell
2026-06-01 03:20:20 <lotheac> generally i would avoid sourcing other scripts into the abuild process. if you have to do something with bash that's not supported by /bin/ash, then run bash and make it source (or perhaps directly run) your script
2026-06-01 03:20:50 <lotheac> can you give a more concrete example about what you're doing
2026-06-01 03:26:16 <shield[m]> I am running a script that is part of a projects build system. I need access to the functions in the script to setup the project, so I must source the script
2026-06-01 03:26:39 <shield[m]> I just made a seperate bash file for this segment
2026-06-01 03:27:21 <lotheac> yeah, either that or bash -c ". foo/bar.bash && whatever_you_needed_to_do"
2026-06-01 03:29:25 <lotheac> of course there may be other/simpler ways to accomplish whatever those bash scripts are doing, but depends on the upstream project how complex they made their build stuff :)
2026-06-01 03:31:39 <shield[m]> oh yeah it discusts me
2026-06-01 03:31:45 <shield[m]> * oh yeah it disgusts usts me
2026-06-01 03:32:22 <shield[m]> and the script isnt doing much except calling python scripts
2026-06-01 03:32:40 <shield[m]> in the long term I will probably resort to calling those python scripts myself
2026-06-01 04:01:32 <elibrokeit> you can skip the bash -c by using subshells 
2026-06-01 04:01:56 <elibrokeit> ( . foo/bar.bash && whatever_you_needed_to_do )
2026-06-01 04:02:08 <lotheac> well, no, because the parent shell is not bash, abuild uses ash
2026-06-01 04:02:11 <elibrokeit> depends on what the thing being sourced does
2026-06-01 04:02:37 <elibrokeit> lotheac: I was getting to that lol 
2026-06-01 04:06:10 <shield[m]> elibrokeit: I tried this, It didnt work because the subshell is still ash
2026-06-01 04:50:26 <ncopa> morning! I do regret expressing my opinion yesterday.
2026-06-01 04:55:14 <ncopa> i guess my main worry is that we dont know what the majority of the devs wants.I dont want the council make decisions based on who scream the loudest.
2026-06-01 04:55:53 <shield[m]> AHHHHHHHHHHHHHHHHHHHHHHHH
2026-06-01 04:56:12 <ikke> shield[m]: please refrain from that, that's not helpful
2026-06-01 04:56:19 <ncopa> what I do know is that LLM generated content is giving us problems, and I think we should try do something about it
2026-06-01 04:57:36 <ncopa> i also think there is a lot we (almost?) all agree on
2026-06-01 04:57:51 <ncopa> those are the parts I think we should start with
2026-06-01 04:59:22 <ncopa> I think som sort of document expressing what we expect from contributors will be useful
2026-06-01 05:00:56 <ncopa> i do not want that new contributors need to read through hundreds of pages of docs before they can contribute. The shorter we can express what we expect, the better
2026-06-01 05:01:30 <ncopa> the less friction for people to contribute, the better
2026-06-01 05:03:34 <ncopa> what I wonder is, where do we put it? in some CONTRIBUTE.md in aports repo? In the official developers guide on docs.a.o? In the wiki? We apparently have the "how to contribute" on the wiki.
2026-06-01 05:22:16 <qaqland> ncopa: write some RULES in AGENTS.md (CLAUDE.md)?
2026-06-01 05:26:47 <qaqland> https://github.com/AOSC-Dev/aosc-os-abbs/pull/16137
2026-06-01 05:29:14 <quinq> Isn't that for robots?
2026-06-01 05:29:48 <quinq> https://agents.md/
2026-06-01 05:29:57 <quinq> “Think of AGENTS.md as a README for agents” yep
2026-06-01 05:39:32 <qaqland> The agents will always read this file, just try to keep it under 50k if possible.
2026-06-01 05:52:16 <ncopa> target audience would be humans
2026-06-01 05:53:40 <Sheila> I think if you want to know how developers feel, anonymous survey.
2026-06-01 05:53:54 <ncopa> I would like to avoid maintaining a double set of docs, eg one for humans and one for AI
2026-06-01 05:54:51 <ncopa> anonymous survey sounds like a good idea
2026-06-01 05:55:27 <ncopa> but it has weaknesses as well
2026-06-01 05:58:01 <ncopa> re AGENTS.md, I think it may also be perceived as that we are supporting use of AI, or are "Pro AI", and will probably lead to new set of endless discussions
2026-06-01 06:06:25 <lotheac> survey's a good idea. it may not need to be anonymous imho, but probably best that it's at least not public who voted what, given the topic's flammability
2026-06-01 06:26:01 <realroot[m]> <realroot[m]> "it wasn't installed at all" <- i do have the firmware `rtl8821ae: Using firmware rtlwifi/rtl8821aefw_29.bin` without the package.
2026-06-01 06:29:33 <realroot[m]> jvvv I see HW kernel link, it's working now with or without linux-firmware-realtek, thanks
2026-06-01 06:29:45 <realroot[m]> *I see HW in kernel link
2026-06-01 06:30:05 <jvvv> realroot[m]: glad you got it sorted
2026-06-01 06:31:24 <realroot[m]> ~/.local/state/tinydm.log has setpriv: unknown capability 'all' for tinydm-1.3.1-r0 and it won't start with x11 but not the one in repo
2026-06-01 06:33:13 <realroot[m]> it works with setpriv package installed
2026-06-01 06:35:42 <jvvv> perhaps you can submit an MR adding `cmd:setpriv` to depends?
2026-06-01 06:37:22 <realroot[m]> will that bring setpriv? cause there is busybox version
2026-06-01 06:39:02 <jvvv> i did a `apk search cmd:setpriv`. it only output the util-linux one.
2026-06-01 06:39:57 <realroot[m]> file /usr/bin/setpriv 
2026-06-01 06:39:57 <realroot[m]> /usr/bin/setpriv: symbolic link to /bin/busybox
2026-06-01 06:40:17 <realroot[m]> i see so apk won't consider it
2026-06-01 06:40:47 <jvvv> not for the dependency, that is correct
2026-06-01 06:41:43 <jvvv> busybox package only has `cmd:busybox` for provides, so its' applets won't be considered for depends
2026-06-01 06:42:02 <ncopa> elibrokeit:  I am sorry for not clearly articulate what those good uses are. It was my mistake trying to respond to the issue while at the same time trying to have a Sunday off and do other activities. I was overwhelmed.
2026-06-01 06:43:42 <ncopa> the day started with "we should probably do something about this council ticket sooner than later", so I tried to spend some of my free time to move that forward
2026-06-01 06:46:05 <ncopa> then the day took the turn "lets fork Alpine" and went downwards from there
2026-06-01 06:47:52 <ncopa> I had not set the day off to deal with the issue. I did have a day full of other activities, but felt that it was urgent to respond. the communication was non-optimal
2026-06-01 06:48:02 <ncopa> I am sorry for that
2026-06-01 06:53:54 <ncopa> elibrokeit: I also apologize if my words were unkind. It was not my intention to accuse anyone.
2026-06-01 07:47:09 <fabricionaweb> good morning, is gitlab down?
2026-06-01 07:48:55 <achill> works for me
2026-06-01 07:49:54 <fabricionaweb> worked now
2026-06-01 07:49:55 <fabricionaweb> thanks
2026-06-01 07:57:15 <ikke> Load is a bit highish
2026-06-01 08:17:51 <Newbyte> <infinitywisdom[m]> "Im trying to get in contact with..." <- just make an issue in the setup-desktop script's repo
2026-06-01 08:25:36 <lotheac> Newbyte: i created one for them earlier https://gitlab.alpinelinux.org/alpine/alpine-conf/-/work_items/10652
2026-06-01 09:54:37 <ncopa> re setup-desktop and login manager for gnome, last time I had a look at it I think the conclusion was that it needs a reboot or similar due to how it is plugged into init system and due to limits in busybox init
2026-06-01 12:52:45 <infinitywisdom[m]> ncopa: It was rebooted countless times. Did not resolve anything. 
2026-06-01 16:50:51 <ollieparanoid1> if somebody could take a look at / merge this trivial patch, it would be great: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103273
2026-06-01 16:58:13 <ncopa> merged. thanks
2026-06-01 20:21:17 <midasi> I created several merge requests some weeks ago and rebased all of them today. Has someone time to review them? Thanks! https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/?author_username=midas
2026-06-01 20:23:15 <ikke> midasi: They were waiting for an ack from thermi
2026-06-01 20:23:32 <ikke> is he still active?
2026-06-01 20:25:37 <jvvv> he was with in the last year, I know because I track libhx for pam_mount. He is logged in here as Thermi_, but I don't know whether is afk or not.
2026-06-01 20:26:58 <midasi> ikke: Oh ok. Not sure if he's still active. I tried to contact him several times in the last few weeks without response.
2026-06-01 20:28:27 <jvvv> He was slow getting back to me when I reached out to him for moving libhx to community, but he did get back to me eventually
2026-06-01 20:31:49 <ikke> midasi: we're waiting for the riscv64 builder to complete 3.24. I don't want to pile up a lot more builds before it is finished
2026-06-01 20:33:27 <midasi> ikke: I understand. We actually hoped to get these packages in 3.24
2026-06-01 20:33:53 <ikke> midasi: once the builder has caught up, there is still time
2026-06-01 20:34:34 <midasi> ikke: ok great. Let me know if sth is missing.
2026-06-01 20:34:52 <ikke> I'll try to review them at least
2026-06-01 20:38:25 <ikke> midasi: libhx bumps soname. I see at least some of the dependencies are also being upgraded, but perhaps better to combine them in a single MR to make sure they are built against the new version
2026-06-01 20:42:09 <jvvv> libcryptmount is subpackage of pam_mount, so bumping pam_mount takes care of both
2026-06-01 20:56:33 <ikke> midasi: I've reviewed the packages
2026-06-01 20:56:43 <ikke> (MRs)
2026-06-01 20:59:02 <midasi> ikke: thanks. re the libhx ABI change, do I need to pkgrel++ on reverse dependencies?
2026-06-01 20:59:21 <ikke> either that, but including the upgrades in the same MR would work as well
2026-06-01 20:59:32 <ikke> But yes, that's generally how that's done
2026-06-01 21:26:17 <markand> shield[m], I think that you are unaware of what side effect using an AI actually is. non exhaustive list: copyright, quality, time consumption, environmental impact
2026-06-01 21:29:06 <shield[m]> I do not want to discuss this anymore please do not mention me, im not a contributor anyway
2026-06-02 05:42:12 <ikke> ncopa: libdrm failed on riscv64: https://tpaste.us/D8Bz 
2026-06-02 05:42:17 <ikke> It's a dependency for many aports
2026-06-02 05:45:02 <ikke> similar error on riscv64: https://github.com/llvm/llvm-project/issues/72256
2026-06-02 07:33:12 <quinq> Hello, is grub broken? :/
2026-06-02 07:33:14 <quinq> (on edge)
2026-06-02 07:33:50 <quinq> I get /etc/grub.d/10_linux: line 197: version_find_latest: not found
2026-06-02 07:53:47 <dne> no idea, but it got upgraded from 2.12 to 2.14 3 days ago…
2026-06-02 07:56:06 <quinq> Yeah dne, thanks :)
2026-06-02 07:56:15 <quinq> I had to manually move the .apk-new
2026-06-02 07:57:03 <dne> ah!
2026-06-02 08:50:36 <ncopa> there was a grub update not too long ago
2026-06-02 08:51:01 <ncopa> with alpine 3.24 we will have support for limine. I wonder if we should move to that as the default boot loader
2026-06-02 08:51:08 <ncopa> maybe for 3.25
2026-06-02 08:51:16 <achill> yeah i wouldnt rush it
2026-06-02 08:51:45 <lotheac> guess i've been under a rock, first time i'm hearing of that software
2026-06-02 08:51:55 <omni> !18228
2026-06-02 08:52:09 <omni> uhm, no
2026-06-02 08:52:17 <omni> I meant #18228
2026-06-02 08:52:52 <omni> and !58567 ?
2026-06-02 08:55:54 <lotheac> seems like a pretty reasonable piece of software on first glance though
2026-06-02 08:56:13 <lotheac> i've been mostly booting my kernels directly from uefi firmware on machines that can do that anyways
2026-06-02 11:46:03 <Habbie> gitlab auth issues?
2026-06-02 11:46:40 <Habbie> https gives Error: access denied: denied by administrative rule 6af05e6d674759fa8ab6a92e0ff8bbc0/560c674e98e70c71aa1e
2026-06-02 11:48:37 <Habbie> git over ssh works
2026-06-02 12:06:37 <Sertonix[m]> ncopa: If possible I would like to find someone who is willing to port limine for ppc64le. Otherwise we won't get away from needing logic for grub everywhere.
2026-06-02 12:17:21 <durrendal> Didn't limine somewhat arbitrarily drop support for ext, then re-add it in a unmaintained state, then drop it again? Also doesn't the project release changes rapidly? Neither of these things seem like they signal "stability" to me, which is the wrong signal for something as critical as a bootloader
2026-06-02 12:33:10 <WhyNotHugo> +1 to limine: it's neat as long as you don't need SecureBoot (which our default GRUB setup doesn't do anyway)
2026-06-02 12:33:52 <WhyNotHugo> Sertonix[m]: isn't there some other bootloader usable for ppc64le? Or do we have to commit to the same bootloader on all arches?
2026-06-02 12:36:14 <Habbie> hmm, no limine for 32 bit arm?
2026-06-02 12:49:25 <Sertonix[m]> WhyNotHugo: the only bootloader for ppc64le we have at the moment is grub and I would hope to change that.
2026-06-02 12:58:14 <WhyNotHugo> apparently u-boot support ppc? I'm both curious about ppc, but hessitant to put time into understanding hardware I don't own :P
2026-06-02 12:59:02 <WhyNotHugo> There's petitboot in testing, but again, I have little context.
2026-06-02 13:00:09 <f_> WhyNotHugo: u-boot supports ppc yes
2026-06-02 13:00:26 <f_> but u-boot isn't really meant to be used like grub
2026-06-02 13:00:43 <f_> (even though IIRC it can be used like that, on EFI at least, but iirc x86_64 only)
2026-06-02 13:01:14 <f_> by the way, is alpine dropping armhf? Like, I saw a fedi post from ncopa about it, but not much else
2026-06-02 13:01:25 <f_> (a few months back)
2026-06-02 13:01:51 <ikke> f_: no concrete plans
2026-06-02 13:02:19 <f_> ok thanks
2026-06-02 13:23:45 <Sertonix[m]> WhyNotHugo: qemu luckily includes firmware that should allow testing. And IEEE1275 is a proper spec. That's as far as I got.
2026-06-02 18:32:49 <markand> 10:51 < ncopa> with alpine 3.24 we will have support for limine. I wonder if we should move to that as the default boot loader
2026-06-02 18:32:52 <markand> yes please!
2026-06-02 18:33:12 <markand> I use limine for dualboot on my thinkpad, works like a charm
2026-06-02 18:33:34 <markand> and no need to learn a programming language to configure your bootloader 
2026-06-02 18:46:01 <Biswa96[m]> does any bootloader need to learn a programming language to configure it?
2026-06-02 18:50:25 <bl4ckb0ne> did a mistake when merging an aport update, is there a way to squash on main? or maybe revert
2026-06-02 18:58:12 <markand> Biswa96[m], grub is turing complete yes
2026-06-02 18:58:55 <markand> I wonder how it ended being the de-facto standard of all distributions, but that's offtopic
2026-06-02 19:04:32 <staceee> bl4ckb0ne: is it possible to revert a merge?
2026-06-02 19:05:37 <bl4ckb0ne> revert or maybe drop, i dont know what's the guideline there
2026-06-02 19:05:45 <bl4ckb0ne> very sorry for the fast merge
2026-06-02 19:06:02 <bl4ckb0ne> i clicked merge like a dumbass, then saw the 2nd commit after
2026-06-02 19:06:07 <staceee> I should have putted some DRAFT: or WIP: in the mr subject, that's also my bad
2026-06-02 19:06:21 <bl4ckb0ne> that could help for next time yes
2026-06-02 19:06:59 <staceee> I added this patch really fast, was doing something else. I just wanna see it the patch works for riscv64
2026-06-02 19:28:31 <ikke> bl4ckb0ne: what has been pushed can not be undone
2026-06-02 19:28:39 <bl4ckb0ne> ill open a revert
2026-06-02 19:32:01 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103393
2026-06-02 19:32:08 <bl4ckb0ne> sorry again for merging to fast
2026-06-02 19:33:04 <ikke> It can happen
2026-06-02 19:33:49 <ikke> bl4ckb0ne: you need to bump pkgrel one more
2026-06-02 19:34:05 <ikke> otherwise cdn will serve the old package and not match the apkindex
2026-06-02 19:34:13 <bl4ckb0ne> oh right, dedicated commit?
2026-06-02 19:34:26 <ikke> Can be the same commit
2026-06-02 19:35:08 <staceee> I'll also try to be more prudent with draft MRs like that
2026-06-02 19:35:08 <bl4ckb0ne> done
2026-06-02 20:36:41 <ncopa> lol! there is a beautiful "TEST" in the git history now for all eternity :D
2026-06-02 20:37:46 <ncopa> now you have a good story to tell your grandchildren :D
2026-06-02 20:39:31 <f_> "yeah I pushed a TEST commit to alpine aports master branch"
2026-06-02 20:39:40 <f_> :D
2026-06-02 20:40:04 <ncopa> i really hope you dont feel bad. you shouldnt. it happens.
2026-06-02 20:41:05 <staceee> x]
2026-06-02 20:41:06 <f_> it once happened to me that I merged a MR too early, just pressed "Merge" completely out of the blue
2026-06-02 20:41:14 <f_> see it even happens to me! :P
2026-06-02 20:41:18 <staceee> litteraly my toot
2026-06-02 20:41:35 <f_> it was on pmaports that I did that, and I remember I was kind of panicked
2026-06-02 20:41:43 <f_> don't be panicked
2026-06-02 20:41:44 <ncopa> i bet you find funny commits with Author Natanael if you dig deep enough
2026-06-02 20:41:57 <staceee> I see this as a life goal check
2026-06-02 21:34:37 <WhyNotHugo> `git log --reverse` tells a really fund story :)
2026-06-02 21:34:58 <WhyNotHugo> Especially with -p
2026-06-03 05:30:48 <markand> reminds me of AirFrance pushing a notification "test de julien à nouveau" to every smartphone on earth having the app installed
2026-06-03 06:14:56 <f_> xD
2026-06-03 06:31:09 <comk> https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
2026-06-03 07:04:25 <markand> "I’m here to tell you that you are out of date"
2026-06-03 07:04:50 <markand> yeah people tell me that at work too, now they start to think about stop using AI because they start to realize that it's not good
2026-06-03 07:05:38 <markand> in a nutshell: I received lots of AI merge requests, so I used AI to manage them
2026-06-03 07:23:36 <quinq> “I invested in LLM, it *has to* pay out”
2026-06-03 07:26:07 <Saijin_Naib[m]> After tridge shoved LLM garbage into ArduPilot, I stopped caring what he had to say about anything because he has clearly lost the plot
2026-06-03 07:26:15 <comk> like managing a hangover with a bottle of vodka. can make the current day more tolerable i guess
2026-06-03 07:26:56 <comk> still should probably not show up drunk to work
2026-06-03 07:27:43 <comk> absolut helped writ these tests
2026-06-03 07:30:44 <Sertonix[m]> -> #alpine-offtopic
2026-06-03 07:31:00 <comk> oops forgot the channel thx Sertonix[m]
2026-06-03 10:17:54 <ncopa> I wonder if we can deprecate ACF
2026-06-03 10:18:01 <ncopa> and setup-acf
2026-06-03 10:18:15 <ncopa> maybe also setup-mta. does anyone every use it?
2026-06-03 10:39:01 <ikke> ncopa: libdrm managed to build the 2nd time
2026-06-03 10:48:09 <ncopa> good. I'm building vector on the p550 may copy it over manually if it passes
2026-06-03 10:49:26 <ikke> ok, it hang the previous time, so I killed it
2026-06-03 10:49:33 <ikke> (more than 12h)
2026-06-03 12:41:58 <panekj> anyone looked at packaging ntfsprogs for old new ntfs driver?
2026-06-03 13:08:38 <tdtrask> @ncopa I still use ACF, but I doubt that my usage alone will be sufficient to prevent its deprecation. :)
2026-06-03 13:25:45 <Saijin_Naib[m]> I am trying to learn ACF and awall to use to deploy and manage family computers remotely
2026-06-03 13:26:09 <Saijin_Naib[m]> I would be sad to see ACF go as it is a really attractive suite of tools for this type of task
2026-06-03 15:10:41 <lotheac> panekj: what do you mean?
2026-06-03 15:21:36 <panekj> lotheac: r/o ntfs driver which was replaced with r/w ntfs driver by the samba/ksmbd/exfat maintainer which has new progs (afaik forked from ntfs3g) that add more utils including ntfsck
2026-06-03 15:22:02 <panekj> it was included in 7.0 or 7.1 kernel
2026-06-03 15:22:15 <panekj> briefly known as ntfs+
2026-06-03 15:22:21 <panekj> https://github.com/ntfsprogs-plus/ntfsprogs-plus
2026-06-03 15:23:15 <lotheac> hm, didn't know about that. i thought tuxera were still trying to give the impression they maintained that stuff
2026-06-03 15:23:29 <panekj> they kinda, kinda don't
2026-06-03 15:23:31 <lotheac> (i briefly worked there 10-ish years ago)
2026-06-03 15:23:35 <panekj> https://lore.kernel.org/lkml/20251020020749.5522-1-linkinjeon@kernel.org/
2026-06-03 15:24:05 <panekj> oh sorry, no, tuxera is ntfs3g which they develop still I think
2026-06-03 15:24:09 <panekj> but that's FUSE
2026-06-03 15:24:24 <lotheac> ntfsprogs too
2026-06-03 15:24:33 <panekj> ntfs/ntfsplus/ntfs3 are kernel drivers
2026-06-03 15:24:40 <lotheac> (and they had/have proprietary ntfs drivers)
2026-06-03 15:24:59 <panekj> I'm talking purely about the open source ones
2026-06-03 15:25:11 <panekj> ntfs3g was only forked for their progs 
2026-06-03 15:25:23 <lotheac> sure -- but the userspace part, ie. progs, generally speaking open source afaik
2026-06-03 15:26:06 <panekj> yes but it's fuse only and afaik never saw any feature improvement
2026-06-03 15:26:15 <lotheac> that said, if namjaejeon forked it, it was probably overdue
2026-06-03 15:26:23 <lotheac> (still talking about progs only)
2026-06-03 15:27:06 <panekj> I was hoping that paragon will release the progs like they promised
2026-06-03 15:27:14 <panekj> but it never happened
2026-06-03 15:28:10 <lotheac> theoretically: *fsprogs and the kernel impl are completely separate and should have zero dependency on the on-disk bytes the other one writes or expects
2026-06-03 15:28:34 <lotheac> so, we could package both ntfsprogs and ntfsprogs-plus
2026-06-03 15:29:38 <panekj> afaik, everyone who uses ntfs3 uses it with ntfs3g-progs because there isn't any other option (but also ntfs3 progs do nothing in terms of fixing the fs so it's kinda meh)
2026-06-03 15:30:17 <lotheac> in which situations do you even need to use the progs? fsck and mkfs?
2026-06-03 15:30:27 <panekj> I do not know in what state ntfs3g-progs is
2026-06-03 15:30:36 <panekj> lotheac: yes
2026-06-03 15:30:41 <lotheac> i'm not speaking about ntfs specifically, just generally
2026-06-03 15:31:12 <panekj> I'm talking generally in terms of packaging, I have no idea if it's maintained or not and if it makes sense to package both
2026-06-03 15:31:17 <lotheac> well, sounds like we should package both impls then and then you can choose your poison of which fsck you want? :D
2026-06-03 15:32:08 <lotheac> both look maintained to me... to a certain degree
2026-06-03 15:32:35 <panekj> I don't think ntfs3g-progs even have fsck
2026-06-03 15:32:46 <lotheac> https://github.com/tuxera/ntfs-3g/blob/edge/ntfsprogs/ntfsck.c
2026-06-03 15:32:48 <panekj> it has ntfsfix
2026-06-03 15:33:18 <panekj> I don't see it on my system though
2026-06-03 15:33:38 <panekj> neither does apk
2026-06-03 15:34:35 <lotheac> yeah, now that i try to recall, i think the company line was "tell the customer to run chkdsk.exe, it would not make sense for us to implement this"
2026-06-03 15:36:13 <lotheac> which tbh i think is a reasonable position. not sure what ntfsprogs-plus fsck would do, but speaking purely as a user i might prefer not trying to fix anything
2026-06-03 15:36:48 <lotheac> which is just another long way to say: both sounds good :)
2026-06-03 15:36:56 <lotheac> packaging both, i mean
2026-06-03 15:38:27 <panekj> tbh, I was asking just to know if someone already deals with that, otherwise I'm going to keep it in my own aports 
2026-06-03 15:38:34 <lotheac> https://github.com/ntfsprogs-plus/ntfsprogs-plus/blob/main/src/ntfsck.c yeah, this one does a *lot* more. 4846 lines vs. 883
2026-06-03 15:39:59 <lotheac> panekj: i get it. sorry for the tangential discussion. i think ntfsprogs-plus is desirable in alpine, but *personally* i would make it a separate aport
2026-06-03 15:41:48 <lotheac> i'm not *opposed* to replacing the current package, but if you want to do that then you need to talk to the current package maintainer (which seems to be ncopa)
2026-06-03 15:43:22 <lotheac> i think contributions would be welcomed :)
2026-06-03 15:45:22 <panekj> having to interact with abuild does not make me happy, maybe once I'm in better headspace I'll consider it
2026-06-03 15:45:49 <lotheac> sorry about that too 😅
2026-06-03 15:49:56 <Ariadne> i think deprecating ACF, like embracing vibe coding, is the wrong move.  we should not deprecate fundamental components of the alpine user experience
2026-06-03 16:08:07 <f_> I never used ACF but it looks useful
2026-06-03 16:08:17 <f_> ehxor: fix your connection please ^^
2026-06-03 16:10:09 <ehxor> my computer and internet are having a sad day. sorry for the noise. if it's not resolved i'll just show myself out til it is
2026-06-03 16:10:52 <panekj> f_ should just get an IRC client that can filter joins/leaves :P
2026-06-03 16:11:43 <f_> it does filter them but only when I want it to
2026-06-03 16:12:03 <f_> ehxor: it's ok if there's nothing you can do, just letting you know :P
2026-06-03 16:12:11 <panekj> I have weechat hide everything until people speak, then it shows the events
2026-06-03 16:13:25 <ehxor> once i'm off my current zoom call i'm gonna restart my router and modem. after that i think my next course of action is throwing them both off a bridge and moving to the woods
2026-06-03 16:14:25 <skarnet> that's the most relatable thing
2026-06-03 16:21:21 <Ariadne> i certainly wish to throw my computer off a bridge and move to the woods
2026-06-03 16:22:21 <panekj> I for one would not throw my puter, I would like to completely disconnect though and do fun stuff in peace 
2026-06-03 16:38:19 <f_> panekj: it seems Noisytoot did it first
2026-06-03 16:39:32 <Saijin_Naib[m]> I would really appreciate ntfs+ being packaged. There is no shortage of performance, conformance, and stability fixes vs ntfs3g and paragon ntfs
2026-06-03 16:42:16 <Saijin_Naib[m]> As for being default, it makes sense to me given the above, but ro/3g have years of usage. Given namjaejon's track record though, I would personally just switch to their implementation immediately anyway
2026-06-03 16:44:23 <panekj> f_: they gone?
2026-06-03 16:44:40 <panekj> sad
2026-06-03 16:44:53 <f_> panekj: they ping timedout
2026-06-03 16:44:59 <f_> on their ZNC
2026-06-03 16:45:09 <f_> but no they're not gone :P was just kidding
2026-06-03 16:45:16 <panekj> ok don't scare me like that
2026-06-03 16:45:22 <f_> xD
2026-06-03 16:45:38 <f_> if you looked at /names you'd know they have a second client here
2026-06-03 16:45:48 <panekj> I'm still wondering what happened to tedu
2026-06-03 16:45:55 <f_> running on the best host domain ever in the world
2026-06-03 21:03:49 <invoked> panekj: nobody knows, or at least, it hasn't come across the wire publicly over at openbsd that i know of
2026-06-03 21:04:07 <invoked> it's been an open question since january (i think the sites went offline jan-feb, thereabouts)
2026-06-04 00:01:03 <panekj> invoke: yeah I can see last federated post from 4 months ago
2026-06-05 09:35:22 <ncopa> 19 packages left to build...
2026-06-05 09:35:26 <ncopa> + the failing ones
2026-06-05 09:35:39 <ncopa> + the latest commits
2026-06-05 10:53:48 <ptrc> btw, what's the policy for packages that were disabled but still have enabled dependencies?
2026-06-05 10:53:53 <ptrc> do we also disable the dependencies?
2026-06-05 10:54:16 <ptrc> e.g. qemu doesn't build for 32-bit anymore, but we have ~5 packages that are still enabled, like alpine-make-vm-image or cloud-utils
2026-06-05 10:54:32 <ptrc> and those still work, because the old qemu package is still there in the repos
2026-06-05 10:54:50 <ptrc> oh, actually, nevermind
2026-06-05 10:54:59 <ptrc> the old package is *not* there anymore
2026-06-05 10:56:07 <ikke> The old package would be removed after the next update of the package
2026-06-05 10:56:28 <ikke> But that means its reverse dependencies would have to be disabled
2026-06-05 10:57:01 <ptrc> alrighty, so in this case the correct thing is to disable all qemu-dependent packages
2026-06-05 10:57:06 <ptrc> got it o7
2026-06-05 10:57:32 <ncopa> cloud-utils only need qemu-img right? maybe we could drop the tool that needs qemu-img?
2026-06-05 10:57:40 <Sertonix[m]> IIRC qemu-tools would still support 32-bit
2026-06-05 10:57:56 <ptrc> then we could try and build just qemu-tools?
2026-06-05 10:58:05 <ncopa> yeah, sounds like a good idea
2026-06-05 10:58:19 <ncopa> qemu guest agent  makes sense to have as 32 bit
2026-06-05 10:59:48 <Sertonix[m]> (I thing _subsystems is missing microblazeel)
2026-06-05 11:03:39 <ncopa> Sertonix[m]: i think we can tag abuild release now?
2026-06-05 11:03:48 <ncopa> for 3.24.
2026-06-05 11:05:21 <Sertonix[m]> Yes
2026-06-05 15:53:38 <ptrc> hm.
2026-06-05 15:54:02 <ptrc> any ideas what to do when a subpackage is only available on a given architecture, but it `amove`s files from the main one?
2026-06-05 15:54:30 <ptrc> because if i simply omit it from $subpackages on the architecture when it's not available, the files will still be there, just in the main package
2026-06-05 15:54:39 <ikke> case $CARCH in; foo) amove;; *) rm;; esac?
2026-06-05 15:54:39 <ptrc> so.. rm -rf them conditionally..?
2026-06-05 15:54:55 <ptrc> ikke: that would be in the subpackage function, which doesn't run at all
2026-06-05 15:55:13 <ikke> Then move the rm to the package function
2026-06-05 15:55:29 <ptrc> sensible, i'm just annoyed at having the conditional twice :P
2026-06-05 21:57:46 <fabricionaweb> Congratulations Sertonix[m] !! 🎉🎉
2026-06-05 23:04:56 <Saijin_Naib[m]> They got dev‽ Awesome!
2026-06-05 23:30:33 <Habbie> congrats!
2026-06-05 23:42:32 <craftyguy[m]> I feel like I missed something... 😛
2026-06-05 23:42:54 <flamingradian[m]> me too
2026-06-05 23:50:29 <Habbie> ~
2026-06-05 23:50:32 <Habbie> oops
2026-06-05 23:54:57 <Habbie> my congrats was based on Saijin_Naib[m]'s assumption
2026-06-05 23:55:38 <Habbie> (and i did read https://gitlab.alpinelinux.org/alpine/tsc/-/work_items/85 once before)
2026-06-05 23:56:53 <Saijin_Naib[m]> Ah, my bad. That is normally the only congrats that gets posted out of context here
2026-06-05 23:57:24 <Habbie> i'm not saying you're wrong. i'm saying i believed you ;) i don't even know if you're wrong or right!
2026-06-06 01:11:37 <qaqland> how could I enable test for less? https://github.com/gwsw/less/issues/791
2026-06-06 01:20:31 <qaqland> can I package() first then execute check() in abuild?
2026-06-06 01:53:02 <abby> achill: here's a patch for jellyfin-desktop to make it compatible with mpvqt 1.2 https://github.com/classabbyamp/void-packages/blob/mpvqt-update/srcpkgs/jellyfin-desktop/patches/mpvqt-1.2.0.patch
2026-06-06 01:53:46 <abby> it seems the jellyfin-desktop devs are all-in on vibecoding a replacement that uses CEF and SDL, for whatever reason
2026-06-06 01:54:31 <abby> but the old one still works, if you switch to the archived repo: https://github.com/classabbyamp/void-packages/commit/1dd66fd322f895f9efe6426f62ab3bab1b8dc602#diff-41c545738e2b6791f7dc216956eeb9e657936ce5292e0ed068cf79e709e6ef5dL15
2026-06-06 06:52:28 <ncopa> omni: I have temp disabled community/racksdb: 0e221c150d08925657acce218791840542e8397b
2026-06-06 06:52:59 <ncopa> I saw there is a new version out, 0.7.0 but I didnt have time to deal with the doc patch
2026-06-06 07:14:42 <omni_> I'll look at it
2026-06-06 13:37:29 <Sertonix[m]> qaqland: Copy the source tree or (if available) use an out-of-tree build and compile a seperate less in check()
2026-06-06 14:20:05 <ikke> wow
2026-06-06 14:20:07 <ikke> build-3-24-riscv64 online 
2026-06-06 14:20:09 <ikke> idle
2026-06-06 14:21:34 <f_> incredible
2026-06-07 05:21:44 <lotheac> ncopa: thoughts on including !99883 in 3.24? i've been putting off merging it because it fails CI on what looks like kube nodes only, but i think it should actually pass on builders
2026-06-07 05:22:13 <lotheac> i would love to find the root cause of the CI failure but... haven't had luck reproducing it
2026-06-07 06:38:41 <ncopa> i think it would be nice to have it included in 3.24, but it is also a bit risky I think? we have now built all packages. Do we know for sure that this will not break the build of any py3-* packages?
2026-06-07 06:40:01 <jvvv> ouch. Just noticed the patch I just pulled in from upstream for !103460 has the line "From: "LLLM (Linear-in-time LLM coding assistant)" <bowman@ualberta.ca>". It is the same diff as I pointed to in my upstream issue report, https://github.com/vectorgraphics/asymptote/issues/611. Not sure how to procede.
2026-06-07 06:41:35 <lotheac> ncopa: that's a fair concern. i think it makes more sense to postpone it then
2026-06-07 06:43:24 <jvvv> I wrote the original patch that I tested, so as I see it not actually LLM generated.
2026-06-07 06:43:35 <ikke> jvvv: the commit is part of master. Any new release would include it. Would you stop updating this pacakge?
2026-06-07 06:44:50 <jvvv> ikke: No. A valid point. I was just concerned it would trigger an uproar.
2026-06-07 06:47:42 <ikke> We cannot control what upstreams are doing. If we want to avoid it at all costs, we would have to start vetting and pruning a lot of pacakges (including linux)
2026-06-07 06:48:03 <lotheac> since that actually is the author name in the upstream commit, personally i would leave it as is
2026-06-07 06:49:05 <jvvv> Ok, thanks to both of you for your comments. I will leave it as it is.
2026-06-07 06:49:56 <lotheac> that said, given that it's your own patch, you might want to ask the upstream committer why they changed the author name :)
2026-06-07 06:50:45 <lotheac> (though realistically that kind of stuff was happening before LLMs too, so i would not hold my breath there)
2026-06-07 06:50:50 <jvvv> Yeah, well, I am not in this for the credit. ;)
2026-06-07 06:51:02 <lotheac> fair enough
2026-06-07 06:51:07 <jvvv> I am just happy when upstream is so responsive.
2026-06-07 09:11:14 <Sertonix[m]> jvvv: https://gitlab.alpinelinux.org/alpine/council/-/work_items/697#note_588065o
2026-06-07 09:12:24 <ikke> Did you mean https://gitlab.alpinelinux.org/alpine/council/-/work_items/703?
2026-06-07 09:13:37 <ikke> contributions versus using upstream 
2026-06-07 09:15:59 <Sertonix[m]> The discussion started at a note before 703 was created, but I typed an "o" so the link is broken
2026-06-07 09:16:43 <ikke> ah
2026-06-07 09:47:04 <jvvv> Sertonix[m]: Thanks, appreciated. I have read, at one point or another, most of the comments in both the 697 and 703 thread. But that one seems rather pertinent to the MR in question.
2026-06-07 09:52:14 <jvvv> And I think that comment fits in line with ikke and lotheac have said. I think I am ok in this case.
2026-06-07 11:34:41 <jvvv> ikke: How is it looking for https://opencollective.com/alpinelinux/updates/alpine-linux-and-postmarketos-conference-sponsoring? I think it is a good thing to do.
2026-06-07 11:35:38 <ikke> We're working on finalizing it
2026-06-07 11:36:37 <jvvv> Wish I could attend. The distance is a bit much for me.
2026-06-07 17:22:43 <ncopa> Seems like we are close to idling 3.24 builders. Please hold your big pushes til rc1 is out
2026-06-07 18:29:08 <f_> they're all idle except riscv64=
2026-06-07 18:29:09 <f_> ?
2026-06-07 18:34:41 <ikke> correct
2026-06-07 18:34:58 <ikke> 15 packages to build
2026-06-07 18:35:50 <f_> go riscv64, go!
2026-06-07 18:46:43 <ikke> single-thread builds are its achilles heal
2026-06-07 18:47:23 <ikke> heel*
2026-06-07 19:23:29 <ikke> 8 packages to go
2026-06-07 21:02:50 <ikke> 1 to go
2026-06-07 21:18:04 <ikke> \o/
2026-06-07 21:24:47 <f_> nice!
2026-06-07 21:58:42 <omni> did we get a tag?
2026-06-08 04:49:13 <ikke> Not yet
2026-06-08 07:26:26 <ncopa> Will tag in a bit. I’m sneaking in ipv6 support to installer
2026-06-08 07:26:55 <ncopa> Also running my local test suite 
2026-06-08 07:57:08 <ncopa> aarch64 release script passes
2026-06-08 08:02:32 <ncopa> hum... 
2026-06-08 08:02:34 <ncopa> >>> mkimage-riscv64: --> grub_efi riscv64-efi bootriscv64.efi 33b68c34aa5c35f9ddfb5f584794b639abe1be6f
2026-06-08 08:02:34 <ncopa> scripts/mkimage.sh: line 210: grub-mkimage: not found
2026-06-08 08:04:25 <ncopa> also my script that does not pull in needed deps
2026-06-08 08:19:49 <ncopa> 3.24.0 is tagged
2026-06-08 08:20:02 <ikke> \o/
2026-06-08 08:20:09 <ikke> I hope it's rc1 :P
2026-06-08 08:21:54 <DWwanghao1> Wow
2026-06-08 08:27:15 <ncopa> its rc1, yes. sorry
2026-06-08 08:27:26 <ncopa> I need help with cleaning up https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.24.0
2026-06-08 09:37:09 <macmpi> chrony shipping in 3.24.0_rc1 takes longer to init (wrt 3.23.4) on non-rtc device. Therefore setup-alpine with ANSWERFILE automation with chrony may fail setting up apkrepos "-1 -c" for instance. This scenario worked until 3.24.0_rc1
2026-06-08 09:42:22 <ikke> macmpi: Is there a different chrony version?
2026-06-08 09:47:44 <dne> there's https://gitlab.alpinelinux.org/alpine/aports/-/commit/08e126a9e53b06b3d75e3e66bad662b6d9b6c4b5
2026-06-08 09:48:01 <dne> and https://gitlab.alpinelinux.org/alpine/aports/-/commit/57c1fa30a67e30c9251670b53b5d981c8fcb58b3 added "maxupdateskew 100.0"
2026-06-08 10:00:22 <macmpi> There has been some work on defaults indeed. Wondering if daemon just does not just return sooner than it did, before time is actually set.
2026-06-08 10:02:10 <macmpi> maybe there should be some workaround in setup-ntp like for busybox ntpd
2026-06-08 11:08:33 <ncopa> do you have netowrk connectivity? i would expect it to work without RTC
2026-06-08 11:28:52 <ikke> ncopa: the issue clarifies that it's TLS verification that fails due to out-of-date clock
2026-06-08 11:30:06 <ncopa> but it worked before? what changed?
2026-06-08 11:30:49 <ncopa> if it was only the default chrony config that changed, it means that the current chrony config does not work
2026-06-08 11:30:49 <ikke> ncopa: Theory is that chrony waited until the time was actually set, now it returns already before that
2026-06-08 11:31:23 <ncopa> oh, ok. it blocked til time was set
2026-06-08 12:43:58 <WhyNotHugo> Now that v3.24.0_rc1 has been tagged, does 3.14.0 development continue in a branch, or still on master?
2026-06-08 12:45:03 <ikke> still master
2026-06-08 12:45:09 <ikke> branching happens on the final release
2026-06-08 12:55:29 <ncopa> the idea is to make it everyones interest to get the release out
2026-06-08 12:56:27 <WhyNotHugo> Okay to add python 3.14 to Draft_Release_Notes_for_Alpine_3.24.0 ?
2026-06-08 12:56:43 <ncopa> yes. absolutely. thanks!
2026-06-08 12:56:45 <achill> sure please do so
2026-06-08 12:57:41 <WhyNotHugo> done :)
2026-06-08 12:58:03 <ncopa> Thanks!
2026-06-08 13:04:09 <linio> Hello! I'm trying to figure out how to make alpine persist changes on my rpi (cm5, emmc) so they're not wiped out on reboot. It seems that diskless mode is default, and that i've to change to system disk mode manually. Docs have instructions but it's not entirely clear what i've to do.. (1/)
2026-06-08 13:05:17 <linio> for example, https://wiki.alpinelinux.org/wiki/System_Disk_Mode says at the top that "If an entire hard disk(s) is available for Alpine Linux, setup-alpine based install is the recommended way", but setup-alpine seems to not recognize the pi's emmc, because it lists only what i understand to be the hardware boot partitions
2026-06-08 13:06:35 <linio> even after creating the partition manually yesterday (type "linux") setup-alpine didn't recognize it
2026-06-08 13:16:30 <ncopa> i think this is a question for #alpine-linux but you can either use lbu to manually save your local changes so it survives reboot or use system disk mode. You can do something copy-modloop or what it was before you start setup-disk and unmount the boot media and it will show up in installer
2026-06-08 13:17:11 <ncopa> or you could try alpine 3.24.0_rc1 which was just released. IIRC there was some fixes to this usecase
2026-06-08 13:46:27 <linio> ncopa ok thanks, will give this a look and keep in mind #alpine-linux for these more sysadmin kind of questions
2026-06-08 15:17:50 <linio> since already started here, can i ask a follow-up (and actually i also asked in the general channel but didn't got a reply)? got " /usr/sbin/update-raspberrypi-bootloader: WARNING: no kernel found
2026-06-08 15:17:50 <linio> ext4 is not supported. Only supported are: vfat" running the `setup-disk -m sys /mnt` as per instructions. and not seeing this in troubleshooting https://wiki.alpinelinux.org/wiki/System_Disk_Mode
2026-06-08 15:22:51 <linio> where can i open issues about the wiki, would like to collect all the problems i'm having in one report
2026-06-08 15:28:01 <linio> ok it's a wiki so i guess it doesn't work like that
2026-06-08 15:32:47 <linio> eh, i think i was in the wrong server, so actually haven't asked there
2026-06-08 16:53:36 <WhyNotHugo> Can I somehow apply `options="net"` for `prepare()` but have other steps with no network?
2026-06-08 17:20:40 <ikke> No
2026-06-08 20:46:22 <f_> FYI, an update regarding armhf in pmOS: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/work_items/4615     -  TL;DR pmOS considering dropping it, barely any device actually armhf on our side
2026-06-08 20:50:23 <Habbie> thanks for the "To be clear" because i'm confused every time (even though i actually know better)
2026-06-08 20:50:50 <ncopa> i tagged 3.24.0_rc2
2026-06-08 20:58:49 <f_> Habbie: you're welcome ^^
2026-06-08 20:58:57 <Habbie> :)
2026-06-08 20:59:12 <f_> I know it can be quite confusing :)
2026-06-08 20:59:45 <f_> especially given pmOS-armv7 is still very much alive and kicking
2026-06-08 20:59:55 <Habbie> yeah, i have one sitting right next to me
2026-06-08 21:00:06 <f_> a lot of developments going on in armv7 world still
2026-06-08 21:00:32 <Habbie> on my other side a machine that might get openwrt one day because alpine/pmos draw lines (sensible lines, to be clear)
2026-06-09 01:37:52 <qaqland> https://github.com/sivel/speedtest-cli is archived
2026-06-09 01:38:22 <qaqland> we can drop community//speedtest-cli now
2026-06-09 07:25:03 <ncopa> Anything blocking a 3.24 release?
2026-06-09 07:31:39 <moha-al> I just tried to install 'coreutils' on the alpine:edge Docker image and running binaries from the package results in relocation errors like: 'Error relocating /bin/ls: renameat2: symbol not found'. Don't think it's a blocker, but wanted to mention it :)
2026-06-09 07:35:30 <ikke> ncopa: I'd give it a bit more time for people to test and provide feedback
2026-06-09 07:36:20 <ikke> moha-al: You probably need to make sure musl is up-to-date
2026-06-09 07:39:04 <moha-al> @ikke: Ah, ok. Thanks, it works after an 'apk upgrade'. Thought 'apk add coreutils' would have pulled that in automatically if required.
2026-06-09 07:39:35 <ikke> Only if there is a soname change
2026-06-09 07:44:02 <omni> one thing I'd like to get in, if possible, is the libvpx security upgrade, it's been blocked by firefox builds OOMing on x86 trying to build glean but that may no longer be an issue
2026-06-09 07:48:23 <omni> working on a rebase now
2026-06-09 08:00:21 <dne> how about !101193 before releasing?
2026-06-09 08:00:56 <dne> (those build failures are not related to the upgrade)
2026-06-09 08:01:37 <dne> s/build/test/
2026-06-09 08:14:01 <ncopa> ok
2026-06-09 09:06:29 <omni> I have hopes that !96959 will pass but the rebuilds will take a long time on riscv64
2026-06-09 10:26:02 <ncopa> im tagging 3.24.0 today. was about to do it now. we will have to backport the security fix after the release. unless you want hold the release til this is merged?
2026-06-09 10:26:37 <ncopa> ABI breakages after 1 April can not expect to be included in release
2026-06-09 10:30:22 <ncopa> i think  !96959  will delay the release up to one more week. it will take days for riscv64 to build those i think
2026-06-09 10:54:10 <ncopa> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/129
2026-06-09 10:55:01 <ncopa> drats....
2026-06-09 10:55:04 <ncopa> new kernels
2026-06-09 10:57:39 <ncopa> i'm gonna update the kernels
2026-06-09 11:58:37 <ncopa> please hold your git pushes unless they are needed to get 3.24 out the door
2026-06-09 12:00:48 <ncopa> ugh. rust-analyzer takes more than an hour
2026-06-09 12:01:02 <ncopa> trying to calculate if we are getting 3.24 out today or not
2026-06-09 12:01:24 <ncopa> tomorrow I will have limited time
2026-06-09 12:25:37 <Sertonix[m]> I wonder if we should drop community/lockdev
2026-06-09 12:32:40 <omni> I think we should start thinking about branching before .0 releases
2026-06-09 12:33:07 <omni> the way we do releases makes the first release of a branch feel like a release candidate
2026-06-09 12:41:31 <Habbie> as a random developer from a different project, i can recommend branching before .0, but not too far before
2026-06-09 12:45:19 <ncopa> i dontk now what to say about grub as I haven't had time to look at the issue and try reproduce it. As I understand you need to run grub-install? Are there any upstream docs we can point to on how to upgrade grub?
2026-06-09 12:46:07 <ncopa> we had similar issue with 3.19 https://alpinelinux.org/posts/Alpine-3.19.0-released.html
2026-06-09 13:11:12 <omni> it is what !58567 is about, isn't it?
2026-06-09 13:29:17 <ikke> This comes back to what minimal was trying to accomplish, some way of recording how grub was installed and automatically update grub based on that information
2026-06-09 13:29:57 <durrendal> +1 on that, we really show revisit that
2026-06-09 13:30:13 <durrendal> s/show/should/ s/that/it
2026-06-09 13:57:24 <ncopa> builders are idle, im tagging 3.24.0 now
2026-06-09 13:57:53 <f_> \o/
2026-06-09 13:58:38 <Habbie> \o/
2026-06-09 13:58:55 <Habbie> i guess i'm doing backports of one of my open MRs :D
2026-06-09 14:00:31 <mio> \o/
2026-06-09 14:08:03 <omni> rust-analyzer was not just an upgrade, it was re-enabling on riscv64
2026-06-09 20:43:13 <ncopa> ok to merge this now? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/129
2026-06-09 20:47:52 <achill> looks fine to me
2026-06-09 20:49:06 <ncopa> merged. thanks!
2026-06-09 20:49:17 <ncopa> will have to start on the 3.24.1 now, or tomorrow...
2026-06-09 20:58:43 <Habbie> congrats!
2026-06-09 20:58:52 <PaoloBarbolini[m]> The postgresql 17 link goes to a 404 page
2026-06-09 21:06:24 <ncopa> what. i thight I deleted postgresql 17
2026-06-09 21:09:06 <ncopa> drats
2026-06-09 21:09:11 <ncopa> was an old copy
2026-06-09 21:09:20 <ncopa> shouldnt do this when I m tired
2026-06-09 21:14:24 <ncopa> should be fixed now
2026-06-09 21:14:26 <ncopa> sigh
2026-06-09 21:14:37 <ncopa> thank you!
2026-06-09 21:27:33 <panekj> "The installer (setup-alpine) now supports the Limine boot loader has gained IPv6 support."
2026-06-09 21:27:51 <panekj> feels like some words are missing
2026-06-09 21:28:07 <panekj> ncopa: ^
2026-06-09 21:30:33 <panekj> also that whole section about installer is missing from wiki
2026-06-09 23:00:25 <Ariadne> congrats on the release
2026-06-10 01:35:47 <qaqland> \o/
2026-06-10 10:11:48 <fabricionaweb> \o/
2026-06-10 10:12:20 <Ermine> 
ACTION throws release confetti

2026-06-10 10:12:42 <fabricionaweb> lmao for the aports contribuitor /dev/urandom 0xDEADCADE 
2026-06-10 12:13:58 <ncopa> cf8e40a28b29c7023aaf62f48be4af3c131ea1ae
2026-06-10 12:14:19 <ncopa> thats /dev/urandom's contrib ^^^
2026-06-10 15:44:55 <jahway603[m]> I realize that 3.24 was released yesterday, but can I please get !103774 merged for 3.23 as the last synapse backport for that release?
2026-06-10 16:30:40 <Saijin_Naib[m]> Is the limine integration in 3.24 meant to be feature-comparable to grub? For instance, changing from linux-lts to linux-stable even with the hook does not update the limine config to load the linux-stable assets
2026-06-10 16:31:49 <Saijin_Naib[m]> Otherwise, it is very nice and much easier to read and understand the config. Thanks for this alternative, all who implemented it
2026-06-10 16:32:10 <Saijin_Naib[m]> Is there a path to easily migrate existing grub installs to limine?
2026-06-10 17:12:04 <Sertonix[m]> GRUB and limine can be installed in parallel (on UEFI systems) and limine can be tested with efibootmgr -n to reduce the risk of ending with an unbootable system.
2026-06-10 20:28:43 <aelin> looks like dovecot needs a rebuild, it's still linked against an old libxapian
2026-06-10 20:29:00 <f_> it's not urgent at all, but I'd appreciate it if someone could look at !97202 :)
2026-06-11 06:54:37 <alexaandru> hi all! congrats on the release! :-) I have this MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103818 - I am offering to take over the maintainership as I noticed the current mainainer (@ajhalili2006) is busy for quite a while now. It's my 1st time so please advise: is it enough to ask in here, or should I try and contact him directly? Thank you!
2026-06-11 06:56:11 <alexaandru> Also, that APKBUILD comes with a patch https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/github-cli/no-ignore-goflags.patch - what am I missing here? Why would we ever care how github-cli is built on windows? We don't have apks for windows, do we? I just can't think of any scenario where that patch would make a difference...
2026-06-11 06:58:59 <ajhalili2006> hi @alexaandru: apologies for the inactivity in my maintainer role (tl;dr: college life as first-year IT student + getting hit by the autistic burnout) but I got notified via my IRC client on my phone, so go ahead and ask.
2026-06-11 06:59:53 <ajhalili2006> I might also do a maintainer email address update on github-cli's APKBUILD later this month alongside checking for any pending MRs relating to it (also additional maintainers wanted)
2026-06-11 07:05:45 <qaqland> alexaandru: just use !103818 instead of url
2026-06-11 07:06:17 <ajhalili2006> re https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103818 for alexaandru: I already LGTM'd the maintainer takeover but I will add myself back as co-maintainer w/ updated email address soon once merged.
2026-06-11 07:07:12 <alexaandru> thank you both! :-) 
2026-06-11 08:24:02 <Saijin_Naib[m]> Anyone have time to review some of my open MRs for Testing, like !97292 !99156 !93699
2026-06-11 08:24:43 <Saijin_Naib[m]> Pitivi and TextPieces would be most impactful for me, as I use Pitivi for video editing and TextPieces for random text transformations and developer-adjacent stuff I am bad at
2026-06-11 08:25:09 <Saijin_Naib[m]> And exaile too, since that is what I use to listen to music, but that is just for relaxing so not as pressing to have reviewed
2026-06-11 08:26:14 <Saijin_Naib[m]> !96399, sorry
2026-06-11 11:53:57 <ncopa> I have drafted a proposal for the AI policy issue. https://gitlab.alpinelinux.org/alpine/council/-/work_items/697#note_618411 I'd like to hear what maintainers think
2026-06-11 12:26:15 <andypost[m]> Would be great to note kinda don't contribute what you do not understand
2026-06-11 12:38:51 <WhyNotHugo> andypost[m]: agreed, I prefer an "I tried to do X and got Y error" than an in-depth AI-generated explantion which is sophistry.
2026-06-11 19:12:45 <Habbie> i don't see loongarch on https://hub.docker.com/_/alpine/tags?name=edge, where can i get an image?
2026-06-11 19:14:09 <Habbie> ok got it
2026-06-11 19:14:14 <Habbie> podman import https://dl-cdn.alpinelinux.org/alpine/v3.24/releases/loongarch64/alpine-minirootfs-3.24.0-loongarch64.tar.gz alpine-loong:edge
2026-06-11 19:14:24 <Habbie> ok that's not edge, but it's fine for now
2026-06-11 19:24:24 <Habbie> whelp, then doas/sudo don't work while they do in images from the hub. i wonder why
2026-06-11 19:26:01 <Habbie> (red herring, doas/sudo are broken under qemu for me, surely for some good reason)
2026-06-11 19:27:43 <witcher01> afaik raspberry pi has no guarantees on how long they support a specific kernel version. linux-rpi is in main so it should be supported for 2 years on alpine
2026-06-11 19:28:18 <witcher01> what happens if rpi were to drop 6.12 which is part of 3.23? do we update to their 6.18? do we stop updating the package for 3.23 because upstream isn't providing any?
2026-06-11 19:28:45 <witcher01> isn't providing any updates?*
2026-06-11 19:29:51 <elibrokeit> well, I suppose it would be irrational to declare that alpine has taken over as the lead developers of rpi-6.12
2026-06-11 19:38:05 <Habbie> (qemu sudo sorted)
2026-06-11 20:02:18 <jvvv> Habbie: I was looking into that (I do a lot of cross container stuff that depends on binfmt) but got sidetracked. How did you sort it?
2026-06-11 20:06:34 <Habbie> jvvv, top answer at https://stackoverflow.com/questions/75954301/using-sudo-in-podman-with-qemu-architecture-emulation-leads-to-sudo-effective-u was exactly right for me (on debian 13)
2026-06-11 20:06:36 <Sertonix[m]> IIRC it is mentioned in thw release notes
2026-06-11 20:08:42 <jvvv> Thanks. Will look at those now. I'm still using qemu-binfmt service, but should get myself on track with the new binfmt service.
2026-06-11 20:08:59 <Habbie> the core part is that C flag
2026-06-11 20:09:04 <Habbie> whatever you use probably makes it easy to add
2026-06-11 20:09:26 <Habbie> probably can even echo it into /proc with little effort somewhere
2026-06-11 20:15:50 <jvvv> Cool, thanks again. And thanks to Sertonix[m] for your work on the binfmt integration.
2026-06-11 20:27:55 <Habbie> mio came to me about the build failure in https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/pdns-recursor/pdns-recursor-5.4.2-r0.log
2026-06-11 20:28:00 <Habbie> and i don't want to keep bothering mio about it
2026-06-11 20:28:08 <Habbie> the failure does not occur for me locally with qemu-static
2026-06-11 20:28:24 <Habbie> coworker mentioned that the failing test uses /tmp - any chance /tmp is weird on the loongarch64 builders?
2026-06-11 20:29:29 <aelin> let me check if i can reproduce this on my loongarch64 machine
2026-06-11 20:29:41 <Habbie> good one, rule out the qemu difference
2026-06-11 20:29:50 <Habbie> i just went into community/pdns-recursor and ran abuild -rK as my test
2026-06-11 20:30:18 <Habbie> aports master, alpine minirootfs 3.24.0 (see 19:14:13 UTC) in podman with, again, qemu-static
2026-06-11 20:36:14 <aelin> >>> pdns-recursor: Updating the community/loongarch64 repository index...
2026-06-11 20:36:14 <aelin> >>> pdns-recursor: Signing the index...
2026-06-11 20:36:21 <aelin> worked fine on a 3B6000
2026-06-11 20:36:38 <aelin> so yeah i second the suspicion that something's up with the builder
2026-06-11 20:36:42 <Habbie> thanks!
2026-06-11 20:44:16 <Habbie> (i moved to #alpine-infra to ask about the builder)
2026-06-12 00:55:50 <infinitywisdom[m]> If anyone is feeling adventurous and would like to test out Alpine Linux on bare metal, or in a virtual machine. I could use some help with testing out a new piece of software. https://codeberg.org/infinitywisdom/Alpine-Linux-NM-Setup.git
2026-06-12 00:56:17 <infinitywisdom[m]> * virtual machine with Network Manager. I
2026-06-12 03:12:51 <Ariadne> aelin: afaik the builder is 3C5000L
2026-06-12 03:13:10 <Ariadne> so it might not be complete loongarch ISA
2026-06-12 06:28:18 <qaqland> package wants to set date and commit when build, for commit I can manually update, what about date? should I use $(date) or something like SOURCE_DATE_EPOCH
2026-06-12 06:28:25 <qaqland> https://github.com/slimm609/checksec/blob/b5a6951e241b6cc3d936fd70bf128b5f992da826/cmd/root.go#L29
2026-06-12 06:31:16 <lotheac> imo SOURCE_DATE_EPOCH seems reasonable
2026-06-12 06:50:01 <qaqland> thanks it works: checksec version 3.1.0 (Built on 2026-06-12 from Git SHA 3c42e52bb1146980bd8371dfc9ea0862333d730b)
2026-06-12 07:01:52 <machophd> hi all , We are bunch of Researcher , Come find Us for source code , research and phd social science at https://www.machophd.org/2026/06/12/elitez-0day-xc-our-news-skraito-here-god-husband-come-find-me-at-chat-live-for-source-code-os-researcher-chat-and-many-more-even-game-all-paternize-by-us-including-conver/
2026-06-12 07:17:33 <elibrokeit> that url is full of more random words than a homemade pastebin server's url generator function
2026-06-12 07:27:09 <skarnet> the phishermen are getting lazier every day
2026-06-12 09:09:48 <f_> oh it's just skraito
2026-06-12 09:49:09 <ncopa> Im gonna do an «office hours» thing today at 15:00 CEST anyone who want to talk with me is welcome. Topic will be contributing guidelines 
2026-06-12 10:01:46 <lotheac> as in 13:00 UTC?
2026-06-12 10:07:56 <Ariadne> in 3 hours?
2026-06-12 10:10:29 <ncopa> Yes
2026-06-12 10:11:53 <lotheac> i can't make it, but does seem like a good idea
2026-06-12 11:47:38 <WhyNotHugo> I'm surpised the "ban people using AI" stance is so strong, yet there's never been any issue with contributing using proprietary software, where all the same ethical concearns are shared.
2026-06-12 11:47:49 <WhyNotHugo> I've seen a couple of MRs even focusing on WSL.
2026-06-12 11:50:18 <Sheila> proprietary software scabs people? what?
2026-06-12 11:54:52 <f_> WhyNotHugo: Don't we discourage using proprietary software and explicitely don't package any unless it's firmware?
2026-06-12 11:55:42 <f_> discourage.. not sure, but aports doesn't have any proprietary software (with firmware being the exception)
2026-06-12 11:56:20 <WhyNotHugo> We don't ban using proprietary software to make contributions tho, we only evaluate the result. And we do package clients which exist purely to interact with proprietary services (e.g.: aws-cli).
2026-06-12 11:56:28 <f_> and with developers rejecting proprietary software packages in aports, that is effectively a ban of proprietary software
2026-06-12 11:57:06 <WhyNotHugo> The proposed ban on AI is to ban "contributions made with", not to ban LLM models themselves from repositories.
2026-06-12 11:58:11 <f_> if you want to ban using proprietary software to make contributions feel free...
2026-06-12 11:58:23 <Sheila> (I feel like 'proprietary software [has] all the same ethical concerns' misunderstands the concerns of people who oppose the use of LLMs, since among them is the fact that they represent a theft of labour, knowledge, and expertise.
2026-06-12 11:58:27 <f_> I see no issue with doing that, or at least discouraging use of it
2026-06-12 11:58:41 <Sheila> which is *not* an ethical concern people generally have with proprietary software.
2026-06-12 11:58:48 <f_> but while proprietary software do have ethical issues, these are different from LLMs' ethical concerns.
2026-06-12 11:58:54 <f_> most of them anyway
2026-06-12 11:59:27 <f_> I'm pretty sure proprietary software is not made by kenyans being paid pennies to look at horrible images
2026-06-12 12:00:54 <f_> but chatgpt is definitely trained at least partially like this
2026-06-12 12:01:24 <WhyNotHugo> You honestly think that proprietary software (especialy that made by large corporations) is not at all the result of exploitation of workers? You think it doesn't take what's useful from the FLOSS commnity without giving back?
2026-06-12 12:01:50 <f_> I do think they are exploiting workers
2026-06-12 12:02:04 <f_> and taking things from FOSS communities without giving anything back
2026-06-12 12:02:37 <Sheila> the entire economic structure we all operate under exploits workers. proprietary software is in no way special in that regard.
2026-06-12 12:02:59 <f_> but it is clear alpine is against proprietary software as I see none of them are accepted in aports
2026-06-12 12:03:03 <f_> (again, with the fw exception)
2026-06-12 12:03:14 <f_> alpine is free software
2026-06-12 12:04:08 <WhyNotHugo> Indeed, but we don't ban contributions _made_ with it. If someone used sublime-text to patch an APKBUILD on WSL, that's perfectly allowed, as long as it aligns with our standards.
2026-06-12 12:04:21 <f_> Alpine is (supposed to be) part of the free software movement to counter proprietary software
2026-06-12 12:04:47 <f_> WhyNotHugo: but do we ban contributions made by someone who is exploiting workers to do it?
2026-06-12 12:05:11 <f_> I'm not sure letting that kind of thing slide would be very benefical for alpine's reputation
2026-06-12 12:05:33 <Sheila> WhyNotHugo: is it even possible for us to know if someone uses st rather than vscodium or vim or emacs or nano? no. why expend time or energy on that consideration?
2026-06-12 12:05:37 <f_> yes, you can use proprietary software to patch an APKBUILD, but it is still your own work to some extent
2026-06-12 12:05:54 <f_> while LLM-generated contributions are by design not your own work
2026-06-12 12:06:27 <f_> If alpine recommends against proprietary software, then I see no reason why it shouldn't recommend against use of LLMs.
2026-06-12 12:06:59 <Sheila> WhyNotHugo: versus, the primary consideration with LLM-assisted work is that we are human beings and our time is valuable, and we would prefer to focus on high-quality contributions. most LLM-assisted work is low-quality.
2026-06-12 12:07:36 <f_> And the result is still your own work no matter if you use sublime text or whatever. But like I said: add an LLM, and it is no longer *your* *own* *work*
2026-06-12 12:07:56 <WhyNotHugo> Sheila: if you don't want to waste time with low-quality contributions, then prohibit that instead.
2026-06-12 12:08:29 <Sheila> and if you can figure out a way to do that that will actually work, I will be eager to see your proposal.
2026-06-12 12:08:40 <f_> we should not let LLMs slide because "eh, there's also this, this and that with the same or similar ethical concerns and it's fine!"
2026-06-12 12:09:20 <f_> some other category of software having similar ethical concerns is not a reason to ignore them.
2026-06-12 12:09:31 <f_> anyway, I'll be right back
2026-06-12 12:09:59 <WhyNotHugo> I didn't mean to imply "we should let is slide because we let somethign else slide before": I'm just honestly surprised at the intense witch-hunt against one thing, with claims as far as "ban it or we'll fork Alpine", while the prior precedent went entirely without mention.
2026-06-12 12:10:46 <Sheila> and if you can figure out how to tell if someone's contributions were made with proprietary software, you can propose a ban on that.
2026-06-12 12:11:29 <WhyNotHugo> FWIW, I think when passing legislation one needs to focus on "what's the expected outcome" of this rule. If you prohibit the use of specific families of tools, the most likely outcome is that people won't disclose the use of such tools.
2026-06-12 12:46:30 <f_> WhyNotHugo: it isn't as easy as "Ban AI or we'll fork Alpine"
2026-06-12 12:46:32 <Sertonix[m]> WhyNotHugo: See https://gitlab.alpinelinux.org/alpine/council/-/work_items/697#note_569378
2026-06-12 12:46:40 <f_> you seem to be missing a lot of the context
2026-06-12 12:46:47 <f_> AI is just the tip of the iceberg
2026-06-12 12:50:12 <Sheila> WhyNotHugo: the "or I/we'll fork" people are upset about a lot of other governance issues, the AI biz is just the straw that broke the camel's back.
2026-06-12 12:50:18 <f_> ^
2026-06-12 12:57:50 <ncopa> I have "office hours" now in case someone wants to talk about contributing guidelines. https://meet.jit.si/NatanaelsCorner
2026-06-12 14:41:22 <invoked> WhyNotHugo: what might be overlooked in this discussion is that when people say "LLMs" they are almost exclusively talking about using commercial tools, with companies approaching trillion dollar valuations. we're not talking about people using open source tools and open source models.
2026-06-12 14:42:04 <invoked> what is open source development anymore, is my question
2026-06-12 14:46:14 <WhyNotHugo> invoked: right, they're usually referring to commercial proprietary tools, but if the rule says "no LLM", that rule is including an open source harness running in someone's basement too.
2026-06-12 14:48:53 <invoked> almost always. but, i mention this as a potential path of productive discussion. it might be getting too existential for some people, but why are we doing this work? to indirectly reward all these companies that pilfered our work to start with?
2026-06-12 14:49:13 <invoked> maybe a policy could include a distinction between using open source tools and open source models vs commercial ones
2026-06-12 14:49:43 <f_> It's not impossible to have an open source model, but in practise most models are proprietary
2026-06-12 14:49:46 <f_> even if running locally
2026-06-12 15:00:23 <invoked> it would send a signal, i guess, if a project policy said (roughly) "contributions are only accepted from humans. the human can be assisted by LLM tools, however, the usage of such tools must be fully disclosed, and the tools and the models must be open source according to <etc>"
2026-06-12 15:01:07 <invoked> but i'm guessing in this context we're trying to thread the needle on allowing use of commercial tools
2026-06-12 15:03:00 <invoked> which for me, is a deal breaker. cozying up to megacorporations directly or indirectly is not why i got into open source whatever, ~30 years ago.
2026-06-12 19:55:03 <staceee> why do I have this with abuild? Missing subpkgdir for foo-bar-doc?
2026-06-12 19:55:15 <staceee> do we now need to mkdir the doc subpkg folder first?
2026-06-12 19:58:29 <achill> usually not, maybe there are no doc files in $pkgdir?
2026-06-12 19:59:23 <staceee> ah gotchat!
2026-06-12 19:59:29 <staceee> wrong prefix
2026-06-12 23:47:37 <Ariadne> WhyNotHugo: yes, we should also not cooperate with Microsoft's colonization of Linux by way of WSL
2026-06-12 23:47:57 <Ariadne> this has been a position i've held since before Alpine was using Gitlab
2026-06-12 23:48:44 <Ariadne> we could have let WSL die on the vine as a tech demo, but too many open source leaders at that time fell for the trap
2026-06-12 23:49:06 <Ariadne> and yes, i'm still mad about *that* too
2026-06-13 02:00:47 <infinitywisdom[m]> If anyone of you is looking for a good markdown editor. I just discovered this one and it is outstanding. https://flathub.org/en/apps/io.github.olaproeis.Ferrite
2026-06-13 04:08:08 <Biswa96[m]> "This project is 100% AI-generated code" - https://github.com/OlaProeis/Ferrite
2026-06-13 04:08:08 <Biswa96[m]> nice!
2026-06-13 07:32:46 <ncopa> witcher01: lets set up a video call. I'd be happy to answer any questions in person
2026-06-13 07:50:11 <witcher01> ncopa: i appreciate the offer, thank you, but i'd really prefer if you could answer that question in the MR, even if it's closed now. i think this should be disclosed openly, not in a private call, as it doesn't just affect myself but also the community as a whole
2026-06-13 07:52:31 <witcher01> alternatively, if you don't want to disclose this in the MR i'm also okay with just replying on IRC. apologies, I only saw your reply just now
2026-06-13 08:28:44 <ncopa> eating breakfast now. i cannot reveal internal deals. but I do not think there is conflict of interest
2026-06-13 08:29:54 <achill> tbh imo the rest of the council should at least look over those deals to verify that there is no coi
2026-06-13 08:30:04 <achill> this is a big deal
2026-06-13 08:45:58 <witcher01> i agree with achill: the potential conflict of interest needs to be discussed. discussing this with the council and letting them decide if a conflict of interest exists sounds like a fair compromise
2026-06-13 08:50:40 <witcher01> the fact that this discussion on a LLM policy made you voice your concerns for not being able to contribute to Alpine any longer is a point of concern for the independence of Alpine to me. the case that this affects you, founder of Alpine and someone with a high position in governance, is what makes this so important
2026-06-13 09:22:41 <ncopa> what I can tell is that when I worked for Docker, they let me work 100% on alpine a period
2026-06-13 09:23:34 <ncopa> there was no-one pushing me to try steer alpine in any direction
2026-06-13 09:24:35 <ncopa> their selling point was that docker should work on *all* platforms and they did not want any OS be percieved as special
2026-06-13 09:25:33 <ncopa> questions has been rised about commercialicing alpine but the answer was always: sure, but not here
2026-06-13 09:25:51 <ncopa> they have always intentionally wanted Alpine to be independent
2026-06-13 09:26:24 <ncopa> when Mirantis bought Docker enterprise that did not change
2026-06-13 09:27:50 <ncopa> they have wanted me to spend less work hours on alpine though, and I have been happy for whatever they have given
2026-06-13 09:28:52 <ncopa> but there has always been a strong desire to keep alpine separate
2026-06-13 09:28:59 <achill> and we dont judge that. we judge that youre employer can force you to use ai and therefore youre using your power to not establish a hard-AI-ban policy. we dont think that mirantis/docker/iren is telling you to do this, but it has a influence, which would then be a coi.
2026-06-13 09:29:35 <Sertonix[m]> achill: Isn't somethink like "I need X in Alpine so I will argue for it" something that everybody using and developing has? Do we call that a conflict of interest now?
2026-06-13 09:29:53 <achill> and i dont feel happy, if your employers agenda has such a high-level on alpine
2026-06-13 09:31:05 <ncopa> occationally they have asked for help with alpine related stuff. mostly "is this CVE fixed"
2026-06-13 09:31:17 <achill> Sertonix[m]: sure, but using your power for that is a no-go.
2026-06-13 09:31:40 <achill> e.g. ariadne resigned from the tsc when she was developing a counter product
2026-06-13 09:33:03 <ncopa> with things like aquisitions happens people start look at priorities etc. and re-negotiations may happen
2026-06-13 09:34:24 <ncopa> so it may be wise to not try to rock the boat for me if I would like to continue work on Alpine
2026-06-13 09:35:21 <ncopa> i do have experimented with AI last years
2026-06-13 09:35:40 <ncopa> and recently I have got a new machine powerful enough run local open source LLMs
2026-06-13 09:36:32 <ncopa> those new tools can do things that was impossible a year ago
2026-06-13 09:37:21 <ncopa> i can also disclose that I do have an AI powered vaccum cleaner, and I love it
2026-06-13 09:38:01 <staceee> those tools still rely on massive energy consumption, licence violation, deep learning and so web ddosing, children in mines, etc
2026-06-13 09:40:31 <panekj> to me it is questionable if alpine can call itself pro- FOSS and community when leaders do not live by those goals
2026-06-13 09:42:20 <achill> ncopa: if your employer has full influence on alpines policies, your employer has control over this project. doesnt matter if they let you work for them or not, they do, even if they dont explictly tell you to.
2026-06-13 09:44:07 <achill> i dont know if that is whats happening, but it surely sounds like it to me
2026-06-13 09:44:22 <ncopa> staceee: for exactly that reason I do not want to talk about my person AI use. I respect that people want to vaccum by hand to use tools that depend on children working in mines. I don't want influence their decision
2026-06-13 09:45:00 <ncopa> achill: they dont have full influence on alpines policies
2026-06-13 09:45:39 <ncopa> and I dont think they care about alpines policies
2026-06-13 09:45:55 <achill> my issue is 5 months open without a council decision and youre talking about "if we do a AI ban, i cant work here in my work-time"
2026-06-13 09:46:57 <achill> im trying to understand whats going on here, but didnt you yesterday wrote in the MR, that they do care if you cant use AI in alpine?
2026-06-13 09:48:37 <panekj> afaik, it's not work related but that if AI ban would happen, ncopa could cease contributions completely which is concerning because I don't believe everything you do is done via LLMs, unless...?
2026-06-13 09:48:54 <achill> that sounds like you have another interest, than just the future of alpine: your future employment
2026-06-13 09:48:59 <staceee> at the very least that feels like a foot-in-the-door technique to me
2026-06-13 09:49:34 <ncopa> sorry, for not being clear. I though I used terms like "unlikely" or "probably". I don't know what will happen in the future. But I do want to have a strong position where I can document that my involvement Alpine is good for the company I work for.
2026-06-13 09:51:28 <ncopa> with docker I could say: "look the cost for the bandwith for alpine docker images is this, if people would have used ubuntu images the cost would have been number which is way higher than you pay me. Is it ok for you that I work on Alpine?"
2026-06-13 09:54:33 <achill> but this shouldnt influence Alpine's decision on a AI policy, espeically with you being on the role of the council.
2026-06-13 09:54:37 <ncopa> I want be able to use AI in my work in alpine for the same reason I want be able to use AI to vaccum my home. It can be used to free my time I spend on chores so I can spend my time on stuff I would like to work on
2026-06-13 09:54:54 <achill> as a concil chair I expect you to handle whats best for alpine, not for your employment
2026-06-13 09:55:17 <achill> you have responsablities as a council member
2026-06-13 09:55:55 <achill> sorry, im a bit emotional right now, im gonna be afk and get some fresh air
2026-06-13 10:00:20 <ncopa> I honestly believe that it is in Alpine Linux's projects best interest to have as few bans as possible. go look at alpine history. I have always been against or skeptic to ban anything.
2026-06-13 10:01:20 <ncopa> Bans are absolutely last resort, when there are no other solutions, when every other potential solution has been evaluated
2026-06-13 10:02:06 <ncopa> that is how I always have handled things in alpine
2026-06-13 10:03:13 <omni> but we have a code of conduct because we have values
2026-06-13 10:04:06 <ncopa> regardless if it is a question about coding style, CoC, systemd, licenses or whatever
2026-06-13 10:04:56 <panekj> one of those things was banned...
2026-06-13 10:05:39 <ncopa> and there was lot of drama around the CoC. It was a painful process. but it was necessary
2026-06-13 10:06:03 <ncopa> and i think there was one or two highly technically skilled devs who left
2026-06-13 10:08:16 <ncopa> if we have to ban AI, so be it. but I don't want to do so without be sure that all possible alternatives has been evaluated.
2026-06-13 10:09:21 <staceee> projects that dont stand clearly against burns-out under agent contributions, and they are added as pin-point on slop lists
2026-06-13 10:09:45 <ncopa> and right now it is not possible to have a reasonable discussion on what alternatives could even be
2026-06-13 10:10:30 <ncopa> slops is a problem which I think we should solve as fast as possible
2026-06-13 10:12:35 <achill> I'm very sorry ncopa, my issue was 5 months open, you as a member of the council had soo much time to evaluate alternatives. but you didn't. I'm sick of it.
2026-06-13 10:14:14 <f_> tbh it looks like everyone including ncopa is sick of it
2026-06-13 10:16:33 <ncopa> I do not think that it is Alpine Linux best interest to make decisions driven by emotions of an angry mob. nor is it in Alpine best interest that decisions are driven by Commercial interests of any company.
2026-06-13 10:20:55 <ncopa> I do not see it as a good sign when there is a majority who think it is more important to either ban or at least disclose AI use than it is that contributors takes responsibility for their submissions and refrain from submitting avoidable review burden for maintainers
2026-06-13 10:21:14 <achill> yet your own employers commerial intestes may indirectly be inflencing the council decision
2026-06-13 10:22:31 <achill> i think taking responsibility of own changes is obviously a must, no body is denying that. but the lack of more AI restrictions is whats concerning.
2026-06-13 10:22:55 <ncopa> sure. councils decisions will have consequences. councils job is to try find out what the consequences will be and figure what is best for the project
2026-06-13 10:23:07 <Sertonix[m]> achill: achill: Can you propose a concept that prevents this from happening and that does not rely on humans never making mistakes?
2026-06-13 10:24:08 <ncopa> banning AI will have consequences. how will that impact the project
2026-06-13 10:24:08 <achill> you mean COI policies?
2026-06-13 10:24:59 <Sertonix[m]> achill: Just any policy/ruleset/whatever
2026-06-13 10:25:44 <ncopa> achill: what I find problematic is that lack explicitly spelling out AI or LLM was more important than documenting the obvious thing
2026-06-13 10:25:54 <ncopa> i need to step out
2026-06-13 10:26:04 <ncopa> this is eating too much of my time
2026-06-13 10:26:25 <ncopa> and no I do not have had plenty of time the las 5 months. if you only knew...
2026-06-13 10:26:53 <achill> i would expect the council to have time for such important matters
2026-06-13 10:28:03 <panekj> If there weren't any governance issues, I would agree
2026-06-13 10:30:17 <Sertonix[m]> achill: What I generally mean is that if you want to make something better you have the best chances by proposing somethink that seems better to both you and others (considering their diverging opinions). Otherwise it's not clear if/how better is even possible.
2026-06-13 10:31:51 <achill> Sertonix[m]: if the council wants me to, i'd be happy for formulate a conflict of interest policy. but look at the council, it's completley unrealistic that they want that and even if so, i dont believe in the council to implement it
2026-06-13 10:33:30 <Ariadne> ncopa: respectfully, alpine is the backbone of cloud-native and agentic AI.  if your employer does not understand the business value of employing the founder of alpine, they are clueless.  an LLM ban will not change the immense business value your presence brings.
2026-06-13 10:33:47 <achill> also what i would love: we need some kind of process to elect council members. but hey, the current council must first accept that and implement that
2026-06-13 10:34:23 <f_|m> my main complaint is that the whole governance is not in the greatest shape (to put it kindly)
2026-06-13 10:37:34 <Sertonix[m]> (achill, written before one message, might still apply to others) So there is nobody really interested in doing the hard work of coming up something better so we can save some time/headacks by being aware of different opinions existing and stop wasting time arguing about this.
2026-06-13 10:38:13 <Ariadne> I'm not interested in wasting my time writing a policy statement that the founder and effective BDFL of Alpine does not want, no. 
2026-06-13 10:38:35 <Ariadne> like why bother?  it is a waste of time
2026-06-13 10:39:27 <achill> yeah, if ncopa is not going to implement it, because whatever now, you can also just not do it. it has the same effect.
2026-06-13 10:39:44 <qaqland> I feel the pressure is a bit too much right now
2026-06-13 10:40:39 <Ariadne> I've already mourned the state of Alpine, at this point I need to start making decisions to protect my livelihood from engineering and policy decisions I lack conviction in
2026-06-13 10:40:42 <achill> i think the pressure is deserved. we expect something from the alpine council. this is not a small project. and we have seen very little from the alpine council.
2026-06-13 10:41:31 <f_> it is a big project with governance issues. That's the root cause of it
2026-06-13 10:42:01 <Ariadne> it is a project that is again -- the backbone of large sectors of the global economy
2026-06-13 10:42:13 <Ariadne> yes I think we expect effective governance
2026-06-13 10:42:21 <Ariadne> I think the world must have it
2026-06-13 10:43:40 <f_|m> Ariadne: yep, and that is precisely the problem. This whole AI policy dispute is just a symptom
2026-06-13 10:44:24 <Ariadne> like it is not just ncopa it is all of us and our collective asses and reputations on the line, and we can't even meet the same standards as the kernel?
2026-06-13 10:44:27 <f_|m> but it looks like that wasn't clear for some people
2026-06-13 10:44:41 <Sertonix[m]> achill: Trying to throw stuff at the wall until something sticks seems better than telling others to wait until the council magically addresses concerns that it does not seem to share/understand.
2026-06-13 10:45:20 <Ariadne> why is throwing stuff that the council does not want "better" 
2026-06-13 10:45:34 <Ariadne> it is meaningless
2026-06-13 10:45:43 <Ariadne> there is no mechanism to override the council
2026-06-13 10:46:02 <Ariadne> so you're just sitting there throwing things to the wind that have no meaning
2026-06-13 10:46:18 <achill> I have tried that, i have opened council issues, no replies, pablo did a endless amount of work to help the council, very little contribution by the council was was seen. i dont think that throwing stuff on the wall works.
2026-06-13 10:46:55 <achill> if the council doesn't see its own problems. we are effectively screwed and cant do anything.
2026-06-13 10:46:59 <f_> fwiw, there is still no TSC and hasn't been one for more than months
2026-06-13 10:47:17 <Ariadne> we tried super hard to fix that
2026-06-13 10:47:49 <Ariadne> well Pablo tried super hard honestly 
2026-06-13 10:47:56 <Ariadne> I just gave him some feedback and support
2026-06-13 10:47:58 <achill> and its the lack action by the council where the bottle neck is
2026-06-13 10:48:13 <f_> https://lists.alpinelinux.org/~alpine/devel/%3C77aaaec294f2e6f897f5d182b1c35f065917d25d.camel%40postmarketos.org%3E     > We expect Ariadne and Pablo to present a proposal to the Council for approval before the next release.
2026-06-13 10:48:26 <f_> but we saw nothing but crickets
2026-06-13 10:48:29 <achill> and we cant do more than pushing them to finally do action
2026-06-13 10:49:05 <Ariadne> we did present a proposal
2026-06-13 10:49:08 <Ariadne> fwiw
2026-06-13 10:49:12 <f_> I figured, Ariadne 
2026-06-13 10:49:25 <Sertonix[m]> achill: With throwing stuff at the wall I didn't meant opening issues. I mean talking with most/all council members (in private if they prefer) to find something that they wouldn't rejekt. I can't tell what has been done.
2026-06-13 10:49:37 <Ariadne> I did that
2026-06-13 10:49:39 <f_> Ariadne: it is just waiting for the council to take action, isn't it?
2026-06-13 10:49:56 <Ariadne> what the council will accept is what ncopa proposed
2026-06-13 10:50:12 <Ariadne> because he thinks we can vibe code our way out of technical debt
2026-06-13 10:50:36 <f_> but technical debt is created by vibecoding...
2026-06-13 10:50:46 <Ariadne> personally I think deterministic problems are solved with deterministic solutions
2026-06-13 10:50:59 <Ariadne> like the xfce example given is silly
2026-06-13 10:51:20 <Ariadne> that is totally solvable with deterministic tools
2026-06-13 10:52:52 <panekj> in stagex, we have a bot specifically for that (it's very simple/dumb but it can be built further upon) which does not require AI
2026-06-13 10:53:04 <panekj> https://codeberg.org/stagex/release-monitoring-bot
2026-06-13 10:53:09 <Ariadne> exactly
2026-06-13 10:53:18 <Ariadne> this isn't hard
2026-06-13 10:53:41 <Ariadne> and I've proposed that type of automation but there is no interest in it
2026-06-13 10:54:07 <Ariadne> but letting an LLM do it is apparently better?  why is something that isn't consistent between runs better? 
2026-06-13 10:54:40 <panekj> long time ago I was proposing such thing (and I remember talking with you specifically about it) :>
2026-06-13 10:55:10 <Ariadne> and then I went and immediately built it when I did enterprise linux for a living
2026-06-13 10:55:22 <Ariadne> and... surprise!  it works! 
2026-06-13 10:55:42 <quinq> Yep
2026-06-13 10:55:48 <Sertonix[m]> Ariadne: They use random seeds as a way to be more convincing since humans expect variation. Not inherently there is no randomness
2026-06-13 10:55:50 <quinq> And there is the problem about dependency
2026-06-13 10:55:56 <quinq> As in tooling dependency
2026-06-13 10:56:07 <f_> quinq: yes, unskilling is real
2026-06-13 10:56:23 <Ariadne> well here's one for ya
2026-06-13 10:56:26 <f_> I've seen friends try to use LLMs for coding and within 2 weeks they'd have completely forgot how to code
2026-06-13 10:56:45 <Ariadne> last night anthropic pulled access to their latest model
2026-06-13 10:56:47 <f_> it's dangerous, but some people seem to know understand how dangerous it is
2026-06-13 10:56:56 <Ariadne> because they were forced to
2026-06-13 10:57:01 <f_> s/seem to know/seem to not/
2026-06-13 10:57:04 <Ariadne> so we become dependent on this stuff
2026-06-13 10:57:09 <Ariadne> and then it gets pulled
2026-06-13 10:57:10 <quinq> f_, I rather meant your infrastructure now depends (heavily) on a closed-source private tool
2026-06-13 10:57:12 <Ariadne> now were fucked
2026-06-13 10:57:18 <quinq> Then the proprietary just decides to make you pay for it
2026-06-13 10:57:23 <f_> quinq: that too.
2026-06-13 10:57:24 <quinq> Then decide to increase the price
2026-06-13 10:57:26 <quinq> Then…
2026-06-13 10:57:37 <f_> Or you just get pulled access to it whenever you criticise sam altman on twitter
2026-06-13 10:58:05 <quinq> I'm not even talking about the problem about *who controls* how it works, and so what results you get
2026-06-13 11:01:02 <Ariadne> and say we get hooked on commercial AI, how the fuck are we funding it
2026-06-13 11:01:26 <quinq> that
2026-06-13 11:03:51 <staceee> we already got an auto-updater bot, that's me, running abumpa while being excitedly reading all the release notes
2026-06-13 11:07:44 <quinq> staceee, sorry but you don't waste enough electricity
2026-06-13 11:22:18 <achill> yes, there is more involved than just auto-bumping packages. stuff like release notes, abi stability, dependency changes, patches and more. but this is solvable or at least can be made easier than it is today with proper automation. and i trust ariadne to get something like this correctly.
2026-06-13 11:22:43 <achill> with no AI involved and human interaction where it needs to be
2026-06-13 12:17:27 <ncopa> Anyone available to step in and do the 3.24.1 release work?
2026-06-13 12:18:16 <ncopa> Also, feel free to merge any MRs assigned to me
2026-06-13 12:41:02 <ncopa> i need to spend my mental energy on personal stuff for at least two weeks. (inc a funeral). but as mentioned, the world economy depends on alpine so i would appreciate help so i can at least two weeks off
2026-06-13 12:43:18 <achill> looking at https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17818, we can do a lot of release work, but e.g. we need you to sign releases (i think thats the biggest one depending on you)
2026-06-13 12:44:35 <achill> i'll see this weekend to start with it and help you out. something on my mind for a while now is also to make releng a team to enhance the bus factor.
2026-06-13 12:47:51 <achill> (which is basically a topic i'm gonna propose to the TSC, but since that doesnt exist yet, there is not much i can do now)
2026-06-13 12:57:25 <witcher01> is there (local?) tooling for the release checklist? at least some of the items can be automated quite well: linux-lts+linut-rpi in sync, whether packages are up-to-date, creating a milestone, tagging the new version, making an announcement, maybe more
2026-06-13 12:58:34 <witcher01> especially that "celebrate" part could use some automation, that's quite tedious /s
2026-06-13 12:58:59 <ncopa> witcher01: tech debt. lots of this has been done manual
2026-06-13 13:00:02 <witcher01> just because i'm curious: how long does preparing a patch release usually take with the manual work?
2026-06-13 13:00:16 <ncopa> depends a bit
2026-06-13 13:00:34 <ncopa> it usually takes a day, or half day
2026-06-13 13:00:51 <witcher01> ah that's stil okay-ish. i expected multiple days
2026-06-13 13:01:08 <achill> but usually you also do minor releases for all major releases, right?
2026-06-13 13:01:11 <ncopa> writing release notes has been the hardest part for me. Im not good at expressing my self
2026-06-13 13:01:26 <f_> somebody can create a milestone for 3.24.1 perhaps?
2026-06-13 13:01:27 <ncopa> i admit i cheated a bit with the 3.24.0 release and used AI to assist me
2026-06-13 13:02:05 <f_> I know linux-rpi and lts are in sync and up to date, rpi-bootloader is up to date, tzdata as well.
2026-06-13 13:02:07 <f_> actually
2026-06-13 13:02:22 <ncopa> i have ususally done minor releases for all maintained in one go, instead of doing them individual
2026-06-13 13:02:23 <f_> oh there's the checklist :)
2026-06-13 13:02:35 <f_> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18249
2026-06-13 13:02:49 <ncopa> i can be around and sign stuff
2026-06-13 13:03:18 <ncopa> $ tpaste < tag-release 
2026-06-13 13:03:18 <ncopa> https://tpaste.us/wvxe
2026-06-13 13:03:55 <ncopa> $ tpaste < abump-kernel 
2026-06-13 13:03:55 <ncopa> https://tpaste.us/JLRg
2026-06-13 13:03:57 <witcher01> milestone for 3.24.0 is still open btw, only #18228 is still ongoing
2026-06-13 13:04:06 <witcher01> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18228
2026-06-13 13:04:27 <ncopa> yeah, i know. the openssl CVE popped up right after tagging 3.24.0
2026-06-13 13:05:10 <witcher01> the issue is about grub tho?
2026-06-13 13:06:08 <witcher01> what's the secret strin to make algitbot paste links to issues btw? doesn't seem to be #<issue_num>
2026-06-13 13:06:13 <ncopa> feel free to take over and fix it. I felt the proposed script looked way too complicated for my liking and was afraid it would create a maintenance burden. i have not had energy to follow it up
2026-06-13 13:06:50 <witcher01> i'm not invested in grub and know little about it, i was just wondering why the 3.24.0 milestone is still open after release
2026-06-13 13:07:14 <f_> should openssl get bumped to 3.6.3 or should it stay at 3.5.7
2026-06-13 13:07:34 <f_> oh wait
2026-06-13 13:07:47 <ncopa> i trust you make a good decision on that
2026-06-13 13:08:01 <achill> it should get stable patch release in a stable branch
2026-06-13 13:08:12 <ncopa> the 3.24.0 is still open because i got tired at the end
2026-06-13 13:08:32 <ncopa> and started to do ugly mistakes
2026-06-13 13:08:34 <f_> latest 3.5.x is 3.5.7 so it's ok
2026-06-13 13:08:40 <achill> for what its worth, i as a developer with merge access, cant modify milestones because i lack permissions
2026-06-13 13:09:38 <achill> ncopa: yeah we really need to have more people on a releng team
2026-06-13 13:09:50 <achill> the current approuch is not sustainable in the future of the project
2026-06-13 13:09:54 <witcher01> ncopa: sorry if i'm coming off abrasive, that's not my intention. it's just personal curiosity, i'm not judging here
2026-06-13 13:10:19 <ncopa> witcher01: same to you. i try reallly hard to not judge anyone
2026-06-13 13:10:22 <f_> achill: you can tick openssl
2026-06-13 13:10:22 <witcher01> i reserve the right to judging if i'm helping out on the release, which i'm not. i don't know the ins and outs
2026-06-13 13:10:28 <achill> done
2026-06-13 13:10:55 <f_> thx
2026-06-13 13:11:30 <ncopa> i am super proud of the community we have built. and i am extremely thankful for everyone stepping up. it means a lot
2026-06-13 13:11:59 <f_> ncopa: I'm also sorry if I have come off as rude or something
2026-06-13 13:12:24 <ncopa> no worries
2026-06-13 13:12:29 <f_> I do like the work you're doing, I don't want alpine to go
2026-06-13 13:12:34 <ncopa> and likewise
2026-06-13 13:12:50 <f_> it's been nice contributing to it and maintaining things here and there in aports
2026-06-13 13:13:03 <ncopa> brb
2026-06-13 13:16:33 <witcher01> is ncopa the only person with release signing keys?
2026-06-13 13:16:45 <witcher01> i.e. is the bus factor 1, or higher?
2026-06-13 13:17:10 <achill> yeah
2026-06-13 13:17:15 <achill> i mean see https://alpinelinux.org/downloads/ that links to ncopas key
2026-06-13 13:17:21 <f_> ncopa: if there's anything I can do wrt release notes I'd be happy to help
2026-06-13 13:17:31 <witcher01> achill: right, thanks
2026-06-13 13:18:34 <Sertonix[m]> Hasn't some other distro regularly lost their signing keys? You can always rotate them. For that reason it can be ok and maybe even beneficial for security of only 1 person has access
2026-06-13 13:18:36 <achill> i wonder if helping the bus factor, it makes sense to add a gpg key of a new releng member, or to have a common key to sign (like other distros do it, although they have this probably automated)
2026-06-13 13:19:53 <achill> Sertonix[m]: but it does make collaboration harder like now
2026-06-13 13:20:24 <Sertonix[m]> I think best case would be to have many developers with each their own signing key and a release is checked to have at least n trusted developer keys.
2026-06-13 13:20:39 <achill> yeah i would also tend towards that
2026-06-13 13:21:05 <witcher01> i imagine checking the signature of a release is a bit difficult for someone
2026-06-13 13:21:25 <witcher01> "first download these 5 public keys" is a bit meh, but it's manageable
2026-06-13 13:21:45 <panekj> keys are usually on a keyserver
2026-06-13 13:21:59 <achill> keyserver are yesterday, didnt you heard, the new shit is wkd
2026-06-13 13:22:25 <witcher01> panekj: you'd still have to fetch them first, no?
2026-06-13 13:22:35 <panekj> yes but what else do you want to do?
2026-06-13 13:22:40 <achill> koch cooked with that one: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/
2026-06-13 13:22:55 <achill> i think its fine
2026-06-13 13:23:00 <panekj> achill: wkd is keyserver just different /s
2026-06-13 13:23:18 <f_> achill: rofl
2026-06-13 13:23:25 <witcher01> it is fine, i'm not against it. just unusual for distros IME
2026-06-13 13:23:51 <panekj> How is it unusual if all major distros do it?
2026-06-13 13:24:20 <Sertonix[m]> witcher01: The only technically better approach I am aware of would be secure multiparty computation but every dev would need their own data center due to the complexity of the operation
2026-06-13 13:24:36 <witcher01> panekj: if that's the case i didn't know that. i'll shut up now
2026-06-13 13:25:53 <panekj> https://www.debian.org/CD/verify
2026-06-13 13:27:10 <panekj> https://fedoraproject.org/workstation/download/ (you need to click the "verify" button that is next to "download" button to get a popup on instructions)
2026-06-13 13:28:22 <panekj> https://www.gentoo.org/downloads/amd64/ "All release files are signed with an official OpenPGP key (see ) and distributed via world-wide download mirrors. "
2026-06-13 13:29:01 <panekj> I think the only alternative could be in *BSD land with signify
2026-06-13 13:30:04 <panekj> and technically SSH keys could be used that way as well (where git is an example) but I don't think anyone did any work to do that
2026-06-13 13:31:24 <panekj> still you need some way to deliver the public key to verify the signature and you can't deliver it the same way as you deliver the release download
2026-06-13 13:38:00 <witcher01> panekj: i don't understand, automatically generated stage 3 gentoo tarballs seem to be signed with only one key?
2026-06-13 13:50:41 <panekj> If you want details about their signing process, please go ask them
2026-06-13 13:53:32 <witcher01> i find it a bit odd to post the link to prove a point but redirect me elsewhere if i'm confused by it. but fine, i won't ask. message received.
2026-06-13 13:54:50 <panekj> The link proves the point I'm making, they are signing releases
2026-06-13 13:55:13 <panekj> How they sign releases is not something I was arguing about
2026-06-13 13:55:28 <witcher01> i never said releases shouldn't be signed? i don't understand what point you're trying to make
2026-06-13 13:56:08 <panekj> You said it's "unusual", I'm saying it's not because all other distros do it
2026-06-13 13:56:30 <witcher01> i said it's unusual ime for any to be signed with any subset out of a set of multiple release signing keys
2026-06-13 13:56:57 <witcher01> s/for any/for any release/
2026-06-13 13:57:49 <witcher01> but i see where the confusion is coming from, apologies for not being more clear. thanks for helping anyway
2026-06-13 13:59:06 <witcher01> "i imagine checking the signature of a release is a bit difficult" was in reply to the concept of using multiple signing keys
2026-06-13 13:59:45 <panekj> in that case, yes, it's usual to have single key for releasing, multiple keys is something that is happening somewhat recently as a next step to advance security
2026-06-13 14:00:52 <panekj> in either case fetching the keys would be same way (and usually the pgp client does it automatically)
2026-06-13 14:01:39 <witcher01> i am aware of that and that this is the normal way to verify release signature, thanks. we were making different points
2026-06-13 14:07:29 <ncopa> i am sorry but I am on a tight schedule. will go a a BBQ with some friends
2026-06-13 14:07:57 <ncopa> i do have things I would like to express, but I constantly feel I dont have ehough time for it
2026-06-13 14:12:38 <ikke>    I've created new milestones
2026-06-13 14:16:25 <ncopa> the opinions have always been my own. I try really really hard to separate them from the interest of any specific company
2026-06-13 14:17:21 <ncopa> im my position I have to be extremely careful what I express. it is usually best to not say anything
2026-06-13 14:19:30 <ncopa> over the years, since the beginning, I have intentionally tried hard to keep
2026-06-13 14:20:01 <ncopa> oh-oh.. i just promised wife to not be late
2026-06-13 14:20:16 <ncopa> to be continued...
2026-06-13 15:22:20 <ikke> Does this look good? https://tpaste.us/84MV
2026-06-13 15:33:09 <skarnet> it does to me, but what do I know ^^"
2026-06-13 15:33:37 <f_> ikke: I guess it looks okay
2026-06-13 16:11:27 <f_> Do you have a release notes draft already? If not I can certainly write the release notes
2026-06-13 16:12:58 <f_> ikke: ^
2026-06-13 16:20:22 <ikke> f_: I have not, would be appreciated
2026-06-13 16:35:58 <f_> ikke: ack
2026-06-13 16:36:29 <ikke> I just pushed the tag
2026-06-13 16:40:36 <f_> it's cosmetic, but in https://gitlab.alpinelinux.org/alpine/aports/-/commit/0934530484bbcde7498e2c694c710a49616a450e there's not the same amount of '=' on both sides
2026-06-13 16:43:35 <ikke> ugh, too late to fix
2026-06-13 16:57:30 <f_> is this good? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/130/diffs
2026-06-13 16:57:42 <f_> anything I should add?
2026-06-13 16:59:34 <ikke> "The full lists of changes can be found in the git log."
2026-06-13 16:59:45 <ikke> Where `git log` is a link to the cgit tag
2026-06-13 16:59:49 <f_> ack
2026-06-13 17:00:26 <ikke> https://git.alpinelinux.org/aports/log/?h=v3.24.1
2026-06-13 17:00:34 <f_> yeah
2026-06-13 17:01:59 <f_> fixed
2026-06-13 17:04:18 <ikke> I would move it below the CVEs, now it interrupts the security advisory and the list of CVEs
2026-06-13 17:05:24 <f_> good point
2026-06-13 17:08:21 <f_> does it look good now?
2026-06-13 17:15:31 <ikke> One more change, mentioned in the MR
2026-06-13 17:15:51 <ikke> Comparing it to other patch releases
2026-06-13 17:21:10 <f_> yeah makes sense
2026-06-13 17:28:25 <ikke> Thanks, pushed the post
2026-06-13 17:28:37 <f_> yw!
2026-06-13 17:33:36 <f_> ncopa now only needs to sign the releases I guess?
2026-06-13 17:33:45 <ikke> yes, and docker images as well
2026-06-13 17:36:08 <f_> \o/
2026-06-13 18:00:54 <Habbie> woop
2026-06-13 18:47:24 <omni> also ff5060b5a6fa0596366f823d053293bc9a8f835a that is relevant for the Xen image
2026-06-13 18:47:43 <omni> algitbot: don't leave me hangin'
2026-06-13 18:48:34 <omni> !103589
2026-06-13 18:48:44 <omni> not that either, eh?
2026-06-13 18:48:50 <omni> https://git.alpinelinux.org/aports/commit/?id=ff5060b5a6fa0596366f823d053293bc9a8f835a
2026-06-13 18:49:52 <sam_> just because it was mentioned: what we do in gentoo is we have some authority keys (L1, L2, L3). L3 is what signs them and it's a generic release signing key, L2 is what signs that and is used for infra, and then L1 is offline and only 2-3 people have that 
2026-06-13 18:50:05 <sam_> it sounds complex but in our experience it isn't really and it works very well
2026-06-13 18:50:15 <sam_> especially as you can do this to then say, have all developers keys signed by it, or all infra members
2026-06-13 18:51:31 <sam_> dunno if I'd recommend switching to that immediately from a personal key, though
2026-06-13 18:59:53 <f_> omni: you want that to be added to the release notes?
2026-06-13 19:04:33 <omni> f_: yes, sorry for being unclear, there's a lot of other things going on where I'm currently at, but I think that would be a worthy mention
2026-06-13 19:22:54 <f_> fair
2026-06-13 19:24:27 <omni> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/131 fwiw, perhaps not super important
2026-06-13 19:26:10 <f_> you bet me to it
2026-06-13 21:02:20 <Sertonix[m]> sam_: Thanks for sharing. Do there exist any record of considered alternatives with pros and cons?
2026-06-13 21:15:13 <abby> on void, packages are signed with one key that's only on one build machine. release images are signed with a newly-generated minisign key each release by one of the core admins. this key is added to a package each time and the privkey is stored in our secret storage
2026-06-13 21:17:33 <panekj> how do you obtain the key outside of void then?
2026-06-13 21:26:34 <abby> https://github.com/void-linux/void-packages/tree/master/srcpkgs/void-release-keys/files/
2026-06-13 22:06:27 <sam_> Sertonix[m]: https://www.gentoo.org/glep/glep-0079.html
2026-06-13 22:06:43 <sam_> also https://www.gentoo.org/glep/glep-0063.html
2026-06-14 00:45:14 <jvvv> omni: I left a comment about a fix for !103596 mkswap test failure on ppc64le and loongarch64
2026-06-14 01:00:56 <omni> thanks
2026-06-14 01:17:57 <jvvv> welcome
2026-06-14 02:02:57 <lotheac> 19:44    Ariadne  like it is not just ncopa it is all of us and our collective asses and reputations on the line, and we can't even meet the same standards as the kernel?
2026-06-14 02:03:16 <lotheac> well, the kernel has both more people, and many of them get paid for working on it full-time
2026-06-14 02:03:31 <Ariadne> what does that have to do with anything
2026-06-14 02:04:04 <Ariadne> being paid or not paid does not mean a requirement to disclose automated tool usage of any kind is unreasonable 
2026-06-14 02:04:28 <lotheac> i think the context i was quoting was existence of policies/effectivity of governance
2026-06-14 02:04:49 <Ariadne> it is in the context of everything, including provenance
2026-06-14 02:04:51 <lotheac> work is work, things people do on their free time for no compensation often naturally take a backseat
2026-06-14 02:05:52 <lotheac> i only have a few hours a week for alpine a week, for example...
2026-06-14 02:06:17 <lotheac> too many "a week"s in that sentence, sorry
2026-06-14 02:07:38 <Ariadne> yes, and? 
2026-06-14 02:07:55 <lotheac> the point i'm trying to make is that i don't think it makes sense to compare the kernel to a mostly volunteer-based distro
2026-06-14 02:07:57 <Ariadne> nothing about what I said meant drop everything and work full time on alpine
2026-06-14 02:11:39 <Ariadne> and yes, the colonizers should ensure we are sufficiently resourced.  but they are colonizers. 
2026-06-14 07:33:39 <ncopa> thank youveryone for helping get the 3.24.1 out. I have signed the releases and created a PR for the docker image
2026-06-14 07:34:33 <ncopa> I think we need to get stable releases out for 3.23 and 3.22 too, I dont know if we need for 3.21, but it is likely
2026-06-14 07:34:51 <ncopa> and tbh, I feel bad for asking for help with that as well
2026-06-14 08:57:54 <f_> ncopa: you shouldn't feel bad. Ideally the releases shouldn't depend only on you
2026-06-14 08:58:14 <f_> Ideally there would be multiple people that could do releases to increase the bus factor
2026-06-14 09:07:23 <f_> Having only you do the releases everytime isn't sustainable IMO, you for example taking a break shouldn't result in the project getting paused and not doing releases anymore
2026-06-14 09:09:21 <ncopa> i know I shouldnt. I know you are right.
2026-06-14 09:09:54 <ncopa> its not healthy that a projects depend on an individual. not for the project, and not for the person
2026-06-14 09:11:24 <f_> yep, agreed ^^
2026-06-14 10:25:54 <Antiz1> 👋 I have a few new aports MR opened for some time (102477, 99837, 99824). May I ask if someone's able to take a look? 🙏 😄
2026-06-14 10:26:18 <f_> !102477
2026-06-14 10:26:21 <f_> algitbot ?
2026-06-14 10:27:29 <ikke> I need to restart it
2026-06-14 10:27:44 <ikke> Something gets stuck 
2026-06-14 10:29:36 <Antiz1> (Sorry, I had to restart my bouncer)
2026-06-14 11:27:53 <quinq> How can I view the aports git in gitlab?
2026-06-14 11:28:23 <quinq> The only way I found is to go to “Explore projects”, but then searching for aports returns everybody's personnal clone of the repo
2026-06-14 11:28:41 <achill> https://gitlab.alpinelinux.org/alpine/aports ?
2026-06-14 11:28:41 <f_> https://gitlab.alpinelinux.org/alpine/aports.git
2026-06-14 11:28:51 <f_> achill bet me to it heh
2026-06-14 11:29:06 <quinq> ok but how do I actually find it?
2026-06-14 11:29:16 <quinq> Without having to ask IRC or browse 200 clones
2026-06-14 11:44:54 <panekj> go to /alpine namespace
2026-06-14 11:45:33 <panekj> https://gitlab.alpinelinux.org/alpine
2026-06-14 11:46:00 <panekj> or search for alpine/aports
2026-06-14 11:46:06 <panekj> https://gitlab.alpinelinux.org/search?search=alpine%2Faports&nav_source=navbar
2026-06-14 11:47:29 <quinq> ok, solution is to prefix with alpine/
2026-06-14 11:47:33 <quinq> Thanks panekj 
2026-06-14 11:51:14 <quinq> achill, pushed MR #445938, we talked a bit about it 4 months ago
2026-06-14 11:52:34 <panekj> hi algitbot 
2026-06-14 11:52:56 <panekj> still dead?
2026-06-14 11:53:30 <achill> MRs are prefixed with !
2026-06-14 11:53:46 <achill> also 445938 seems to be the wrong ID
2026-06-14 11:55:29 <quinq> Ah sorry, maybe that's a build id
2026-06-14 11:55:34 <panekj> that's CI id
2026-06-14 11:56:04 <panekj> one that doesn't exist in alpine/aports
2026-06-14 11:56:20 <panekj> latest is #445937
2026-06-14 11:56:39 <quinq> It tells me ID #1… To my own clone
2026-06-14 11:57:10 <panekj> oh actually there is #445939 but not #445938
2026-06-14 11:58:03 <panekj> maybe because your profile is private
2026-06-14 11:58:18 <quinq> My profile or the repository?
2026-06-14 11:58:28 <quinq> The repository is “Internal”, don't know about the profile
2026-06-14 11:58:54 <panekj> it seems you opened MR to your own fork
2026-06-14 11:59:14 <quinq> Possible, though I followed https://wiki.alpinelinux.org/wiki/Creating_patches#Creating_a_merge_request
2026-06-14 11:59:23 <panekj> https://gitlab.alpinelinux.org/quinq/aports/-/merge_requests/1
2026-06-14 11:59:46 <quinq> Yep
2026-06-14 12:00:13 <quinq> The guide says: $ git push -u origin $branchname
2026-06-14 12:00:21 <panekj> you need to switch target to alpine/aports when creating MR
2026-06-14 12:00:29 <quinq> What's the “target”?
2026-06-14 12:00:36 <quinq> You mean on the website?
2026-06-14 12:00:38 <panekj> https://gitlab.alpinelinux.org/quinq/aports/-/merge_requests/new
2026-06-14 12:01:18 <quinq> Hummm, so I need to create two MR, one to my own repository, then to the target one?
2026-06-14 12:01:28 <panekj> Only one MR is needed
2026-06-14 12:01:40 <panekj> but GitLab tries to automatically target your own repo over alpine/aports
2026-06-14 12:02:04 <quinq> Ah ok
2026-06-14 12:02:04 <quinq> Gitlab will usually print a URL to create a Merge Request in your terminal.
2026-06-14 12:02:08 <quinq> Open that URL in your browser, follow the instructions to complete the Merge Request creation.
2026-06-14 12:02:22 <panekj> yes and it will sometimes switch target to your own fork
2026-06-14 12:02:23 <quinq> So maybe that's not enough and it should be stated to manually select the actual *alpine* project repo
2026-06-14 12:03:19 <panekj> I don't remember what criteria it uses for choosing, maybe if you push to master it will point to alpine/aports by default
2026-06-14 12:03:47 <panekj> they change stuff constantly so I wouldn't be surprised if it breaks between updates
2026-06-14 12:05:39 <quinq> Thanks again for the help, panekj 
2026-06-14 12:05:41 <quinq> Created !103957
2026-06-14 12:06:43 <quinq> wth
2026-06-14 12:06:56 <quinq> I rebased the commit (as requested by the UI)
2026-06-14 12:07:04 <quinq> Now I have the commits in my own MR
2026-06-14 12:07:39 <panekj> looks fine to me
2026-06-14 12:07:54 <quinq> Ah no, now it doesn't show them anymore after a refresh of the page
2026-06-14 15:45:14 <nmeum> would appreciate if more people test the busybox 1.38.0 upgrade from !102663. if you notice any problems, please report them in the PR. otherwise I will merge this in a week or so.
2026-06-14 15:45:19 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102663
2026-06-14 15:49:10 <ikke> I can try it on my build instance
2026-06-14 16:10:37 <staceee> oh cool! busybox now have a lsblk applet
2026-06-14 16:17:59 <staceee> i'll install this on my sxmo devices, we use busybox a lot
2026-06-14 16:32:31 <nmeum> cool, thanks!
2026-06-14 16:53:49 <staceee> nmeum: well I'm not noticy any immediate issue
2026-06-14 16:54:01 <nmeum> \o/
2026-06-14 16:54:14 <staceee> tested on two x86_64. My build system fails to build it for aarch64, so I can't test this on pinephone unfortunately
2026-06-14 16:54:38 <staceee> some /stdin problem related to builds.sr.ht
2026-06-14 17:03:10 <WhyNotHugo> Why is this flagged and how do I unflag it? https://pkgs.alpinelinux.org/package/edge/community/x86_64/imapgoose
2026-06-14 17:26:06 <jvvv> Weird. Looked at https://release-monitoring.org/project/390364/ and according to that, I don't think it should have been auto flagged.
2026-06-14 17:27:32 <jvvv> The "How to Flag" page has "Manual package flagging has been disabled in favour of automatic flagging based on Anitya", so it does not seem like that could have been the cause either.
2026-06-14 17:35:00 <WhyNotHugo> I think a (now fixed) bug in aniyta preivously resulted in a lower version being detected as the latest.
2026-06-14 17:39:47 <jvvv> I didn't see anything in the apkbrowser anitya code that jumped out at me.
2026-06-14 19:05:33 <jvvv> omni: I see that you closed !103596. I hope I didn't overstep? I was just trying to help, mainly because there is at least one fix in the 2.42.1 release that addresses an issue with akms builds.
2026-06-14 20:53:54 <staceee> the release-monitoring fails to detect sr.ht rss feeds bow
2026-06-14 20:54:04 <staceee> I have also noticed this for my own softs
2026-06-14 20:54:58 <staceee> https://release-monitoring.org/project/390575/
2026-06-14 21:48:41 <jvoisin> in the light of https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/99914 can I have https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103823 merged ?
2026-06-14 22:39:07 <omni> jvvv: absolutely not, but I see that I had missed pressing the "Add comment now" button for my comment on why I closed it
2026-06-14 22:51:00 <omni> jvvv: you didn't overstep, thank you for your contributions, do you think it should be backported to 3.24-stable?
2026-06-14 22:58:06 <jvvv> omni: yes, I think backporting is good idea. Do you think it should wait until it has a chance to run for some amount to time on edge to ensure there are no regressions?
2026-06-14 23:00:37 <jvvv> omni: And thanks for confirming it didn't do something to annoy you. I took your closure of the MR as a hint that I should step mine forward.
2026-06-14 23:01:13 <jvvv> But then I worried that I had assumed too much.
2026-06-14 23:08:40 <omni> I agree that it would be good to let it be in edge a bit before going into 3.24
2026-06-14 23:09:54 <jvvv> I can submit a draft for the backport tonight.
2026-06-14 23:10:01 <omni> jvvv: there seems to be issues on the package builders with tests (if you want to worry about something else ;)
2026-06-14 23:10:14 <omni> lsfd/option-inet-udplite in particular
2026-06-14 23:10:30 <omni> I added a comment on your MR
2026-06-14 23:11:17 <jvvv> Sure, the backport can wait. I will address the comment and look info the build issue right after.
2026-06-14 23:11:39 <omni> I wonder why that wasn't caught in CI..
2026-06-14 23:13:59 <jvvv> I think that the builder env differs enough from the CI env that this can happen. ikke would know whether that is actually the case. I am starting to look at the logs now,
2026-06-14 23:17:45 <omni> I retried and two of the previously failing tests passed on aarch64 and x86_64, so lsfd/option-inet-udplite may be the only one we need to address
2026-06-14 23:18:46 <jvvv> Yeah, I've had the impression that some of the util-linux tests are flaky.
2026-06-14 23:26:25 <omni> I wonder if this can be a hint https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?h=stable/v2.42&id=33981ff8bd970b79f350d58ffd7878f0a638a929
2026-06-14 23:28:02 <jvvv> Sure looks like it on first blush
2026-06-14 23:54:56 <jvvv> omni: That patch is already part of 2.42.1 release.
2026-06-14 23:58:56 <omni> jvvv: I know, more of a hint that it might be fine to skip...
2026-06-15 00:08:30 <jvvv> omni: I just force pushed skip just now
2026-06-15 00:11:37 <jvvv> fixing...
2026-06-15 00:15:54 <jvvv> sorry, I know better than to try work fast
2026-06-15 00:21:00 <omni> jvvv: yeah, but don't worry, it's fine
2026-06-15 00:21:40 <omni> I wonder if this was the part of tests/ts/lsfd/option-inet that was failing previously and wether we still have to remove that
2026-06-15 00:23:58 <omni> jvvv: I hope this isn't blocking you from doing something else, if it is I'll take care of this
2026-06-15 00:26:41 <jvvv> omni: no, it is fine... I have something I'm working, but is not any kind of timeline. I see the util-linux issue as more important.
2026-06-15 00:27:03 <jvvv> s/not any/not on any/
2026-06-15 01:28:05 <omni> jvvv: I cherry-picked your upgrade commit, included the removal of tests/ts/lsfd/option-inet and opened a backport MR
2026-06-15 01:35:10 <jvvv> omni: Thanks for the heads up. Sorry I wasn't more help. I really would like to understand why the test results are different under CI and builders. But for now I think disabling the test is ok since it passing at least in CI... just my two cents.
2026-06-15 01:38:08 <omni> jvvv: it may be hard to research without access to the package builders or similar setup
2026-06-15 01:45:01 <jvvv> I think that is true. I've tried at various times to try get up to speed with the setup our infra uses, but unfortunately I keep falling short of a level of knowledge of the core tools to feel like I am in a good place to be helpful with that.
2026-06-15 14:04:51 <ncopa> I'm gonna do another community office hours today 18:00 UTC (20:00 CEST) where I will be available to respond to questions on any topic
2026-06-15 14:05:54 <ncopa> 18:00 - 19:00 UTC. If there are no questions it will be shorter
2026-06-15 14:09:37 <ncopa> alpine linux related questions
2026-06-15 14:16:09 <ncopa> https://meet.jit.si/NatanaelsCorner
2026-06-15 17:35:39 <telmich> I'd like to suggest including CONFIG_WWAN and CONFIG_MTK_T7XX in the kernel option, as I have the 56:00.0 Cellular controller/modem: MEDIATEK Corp. T700 5G Modem [5G Solution 5000] (rev 01) - what was the most appropriate/easiest way for that at the moment?
2026-06-15 17:35:58 <telmich> (it's a HP Elitebook X G2i, quite a nice machine, in theory sun light readable)
2026-06-15 17:38:00 <ikke> telmich: best to create an issue in the aports project
2026-06-15 17:42:20 <telmich> ikke: Where are you? I'm also in the jitsi (with a computer with a camera and microphone...)
2026-06-15 17:47:37 <f_> telmich: you mean to ping ncopa right?
2026-06-15 18:09:40 <f_> office hour is happening right now
2026-06-15 18:09:43 <f_> fwiw
2026-06-15 18:10:32 <elagost> is it ok to join and just listen in?
2026-06-15 18:12:07 <f_> I think so
2026-06-15 18:13:17 <ikke> sure
2026-06-15 18:14:20 <telmich> ncopa: Great idea!
2026-06-15 18:14:31 <telmich> Was fun seeing some of you again today!
2026-06-15 18:54:10 <f_> thanks ncopa for the office hour ^^
2026-06-15 19:25:47 <ncopa> np. was nice talking with you
2026-06-15 19:26:04 <f_> likewise :)
2026-06-15 19:56:59 <vmignot> I really don't want to relaunch the debate of those last days, but is there a place where I can follow this whole LLM policy debate and potential conclusion (except the original MR) ?
2026-06-15 19:58:18 <vmignot> Or if we are waiting for a specific event
2026-06-15 20:01:16 <achill> currently we're try to work on it between developers, but the correct place to follow about it is: https://gitlab.alpinelinux.org/alpine/council/-/work_items/697
2026-06-15 20:23:36 <vmignot> achill: thanks !
2026-06-15 21:41:17 <durrendal> achill: any chance members of the infra team are invited to that discourse? 
2026-06-16 00:47:50 <Sertonix[m]> dalias: Do you have by any chance an idea what the cause of https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17962 could be?
2026-06-16 02:07:29 <dalias> sertonix[m], -Wl,-E makes no sense with static linking
2026-06-16 02:11:10 <dalias> ok ld is just emitting an invalid symbolic relocation
2026-06-16 02:11:13 <dalias> no idea why
2026-06-16 02:13:01 <dalias> but you can work around it by removing the bogus -Wl,-E
2026-06-16 05:35:44 <Sertonix[m]> Thanks!
2026-06-16 12:16:24 <WhyNotHugo> achill: does apkbrowser need a manual deploy for new versions?
2026-06-16 12:18:23 <achill> afaik no
2026-06-16 12:19:12 <WhyNotHugo> What deploys it?
2026-06-16 12:19:25 <staceee> could apkbrowserl link to anyta?
2026-06-16 12:20:07 <staceee> or does it already?
2026-06-16 12:34:35 <WhyNotHugo> staceee: it doesn't show links
2026-06-16 12:35:20 <WhyNotHugo> IIRC, it doesn't store the anitya project URL
2026-06-16 12:36:09 <WhyNotHugo> But instead of a bool anitya_checked, we could store str anitya_url.
2026-06-16 12:38:37 <WhyNotHugo> staceee: why specifically do you want a link?
2026-06-16 12:41:13 <staceee> mhh mostly to see all recent versions, I confess that doesn't feels that usefull
2026-06-16 12:42:27 <staceee> I think a more usefull button would be to link to the "add project" page, pre-filling most of the input boxes
2026-06-16 12:42:59 <staceee> or to link to an existing project
2026-06-16 12:43:57 <staceee> I'm imagining what I would need to help me tracking all the packages I maintain
2026-06-16 12:45:01 <staceee> perhaps that is an unrelated topic, and should be done with another bot or tooling
2026-06-16 13:05:16 <jvvv> I'm working on pyside6 upgrade from 6.11.0 to 6.11.1. According to my build logs, I do not see a soname change. In this case, I should not need to bump revdeps, is that correct?
2026-06-16 14:03:34 <WhyNotHugo> staceee: latest version is shown over a tooltip on top of the package version
2026-06-16 14:03:47 <WhyNotHugo> (I admit it's not the best UX, I found this feature reading the source code)
2026-06-16 14:04:03 <staceee> is this released yet?
2026-06-16 14:04:17 <staceee> s/released/upstream/
2026-06-16 14:04:33 <WhyNotHugo> I pushed a tweak today to also allow filtering packages by "unchecked with anitya"
2026-06-16 14:04:42 <WhyNotHugo> No, that's why I asked about the deployment process
2026-06-16 14:05:15 <WhyNotHugo> The tooltip thing is live.
2026-06-16 14:11:46 <ikke> It's deployed as a docker compose project, so someone would manually need to pull restart it
2026-06-16 14:31:40 <PureTryOut> WhyNotHugo: oh that's awesome! Thanks for that!
2026-06-16 14:33:26 <WhyNotHugo> ikke: can that someone be you? 🫶 I don't think I have that kind of access
2026-06-16 15:16:01 <runxiyu_> Hi! I'll be a bit slow on package maint and a few other things because I'm sending my main laptop (which kernel panics every time I shake it) to repair, and I'll be on a MacBook Air (M1, 2020) for a while instead
2026-06-16 15:16:25 <runxiyu_> Unless I can get asahi-alpine with the new fairydust kernel to work on there, I'll probably be unable to maintain Alpine packages for a little bit
2026-06-16 16:08:41 <ikke> WhyNotHugo: done
2026-06-16 16:10:04 <Sertonix[m]> runxiyu_: On arch linux people are able to sucessfully use abuild rootbld to maintain alpine packages, if that is of interest for you
2026-06-16 16:10:20 <runxiyu_> oh, interesting
2026-06-16 16:10:32 <runxiyu_> i'm still trying to get mps's alpine-asahi thing to work for me tho :D
2026-06-16 16:11:25 <f_> WhyNotHugo: seems to not work at least for inspircd
2026-06-16 16:11:45 <f_> despite being monitored by anitya https://release-monitoring.org/project/370606/ either that or I don't know how to use it
2026-06-16 16:11:57 <ikke> I might still need to run a migration
2026-06-16 16:13:19 <ikke> ah, it will automatically do that when it updates the db
2026-06-16 16:15:12 <ikke> hmm: 'sqlite3.OperationalError: no such column: anitya_checked'
2026-06-16 16:18:42 <ikke> I guess there's nothing that adds the anitya_checked column
2026-06-16 16:22:13 <WhyNotHugo> ikke: I did bootstrap the whole thing locally and the column exists, the query did work.
2026-06-16 16:22:35 <ikke> WhyNotHugo: yes, but it does not update the tables if it already exists from what I can tell
2026-06-16 16:22:53 <ikke> There's no ALTER TABLE statement
2026-06-16 16:23:06 <WhyNotHugo> Odd. The code updating the column is not new tho, that didn't fail?
2026-06-16 16:23:45 <ikke> Previous commit that was deployed was 066737d
2026-06-16 16:24:26 <ikke> So it has never worked I guess
2026-06-16 16:24:59 <WhyNotHugo> I'll update update/update-database.py
2026-06-16 16:25:27 <ikke> Thanks
2026-06-16 16:25:33 <ikke> I''m afk, but will check later
2026-06-16 16:42:39 <WhyNotHugo> bbl, have a fix, need to double test it and will send an MR
2026-06-16 17:43:58 <runxiyu_> update: thanks to mps's asahi-aline, i'll probably be fine™
2026-06-16 17:44:03 <runxiyu_> alpine*
2026-06-16 17:58:46 <f_> hiya, I'd appreciate it if someone would like to take a look at !103336, that would be one less package depending on EoL botan2
2026-06-16 17:59:56 <f_> well actually biboumi is the only remaining package that depends on botan2. So with this in botan2 could be dropped entirely
2026-06-16 18:00:07 <f_> I will remove it
2026-06-16 19:00:24 <infinitywisdom[m]> When setting up for a software development environment. What are the most essential software, tools, and configurations that you require to develop software gracefully?
2026-06-16 19:00:53 <f_> I just install alpine-sdk and go on with my life :)
2026-06-16 19:01:05 <f_> some cross-compilers too like gcc-aarch64 and gcc-armv7
2026-06-16 19:01:26 <f_> and vim, very important
2026-06-16 20:59:27 <ncopa> runxiyu_: I got alpine working on a macbook M1 pro with asahi kernel
2026-06-16 21:02:01 <f_> runxiyu_: oh, yeah postmarketos also has a working M1 port
2026-06-16 21:28:56 <markand> nice! 
2026-06-16 21:29:15 <markand> I'm running arch on my mac studio but I'm thinking of ditching out for my favorite distro as well
2026-06-16 21:29:37 <markand> and that will help me maintain my alpine packags
2026-06-16 21:43:17 <WhyNotHugo> https://gitlab.alpinelinux.org/alpine/infra/apkbrowser/-/merge_requests/26
2026-06-17 02:12:21 <jahway603[m]> Can I please get !104090 and !104091 merged?
2026-06-17 05:33:31 <Saijin_Naib[m]> Is flatpak being broken with busybox umount an expected issue (ie, just install util-linux duh) or is this Issue worthy?
2026-06-17 05:33:59 <Saijin_Naib[m]> I just re-setup from scratch to use Limine and get an 8GB swap so I can hibernate, and this bit me for the first time
2026-06-17 05:34:40 <Saijin_Naib[m]> It seems flatpak calls umount with no-canonicalize during the installation of a flatpak and busybox umount does not implement this
2026-06-17 05:34:55 <Saijin_Naib[m]> Causes installations and updates to fail until umount/util-linux are installed
2026-06-17 07:26:33 <ncopa> so flatpack has hard dependency of util-linux?
2026-06-17 07:29:55 <Sertonix[m]> I see no mention of the option in the flatpak code. Can we first track down it's usage before making conxlusions?
2026-06-17 07:45:26 <ncopa> yes. ofc!
2026-06-17 07:56:10 <Saijin_Naib[m]> How can I help debug this?
2026-06-17 07:56:31 <Saijin_Naib[m]> Does there need to be a special flatpak-dbg package and I run it via gdb to capture the messages?
2026-06-17 07:58:25 <Sertonix[m]> The error message might be helpful.
2026-06-17 08:00:35 <Saijin_Naib[m]> https://bpa.st/2DMQ
2026-06-17 08:00:43 <Saijin_Naib[m]> for an example, the app being installed does not matter
2026-06-17 08:21:24 <craftyguy[m]> can you run flatpak with -vv ?
2026-06-17 08:26:25 <Saijin_Naib[m]> yeah, sure
2026-06-17 08:27:13 <Saijin_Naib[m]> https://bpa.st/OEZA
2026-06-17 08:28:59 <omni> can all changes, please, go through merge requests?
2026-06-17 08:37:49 <Sertonix[m]> <Saijin_Naib[m]> "https://bpa.st/2DMQ" <- Seems to be bug in fuse3. Will try to guess what is wrong
2026-06-17 08:39:23 <Sertonix[m]> What does stat /run/mount/utap return?
2026-06-17 08:40:31 <Saijin_Naib[m]> Ah, awesome, thanks for tracking it that far
2026-06-17 08:41:08 <Saijin_Naib[m]> https://bpa.st/BEQA
2026-06-17 08:41:52 <Sertonix[m]> The detection of using the util-linux specific option relies on that file not existing: http://github.com/libfuse/libfuse/pull/1247
2026-06-17 08:42:10 <Sertonix[m]> Maybe "umount" has been uninstalled since the last reboot
2026-06-17 08:42:28 <Sertonix[m]> *not using
2026-06-17 08:44:41 <Saijin_Naib[m]> So what would my next steps to test/verify be?
2026-06-17 08:46:26 <Sertonix[m]> When umount is the busybox version you can do "doas rm /run/mount/utap" (or reboot) and it should start working.
2026-06-17 08:48:55 <Saijin_Naib[m]> Oh, wow, yep that was it
2026-06-17 09:34:55 <jvoisin> may I have https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103823 reviewed and merged? <3
2026-06-17 09:42:37 <ikke> !103823
2026-06-17 09:49:05 <PureTryOut> jvoisin: done a quick review
2026-06-17 10:23:11 <ncopa> anyone willing to take over maintenance of python3 package? and would be willing to be listed as platform maintainer at https://devguide.python.org/core-team/experts/#platforms
2026-06-17 10:30:36 <achill> I mean I would, I'd also try to get the multi versions python in
2026-06-17 10:33:14 <Sertonix[m]> ncopa: I would like to merge and backport https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/505 . Any objections?
2026-06-17 10:34:07 <ncopa> there is an cpython upstream discussion about a stack overflow issue that we fixed in 2026e1259422. I think they look for someone that can help them review an upstream fix and be upstream maintainer for alpine/musl platform
2026-06-17 10:34:23 <ncopa> 2026e1259422d4e0cf92391ca2d3844356c649d0
2026-06-17 10:41:18 <ncopa> Sertonix[m]: no objection from me. I trust your judgement on this.
2026-06-17 10:46:22 <ncopa> achill: whoever takes over python can decide what to do with multi version. My personal opinion is that adding multiversion will over time result in a maintenance nightmare
2026-06-17 10:48:06 <jvoisin> <3^
2026-06-17 10:48:23 <jvoisin> bumping a single python version is already tedious as it is
2026-06-17 11:00:08 <ncopa> indeed
2026-06-17 11:01:22 <ncopa> I dont think it has been properly announced but Sertonix[m] is officially an Alpline Linux developer \o/
2026-06-17 11:02:54 <ncopa> achill: I think there is another python issue that I think has higher prio than multiversion. it is a split of zstd or something.
2026-06-17 11:03:30 <Sertonix[m]> IIRC there was an open MR with a good approach for that?
2026-06-17 11:04:30 <WhyNotHugo> Congrats Sertonix… Although I thought they were a Developer already many months ago
2026-06-17 11:04:58 <ncopa> ah it got merged already 614add499ad7d79351b0bdc0c3900d25a85907a2
2026-06-17 11:05:24 <WhyNotHugo> ncopa: I'd like to see other python versions, but strictly limited to the tools necessary to bootstrap a new virtualenv. I.e.: prohibit any other package from depending on these.
2026-06-17 11:05:52 <ncopa> um.. where did the python zstd split go?
2026-06-17 11:06:17 <WhyNotHugo> !99883
2026-06-17 11:07:08 <Sertonix[m]> So singular packages which intentionally differ from the main version by eg. not splitting something like python3-extra and don't try to have dependency tracing in abuild? I would be a bit less against that
2026-06-17 11:07:47 <ncopa> yeah !99883 was what I had in mind. its merged so all good
2026-06-17 11:10:30 <ncopa> let me know as soon someone has an MR with maintainer change so I can forward new maintainer to upstream cpython so they know who can help them deal with security issues
2026-06-17 11:17:57 <WhyNotHugo> achill: ikke: This is the fix for the column thing yesterday: https://gitlab.alpinelinux.org/alpine/infra/apkbrowser/-/merge_requests/26
2026-06-17 11:18:11 <WhyNotHugo> I think packages which were recently added to anitya also don't update because of this
2026-06-17 11:19:21 <ikke> correct
2026-06-17 11:21:18 <ncopa> Sertonix[m]: would you like to take over maintainership of abuild?
2026-06-17 11:28:21 <Sertonix[m]> ncopa: Yes, I can try doing it.
2026-06-17 11:28:35 <ncopa> <3
2026-06-17 11:30:18 <ncopa> feel free to ask me anything. I have had some ideas for a while that never materialized
2026-06-17 11:30:52 <ncopa> like splitting out (and renaming?) sanitycheck
2026-06-17 11:31:12 <ncopa> do a sh -n $APKBUILD check before sourcing it
2026-06-17 11:32:03 <ncopa> move src/ pkg/ tmp/ etc to a  $workdir
2026-06-17 11:32:20 <ncopa> move config to XDG_HOME
2026-06-17 11:32:55 <ncopa> make it possible to configure where sources are extracted and built (so you can build from tmpfs if you want)
2026-06-17 11:33:37 <ncopa> fix git commit hash that is stored in .apk to be current commit, instead of finding last commit for the given APKBUILD
2026-06-17 11:33:57 <ncopa> split out the man-page compression and symlink handling to an external C helper
2026-06-17 11:34:20 <ncopa> probably more
2026-06-17 11:42:03 <WhyNotHugo> ncopa: would be happy to see config moved to XDG_CONFIG_HOME. I think I even have a 90% done patch sitting around
2026-06-17 11:45:06 <jvoisin> Sertonix[m]: congratz :)
2026-06-17 11:57:25 <runxiyu_> ncopa: works on my Air properly now, with external display too
2026-06-17 11:57:27 <runxiyu_> f_: nice
2026-06-17 11:57:32 <runxiyu_> f_: though i'll probably just use alpine
2026-06-17 12:05:59 <ncopa> runxiyu_: nice!
2026-06-17 12:06:41 <runxiyu_> though im taking the oportunity to clear up my dotfiles and such so im going slow before i could get real work done XD
2026-06-17 12:07:56 <ncopa> re abuild, I have also been thinking of splitting rootbld out and maybe refactor it to use crun or something OCI
2026-06-17 12:08:43 <jvoisin> seems like Gitlab isn't happy
2026-06-17 12:09:01 <jvoisin> I'm getting a lot of "Something went wrong on our end. Please try again." messages
2026-06-17 12:09:43 <ncopa> no idea of what tooling we could wire in if we used OCI standard for rootbld, but I have a feeling it could open doors for us
2026-06-17 12:10:11 <ncopa> jvoisin: try #alpine-infra
2026-06-17 12:11:37 <jvoisin> thanks
2026-06-17 12:27:43 <ncopa> anyone willing to take responsiblity to get stable releases out for 3.23, 3.22 and 3.21?
2026-06-17 12:34:33 <f_> ncopa: is there a checklist for these somewhere?
2026-06-17 12:35:02 <f_> I might probably be able to help out on some checklist things and the release notes
2026-06-17 12:39:22 <ikke> f_: the 3.24.1 checklist for example
2026-06-17 12:40:16 <ikke> ncopa: we need to fix the stable builders for rv64 first
2026-06-17 12:52:05 <ncopa> ok
2026-06-17 13:42:11 <Sertonix[m]> ncopa: I am still working on something to replace rootbld
2026-06-17 13:44:51 <ncopa> what do you think about using crun?
2026-06-17 13:50:47 <Sertonix[m]> I am thinking about not using anything (specific) and instead require users to specify how environments are setup. That has some difficulties but I want at least XEN, qemu, user namespaces and a nested mix of these to work.
2026-06-17 14:00:51 <ncopa> sounds complicated. maybe incus could help there
2026-06-17 14:01:32 <ncopa> looks like the openssl security fixes did not go into openssl 3.3, which we use for 3.21-stable
2026-06-17 14:15:11 <WhyNotHugo> if we replace rootbld, it would neat for it to work entirely unprivileged.
2026-06-17 14:16:26 <WhyNotHugo> I guess that aligns with it working nested
2026-06-17 15:26:19 <eletrotupi> hello! 
2026-06-17 15:26:49 <eletrotupi> question, should we add GHSA/GO vuln checks to secfixes?
2026-06-17 15:26:55 <eletrotupi> or just pure CVEs
2026-06-17 15:27:33 <ikke> For the secdb, only CVEs are recorded. There are projects that add other kind of advisories as well though
2026-06-17 15:27:36 <eletrotupi> oh, GHSA does have a CVE linked to it, but I can't access?
2026-06-17 15:27:43 <eletrotupi> hm
2026-06-17 15:40:07 <eletrotupi> should i also add the dependencies CVE's or that's too much?
2026-06-17 15:40:43 <eletrotupi> because technically, this prometheus release only have a single GHSA call/CVE, but the direct dependencies have multiple
2026-06-17 15:53:15 <Sertonix[m]> WhyNotHugo: We can easily do unprivileged rootbld, just needs to fix the MR a bit.
2026-06-17 16:56:44 <PureTryOut> Sertonix: did you just merge rootless rootbld? 😱 That's amazing, thanks!
2026-06-17 16:58:30 <Sertonix[m]> I am considering to do an abuild release for edge soon with it. Not yet sure how to version that.
2026-06-17 18:19:52 <WhyNotHugo> Sertonix[m]: rc?
2026-06-17 18:20:08 <WhyNotHugo> or just alpha
2026-06-17 21:24:40 <WhyNotHugo> I recall there was interest in having the initfs be event-based. I like the idea, but I can't quite imagine how to implement this. How would we drive the event loop? How would other processes "emit" events?
2026-06-17 21:50:50 <Sertonix[m]> nlplug-findfs is already event driven (and multi threaded!). That concept but no shell script wrapping it, more kinds of events and embedded lua runtime for user configuration/glue. "other processes" would be something to avoid as much as possible. Depending on the interface of some libraries there might be multiple threads with an event loop.
2026-06-17 21:53:43 <Sertonix[m]> But IMHO first step would be to create a huge list of known/plausible use cases to more easily check if an idea is worth considering.
2026-06-17 21:59:29 <WhyNotHugo> That makes total sense, I was thinking of a multi-process event kinda thing.
2026-06-17 21:59:45 <WhyNotHugo> So if someone wants some weird custom command, they exec that via the lua runtime, but the API in there is well defined?
2026-06-17 22:47:55 <Sertonix[m]> Something like that.
2026-06-18 00:29:46 <amrfti> That would be very handy. I've been wanting to make good clevis integration with mkinitfs but there isn't any way to "hook" into it like there is for dracut.
2026-06-18 00:29:54 <amrfti> So it's hard to package
2026-06-18 00:36:09 <Sertonix[m]> I would rather not focus on clevis. It breaks many of the advantages that only using lua is supposed to bring.
2026-06-18 01:56:45 <amrfti> Such as? I'm not opposed to the idea of Lua as an initfs API, but also using it to call binaries doesn't seem problematic to me.
2026-06-18 02:04:41 <Sertonix[m]> Extra dependencies, extra files/environment to imitate a regular system, race conditions, limited parallelization, runaway processes
2026-06-18 02:09:21 <amrfti> Well if you want to use clevis, you're going to need clevis... And those other issues you listed are the onus of the supposed hook writers.
2026-06-18 02:18:47 <Sertonix[m]> But people typically want to use clevis cause they know that it can do what they want, not because it is the only thing that can possibly do what they want.
2026-06-18 02:20:36 <jahway603[m]> Can I please get backport !104159 merged?
2026-06-18 03:55:45 <amrfti> Sertonix: Fair enuff. I just want good tpm disk unsealing, I have a lot of servers I would love to use it on.
2026-06-18 04:44:57 <jvvv> WhyNotHugo: did the last change you made to apkbrowser make it online?
2026-06-18 04:45:43 <ikke> aksjdaksdja\\
2026-06-18 04:45:55 <ikke> oops, wrong button
2026-06-18 04:46:30 <ikke> jvvv: Not the latest latest changes yet
2026-06-18 04:48:32 <jvvv> Ok, just wondering since all hightlighting of the Version column is gone. But I notice WhyNotHugo and yourself talking about it, so I am hopeful that the last commit will improve the matter.
2026-06-18 05:03:06 <ikke> Ok, I see the fix MR has been merged, I'll deploy it
2026-06-18 05:09:27 <ikke> WhyNotHugo: achill seeing this in the log: 'Failed to lookup commit 41bb837115def58044be4c0c713722592214f614 in gitlab API'
2026-06-18 05:14:36 <ikke> (for every commit, mind you)
2026-06-18 07:33:15 <qaqland> our audio service needs some adjustments #18232
2026-06-18 08:38:32 <ncopa> achill: could you please open an MR where you take over maintainership for python3? I need to respond to upstream
2026-06-18 08:40:00 <ncopa> achill: can you also confirm that you are ok to be listed upstream as platform maintainer? https://devguide.python.org/core-team/experts/#id2
2026-06-18 09:15:29 <achill> ncopa: sure sounds good
2026-06-18 09:21:12 <achill> !104180
2026-06-18 09:54:44 <strophy> Could anyone help me with a MR review please: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97599
2026-06-18 10:19:53 <ikke> !97559
2026-06-18 10:22:37 <WhyNotHugo> ikke: Where does this 41bb837115def58044be4c0c713722592214f614 value come from?
2026-06-18 10:23:29 <WhyNotHugo> Oh, it's a aports commit. That seems unrelated to the changes, no?
2026-06-18 10:24:14 <ikke> Yeah, not related to the change
2026-06-18 10:24:32 <ikke> Everything is still continuing, just logged
2026-06-18 14:12:42 <omni> ncopa: you're about to tag patch releases, right? is that only 3.21 through 3.23? (not 3.24)
2026-06-18 14:13:25 <omni> are you also just waiting for build-3-22-riscv64 to complete?
2026-06-18 14:20:34 <ikke> omni: 3.24.1 is already released
2026-06-18 14:20:47 <ikke> Already including the openssl fixes 
2026-06-18 14:32:56 <ncopa> i need someone to help me with doing the patch releases. I need to focus on personal stuff rest of this week. I'm just trying to push the build-3-22-riscv64 builders to a state where we can do a release
2026-06-18 15:24:06 <PureTryOut> ncopa: looking at libcec there is also a libcec-rpi in testing, you're the maintainer for both. Both are built from same tarball but one can currently not be swapped for the other. Is it ok if I integrate these recipes together and just make the `-rpi` a subpackage of the main `libcec` package, and provide a virtual that both the normal and the -rpi version can fullfill?
2026-06-18 15:31:53 <durrendal> any chance I could get !101283 merged? 
2026-06-18 15:45:54 <lotheac> durrendal: you have to rebase it first
2026-06-18 15:46:37 <lotheac> gitlab says there are conflicts
2026-06-18 15:53:44 <durrendal> lotheac: thanks for catching that, didn't notice it
2026-06-18 15:59:34 <lotheac> ah.. you also modify strongswan. my experience recently is that changing strongswan build-time configs might break it entirely for the use-cases it's currently used for
2026-06-18 16:00:18 <lotheac> so... sorry, but i will leave it to the maintainer :P
2026-06-18 16:02:50 <lotheac> (eg. its configure --enable-kernel-lipipsec configure option, which enables the userspace impl of lipisec, causes the userspace impl to be enabled by default and basically not able to be turned off)
2026-06-18 16:13:39 <Sertonix[m]> Well, it already broke for use cases it was used for by not having stroke enabled: https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18271
2026-06-18 16:19:11 <lotheac> by "currently used for", i meant "the alpine users who use the package as it is"
2026-06-18 16:20:39 <lotheac> normally i would be "ok, just adding a feature, sure, ok" for a configure option, but strongswan... surprises you
2026-06-18 17:16:31 <durrendal> Sertonix[m]: this is precisely what broke networkmanager-l2tp and why I added stroke back to strongswan. I've been running a build of both the modified strongswan and networkmanager-l2tp for months now without issues
2026-06-18 17:17:02 <durrendal> but, agreed with lotheac that the maintainer should have a say on matters, they're more contextually aware and my use case is narrow.
2026-06-18 17:19:55 <Sertonix[m]> Since the maintainer is ncopa you can probably adapt the package if you want to.
2026-06-18 17:59:36 <fromagium> Hello. I have been notified of a MR of mine (!102368) that has been stale for about a month and the bot' message brought me here. The maintainer seems to be inactive lately. I still need the package to be updated on my side. May I ask how I should proceed?
2026-06-18 18:01:59 <PureTryOut> Just a note, the community repo in 3.23 is not really supported anymore. You should upgrade to 3.24 if you can
2026-06-18 18:02:22 <PureTryOut> And the PR title says 3.23 but you have it targetted to master which is edge
2026-06-18 18:03:24 <fromagium> Right, good point, I'll rework that.
2026-06-18 18:06:06 <PureTryOut> I mean edge still needs the upgrade lol, so I just merged it there
2026-06-18 18:15:06 <ncopa> PureTryOut: mergeing libcec and libcec-rpi sounds like a good idea. do you mind take over maintainership of those two?
2026-06-18 18:19:10 <fromagium> PureTryOut: ok, got you, so I will d re-open a MR targeting 3.24
2026-06-18 18:20:38 <ncopa> all the build-3-2*-builders are idle, anyone available to help with stable releases? I think we only need for 3.23 and 3.22 unless someone backports the openssl CVE fixes to openssl 3.3. might be debian or other distro have patches
2026-06-18 18:49:58 <fromagium> PureTryOut: created !104204 for 3.24. Turns out there is a new version (0.9.5) of the package available, so edge would need to be updated again. Are the stable changes ported to edge in some ways, or should I ask for a merge of the same change on edge?
2026-06-18 19:22:13 <PureTryOut> ncopa: yeah can do
2026-06-18 19:22:39 <PureTryOut> fromagium: normally the maintainer is responsible for backporting to stable releases, but you can also do it if you want
2026-06-18 19:27:38 <fromagium> alright, noted, many thanks for the help
2026-06-18 22:54:17 <omni> ikke: I know, just wanted to make sure and so that I could get things into 3.24 without being in the way 
2026-06-19 03:01:08 <Sertonix[m]> I don't know who needs to hear this but arch= in a split function (or the package() function) is wrong. Please refuse to merge changes that do that.
2026-06-19 04:57:27 <ikke> Could add a linter for that
2026-06-19 05:47:35 <ikke> #18274
2026-06-19 10:13:07 <strophy> Could anyone please help me review and merge !92565
2026-06-19 11:47:44 <kpcyrd> if somebody has time, I would like to get this off my pinned tabs :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/102192
2026-06-19 12:01:59 <jahway603[m]> !102192
2026-06-19 14:20:06 <f_> ok I am around for getting some of the release checklist done
2026-06-19 14:28:12 <f_> ikke: are you able to create a milestone for 3.23?
2026-06-19 14:38:41 <ikke> Yes, will do that in a bit
2026-06-19 14:38:45 <ikke> Will also create one for 3.22
2026-06-19 14:42:08 <f_> thanks, don't tag yet, I realised ca-certificates is out of date on 3.23
2026-06-19 14:52:31 <f_> !104263
2026-06-19 14:53:01 <ikke> f_: And new kernels just got released
2026-06-19 14:53:11 <f_> okay I'll upgrade those as well
2026-06-19 14:55:09 <f_> huh, linux-rpi and linux-lts are not in sync actually.. rpi is on 6.12.x while lts is on 6.18.x, is this intentional?
2026-06-19 14:55:45 <el[m]1> i've gotten an lts update on my pi-derived device to 6.18.x, it even nuked some akms stuff 🫠 so it seems like it's somehow been synced up....?
2026-06-19 14:56:09 <f_> el[m]1: we're talking about alpine 3.23
2026-06-19 14:56:32 <el[m]1> ah okay. my apologies. this was on 3.24.0
2026-06-19 14:56:40 <f_> yeah 3.24 has both on 6.18
2026-06-19 14:57:49 <f_> anyway I guess I'll leave -rpi as-is for now, just upgrading -lts
2026-06-19 15:00:20 <f_> !104264
2026-06-19 15:10:53 <ikke> f_: 3.22 also needs updates of both packages
2026-06-19 15:11:19 <f_> yeah I'll bump these for 3.22 too
2026-06-19 15:12:56 <ikke> Hmm, we lost the s390x host
2026-06-19 15:13:24 <f_> :\
2026-06-19 15:32:28 <ikke> Need to wait for those to return before we can continue, I've sent an email
2026-06-19 15:35:11 <f_> heh well that gives me time to bump linux, apk and ca-certs
2026-06-19 16:09:14 <f_> huh it turns out alpine 3.22 effectively has apk 2.14.10 more or less
2026-06-19 16:09:57 <f_> but a bump won't hurt. anyway, let's wait for s390x
2026-06-19 16:16:16 <ikke> Unplanned power outage (due to planned work)
2026-06-19 16:20:13 <f_> right, but at least I think I bumped all the packages that needed a bump
2026-06-19 16:21:41 <f_> I'll have to go afk for a bit, but when I come back I should be able write the release notes
2026-06-19 16:26:21 <ikke> f_: thanks!
2026-06-19 16:46:38 <ikke> ETA is in the afternoon US time, so too late for me
2026-06-19 18:30:37 <f_> ikke: btw, it might make sense to merge omni's MR in the mksite repo? I'll admit I overlooked those xen fixes but they seem relevant (and I added them locally to 3.2{2,3}.5 release notes)
2026-06-19 18:56:40 <f_> is this good? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/133/diffs
2026-06-19 18:56:46 <f_> anything I missed?
2026-06-19 20:13:49 <WhyNotHugo> ikke: can you roll over to the newer apkbrowser with the fixed column creation?
2026-06-19 20:14:09 <ikke> WhyNotHugo: That one should've been deployed already
2026-06-19 20:19:57 <ikke> WhyNotHugo: Anything missing?
2026-06-19 20:21:37 <WhyNotHugo> All proyects say "Not found in Anitya". I wonder if they actually need to be updated for the flag to be updated.
2026-06-19 20:27:23 <ikke> Now deployed the docker images that were built in gitlab (instead of locally built)
2026-06-19 20:38:19 <f_> ikke: are we waiting for the s390x runner to come back before merging the linux/apk bumps?
2026-06-20 00:07:46 <f_> okay if the s390x runner comes back by tomorrow (UTC) then I can retrigger s390x ci builds
2026-06-20 00:07:55 <f_> until then - good night!
2026-06-20 06:21:12 <ikke> f_: I have rebased your MRs and added one more kernel module that needed to be rebuilt.
2026-06-20 11:47:47 <f_> ikke: thanks!
2026-06-20 15:50:33 <jvvv> Could I get !104258 reviewed? There is no soname change so I think it is ready.
2026-06-20 16:36:37 <jvvv> ikke: Thank you
2026-06-20 16:39:59 <ikke> yw
2026-06-20 18:21:22 <ikke> Just rv64 3.22 building kernels left
2026-06-20 18:25:29 <RavFX[m]> Alpine-linux Matrix room (that is bridge to it's IRC equivalent) seam to be borked. I can't send a message on that room (it's why I send here). It's eating up other home server storage by flooding with "states" Like 7M db row of it since two days lol.
2026-06-20 18:27:26 <RavFX[m]> If not fixed in the next week or so, I will have to ACL it away from my side as it cause maintainance issues due to the storage size requirement of dealing with that kind of bork.
2026-06-20 18:28:27 <abby> matrix moment
2026-06-20 18:29:29 <ikke> PureTryOut: pj: ^
2026-06-20 18:31:39 <f_> ikke: I don't think there's much they can do
2026-06-20 18:31:49 <ikke> Who can?
2026-06-20 18:32:04 <f_> #_oftc_#alpine-linux:matrix.org is still on room version v1
2026-06-20 18:32:08 <f_> only matrix.org themselves can fix it
2026-06-20 18:32:21 <f_> and you know they're not particularly responsive...
2026-06-20 18:34:33 <RavFX[m]> It would have to be upgraded (tombstoned) right
2026-06-20 18:35:14 <f_> RavFX[m]: yeah but no one other than matrix.org can do this
2026-06-20 20:00:03 <Saijin_Naib[m]> If anyone has bandwidth after the release, can I get a review and hopefully merge of !99156 !97494 !97292
2026-06-20 20:00:19 <Saijin_Naib[m]> It would help me get some work done
2026-06-20 20:45:44 <jvvv> I preparing an upgrade for cproto. It licensed as public domain. I am trying to determine if there is a way to satisfy the spdx requirements with this situation.
2026-06-20 20:46:42 <jvvv> It is not looking to me like it is possible and I am not comfortable with talking to upstream about it.
2026-06-20 20:47:18 <Sertonix[m]> jvvv: https://gitlab.alpinelinux.org/alpine/abuild/-/commit/c396dcd7403c14e7f1d9d0ca2739d48d7eb54c04
2026-06-20 20:47:58 <Sertonix[m]> (Maybe the linked issues is easier to understand)
2026-06-20 20:49:55 <jvvv> Sertonix[m]: Thanks! That looks hopeful.
2026-06-20 20:59:28 <jvvv> Sertonix[m]: So, in the case I am working on, an acceptible license value could be "LicenseRef-$pkgname-Public-Domain"?
2026-06-20 21:02:43 <Sertonix[m]> Yes, that should be fine. Technically SPDX requires LicenseRef to refer to some xml license definition but I intend to ignore that.
2026-06-20 21:06:06 <jvvv> Thanks. Appreciated.
2026-06-20 21:42:28 <jvvv> The warning in the CI lint https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/2403980 seems wrong to me. I think that word splitting is what is wanted in this case. Am I looking at it wrong?
2026-06-20 21:46:53 <WhyNotHugo> jvvv: yeah, word splitting is what you wanted in this particular case. 
2026-06-20 21:47:17 <WhyNotHugo> Normally I'd suggest using `find … | xargs move` or `find … -exec amove`, but amove is a funcion, not a command, so you can't script around it.
2026-06-20 21:47:52 <WhyNotHugo> This will break if the find command ever returns a filename with spaces
2026-06-20 21:48:56 <jvvv> WhyNotHugo: Thanks for the assessment. It gives me ideas for trying to adjust that line to not use amove in this case.
2026-06-20 21:59:58 <Sertonix[m]> The line is planned to be made obsolete by an abuild change
2026-06-20 22:00:57 <Sertonix[m]> But I don't want to break everything at the same time :)
2026-06-20 22:04:28 <durrendal> any change I could get !103015 !103016 !103226 !103227 !102338 !104314 merged? It's a series of new aports but most of them are just adding back functionality that was broken out from saltstack between 3007 -> 3008. I can't upgrade salt before the extensions are merged back in without essentially breaking the package.
2026-06-20 22:04:40 <durrendal> s/change/chance/
2026-06-20 22:05:22 <durrendal> 102338 should have been !103228
2026-06-20 22:56:39 <Sertonix[m]> dalias: Why is lckpwdf not implemented as always failing? musl doesn't know how to correctly lock the file so wouldn't the safe bet be that the file is locked/used by another process
2026-06-20 22:58:30 <dalias> hm?
2026-06-20 22:58:59 <dalias> oh i forgot that even existed. i don't know
2026-06-20 23:03:28 <Sertonix[m]> Ok, just a bit worried that alpine would not notice if lckpwdf is used by a package as the critical security component
2026-06-20 23:05:16 <dalias> maybe grep for the symbol in bin dirs
2026-06-21 09:40:58 <ikke> What is the easiest way to resign an existing apk file with apkv2?
2026-06-21 10:47:42 <WhyNotHugo> The new anitya_checked column in apkbrowser is never back-populated, so all packages will say "Not found in anitya" until there's a package update.
2026-06-21 10:52:47 <ikke> WhyNotHugo: I guess someone needs to create code to backfill it, if possible?
2026-06-21 10:53:07 <WhyNotHugo> Yeah, this was an FYI, not a demand for someone to fix it.
2026-06-21 10:54:02 <ikke> I'm still strugling getting the apk file signed with the right key, to get the linux kernel available for 3.22 so that we can create a release
2026-06-21 10:56:12 <Sertonix[m]> Let me take a look
2026-06-21 10:56:13 <ikke> abuild-sign appears to append the key
2026-06-21 10:59:12 <Sertonix[m]> abuild-gzsplit < foo.apk && abuild-sign control.tar.gz && cat control.tar.gz data.tar.gz > foo.apk
2026-06-21 10:59:32 <ikke> ah, didn't know about gzsplit
2026-06-21 10:59:39 <ikke> will try
2026-06-21 11:04:55 <ikke> Sertonix[m]: thanks! that worked
2026-06-21 11:07:28 <ikke> Let's see if the builder manages to build the modules now
2026-06-21 11:15:44 <ikke> apparently not, it already deadlocked at ';checking for available kernel interfaces...'
2026-06-21 11:20:35 <ikke> I'm racing a banapi against a milkv, see who wins
2026-06-21 11:22:49 <f_> both riscv?
2026-06-21 11:24:41 <f_> ikke: Need more help for 3.22?
2026-06-21 11:25:53 <f_> not at home right now but I'll be around in a few hours
2026-06-21 11:26:34 <ikke> Yes, the kernel built, now the modules need to be built
2026-06-21 11:26:57 <ikke> But the builder is not cooperating
2026-06-21 11:29:27 <f_> linux-rpi built successfully right?
2026-06-21 11:29:36 <f_> and lts in other arches?
2026-06-21 11:31:21 <ikke> everything is finished except linux-lts + modules in rv64 3.22-stable
2026-06-21 11:31:45 <ikke> linux-rpi is only for arm-like arches
2026-06-21 11:31:47 <f_> as...usual basically?
2026-06-21 11:31:51 <ikke> yup
2026-06-21 11:32:10 <f_> yes I asked for rpi in arm*
2026-06-21 11:32:25 <ikke> right. All other builders are idle
2026-06-21 11:32:26 <f_> I know rpi doesn't do riscv boards that run linux :)
2026-06-21 11:34:03 <f_> okay, how about 3.21? Same situation?
2026-06-21 11:34:43 <f_> I see all 3.21 builders are idle except rv64
2026-06-21 11:34:56 <ikke> build-3-21-riscv64 online 
2026-06-21 11:34:58 <ikke> idle
2026-06-21 11:35:16 <ikke> For some reason in managed to finish on its own
2026-06-21 11:35:27 <f_> oh cool
2026-06-21 11:35:36 <ikke> let me check, just to be sure
2026-06-21 11:35:37 <f_> It said "lost" a few minutes ago
2026-06-21 11:36:07 <ikke> Yeah, I restarted the service
2026-06-21 11:36:33 <ikke> oh, we didn't update 3.21
2026-06-21 11:36:42 <ikke> openssl fix is not available there
2026-06-21 11:36:45 <ikke> only 3.22 and 3.23
2026-06-21 11:36:52 <f_> oh I'm dumb
2026-06-21 11:37:05 <f_> I confused 3.23 & 3.22 with 3.22 & 3.21
2026-06-21 11:37:05 <ikke> and the 3.23 builder is on different hw
2026-06-21 11:37:21 <f_> my bad
2026-06-21 11:38:19 <f_> 3.23 riscv64 completed then, it's only 3.22 riscv64 that's causing issues?
2026-06-21 11:38:41 <ikke> https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=v3.23&repo=&arch=&origin=&flagged=&maintainer= looks good
2026-06-21 11:43:38 <ikke> oh, most modules are not available for rv64
2026-06-21 11:48:17 <ikke> ok done
2026-06-21 11:48:19 <ikke> But I have to go now
2026-06-21 11:49:07 <f_> cya
2026-06-21 12:33:01 <pu> Hi, I forked aports 45064 commits ago... update fork seems to fail in gitlab, should I dump and refork aports?
2026-06-21 12:34:24 <WhyNotHugo> Oh, the code for apkbrowser backfilling *is* correct
2026-06-21 12:34:34 <WhyNotHugo> It just seems taht all the samples I came across are actually unchecked
2026-06-21 12:37:51 <WhyNotHugo> But a lot of packages on the web UI show "no checked" despite being present.
2026-06-21 12:40:43 <WhyNotHugo> pu: You can clone to a new location and then `git pull path/to/new/clone master`
2026-06-21 13:17:16 <pu> WhyNotHugo: if I clone my fork elsewhere it will still be 45K commits late no?
2026-06-21 13:52:34 <quinq> pu, pull locally, rebase, and push back
2026-06-21 14:07:50 <WhyNotHugo> Oooh, your fork on gitlab is behind. There's a button in the UI to sync it.
2026-06-21 14:08:02 <WhyNotHugo> GitLab is pretty dumb and you need to push al objects for those 45k commits back to your fork to update it
2026-06-21 15:18:05 <ikke> and the 3.22 builder is no longer idle
2026-06-21 15:51:06 <pu> If I need to update my sole package that is in community, do I need to start in testing again, or can I update it in community right away?
2026-06-21 15:51:44 <ikke> the latter
2026-06-21 16:21:25 <WhyNotHugo> Is there any (sane) way that I can rebuild an aport using all dependencies with versions matching the current aports checkout, rather than latest in mirrors?
2026-06-21 16:24:14 <ikke> Don't think so, without pinning dependencies. I assume from your question there are downgrades involved?
2026-06-21 16:24:46 <WhyNotHugo> Yeah, basically want to use this for bisection
2026-06-21 16:41:00 <Sertonix[m]> I think my general approach would be to have a script creating indexes that only contain versions that should be used.
2026-06-21 16:41:15 <ikke> But you'd only make sure only those repos are enabled
2026-06-21 16:41:30 <ikke> also need to make*
2026-06-21 16:42:31 <ikke> I don't think you can make apk prefer packages from a specific repo
2026-06-21 16:42:46 <ikke> (except repo pinning each package)
2026-06-21 16:42:50 <Sertonix[m]> But to exactly match the checkout you would need compile most recursive makedependencies from source. Which I have been looking at but is a bit more complex
2026-06-21 16:43:57 <ikke> apkap recursive-revdeps <pkg>?
2026-06-21 16:43:59 <ikke> ap*
2026-06-21 16:44:00 <Sertonix[m]> with rootbld it should be enough to set mirror=$REPODEST
2026-06-21 16:45:33 <Sertonix[m]> The lua-aports list is incomplete due to silently ignoring unknown depends and subpackage depends. It mostly works which may be enough in this case
2026-06-21 17:49:40 <ikke> wow, a miracle, rv64 finished before s390x
2026-06-21 17:49:53 <f_> wow
2026-06-21 17:50:02 <f_> was it real rv64 or in qemu
2026-06-21 17:50:06 <ikke> real
2026-06-21 17:50:13 <f_> that can't be real
2026-06-21 17:50:32 <ikke> I have a feeling the s390x machine is a bit slower since the reboot
2026-06-21 17:51:07 <f_> Maybe the s390x machine and riscv64 machine got swapped without you noticing ;)
2026-06-21 17:51:17 <ikke> heh
2026-06-21 17:51:49 <f_> try `uname -m` on both just to make sure xD
2026-06-21 17:53:02 <f_> I mean, riscv64 is supposed to be the slow builder, not s390x!
2026-06-21 17:53:26 <ikke> build-edge-s390x [~]# uname -m
2026-06-21 17:53:28 <ikke> s390x
2026-06-21 17:53:47 <f_> maybe they modified uname to return s390x instead of riscv64!
2026-06-21 17:53:48 <ikke> build-3-22-s390x [~]# uname -m
2026-06-21 17:53:50 <ikke> s390x
2026-06-21 17:54:34 <f_> with my bad jokes out of the way I guess 3.23 is ready to be tagged in the meantime? :)
2026-06-21 17:54:56 <f_> 3.23.5*
2026-06-21 17:55:22 <ikke> I suppose :)
2026-06-21 17:55:35 <f_> oh there's a rpi-bootloader update, probably should backport that
2026-06-21 17:55:48 <f_> I can take care of that
2026-06-21 17:55:51 <ikke> right
2026-06-21 17:55:57 <ikke> I'll hold off on tagging then
2026-06-21 17:58:03 <f_> I'll backport to 3.24 too
2026-06-21 18:05:16 <f_> !104330 for 3.22
2026-06-21 18:08:49 <ikke> f_: checksum failure
2026-06-21 18:09:01 <f_> oops
2026-06-21 18:14:55 <ikke> That was fast
2026-06-21 18:15:10 <ikke> Already built on the builders
2026-06-21 18:26:17 <f_> ikke: oh it's just binaries, there's nothing to "build*
2026-06-21 18:26:23 <ikke> right
2026-06-21 18:30:24 <f_> !104332 for 3.23
2026-06-21 18:30:56 <f_> !104332
2026-06-21 18:30:58 <f_> that's better
2026-06-21 18:37:50 <ikke> it's a breath of fresh are compared to nodejs :)
2026-06-21 18:38:59 <ikke> Ok, can we do a final cross-check that everything is up-to-date?
2026-06-21 18:39:22 <ikke> check that kernel version are in sync (eg linux-lts and linux-rpi)
2026-06-21 18:40:05 <ikke> linux-lts, 3.22-stable, 6.12.94 for all arches
2026-06-21 18:40:16 <f_> fair
2026-06-21 18:40:35 <ikke> linux-lts, 3.23-stable, 6.18.36 for all arches
2026-06-21 18:41:06 <f_> that's up to date
2026-06-21 18:41:12 <f_> musl is ok too
2026-06-21 18:41:24 <ikke> linux-rpi, 3.22-stable, 6.12.85 for all arches (aarch64, armv7, armhf)
2026-06-21 18:41:26 <f_> apk-tools ... v2 in 3.22, so definitely "fine"
2026-06-21 18:41:40 <ikke> linux-rpi, 3.23-stable, 6.12.85 for all arches (aarch64, armv7, armhf)
2026-06-21 18:41:45 <f_> 3.23 .. I don't think apk got a new release yesterday
2026-06-21 18:42:41 <ikke> raspberrypi-bootloader, 3.22-stable, 1.20260619-r0
2026-06-21 18:43:18 <ikke> 3.23-stable is still old version (not updated on pkgs.a.o yet)
2026-06-21 18:43:33 <f_> right the builders need to "build" it
2026-06-21 18:43:52 <ikke> it has been built, but uploading to t1 can take ~15 minutes
2026-06-21 18:43:55 <f_> ah right
2026-06-21 18:44:08 <ikke> and then apk-browser needs to ingest it
2026-06-21 18:44:29 <f_> gives me time to backport the rpi-bl update to 3.24
2026-06-21 18:44:40 <ikke> ca-certificates, 3.22-stable, 20260611-r0, all arches, same for 3.23-stable
2026-06-21 18:46:13 <ikke> Ok, raspberrypi-bootloader is up to date now as well
2026-06-21 18:46:26 <ikke> Next step, alpine-base
2026-06-21 18:49:18 <ikke> Looks okay (v3.23.5)? https://tpaste.us/aW1N
2026-06-21 18:50:32 <f_> looks good to me!
2026-06-21 18:51:11 <ikke> pushed
2026-06-21 18:51:33 <f_> \o/
2026-06-21 18:53:15 <ikke> Same for 3.22.5, looks good? https://tpaste.us/qbEz
2026-06-21 18:54:15 <f_> lgtm too
2026-06-21 18:54:28 <ikke> Pushed
2026-06-21 18:55:36 <f_> now just need to wait for release images I guess
2026-06-21 18:55:47 <ikke> Yes
2026-06-21 18:56:07 <ikke> ncopa needs to sign them, I cannot do that
2026-06-21 18:56:38 <f_> I mean wait for them to build
2026-06-21 18:56:43 <ikke> ack
2026-06-21 18:56:58 <ikke> Can you update the date on the post? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/133
2026-06-21 18:57:08 <f_> I seem to remember that 3.24.1 images appeared before ncopa had a chance to sign them
2026-06-21 18:57:11 <f_> sure
2026-06-21 18:57:32 <ikke> yes, correct. The builders already upload the images, and then ncopa signs them
2026-06-21 18:58:12 <f_> done
2026-06-21 19:00:38 <ikke> https://wwwtest.alpinelinux.org/posts/Alpine-3.22.5-3.23.5-released.html (wwwtest)
2026-06-21 19:00:42 <ikke> looks good?
2026-06-21 19:01:02 <ikke> Waiting for the images to appear on dl-cdn before pushing it live
2026-06-21 19:01:19 <f_> neat
2026-06-21 19:04:06 <ikke> hmm, 3.22.5 is still missing
2026-06-21 19:04:36 <f_> Seems in dl-master for some arches but not all
2026-06-21 19:04:45 <f_> e.g. in armhf but not armv7
2026-06-21 19:06:01 <ikke> ok, seems they're being picked up now
2026-06-21 19:10:21 <ikke> 4100% CPU usage 
2026-06-21 19:11:26 <f_> heh
2026-06-21 19:13:13 <ikke> Ok, everything is idle now
2026-06-21 19:14:43 <f_> it seems only x86_64 doesn't have 3.23.5 yet
2026-06-21 19:14:58 <ikke> It was the last one to upload
2026-06-21 19:15:04 <f_> right makes sense
2026-06-21 19:17:12 <f_> btw it seems 3.24.1 wasn't announced in the ML
2026-06-21 19:18:02 <ikke> I guess we can do a single anouncement for both
2026-06-21 19:18:12 <f_> yeah
2026-06-21 19:19:37 <f_> going afk for now, see you in max ~1 hour :)
2026-06-21 19:34:54 <ikke> alright, thanks for all your help
2026-06-21 20:07:26 <f_> \o/
2026-06-21 21:33:36 <runxiyu_> riscv64 builder has been a bit sad recently
2026-06-21 22:12:01 <f_> runxiyu_: it always is sad
2026-06-21 22:12:11 <f_> when it isn't, it's slow
2026-06-21 23:28:21 <quinq> Oh, Alpine is using busybox as /bin/sh?
2026-06-21 23:28:25 <quinq> I thought it was dash
2026-06-21 23:35:39 <quinq> It's non conformant to set -e
2026-06-22 02:25:15 <Asmadeus> Is there a rule for what package gets a -dbg subpackage in aports? (just curious, I often have to debug system stuff and some packages I can grab the existing debuginfo from repos, others I need to take the time to rebuild, and I don't see any rule from listing all -dbg packages)
2026-06-22 02:25:31 <Sertonix[m]> quinq: Could you elaborate? set -e has non-intuitive side effects.
2026-06-22 02:26:41 <Sertonix[m]> Asmadeos: Not really. It generally exists if somebody wanted to have it and it's not too big.
2026-06-22 02:32:30 <Asmadeus> Fair enough, thanks. If just building more is expensive it might make sense to move to a separate repo or something that's not archived (at least for main/ packages), or perhaps setting up a debuginfod server instead, but it's not something I'd have the time to help much with so I'll just rebuild packages I need for now :P
2026-06-22 02:41:32 <runxiyu_> ikke: https://gitlab.alpinelinux.org/runxiyu/aports/-/pipelines/447166 is timing out on riscv64 a lot. any ideas on how to fix it?
2026-06-22 02:41:34 <runxiyu_> thanks!
2026-06-22 02:47:08 <mio> runxiyu_: try increasing the job timeout on your aports fork (CI/CD Settings > General pipelines > Timeout)
2026-06-22 02:48:23 <runxiyu_> alright
2026-06-22 02:48:39 <mio> the default is 1h, depending on the package, it may not be enough, e.g. on slower arches
2026-06-22 02:51:02 <mio> https://gitlab.alpinelinux.org/$username/aports/-/settings/ci_cd
2026-06-22 03:20:44 <qaqland> I set 24h for riscv64, it's always the slowest.
2026-06-22 03:26:13 <quinq> Sertonix[m], it doesn't propagate it to sub-shells for command substitution
2026-06-22 04:06:30 <jvvv> I sent an email to the maintainer of community/solaar over a week ago. There are three MRs against that aport, two from two months ago and mine from about three weeks ago. How long is a reasonable amount of time to wait for a reply?
2026-06-22 04:11:19 <jvvv> As it stands, solaar is broken because of it's dependencies. One dep conficts with one of its vendored libs and one dep is missing.
2026-06-22 10:57:31 <Sertonix[m]> jvv: There is unfortunatly no clear policy but I would consider the package free for adoption until they come back
2026-06-22 11:02:23 <Sertonix[m]> quinc: Do you mean like this: sh -ec 'echo $(false); echo true?'
2026-06-22 11:47:43 <ncopa> whoops. I think I may have pushed the busybox update
2026-06-22 11:47:46 <ncopa> unintentionally
2026-06-22 11:56:33 <f_> 4/10 should've been a commit with a beautiful "TEST" in the commit name
2026-06-22 11:56:39 <f_> :D
2026-06-22 11:57:21 <ncopa> :D
2026-06-22 11:57:54 <f_> i see you upgraded linux-lts in master, I guess I can close my MR then ^^
2026-06-22 11:58:10 <ncopa> f_: thank you for working on the kernel bumps. I did a config change for lts aarch64 to simplify boot on rock 5T, and it was simpler for me to run my abump-kernel script
2026-06-22 11:58:11 <ncopa> sorry
2026-06-22 11:58:25 <f_> ncopa: no worries, glad I could help
2026-06-22 11:58:43 <ncopa> and thank you for helping with the 3.2[23].5 releases
2026-06-22 11:59:00 <ncopa> $ tpaste < abump-kernel 
2026-06-22 11:59:00 <ncopa> https://tpaste.us/5pXx
2026-06-22 12:01:47 <f_> thx
2026-06-22 12:14:30 <el[m]1> for what it's worth, i've seen a first prototype release of xfwl4 pop up on the xfce mailing list just hours ago. so if alpine edge wanted to toy around with moving xfce to wayland, it seems like the tooling for that will be available for some early testing soon
2026-06-22 12:17:10 <f_> oh xfce4 can already run wayland with labwc
2026-06-22 12:25:55 <el[m]1> f_: sure but that's kind of unofficial, isn't it? i mention xfwl4 since that seems to be the official way, and i assume people who would package that at some point are in this room 😊 since it would be nice to see xfce on alpine move to wayland once that is feasible (and hopefully see pmOS Edge follow along)
2026-06-22 12:31:06 <f_> I actually hope X11 xfce4 stays around
2026-06-22 14:11:03 <dne> hmm, what is blocking !104273? (linux-lts on 3.24-stable is currently behind 3.23-stable)
2026-06-22 14:15:16 <ikke> dne: see the comment from f_
2026-06-22 14:15:22 <ikke> It's incomplete 
2026-06-22 14:15:44 <ikke> Our focus was on 3.22 and 3.23 to be able to do releases 
2026-06-22 14:15:52 <dne> ok, I see
2026-06-22 14:23:29 <f_> dne: I'll update it in a few minutes
2026-06-22 15:38:08 <jvvv> AntoniAloyTorrens[m]: Did you get my email about community/solaar?
2026-06-22 17:58:09 <ikke> I've mentioned the s390x slowness to the hoster, they said not all processors were online. I expect the performance to be back to normal now.
2026-06-22 18:01:07 <jvvv> Nice!
2026-06-22 21:45:23 <Sertonix[m]> Anybody willing to figure out why gnome-authenticator fails to link on specifically x86_64?
2026-06-22 21:47:27 <sam_> can you link the build log please (+ apkbuild)?
2026-06-22 21:47:47 <sam_> i can have a very quick look for anything obvious
2026-06-22 21:52:22 <Sertonix[m]> https://gitlab.alpinelinux.org/sertonix/aports/-/jobs/2406580
2026-06-22 21:52:43 <Sertonix[m]> (disabling the -dbg subpackage has no effect)
2026-06-22 22:06:41 <sam_> hm
2026-06-22 22:08:16 <sam_> i think it's a bfd bug
2026-06-22 22:10:08 <sam_> a tarball of the inputs (.os) would be helpful. are you using -Wl,--no-keep-memory? if not, please try it, as it may avoid mmap use enough here 
2026-06-23 06:06:57 <Saijin_Naib[m]> https://mastodon.social/@bagder/116797911817651844
2026-06-23 06:13:21 <ikke> our curl builds against libpsl
2026-06-23 06:17:53 <Saijin_Naib[m]> I love Alpine
2026-06-23 07:57:22 <ncopa> <3
2026-06-23 08:23:52 <fabricionaweb> Morning, who could check this !102133
2026-06-23 08:25:07 <june> oh another pds implementation!
2026-06-23 08:25:21 <june> i just opened a mr for tranquil yesterday
2026-06-23 08:29:51 <fabricionaweb> nice one june! I was thinking on it as well but Im running cocoon myself
2026-06-23 08:31:03 <fabricionaweb> you are sourcing it from tangled itself, bold move hahahha
2026-06-23 08:36:01 <fabricionaweb> I think I have a branch for knot june, I just didnt open the PR
2026-06-23 08:36:14 <june> yeah! fabricionaweb, tranquil is very very nice imho. it's also made by my friends! i feel like tangled has good enough uptime though, when it comes to depending on it
2026-06-23 08:36:16 <fabricionaweb> actually I did !102769
2026-06-23 08:36:20 <fabricionaweb> prob needs rebase
2026-06-23 08:36:27 <june> wow! yeah a knot package would also be nice!
2026-06-23 08:36:48 <fabricionaweb> Im running it on my box, I think its fine but a few corks like running under git user
2026-06-23 08:39:50 <june> hm yeah. im running forgejo myself and the default user in that package is "forgejo". i configured it to be "git" but since im on diskless (data-disk) with local backup and an apk overlay, the forgejo user gets created on every boot anyway, which is a bit annoying.
2026-06-23 08:41:03 <june> also, the tranquil package is my first ever apkbuild so it'd appreciate a review :>
2026-06-23 08:42:10 <Biswa96[m]> @nmeum would you like to review the PRs in android-tools project? Those are some important changes.
2026-06-23 09:01:14 <strophy> !95951 is passing CI! Could anyone help me to review and merge this while it is fresh please?
2026-06-23 09:03:54 <fabricionaweb> I may have a few suggestions june, later I write some
2026-06-23 09:15:30 <ncopa> my incus setup broke for some reason. dont know what is going on.
2026-06-23 09:15:32 <ncopa> ncopa-desktop:~/aports/community (master)$ doas apk add incus incus-vm incus-client 2>&1 | tpaste
2026-06-23 09:15:32 <ncopa> https://tpaste.us/KzEB
2026-06-23 09:17:16 <ncopa> incus client was built https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/incus/incus-7.0.0-r3.log
2026-06-23 09:21:24 <ncopa> oh, i know what happened
2026-06-23 09:21:42 <ncopa> ap build-list does not set CARCH
2026-06-23 09:21:58 <ncopa> so it does not pick up that the incus-vm subpackage should be built
2026-06-23 09:22:23 <ncopa> and it ends up deleting those packages from the repo when doing garbage collection
2026-06-23 09:24:13 <ikke> ncopa: there is an MR
2026-06-23 09:24:23 <ikke> subpackages was overwritten instead of extended
2026-06-23 09:24:33 <ikke> (the MR does not adress that yet)
2026-06-23 09:24:44 <ikke> !104136
2026-06-23 09:26:03 <ncopa> oh, right
2026-06-23 09:26:21 <ncopa> i was wrong. that is the real problem
2026-06-23 10:56:23 <qaqland> is there any bot that can help quickly CC maintainers? e.g. in !104321, there are 4 packages
2026-06-23 10:57:30 <qaqland> i want to request review and approvals from them in one click
2026-06-23 11:02:47 <june> sorry fabricionaweb, i was afk. id appreciate some suggestions, thanks!
2026-06-23 11:03:05 <ikke> qaqland: not atm
2026-06-23 11:35:53 <bdprom> could !103001 be merged at some point please, sway has been out of RC for a while now
2026-06-23 12:29:41 <f_> FYI pmOS dropped armhf yesterday
2026-06-23 12:29:55 <f_> https://postmarketos.org/edge/2026/06/22/armhf-removed/
2026-06-23 12:31:58 <ikke> Right, saw the announcement
2026-06-23 12:34:17 <f_> in the future there'll be arch "tiers", wonder if that would be interesting for alpine
2026-06-23 12:37:06 <f_> for pmOS it would have Tier 1-3 with various requirements for each tier, initially it would be     Tier 1: x86_64, aarch64    Tier 2: armv7    Tier 3: riscv64, loongarch64, ppc64le, x86
2026-06-23 12:37:52 <f_> and different expectations when it comes to disabling packages for some arches
2026-06-23 12:43:15 <Habbie> the tier model is very common. Rust (language) and Haiku (OS) also use it, and many others i believe
2026-06-23 13:17:20 <june> thanks for the review, fabricionaweb! i really appreciate it. i do wonder what you meant by moving example.toml installation to conf.d, though. is it about specifying env vars for every config option?
2026-06-23 13:17:45 <june> there would be a lot of them and i feel like itd just become a burden to maintain tbh
2026-06-23 13:21:57 <f_> june: I think they mean the forgejo user is setup in conf.d
2026-06-23 13:22:59 <june> f_, nono. im talking about their review on !104392
2026-06-23 13:24:20 <f_> ohhh
2026-06-23 13:24:33 <f_> I can review it too in a few hours if you want
2026-06-23 13:31:43 <fabricionaweb> I mean just the permissions
2026-06-23 14:10:50 <june> thanks, f_, that would be really nice :)
2026-06-23 14:11:29 <june> oh i already did that then fabricionaweb
2026-06-23 14:11:33 <june> thanks
2026-06-23 14:52:26 <eletrotupi> hello
2026-06-23 14:52:41 <eletrotupi> i've been wondering if we should upgrade prometheus to use the latest release instead of the LTS one
2026-06-23 14:53:02 <eletrotupi> i don't really have an exact usecase for that, i'm confortable with using the LTS one in my own stuff
2026-06-23 14:53:28 <eletrotupi> however i do wonder if that's the desire for the majority of the other users + if this will not lag a lot behind when we eventually decide to migrate
2026-06-23 14:53:42 <eletrotupi> perhaps having both might be a decent path forward?
2026-06-23 14:53:57 <eletrotupi> so having prometheus-latest and prometheus or something like that?
2026-06-23 15:14:01 <f_> Maybe it would make sense to have prometheus-lts and prometheus, and have the -lts one in stable releases and the latest one in edge only
2026-06-23 15:14:08 <f_> or something
2026-06-23 15:14:10 <f_> ¯\_(ツ)_/¯
2026-06-23 15:15:02 <ikke> I'm a bit concerned about the proliferation of multiple versions of all kinds of packages. Not only due storage, but also maintanance and build time increases
2026-06-23 15:27:03 <durrendal> As someone maintaining a complex project that provides both LTS and STS variants I'm wont to agree with ikke. The juice hasn't been worth the squeeze in my experience
2026-06-23 16:46:41 <eletrotupi> yeah, same, the issue with what f_ suggested is that if you have the prometheus package installed today, and you know it is the LTS version, out of the sudden you will have to migrate to the prometheus-lts package instead
2026-06-23 16:46:59 <eletrotupi> and if you're not very aware or read the release notes, then you'll ended up with a non-lts package if you just blindly upgrade
2026-06-23 16:47:23 <eletrotupi> also, I understand the concerns mentioned by ikke
2026-06-23 16:47:42 <eletrotupi> I wonder how to survey or get data that people are aware that they're using the LTS version to be honest
2026-06-23 16:53:40 <f_> right
2026-06-23 17:27:36 <jvvv> ikke: Thank you for the review of !104377
2026-06-23 17:28:29 <jvvv> I am not sure if I handled the pkgrel bump correctly
2026-06-23 17:29:35 <ikke> Generally the first commit does the bump as well, but it's not a big deal
2026-06-23 17:32:03 <jvvv> OK, sorry, I think I am being obtuse about this... but just so I am clear, bumping pkgrel in both commits is preferred in a case like this?
2026-06-23 17:32:28 <jvvv> This is the kind of situation people just irratated with me
2026-06-23 17:32:36 <jvvv> s/just/get/
2026-06-23 17:32:53 <ikke> jvvv: I also commented on your MR. It's not necessary to bump twice
2026-06-23 17:33:33 <jvvv> Ok, thanks. Sorry if I'm annoying
2026-06-23 17:34:25 <ikke> No worries
2026-06-23 17:34:50 <f_> ncopa: ty for sharing your abump-kernel script, very helpful
2026-06-23 17:40:31 <june> abump-kernel? that sounds interesting
2026-06-23 17:41:17 <f_>  13:59 <@ncopa> https://tpaste.us/5pXx
2026-06-23 17:41:44 <june> ty!
2026-06-23 17:42:33 <ikke> wow, zig package has 19k files
2026-06-23 17:43:18 <ikke> (mostly due for cross-compilation apparently)
2026-06-23 17:43:35 <june> its probably almost all std
2026-06-23 17:43:46 <june> zigs std is awesome !!!
2026-06-23 18:20:20 <lnl> Also kernel and libc headers for all the targets lol
2026-06-23 18:21:46 <ikke> yes
2026-06-23 19:21:37 <jvoisin> that's the price to pay for memory safet- oh wait
2026-06-23 19:21:39 <jvoisin> :>
2026-06-23 20:56:21 <runxiyu> i hope arch tiers wouldn't be used as a justification to not care about platforms
2026-06-23 21:06:33 <f_> runxiyu: nah
2026-06-23 21:06:54 <f_> each arch would have at least one maintainer
2026-06-23 21:07:01 <f_> who can take a look at things
2026-06-23 22:31:15 <mathew23> Hi. I have a quick question. What should I do if a merge request passes tests, I've dealt with any issues brought up by maintainers, but then it has just been sitting there for 3 weeks?
2026-06-23 23:00:24 <Sertonix[m]> f_: a maintainer per arch sounds completely independant of arch tiers?
2026-06-24 00:27:53 <Ariadne> what's up with gitlab
2026-06-24 00:50:26 <Saijin_Naib[m]> Thanks for the mass review/merge of my bump MRs
2026-06-24 00:51:49 <Saijin_Naib[m]> I could still really use review/merge of at least !97292
2026-06-24 04:53:59 <ikke> Ariadne: DoS / scraping
2026-06-24 05:29:01 <Ariadne> lovely
2026-06-24 06:00:23 <PureTryOut> Sertonix: with latest rootbld apk now asks me for confirmation before installing dependencies into the build root, that seems wrong. I have apk configured to ask for confirmation (`-i`) system-wide so maybe that's interfering but that shouldn't affect rootbld
2026-06-24 06:00:57 <PureTryOut> mathew23: ping someone with merge rights to look at it. Bumping it here would suffice if you'd mention the MR in question
2026-06-24 06:23:40 <ikke> PureTryOut: I was already looking at it. It's about nethack
2026-06-24 06:23:41 <jvvv> PureTryOut: I've looked pretty closely at the rootbld() function. I don't see how apk is being called interactive unless SUDO_APK defined that in the environment. It is defined as ':${SUDO_APK:="abuild-apk --no-interactive"
2026-06-24 06:23:51 <ikke> !103219
2026-06-24 06:24:28 <PureTryOut> jvvv: perhaps it's not rootbld specific but abuild in general, I just never use abuild without rootbld 😅
2026-06-24 06:26:58 <jvvv> PureTryOut: Sure, I primary use rootbld also. It is never been interactive for me, not even since the last update, so it just makes me curious.
2026-06-24 06:28:35 <jvvv> Looking at the rootbld function and it uses $SUDO_APK, which defaults to what I said above. It just makes me think something else could be involved.
2026-06-24 06:29:51 <jvvv> Like it being defined in the shell's environment when abuild rootbld is run.
2026-06-24 06:30:27 <jvvv> Or in one of the abuild.conf or /usr/share/abuild/default.conf
2026-06-24 06:31:49 <PureTryOut> jvvv: try creating the file `/etc/apk/interactive` and then try again
2026-06-24 06:32:04 <jvvv> Ah I see it now, it changed to ROOTBLD_APK... sorry, I need to git pull
2026-06-24 06:33:14 <PureTryOut> Yeah that's missing the --no-interactive which probably causes this
2026-06-24 06:34:19 <jvvv> Yep, I'm definitely behind the time on that. I will have to re-study abuild.in from scratch it looks like.
2026-06-24 06:36:04 <PureTryOut> Thanks for the pointer though, submitted a fix https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/518
2026-06-24 06:37:15 <jvvv> PureTryOut: I see that ROOTBLD_APK gets inherits it's apk command from the APK variable, so I wonder if defining APK in ~/.abuild/abuild.conf to 'apk --no-interactive' would be another approach
2026-06-24 06:41:12 <jvvv> So, I did this: doas touch /etc/apk/interactive; echo 'APK="apk --no-interactive"' >> ~/.abuild/abuild.conf
2026-06-24 06:42:19 <jvvv> Running abuild rootbld at this point does not ask, but if I remove the last line of my abuild.conf conf, it does
2026-06-24 06:43:54 <jvvv> But your MR makes sense to me.
2026-06-24 07:43:08 <fabricionaweb> Hi, I need review on 3 opened MR aports:add !102133 !102769 !102821
2026-06-24 09:22:08 <fabricionaweb> I hate to maintain node apps that require frontend build... Always pita to build for other arch also makes not much sense since outcome is noarch anyways...
2026-06-24 09:33:27 <PureTryOut> jvvv: yeah I could work around it locally but there really is no reason to ask for confirmation in rootbld, so better just fix it properly
2026-06-24 10:11:12 <fabricionaweb> I think I will need to port that "rolldown rust" as well... 
2026-06-24 10:54:03 <f_>  01:00 <Sertonix[m]> f_: a maintainer per arch sounds completely independant of arch tiers?
2026-06-24 10:54:05 <f_> yeah it is
2026-06-24 10:54:07 <f_> kind of
2026-06-24 10:54:17 <f_> maintainers have different responsibilities depending on the arch tier
2026-06-24 10:54:23 <f_> slightly different
2026-06-24 14:05:13 <Sertonix[m]> If there are rust build failures in alpine edge 32-bit related to libc::timespec please note them at http://gitlab.alpinelinux.org/aports/abuild/-/merge_requests/508 (currently known is librewolf/firefox)
2026-06-24 14:05:41 <f_> Sertonix[m]: 404
2026-06-24 14:06:12 <f_> http://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/508 is the correct link
2026-06-24 14:06:50 <Sertonix[m]> Right, thanks!
2026-06-24 14:20:14 <PureTryOut> What's up with the constant CI runners failing to start a job? Doesn't matter what arch or what type of job, they often just fail to start at all
2026-06-24 14:23:48 <f_> PureTryOut: they're busy with other tasks?
2026-06-24 14:25:57 <lotheac> fail to start as in stuck waiting to start, or there is an error?
2026-06-24 14:34:53 <WhyNotHugo> Maintainer for testing/btfs doesn't even seem to have a GitLab account. All commits in recent years were done by other. Ref: 89b03a46de2b60f36e101fbdf0e211ccf7dc25ae
2026-06-24 14:35:03 <aelin> i presume librewolf's codebase is just firefox right?
2026-06-24 14:35:13 <aelin> if so I'll just patch and test build Firefox
2026-06-24 14:35:30 <WhyNotHugo> aelin: essentially yes, with some patches on top
2026-06-24 14:41:35 <aelin> hm firefox 151 does not have this version of zeitstempel vendored as far as I can tell
2026-06-24 14:41:40 <aelin> guess I'll patch librewolf instead
2026-06-24 14:42:14 <aelin> I can't pull from GitLab for some reason
2026-06-24 14:43:14 <aelin> oh nvm found it
2026-06-24 14:51:25 <puretryout[m]1> [lotheac](https://matrix.to/#/@_oftc_lotheac:matrix.org) error, see https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2409117 as an example
2026-06-24 14:51:29 <puretryout[m]1> > error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504
2026-06-24 14:55:00 <lotheac> from that log, i would wager a guess that's a timeout trying to fetch the aports repo from gitlab
2026-06-24 14:55:16 <lotheac> ikke may have more insight
2026-06-24 14:55:28 <PureTryOut> That said, the whole of GitLab is slow, including pushing and pulling from git. I guess that's related
2026-06-24 14:55:45 <lotheac> yeah, i can see that just trying to read the logs...
2026-06-24 14:56:21 <f_> apparently it's because of DDoSing/scrapers
2026-06-24 14:56:38 <f_> always ruining all the fun...
2026-06-24 14:58:07 <PureTryOut> 😢 Is there no Anubis or something comparable yet?
2026-06-24 14:59:26 <f_> there is go-away
2026-06-24 14:59:51 <f_> which is about just as effective
2026-06-24 15:10:00 <PureTryOut> Well it's basically completely down at this point. I have a git push going on for about 10 minutes already, only 1 commit 🤷
2026-06-24 15:11:56 <aelin> yeah, I've also been trying to push the Firefox/Librewolf fix for 10 minutes now
2026-06-24 15:13:52 <ikke> 🤔
2026-06-24 15:18:09 <ikke> I took some more drastic measures, sorry if I affected someone
2026-06-24 15:18:52 <aelin> this is funny, GitLab thinks my MR has no changes
2026-06-24 15:19:36 <aelin> I'll just grab a coffee and come back later
2026-06-24 15:19:43 <ikke> Load is lower again now
2026-06-24 16:06:07 <mathew23> Any chance someone could merge !103219 (NetHack 5)? It's been sitting around for a few weeks and I don't think the assignee can do it.
2026-06-24 17:42:37 <PureTryOut> Various MR's now think there are no changes while there definitely are 😅
2026-06-24 17:43:06 <f_> I think today is "GitLab goes weird" day.
2026-06-24 17:43:57 <PureTryOut> I guess I'll merge these locally...
2026-06-24 18:48:18 <ptrc> hm, i'm getting a 404 on trying to curl a .patch from a merge request
2026-06-24 18:48:38 <ptrc> not even a 500, but a 404
2026-06-24 18:50:33 <quinq> Maybe it's locked out behind identification?
2026-06-24 18:50:39 <ptrc> nope, shouldn't be
2026-06-24 18:52:10 <quinq> What's the actual link? Could test from here too
2026-06-24 18:52:50 <ptrc> ah, gitlab thinks it has no commits
2026-06-24 18:52:51 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104462
2026-06-24 18:52:57 <ptrc> and adding .patch or .diff at the end
2026-06-24 18:53:37 <quinq> At least from here the gitlab is veeery slow to answer
2026-06-24 18:53:55 <quinq> Right, it says Commits 0
2026-06-24 18:56:08 <ptrc> shrug, a git fetch works just fine
2026-06-24 19:03:21 <quinq> $ time curl -LI https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104462
2026-06-24 19:03:24 <quinq>     0m16.19s real     0m00.02s user     0m00.01s system
2026-06-24 19:03:35 <quinq> Is the gitlab under attack'
2026-06-24 19:03:39 <quinq> s/'/?/
2026-06-24 19:07:03 <ncopa> always
2026-06-24 19:07:10 <quinq> ptrc, this seems to work though, https://gitlab.alpinelinux.org/alpine/aports/-/commit/48ad3671db339a7e2ff749cb9aa1f001098a22f2.patch
2026-06-24 19:07:46 <ptrc> quinq: aye, though i already `git fetch`ed the branch manually :p
2026-06-24 19:07:53 <ptrc> i'm guessing the mr indexing is broken
2026-06-24 19:07:54 <quinq> ^^
2026-06-24 19:08:12 <quinq> Most frustrating part if how long it freaking takes
2026-06-24 19:08:39 <WhyNotHugo> quinq: the most frustrating part is that it shows stale data instead of indicating that it's not ready yet.
2026-06-24 19:08:54 <WhyNotHugo> You can potentially merge an MR where you see one thing, but the branch has something else already.
2026-06-24 19:08:57 <quinq> That too I suppose ^^
2026-06-24 21:20:54 <Ariadne> is there a reason why we cannot install Anubis/go-away on gitlab? 
2026-06-24 21:22:10 <WhyNotHugo> Ariadne: isn't it already running go-away?
2026-06-24 21:22:40 <Ariadne> well if it is, it does not seem effective 
2026-06-24 21:22:58 <WhyNotHugo> Yeah, my queries get __goaway_challenge=… appended to them
2026-06-24 21:23:15 <Ariadne> maybe Anubis will be more effective? 
2026-06-24 21:31:35 <quinq> Ariadne, it is
2026-06-24 21:31:59 <Ariadne> to which? 
2026-06-24 21:32:03 <quinq> via: HTTP/1.1 git.gammaspectra.live/git/go-away@(devel)
2026-06-24 21:32:19 <quinq> I think that the problem with Anubis is that it requires JavaScript
2026-06-24 21:32:27 <quinq> go-away has simpler method
2026-06-24 21:32:38 <quinq> (*I think*)
2026-06-24 21:32:59 <WhyNotHugo> Yeah, IIRC  Anibus is more disruptive.
2026-06-24 21:32:59 <Ariadne> yes, but gitlab already requires javascript
2026-06-24 21:33:16 <WhyNotHugo> gitlab already requires **multiple megabytes** of javascript
2026-06-24 21:33:28 <quinq> Ariadne, it doesn't necesarily
2026-06-24 21:33:44 <quinq> What ptrc proved just a few hours ago
2026-06-24 21:34:21 <quinq> I mean for the whole web UI, sure, but not for accessing some direct content otherwise
2026-06-24 21:34:28 <Sheila> anubis has carveouts for certain no-JS UAs, so I'm not sure why 'requires JS' is a barrier.
2026-06-24 21:34:40 <Ariadne> yes I am talking about typical use of gitlab
2026-06-24 21:34:49 <quinq> (though IIRC it's kind of a configuration option? I remember some gitlab instances not actually requiring JavaScript for most things)
2026-06-24 21:35:16 <quinq> Sheila, read again :)
2026-06-24 21:37:00 <Ariadne> my point is that I think it is better to install anubis and terminate the DoS
2026-06-24 21:37:13 <Ariadne> clearly whatever go-away does isn't working anymore 
2026-06-24 21:38:43 <quinq> Is there some access logs available to see how this “isn't working”?
2026-06-24 21:39:28 <Ariadne> not my department (: 
2026-06-24 21:39:34 <quinq> I'm just curious to see what kind of UA is hammering the gitlab
2026-06-24 21:39:57 <Ariadne> my guess is that it's perplexity
2026-06-24 21:40:34 <Ariadne> I wound up firewalling all of Perplexity's ip ranges from distfiles.ariadne.space
2026-06-24 21:40:54 <Ariadne> because it would just sit there and keep downloading the same tarballs over and over and over again
2026-06-24 21:42:06 <Ariadne> and while I use a colo provider that gives me 50gbps unmetered connection, it is shared between many other customers and I do not see the point of maxing out my colo box to serve fucking AI code search engines all day 
2026-06-24 21:48:30 <quinq> “Perplexity is a free AI-powered answer engine that provides accurate, trusted, and real-time answers to any question.”
2026-06-24 21:48:34 <quinq> Trusted by whom?
2026-06-24 21:48:42 <quinq> By their marketing team?
2026-06-25 00:52:53 <Ariadne> quinq: great question.  i hear 'AI-powered answer engine' and i want to run like hell
2026-06-25 01:42:48 <Sheila> all I know about AI 'accuracy' is that experts keep telling people to not use it for answering questions in their field but saying it's fine for not-their field. which mainly just tells me "don't".
2026-06-25 02:09:53 <skarnet> it's just like the press! It's always so accurate, except in *that one field* that I know very well. Incredible how these things go.
2026-06-25 02:26:48 <Ariadne> well i've spent the past hour and a half trying to git pull, so i can git push
2026-06-25 02:26:57 <Ariadne> and i think i give up
2026-06-25 03:18:36 <Asmadeus> FWIW fetching from gitlab ( https://gitlab.alpinelinux.org/alpine/aports.git/ ) times out, but there's a mirror at https://git.alpinelinux.org/aports that's easier to pull from
2026-06-25 03:19:53 <Asmadeus> I'd tend to agree more aggressive filtering would be appreciated though (whether anubis or just tuning go-away more aggressively), but setting these up takes time and I assume very few people would have access to this :/
2026-06-25 04:44:30 <Ariadne> Asmadeus: yes, i normally pull from the public mirror, but due to the DoS, the public mirror is not in sync
2026-06-25 06:20:24 <Asmadeus> oh :(
2026-06-25 06:32:05 <ikke> I've made changes to the go-away config
2026-06-25 06:33:18 <ikke> Load has been reduced again 
2026-06-25 07:41:56 <runxiyu> Ariadne: go-away can trivially be configured to do anubis-like js pow challenges
2026-06-25 07:42:18 <Ariadne> yes
2026-06-25 07:42:31 <Ariadne> that's wonderful, can we turn it on? :)
2026-06-25 07:46:19 <dne> in #alpine-infra:
2026-06-25 07:46:22 <dne> 05:42 <@ikke> Adjust the go-away config to ask for a PoW challenge now in most cases
2026-06-25 07:46:24 <dne> 05:42 <@ikke> Adjusted*
2026-06-25 07:48:19 <Ariadne> what are these bots?  where do they come from?  do those companies have accounts payable contacts we can send invoices to?
2026-06-25 07:48:20 <Ariadne> :)
2026-06-25 07:50:03 <Ariadne> i am kidding, but not really.  i think if these AI companies want to flood us with bots, they should pay for the increased infrastructure & sysadmin time necessary to support it
2026-06-25 07:51:57 <runxiyu> has anyone profiled which parts of gitlab seem to be the culprit on performance?
2026-06-25 07:53:15 <Ariadne> i mean, it is gitlab
2026-06-25 07:53:29 <Ariadne> not exactly known to be the highest performing app
2026-06-25 07:54:09 <runxiyu> other than comprehensive CI, what are some of the reasons we use gitlab?
2026-06-25 07:54:34 <Ariadne> at this point?  probably because migrating off gitlab is even more of a nightmare?
2026-06-25 07:54:49 <Ariadne> but historically, it was what was available
2026-06-25 07:55:16 <Ariadne> gitea (now forgejo) was not really in a state where it could be implemented 10 years ago
2026-06-25 07:56:49 <Ariadne> and what we had before (gitolite + redmine), we had significantly outgrown
2026-06-25 07:57:40 <runxiyu> makes sense
2026-06-25 07:58:12 <runxiyu> i remember exporting issues and MRs isn't that giant of a nightmare though
2026-06-25 07:58:16 <runxiyu> but yeah
2026-06-25 07:59:04 <runxiyu> at some point i should study how the builders work
2026-06-25 08:00:24 <Ariadne> the builders are a botnet :D
2026-06-25 08:00:44 <runxiyu> in the most literal sense. hah!
2026-06-25 08:01:03 <Ariadne> way back in the day, #alpine-commits was command & control for it
2026-06-25 08:01:12 <Ariadne> now the botnet lives on mqtt :)
2026-06-25 08:01:20 <runxiyu> IRC is a great rendevous point
2026-06-25 08:01:22 <runxiyu> lolvich[m]: 
2026-06-25 08:01:26 <runxiyu> uhhh goguma--
2026-06-25 08:01:29 <runxiyu> lol*
2026-06-25 08:02:31 <lotheac> migrating off of gitlab would be technically interesting, imo
2026-06-25 08:02:39 <lotheac> not sure if it's the right call though
2026-06-25 08:02:49 <Ariadne> i don't think it is
2026-06-25 08:03:00 <Ariadne> gitlab is really good at horizontal scaling
2026-06-25 08:03:23 <lotheac> been thinking about moving one of my clients from github to ... well anything
2026-06-25 08:03:29 <Ariadne> we just need servers & sysadmin time
2026-06-25 08:03:37 <Ariadne> and probably a beer budget for ikke
2026-06-25 08:03:38 <runxiyu> horizontal scaling is nice
2026-06-25 08:03:49 <runxiyu> it would be nicer if it wasnt so goddam bloated in the first place
2026-06-25 08:04:04 <Ariadne> well modern gitlab isn't really targeted at *us*
2026-06-25 08:04:18 <runxiyu> exactly
2026-06-25 08:04:20 <Ariadne> it is targeted at corporate environment
2026-06-25 08:32:35 <achill> abby: thx for the jellyfin-desktop patch, is now in alpine aswell :)
2026-06-25 08:39:43 <ikke> Yeah, our gitlab deployment is monolithic and we definitely need to scale it. Takes quite some effort to do.
2026-06-25 08:41:58 <Ariadne> out of curiosity, how stable are our IPv4/IPv6 addresses for gitlab?
2026-06-25 08:42:21 <Ariadne> gears are turning in my brain, you see
2026-06-25 08:46:42 <Ariadne> you see, my thinking is, if alpine gitlab ips are stable, we could just ask some network engineers at the AI companies to do us a solid and nullroute alpine's gitlab ips on their end
2026-06-25 08:47:00 <Ariadne> thus killing the DoS traffic, or at least a large part of it
2026-06-25 08:47:33 <raspbeguy> Hello, I think this MR can be merged now !103526
2026-06-25 08:49:11 <ikke> Ariadne: most traffic is coming from random residential IPs
2026-06-25 08:49:47 <Ariadne> damn, so its people using claude code and shit
2026-06-25 08:50:16 <ikke> Or proxied scrapers 
2026-06-25 08:50:48 <Ariadne> oh yeah there was that one firefox extension that turns your browser into an exit node in exchange for 'free vpn'
2026-06-25 08:51:00 <Ariadne> i forget what it's called, but that's definitely a thing
2026-06-25 08:51:30 <Ariadne> (that and other 'fun facts' you get to learn about working in adtech)
2026-06-25 08:52:27 <dne> https://spur.us/blog/smart-tv-apps-residential-proxy-sdks
2026-06-25 08:52:39 <Sheila> at adelie we were dealing with scrapers hammering our gitlab trying to get a specific kernel commit recently, until zv put together some filtering at nginx level to automatically ban ips doing it. I wonder if there's a similar pattern here.
2026-06-25 08:53:20 <Sheila> (the weird part is we don't have a kernel tree on our gitlab at all.)
2026-06-25 08:53:53 <Ariadne> dne: that shit is why i never configure the network on any 'smart' appliance anymore
2026-06-25 08:56:06 <dne> same thing going on in many "free" mobile apps I guess
2026-06-25 08:59:39 <ikke> It's random commit and other objects being scraped as far as I can tell 
2026-06-25 09:00:56 <Ariadne> is this like when all the security companies were scraping security.alpinelinux.org instead of just calculating the reports locally
2026-06-25 09:01:22 <Ariadne> or is it more intensive than that
2026-06-25 09:02:48 <PureTryOut> ugh that is why FOSS is important, and platforms to run those FOSS apps on. Luckily Plasma Bigscreen is a thing for TV's now...
2026-06-25 09:07:48 <Sheila> I don't want a 'smart TV', I just want my TV to show what I tell it to.
2026-06-25 09:08:06 <Ariadne> you're saying the same thing
2026-06-25 09:08:55 <Ariadne> i just have a little mini pc (running alpine of course) with bluetooth keyboard/mouse thingy
2026-06-25 09:09:04 <Ariadne> running plasma
2026-06-25 09:09:10 <Ariadne> haven't tried bigscreen yet
2026-06-25 09:10:43 <Ariadne> the mini pc is weird though, it's a reject PS5 SoC
2026-06-25 09:22:59 <PureTryOut> I don't want what companies atm call a smart TV either. It's just an ad-infested and data-sucking mess.
2026-06-25 09:23:35 <PureTryOut> TV's itself should be dumb but big displays, and I'll plug in a HTPC like thing running some FOSS option like Alpine/postmarketOS with Plasma Bigscreen ;)
2026-06-25 09:45:34 <quinq> PureTryOut, correct
2026-06-25 09:46:16 <quinq> Sheila, banning sounds like a good idea
2026-06-25 09:46:35 <quinq> Maybe there could be a shared list of bad actors too, like some do for email spam lists
2026-06-25 09:48:01 <Ariadne> quinq: dronebl already seems like a reasonable mechanism for that
2026-06-25 09:48:42 <lotheac> others exist too. someone pointed out "crowdsec" to me recently
2026-06-25 09:49:33 <Ariadne> i only know dronebl because i made it originally :P
2026-06-25 09:50:04 <quinq> :D
2026-06-25 09:50:48 <quinq> Ariadne, that sounds cool
2026-06-25 09:50:56 <quinq> s/sounds/looks/
2026-06-25 09:51:47 <quinq> crowdsec “Preemptively block malicious IPs with AI-driven ultra-curated collective threat intelligence”
2026-06-25 09:51:53 <quinq> Hummm, fighting fire with fire?
2026-06-25 09:52:42 <lotheac> i'm not making a recommendation here, just pointing out that there are companies doing this as their business even in current times :p
2026-06-25 09:52:59 <quinq> https://www.crowdsec.net/pricing
2026-06-25 09:53:06 <quinq> lel
2026-06-25 09:53:25 <Ariadne> everything is AI now
2026-06-25 09:53:38 <quinq> lotheac, that's what companies do, they poison you, then sell you some drug to ease a bit the symptoms
2026-06-25 09:54:18 <Ariadne> even Edera, a hypervisor and private cloud platform company, is "AI" now
2026-06-25 09:54:27 <Ariadne> why not 
2026-06-25 09:55:08 <Ariadne> that's not a smart TV botnet, it's an AI crowdsourced download platform
2026-06-25 09:55:44 <Ariadne> It's not net abuse, it's agentic AI
2026-06-25 09:56:01 <runxiyu_> https://u.runxiyu.org/VCSCeMxN36OKLJoTryxARiqRGqeQRiM4.png
2026-06-25 09:56:39 <quinq> Ariadne, I'll add dronebl to a pf anchor
2026-06-25 09:58:02 <quinq> “Access multiple AI models without being tracked. Use the power of different LLMs, all grounded by Kagi search results, while keeping your prompts and data private.”
2026-06-25 09:58:07 <quinq> everything AI
2026-06-25 09:58:29 <Ariadne> my point being something being "AI" is not necessarily actually related to AI, it is just marketers' favorite word this cycle
2026-06-25 09:58:35 <runxiyu_> One of the proxies I use to access the internet was on dronebl a while back though :(
2026-06-25 09:59:06 <Ariadne> why wouldn't you just ssh vpn through your vps or whatever
2026-06-25 09:59:08 <quinq> runxiyu_, it's easy to unlist, it's like the third entry on the main page
2026-06-25 09:59:25 <Ariadne> not if it's an open proxy
2026-06-25 09:59:29 <quinq> ok
2026-06-25 09:59:39 <Ariadne> those get retested before being delisted
2026-06-25 09:59:44 <runxiyu_> Ariadne: Yeah, it's not an open proxy, it just so happened that the VPS IP I got was in dronebl for a while
2026-06-25 10:00:00 <runxiyu_> The GFW blocks SSH proxying though
2026-06-25 10:00:09 <quinq> What's GFW?
2026-06-25 10:00:17 <runxiyu_> Uhh, censorship mechanism 
2026-06-25 10:00:18 <Ariadne> ah, the last vps user was abusive
2026-06-25 10:00:19 <runxiyu_> in my jurisdiction
2026-06-25 10:00:20 <quinq> oh, china, right
2026-06-25 10:00:27 <quinq> :>
2026-06-25 10:02:42 <Ariadne> how the heck does the GFW pull that off
2026-06-25 10:02:48 <lotheac> sort of relatedly, but kinda opposite to an IP being on a blocklist, i'm dealing with some VPSes that are receiving traffic on their https ports that just looks like random bytes, from IPs in a specific country
2026-06-25 10:02:54 <runxiyu_> dunno but DPI
2026-06-25 10:03:46 <lotheac> or i mean, they perform the tls handshake properly but then proceed to talk to the webserver in binary. my precious access logs...
2026-06-25 10:03:56 <quinq> Ariadne, maybe a bit outdated: https://geneva.cs.umd.edu/posts/fully-encrypted-traffic/en/
2026-06-25 10:04:32 <runxiyu_> there's also gfw.report
2026-06-25 10:51:18 <june> oh hi runxiyu_ im on irc now too !!
2026-06-25 10:57:43 <tomalok> looks like the new runc-1.5.0 wants libpathrs -- no APK currently -- anyone else have that on their to-do list, or found anything else that wants it?
2026-06-25 10:57:53 <runxiyu_> o/ june!
2026-06-25 10:57:59 <runxiyu_> wait
2026-06-25 10:58:02 <runxiyu_> you use alpine now? :D
2026-06-25 11:47:13 <june> runxiyu_ well not for my desktop but i always used alpine on some of my servers !!
2026-06-25 11:47:29 <runxiyu_> nice!
2026-06-25 11:47:36 <june> i recently made !104392 and now my pds is on alpine :3
2026-06-25 11:47:37 <runxiyu_> its approximately the only linux-based system i use nowadays
2026-06-25 11:47:45 <june> woaw
2026-06-25 11:47:45 <runxiyu_> greatt
2026-06-25 11:47:50 <runxiyu_> i dont really use atproto for now to
2026-06-25 11:47:52 <runxiyu_> tho*
2026-06-25 11:48:50 <runxiyu_> june: btw, #tangled on libera might be niteresting for you
2026-06-25 11:49:08 <june> oh!
2026-06-25 11:49:16 <june> didnt know there was a libera channel thank!!
2026-06-25 11:51:16 <ptrc> aelin: thank you for the mozware time64 patch :3 applied it to latest Firefox, and it builds without issues ^^
2026-06-25 11:52:15 <fabricionaweb> there is other 2 atproto related PR sitting there !102133 and !102769
2026-06-25 11:53:43 <fabricionaweb> yes alpine is amazing, whenever I can I port/run things on it, its my sin
2026-06-25 11:55:55 <fabricionaweb> 
ACTION goes to #alpine-offtopic

2026-06-25 12:03:26 <ikke> Could someone apply it to librewolf?
2026-06-25 12:07:42 <ptrc> that's where i got it from, but it also needed some more patches
2026-06-25 12:08:10 <ptrc> and i just pushed more patches to hopefully get it to build
2026-06-25 12:11:07 <Asmadeus> Happy to help with time64 fallout if there's more, as well as I'm the culprit who asked about it on rust zulip (either ping me here or mention in the time64 enabling MR https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/508 ; but JST so might not react much during europe/american daytime)
2026-06-25 12:24:35 <Habbie> dmi, !104487 :)
2026-06-25 12:24:52 <jvoisin> lotheac: migrating to what?
2026-06-25 12:39:51 <zv> Ariadne: here is the crude hack i put in place that killed 99.99999% of bot traffic. because they always go for the commits. yes it break some things for regular users but only if browsing regular commits. the workaround for that is to remove a letter from the commit hash so that strlen() is shorter. https://paste.debian.net/plainh/e4dd4086
2026-06-25 12:41:35 <zv> part 2 sorry: https://paste.debian.net/plainh/c21f51ca
2026-06-25 12:42:23 <dmi> Habbie: tyy
2026-06-25 12:42:30 <Habbie> :)
2026-06-25 14:05:55 <lotheac> jvoisin: depending on what what you're asking -- i think migrations in general are technically interesting
2026-06-25 14:06:55 <lotheac> (because there's a lot of details in how to translate concepts from one system to another; lazy migrations just drop the ball on everything)
2026-06-25 14:11:14 <ikke> Carlo did a pretty amazing job migrating from github+redmine to gitlab
2026-06-25 14:27:52 <runxiyu> zv: im a bit confused about what you mwan
2026-06-25 14:29:31 <runxiyu> What really does strlen have to do with this?
2026-06-25 14:47:07 <zv> location ~* "/[0-9a-f]{40}/" { # detects a commit hash
2026-06-25 14:47:43 <zv> obviously not strlen literally, i was imprecise. but it matches a fixed-length commit hash, that is the secret sauce
2026-06-25 14:50:44 <runxiyu> ah
2026-06-25 15:13:03 <jvoisin> lotheac: gitlab looks like the least worse software forge around, what would you want to migrate to?
2026-06-25 15:14:43 <panekj> are you sure about that
2026-06-25 15:16:45 <quinq> sourcehut is nice
2026-06-25 15:16:54 <quinq> There's Forgejo too
2026-06-25 15:25:07 <abby> gitlab is like the twitter of forges
2026-06-25 15:25:25 <abby> "issues are work items now" "git history now goes sideways"
2026-06-25 15:26:19 <skarnet> zv: that can't be the only heuristic because people sometimes access commits directly too (e.g. linked to it from web discussions). I've done that and it creates false positives, which are annoying to remove.
2026-06-25 15:28:45 <unvFK9I3vgc> i'd give radicle a shout completely different concept, very refreshing, but also a bit young still
2026-06-25 15:31:38 <runxiyu_> I don't think radicle is what we want for the purposes of Alpine.
2026-06-25 15:32:38 <ikke> f_: I've lowered it a bit, can you check if it improved?
2026-06-25 15:32:56 <ikke> (oh, that was in #-infra)
2026-06-25 15:34:09 <jvoisin> quinq: sourcehut is email-only making it tedious to use at best, and I wouldn't put any trust in forgejo :/
2026-06-25 15:36:00 <runxiyu_> jvoisin: Any reasons about forgejo, btw?
2026-06-25 15:36:19 <runxiyu_> I'm still trying to figure out Alpine's needs specifically to see if I could possibly write something up lol
2026-06-25 15:36:31 <runxiyu_> But probably not, and I guess m ytime is better spent improving furgit in the first placve
2026-06-25 15:37:03 <zv> skarnet: it was an emergency move, 99.9999% of bots are gone, 99.9999% of normal users have no problems. either being totally offline because of bot ddos, or having something online.
2026-06-25 15:37:18 <jvoisin> runxiyu_: https://dustri.org/b/carrot-disclosure-forgejo.html + https://dustri.org/b/follow-up-to-carrot-disclosure-forgejo.html
2026-06-25 15:38:13 <skarnet> zv: sure, but please refine it now that the emergency's over, because linking to commits is useful
2026-06-25 15:38:56 <skarnet> I have a heuristic that works for cgit, but gitlab is organized differently and I'm not sure how the bots hit it
2026-06-25 15:39:48 <skarnet> jvoisin: wdym sourcehut is email-only?
2026-06-25 15:40:10 <jvoisin> skarnet: can I open a pull-request without an email client?
2026-06-25 15:40:16 <runxiyu_> ah
2026-06-25 15:40:27 <skarnet> ah, for PRs, yeah that makes sense
2026-06-25 15:40:32 <Ermine> skarnet: you send patches over e-mail here, no web-based interface for that
2026-06-25 15:40:32 <runxiyu_> yeah
2026-06-25 15:40:37 <runxiyu_> well
2026-06-25 15:40:38 <runxiyu_> actually
2026-06-25 15:40:41 <runxiyu_> yes you definitely can
2026-06-25 15:40:45 <runxiyu_> you can make a fork on git.sr.ht
2026-06-25 15:40:53 <runxiyu_> and there's a 'prepare patchset' button
2026-06-25 15:40:57 <runxiyu_> but yeah the UX is not really good
2026-06-25 15:41:04 <runxiyu_> i might try to improve that *sometime*
2026-06-25 15:41:05 <runxiyu_> also
2026-06-25 15:41:08 <runxiyu_> as much as i love builds.sr.ht
2026-06-25 15:41:14 <runxiyu_> it might not be sufficiently flexible for alpine
2026-06-25 15:41:35 <runxiyu_> also, at least insofar as git.sr.ht  uses go-git, we're still gonna have ridiculous performance hiccups
2026-06-25 15:46:05 <f_> when you need a gaming PC to render the gitlab issue textbox at a decent speed, I'm not sure what else to say
2026-06-25 15:50:43 <Sertonix[m]> I wonder if there is a forge that splits read-write access (needing login to do anything, most up-to-date) and read-only access (a public mirror that might not be up-to-date all the time). Then any DOS on the public side shouldn't effect work from being done. Any DOS with login can be traced to accounts and pausing registrations if necesarry
2026-06-25 15:50:56 <runxiyu_> good point
2026-06-25 15:51:10 <runxiyu_> f_: +1
2026-06-25 15:51:41 <ikke> read access is already quite expensive
2026-06-25 15:51:47 <ikke> For certain read operations at least
2026-06-25 15:54:52 <Sertonix[m]> some expensive operations operations that are likely only used by contributors could be behind authentication
2026-06-25 15:55:24 <f_> the scrapers are scraping for the most part git commit pages I believe?
2026-06-25 15:55:28 <Sertonix[m]> but it was just an idea
2026-06-25 15:55:50 <f_> also maybe that wouldn't work out for builders that have to pull git
2026-06-25 15:56:12 <f_> (I'm assuming they're just running regular git pull without auth)
2026-06-25 15:58:31 <runxiyu> presumably the heaviest part is serving all the stupid requests for commit pages and atuff
2026-06-25 15:58:40 <runxiyu> rather than serving the git protocol
2026-06-25 15:58:59 <runxiyu> wrt serving the git protocol
2026-06-25 15:59:10 <runxiyu> just reuse packs and deltas more aggressively ig lolvich[m] 
2026-06-25 15:59:12 <runxiyu> lol*
2026-06-25 15:59:15 <runxiyu> goguma--
2026-06-25 16:01:17 <Sertonix[m]> f_: creating read-only access tokens / keypairs for the builders/CI should be relatively simple. I just don't know if gitlab allows effective restrictions for not logged in users
2026-06-25 16:02:25 <Sertonix[m]> Or can one redirect the commit links to the plain text .patch links ;)
2026-06-25 16:02:41 <zv> skarnet: i can poke it at and share my findings another time. it isn't really high on my priorities list at the moment but i recognize it would be useful to figure out.
2026-06-25 16:02:43 <f_> .patch links need to get geberated htough
2026-06-25 16:03:04 <skarnet> zv: ack
2026-06-25 16:15:44 <quinq> That's a feature
2026-06-25 16:15:53 <quinq> No need for a full blown web browser
2026-06-25 16:16:04 <quinq> Just use the regular git cli tooling
2026-06-25 16:16:17 <quinq> (git pull requests)
2026-06-25 16:25:27 <runxiyu> i agree too and it would make my life easier
2026-06-25 16:25:35 <runxiyu> well
2026-06-25 16:25:49 <runxiyu> push to create MR is also appreciated :p
2026-06-25 16:27:59 <f_> I hate the current state of git forge hosting
2026-06-25 16:28:58 <aelin> ikke: librewolf is broken because the patch that was cherry-picked was faulty
2026-06-25 16:29:14 <aelin> if it is replaced with the one on my branch it should build fine
2026-06-25 16:29:31 <aelin> I believe Hugo just didn't see that I had updated it because of the GitLab issues
2026-06-25 16:30:28 <f_> thanks for fixing librewolf on armv7, aelin ^^
2026-06-25 16:30:56 <aelin> firefox has the correct version of the patch
2026-06-25 16:32:18 <runxiyu_> f_: send me a list of complaints
2026-06-25 16:33:05 <f_> gitlab has quite good features (namely: CI, MR workflow) that would be hard to move away from, that many other forges (github, forgejo, sourcehut) don't have
2026-06-25 16:33:20 <f_> but at the same time gitlab is slowing down to a crawl
2026-06-25 16:34:22 <jvoisin> AI FIST
2026-06-25 16:34:31 <jvoisin> can't wait for the bubble to pop.
2026-06-25 16:34:48 <f_> and honestly I feel like I and other users are not being heard
2026-06-25 16:35:43 <f_> when you rename issues to work items and then give people the opportunity to give feedback, you should listen to the feedback, not just be like "oh you'll get used to it"
2026-06-25 16:36:06 <f_> especially when the first page of your feedback thing says "we will listen to the feedback"
2026-06-25 16:37:18 <f_> a clone of Jira/bitbucket isn't what I want, gitlab
2026-06-25 16:37:33 <f_> (and what many foss projects want)
2026-06-25 16:39:26 <iggy> gitlab does not care what open source projects (or developers) want
2026-06-25 16:40:19 <iggy> some product owner/consultant/big enterprise told them it was a good idea and they're going to run with it
2026-06-25 16:40:37 <f_> iggy: oh now it's AI
2026-06-25 16:41:13 <runxiyu> CI yeah
2026-06-25 16:41:20 <runxiyu> what really about gitlab's MR workflow ThomasRoche[m] 
2026-06-25 16:41:23 <runxiyu> goguma--
2026-06-25 16:41:25 <runxiyu> im so sorry
2026-06-25 16:41:32 <f_> goguma really loves matrix users
2026-06-25 16:42:20 <f_> runxiyu_: well for example blocking threads in MRs, that prevent the MR from being merged
2026-06-25 16:46:40 <runxiyu> oh
2026-06-25 16:46:42 <runxiyu> lol alright
2026-06-25 19:47:59 <aelin> here's the librewolf fix: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/104515
2026-06-25 19:51:29 <Habbie> mio, i see you edited my commit message in !104493, is the format from abump -s not preferred?
2026-06-25 19:53:55 <mio> Habbie: the CVE list is a bit long, probably better to fit in the commitmsg body
2026-06-25 19:54:00 <Habbie> right, fair
2026-06-25 19:54:04 <Habbie> this is going to be a theme this year
2026-06-25 22:33:48 <lotheac> jvoisin: migrate to what exactly, i'm not sure about :) would need to try things out more
2026-06-26 07:35:09 <fabricionaweb> Hi, good morning, I have some PR stale !102133 !102769
2026-06-26 08:32:59 <f_> hi, can we get !104308 merged without waiting on clayton? He's on holiday and he actually had told me to tag that unudhcpd release and push the update to aports
2026-06-26 08:43:35 <lotheac> sure... if i can get gitlab to do it :)
2026-06-26 08:52:46 <f_> :(
2026-06-26 08:53:01 <f_> "HTTP(s) gitlab.alpinelinux.org Unreachable"
2026-06-26 08:58:05 <lotheac> yeah, it doesn't seem to want that merged :)
2026-06-26 08:59:02 <f_> I'd hate it when I can't get anything done because gitlab is down because of AI scrapers
2026-06-26 08:59:22 <f_> but thanks for trying at least
2026-06-26 09:14:23 <ikke> 😔
2026-06-26 09:15:46 <runxiyu> honestly i dont think "gitlab scales horizontally when you add more servers and admins" is a great reason to keep using gitlab for us
2026-06-26 09:16:18 <craftyguyawayuntilJuly9[m]> I can't sign in rn to approve, but I approve 😁
2026-06-26 09:18:38 <ikke> runxiyu: the way we use gitlab right now does not make the migration to other systems simple
2026-06-26 09:19:00 <f_> runxiyu: I don't think it's purely a gitlab issue. Even cgit is having issues
2026-06-26 09:19:18 <f_> they managed to take it down completely
2026-06-26 09:20:14 <f_> craftyguyawayuntilJuly9[m]: thx, hope you're having good holidays too :P
2026-06-26 09:26:25 <runxiyu> f_: ive found that cgit really doesnt like mass scrapers
2026-06-26 09:26:29 <runxiyu> im not sure why though
2026-06-26 09:26:41 <runxiyu> and i dont think i could trivially blame it on cgi
2026-06-26 09:26:46 <runxiyu> ill need to benchmark ofc
2026-06-26 09:26:51 <runxiyu> ikke: makes sense, yeah
2026-06-26 10:52:18 <ikke> gitlab is back for now
2026-06-26 10:56:41 <quinq> gg
2026-06-26 10:58:37 <zv> my anecdotal impressions of cgit vs. scrapers is that there are several compounding factors. (1) syntax highlighting, (2) stuck processes or slow scrapers, (3) excessive cpu usage. ultimately leading to resource exhaustion
2026-06-26 10:59:06 <zv> as for mitigations i haven't had time to look into it so i disabled the two cgit instances we host
2026-06-26 11:29:39 <staceee> hey folks, can someone could have a look at !99286 please ~
2026-06-26 11:48:33 <f_> thank you mio !
2026-06-26 11:49:51 <mio> :) thanks to lotheac as well for rebase
2026-06-26 11:50:09 <mio> you're welcome
2026-06-26 11:51:21 <f_> yep thanks lotheac as well :)
2026-06-26 11:51:24 <f_> you're both awesome
2026-06-26 12:19:10 <quinq> Hi, it seems that libpsl is broken on edge/amd64
2026-06-26 12:19:17 <quinq> lto1: fatal error: bytecode stream in file '/usr/lib/gcc/x86_64-alpine-linux-musl/15.2.0/../../../../lib/libpsl.a' generated with LTO version 14.0 instead of the expected 15.1
2026-06-26 12:19:21 <quinq> compilation terminated.
2026-06-26 12:34:47 <sam_> the best way to handle these would be using something like i've done on our side (dot-a.eclass)
2026-06-26 12:35:00 <sam_> the gist is that for anything w/ static-libs (at least where LTO is being used), you build w/ -ffat-lto-objects and strip the LTO parts at the end
2026-06-26 12:54:36 <Sertonix[m]> quinq: Current approach is to bump pkgrel if somebody needs it.
2026-06-26 12:59:29 <lotheac> mio: oh heh didnt know that rebase completed
2026-06-26 14:40:02 <skarnet> fwiw I know how to harden cgit against scrapers, but my solution works with inetd-like web servers, not monolithic ones
2026-06-26 14:40:59 <skarnet> but it could probably be adapted if the server can reload its config fast
2026-06-26 20:07:14 <Biswa96[m]> would it be possible to review this MR please? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103478
2026-06-26 20:46:30 <Saijin_Naib[m]> If anyone has bandwidth, I would really appreciate a review of !97292 !97494 !99156
2026-06-26 21:13:55 <WhyNotHugo> What's the blockage is moving to `maintainer=` instad of `# Maintainer=`?
2026-06-26 21:23:53 <Sertonix[m]> The TSC proposal included additional changes that were more controvercial (dropping contributor comments), causing it to get stalled. I think to get peoples opinions to see if there is a consent would require creating a new proposal with a smaller scope.
2026-06-26 21:24:32 <WhyNotHugo> I can see how scoping in the Contributor comment would stall things.
2026-06-26 21:25:00 <WhyNotHugo> Reminds me of straightforward legislation getting stalled because somebody adds a last minute clase at the bottom "… and also let's ban abortion", or something close.
2026-06-26 21:25:24 <WhyNotHugo> (not that I'm comparing the two examples, to be clear0
2026-06-26 21:34:57 <Sertonix[m]> WhyNotHugo: Do you have motivation to write the proposal? I could proof read it before submitting. Old proposal is https://gitlab.alpinelinux.org/alpine/tsc/-/work_items/88
2026-06-26 21:44:36 <skarnet> if you're making syntax changes to APKBUILDs, please also provide a script that converts to the new syntax. The price of simplifying automation should not be work for human maintainers. We should be able to also use automation to conform to the new syntax.
2026-06-26 21:45:12 <skarnet> of course if these were semantics changes that would be different, but here it just looks like churn
2026-06-26 21:54:00 <Sertonix[m]> Hm, that does sound like a good (and relatively simple to implement) idea.
2026-06-26 22:34:01 <WhyNotHugo> sed -E 's/# Maintainer: (.*)/maintainer="\1"/'
2026-06-26 22:36:22 <WhyNotHugo> Co-Authored-By: busybox sed 1.38.0
2026-06-26 22:41:21 <Sertonix[m]> That has some issues, I am working on something
2026-06-26 22:45:26 <WhyNotHugo> Sertonix[m]: https://paste.sr.ht/blob/7ab24b76039142ed6fcdb6cf1c53c778c3cce50e
2026-06-26 22:58:46 <Sertonix[m]> Here: https://codeberg.org/sertonix/alpine-scripts/src/branch/main/abuild-maintainer2var
2026-06-26 22:59:59 <Sertonix[m]> bug-by-bug compatibility, removal of duplicate maintainer lines and sanitychecks
2026-06-26 23:01:16 <WhyNotHugo> I'll link to that with the same disclaimer: acceptance of the propsal does imply acceptance of the script.
2026-06-26 23:01:27 <WhyNotHugo> Mostly to avoid getting tangled up on discussions on the implementation.
2026-06-26 23:04:50 <jvvv> Sorry, I just comming in to the discussion about maintainer comment vs var discussion rn. Is there a push to make one preferred over the other? I don't have an opinion, really. I just ask because I coudld easy change all of mine to align with current preference in a few bulk MRs.
2026-06-26 23:05:42 <Sertonix[m]> WhyNotHugo: IMHO we can drop the history lesson (both at the start and end) and just ref the old issues, there were not really discussions about the maintainer variable. I would prefer "replace" instead of "deprecate", sounds less scary.
2026-06-26 23:06:46 <Sertonix[m]> jvvv: There is no real value in bulk changing you aports. A new proposal is in the making.
2026-06-26 23:08:27 <jvvv> Ok, thanks. Main reason I ask is that most or all of aports I maintain have both comment and variable, so scripts meant to change mine might choke in such a case, idk.
2026-06-26 23:09:33 <Sertonix[m]> I made sure to consider that case
2026-06-26 23:11:14 <jvvv> Great. Thanks
2026-06-26 23:11:51 <skarnet> Sertonix[m]: thanks.
2026-06-27 00:51:55 <WhyNotHugo> apkbrowser flags a package as out of date. Local version is 3.052, but anitya's last version is 3.052R. The "R" cannot be represented in aports, can we somehow indicate that this package shouldn't be flagged?
2026-06-27 08:42:47 <Ariadne_> WhyNotHugo: i think it can be, actually.  we used to do so with openssl before they adopted a more traditional version scheme
2026-06-27 09:56:34 <runxiyu_> Does alpine run a debuginfod server?
2026-06-27 09:56:40 <runxiyu_> Or can I MR to enable -dbg for firefox?
2026-06-27 10:03:21 <ptrc> isn't it already enabled on most architectures?
2026-06-27 10:03:52 <ptrc> yeah, only 32-bit and rv64 don't have -dbg, because having debug symbols increases resources needed to build
2026-06-27 10:04:15 <ptrc> and our rv64 builder already struggles with firefox x.x
2026-06-27 10:04:41 <ptrc> > elapsed time 8h 24m 49s
2026-06-27 10:12:29 <runxiyu_> right
2026-06-27 10:12:38 <runxiyu_> im stupid, it does have -dbg on my arch
2026-06-27 10:12:42 <runxiyu_> i was looking at the wrong listing
2026-06-27 10:17:09 <f_> "rv64 builder already struggles" is a common theme :P
2026-06-27 10:17:16 <WhyNotHugo> Ariadne: do you remember how? 😅
2026-06-27 10:18:10 <ikke> 1.2.3r is allowed
2026-06-27 10:18:23 <WhyNotHugo> Is Firefox even usable on riscv64? Given the build performance I keep seeing, I can't imagine actually using it.
2026-06-27 10:19:17 <f_> firefox is usable on my armv7 tablet which .. I believe, despite being 14 years old, might be .. slightly faster than the fastest riscv64 hw out there
2026-06-27 10:19:30 <f_> than some of the faster riscv64 hw*
2026-06-27 10:19:54 <f_> (assuming many are about as fast as a Pi2, which my tablet does outperform)
2026-06-27 10:20:08 <f_> so, probably not :^)
2026-06-27 10:20:53 <WhyNotHugo> I question the value of packaging something that won't even run on existing hardware. Especially when we wait 8hs to know if it builds and struggle with build failures like this
2026-06-27 10:21:06 <WhyNotHugo> I do see the value in finding issues in upstream tbf
2026-06-27 10:21:09 <WhyNotHugo> But still
2026-06-27 10:21:19 <f_> I'd guess it may run on one of those 64 core riscv64 hardware out there
2026-06-27 10:21:21 <ptrc> honestly this kind of stuff is why i wish we had some equivalent of popcon
2026-06-27 10:21:34 <ptrc> just so we can see how many people actually download a package on a given arch
2026-06-27 10:22:26 <f_> WhyNotHugo: personally I just disable packages that take ages to compile on riscv64 to not put more strain on builders
2026-06-27 10:22:41 <f_> regardless of if it actually does run fine on such lowend hardware
2026-06-27 10:23:23 <WhyNotHugo> Tempted to do so with librewolf: if nobody complains, then nobody's using it?
2026-06-27 10:24:44 <WhyNotHugo> Is there some way to apply an MR locally, push to master **and** have GitLab properly mark it as merged rather than closed?
2026-06-27 10:27:42 <f_> WhyNotHugo: fwiw, this is just a guess based on what I heard from other people
2026-06-27 10:27:51 <f_> I don't actually own rv64 hardware
2026-06-27 10:29:03 <f_> I think Pi3-like (performance-wise, so I guess the 64-core rv64 boards) might be able to run firefox okay?
2026-06-27 10:29:11 <f_> ¯\_(ツ)_/¯
2026-06-27 10:30:46 <f_> I'm just guessing
2026-06-27 10:41:50 <lotheac> fwiw as i understand it alpine would love to have more rv64 builder capacity, optimally faster than now
2026-06-27 10:42:34 <lotheac> hardware exists now but it is very hard to buy in my experience
2026-06-27 10:43:18 <lotheac> s/hardware/faster hardware/
2026-06-27 10:47:16 <Sertonix[m]> WhyNotHugo: Disabling stuff on riscv64 supports a "nobody is using riscv64, meaning nobody improves riscv64, meaning nobody is using riscv64..." spiral.
2026-06-27 10:48:43 <Sertonix[m]> And it seems unlikely that people held back by the current state of packaging complain, more likely that they go elsewhere
2026-06-27 10:50:34 <realroot[m]> >According to Crush from Arace: Milk-V Titan is expected to be shipped in early July.
2026-06-27 10:50:34 <realroot[m]> riscv64
2026-06-27 10:52:52 <WhyNotHugo> Alpine missing in "Future OS Support":https://milkv.io/titan Can we do anything to get it there?
2026-06-27 10:56:25 <quinq> Hi
2026-06-27 10:56:28 <quinq> Need gitlab help :/
2026-06-27 10:56:34 <quinq> I updated a patch
2026-06-27 10:56:37 <f_> what's your gitlab emergency today?
2026-06-27 10:56:41 <quinq> :>
2026-06-27 10:57:07 <quinq> I pushed it again to my remote clone in gitlab (git push -f)
2026-06-27 10:57:20 <quinq> It answered me correctly:
2026-06-27 10:57:21 <quinq> remote: View merge request for aports:
2026-06-27 10:57:21 <quinq> remote:   https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/103957
2026-06-27 10:57:26 <quinq> But the patch hasn't changed at all
2026-06-27 10:57:54 <f_> quinq: it takes a bit of time I believe
2026-06-27 10:58:03 <WhyNotHugo> quinq: GitLab will show stale data while it pregenerates that information in the background.
2026-06-27 10:58:12 <quinq> Oh wait, now a new thing suddenly appeared (after 5 minutes)
2026-06-27 10:58:20 <quinq> But it didn't change the commit
2026-06-27 10:58:24 <quinq> It just added a new one?
2026-06-27 10:58:36 <WhyNotHugo> TBF, this bothers me tremendously, since I'm not 100% certain that what I'm merging is what I'm seeing.
2026-06-27 10:58:47 <quinq> Yeah
2026-06-27 10:59:01 <quinq> Ah ok… It changed the commit… But not the MR title (that is the commit title)
2026-06-27 10:59:25 <quinq> Lel, even the commit message body hasn't changed
2026-06-27 10:59:29 <quinq> Is that actually expected?
2026-06-27 10:59:49 <quinq> Am I supposed to manually modify the “MR message” (whatever that means)?
2026-06-27 11:01:23 <WhyNotHugo> Sertonix[m]: https://paste.sr.ht/blob/39e6b7228afbf2b2679b2806fd1c67521ca6a713
2026-06-27 11:05:38 <quinq> Erf, gitlab is breaking the comment message format
2026-06-27 11:05:43 <quinq> It reflows everything on a single line
2026-06-27 11:06:56 <Sertonix[m]> WhyNotHugo: Sounds good enough
2026-06-27 11:07:39 <Sertonix[m]> quinc: I commonly reformat the message for gitlab. linebreaks that are intentional can be fixey with a backslash at the end of the line
2026-06-27 11:14:32 <quinq> Are there really unintentional newlines in messages usually?
2026-06-27 11:14:48 <quinq> I'd think the majority are *intentional* newlines, way over unintentional ones
2026-06-27 11:14:51 <quinq> Sounds like a weird default
2026-06-27 11:14:54 <WhyNotHugo> gitlab comments are markdown.
2026-06-27 11:15:17 <WhyNotHugo> Personally, I often write long comments with code blocks in vim and copy-paste, and the behaviour is very fitting for this case.
2026-06-27 11:15:54 <quinq> Long comments as in without newlines?
2026-06-27 11:21:16 <WhyNotHugo> As in prose with full paragraphs rather than short lines.
2026-06-27 11:21:59 <quinq> I see, you're writing a novel :D
2026-06-27 11:22:19 <quinq> I'm more inclined to semantic line-breaks
2026-06-27 11:22:47 <quinq> We have LLM for over-written comments
2026-06-27 11:24:11 <WhyNotHugo> If you write with semantic line breaks, doesn't the markdown reflow render properly?
2026-06-27 11:24:17 <WhyNotHugo> Or do you expect this to be rendered this wy too?
2026-06-27 11:25:07 <quinq> Yes, I expect what I write to be rendered the way I write it :)
2026-06-27 11:25:28 <quinq> And yes it does reflows, that's my initial message
2026-06-27 11:27:51 <WhyNotHugo> I thought usually semantic line-breaks were and editor thing, but not intended to be rendered as such. You need to add two spaces at the end of the line to opt-out of the usual reflow.
2026-06-27 11:28:06 <WhyNotHugo> FWIW, man/mdoc does the same.
2026-06-27 11:28:47 <quinq> I did it with the escape character like Sertonix[m] suggested, thanks :)
2026-06-27 11:30:49 <quinq> A bit weird again that for getting your actual newline, you have to escape it
2026-06-27 11:30:52 <quinq> But it werks
2026-06-27 12:25:50 <Noisytoot> <f_> I think Pi3-like (performance-wise, so I guess the 64-core rv64 boards) might be able to run firefox okay?
2026-06-27 12:25:58 <Noisytoot> does firefox parallelize that well?
2026-06-27 13:02:02 <f_> Dunno.
2026-06-27 15:00:42 <witcher01> forgejo-lts is on v11 on Alpine stable v3.24, but that version is EoL on 2026-07-16. how do we handle such a case? are major updates for a stable release allowed in this case?
2026-06-27 16:05:54 <elagost> can I use an `install` function in a subpackage in an APKBUILD? apkbuild-lint says 'Add install scripts to global install variable instead'
2026-06-27 16:16:43 <JustSouptheyhe[m]> elagost: Do you mean a function named install?
2026-06-27 16:32:57 <Sertonix[m]> The "install" variable should be set in the global shell environment. changing it in a split function results in issues
2026-06-27 16:33:46 <Sertonix[m]> The name of the file indicates the (sub)package it belongs to
2026-06-27 16:36:31 <elagost> Thanks Sertonix[m] I will do that.
2026-06-27 17:04:00 <jvvv> Is the edge riscv64 builder really still building mlt? I know the status page shows the builder as "LOST", so maybe it is just not showing.
2026-06-27 17:41:55 <witcher01> i had a look at searxng today which has a rolling release model and versions their software YYYY.MM.DD+githash. is it possible to represent this scheme in the pkgver variable?
2026-06-27 17:42:54 <witcher01> specifically, the pkgver variable mentions the only valid format as "{digit}{.digit}...{letter}{_suf{#}}" which this doesn't fit into. would a workaround as "0.0.0_gitYYYYMMDD" be acceptable in such a case?
2026-06-27 17:44:07 <witcher01> are packages with a "rolling release" model even acceptable at all in testing/community? they have not and are not planning on making any releases
2026-06-27 17:46:46 <DylanVanAssche> I receive HTTP 504 when pulling master from aports. AFAIK there's no maintenance going on?
2026-06-27 17:53:19 <f_> witcher01: I would go with 0_gitYYYYMMDD
2026-06-27 19:28:42 <witcher01> f_: thanks
2026-06-27 21:54:07 <Ariadne> WhyNotHugo: letters in $pkgver should just work
2026-06-27 21:55:12 <Ariadne> the letters *may* have to be lowercase though
2026-06-27 21:58:51 <Ariadne> look at tzdata it is another package that uses letters in $pkgver
2026-06-28 04:58:43 <strangeperson> hello! Tuwunel's build job gets killed for loongarch64 because "The script exceeded the maximum execution time set for the job" in !103586. can somebody help?
2026-06-28 05:05:42 <ikke> strangeperson: you can increase the timeout in the CI/CD settings of your project
2026-06-28 05:20:31 <strangeperson> ikke: thank you
2026-06-28 13:00:01 <WhyNotHugo> Ariadne: I think using a lowrcase letter will still result in a mismatch in apkbrowser…
2026-06-28 13:00:09 <WhyNotHugo> ALthough case-normalisation does seem reasonable there.
2026-06-28 13:13:47 <Newbyte> Are the default subpackages supported by abuild (like dbg, doc, dev) documented anywhere? Hard to find any substantial documentation for abuild.
2026-06-28 13:30:21 <quinq> Newbyte, it's not explicitly documented, but the “Special Variables” section of APKBUILD(5) gives you a list
2026-06-28 13:30:43 <Newbyte> I ended up just reading abuild's source code but thank you!
2026-06-28 13:31:14 <quinq> Works too
2026-06-28 13:37:47 <Newbyte> Why is default_lang() located about a thousand lines of code before the other default subpackage functions
2026-06-28 13:46:07 <Sertonix[m]> It looks like it was added close to other lang related functions that have since been removed
2026-06-28 15:01:53 <Newbyte> <Sertonix[m]> "It looks like it was added close..." <- I opened an MR to move it to the other default functions: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/520
2026-06-28 15:03:01 <Sertonix[m]> Not sure if refactoring that is worth messing up git blame
2026-06-28 15:06:00 <achill> could this git blame ignore file help?
2026-06-28 15:31:27 <Newbyte> You're welcome to close it if you value simpler git blame over more self-documenting code
2026-06-28 15:32:20 <Newbyte> But as Achill is hinting to I think GitLab recently got support for some sort of blame ignore thing
2026-06-28 16:50:24 <ekatwired> Hello everynyan. Currently building a program which uses libapk and when I load database it of course load like 12 megs for caches, that is okay but when I do "apk_db_close" I still get the 9 extra megs in the memory.
2026-06-28 16:51:05 <ekatwired> Most of the allocations I saw were from balloc functions but close should free them, right?
2026-06-28 17:01:26 <quinq> ekatwired, out of curiosity, do you have a small code example?
2026-06-28 17:31:51 <ekatwired> quinq: I would have to SSH to place from phone but is is basically:ctx init, db open, db close and i still have the memory leftover.
2026-06-28 18:15:58 <witcher01> Sertonix[m]: "git blame -M" should recognize that lines moved and not display the commit that moved them
2026-06-28 20:59:42 <ekatwired> quinq: ah it was just memory fragmentation
2026-06-28 21:04:20 <quinq> Thanks for the follow-up, ekatwired :)
2026-06-28 23:07:49 <infinitywisdom[m]> I lost the bookmark to something I need. Does anyone have the link to the setup-alpine and setup-desktop software within the alpine linux installer?
2026-06-29 08:26:16 <fabricionaweb> Hi, I have some PR sitting stale for a while !102133 and !102769
2026-06-29 09:51:11 <raspbeguy> Hello, here are some MR ready for merge !101252 !102731 !102954 !102955 !103900 !104608
2026-06-29 09:53:54 <fabricionaweb> ok you are bigger
2026-06-29 11:15:39 <Antiz1> Don't wanna start a fight, but I got some under my belt too 👀 😝
2026-06-29 11:16:29 <Antiz1> !99824 !99837 !104345 !102477
2026-06-29 11:16:46 <Antiz1> In case anyone happens to have time for those 🤗
2026-06-29 11:51:35 <Antiz1> WhyNotHugo: Thanks for diffoci MR ;) To answer your interrogation, I doubt the Alpine image is reproducible unless you did some work on that matter. As a reference here's the work I've done to make the Arch Linux OCI image reproducible:  
2026-06-29 11:51:59 <Antiz1> https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/96
2026-06-29 11:52:15 <Antiz1> (Or part of the work that is, there's more to it actually)
2026-06-29 11:53:01 <Antiz1> Basically normalizing timestamps for the whole rootFS, get rid of non-essential non-determistic bits, etc... 
2026-06-29 11:53:37 <Antiz1> I'm generally invested in the reproducible builds effort in Arch Linux (and beyond). Happy to help on the Alpine side if that ever becomes a subject there :)
2026-06-29 11:54:05 <Antiz1> cc kpcyrd ( 👋 ) who'se also deeply invested in RB :)
2026-06-29 12:10:07 <Antiz1> WhyNotHugo: I addressed all your comments, thanks for the reviews! 🤗
2026-06-29 15:44:29 <noelle> I'm new to building Alpine packages, and I'm trying to build the musl package locally on Alpine 3.24. I cloned the aports repo on the 3.24_stable branch, cd to main/musl, ran `abuild -r`. The .apk file I get only has one file in it: lib/ld-musl-aarch64.so.1. I expect to also find /lib/libc.musl-aarch64.so.1, but it's not there. Why?
2026-06-29 15:45:29 <noelle> Specifically, I want to have the debug symbols for libc.musl-aarch64.so.1, since for some reason they aren't included in the published `musl-dbg` package.
2026-06-29 15:46:29 <ikke> noelle: /lib/libc.musl-aarch64.so.1 is a symlink to /lib/ld-musl-aarch64.so.1.
2026-06-29 15:47:15 <ikke> /lib/libc.musl-aarch64.so.1 -> ld-musl-aarch64.so.1
2026-06-29 15:47:25 <ikke> /lib/libc.musl-aarch64.so.1 is owned by musl-1.2.6-r2
2026-06-29 15:49:09 <noelle> ikke: So it is, thank you!
2026-06-29 20:35:34 <Antiz1> https://gitlab.alpinelinux.org/Antiz/aports/-/jobs/2415891 <-- It seems like libstemmer 3.1.1 rebuild for tinysparql (https://gitlab.alpinelinux.org/alpine/aports/-/commit/96c4ad046da1c92dfac4b624d4396564c9ffeaf6) didn't properly landed in risc-v6
2026-06-29 20:35:52 <Antiz1> riscv64*
2026-06-29 20:35:55 <Antiz1> (edge branch)
2026-06-29 20:54:28 <Sertonix[m]> riscv64 is ~300 packages behind, might take a while before it has cought up: https://build.alpinelinux.org
2026-06-29 20:58:38 <Antiz1> Sertonix[m]: Right, I haven't thought of checking build.al.org. Thanks :)
2026-06-29 20:59:17 <jvvv> If the riscv64 edge builder were a person, I would feel bad for it. Always heaped up with work with never an end seeming to be in sight. It is like the little engine that could (well, eventually, it will, but don't hold your breath or you will pass out).
2026-06-30 06:26:17 <ncopa> the build-edge-riscv64 machine (a hifive premiere p550) deadlocked again. I have powercycled it and are now trying to manually run abuild for completeing firefox-esr
2026-06-30 06:26:59 <ikke> 😔
2026-06-30 06:27:47 <ncopa> i have set up some monitoring. it may be it got overheated? I have set the fan to be slow to make it more silent
2026-06-30 06:27:55 <ncopa> it sits under my desk...
2026-06-30 18:43:51 <witcher01> what's the rule for license files in packages? i assume they should always be packaged for all packages?
2026-06-30 19:09:49 <achill> they are only required for MIT or ISC, but it also doesn't hurt with other licenses
2026-06-30 19:10:14 <achill> its basically the legal requirement of licenses containing "The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software."
2026-06-30 19:23:36 <jvvv> achill: That brings up a point I have been intending to ask about. A lot of the python packages I have dealt with often install licenses in with the python directories. Would it make sense to symlink to these, like to usr/share/licenses/$pkgname ?
2026-06-30 19:24:48 <jvvv> Sorry, I meant to add a pseudo license file name to the end of that path
2026-06-30 19:25:48 <jvvv> I haven't worried about, since if the license is installed, that should cover topics like the MIT and ISC requirements
2026-06-30 20:08:30 <achill> i think if the license is anywhere in the package, its fine
2026-06-30 20:23:26 <JustSouptheyhe[m]> Isn't the logic to have it under /usr/share/licenses/$pkgname so its picked up by the *-docs splitfunc? Unless the splitfunc can also figure it out under the python install paths.
2026-06-30 20:47:42 <jvvv> If someone has time, would they please review !103066
2026-06-30 21:11:41 <roselandgoose> I'm starting to suspect that `apk audit /etc/init.d` is broken
2026-06-30 21:13:00 <roselandgoose> can anyone test this, by editing a file in there and running the audit. On both of my machines, only new symlinks are listed in the audit, not changed files
2026-06-30 21:13:25 <roselandgoose> one is usr-merged and one isn't.
2026-06-30 21:13:28 <roselandgoose> edge
2026-06-30 21:14:34 <roselandgoose> apk-tools 3.0.6-r0
2026-06-30 21:18:37 <roselandgoose> ah, hmm.. is this intended behavior?
2026-06-30 21:19:09 <roselandgoose> --full includes the files in question...
2026-06-30 21:19:49 <roselandgoose> but I don't (yet) see this documented anywhere, and its not comming from /etc/apk/protected_paths.d/
2026-06-30 21:24:11 <roselandgoose> hmm, I'm guessing this is intended..
2026-06-30 21:24:13 <roselandgoose> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/database.c#L2102
2026-06-30 21:24:46 <roselandgoose> except.. as a result, update-conf automatically overwrites "unchanged" initd's
2026-06-30 21:25:26 <roselandgoose> even when -i is _not_ used
2026-06-30 21:53:35 <roselandgoose> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/work_items/10657
2026-06-30 22:08:36 <Sertonix[m]> IIRC editing regular files in /etc/init.d is not supposed to be done.
2026-06-30 22:11:19 <Sertonix[m]> *packaged regular files
2026-06-30 22:30:00 <jvvv> That was my understanding also and should probably have mentioned that to roselandgoose in #alpine-linux channel
2026-06-30 22:30:45 <jvvv> Also the reason I suggested creating a locally modified initd service file to suite specific needs
2026-06-30 22:34:03 <jvvv> Sorry, roselandgoose, I think I dropped the ball on that one