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