2025-02-01 00:26:59 <mio> ovf: not stuck as in frozen, there's an aport having trouble fetching from api.nuget.org
2025-02-01 00:27:35 <mio> infra is aware and working on it, possibly a peering issue
2025-02-01 00:29:22 <mio> the affected builders can still build other aports in the meantime, just testing aports aren't synced up at the moment
2025-02-01 00:30:08 <mio> just on those two arches on edge
2025-02-01 06:55:47 <ikke> fancsali[m]: If you are building locally and testing it, you can always provide --available to make apk upgrade to the newly built package without bumping pkgrel
2025-02-01 08:55:45 <Wyk72> hello everyone
2025-02-01 08:56:40 <Wyk72> just chiming in to ask for the status of the VDO/KVDO (Virtual Data Optimizer) packages in Alpine, if it was ever considered
2025-02-01 10:54:52 <fancsali[m]> <ikke> "fancsali: If you are building..." <- Hm, that's a option...
2025-02-01 10:54:52 <fancsali[m]> ... but what if I am working on kernel packages, and want to test them on a live USB.
2025-02-01 10:54:52 <fancsali[m]> I might need to flip my workflow...
2025-02-01 14:44:27 <nangel> lol.   updating kamailio to v6.0.0 and abuild reports the -doc subpackage is unusually large.
2025-02-01 14:45:52 <nangel> kamailio adds 45.1M to the running system, in 46 different packages.
2025-02-01 16:15:46 <donoban> hmm.. wanted to check that I discovered that apk ignores the '-i' option if you aren't root
2025-02-01 16:16:31 <donoban> ah, it ignores if you pass the --simulate option
2025-02-01 16:17:29 <donoban> nangel: here it adds 18MiB https://tpaste.us/JNj0
2025-02-01 16:17:48 <donoban> ah, you mean the next version
2025-02-01 16:18:02 <donoban> so it looks weird yeah
2025-02-01 16:33:08 <nangel> donoban - There's a reason for 5.X.y to 6.0.0.  Following kamailio since 1.5.0 through today, it is just a weird beast
2025-02-03 03:20:05 <ayakael> Good evening, would someone be so kind as to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79125
2025-02-03 03:24:57 <lotheac> ptrc: could you take a look at !79157 and !78838 when you get a chance? thanks!
2025-02-03 03:33:32 <ayakael> (!79125)
2025-02-03 05:00:05 <qaqland> i want to bump this port !79331, besides "apk search -r libgit2.so", do other packages need to be rebuilt?
2025-02-03 05:23:51 <j_v> qaqland: apk search -r so:libgit2.so
2025-02-03 05:24:03 <j_v> ooops
2025-02-03 05:24:19 <j_v> sorry, read it but didn't let it sink in
2025-02-03 06:01:08 <ikke> qaqland: that list appears to be complete
2025-02-03 06:07:48 <qaqland> thanks
2025-02-03 07:47:23 <qaqland> ncopa: there is a test issue about !78989 (my friend doesn't use irc, so i fwd it) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78989#516f644755e63ec50434bd1db30c53c873151915
2025-02-03 08:35:34 <qaqland> about half of rust package link to libgit2.so still use old version, can I set them all use bounded libgit2?
2025-02-03 08:36:33 <qaqland> 
ACTION 's grammar seems wrong

2025-02-03 10:21:12 <qaqland> 
ACTION not bounded but vendored

2025-02-03 13:35:35 <fabricionaweb> except for the branch - I did run on 3.21 instead of master - and for a single CVE comment - why Jirutka's pipeline passed and mine didnt ??? I dont get it :(
2025-02-03 13:35:49 <fabricionaweb> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79063/diffs vs https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79349/diffs
2025-02-03 13:36:46 <fabricionaweb> ok its not over yet still running
2025-02-03 14:08:43 <fabricionaweb> yeah great, now its over and it have passed, tho we made the same same changes LOL I really dont get it 🤷maybe was some dep from 3.21 
2025-02-03 15:35:14 <kaey_> merge please !77477. Or do i have to mark discussions as resolved myself?
2025-02-03 17:05:16 <qaqland> all repositories about testing/elektra has been archived, maybe we can drop this port
2025-02-03 17:05:24 <qaqland> https://github.com/ElektraInitiative/libelektra
2025-02-03 17:09:12 <qaqland> 
ACTION s/has/have

2025-02-03 18:25:40 <craftyguy[m]> any chance we could get a review on !79242? thanks :D
2025-02-03 19:52:05 <craftyguy[m]> regarding the loss of hosting from equinox, pmOS has had a great experience with hosting from OSUOSL so far. it's a university that has been around for decades, many FOSS projects use them (including linux.org at one point). Not sure if Alpine has considered submitting an application to them, but the worst that could happen is they say "no" :)
2025-02-03 19:52:26 <craftyguy[m]> s/linux.org/kernel.org/ heh
2025-02-03 19:57:33 <fossdd[m]> afaik the ppc builders are from OSUOSL but i might be mixing things
2025-02-03 19:57:55 <ikke> Yup
2025-02-03 19:58:32 <clandmeter> kernel.org is using the same resources as us
2025-02-03 19:58:46 <clandmeter> fastly and equinix...
2025-02-03 19:58:55 <clandmeter> I guess they are also looking for alternatives
2025-02-03 20:00:17 <fossdd[m]> so many open source projects depending on the same handful of sponsors is not great..
2025-02-03 20:01:01 <fossdd[m]> there are so many companies relying on these projects, in comparison to how many actually sponsor stuff, its terrible
2025-02-03 20:01:13 <Forza> I was thinking the same. But it is perhaps hard to spread out too? 
2025-02-03 20:01:35 <ikke> By joining open collective, we hope to be less reliant on specific sponsors
2025-02-03 20:02:00 <clandmeter> kind off, but we have a long way to go..
2025-02-03 20:02:04 <ikke> yes
2025-02-03 20:02:19 <quinq> It's good to start somewhere
2025-02-03 20:02:26 <clandmeter> the numbers don't quite add up yet. 
2025-02-03 20:02:28 <fossdd[m]> i would hope that commercial companies who make money with Alpine would contribute to opencollective and not individuals
2025-02-03 20:02:44 <clandmeter> that is what we are hoping for
2025-02-03 20:02:53 <ikke> That's what we hope as well, but only time will tell
2025-02-03 20:02:59 <Forza> Or maybe providing man hours/employees? 
2025-02-03 20:03:03 <clandmeter> and there are many of them, you can see it in the traffic stats...
2025-02-03 20:03:13 <quinq> Forza, do you mean spies?
2025-02-03 20:03:18 <fossdd[m]> yep exactly
2025-02-03 20:03:26 <Forza> Oh? 
2025-02-03 20:04:04 <clandmeter> we are doing roughly 1PB per week over the cdn, which is kind of insane
2025-02-03 20:04:14 <Saijin_Naib[m]> clandmeter: I hope our organization can get there in the near future. We need to buy time from Ariadne first, though
2025-02-03 20:04:42 <Saijin_Naib[m]> clandmeter: And that is -Os packages! Nuts! 
2025-02-03 20:05:00 <quinq> clandmeter, isn't that some kind of defect from docker?
2025-02-03 20:05:08 <quinq> Like it downloads everytime it's run
2025-02-03 20:05:11 <Forza> It's common in Linux that they have people that can devote some time to various open source projects. For example maintainers etc? But maybe that could 'taint' things? 
2025-02-03 20:05:18 <quinq> (I don't know docker very well)
2025-02-03 20:05:29 <ikke> quinq: generally you build your image, and that image should have all the packages
2025-02-03 20:05:45 <clandmeter> its hard to tell where its coming from exactly, but we assume docker is a big part of it.
2025-02-03 20:05:50 <ikke> But what's often done in CI pipelines is using a base image and installing packages on the fly
2025-02-03 20:05:54 <quinq> ok, thanks ikke :)
2025-02-03 20:06:51 <quinq> Would “tracking” ip source be considered a breach of privacy?
2025-02-03 20:07:01 <ikke> yes
2025-02-03 20:07:04 <Forza> Yea 
2025-02-03 20:07:08 <quinq> I mean like having per ip statistics, in order to determine recurrent behavior
2025-02-03 20:07:12 <quinq> ok
2025-02-03 20:07:17 <clandmeter> we only see stats per region
2025-02-03 20:07:17 <caskd> if infra team needs some extra less-reliable servers i can provide some, but the "less reliable" is key
2025-02-03 20:07:20 <Saijin_Naib[m]> clandmeter: Is a lot end-users? If apkcache could be easily shared locally via avahi or something, Id have my house do that
2025-02-03 20:07:25 <clandmeter> thats what fastly offers automagically
2025-02-03 20:08:06 <clandmeter> and those stats are just traffic and hits, not what kind of request.
2025-02-03 20:09:35 <clandmeter> im planning to write an article about it, to shed some light on the challenges. I dont think commercial users are aware of it.
2025-02-03 20:09:36 <Forza> Musy be possible for CI runners to cache source packages to avoid the bandwidth. 1PB is huge 
2025-02-03 20:09:58 <ikke> caching is hard, so people avoid it
2025-02-03 20:10:05 <ikke> and it works without it, so people do not bother even
2025-02-03 20:10:38 <quinq> clandmeter, indeed, maybe having some kind of disclamer on the website would help sensibilizing people about how they might generate unnecessary traffic while it could be easily avoided
2025-02-03 20:11:00 <quinq> ikke, maybe it needs to be enabled by default :>
2025-02-03 20:11:21 <ikke> quinq: it needs somewhere to cache it
2025-02-03 20:11:32 <ikke> if ci is a docker container that gets rm'd, then caching won't help
2025-02-03 20:12:09 <quinq> Sure, but I was rather thinking about making people aware of it
2025-02-03 20:12:15 <quinq> But yeah there might be better ways :)
2025-02-03 20:12:49 <ikke> You don't get that monkey back in the sleeve
2025-02-03 20:13:02 <quinq> jaja, didn't know that expression
2025-02-03 20:13:50 <ikke> It's a dutch expression :P
2025-02-03 20:13:52 <Forza> Caching proxy, that only stores tarballs and the like? At least common upstream could be determined to be safe to cache, etc. 
2025-02-03 20:14:35 <quinq> nice ^^
2025-02-03 20:15:44 <ikke> There are plenty of mirrors, but we don't want to hardcode a mirror in the docker image that might disappear again, so it must at least be something we control
2025-02-03 20:16:05 <ikke> And it should also be reliable
2025-02-03 20:16:23 <quinq> That could be solved by the “cdn-dl” hostname though
2025-02-03 20:16:42 <ikke> Yes, which is our current solution
2025-02-03 20:16:47 <ikke> dl-cdn backed by fastly
2025-02-03 20:17:09 <quinq> Ah yeah, but they don't do it for free, do they?
2025-02-03 20:17:14 <ikke> They do for us
2025-02-03 20:17:25 <quinq> And it's exclusive to their network, or is it possible to insert mirrors you think are stable?
2025-02-03 20:17:26 <ikke> https://alpinelinux.org/sponsors/
2025-02-03 20:17:49 <quinq> ok
2025-02-03 20:17:57 <ikke> fastly manages the frontend
2025-02-03 20:18:07 <ikke> they serve it from their caches
2025-02-03 20:20:01 <durrendal> clandmeter: are we at risk of losing sponsorship from Fastly or just Equinix currently?
2025-02-03 20:20:16 <ikke> Just equinix atm
2025-02-03 20:20:36 <ikke> We had a conversation with fastly that at least for the time being they're comitted
2025-02-03 20:20:51 <durrendal> phew, was a bit concerned there for a second, a petabyte of traffic is absurd.
2025-02-03 20:21:03 <Forza> I meant run your own proxy for CI 
2025-02-03 20:21:48 <Forza> It can still access everything online, but you can configure or whitelist what to cache 
2025-02-03 20:33:52 <fossdd[m]> fwiw just saw https://www.phoronix.com/news/Alpine-Linux-Infra-Crisis
2025-02-03 20:38:35 <clandmeter> nice
2025-02-03 20:38:44 <clandmeter> any attention is welcome
2025-02-03 20:39:30 <clandmeter> durrendal: i hope not, it would be a major headache to solve that loss.
2025-02-03 20:40:15 <clandmeter> we do see the msg is out, and we are getting responses, which is good.
2025-02-03 20:56:30 <quinq> torrent really is a (old) technology to explore, this would solve some of the problems of single-point distribution throught http
2025-02-03 20:58:27 <ikke> torrents are often blocked
2025-02-03 20:58:30 <ikke> torrent traffic
2025-02-03 20:59:55 <quinq> Nothing is perfect, not set in stone
2025-02-03 21:00:21 <quinq> By showing the usefulness of something, things change
2025-02-03 21:00:28 <quinq> s/not/nor/
2025-02-03 21:00:53 <quinq> I'm not saying it's an easy drop-in replacement, but would be interesting to explore
2025-02-03 21:01:07 <quinq> If only as an alternative path for starters
2025-02-03 21:01:24 <quinq> Of course that requires development effort
2025-02-03 21:01:52 <quinq> But the protocol is made exactly for this
2025-02-03 21:02:28 <ikke> Ofcourse epxloring other options is good. But I'm afraid it would just be an additional 'cost' instead of alleviating what we have now
2025-02-03 21:02:44 <Saijin_Naib[m]> <quinq> "torrent really is a (old..." <- How does Win10/11 do it for local update cache sharing? It works brilliantly, and helped a ton when I supported my Town's ITS team
2025-02-03 21:21:38 <ikke> Saijin_Naib[m]: not sure if it's the same technology, but perhaps https://learn.microsoft.com/en-us/windows/win32/bits/background-intelligent-transfer-service-portal
2025-02-03 21:36:35 <Saijin_Naib[m]> Hmm, TLDR and potentially OT, but in my Town role, we were dark fiber between two campus
2025-02-03 21:37:04 <Saijin_Naib[m]> Main part had light fiber, satellite part only dark fiber link to main
2025-02-03 21:37:48 <Saijin_Naib[m]> I would take a laptop over to the satellite every Patch Tuesday afternoon to host updates for the computer fleet on that side
2025-02-03 21:38:17 <Saijin_Naib[m]> If not, their requests would flood the link and make it like dialup for users in the satellite location
2025-02-03 21:39:02 <Saijin_Naib[m]> And this is a small Town... how much could be saved if Alpine users can easily, safely, and automatically peer-share updates and apks?
2025-02-03 21:39:44 <Saijin_Naib[m]> Is a funding campaign something that could work?
2025-02-03 21:40:08 <ikke> Like https://opencollective.com/alpinelinux?
2025-02-03 21:40:42 <Saijin_Naib[m]> Yeah (I just signed up), but more targeted?
2025-02-03 21:41:37 <Saijin_Naib[m]> https://fund.webodm.org/#/howitworks
2025-02-03 21:42:16 <Saijin_Naib[m]> I orchestrated a large campaign for OpenDroneMap to address being stuck on 16.04lts, add snap and wsl2 builds
2025-02-03 21:42:59 <Saijin_Naib[m]> Basically, a community funding drive to develop an apkcache peering or whatever solution to reduce your cdn load and make it more robust for us all?
2025-02-03 21:45:53 <ikke> The load on the cdn itself is not our main concern right now
2025-02-03 21:46:13 <Saijin_Naib[m]> Ahh, okay
2025-02-03 21:48:26 <quinq> Saijin_Naib[m], I have no idea about what is done in Windows
2025-02-03 21:50:45 <quinq> It rather looks like just deploying local caching though
2025-02-03 21:51:01 <quinq> “To optimize WAN bandwidth when users access content on remote servers, BranchCache fetches content from your main office or hosted cloud content servers and caches the content at branch office locations, allowing client computers at branch offices to access the content locally rather than over the WAN.”
2025-02-03 22:02:33 <Saijin_Naib[m]> @quinq to add to that, client PCs can also direct share (Home, Pro, Workstation, et al) with a single toggle in Settings and no infra need
2025-02-03 22:05:10 <quinq> Ah, that looks more like a distributed model indeed :)
2025-02-04 03:40:02 <Ariadne> Saijin_Naib[m]: weh?
2025-02-04 03:49:21 <Saijin_Naib[m]> Ariadne Ah, just remembering that our Org wants to sponsor Alpine, but there is a lot of infra work we'd need to do first and we had wanted to contract you for help with that all
2025-02-04 03:49:38 <Ariadne> oh right
2025-02-04 03:49:48 <Saijin_Naib[m]> I can follow back up via email if your situation has changed since the past few months
2025-02-04 03:50:57 <Ariadne> no i’m still incredibly busy sadly :(
2025-02-04 03:55:31 <Saijin_Naib[m]> That's because you got the skills, haha
2025-02-04 03:55:34 <Ariadne> who are contauro?
2025-02-04 03:58:18 <Ariadne> they are apparently a sponsor now
2025-02-04 03:58:30 <Ariadne> “alpine linux support by contauro”
2025-02-04 03:59:01 <Ariadne> and, importantly, has the quality and competency of this support been appropriately vetted?
2025-02-04 04:00:55 <Ariadne> my concern: it could be construed that alpine endorses the support offering
2025-02-04 04:06:04 <Ariadne> half tempted to evaluate the quality of their support offering myself
2025-02-04 04:06:36 <Ariadne> maybe put a server up with a kernel module that just calls panic() and see if they can figure it out — most admin companies get tripped up by that one
2025-02-04 07:08:46 <donoban> I recently heard a company after months with a degraded raid accuse the customer that a process of theirs is breaking the hard disks :\
2025-02-04 07:15:39 <Saijin_Naib[m]> I want to package campcounselor into edge, but we are missing gnome libgda... no release tags in 4 years. Likely to be accepted or nah because libgda?
2025-02-04 07:16:37 <quinq> Saijin_Naib[m], if libgda is unmaintained, suggest upstream to vendor it
2025-02-04 07:16:53 <quinq> Otherwise if it's maintainted, it could be packaged
2025-02-04 07:17:14 <Saijin_Naib[m]> It gets translation updates, CI fixes, and some build fixes, but no tags
2025-02-04 07:17:22 <Saijin_Naib[m]> Minimal maintenance?
2025-02-04 07:17:50 <pj> last time it was actually touched was 3 years ago
2025-02-04 07:17:55 <pj> that looks like abandoned software
2025-02-04 07:18:13 <Saijin_Naib[m]> Right for a release tag, but it has a steady stream of commits in the meanwhile to the main branch
2025-02-04 07:18:21 <quinq> pj, Saijin_Naib[m] just proved otherwise
2025-02-04 07:18:24 <pj> I'm talking about master branch
2025-02-04 07:18:28 <Saijin_Naib[m]> Same
2025-02-04 07:18:35 <Saijin_Naib[m]> https://gitlab.gnome.org/GNOME/libgda/-/commits/master?ref_type=HEADS
2025-02-04 07:18:39 <pj> It literally does not get any development
2025-02-04 07:18:45 <pj> translations are not development
2025-02-04 07:18:48 <quinq> Doesn't mean it's abandoned
2025-02-04 07:19:07 <pj> it is if it's not maintained 
2025-02-04 07:19:07 <quinq> If there are unattended bug reports, then yeah that's problematic
2025-02-04 07:19:35 <quinq> pj, making a tautology doesn't make it correct
2025-02-04 07:20:10 <Saijin_Naib[m]> mmm, alright
2025-02-04 07:20:24 <Saijin_Naib[m]> I see a build error bugreport that is 3mo old and unresolved
2025-02-04 07:20:30 <Saijin_Naib[m]> I guess I'll shelve this for the time being
2025-02-04 07:20:38 <quinq> Point it so actually check it
2025-02-04 07:20:49 <quinq> Not to just throw vague opinion about it and close the discussion
2025-02-04 07:21:07 <pj> https://gitlab.gnome.org/GNOME/libgda/-/issues/263
2025-02-04 07:21:18 <Saijin_Naib[m]> https://gitlab.gnome.org/GNOME/libgda/-/issues/273
2025-02-04 07:21:44 <Saijin_Naib[m]> It looks like some depends have deprecated stuff libgda relies upon and builds break now
2025-02-04 07:21:48 <Saijin_Naib[m]> That is going to be beyond me
2025-02-04 07:22:12 <Saijin_Naib[m]> I liked the experience of using it to browse and play my bandcamp stuff, so I wanted to package it for others
2025-02-04 07:22:15 <pj> there is multiple reports open that it either does not compile or is broken in other way
2025-02-04 07:22:17 <pj> https://gitlab.gnome.org/GNOME/libgda/-/issues/253
2025-02-04 07:22:23 <Saijin_Naib[m]> But yeah, libgda looks like it is going to not be fun
2025-02-04 07:22:43 <quinq> Saijin_Naib[m], didn't know there were external interfaces to bandcamp, good to know!
2025-02-04 07:22:57 <quinq> The website just breaks some webbrowsers on musl
2025-02-04 07:23:16 <Saijin_Naib[m]> It works as flatpak, and is pretty slick if you have way too many things. Great filtering, sorting etc
2025-02-04 07:26:07 <pj> Saijin_Naib[m]: https://src.fedoraproject.org/rpms/libgda/tree/rawhide
2025-02-04 07:28:03 <Saijin_Naib[m]> Ahh, okay, vendored/patched?
2025-02-04 07:33:45 <pj> I don't think you will be able to package it unpatched
2025-02-04 07:35:00 <quinq> This looks even less “maintained”
2025-02-04 07:36:18 <Saijin_Naib[m]> Yeah, I think this one is above me at the moment
2025-02-04 07:36:25 <quinq> I think I know the solution
2025-02-04 07:36:33 <quinq> Saijin_Naib[m], you could take over that library :D
2025-02-04 07:36:48 <Saijin_Naib[m]> That would be awful for everyone involved, haha
2025-02-04 07:36:53 <quinq> jaja
2025-02-04 07:45:00 <pj> <quinq> "This looks even less “maintained..." <- it's just spec build?
2025-02-04 07:50:31 <quinq> I didn't have an extensive look, but yeah it seems like that
2025-02-04 07:50:38 <quinq> got to go to the mine
2025-02-04 07:50:41 <quinq> Have a good day! :)
2025-02-04 18:28:47 <witcher01> Could someone have a look at !75949, !75790, and !53556?
2025-02-04 18:28:59 <witcher01> The first 2 are nagios-plugins related, the maintainer has been inactive for a while now.
2025-02-04 18:29:14 <witcher01> The last is a new aport that has been sitting as a MR for a while
2025-02-05 08:46:29 <lindsay> Could someone have a look at !77603 ? It's been a while. 
2025-02-05 08:56:30 <Ermine> libxkbcommon no longer publishes tarballs, instead they want people to fetch a given revision from git. What should I do?
2025-02-05 09:00:04 <fabricionaweb> dont we have a bunch of packages that does it from git?
2025-02-05 09:04:41 <ikke> Not directly, only indirectly 
2025-02-05 09:04:53 <ikke> Ermine: do they still tag versions?
2025-02-05 09:05:36 <ikke> Seems like they still have tags on GitHub, which provides source archives 
2025-02-05 09:11:41 <Ermine> ah, yes, there are github-generated tarballs
2025-02-05 10:40:52 <matttbe> Hello! A month ago, a new package I suggested (mptcpd) got accepted in testing (again, thank you for that!). I was just wondering if, as the maintainer of this package, I had to do anything to get it out of testing.
2025-02-05 10:40:52 <matttbe> The wiki is a bit vague about that: https://wiki.alpinelinux.org/wiki/Aports_tree → "testing: (...) Package will be moved to main or community if there is positive feedback or for other good reasons."
2025-02-05 10:40:52 <matttbe> Sorry, that's my first package I'm maintaining in Alpine Linux: Who can provide such feedback? How? Do I need to ask someone to do that? Or simply wait? :)
2025-02-05 10:52:46 <Ariadne> open a MR moving it
2025-02-05 10:53:09 <matttbe> Ariadne: OK, thank you, I can do that!
2025-02-05 11:16:34 <matttbe> (done for the MR: !79478 -- no hurry of course, I'm happy to wait, it was just to say I did the suggested action :) )
2025-02-05 12:29:38 <PureTryOut> Does anybody know why the CI on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79339 just fails to run? The job is started but it never actually tries to build anything strangely
2025-02-05 12:51:57 <ikke> Shell syntax error somewhere?
2025-02-05 13:12:40 <maribu> I got asked to clarify the license of the APKBUILD of a package that I maintain. Specifically, it is not about the license of the software that the APKBUILD builds, but rather the APKBUILD itself. See https://github.com/kjarosh/latex-docker/issues/13#issuecomment-2636772708
2025-02-05 13:16:21 <maribu> I'd rather not add SPDX identifiers to random APKBUILDs, or rather get involved in this discussion at all. But if and when Alpine decides to add explicit license info to the APKBUILD (not to the package build by it), I would be happy to agree to have my contributions licensed and whatever free license Alpine settles on.
2025-02-05 13:17:30 <maribu> https://rfc.archlinux.page/0040-license-package-sources might also be a good reference on this discussion
2025-02-05 14:05:50 <PureTryOut> ikke: ugh, you're right, typed "easc" instead of "esac"...
2025-02-05 14:12:59 <quinq> Who ever thought "esac" was a good idea…
2025-02-05 14:18:02 <pj> fi :]
2025-02-05 14:19:46 <cfp> Hi, I am currently trying to write some APKBUILDs where I need to package whole directories, I tried using globs but they just dont work, the parameter is passed as-is to the install utility. Anyone know how it works?
2025-02-05 14:21:23 <fabricionaweb> esac is the reverse of case like fi is the reverse of if and done is the reverse of for
2025-02-05 14:21:40 <fabricionaweb> wait a moment
2025-02-05 14:32:41 <quinq> pj :>
2025-02-05 14:33:05 <quinq> haha yeah fabricionaweb 
2025-02-05 14:59:03 <PureTryOut> cfp: if you need to install a whole directory just use `cp -r`, that's what other APKBUILDs do
2025-02-05 16:51:39 <quinq> (-R)
2025-02-05 18:18:34 <DylanVanAssche> ikkeThe patches for the CI kernel were merged that I submitted. Could you update the CI runners?
2025-02-05 19:41:45 <Mis012[m]> hi, I'm trying to (ab)use the aports CI for nightlies, and it seems that the detection of changes doesn't work correctly... except that's only for one branch, another branch that only differs in which APKBUILD is changed works just fine
2025-02-05 19:41:46 <Mis012[m]> 
ACTION uploaded an image: (13KiB) < https://matrix.org/oftc/media/v1/media/download/AYrX3tuA40hfstlLsRDpbLpL_nr4ovo62lBFAWvicVhfcct0Yrp0AuL1QWjd_vy-sISmQ_-iQNjnq6EBmGZ4P7FCeVH7sMCgAG1hdHJpeC5vcmcvRGhqeWxRZnF2aEtxYnhMZG12VEdmRkpQ >

2025-02-05 19:41:48 <Mis012[m]> any idea?
2025-02-05 19:42:28 <Mis012[m]> full log here https://gitlab.com/android_translation_layer/aports/-/jobs/9051258335
2025-02-05 19:43:16 <Mis012[m]> I tried executing e.g https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/lib/functions.sh#L27 locally and it seems to produce expected results
2025-02-05 20:08:03 <markand> o/
2025-02-05 20:08:12 <markand> can someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79343 please? <3
2025-02-05 20:54:05 <markand> <3 
2025-02-05 21:04:09 <ikke> Mis012[m]: ping
2025-02-05 21:04:33 <Mis012[m]> hi
2025-02-05 21:04:52 <ikke> So you are using our alpine-gitlab-ci docker image I understand?
2025-02-05 21:05:19 <Mis012[m]> yes
2025-02-05 21:06:47 <ikke> It appears you are using branch pipelines
2025-02-05 21:06:50 <ikke> Is that correct?
2025-02-05 21:07:12 <ikke> The docker image assumes merge request pipelines to find be able to determine what changes are made
2025-02-05 21:07:25 <Mis012[m]> yes, I hacked around that and it works for the other branch
2025-02-05 21:07:39 <Mis012[m]> it just needs some envs set
2025-02-05 21:07:47 <ikke> right
2025-02-05 21:09:57 <Mis012[m]> https://gitlab.com/android_translation_layer/art_standalone/-/blob/master/.gitlab-ci.yml?ref_type=heads
2025-02-05 21:09:57 <Mis012[m]> https://gitlab.com/android_translation_layer/android_translation_layer/-/blob/master/.gitlab-ci.yml?ref_type=heads
2025-02-05 21:10:04 <Mis012[m]> working and non-working respectively
2025-02-05 21:12:09 <ikke> >>> Changed aports in testing:
2025-02-05 21:12:11 <ikke>  - 
2025-02-05 21:12:16 <Mis012[m]> yes
2025-02-05 21:12:17 <ikke> So for some reason it gets an empty result back
2025-02-05 21:13:09 <Mis012[m]> I posted that as an image, forgot that Matrix broke those by also requiring authentication for public rooms
2025-02-05 21:13:37 <ikke> I see the image link
2025-02-05 21:13:47 <ikke> but the links matrix generates are obnoxiously long
2025-02-05 21:14:14 <Mis012[m]> well, that's not the worst thing ever as long as they work, which iirc they don't currently
2025-02-05 21:14:41 <ikke> I can see the iamge
2025-02-05 21:14:52 <Mis012[m]> hm, so they fixed it? nice
2025-02-05 21:14:53 <Mis012[m]> nvm then
2025-02-05 21:15:18 <ikke> The link is wrapped in my irc client, so I need to put it in raw mode to get the whole link
2025-02-05 21:16:36 <ikke> Not sure if that's the case here, but I recall having lots of issues with gitlab reusing repos and shallow lcones
2025-02-05 21:17:20 <Mis012[m]> well, it clearly knows that the change was under testing/
2025-02-05 21:17:22 <ikke> The existing shallow points were preventing git from properly calculating changes
2025-02-05 21:17:35 <Mis012[m]> and git doesn't store directory entries
2025-02-05 21:17:41 <Mis012[m]> so that's intriguing
2025-02-05 21:18:32 <ikke> It determines changes aports in 2 phases indeed
2025-02-05 21:18:48 <ikke> first by checking each directory if there are changes to determine the repo
2025-02-05 21:18:59 <ikke> and then for each directory what APKBUILD files have been changed
2025-02-05 21:19:26 <Mis012[m]> well, the - looked like it also knows there is 1 changed
2025-02-05 21:19:30 <Mis012[m]> *change
2025-02-05 21:20:04 <ikke> echo -n | printf "- %s\n"
2025-02-05 21:22:48 <ikke> I'd advise you to manually trace the steps build.sh does compared to your situation
2025-02-05 21:23:31 <Mis012[m]> well, I did that locally, and I got the APKBUILD correctly identified
2025-02-05 21:24:00 <Mis012[m]> the fact that it works in the other branch makes me think it might indeed be some gitlab weirdness
2025-02-05 21:25:03 <ikke> Just to rule it out: can you try to set the repo options to do a fresh clone and fetch depth at least something like 20?
2025-02-05 21:25:54 <Mis012[m]> mhm
2025-02-05 21:25:56 <Mis012[m]> 
ACTION uploaded an image: (44KiB) < https://matrix.org/oftc/media/v1/media/download/AbWLTZOrO-RUut64lXlWTZu_2pRk7aO2B_L0-QHLsuEsJTt_NX3dogsca0nDaJemeNQ1XBGjzdjfr6FvUEeH0HtCeVIBpm3wAG1hdHJpeC5vcmcvaXd0T2RQTWFzU0xXenVxdU9KaE52dlB5 >

2025-02-05 21:26:00 <Mis012[m]> it was set to fetch
2025-02-05 21:26:27 <Mis012[m]> wouldn't be surprised if that fixes it
2025-02-05 21:26:44 <ikke> I know that gave us trouble
2025-02-05 21:29:36 <Mis012[m]> eh, nope... same issue
2025-02-05 21:29:59 <ikke> There is a variable you can set to log more info
2025-02-05 21:30:47 <ikke> CI_DEBUG_BUILD
2025-02-05 21:31:13 <Mis012[m]> just =1?
2025-02-05 21:31:17 <ikke> yes
2025-02-05 21:31:27 <ikke> it checks it with -n
2025-02-05 21:32:28 <Mis012[m]>   GIT_STRATEGY: clone
2025-02-05 21:32:28 <Mis012[m]>   GIT_DEPTH: "500"
2025-02-05 21:32:31 <Mis012[m]> seems it also does this
2025-02-05 21:32:40 <Mis012[m]> not sure if that overrides the project settings
2025-02-05 21:33:31 <ikke> I think it will
2025-02-05 21:34:02 <Mis012[m]> so no wonder that didn't change anything...
2025-02-05 21:34:11 <ikke> nod
2025-02-05 21:38:57 <Mis012[m]> https://gitlab.com/android_translation_layer/aports/-/jobs/9054762872
2025-02-05 21:39:06 <Mis012[m]> certainly interesting
2025-02-05 21:44:00 <Mis012[m]> ikke: still not sure what the issue is
2025-02-05 21:45:32 <ikke> Mis012[m]: line 376 to 379
2025-02-05 21:46:21 <ikke> `ap` is sensitive to syntax errors in APKBUILD files
2025-02-05 21:46:30 <Mis012[m]> mhm
2025-02-05 21:47:09 <ikke> You say it works locally?
2025-02-05 21:47:09 <Mis012[m]> I expected that if there was a syntax error that would get communicated
2025-02-05 21:47:28 <Mis012[m]> I didn't try building the APKBUILD locally
2025-02-05 21:47:58 <Mis012[m]> but the changes in it should be analogical to the ones I made in the other repo
2025-02-05 21:48:15 <Mis012[m]> I assume there is some APKBUILD syntax checker I could try?
2025-02-05 21:48:35 <ikke> check if ap builddirs -d testing android-translation-layer returns the package?
2025-02-05 21:49:09 <ikke> ap builddirs returns the packages in build order (dependencies first)
2025-02-05 21:49:50 <WhyNotHugo> Can I merge MRs for packages which I maintain? Is GitLab's permission granular enough for this?
2025-02-05 21:50:25 <ikke> No, certainly not the CE version
2025-02-05 21:51:08 <ikke> the enterprise edition has code owners, but not sure if that can be dynamic
2025-02-05 21:51:44 <Mis012[m]> ap builddirs -d testing android-translation-layer
2025-02-05 21:51:44 <Mis012[m]> WARNING: android-translation-layer: not provided by any known APKBUILD
2025-02-05 21:51:46 <Mis012[m]> mhm
2025-02-05 21:51:54 <Mis012[m]> I thought I tried this
2025-02-05 21:51:55 <ikke> dir name different from package name?
2025-02-05 21:52:21 <Mis012[m]> the package exists upstream, I just hacked the APKBUILD for nighlties
2025-02-05 21:54:14 <ikke> oh, needs to be an absolute path to -d
2025-02-05 21:54:44 <Mis012[m]> hm, waaaait
2025-02-05 21:54:59 <Mis012[m]> wtf
2025-02-05 21:55:15 <Mis012[m]> the pkg name is wring
2025-02-05 21:55:17 <Mis012[m]> s/wring/wrong/
2025-02-05 21:55:45 <Mis012[m]> well... I think I found the issue 🤦‍♂️
2025-02-05 21:56:07 <Mis012[m]> 
ACTION uploaded an image: (31KiB) < https://matrix.org/oftc/media/v1/media/download/ATLLfoFle1sOUUc0ydEAm7R3K8xfe2ZifuWxQXJuLp1y8VsHeJNx3Z0qb56p_5s3tR4nDumhF0gGdXinPJhcUpJCeVIDYJVAAG1hdHJpeC5vcmcvSGJYbFl1emlTWGJHTWdyZmdiZ1R0ZnhG >

2025-02-05 21:56:29 <ikke> heh
2025-02-05 21:56:35 <Mis012[m]> every time I was checking if I messed something up here, my brain was like "the pkgname is white, so didn't mess that up"
2025-02-05 21:57:17 <ikke> I need to fix that some time
2025-02-05 21:57:38 <ikke> Right now the script assumes ap builddirs will return the packages it provides
2025-02-05 21:57:39 <Mis012[m]> would be nice if the error got printed yeah
2025-02-05 21:59:53 <Mis012[m]> ikke: or ideally lint the APKBUILD
2025-02-05 22:00:21 <ikke> We have other jobs for linting
2025-02-05 22:00:50 <ikke> But there is nothing yet that verifies the pkgname equals the dirname
2025-02-05 22:01:17 <Mis012[m]> I suppose printing the error would be good enough
2025-02-05 22:01:24 <Mis012[m]> rather than swallowing it
2025-02-05 22:01:50 <Mis012[m]> and in tandem with that make the error be "pkgname != dirname"
2025-02-05 22:03:56 <ikke> would you mind adding an issue to the alpine/infra/docker/alpine-gitlab-ci project?
2025-02-05 22:04:00 <ikke> as a reminder
2025-02-05 22:04:26 <Mis012[m]> np
2025-02-05 22:10:24 <Mis012[m]> ah, I don't think I have an account on that gitlab
2025-02-05 22:11:08 <ikke> ok, you should be able to login with a gitlab.com or github.com account if you have that
2025-02-05 22:12:41 <Mis012[m]> hm, username taken, guess I do have one xD
2025-02-05 22:14:55 <ikke> Seems to have been came over from redmine
2025-02-05 22:15:00 <ikke> migrated over*
2025-02-06 07:32:04 <qaqland> >>> Host system information (arch: armhf, release: edge) <<<
2025-02-06 07:32:05 <qaqland> - Free space: 6.6G
2025-02-06 07:32:15 <qaqland> No space left on device
2025-02-06 07:37:27 <quinq> Maybe on the other device
2025-02-06 07:37:36 <quinq> df might be more accurate
2025-02-06 07:45:46 <qaqland> my MR has 35 commits, it takes all the space :(
2025-02-06 07:54:36 <quinq> 35 commits, that must be like 100k of compressed text
2025-02-06 08:07:37 <ikke> quinq: can you see what runner?
2025-02-06 08:09:30 <qaqland> this MR !79331
2025-02-06 08:27:46 <ikke> qaqland: I did a cleanup on one runner, hope that helped 
2025-02-06 09:05:49 <qaqland> ikke: thx
2025-02-06 10:11:13 <fabricionaweb> is it intended that our mirrors are http? https://mirrors.alpinelinux.org/mirrors.txt
2025-02-06 10:48:20 <fabricionaweb> raspbeguy how do you approve it a MR? LOL I have never found that button 
2025-02-06 10:48:34 <fabricionaweb> s/it//
2025-02-06 10:49:16 <raspbeguy> fabricionaweb, you must have a certain role on gitlab for that button (I don't remember which)
2025-02-06 10:51:30 <qaqland> fabricionaweb: iirc, packages have their own signatures, there is no need for safety from https
2025-02-06 10:53:03 <fabricionaweb> thanks both
2025-02-06 11:00:47 <fabricionaweb> raspbeguy I will try that regreet a little more, but I think its a package that worth be on community + mention on wiki, eventually
2025-02-06 11:01:05 <fabricionaweb> I notice it may require touch the sudoes to be able to use reboot/poweroff (I mentioned on #alpine-linux I think)
2025-02-06 12:44:17 <raspbeguy> fabricionaweb: would you like to become maintainer for regreet ?
2025-02-06 13:25:02 <fabricionaweb> its my first time using it, but maybe yeah
2025-02-06 14:21:05 <raspbeguy> I personally don't use it (anymore) so if you can give it more love than I do then sure
2025-02-06 17:51:18 <ikke> You need to be at least a guest on the project to be able to approve MRs
2025-02-06 18:40:29 <Mis012[m]> how safe is the "safe" option really https://wiki.alpinelinux.org/wiki/Build_with_abuild_rootbld_in_Docker_container
2025-02-06 18:41:01 <Mis012[m]> is there no known way to use those syscalls to escape docker?
2025-02-06 18:47:43 <Ariadne> container escapes need a reference to the parent environment in order to escape.  so, as long as there is no reference to the parent mount namespace inside the container (such as a leftover mount) it is reasonably safe
2025-02-06 19:21:26 <Mis012[m]> bwrap works with gitlab.com runners fwiw, but I assume they just use VMs
2025-02-06 21:21:45 <fossdd[m]> Hey, can somebody merge !79210?
2025-02-06 22:00:23 <Mis012[m]> Ariadne: well, doesn't allowing `mount` mean the code in the container can do `mount -t devtmpfs none <wherever>`?
2025-02-06 22:00:31 <Mis012[m]> and access raw block devices
2025-02-06 22:00:39 <Mis012[m]> seems like a security issue to me
2025-02-06 22:07:17 <Ariadne> no, simply allowing mount syscall does not actually allow mounting
2025-02-06 22:07:37 <Ariadne> if you are in an unprivileged mount namespace you also need caps for that
2025-02-06 22:08:09 <Ariadne> if you are in a privileged mount namespace then this is all a fool’s errand anyway
2025-02-06 22:14:20 <Mis012[m]> nice
2025-02-06 22:17:51 <Mis012[m]> Ariadne: it seems that https://wiki.alpinelinux.org/wiki/Build_with_abuild_rootbld_in_Docker_container is not working (with current version of bwrap | for me)
2025-02-06 22:18:13 <Mis012[m]> is there some place this is used in production that would have no choice but be up-to-date?
2025-02-06 22:20:08 <Mis012[m]> well, technically s/me/my friend/ so can't vouch for instructions being followed properly :P
2025-02-06 22:20:42 <Ariadne> no we don’t use rootbld in production
2025-02-06 22:21:00 <Mis012[m]> sad
2025-02-06 22:21:03 <Ariadne> we should, but instead a different, less elegant approach is used
2025-02-06 22:21:26 <Mis012[m]> clone(child_stack=NULL, flags=CLONE_NEWNS|SIGCHLD) = -1 EPERM (Operation not permitted)
2025-02-06 22:21:29 <Mis012[m]> getting this
2025-02-06 22:22:25 <Mis012[m]> with bwrap --bind / / bash
2025-02-06 22:23:33 <ovf> ncopa: fyi i think i figured out !79552 -- works ok on x86_64, ci timed out on aarch64 but i've restarted just in case
2025-02-06 22:23:34 <Mis012[m]> fwiw the link to https://github.com/moby/moby/blob/master/profiles/seccomp/default.json links master
2025-02-06 22:27:19 <Mis012[m]> seems https://github.com/moby/moby/commit/7de9f4f82de417097f6fab150288ca2f1c0a9d91 was the latest June 2022 (edit time), let's try that
2025-02-06 23:24:47 <Mis012[m]> nope, maybe their definition for clone has priority?
2025-02-07 00:31:39 <Mis012[m]> well, got it working with `--unshare-pid --unshare-user` for bwrap and `sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=0 && sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0`
2025-02-07 00:32:02 <Mis012[m]> none of which is mentioned on that wiki page so no idea if that's the intended most safe way
2025-02-07 02:10:56 <j_v> doas alpine have any user uids and group gids that are reserved. is there a way to be certain that adding user/group at specific uid/gid won't collide later with an installation created user/group?
2025-02-07 02:11:03 <j_v> s/doas/does
2025-02-07 04:30:14 <prabu> j_v, https://wiki.alpinelinux.org/wiki/Setting_up_a_new_user#Common_permission_groups points to https://git.alpinelinux.org/alpine-baselayout/tree/group
2025-02-07 04:37:01 <j_v> prabu: thanks. appreciated. i also did `find ~/aports -name '*.p*-install' -exec grep -E 'add(group|user)' {} \;` which was also interesting, though not as enlightening as i had hoped.
2025-02-07 06:27:48 <donoban> it seems that markdown-oxide probably doesn't work because helix is outdated and I noticed that stills locked due !70759 ... thinking about it, is not feasible to patch helix for use the same queries of already packaged tree-sitter?
2025-02-07 06:35:49 <ikke> donoban: potentially relevant: https://github.com/helix-editor/helix/issues/1603
2025-02-07 06:36:21 <ikke> I see I already linked to that in the thread
2025-02-07 06:40:16 <donoban> hmm.. reading this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70759#note_470925 I suppose that is not easy to patch, maybe some tree-sitter behaviour is hard-coded inside helix
2025-02-07 06:50:19 <donoban> I wonder if replacing this 'https://github.com/helix-editor/helix/tree/master/runtime/queries' with alpine packaged one would make a compatible helix, but it looks too simple for nobody have done before..
2025-02-07 06:52:38 <donoban> ah, it seems that it already does it
2025-02-07 06:53:20 <donoban> but.. it does after building the binary
2025-02-07 06:57:27 <donoban> let's try!     512 lrwxrwxrwx    1 donoban  donoban       31 Feb  7 06:57 queries -> /usr/share/tree-sitter/queries/
2025-02-07 06:58:18 <donoban> maybe I've should linked both queries&grammars dirs
2025-02-07 07:01:47 <donoban> ah no the grammars dir is empty before building
2025-02-07 07:03:00 <donoban> meh, test failed on some grammar tests and I lost the binary
2025-02-07 07:18:31 <donoban> nah, no change
2025-02-07 09:31:05 <donoban> lazygit works fine directly on the terminal, but inside tmux says: *exec.Error exec: "infocmp": executable file not found in $PATH
2025-02-07 09:31:22 <donoban> it seems that tries to use ncurses
2025-02-07 09:32:12 <donoban> running with TERM='alacritty' works
2025-02-07 09:32:51 <pj> <donoban> "I wonder if replacing this '..." <- it's better if you don't
2025-02-07 09:33:35 <donoban> hehe well, I hope nobody will be hurt :D
2025-02-07 09:34:21 <pj> you can do it for yourself, but each editor using tree-sitter has different tree-sitter lib requirement and built with different assumptions for the grammars
2025-02-07 09:35:33 <donoban> and that assumptions are directly linked on the source code?
2025-02-07 12:23:19 <qaqland> aarch64: No space left on device.
2025-02-07 12:23:49 <qaqland> 
ACTION thus build failed

2025-02-07 12:28:50 <pj> grammars should be mostly ABI compatible but it depends on generated code, so far editors and tree-sitter have been on same version (14), but injections/highlights/etc. are tied to the grammar and tied to the editor (each editor implements them differently)
2025-02-07 12:30:09 <pj> grammars should work (load) as libraries but it's not guaranteed that they will work correctly according to the grammar definition
2025-02-07 15:08:42 <donoban> I see
2025-02-08 05:44:58 <qaqland> i wonder if it's valid to link libgit2(old version) in !79468
2025-02-08 05:45:34 <qaqland> https://github.com/nabijaczleweli/cargo-update/blob/v16.1.0/Cargo.toml#L55 it use git2 = 0.20.0 which should link to libgit2 1.9.0
2025-02-08 09:35:46 <z3ntu> ping on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78354
2025-02-08 10:08:52 <fabricionaweb> !78515 would someone check this electron app
2025-02-08 16:12:44 <ptrc> sigh, i wish gitlab had a feature where i can just click "please rebase and merge" on 3 different MRs and not have to worry about race conditions
2025-02-08 16:15:31 <quinq> ptrc, updating webkitgtk? :D
2025-02-08 16:17:16 <ikke> ptrc: it has, you have to pay for it :(
2025-02-08 16:17:25 <ikke> (merge trains)
2025-02-08 16:20:20 <quinq> ikke, to pay you?
2025-02-08 16:20:51 <ikke> No, gitlab
2025-02-08 16:21:08 <ikke> ie, their enterprise edition
2025-02-08 16:21:10 <quinq> :>
2025-02-08 16:22:37 <ptrc> aren't merge trains also rerunning the whole CI again
2025-02-08 16:26:02 <ptrc> quinq: not really, more of a "there's 30 MRs by the respective package maintainers that are just a simple bump and i wish i could just click a single button after review and then move onto the next one"
2025-02-08 16:26:37 <ptrc> currently i solve this by.. having a sidecar daemon running on my desktop that just listens on HTTP, receives MR IDs and merges them\
2025-02-08 16:27:09 <ptrc> https://ptrc.gay/vjSxrjvJ
2025-02-08 16:27:18 <ptrc> bit unorthodox but gets the job done
2025-02-08 16:30:09 <ikke> I use a patched glab combined with fq to do it
2025-02-08 16:30:59 <ikke> https://gitlab.alpinelinux.org/kdaudt/glab/-/tree/retry
2025-02-08 16:31:39 <ikke> It's not perfect (mostly when others are merging as well), but it works
2025-02-08 16:52:35 <ptrc> oh, i think my local glab executable is also built from that branch :P
2025-02-08 16:58:06 <abby> ptrc: i use https://leahneukirchen.org/dotfiles/bin/git-merge-pr for github, could probably be adapted for gitlab
2025-02-08 16:58:45 <ptrc> i mean, the actual merging part is handled by glab
2025-02-08 16:58:50 <ptrc> ( the cli tool ) 
2025-02-08 16:58:53 <fossdd[m]> i mean there is also marge bot
2025-02-08 16:59:10 <fossdd[m]> but it has different issues ig
2025-02-08 16:59:22 <ptrc> my main issue was.. queueing them, so that they actually get merged and not stuck because someone merged another thing in the meantime and it got aborted
2025-02-08 16:59:35 <ptrc> and gitlab's rebase sometimes takes 30+ seconds
2025-02-08 17:39:40 <fabricionaweb> eh my build is failing now error: unable to select packages:   so:libsimdjson.so.23 (no such package):     required by: nodejs-22.13.1-r0[so:libsimdjson.so.23did we broke nodejs or something else
2025-02-08 17:40:28 <fabricionaweb>  that so only exists for longarch lol
2025-02-08 17:44:53 <ikke> beacuse the builder is stuck
2025-02-08 17:45:01 <ikke> simdjson has just been upgraded
2025-02-08 17:47:49 <ikke> seems like only nodejs is built against it, pushed a rebuilt
2025-02-08 18:03:19 <fabricionaweb> thanks
2025-02-08 18:33:08 <bl4ckb0ne> hm i merged the simdjson upgrade and forgot to check the soname change sorry
2025-02-08 18:40:25 <ikke> can happen
2025-02-08 23:16:56 <j_v> is it possible to update a forked repo (specifically my aports fork) from glab command line? looking for it, not seeing it, but maybe i'm looking right passed it.
2025-02-08 23:24:08 <j_v> was thinking i could fetch upstream remote, but could that cause problems on pushes back to origin remote?
2025-02-08 23:52:00 <j_v> ok, got it, sorry for noise
2025-02-10 05:22:35 <j_v> seems a shame conky is in main instead of community. if it were in community, the manual page could be built (needs pandoc-cli from community).
2025-02-10 07:26:14 <PureTryOut> tbh it makes sense to not be in main, I'd suggest asking the maintainer to move it (or make the PR yourself and ask the maintainer for feedback)
2025-02-10 11:21:19 <fossdd[m]> <j_v> "seems a shame conky is in main..." <- note that man pages could only be built on x86_64 and aarch64 due to limitations on pandoc-cli (or rather ghc)
2025-02-10 11:34:32 <quinq> Not sure what's the actual policy
2025-02-10 11:34:40 <quinq> But I'd assume main is for core packages
2025-02-10 11:34:49 <quinq> conky is far from being a core component
2025-02-10 11:35:16 <ikke> There's not a hard policy. And there are sometimes still packages left from the time that there was no community repo
2025-02-10 11:35:51 <quinq> j_v, send a MR ;)
2025-02-10 11:50:47 <fossdd[m]> and looking at the git log, yeah: conky is in main since 2010 and community exists since 2015
2025-02-10 12:27:19 <clandmeter> thank you friends of pmos :)
2025-02-10 12:49:54 <fabricionaweb> morning, could someone look to my MR? !78515 
2025-02-10 15:27:58 <fabricionaweb> there is an update to vaultwarden that mention a CVE but its a rust cve, should I tag as security and add the secfix? 
2025-02-10 15:28:33 <fabricionaweb> like some rust crates bump
2025-02-10 15:38:10 <staceee> I'm trying to package something, but it fails at the end, while tracing dependencies: libdl.so.2: path not found
2025-02-10 15:38:17 <staceee> why?
2025-02-10 15:41:06 <staceee> I built the binaries. How can they be linked to this?
2025-02-10 15:47:38 <yyp> Perhaps there's a prebuilt part that's linked against glibc? Musl doesn't seem to have shared libdl but glibc does
2025-02-10 15:54:37 <yyp> I've experienced a similar error when building a nodejs program and it used a module that bundled a prebuilt native helper
2025-02-10 20:21:21 <j_v> fossdd[m]: i hadn't thought about that pandoc depends on ghc. ephemerially, i know that, but wasn't making the connection when i was thinking about conky. with the ghc dep for pandoc, i think if i want to find a way for making conky man page availability would be better to find a different way to generate it.
2025-02-10 20:21:56 <j_v> fossdd[m], ikke, quinq, thanks for the input. i appreciate it.
2025-02-10 20:23:26 <quinq> j_v, good luck :D
2025-02-10 20:23:45 <quinq> Maybe the easiest way would be to just write an actual man-page
2025-02-10 20:25:01 <j_v> yeah, thought about it, just leaves a maintenance burden though, especially with how often conky adds features. still, a point worth looking into.
2025-02-10 20:27:42 <quinq> Yeah it is, but…
2025-02-10 20:27:51 <quinq> Could be upstreamed too maybe
2025-02-10 20:33:29 <fossdd[m]> can i motivate you for https://git.sr.ht/~sircmpwn/scdoc? :)
2025-02-10 20:36:26 <j_v> good one... will play around with that as a starting point. thanks!
2025-02-10 20:39:19 <quinq> I'd say keep to ms, no need for yet-another-documentation-format
2025-02-10 20:49:27 <j_v> the interesting thing to me, one that i had not noticed before, is that the build system does it as a two step dance. from Jinja2 template to markdown then to roff man... i think the first step only needs python and yaml, finding a converter from md to roff man or mdoc should be feasible. quing, thanks for your input... while scdoc looks interesting, not sure it is needed in
2025-02-10 20:49:28 <j_v> this instance, possibly even complicates the prospective task
2025-02-10 21:06:23 <humm> quinq: man or mdoc, not ms
2025-02-10 21:07:40 <j_v> ok, i have a path forward. py3-jinja2 and py3-pyaml to convert jinja2 to markdown, go-md2man for markdown to man.
2025-02-10 21:10:25 <humm> it’s sad that most converters to troff are written by people who don’t know about or care for good troff, so there are hardly any man page generators that produce /good/ man pages
2025-02-10 21:15:28 <j_v> you are right. i've been down similar roads plenty other times. very frustrating at times.
2025-02-10 21:39:13 <j_v> lowdown -Tman does a nicer output than go-md2man
2025-02-10 21:39:54 <j_v> not surprising... lowdown comes from bsd.lv project, same folks that brought us mandoc.
2025-02-10 22:30:58 <j_v> jeez, that much easier than i expected. thanks for tolerating my whining about missing the conky man page and suggestions on moving forward. !79763
2025-02-10 23:05:30 <WhyNotHugo> Any feedback for !77155 ?
2025-02-11 13:22:03 <vkrishn> would be helpful, if anyone tell which tool to use to figure out why so huge diff in aports, https://tpaste.us/Xvwl 
2025-02-11 13:34:56 <fabricionaweb> which diff are u looking for? I didnt get
2025-02-11 13:37:13 <vkrishn> size
2025-02-11 13:37:29 <vkrishn> what is causing the size diff
2025-02-11 13:38:06 <fabricionaweb> I mean, cant tell just looking like that
2025-02-11 13:38:17 <fabricionaweb> it can be git history, can be the branches, tags
2025-02-11 13:41:45 <clandmeter> did you run gc on both?
2025-02-11 13:41:54 <vkrishn> clandmeter: yes
2025-02-11 13:42:02 <vkrishn> first thing i did
2025-02-11 13:42:04 <clandmeter> has the same amount of branches? 
2025-02-11 13:42:07 <clandmeter> and tags
2025-02-11 13:42:12 <vkrishn> aports has more
2025-02-11 13:42:24 <vkrishn> i mean git.a.o
2025-02-11 13:42:36 <vkrishn> but size is smaller
2025-02-11 13:42:47 <clandmeter> could be that one is optimzed and one is not
2025-02-11 13:43:07 <clandmeter> but im not sure if that is transfered over, i would guess not. 
2025-02-11 13:43:11 <vkrishn> let me know any cmds to run and will post it or upload it
2025-02-11 13:43:30 <fabricionaweb> one is from git.a.o and the other is ?
2025-02-11 13:43:37 <vkrishn> fabricionaweb: gitlab
2025-02-11 13:43:55 <fabricionaweb> yes one, how about the other from where?
2025-02-11 13:44:02 <vkrishn> git.a.o
2025-02-11 13:44:10 <fabricionaweb> so both are from git.a.o
2025-02-11 13:45:42 <clandmeter> git.a.o vs gitlab.a.o
2025-02-11 13:45:50 <vkrishn> fabricionaweb: https://tpaste.us/LyBV 
2025-02-11 13:46:05 <fabricionaweb> ok now I get it
2025-02-11 13:54:54 <dalias> i want to make (and hopefully upstream) a package variant for git snapshots of something where the 'release' package is critically outdated
2025-02-11 13:54:59 <dalias> specifically, openscad
2025-02-11 13:55:28 <dalias> (latest tag is 2021, but you need ≥2024 to have usable performance, bugfixes, etc.
2025-02-11 13:56:06 <dalias> what's the right way to package something where src is git snapshot?
2025-02-11 13:56:34 <dalias> especially problematic is that it has submodules so you can't just point source link to github..../archive/...
2025-02-11 13:56:57 <vkrishn> from last clone, https://tpaste.us/ZKn9 , will run gc again
2025-02-11 13:58:02 <fossdd[m]> dalias: i suppose something like this !65054?
2025-02-11 13:59:53 <dalias> ok that's roughly how i hacked it to build locally...
2025-02-11 14:00:00 <dalias> really nasty to update tho
2025-02-11 14:00:27 <fossdd[m]> yep really crappy but yeah
2025-02-11 14:05:16 <vkrishn> no diff, https://tpaste.us/lbnN 
2025-02-11 14:06:44 <dalias> why do some APKBUILD build() recipes have to cd into the extracte dsrc dir and others assume they're already there?
2025-02-11 14:07:37 <fossdd[m]> probably just for historic reasons, today APKBUILDs should define builddir and abuild automatically cd's into it before calling functions
2025-02-11 14:09:56 <dalias> ah
2025-02-11 14:10:34 <dalias> ok something went wrong, trying again..
2025-02-11 14:10:47 <ikke> And builddir has a default value that is suitable for most cases 
2025-02-11 14:10:56 <dalias> where does the default come from?
2025-02-11 14:11:08 <ikke> abuild
2025-02-11 14:11:26 <ikke> Based on $pkgdir and $pkgver
2025-02-11 14:11:39 <ikke> pkgname, sorry 
2025-02-11 14:12:03 <dalias> and if the extracted sources don't have a matching dir name, it doesn't happen?
2025-02-11 14:12:28 <fossdd[m]> yeah, then you should set it to `builddir="$srcdir/whatever"`
2025-02-11 14:12:40 <dalias> ok
2025-02-11 14:12:50 <dalias> in this case the extracted src dir is a git hash name
2025-02-11 14:12:53 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2962
2025-02-11 14:13:13 <ikke> Then you have to provide it yourself
2025-02-11 14:15:19 <ikke> builddir="$builddir/$pkgname-$_commit" or something like that 
2025-02-11 14:16:58 <dalias> yeah
2025-02-11 14:16:59 <dalias> thanks
2025-02-11 14:17:26 <dalias> if test build works, i'll see if i can clean it up reasonably well
2025-02-11 14:18:17 <dalias> i should probably script generating all the submodule stuff from the .gitmodules file so it's reasonably easy to upgrade
2025-02-11 14:31:29 <dalias> what dir does package() run from?
2025-02-11 14:31:49 <ikke> $builddir if it exists, else $srcdir
2025-02-11 14:37:52 <dalias> it's running from the dir with the APKBUILD file in it ..?!
2025-02-11 15:00:48 <ikke> Oh $startdir then instead of $srcdir. Make sure that $builddir exists 
2025-02-11 15:06:16 <dalias> failed at the very end with
2025-02-11 15:06:20 <dalias> >>> ERROR: openscad: Failed to create index
2025-02-11 15:06:23 <dalias> what does this mean?
2025-02-11 15:06:59 <dalias> do i have to make a silly local signing key before i can make local apks?
2025-02-11 15:11:33 <skarnet> IME yes you do
2025-02-11 15:11:55 <Habbie> dalias, here's my notes, that may or may not help https://github.com/PowerDNS/pdns/wiki/Downstream-updates:-Alpine-Linux
2025-02-11 15:11:55 <skarnet> (but that's easy)
2025-02-11 15:12:11 <Habbie> indeed abuild-keygen is in there
2025-02-11 15:12:19 <Habbie> i stuck 80% of this in a Dockerfile to simplify my life
2025-02-11 15:21:14 <dalias> thanks
2025-02-11 15:21:21 <dalias> ok the build is working now
2025-02-11 15:21:22 <dalias> :)
2025-02-11 17:28:02 <yaboyfred> Is the aports mailing list still not functional? Or any ETA on when its working again?
2025-02-11 17:33:09 <ikke> The mailing list is functional, but there's no integration with gitlab 
2025-02-11 17:33:41 <ikke> It needs someone to step in to fix it
2025-02-11 17:44:59 <wyk72> hi, I have a difficult issue compiling VDO utils for Alpine ( https://github.com/dm-vdo/vdo ). I managed to use a lot of workarounds for this code (that is VERY libc-dependent and VERY non-POSIX in macros etc.)
2025-02-11 17:45:46 <wyk72> I hit a wall here:
2025-02-11 17:46:08 <wyk72> fileLayer.c: In function 'setupFileLayer': fileLayer.c:342:26: error: overflow in conversion from 'long unsigned int' to 'int' changes value from '2148012658' to '-2146954638' [-Werror=overflow]   342 |     if (ioctl(layer->fd, BLKGETSIZE64, &bytes) < 0) 
2025-02-11 17:46:43 <wyk72> from what I've read it's an Alpine-specific issue with ioctl interface i.e.:
2025-02-11 17:46:59 <wyk72> "this is an Alpine issue, in that alpine uses musl instead of glibc, so ioctl interface requires an operation code parameter of type int (integer with a sign) instead of unsigned long (integer without a sign), and yet the kernel constants for operation code are unsigned and some of them exceed max int size, which results in an unwanted type conversion;"
2025-02-11 17:47:23 <wyk72> how can I avoid this "unwanted conversion" ??
2025-02-11 17:53:01 <wyk72> can I safely ignore the warning ?
2025-02-11 18:13:29 <wyk72> I ignored it, let's see if this thing works
2025-02-11 19:34:37 <dalias> isn't alpine policy that dev packages are supposed to include static libc?
2025-02-11 19:34:39 <dalias> libs*
2025-02-11 19:35:02 <dalias> i just found spd, fmt, and clipper are missing them :/
2025-02-11 19:39:57 <ikke> I have not heard of a policy that it's required
2025-02-11 19:43:35 <dalias> being that one reason folks like alpine is as a platform for building static binaries using musl (without having to build your own cross compiler and lib ecosystem) having static libs seems very desirable
2025-02-11 19:43:48 <dalias> in my case i just want to make binaries that wont break when i dist-upgrade
2025-02-11 20:04:10 <fossdd[m]> its done on request i think
2025-02-11 20:04:14 <fossdd[m]> but its not required
2025-02-11 20:04:45 <Ariadne> dalias: sometimes there are -static packages instead, and sometimes they aren't provided at all
2025-02-11 20:11:40 <dalias> *nod*
2025-02-11 20:12:00 <dalias> in the case of these they're tiny c++ things that should almost have been header-only, so stupid that .so's exist at all
2025-02-12 00:35:41 <pj> never heard about such policy
2025-02-12 00:36:13 <pj> it's always done at maintainers discretion
2025-02-12 09:21:31 <fossdd[m]> someone want to merge !77840?
2025-02-12 10:30:23 <fabricionaweb> are we already using the maintainer field?
2025-02-12 10:34:41 <ikke> Yes, it's already being used, but it's not mandatory 
2025-02-12 12:50:58 <jahway603[m]> can someone please merge !79806?
2025-02-12 12:54:16 <fabled> ikke, ncopa: seems edge builders on aarch64 and x86_64 are stuck on ftbfs packages such as dracut
2025-02-12 13:07:49 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/16899
2025-02-12 13:27:03 <ncopa> fabled: I'll have a look at it in a bit
2025-02-12 13:27:12 <fabricionaweb> Is it possible to increase time for riscv builder? 
2025-02-12 13:29:47 <ncopa> I think you need to increase it in your forked repo?
2025-02-12 13:30:44 <ikke> Yes
2025-02-12 13:32:42 <mio> dracut has !79742
2025-02-12 13:33:28 <mio> 1-2 others like victoria-metrics may be due to flaky tests that need multiple retries
2025-02-12 13:33:33 <ncopa> just found that. merging it
2025-02-12 13:35:48 <fabricionaweb> is it just add timeout: to build-riscv64:? hm
2025-02-12 13:43:51 <fabricionaweb> Im re-running it, maybe it pass
2025-02-12 13:50:07 <ikke> fabricionaweb: no, in your project settings 
2025-02-12 14:08:39 <fabricionaweb> ok thanks I changed, tho It wasnt the reason as it have passed now after retry
2025-02-12 14:40:07 <bl4ckb0ne> if I use a `-dev` package in an APKBUILD, should it automatically pull the base package?
2025-02-12 14:41:07 <yyp> yes
2025-02-12 14:41:10 <fossdd[m]> most -dev packages do
2025-02-12 14:41:43 <fossdd[m]> not not sure if thats specified in default_dev or somewhere else
2025-02-12 14:42:41 <bl4ckb0ne> i have a weird case of a -dev dependency that is looked for at CMake generation but is used at runtime by a command inside cmake, and I have to specify both base and -dev for the build to work
2025-02-12 14:43:13 <bl4ckb0ne> because the -dev has the pkgconf, but somewhat -dev and no base passes the generation but not the build
2025-02-12 15:20:50 <bl4ckb0ne> took me some time but !71645 is up for review if anybody has eyes to spare 
2025-02-12 15:21:07 <bl4ckb0ne> should enable qsv for jellyfin 
2025-02-12 16:04:31 <fossdd[m]> oh nice!
2025-02-12 16:13:33 <fossdd[m]> took a quick look, really cool! i think some patches are also pretty easy to upstream, right?
2025-02-12 16:14:04 <bl4ckb0ne> i think a few are but im lacking time, and some other are just disabling backtrace stuff
2025-02-12 16:14:11 <bl4ckb0ne> thanks for your feedback fossdd[m] 
2025-02-12 16:14:33 <fossdd[m]> yeah understandable
2025-02-12 16:17:37 <bl4ckb0ne> the intel-graphics-compiler is going to get trimmed down, they are working on using llvm16 and up soon
2025-02-12 16:18:24 <bl4ckb0ne> i didnt get your comment about shipping LICENSE for MIT
2025-02-12 16:21:06 <fossdd[m]> i think for MIT licenses, its legally required to distribute the license together with the binaries, e.g. a `install -Dm644 LICENSE.md "$pkgdir"/usr/share/license/$pkgname`
2025-02-12 16:21:20 <fossdd[m]> * -Dm644 LICENSE.md -t "$pkgdir"/usr/share/license/$pkgname`
2025-02-12 16:23:53 <bl4ckb0ne> i dont see a lot of packages doing that
2025-02-12 16:56:49 <WhyNotHugo> If I want to submit the same update to both master and 3.21-stable, I need to open two separate MRs, right? There's no way to "tag" on as "also cherry-pick for 3.21-stable"?
2025-02-12 16:57:51 <ikke> correct
2025-02-12 17:28:33 <ncopa> would be nice with a tag 'backport-3.21' and a bot that would create a MR with the cherry-pick
2025-02-12 17:28:43 <ncopa> we have that for k0s in github
2025-02-12 17:29:03 <ikke> Yes
2025-02-12 17:57:49 <fossdd[m]> yes thought that too, nixos have that too
2025-02-12 17:58:25 <fossdd[m]> but i think the bot would learn how to resolve basic merge conflicts like pkgver/pkgrel change
2025-02-12 18:03:05 <ncopa> it can just error on those, initially
2025-02-12 18:03:50 <ncopa> but that kinda explains where it came from in k0s. the dev is a nix user :)
2025-02-12 18:04:04 <fossdd[m]> ahh haha
2025-02-12 18:04:24 <fossdd[m]> but i think thats important to make MRs more sustainable
2025-02-12 18:04:53 <fossdd[m]> nixos has always more than 5k concurrent PRs
2025-02-12 18:05:52 <fossdd[m]> seems like they use this github action: https://github.com/korthout/backport-action
2025-02-12 18:08:00 <bl4ckb0ne> fossdd[m]: I have addressed everything except the MIT stuff, which im not 100% sure about 
2025-02-12 18:08:44 <ikke> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license
2025-02-12 18:09:43 <bl4ckb0ne> alrighty, will do then
2025-02-12 18:09:52 <bl4ckb0ne> just -doc is enough to copy it automatically?
2025-02-12 18:10:05 <ikke> You do need to make sure it's in $pkgdir
2025-02-12 18:10:51 <Ariadne> hi
2025-02-12 18:12:13 <fossdd[m]> hi
2025-02-12 18:14:47 <ncopa> hi
2025-02-12 18:16:35 <ncopa> seems like we have an issue with x86_64 go in 3.21-stable
2025-02-12 18:18:21 <bl4ckb0ne> should be addressed now, thanks
2025-02-12 18:21:57 <fossdd[m]> oh there is already a open issue https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/20
2025-02-12 18:44:35 <fossdd[m]> ncopa: can you take a look at https://github.com/alpinelinux/docker-alpine/pull/391?
2025-02-12 18:44:55 <fossdd[m]> have been redirecting people to the aports issue tracker since they didnt know better and i think that could help
2025-02-12 19:38:54 <WhyNotHugo> I notice that a lot of APKBUILD use `rf -rf`. Isn't `rf -r` preferrible? Or are package() functions intended to be kept re-entrant?
2025-02-12 20:31:45 <ncopa> I think rm -r is preferred so we know when that line can be removed
2025-02-12 23:04:29 <fossdd[m]> hmm i wonder how something like !79944 can be prevented
2025-02-12 23:04:42 <fossdd[m]> maybe reviewing after the rebase, but that involves a lot more time i think
2025-02-12 23:22:29 <khem> could be good if build systems could detect the dependency automatically and manual bump is not needed 
2025-02-13 04:11:43 <ikke> khem: a pkgrel bump is required for a rebuild for various reasons
2025-02-13 05:49:40 <Saijin_Naib[m]> !79950 is a pretty straightforward bump, if anyone wants to reviewit
2025-02-13 06:23:44 <Saijin_Naib[m]> Is there a canonical APKBUILD template for Go projects?
2025-02-13 06:23:57 <Saijin_Naib[m]> newapkbuild doesn't have a flag for Go projects, and I am not familiar with them
2025-02-13 06:24:01 <Saijin_Naib[m]> I want to package sonicradio
2025-02-13 06:24:06 <Saijin_Naib[m]> https://github.com/dancnb/sonicradio/releases/tag/v0.6.4
2025-02-13 06:26:48 <ikke> seems to be as simple as `go build .` in build and `install -Dm0755 sonicradio "$pkgdir"/usr/bin/sonicradio` in package
2025-02-13 06:32:33 <Saijin_Naib[m]> ikkeooh, okay, I'll give that a.... Go
2025-02-13 06:32:36 <Saijin_Naib[m]> hurhurhur
2025-02-13 07:20:29 <Saijin_Naib[m]> It was that easy, ikke, thanks!
2025-02-13 07:20:41 <Saijin_Naib[m]> Now I'm going to try bumping greybird theme
2025-02-13 07:30:37 <Saijin_Naib[m]> woof, that is a bigger undertaking... switching from just moving etc to meson
2025-02-13 09:00:32 <fabricionaweb> hi, morning, who could merge this? !78515 
2025-02-13 09:42:02 <lotheac> i would also appreciate !78944 !78838 merges
2025-02-13 10:36:35 <donoban> anyone knows how to loop an string "word1 word2 wordX" on ash? All I find seems bash based or too uggly
2025-02-13 10:38:26 <fossdd[m]> for x in word1 word2 wordX; do echo $x; done
2025-02-13 10:38:31 <fossdd[m]> or what do you mean?
2025-02-13 10:39:06 <donoban> I mean, foo="word1 word2 word3"
2025-02-13 10:39:10 <donoban> for x in $foo...
2025-02-13 10:39:16 <donoban> but I can change it
2025-02-13 10:39:24 <donoban> will pass directly the words
2025-02-13 10:39:46 <fossdd[m]> should also work with a variable
2025-02-13 10:39:57 <donoban> it takes the whole string as 1 element
2025-02-13 10:40:45 <fossdd[m]> also if you dont quote $foo?
2025-02-13 10:40:54 <donoban> hmm. ouch
2025-02-13 10:40:59 <donoban> probablty was that
2025-02-13 10:41:00 <fossdd[m]> so not `for x in "$foo"` but `for x in $foo`
2025-02-13 10:41:04 <fossdd[m]> yea
2025-02-13 10:41:08 <donoban> but look: https://tpaste.us/4vzJ
2025-02-13 10:41:14 <donoban> no need to use a var, right?
2025-02-13 10:41:31 <fossdd[m]> yes that should work
2025-02-13 10:46:59 <donoban> I think it's best approach !79781
2025-02-13 11:51:19 <fossdd[m]> i feel like this is really flaky
2025-02-13 11:51:33 <fossdd[m]> but not sure
2025-02-13 11:56:27 <skarnet> uh, pgrepping to know that something is running is a terrible idea
2025-02-13 11:57:38 <skarnet> if you want a marker that says some process is running, have it coded in the service manager by policy, e.g. touch a file when the power manager service starts and delete when it stops, etc.
2025-02-13 11:58:05 <skarnet> pgrep is almost never a reliable solution
2025-02-13 11:59:06 <skarnet> (any user can run a script that sleeps forever and that they call gnome-power-manager, and that will defeat the snippet)
2025-02-13 12:07:56 <donoban> hmm...
2025-02-13 12:11:37 <donoban> maybe force the grep to only check /usr/bin/xxx? I undertand your point but that would need that all managers share the same logic, and many are not a rc service, just executed on desktop startup... it seems too much complex
2025-02-13 12:29:25 <donoban> it seems that busybox pgrep is not capable of that
2025-02-13 12:31:40 <fossdd[m]> i think this is anyway not a proper solution for the actual problem no?
2025-02-13 12:31:46 <donoban> ah anyway you mean to call the real power manager, I understand to use a script with the same name
2025-02-13 12:32:18 <donoban> fossdd[m]: in what sense?
2025-02-13 12:52:10 <staceee> guys, on one machine, I got /sbin/acpid that burn 100% on one thread. What can cause this?
2025-02-13 12:54:06 <staceee> my firmware is spaming acpi events I guess?
2025-02-13 13:40:14 <sertonix[m]> Can you figure out the pid of acpid and the do ls -l /proc/<pid>/fd ? Is there any entry that shows as deleted?
2025-02-13 13:42:21 <sertonix[m]> staceee: ^
2025-02-13 13:44:48 <jahway603[m]> can someone please merge !79806?
2025-02-13 14:21:40 <staceee> sertonix[m]: I rebooted to fix this, but if I struggled again with this, I'll do so
2025-02-13 14:38:00 <sertonix[m]> staceee: You can also take a look at https://gitlab.alpinelinux.org/alpine/aports/-/issues/15987 when this happens again
2025-02-13 14:39:49 <staceee> ah interesting
2025-02-13 14:39:51 <staceee> I'll track this
2025-02-13 15:15:55 <fossdd[m]> im thinking of a reference packaging manual which could serve as packaging guidelines
2025-02-13 15:16:34 <fossdd[m]> something similar like https://github.com/chimera-linux/cports/blob/master/Packaging.md or https://docs.fedoraproject.org/en-US/packaging-guidelines/
2025-02-13 15:17:45 <fossdd[m]> there is https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package but ive found it very lacking and a proper maintained guide could help it
2025-02-13 15:19:29 <fossdd[m]> like a manual that could explain all basic like APKBUILD, repositories, backporting, building with best practices for different stuff, example APKBUILD for different build systems/programming languages
2025-02-13 15:37:47 <Saijin_Naib[m]> @fossdd that sounds incredible
2025-02-13 15:48:37 <janvhs> Omg I was wondering why the alpine-devel channel was dead… I was in the libera.chat one 🤦 anyways here we go
2025-02-13 15:48:47 <janvhs> Hey I want to spend some time during work to contribute to the Alpine project, since it’s my main OS I use during work anyway. I saw some talk about wanting to replace OpenRC with skarnet‘s s6 and would be interested in helping. I wasn’t able to find code for the effort, tho. Can someone point me to it?
2025-02-13 15:50:35 <fossdd[m]> its pretty slowed down because its quite difficult
2025-02-13 15:50:41 <fossdd[m]> see https://gitlab.alpinelinux.org/alpine/tsc/-/issues/84 and https://gitlab.alpinelinux.org/alpine/tsc/-/issues/78
2025-02-13 15:51:17 <khem> https://github.com/skarnet/s6
2025-02-13 15:51:25 <fossdd[m]> i dont think the default is going away anytime soon
2025-02-13 15:51:38 <skarnet> janvhs: I still need to work on the openrc support for s6
2025-02-13 15:51:40 <fossdd[m]> but feel free to contribute to s6 or alpine in some other way!
2025-02-13 15:51:56 <skarnet> it was basically stuck for a few months but I should resume it soon
2025-02-13 15:52:02 <fossdd[m]> ah nice
2025-02-13 15:52:18 <skarnet> I'll keep yall informed when I have news (doesn't only depend on me)
2025-02-13 15:52:29 <fossdd[m]> it would be nice to see alpine being more flexible regarding the init system
2025-02-13 15:52:49 <skarnet> agreed, but since openrc is maintained these days there's less urgency
2025-02-13 15:52:58 <janvhs> alrighty, that explains a lot. I’ve noticed some script in my /etc/init.d for s6. What’s up with that?
2025-02-13 15:53:10 <khem> although init systems are quite near the backbone of the distros 
2025-02-13 15:54:02 <skarnet> janvhs: it's the old openrc way of supporting s6, it's more or less obsolete, you can ignore it - making it up to date is one of the things I need to work on
2025-02-13 15:54:08 <fossdd[m]> skarnet: yes for sure. nice seeing openrc having progress again
2025-02-13 15:54:10 <janvhs> fossdd[m]: yeah that would be nice, but I don’t know if that’s really feasible, since it’s a lot of duplicated effort. I think Artix is doing something like this?
2025-02-13 15:54:31 <skarnet> yeah and they have one guy who put in *a lot* of effort doing it
2025-02-13 15:54:39 <skarnet> it doesn't come for free
2025-02-13 15:54:51 <janvhs> definitely not lol
2025-02-13 15:56:29 <janvhs> Cool thank you. Is there anything in Alpine that needs addressing? Not quite sure what I could help with otherwise (except for one or two things with setup-alpine and XFCE packages)
2025-02-13 15:58:01 <fossdd[m]> help is always welcome! :3
2025-02-13 15:58:11 <fossdd[m]> there is https://wiki.alpinelinux.org/wiki/Alpine_Linux:Contribute for some ideas
2025-02-13 15:58:39 <janvhs> Thank you fossdd[m] :3
2025-02-13 16:36:17 <Saijin_Naib[m]> @janvhs oooh, what xfce packages? I have been trying to package the few we are missing, but they are a bit tough for me
2025-02-13 16:51:27 <janvhs> Saijin_Naib[m]: No it was more about setup-desktop not producing a fully functional XFCE desktop
2025-02-13 17:17:20 <durrendal> a quick question for the group, I want to backport woodpecker 3.0.1 to 3.21 since 2.8.0 seems to keep getting stuck on the builders. However since the go rebuilds bumped the package I can't just reuse the commit from my upgrade MR. Is it acceptable to bump the package to get a clean commit to cherry pick from?
2025-02-13 17:19:04 <fossdd[m]> you could resolve the conflict or amend the commit, or?
2025-02-13 17:20:45 <durrendal> that's a good point, perhaps I'm overthinking this
2025-02-13 17:21:12 <abby> fyi: https://www.openwall.com/lists/musl/2025/02/13/1
2025-02-13 17:25:20 <fossdd[m]> !79993
2025-02-13 17:31:24 <fossdd[m]> and !79994 !79995 !79996 !79997 :)
2025-02-13 17:31:49 <dne> \o/
2025-02-13 18:56:06 <Saijin_Naib[m]> @janvhs what is missing still? udisks2, xfce4-notifyd? 
2025-02-13 20:45:43 <f00860> Hi! Having problems running the pipeline for a package: https://gitlab.alpinelinux.org/f86/aports/-/jobs/1729586
2025-02-13 20:46:16 <f00860> I've asked upstream, because it looks like it is related to an incompatibility with arm hardware
2025-02-13 20:46:28 <f00860> https://github.com/moosefs/moosefs/issues/636
2025-02-13 20:47:18 <f00860> They've checked (they even bought arm hardware to test it), but everything worked fine. So the pipeline is doing something special
2025-02-13 20:52:33 <ikke> Not sure if it matters, but it's running on aarch64 with linux32
2025-02-13 20:58:15 <psykose> you can cause bus errors without assembler fine
2025-02-13 20:58:45 <psykose> running arm32 on arm64 makes some unaligned stuff that is valid on native arm32 give a bus error
2025-02-13 21:20:03 <ncopa> sigh, I have a problem
2025-02-13 21:20:12 <ncopa> ape-tools 2.14.10
2025-02-13 21:20:18 <ncopa> we need back port it to stable branches
2025-02-13 21:20:23 <ncopa> but it breaks the ABI
2025-02-13 21:21:09 <ncopa> if people link to libapk.so in their own homebuilt stuff, things will break
2025-02-13 21:21:32 <ncopa> or if they use dlopen of cffi, like we do for our sec fixes site
2025-02-13 21:21:34 <ncopa> things will break
2025-02-13 21:21:47 <ncopa> not sure what to do
2025-02-13 21:22:03 <ncopa> and I should have pushed new release tonight, due to musl and 0penssl CVE
2025-02-13 21:26:55 <ncopa> not sure what to do
2025-02-13 21:28:23 <Ermine> why do you need to backport it though?
2025-02-13 21:30:28 <ncopa> it fixes a few regressions
2025-02-13 21:30:55 <ncopa> maybe I'll just cherrypick the fixes that does not break ABI
2025-02-13 21:56:50 <f00860> <psykose> "running arm32 on arm64 makes..." <- So, ho can I proceed on this? Disable the tests for the package?
2025-02-13 22:10:05 <ncopa> fcolista: I think the gtest rebuilds broke a few builds. https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/net-cpp/net-cpp-3.1.1-r3.log
2025-02-13 22:10:29 <ncopa> seems like mio already fixed kconfig
2025-02-13 22:17:07 <mio> maintainer of net-cpp is already looking into it
2025-02-13 22:17:58 <fossdd[m]> good
2025-02-13 22:17:58 <mio> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80014#note_481222
2025-02-13 22:19:26 <ncopa> thanks!
2025-02-13 22:29:50 <mio> :) just passing on the message to the respective maintainers
2025-02-13 22:35:07 <ncopa> thank you for following up!
2025-02-13 22:53:12 <Ariadne> ncopa: how does secfixes site break with new libapk?  i think our use of libapk is only relating to version comparison
2025-02-13 22:55:59 <ncopa> https://gitlab.alpinelinux.org/alpine/security/secfixes-tracker/-/blob/master/secfixes_tracker/version.py?ref_type=heads#L11
2025-02-13 22:56:21 <ncopa> it will try open an non-existing file
2025-02-13 22:56:25 <ncopa> that got renamed
2025-02-13 22:56:37 <Ariadne> ah
2025-02-13 22:56:50 <Ariadne> we could require apk-tools-dev for secfixes site and just open libapk.so instead
2025-02-13 22:57:02 <ncopa> I did a proper py3 module for apk3
2025-02-13 22:57:37 <ncopa> similar to the one we do for Lua
2025-02-13 22:57:45 <ncopa> and its built with apk-tools itself
2025-02-13 23:00:03 <Ariadne> that is better, maybe we can backport it instead?
2025-02-13 23:00:28 <ncopa> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11062
2025-02-13 23:00:45 <ncopa> i dont think I will do the apk-tools upgrade today
2025-02-13 23:05:55 <ncopa> drags!
2025-02-13 23:05:58 <ncopa> drats!
2025-02-13 23:06:03 <ncopa> i tagged 3.21.3
2025-02-13 23:06:12 <ncopa> but forgot a bug fix to alpine-conf
2025-02-13 23:06:27 <ncopa> i hate doing releases with stress
2025-02-13 23:06:29 <ncopa> late night
2025-02-13 23:10:06 <ncopa> phew.. it was tiny-cloud, not alpine-cone. and the fix is in
2025-02-14 00:00:53 <ncopa> does this look good? https://wwwtest.alpinelinux.org/posts/Alpine-3.18.12-3.19.7-3.20.6-3.21.3-released.html
2025-02-14 00:06:09 <Ariadne> looks good to me!
2025-02-14 00:23:56 <ncopa> thanks!
2025-02-14 07:15:36 <fcolista> morning all
2025-02-14 07:21:19 <fcolista> mio, thank you for following up the gtest thing
2025-02-14 07:21:28 <fcolista> which packages are still broken?
2025-02-14 10:00:51 <strophy> Hi! I have been contributing a bit to packages related to the grpc and protobuf ecosystem in Alpine since I have a bit of a quiet week. I'm currently blocked on grpc waiting for a review updating a dependency, could someone please help out? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79935 Thanks!
2025-02-14 10:16:03 <f00860> I'm also searching for a volunteer who wants to review/merge my MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78907
2025-02-14 10:18:50 <fabricionaweb> looks good, I notice its a major bump, and the dev have also been there, great, just need the maintainer, idk if they still active
2025-02-14 10:22:07 <fabricionaweb> I also look for an update on mine !78515 
2025-02-14 10:38:49 <fabricionaweb> thanks for reviewing it f00860 / aron (is it you right?)
2025-02-14 11:10:15 <pltrz[m]> Hello! I am not sure if the developer assigned to !70759 (jirutka?) is still reviewing? It's been pending a developer's action for a while. Not sure the protocol, after I pinged the devs who were involved in the MR discussion a few weeks ago. Kindly requesting advice on how to proceed.
2025-02-14 12:49:21 <mio> fcolista: at the moment - flann, nix (there's already an open MR with a potential fix)
2025-02-14 12:52:21 <mio> (maintainer has been working on it, so not sure if it's ready)
2025-02-14 15:21:15 <fcolista> bah I can't figure why flann fails
2025-02-14 15:22:08 <fcolista> is in testing and also last release is from 2021
2025-02-14 15:22:19 <fcolista> wondering if it makes sense to disable test and go ahead
2025-02-14 15:22:26 <fcolista> since it's blocking the buidler
2025-02-14 15:23:31 <mio> fcolista: this might be one reason https://github.com/flann-lib/flann/issues/524 seems the BUILD_TESTS flag doesn't work
2025-02-14 15:23:45 <fcolista> I saw that
2025-02-14 15:23:56 <fcolista> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/flann/flann-1.9.2-r0.log
2025-02-14 15:24:21 <fcolista> if you see an old one, the "No tests were found" was also before
2025-02-14 15:24:26 <mio> yeah
2025-02-14 15:24:48 <mio> does the distutils thing affect the package functionality?
2025-02-14 15:25:05 <fcolista> not sure
2025-02-14 15:26:01 <fcolista> i think no though
2025-02-14 15:26:06 <fcolista> never used flann
2025-02-14 15:26:38 <mio> maybe disable the test for now?
2025-02-14 15:26:48 <mio> s/the test/tests/
2025-02-14 15:27:05 <fcolista> that's what I was saying
2025-02-14 15:27:29 <PureTryOut> I didn't read this conversation and already did 😅
2025-02-14 15:27:36 <mio> lol
2025-02-14 15:27:40 <fcolista> :D
2025-02-14 15:28:14 <mio> okay, thanks both for looking into it
2025-02-14 15:34:09 <mio> ayatana-indicator-datetime might need to a test skipped. couldn't reproduce the test failure locally on x86_64, hoping it just needs a few more retries
2025-02-14 15:35:45 <mio> to pass on the x86_64 builder, that is
2025-02-14 16:03:39 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80048
2025-02-14 16:04:16 <fcolista> uff..it fails on s390x..
2025-02-14 16:45:03 <fossdd[m]> [@_oftc_mick_ib__:matrix.org](https://matrix.to/#/@_oftc_mick_ib__:matrix.org) can maybe help
2025-02-14 16:48:02 <ikke> iirc mick only does ppc64, not s390x
2025-02-14 18:21:12 <fossdd[m]> ah didnt know that
2025-02-14 19:28:00 <donte> https://www.donte.net/
2025-02-14 22:25:25 <jahway603[m]> Does !79806 need to be "Approved" or can it get merged?
2025-02-15 03:25:01 <dalias> is wxwidgets opengl supposed to be working ?
2025-02-15 03:25:35 <dalias> afaict it's built with EGL option which inhibits/breaks GLX, but EGL doesn't actually work
2025-02-15 08:52:10 <jahway603[m]> Can someone please merge !79806?
2025-02-15 11:10:55 <fcolista> mio, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80079
2025-02-15 11:11:21 <fcolista> I assigned this MR to the maintainer
2025-02-15 11:11:47 <fcolista> this package is outdated, anyway
2025-02-15 11:20:20 <donoban> ey guys not a big deal but I think that it will help the s
2025-02-15 11:21:28 <donoban> usage of alpine as a desktop, what do you think about change default power button behaviour if it's running on a laptop? !79781 I don't see that it will hurt and could prevent many situations where the user shutdowns accidentally 
2025-02-15 11:38:01 <henrix> donoban: +1 on that *but* I don't think that test is reliable
2025-02-15 11:38:24 <henrix> for ex, my laptop has '/proc/acpi/button/lid/LID1', not '/proc/acpi/button/lid/LID'
2025-02-15 11:39:20 <henrix> maybe [ -e /proc/acpi/button/lid/*/state ] would be better...?
2025-02-15 11:39:55 <donoban> oh yeah
2025-02-15 11:40:29 <donoban> maybe just test the path '/proc/acpi/button/lid'
2025-02-15 11:40:49 <henrix> yeah, that should be fine too I guess
2025-02-15 11:41:28 <henrix> (I know there are other scripts that need a similar fix... but I time is a very limited resource these days :-/ )
2025-02-15 11:42:01 <donoban> scripts inside aports?
2025-02-15 11:45:51 <henrix> yeah, for ex in acpid, file /usr/share/acpid/lid-closed
2025-02-15 11:46:15 <donoban> ok I will take a look
2025-02-15 11:47:27 <henrix> thanks. I think there are other places. my TODO list had a 'FIX THIS' for quite some time but yeah...
2025-02-15 12:03:12 <donoban> hehe todo list is for that, you can't do everything but always will do more that without it
2025-02-15 12:03:21 <donoban> than*
2025-02-15 12:55:49 <donoban> henrix: probably needs something like: STATE_FILE=$(find /proc/acpi/button/ -name state)
2025-02-15 12:56:10 <donoban> or better.. STATE_FILE=$(find /proc/acpi/button/lid -name state)
2025-02-15 12:58:28 <donoban> imo that script should be deleted and just move code to handler.sh
2025-02-15 12:58:53 <donoban> handler.sh currently both uses the script and directly:  if [ -e /proc/acpi/button/lid/LID ]; then
2025-02-15 13:01:30 <donoban> I don't see anything more using that scripts on aports
2025-02-15 14:48:13 <fossdd[m]> !79741 is ready to merge
2025-02-15 14:48:52 <fossdd[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79741
2025-02-15 15:12:31 <f00860> Any change to get !78907 merged?
2025-02-15 15:30:33 <jahway603[m]> !79806 is ready to merge
2025-02-15 15:30:50 <jahway603[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79806
2025-02-15 16:17:32 <donoban> crash again with last kernel :\
2025-02-15 16:42:42 <fossdd[m]> which kernel package + version?
2025-02-15 16:42:49 <fossdd[m]> and alpine release
2025-02-15 17:02:13 <donoban> last on edge
2025-02-15 17:03:34 <donoban> I'm running kernel from v3.21 since some days ago but today I decided to test last again with this #16913
2025-02-15 17:21:39 <dalias> does apk have a way to set in world a set of packages you want to ensure are never installed?
2025-02-15 17:22:43 <durrendal> apk add !neovim
2025-02-15 17:23:13 <durrendal> but, that'll just purge the package if it's installed. You could still apk add neovim
2025-02-15 17:23:38 <durrendal> so maybe only part of the solution unfortunately
2025-02-15 17:25:09 <durrendal> when you apk add !$apk it does get inserted into world as !$apk, so a small wrapper on top of apk to check for such packages could maybe work? Or a meta package that lists all the packages you never want as depends="!$apk !$apk" might be a better solution
2025-02-15 17:25:23 <dalias> i don't mean preventing intentional apk add
2025-02-15 17:25:24 <durrendal> since then with the meta package installed any item listed in the depends could conflict
2025-02-15 17:25:31 <dalias> rather, preventing it from getting pulled in as a dep
2025-02-15 17:25:33 <dalias> so i think this owrks
2025-02-15 17:25:43 <dalias> it would show !foo as a conflict, right?
2025-02-15 17:26:05 <dalias> intended application: apk add !polkit
2025-02-15 17:27:00 <durrendal> I believe that might work
2025-02-15 17:27:33 <durrendal> let me test real quick
2025-02-15 17:30:07 <dalias> because i'm always paranoid that installing some desktop app is gonna pull in polkit and put a giant gaping rootkit on my box
2025-02-15 17:31:31 <durrendal> hmm it doesn't seem to work when I try
2025-02-15 17:32:26 <durrendal> I tried apk add !polkit-netlogind-libs which is a depends of xfce-polkit. When I apk add xfce-polkit it overwrites the !polkit-netlogind-libs
2025-02-15 17:33:30 <durrendal> I do think adding it to a meta package would work though. I deconflict the saltstack sts and lts builds by adding !salt (and all of it's subpackages) to the depends for salt-lts and they do deconflict
2025-02-15 17:33:58 <durrendal> so if you were to hunt down all the polkit related packages and show them into a depends=!polkit !polkit-common ..." statement it should conflict after install
2025-02-15 17:34:08 <durrendal> should, I didn't actually test :)
2025-02-15 17:35:15 <donoban> hmm... it seems broken, I would swear it worked before
2025-02-15 17:35:38 <donoban> other alternativa is add a virtual empty package?
2025-02-15 17:37:05 <dalias> better might be an empty meta package that "provides" polkit
2025-02-15 17:37:20 <ikke> apk add -t polkit
2025-02-15 17:37:25 <dalias> ikke, :)
2025-02-15 17:38:14 <dalias> is the main "polkit" package the one that actually includes the suid binary or dbus activation or whatever?
2025-02-15 17:38:20 <durrendal> -t, that's a new one for me. very neat
2025-02-15 17:38:47 <dalias> durrendal, -t is to make virtual packages. very useful to make a virtual package for all the build-deps of something you want to build
2025-02-15 17:38:54 <ikke> durrendal: apparently it only contains /usr/lib/polkit-1/polkitd
2025-02-15 17:38:54 <dalias> then you can just remove it to clean up after
2025-02-15 17:39:16 <donoban> I have no idea what happened here https://tpaste.us/qYN4
2025-02-15 17:39:36 <donoban> it installed an alternative?
2025-02-15 17:40:06 <donoban> makes sense https://tpaste.us/N5wq
2025-02-15 17:40:41 <durrendal> dalias: I can definitely see the use for it. Will definitely add it to the toolkit :)
2025-02-15 17:40:52 <donoban> ikke: and what does !package?
2025-02-15 17:40:52 <ikke> It's exactly what abuild uses
2025-02-15 17:41:40 <ikke> !package is meant to mark package as conflicting
2025-02-15 17:42:12 <donoban> but i end installed anyway?
2025-02-15 17:42:16 <donoban> i/it
2025-02-15 17:42:45 <durrendal> ikke: that makes sense, since it's just the -libs that was installed in that scenario.
2025-02-15 17:43:06 <dalias> the libs shouldn't be harmful
2025-02-15 17:43:11 <durrendal> donoban: I think it might be because it's not a conflict of a specific package. Since nothing depends on the conflict not existing apk can just overwrite it
2025-02-15 17:43:15 <dalias> it's the service that's harmful
2025-02-15 17:43:23 <dalias> because it hands out root like halloween candy
2025-02-15 17:46:50 <donoban> https://tpaste.us/xDKv here works as I remebered
2025-02-15 17:47:10 <donoban> imo something weird happens in the oher case
2025-02-15 17:48:38 <donoban> if I block both polkit libs I refuses to install too https://tpaste.us/yBo0
2025-02-15 17:49:24 <donoban> ah, so it just installed the nelogind version isntead the elogind
2025-02-15 17:50:24 <donoban> there is no problem with !, what is the advantage of using -t?
2025-02-15 17:56:05 <ikke> Both approaches would work
2025-02-15 18:00:45 <donoban> ok
2025-02-15 18:02:15 <dalias> the -t approach makes packages that depend on the banned package install fine and maybe break at runtime
2025-02-15 18:02:31 <dalias> the ! approach should make packages that depend on the failed package fail to install with a conflict error
2025-02-15 18:02:46 <dalias> so depends on which behavior you want
2025-02-15 18:04:40 <donoban> ahh I see
2025-02-15 18:44:46 <mio> fcolista: thanks, will close mine in favour of that then, seems the existing upgrade MR might not be ready yet
2025-02-15 18:46:59 <mio> your fix is better :)
2025-02-15 19:06:19 <f00860> !78907 is ready to merge.
2025-02-15 19:12:10 <mio> fcolista: actually, for nix looks like the maintainer's upgrade MR is good to go, just got a reply in !77820
2025-02-15 19:13:05 <mio> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77820
2025-02-15 19:17:11 <mio> left a MR for maintainer of include-what-you-use, the main one left to unblock is pcl
2025-02-15 19:29:06 <ikke> !78907
2025-02-16 04:30:09 <dalias> are there any apps using opengl thru wxwidgets in aports?
2025-02-16 04:30:54 <dalias> (successfully)
2025-02-16 04:31:00 <dalias> i suspect it's entirely broken in the build for alpine but i'd like to make sure
2025-02-16 08:12:54 <quinq> dalias, I'm able to build and run some opengl sample from their sources at least
2025-02-16 08:39:17 <kaathewise> Good day!  The Nushell PR was a draft for a few days, so it might've fallen through
2025-02-16 08:40:22 <kaathewise> I wanted to ask if anyone with merge rights could take a look at it if they have the time.  Thanks in advance!
2025-02-16 08:40:24 <kaathewise> !79538
2025-02-16 09:50:20 <donoban> hmm.. I think that yesterday tested something very similar to this: https://tpaste.us/YqVZ but it installed swaylock (then failed to exec due missing symbols obv)
2025-02-16 09:50:38 <donoban> why it doesn't install swaylock now? 
2025-02-16 09:56:19 <vkrishn> getting this issue, probably needs some pkg to install, https://tpaste.us/5QMB 
2025-02-16 10:15:19 <vkrishn> nm, did, apk add lxc-templates-legacy-alpine, works
2025-02-16 10:23:22 <vkrishn> now, i can login as root also via, lxc-console -n guest1
2025-02-16 10:38:06 <vkrishn> q
2025-02-16 10:52:56 <dalias> quinq, and it runs?
2025-02-16 10:55:28 <quinq> Yeah, it shows the 3D pyramid 
2025-02-16 10:55:54 <quinq> dalias, is there something specific you're trying to run? (I could try reproducing here)
2025-02-16 10:57:21 <quinq> (on edge/amd64)
2025-02-16 11:01:00 <dalias> im trying to build prusaslicer agsinst it and getting no gl (fail to init glew)
2025-02-16 11:13:34 <quinq> There's a million deps :(
2025-02-16 11:16:28 <quinq>   cmake/modules/FindOpenVDB.cmake:367 (just_fail)
2025-02-16 11:16:40 <quinq>   IlmBase::Half can not be found!
2025-02-16 11:16:41 <quinq> meh
2025-02-16 11:18:22 <dalias> yes
2025-02-16 11:18:29 <dalias> its hell to build
2025-02-16 11:19:47 <dalias> what i did to test was use the supplied dep builder after rm'ing all the ones i could get as pkgs
2025-02-16 12:15:23 <herta> ncopa: what do you think of https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78703#note_476391 ? Since the support for reboot was merged, does it make sense to add it to inittab in edge? I think this would be useful as documentation for why this patch was made in the first place. And of course, so that people don't edit inittab manually if they need the reboot function.
2025-02-16 14:07:32 <vkrishn> i don't know how to add it to an ISSUE as wiki docs are not clear in steps, i am unable to root login using `lxc-console -n guest1` 
2025-02-16 14:07:50 <vkrishn> when i use `lxc-create -n guest1 -f /etc/lxc/default.conf -t download` but login is ok if installed using, lxc-create -n guest1 -f /etc/lxc/default.conf -t alpine
2025-02-16 14:08:34 <vkrishn> seems also some diff in what pkgs are installed in rootfs, by both process
2025-02-16 14:20:53 <vkrishn> might be by design, created a user (setup-user) and used su
2025-02-16 15:29:09 <vkrishn> lxc-templates-legacy-alpine probably needs an update
2025-02-16 18:23:01 <DavidHeidelberg> ptrc: heya, simple click, test and CI green: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80089
2025-02-17 01:18:51 <dalias> ok wtf..
2025-02-17 01:19:29 <dalias> how/why did alpine firefox open this on start? https://www.mozilla.org/en-US/firefox/welcome/23/
2025-02-17 07:42:05 <donoban> lol, it remember XScreenSaver on debian
2025-02-17 08:36:44 <WhyNotHugo> When a package ships a file in protected_paths.d and also ships a file matching an expression there, that rule should apply properly, right?
2025-02-17 08:37:04 <WhyNotHugo> Or are rules referrencing the same package somehow ommitted due to the rule being updated along with the package?
2025-02-17 08:37:10 <WhyNotHugo> Contxt: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16912#note_481647
2025-02-17 08:47:16 <fabricionaweb> if I want to rename a package, do I need to set the provides=oldname to backwards compatibility?
2025-02-17 09:44:55 <fabricionaweb> are we holding new aports? Thinking in new policy or something? 
2025-02-17 10:57:09 <apalos> What's the usual process of updating a kernel config ? Pathes?
2025-02-17 10:57:36 <apalos> There's patches flying aropund in U-Boot, where we can boot an .sio over https directly
2025-02-17 10:58:11 <apalos> It works only  EFI for now, but we can launch an OS we downloaded in RAM and in order to do so, we need a handful of kernel modules to be around
2025-02-17 11:03:10 <ovf> release-monitoring.org integration is toast? e.g. https://release-monitoring.org/project/141621/ lists 1.37.0 but https://pkgs.alpinelinux.org/packages?name=imhex has 1.36.2 as up-to-date
2025-02-17 12:13:41 <apalos> q
2025-02-17 12:16:17 <quinq> yesh?
2025-02-17 12:17:49 <apalos> wrong vim window :)
2025-02-17 12:49:56 <quinq> ;)
2025-02-17 13:42:27 <vkrishn> it might be possible to get an lxc guest started using alpine-minirootfs with a few lines of wrapper script (as there is some difference in etc/ files) :)
2025-02-17 17:37:33 <Ermine> bl4ckb0ne: w-p mr is ready for you, !80177
2025-02-17 18:03:41 <bl4ckb0ne> thanks!
2025-02-18 07:39:39 <raspbeguy> Hello, could someone have a look on !78807 !74517 !72559 !79858 !80181 please?
2025-02-18 12:48:09 <markand> and then when someone has time too on !79397 it will get few retro enthusiasts enjoying alpine / postmarketos more :)
2025-02-18 15:40:43 <fabricionaweb> I also have one that I need to run, Im building it local while its not merged !78515
2025-02-18 16:00:19 <hcs-hmk> I think I've found a little mishap with the kernel config. Between alpine 3.20 and 3.21, a whole bunch of USB_NET modules were silently dropped from the config. The one that affects me specifically is CONFIG_USB_NET_QMI_WWAN=m, but there are 14 others which are also not present on 3.21.   Is there a reason for this, or was it just an oversight?
2025-02-18 16:10:59 <hcs-hmk> Since the modules have been there since 3.16 and likely earlier,  were plucked out in 3.21, then readded in edge/master, I believe this to be a regression.
2025-02-18 16:35:39 <fossdd[m]> <hcs-hmk> "I think I've found a little..." <- can you please open a issue move testing/libretro-* cores and update them: https://gitlab.alpinelinux.org/alpine/aports/issues
2025-02-18 16:35:45 <fossdd[m]> s/move testing/libretro-* cores and update them://
2025-02-18 16:40:37 <hcs-hmk> I've no idea what you mean by libretro, but I'm making an issue now.
2025-02-18 17:00:28 <j_v> hcs-hmk: do you already have a list of the dropped usb net modules? i will have some time in a little while, i can prepare an mr to fix.
2025-02-18 17:01:03 <hcs-hmk> I do have a list
2025-02-18 17:01:06 <hcs-hmk> Can I DM you?
2025-02-18 17:01:17 <j_v> sure, that is fine
2025-02-18 17:35:16 <donoban> ey fossdd[m] , I understand that it's the default for years and some users like it, but thinking on the "majority" of users I think that it's a benefit to be a little cautioness powering off the system
2025-02-18 17:36:34 <donoban> I don't say due myself, I don't care, my power button does nothing :P
2025-02-18 17:41:11 <fossdd[m]> <donoban> "ey fossdd , I understand that it..." <- the "majority" is recommended to use `setup-desktop` and if power users decide not so, they can disable acpid, or as I suggested remove the ACPI event trigger
2025-02-18 17:41:34 <fossdd[m]> i'm not sure i understand what youre trying to gain here
2025-02-18 17:49:15 <donoban> just having a better/safer default than it's currently, but it's clearly something very opinated :\
2025-02-18 17:50:20 <donoban> I powered off accidentally many times (3 or 4) in last years, normally after reinstalling the system
2025-02-18 17:51:08 <donoban> last time thought about improving it and changuing the default behaviour seems one possibility
2025-02-18 18:02:37 <fossdd[m]> and i really appreciate that, but i alredy think the setup-desktop MR is the solotion
2025-02-18 18:03:54 <fossdd[m]> further enhancements would be imo to subpackage the ACPI trigger that power users (e.g. you) can customize the event as they wish
2025-02-18 18:05:12 <fossdd[m]> without messing up apk managed files and still having the power button suspend without another ACPI daemon
2025-02-18 18:11:42 <donoban> I found the subpackage-alternative more messing... the ideal for custom conf without messing apk managed files would be a 'acpid.d/' dir but meh.. I think that it's something too much irrelevant for complicate more. If the default is fine let it be...
2025-02-18 20:33:48 <Ariadne> ncopa: thoughts on s/apk-tools/cmd:apk/ in alpine-base?
2025-02-18 20:47:14 <ncopa> Ariadne: what problem would that solve?
2025-02-18 20:47:55 <Ariadne> ncopa: we have apk-tools nightly in testing now, as `apk-tools3`, but to install it, you have to manually detangle `alpine-base` dependency
2025-02-18 20:50:00 <Ariadne> (there is a secondary blocker for KDE users, but that is easy to overcome by allowing both libapk versions to be installed in parallel, which should be fine on systems with a v2 apkdb)
2025-02-18 20:55:35 <ncopa> what is left for upgrading main/apk-tools to 3.0?
2025-02-18 20:57:00 <ncopa> in not very found of the cmd:apk, which is not known until after package is built, so it may be a problem to find out build order
2025-02-18 20:57:26 <Ariadne> i don't think much is left, but would like to defer to fabled on that one :)
2025-02-18 20:58:09 <ncopa> what about have a replaces=apk-tools in apk-tools3?
2025-02-18 20:58:30 <Ariadne> yes, that is one possibility, to use provider there.
2025-02-18 20:59:04 <ncopa> I think the plan is to upgrade to apk3 before 3.22 release in may
2025-02-18 20:59:06 <Ariadne> however, we don't want to upgrade everyone to apk3
2025-02-18 20:59:11 <Ariadne> at least not yet
2025-02-18 20:59:22 <Ariadne> (well, everyone who uses testing that is)
2025-02-18 21:00:29 <Ariadne> one option could be to use `provides="apk-tools=0"` which would cause the solver to avoid apk-tools3 unless specifically requested, i guess
2025-02-18 21:00:40 <Ariadne> let me try that really quick :)
2025-02-18 21:13:14 <Ariadne> hmm, not apk-tools=0, but apk-tools=2.10 seems to work :)
2025-02-18 21:16:15 <khem> does resolver support >= ? then maybe >= 0 will work I dont know just shooting in dark 
2025-02-18 21:16:19 <Ariadne> yes
2025-02-18 21:16:37 <Ariadne> but some tools like abuild have narrower constraints
2025-02-18 21:17:14 <khem> I see so you just want to override a particular version then ?
2025-02-18 21:25:21 <donoban> if running edge is safe just 'apk add apk-tools3'?
2025-02-18 21:25:35 <donoban> by safe I mean, not absolutly disaster :)
2025-02-18 21:26:56 <Ariadne> edge is perfectly safe if you know what you're doing
2025-02-18 21:27:07 <Ariadne> and if you use apk3, *do not upgrade the apkdb right now*
2025-02-18 21:27:54 <donoban> well it conflicts with apk-tools and some things depend on it
2025-02-18 21:28:28 <Ariadne> those conflicts are fixed as of a few minutes ago, but the x86_64 builder is failing to build some other package right now
2025-02-18 21:28:50 <Ariadne> you can build the package manually in the meantime
2025-02-18 21:29:24 <donoban> but I'm not sure what I should test, just install apk3 and continue using it as normal?
2025-02-18 21:33:04 <Ariadne> if you wish to :)
2025-02-18 21:35:09 <donoban> the rolling edge _:D
2025-02-18 21:38:48 <donoban> it works!
2025-02-18 21:40:35 <donoban> maybe its placebo but I feel that it runs faster ^^
2025-02-18 21:41:11 <Ariadne> i would say placebo :P
2025-02-18 21:42:22 <donoban> *do not upgrade the apkdb right now* what happens with that?
2025-02-18 21:42:28 <donoban> I think that I have something doing auto 'apk update'
2025-02-18 21:42:42 <Ariadne> that's not the apkdb, that's remote indices
2025-02-18 21:43:14 <donoban> apkdb is the local state of installed packages?
2025-02-18 21:43:33 <Ariadne> what happens when you upgrade your apkdb is that tools like KDE discover and whatever the gnome one is will quit working
2025-02-18 21:43:36 <donoban> now I'm running apk3 with apk2 apkdb?
2025-02-18 21:43:39 <Ariadne> yes
2025-02-18 21:43:50 <donoban> well I don't use anything. just plain apk
2025-02-18 21:44:06 <Ariadne> well the other thing is, the apkdb format is still not formally frozen
2025-02-18 21:44:19 <donoban> I can do a zfs snapshot
2025-02-18 21:44:39 <Ariadne> it's not worth it, apk will auto-upgrade the apkdb when we're ready for it :P
2025-02-18 21:45:01 <donoban> ok ok
2025-02-18 21:45:03 <Ariadne> if you really want to do it anyway, you can read the manpages about it :P
2025-02-18 21:45:23 <donoban> RT_APK_M
2025-02-18 21:45:29 <donoban> :)
2025-02-19 07:25:15 <fossdd[m]> someone wants to merge !79512 & !76192? :D
2025-02-19 09:54:54 <fabricionaweb> what to do when a package is missing on x86_64 but its there for the others?
2025-02-19 10:21:59 <clandmeter> fabricionaweb: check the log
2025-02-19 10:22:15 <clandmeter> and make sure its enabled for that arch
2025-02-19 10:24:08 <psykose> the builder is just behind for x86_64
2025-02-19 10:24:23 <fabricionaweb> ok so just wait
2025-02-19 10:24:25 <psykose> one of the reasons is that every package has a 45 second overhead in the post-build re-index+re-sign step
2025-02-19 10:24:44 <psykose> if you look at the log you can see stuff like  started at 10:13:36 and finished 10:15:10 with a 1m34s runtime (per log) then the next package starts at 10:15:55
2025-02-19 10:25:08 <psykose> since abuild does a full resign of the whole repo index between every single package
2025-02-19 10:26:56 <psykose> to reduce that overhead there would have to be a separate mode to not do the last step in https://img.ayaya.dev/NA9rFasReRWC so buildrepo could drive it at the end of a full build instead
2025-02-19 10:31:15 <fabricionaweb> hm thanks
2025-02-19 10:32:47 <fabricionaweb> I see that one of my aports broke the build, I removed the ulimit but seems is required LOL damn
2025-02-19 10:40:41 <clandmeter> signing the index shouldnt take that long?
2025-02-19 10:43:49 <psykose> the signing part is probably fast, the apk index command is what most likely takes long
2025-02-19 10:44:20 <psykose> it could also be something else that takes 40 seconds but that's my first guess
2025-02-19 10:44:53 <psykose> since running apk index on the whole repo involves opening every file and there is a huge amount of files to go through
2025-02-19 10:44:58 <clandmeter> from what i understand its smart to now index all of them but just the diff
2025-02-19 10:45:15 <clandmeter> not*
2025-02-19 10:45:32 <psykose> run the command manually and find out :D
2025-02-19 10:45:48 <psykose> you should find out what it is anyway since a 45 second bonus on every package build is quite silly
2025-02-19 10:46:09 <clandmeter> i havent looked into it. could it be some git cmd? 
2025-02-19 10:46:22 <psykose> could be
2025-02-19 10:46:25 <clandmeter> as this is also taking more and more time on my local setup
2025-02-19 10:46:37 <clandmeter> git prune history :)
2025-02-19 10:46:58 <psykose> reminds me i had that stubbed out from abuild back when i used it
2025-02-19 10:47:13 <clandmeter> last commit id
2025-02-19 10:47:38 <clandmeter> i think that was/is taking some time on mine
2025-02-19 10:51:54 <psykose> if i was debugging it i would probably run `extrace -t` near the end of a build and see all the rough times/processes add up until the start of the next one and go through the output of it after
2025-02-19 10:51:58 <psykose> should give useful-enough rough data
2025-02-19 10:52:06 <psykose> it's only useful to run on the actual builder of course
2025-02-19 10:55:12 <psykose> looking at more packages go through some of them only delay for like 5s so it's indeed quite variable
2025-02-19 10:55:20 <psykose> points more to git calls being slow in some case
2025-02-19 10:56:29 <fossdd[m]> yeah most of the times i used abuild its quite fast, but sometimes it hangs in there
2025-02-19 10:56:36 <fossdd[m]> even after a retry
2025-02-19 11:04:23 <ikke> From what I saw, uninstalling packages takes unusual long
2025-02-19 11:05:00 <fossdd[m]> abuild rootbld could help there
2025-02-19 11:06:09 <clandmeter> what would that matter? 
2025-02-19 11:06:29 <clandmeter> i would assume it takes more time, and the env is pristine all the time. 
2025-02-19 11:06:33 <fossdd[m]> it doesnt remove the packages, it removes the whole build container afaik
2025-02-19 11:07:24 <clandmeter> it will clean afterwards, but the flow should be similar 
2025-02-19 11:07:36 <clandmeter> plus it would need to install more pkgs
2025-02-19 12:00:36 <candrew> could someone please merge !79683 and !79832
2025-02-19 19:45:00 <jvvv> ptrc: i'm currently testing webkit2gtk-4.1 having been built with '-DUSE_SYSTEM_MALLOC=ON'. i'm main reason is i've been trying to isolate issues with luakit crashing. webkit built with that option seems has cut down on the frequency of luakit crashes. is this something you that you would be willing to entertain via an mr?
2025-02-19 19:45:26 <jvvv> s/i'm main/the main/
2025-02-19 19:47:17 <quinq> Also maybe bump while you're at it ;)
2025-02-19 19:47:52 <jvvv> yes, good point
2025-02-19 19:49:50 <psykose> that's a terrible idea since the embedded allocator is also part of security mitigations
2025-02-19 19:49:57 <psykose> it also sounds like the issue isn't fixed at all since it still crashes
2025-02-19 19:51:03 <jvvv> psykose: thanks for that heads up. looks like i need to do more research on that end.
2025-02-19 19:52:38 <jvvv> and you are right, issue is not fixed.
2025-02-19 21:07:51 <ikke> 'Error:      "2" is not greater than "2"
2025-02-19 21:07:53 <ikke> '\
2025-02-19 21:08:16 <psykose> it's true
2025-02-19 21:08:46 <ikke> exactly
2025-02-19 21:08:55 <ikke> Wonder what universe this was expected to run in
2025-02-19 21:12:27 <quinq> A universe where they pass a value greater than 2
2025-02-19 21:16:36 <ikke> 🙃
2025-02-19 23:57:10 <test_alpp> hi guys i use edge repos but i cant understand well one thing,anyone can explain me in the https://security.alpinelinux.org/branch/edge-main and https://security.alpinelinux.org/branch/edge-community that packages are vulnerable or potencially vulnerable???
2025-02-20 00:10:23 <iggy> test_alpp: edge isn't "supported" security wise, but also that's "potentially" vulnerable, and also at least one of those I looked at was bollocks
2025-02-20 00:25:38 <test_alpp> i think the same iggy never had any problem that i remember  then for people that security is a priority edge repos maybeeee better the main? anyone here use edges repos?
2025-02-20 00:27:22 <test_alpp> e.g i really dont understant this one https://security.alpinelinux.org/vuln/CVE-2023-51767?
2025-02-20 00:28:17 <test_alpp> and the Maintainer is natanael
2025-02-20 00:33:31 <mio> the cve in the example only affects up to versions (and possibly including) 9.6
2025-02-20 00:33:50 <mio> newerr versions should be fixed
2025-02-20 00:34:39 <mio> s/newerr/newer/ it says "potentially vulnernable" probably because the cve hadn't been documented yet in the APKBUILD
2025-02-20 00:36:00 <mio> s/potentially vulnernable/possibly vulnerable/ ... generally cves are promptly patched in edge and backported to the supported release branches
2025-02-20 00:38:23 <mio> when an aport is upgraded/patched for a cve, it's usually documented in a "secfixes" section of the APKBUILD, e.g. https://git.alpinelinux.org/aports/tree/main/openssh/APKBUILD#n64
2025-02-20 00:41:10 <test_alpp> so you agree that edge repos are "safe" to use.
2025-02-20 00:42:23 <test_alpp> the "potentially vulnerable packages"  can missled some people to think the packages arent safe 
2025-02-20 00:42:40 <mio> depends on what you meant by "safe" ... edge gets the latest fixes/patches, so in that sense it is safe, but upgrades may occasionally introduce bugs
2025-02-20 00:46:00 <mio> on a balance between getting the latest security patches while having less package turnover, it's probably "safer" to go with a stable release
2025-02-20 00:47:59 <mio> however, some people may always want the latest versions of everything, and access to the testing/ repo
2025-02-20 00:50:16 <mio> the "possibly vulnerable" might look a bit scary, but usually they would have been addressed, and easier way of finding out is to check the commit log for a package and see if there's any mention of a security upgrade or cve
2025-02-20 00:51:01 <mio> like https://git.alpinelinux.org/aports/log/main/openssh/APKBUILD ... latest commit mentions "security upgrade"
2025-02-20 00:53:26 <test_alpp> yeah as you said one bug here one bug there but for me "safe" is get latest security patches & fixes, i dont care about package turnover in this machine, i know that maybe some time i will have some problems cuz a bug was introduced, im using edge repos for years and i cant remember any problem mio 
2025-02-20 00:54:15 <mio> then it should be fine :)
2025-02-20 00:54:59 <test_alpp> for me edge is more stable that usa arch
2025-02-20 01:09:26 <test_alpp> thanks mio ;)
2025-02-20 01:10:45 <mio> you're welcome :)
2025-02-20 13:20:29 <fabricionaweb> pipelines are stuck it seems
2025-02-20 13:20:57 <pj> correct, CI is offline
2025-02-20 13:27:01 <caleb_m> how unsafe is it to kill apk during an upgrade?
2025-02-20 13:27:38 <caleb_m> like, from a .pre-upgrade script if conditions aren't met (specifically that some packages that were in depends= are now optional, but should remain installed)
2025-02-20 13:29:21 <fossdd[m]> uhh killing apk is usually not really safe. afaik thats also why running apk on unstable internet connections can be dangerous
2025-02-20 13:36:54 <psykose> killing apk from a pre-upgrade is definitely a terrible idea
2025-02-20 13:37:27 <psykose> if you want to transition toplevel packages depends= to "optional, still be installed" deps you can create a new subpackage and have that subpackage be install_if="$pkgname=$pkgver-r$pkgrel" with depends= on the same deps
2025-02-20 13:37:34 <psykose> on upgrade it will install the new subpackage and keep the deps
2025-02-20 13:37:41 <psykose> someone can exclude them with !new-subpackage
2025-02-20 13:37:47 <psykose> it's not the nicest thing ever but it "works"
2025-02-20 13:38:19 <fossdd[m]> i hope well get one day weak dependencies in apk
2025-02-20 13:38:30 <psykose> what would that look like
2025-02-20 13:38:48 <psykose> mechanically
2025-02-20 13:39:38 <fossdd[m]> dependencies but uninstallable with apk add !pkgname, similar to install_ifs but defined in the origin package and not in the depending package
2025-02-20 13:40:18 <psykose> that seems identical to that install_if subpackage but just putting it in another place
2025-02-20 13:40:23 <psykose> it also does not play well with the cli ux
2025-02-20 13:40:34 <psykose> because you would !dep but then something else might later want it non-soft
2025-02-20 13:40:47 <psykose> and you get an upgrade constraint failure and have to untangle it
2025-02-20 13:40:59 <psykose> by contrast !subpackage-for-opt-deps doesn't break anything
2025-02-20 13:41:18 <fossdd[m]> hmm fair
2025-02-20 13:43:43 <psykose> i find the whole optional/hard deps discussions in this space a bit overblown on average
2025-02-20 13:44:28 <psykose> people spend a lot of mental effort thinking of various solutions for how to express these constraints, for what is usually a request born out of 'i am using a distro and want to remove some random package that takes 60kb and am upset that i cant'
2025-02-20 13:45:53 <fossdd[m]> i agere but there are valid usecases, especially for postmarketos
2025-02-20 13:46:30 <psykose> the main nice to have would be some sort of optional signalling in some way for a package to say 'also optionally add this constraint to install this other thing that adds some feature'
2025-02-20 13:46:51 <psykose> but emphasis on the nice to have, since that is just sparkling documentation
2025-02-20 13:46:57 <fossdd[m]> thats what arch does i guess
2025-02-20 13:47:09 <fossdd[m]> but i kinda think opt depends should be opt-out and not opt-in
2025-02-20 13:47:43 <psykose> yes, though over half the arch optdepends are stuff like 'optional libfoo for $usecase' that only happens to work that way because of lazy symbol resolution in the thing using the lib
2025-02-20 13:48:09 <psykose> (here they are just hardlinked instead)
2025-02-20 14:12:25 <caleb_m> psykose right i guess that's kinda what i don't want. the usecase specifically is that we have a generic "device" package which depends on a bunch of firmware and daemons for various devices
2025-02-20 14:12:30 <caleb_m> but not all devices need all of them
2025-02-20 14:12:47 <caleb_m> so i'd like to just move them to world and let the user remove them manually if they want
2025-02-20 14:12:58 <caleb_m> any kind of subpackage magic would just obfuscate the API
2025-02-20 14:13:15 <psykose> does the installer know the specific device or nah
2025-02-20 14:13:37 <caleb_m> no
2025-02-20 14:14:11 <caleb_m> and it would be pretty complicated to do for each package
2025-02-20 14:14:17 <psykose> putting everything in world via the normal pmb_recommends (iirc that's what it does) seems fine then
2025-02-20 14:14:23 <caleb_m> here's my cursed poc, example output in the MR description: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6239/diffs#3805feffbf39ddafff9e24409623f00efeb62506_0_45
2025-02-20 14:14:30 <psykose> though yes there's no way to transition that
2025-02-20 14:14:36 <caleb_m> psykose right but that only works on newly built images
2025-02-20 14:14:37 <caleb_m> yeah
2025-02-20 14:14:38 <psykose> and yeah i am like 98% sure in general that won't work
2025-02-20 14:14:47 <psykose> i have broken maybe 10 systems with C-c on apk
2025-02-20 14:15:28 <caleb_m> yikes
2025-02-20 14:15:35 <psykose> i think there's some specific timing where a package might be 'installed' but the files were not actually put onto the root, so on an add/upgrade you wouldn't actually have that have happened at kill time
2025-02-20 14:15:56 <caleb_m> that timing wouldn't be hit in a .pre-upgrade script though right? :3
2025-02-20 14:16:15 <psykose> the timing seems to be any time in the middle of a tx, though what gets broken depends what it was doing of course
2025-02-20 14:16:28 <caleb_m> hmm
2025-02-20 14:16:39 <psykose> if the first thing in the log was 'deleting package', then that could mean something wasn't removed (stale files on disk, package actually uninstalled)
2025-02-20 14:16:39 <caleb_m> and it'll never be doing i/o while the .pre-upgrade is running... soo it's safe?
2025-02-20 14:16:51 <psykose> i don't think it's i/o related since it's not about sync
2025-02-20 14:17:00 <psykose> it's about tracking what it did, but i'm just guessing
2025-02-20 14:17:06 <caleb_m> hmm ok
2025-02-20 14:17:28 <caleb_m> it would be nice if we could `exit 254` or something to tell apk to abort
2025-02-20 14:17:44 <caleb_m> but i guess it can't because the .pre-upgrade runs randomly
2025-02-20 14:17:46 <psykose> there's more layers to this with pre/post hooks marking serialization points where it writes out stuff to the root instead of doing it in as close to one shot as possible (with no such hooks)
2025-02-20 14:17:58 <psykose> it's why they're bad to use in general, but haha bit late to change that
2025-02-20 14:17:59 <caleb_m> hmm
2025-02-20 14:18:08 <caleb_m> yeahhh
2025-02-20 14:18:26 <caleb_m> does --dry-run run scripts? i guess no?
2025-02-20 14:18:36 <psykose> so tl;dr everything kinda sucks, fucking with it more with killing is bound to go badly for someone upgrading with potentially more than just that 1 mr of changes
2025-02-20 14:18:39 <psykose> i think it doesn't
2025-02-20 14:19:09 <skarnet> we really need transactional filesystems :/
2025-02-20 14:19:31 <psykose> for a distro, i think the main mechanism to do stuff like this could be built around the /etc/apk commit_hooks thing
2025-02-20 14:19:50 <psykose> regular package triggers are great but don't allow doing meta stuff (i.e. running apk, etc)
2025-02-20 14:20:07 <psykose> the actual commit_hooks trigger is just pre/post so it's very primitive, but maybe it's useful to build something
2025-02-20 14:20:12 <psykose> never thought about it in a pmos context
2025-02-20 14:20:43 <caleb_m> ohh, interesting. are there docs describing their behaviour? the wiki page is a bit sparse
2025-02-20 14:21:20 <psykose> that description is the entire api :P
2025-02-20 14:21:37 <psykose> apk just isn't good at this sort of meta-thing to rework things in the middle of an upgrade
2025-02-20 14:22:00 <caleb_m> i mean the other option which i keep going back to is that we ship an apk wrapper and implement recommended packages (and other nice things) that way
2025-02-20 14:22:30 <caleb_m> but then we have to fork apk-tools to change the install path
2025-02-20 14:23:48 <psykose> yeah it's all a lot of work
2025-02-20 14:24:13 <caleb_m> apk3 will at least get us a bit closer i think
2025-02-20 14:24:22 <caleb_m> not exactly sure what all the features are there
2025-02-20 14:24:40 <psykose> i don't remember any high-level features, it's been too long since i compared
2025-02-20 14:24:55 <psykose> i remember install_if="a !b".. and uhh no other changes
2025-02-20 14:25:36 <caleb_m> lol
2025-02-20 14:25:37 <psykose> 90% of the changes to me were just format/"now there is zstd compression :)"
2025-02-20 14:26:46 <caleb_m> maybe we can get get arbitrary metadata + a hook that gets run after downloading packages but before upgrading that lets us modify the transations(?)
2025-02-20 14:26:51 <caleb_m> then we can do recommended packages ourselves
2025-02-20 15:38:21 <sertonix[m]> Doing recommended packages with install_if could also allow users to decide whenever or not these are opt-in or opt-out (just like the doc subpackages on alpine)
2025-02-20 15:41:48 <psykose> yes, it's kind of the best mechanism for it
2025-02-20 20:04:02 <bl4ckb0ne> is the x86_64 3.21 builder stuck? 
2025-02-20 20:05:19 <ikke> it's idle
2025-02-20 20:05:36 <ikke> Or are you referring to the gitlab ci runner?
2025-02-20 20:05:41 <bl4ckb0ne> yeah
2025-02-20 20:05:42 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1737795 
2025-02-20 20:05:51 <ikke> The host is unreachable
2025-02-20 20:06:07 <bl4ckb0ne> crashed?
2025-02-20 20:06:51 <ikke> Note sure exactly, we have a support request open with equinix
2025-02-20 20:38:57 <fabricionaweb> :/
2025-02-20 20:58:59 <tomalok> for x86 .. i'm getting the following when trying to build the new docker-28.0.0 -- "# github.com/docker/docker/libnetwork/drivers/bridge
2025-02-20 20:58:59 <tomalok> libnetwork/drivers/bridge/port_mapping_linux.go:679:45: undefined: syscall.SYS_SETSOCKOPT"
2025-02-20 20:59:37 <tomalok> the other (non-x86_64) archs built just fine...  no idea (yet) if x86_64 is similarly afflicted
2025-02-20 21:18:25 <ikke> tomalok: probably unrelated, but someone reported docker 28.0.0 breaking networking for them
2025-02-20 21:18:52 <ikke> https://www.reddit.com/r/docker/comments/1itw1ve/dont_upgrade_docker_this_morning/
2025-02-21 03:25:17 <tomalok> there are a lot of networking stuff landing in 28
2025-02-21 03:29:01 <tomalok> IPSET kernel requirement as a step towards netfilter, apparently? looks like there's CONFIG_NET_EMATCH_IPSET=m and CONFIG_IP_SET=m (and deeper configs) at least in alpine-virt kernels.
2025-02-21 06:46:17 <fabricionaweb> !78515 who can merge this
2025-02-21 15:27:55 <tomalok> well docker-28 x86_64 build is fine now that it's building things again -- but x86 still missing syscall.SYS_SETSOCKOPT
2025-02-21 15:28:09 <ikke> is that python?
2025-02-21 15:28:29 <ikke> oh no, go probably
2025-02-21 15:31:06 <ikke> tomalok: Seems to be missing here: https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/syscall/zsysnum_linux_386.go
2025-02-21 15:34:55 <tomalok> so, they used a syscall that go doesn't support for x86?
2025-02-21 15:35:58 <ikke> Yeah, not sure if that's an expected omission or not
2025-02-21 15:36:13 <ikke> according to https://x86.syscall.sh/, the syscall is there (NR 366)
2025-02-21 15:36:58 <tomalok> https://github.com/golang/go/issues/19043
2025-02-21 15:37:55 <ikke> so docker would need to do something different for x86?
2025-02-21 15:38:50 <tomalok> i'm not sure if this is the only one, or what it's trying to do... probably something related to the new networkings stuff
2025-02-21 15:38:56 <ikke> "On 386 GNU/Linux you'll need to call something along the lines of Syscall6(syscall.SYS_SOCKETCALL, 15, /* setsockopt arguments */)"
2025-02-21 15:39:20 <ikke> "linux/386 multiplexes all socket syscalls into a one syscall (probably
2025-02-21 15:39:22 <ikke> because there aren't enough registers to pass the arguments.)
2025-02-21 15:39:24 <ikke> "
2025-02-21 15:49:35 <tomalok> sounds like something they should address for 28.0.1
2025-02-21 16:16:24 <fossdd[m]> someone want to merge !79512,,
2025-02-21 16:22:42 <ikke> I want chromium not to fail on armv7
2025-02-21 16:49:09 <fossdd[m]> sorry, cant help with that
2025-02-21 17:57:57 <qaqland> do i need to ping each maintainer in !80333
2025-02-21 18:00:08 <ikke> not for plain rebuilds (pkgrel bumps), but for other changes it would be good
2025-02-22 05:01:09 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79951
2025-02-22 05:01:14 <Saijin_Naib[m]> Can I get a review on this MR?
2025-02-22 08:07:38 <fabricionaweb> You resolved the sugestions but I don't see the changes 
2025-02-22 08:35:51 <ovf> has edge x86_64 testing really not been updated since 2025.02.09? https://pkgs.alpinelinux.org/packages?branch=edge&repo=testing&arch=x86_64
2025-02-22 08:38:54 <ikke> yes
2025-02-22 09:04:29 <ovf> can't see anything as to why (mostly just curious, but also i want my updates). looks like this never got built? https://gitlab.alpinelinux.org/alpine/aports/-/commit/595a1964e0e2828f47bf3cefdc381ad88992513b
2025-02-22 09:09:21 <ikke> it's built, not uploaded just yet
2025-02-22 09:09:30 <ikke> There was a package blocking the builder
2025-02-22 15:04:28 <famfo> Hi, my PR !72313 has once again be marked as stale because it didn't get any reviews. I tried to privately get hold of jirutka but haven't been successful either. Dose anyone have an idea how to move forward?
2025-02-22 16:01:27 <ikke> famfo: it's a tough sitation, the maintainer is not feeling to well, but the changes are too significant for me to merge this without their approval
2025-02-22 16:03:27 <yaboyfred> How does one go about requesting a package version bump? Submit a pull request, an issue, just ask here, mail to maintainer?
2025-02-22 16:12:55 <pj> famfo: protobuf dependencies could be removed no?
2025-02-22 16:13:21 <pj> atuin uses protox now which is pure rust compiler for protobuf defs
2025-02-22 16:15:11 <mio> yaboyfred: maybe submit a merge request if you can (check there isn't already an open one first), or open an issue if you prefer the maintainer to handle it
2025-02-22 16:15:49 <mio> as in, if you're not sure in the latter case
2025-02-22 16:37:59 <yaboyfred> mio: ok thanks
2025-02-22 17:00:58 <famfo> pj, I can check in a bit, not sure
2025-02-22 17:45:42 <panekj> I think they are not required, I compile atuin without it
2025-02-22 17:45:55 <panekj> and 18.4.0 release mentions removing protoc
2025-02-22 17:46:25 <panekj> "Thanks to @senekor, we no longer require protoc available at build time, and instead use protox"
2025-02-22 17:47:13 <panekj> after that's done, the MR is good to merge
2025-02-22 18:07:34 <craftyguy[m]> any chance of having these reviewed/merged soon-ish? !80058 !79820 thanks :D
2025-02-22 20:53:05 <Saijin_Naib[m]> <fabricionaweb> "You resolved the sugestions..." <- Ugh, okay. No idea how thar happened
2025-02-22 23:32:14 <Ariadne> craftyguy[m]: done
2025-02-23 00:13:46 <craftyguy[m]> Ariadne: thank you :)
2025-02-23 11:06:38 <donoban> is fine to call "git clone" for fetching data for check()? !301230
2025-02-23 11:12:57 <ikke> donoban: not really
2025-02-23 11:17:25 <donoban> ok
2025-02-23 11:18:38 <ikke> You can add the archive to sources and link it to the correct place in prepare
2025-02-23 11:20:29 <donoban> hm.. I was doing on check() so the unzip etc.. is avoided if checks skippeds
2025-02-23 11:22:51 <ikke> make sure abuild check can be run multiple times at least
2025-02-23 11:23:18 <donoban> ok
2025-02-23 11:28:34 <donoban> fixed!
2025-02-23 11:29:11 <donoban> oh, I missed competions and doc
2025-02-23 11:29:56 <donoban> will add later
2025-02-23 22:22:57 <WhyNotHugo> I've drafted an aport for system-udev (which works as a drop-in replacement for eudev)…
2025-02-23 22:23:04 <WhyNotHugo> It's a horrible pile of patches from various sources so far: https://gitlab.alpinelinux.org/WhyNotHugo/aports/-/commit/af75681d25cd3da1ec7a1d7341edb987f640f722
2025-02-23 22:23:44 <WhyNotHugo> Sharing here to hear if it's even worth continuing the effort right now
2025-02-23 22:23:59 <fossdd[m]> very cool!
2025-02-23 22:24:19 <fossdd[m]> im not sure but IIRC ariadne already has it packaged locally
2025-02-23 22:24:42 <WhyNotHugo> dammit, such wasted effort. should have asked first.
2025-02-23 22:25:10 <WhyNotHugo> I leart a lot about rebasing piles of .patch files tho 🤷‍♂️
2025-02-23 22:31:54 <fossdd[m]> > <Ariadne> incidentally, i have a systemd-udev package up and running on my desktop that replaces eudev, and it is working as expected
2025-02-23 22:32:19 <fossdd[m]> but yeah the effort is still not wasted
2025-02-23 22:55:48 <WhyNotHugo> The build system is such a horrible entangled mess. And the language for rules is… ugh. I wish I had enough time to write something standalone that uses rules written in lua or something simple like that.
2025-02-24 00:46:07 <qaqland> Hi, I think !80333 is ready.
2025-02-24 01:38:03 <peterson[m]> From Trusted and Vouched Dealers... (full message at <https://matrix.org/oftc/media/v1/media/download/AXKUR0bRP65jdJ2VfeyWKtrL_Sqm1ez5fyA4Zzwp5dD75AC52Q0bj4Wbk3P5XohuAPKtC1JKBm5XVeKFGMGcd4lCeVfbOw-gAG1hdHJpeC5vcmcvY2laTlRuVXlWbHF2c1ZraXhJQk9tRmxI>)
2025-02-24 11:03:34 <fabricionaweb> if/when you are the maintaner and there is no other contributor, do we keep the contributor comment or just remove it?
2025-02-24 11:05:07 <ikke> you can just remove it
2025-02-24 11:17:26 <quinq> Maybe you can add: # Contributor: are welcome
2025-02-24 11:17:40 <ikke> Please don't
2025-02-24 11:20:11 <quinq> :)
2025-02-24 11:29:38 <fabricionaweb> Contributor: please don't ok got it
2025-02-24 11:37:20 <quinq> jaja
2025-02-24 13:38:49 <fabricionaweb> I want to bump py3-sphinx but it needs to bump py3-flit-core, which is currently failing because it remove a vendor, to solve it may need a patch, should I open an issue to track down all of this?
2025-02-24 13:42:02 <fossdd[m]> what means "it remove a vendor"
2025-02-24 13:42:18 <fossdd[m]> if you could upgrade it with the patch, that would be good
2025-02-24 13:42:42 <fossdd[m]> otherwise feel free to open a issue that somebody else can pick it up
2025-02-24 13:48:11 <fabricionaweb> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/py3-flit-core/APKBUILD#L21
2025-02-24 13:48:55 <fabricionaweb> it deletes the tomli but now it brokes because theres an wildcard looking for licenses in that folder
2025-02-24 14:28:06 <bl4ckb0ne> ping on !71645 pls, sorry it's a big one 
2025-02-24 14:48:27 <fabricionaweb> I made the mr fossdd
2025-02-24 14:49:36 <fossdd[m]> thanks, the patch looks good i think
2025-02-24 14:50:54 <durrendal> any chance I could get !74101 merged? It's quite a few ruby packages, but they should all be in order.
2025-02-24 15:48:44 <tomalok> ikke - fwiw docker upstream merged a fix for linux/386 compilation of docker 28 -- thanks for the assist -- there should be another release with other networky patches soon
2025-02-24 16:05:09 <ikke> nice
2025-02-24 16:45:05 <fabricionaweb> one of the packages I maintain does use cmake ExternalProject got grab a dependency from git, is it fine or should I patch it to add to $source for instance?
2025-02-24 16:45:25 <fabricionaweb> s/got/to grab/ sorry typo there
2025-02-24 16:56:20 <ikke> fabricionaweb: you should patch it to use local source
2025-02-24 16:56:40 <fabricionaweb> ok doing it
2025-02-24 18:07:18 <jvvv> could i get a review of !80252 and !80255?
2025-02-24 18:13:32 <ikke> it needs a _krel bump for all out-of-tree kernel modules as well
2025-02-24 18:14:40 <jvvv> ikke: thanks, on it
2025-02-24 18:24:20 <jvvv> ikke: should that be a separate mr?
2025-02-24 18:29:24 <jvvv> ikke: nvrmnd... looked at previous merged mr's
2025-02-25 00:30:51 <craftyguy[m]> any chance this could get merged soon? !80342 thanks!
2025-02-25 09:21:34 <fabricionaweb> good morning, I also have one pending !78515 
2025-02-25 12:55:16 <telmich> I think mpv is broken in edge at the moment - might need a recompile / relink. It exits with various missing symbols: Error loading shared library libvulkan.so.1: No such file or directory (needed by /usr/bin/mpv) and Error relocating /usr/lib/libplacebo.so.338: vkGetInstanceProcAddr: symbol not found
2025-02-25 12:55:31 <ikke> telmich: known issue
2025-02-25 12:55:43 <telmich> ack, thanks for the quick feedback!
2025-02-25 12:56:24 <ikke> It's because electron started to provide libvulkan,so.1 but in a subdirectory
2025-02-25 12:56:45 <fossdd[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/16934
2025-02-25 12:58:15 <ikke> Just merged !80434
2025-02-25 12:58:25 <fossdd[m]> ikke: thanks!
2025-02-25 14:46:01 <pltrz[m]> hello; anyone able to review !70759 ? thanks!
2025-02-25 14:52:56 <pj> jirutka has limited availability recently so it may be hard to get it merged
2025-02-25 14:59:03 <pltrz[m]> pj: understandable! could another developer take a look?
2025-02-25 15:01:25 <pj> there's already 4 other devs in that thread, I think it has been looked enough
2025-02-25 15:01:37 <pj> but it will not get merged without package maintainer approval
2025-02-25 15:02:08 <pltrz[m]> makes sense; thanks for the info!
2025-02-25 15:02:54 <pj> for stuff like helix, I recommend using the build grammar feature anyway
2025-02-25 15:03:11 <pj> helix --build or something like that
2025-02-25 15:04:25 <pltrz[m]> neat, I had no idea that was a feature in helix
2025-02-25 15:06:30 <pltrz[m]> ah, seems --grammar fetch works but then --gramar build fails
2025-02-25 15:07:04 <pj> probably need C compiler installed
2025-02-25 15:12:36 <pltrz[m]> a C compiler is indeed symlinked to /usr/bin/cc, but it seems the error is with cc-rs: error occurred in cc-rs: unknown target 'x86_64-alpine-linux-musl'.
2025-02-25 15:13:18 <pltrz[m]> I suppose it's what Matthias is referring to here
2025-02-25 15:13:21 <pltrz[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78019#note_471047
2025-02-25 15:16:57 <fossdd> pltrz[m]: its a issue of https://github.com/rust-lang/cc-rs/issues/1407
2025-02-25 15:17:24 <fossdd> upstream broke basically all custom targets
2025-02-25 15:18:01 <fossdd> but its not a helix issue, the only thing you could do is to patch the Cargo.toml to downgrade cc
2025-02-25 15:18:21 <fossdd> but tbh it makes probably more sense to just wait what upstream comes up with
2025-02-25 15:20:38 <pj> it's an annoying thing that rust people went with whole triples thing and then everything is just <arch>-unknown-<os>-<env>
2025-02-25 15:25:00 <fossdd[m]> didnt the target triple come from llvm originally?
2025-02-25 15:27:21 <bl4ckb0ne> fossdd[m]: is it just me or the commit on !79695 are all sdl3 and not sdl2-compat?
2025-02-25 15:27:53 <fossdd[m]> oh yeah i was just (ab)using the CI to test if they work against sdl3
2025-02-25 15:28:09 <fossdd[m]> see the last commit
2025-02-25 15:28:17 <bl4ckb0ne> i see
2025-02-25 15:29:05 <bl4ckb0ne> im surprised there are packages that succeed building with sdl3 directly
2025-02-25 15:29:39 <bl4ckb0ne> i wonder if we could drop sdl2 now that we have sdl3 and sdl2-compat once your MR lands
2025-02-25 15:29:45 <fossdd[m]> yeah im sure some of them just have sdl in makedepends and dont use it at all
2025-02-25 15:29:46 <pj> fossdd: yes, but I'm complaining about rust ecosystem ignoring everything but -unknown-
2025-02-25 15:29:59 <fossdd[m]> tbh i really like that sdl managed to have a drop in replacement for sdl2 to 3, its basically the middleground between two breaking versions
2025-02-25 15:30:10 <fossdd[m]> hope some other projects can adopt this model too
2025-02-25 15:30:42 <fossdd[m]> bl4ckb0ne: yeah i could see that working, altough some libraries like sdl2_image should be upgraded first
2025-02-25 15:31:30 <bl4ckb0ne> sdl does a vgood job at not breaking the whole ecosystem that depends on them
2025-02-25 15:31:53 <bl4ckb0ne> sdl2_image is standalone, idk if there's an image compat equivalent
2025-02-25 15:32:57 <abby> bl4ckb0ne: arch has had some issues with using sdl2-compat iirc
2025-02-25 15:32:57 <bl4ckb0ne> it moved to 3.0 as well
2025-02-25 15:33:14 <bl4ckb0ne> https://github.com/libsdl-org/SDL_image/blob/main/docs/README-migration.md migration seems fairly straightforward
2025-02-25 15:33:20 <bl4ckb0ne> abby: what kind of issues?
2025-02-25 15:33:42 <abby> don't remember exactly, just saw some forum posts
2025-02-25 15:33:57 <abby> various games not working or something
2025-02-25 15:34:17 <fossdd[m]> yes but they are already fixed
2025-02-25 15:34:35 <fossdd[m]> the usual bugs that happen after a big upgrade
2025-02-25 15:35:05 <fossdd[m]> ( thats why we need more testing and we can do that by switching to sdl2-compat :p )
2025-02-25 17:04:06 <WhyNotHugo> do CI builders not share distfiles?
2025-02-25 17:04:32 <ikke> no
2025-02-25 17:04:41 <pj> they are on different hosts in different places, I don't see have that would be feasible 
2025-02-25 17:04:51 <pj> s/have/how/
2025-02-25 17:24:06 <WhyNotHugo> right
2025-02-26 14:45:08 <ikke> tomalok: docker 28.0.1 is out
2025-02-26 15:07:23 <tomalok> ikke: 👍
2025-02-26 18:08:39 <fabricionaweb> I made this bump but the bot didnt tag the maintainer, is it because of the new maintainer field on APKBUILD? !80525
2025-02-26 18:11:54 <ikke> fabricionaweb: "no users found with email address .."
2025-02-26 18:12:25 <fabricionaweb> ahh ok, altho he is there, maybe its just a wrong mail address
2025-02-26 18:13:14 <ikke> yeah, their profile has a different address
2025-02-26 19:51:11 <ikke> In 10 minutes gitlab will be restarted to apply security upgrades
2025-02-26 22:06:34 <fossdd[m]> can someone merge !80121?
2025-02-26 22:56:49 <Ermine> https://git.alpinelinux.org/aports/tree/community/syncthing/syncthing.pre-install -- seems like syncthing's home directory is not created. Is that on purpose?
2025-02-26 22:57:49 <Ermine> nvmd
2025-02-27 02:19:14 <lotheac> could somebody merge !78838 and !78944 ?
2025-02-27 02:20:17 <lotheac> and maybe !80325 ... though maintainer has not reacted on that yet
2025-02-27 10:28:38 <Kladky> could someone please take a look at !77625? It's been open for two months now, but the maintainer hasn't commented yet
2025-02-27 10:34:52 <PureTryOut> I need webkit2gtk-4.0 for a package but in Alpine there is only webkit2gtk-4.1. Checking the Arch Linux packages for both they seem to be the exact same except for a single build argument specifying the use of some dependency. Does anyone know what specifically I would need to change to get a 4.0 build rather than 4.1?
2025-02-27 10:36:16 <PureTryOut> Oh wait, maybe the use of libsoup rather than libsoup3 🤔
2025-02-27 11:01:57 <fossdd[m]> it was removed because it only caused issues
2025-02-27 11:01:57 <fossdd[m]> 1bb817533b2a46cbfb7306f5ea32d327d305a711
2025-02-27 11:03:02 <fossdd[m]> cinny also requires webkit2gtk-4.0 (because it uses tauri v1) but i honestly think its better to disable it until it works with a newer webkit2gtk
2025-02-27 11:03:09 <fossdd[m]> !77457
2025-02-27 11:06:19 <fossdd[m]> ah see also https://gitlab.alpinelinux.org/alpine/aports/-/issues/14974
2025-02-27 11:06:43 <fossdd[m]> and !75198 for the removal
2025-02-27 12:01:34 <PureTryOut> I mean yeah I probably won't merge this, but I need something to start off with. I'll see later how I can get it to at least webkit2gtk-4.1
2025-02-27 12:05:37 <fossdd[m]> yeah since it uses tauri v2 it should hopefully not be too hard
2025-02-27 12:06:52 <PureTryOut> as far as I can see it doesn't use v2 yet? They seem to be working on it still
2025-02-27 12:07:03 <PureTryOut> I probably only need the cli anyway, but it'd be nice to have the full featured app
2025-02-27 15:57:17 <ser> What's the process for requesting the promotion of a package from testing to community?
2025-02-27 15:58:20 <ser> https://wiki.alpinelinux.org/wiki/Creating_patches mentions "after a reasonable time", but it's the only reference I can find about promoting packages.
2025-02-27 16:01:23 <fossdd[m]> https://gitlab.alpinelinux.org/alpine/aports#community
2025-02-27 16:01:54 <fossdd[m]> tldr: if you tested it enough and can say its stable to use and you want to support it for the lifecycle of the next alpine release
2025-02-27 16:19:02 <streampunk> I have packages that need platform dependent subpackages. I copied code from the wiki and also compared with other packages. CARCH should be set. Not only that CARCH is not set. abuild actively unsets CARCH if I set manually... (full message at <https://matrix.org/oftc/media/v1/media/download/AdhnyFxMCd6hrfTxxl6k-rJ6iyTDL1ghzZa9V7edYc2RostXZzHD5SKnzhatWV84X6QsBaT6jPdCjgEBYqodD_5CeVkE1XngAG1hdHJpeC5vcmcvZ09oR2xwdXlJUEtrUWVzalVueEdjTER1>)
2025-02-27 16:19:57 <streampunk> s/only/online/
2025-02-27 17:09:57 <fossdd[m]> $CARCH should be available in APKBUILDs
2025-02-27 17:10:28 <fossdd[m]> otherwise something else might be wrong
2025-02-27 17:18:05 <streampunk> fossdd: thanks that helped me to check my assumption. When debugging is used a subshell, that does not inherit CARCH.
2025-02-27 17:25:57 <ser> fossdd[m]: thank you. Is there an approval process, or do you just... add the package to community?
2025-02-27 17:28:33 <ser> The package has been in testing since Apr 4, 2004. _I_ use it all day, every day... but then, I wrote it. I don't know how many other people use it, but I haven't had any complaints.
2025-02-27 17:37:16 <streampunk> ser: I'd say make a MR end see what happens (I didn't get what package this is about)
2025-02-27 17:42:50 <ser> streampunk: I didn't say, but it's rook.
2025-02-27 17:45:30 <ser> Huh. "If the package is not moved within 6 months (in testing), we remove it after 9".
2025-02-27 17:46:01 <ser> Like, "moved" as in "new changes added," or as in "moved to community or main"?
2025-02-27 17:46:13 <ser> I didn't realize there was a deadline.
2025-02-27 17:46:50 <ser> rook's obvs been in testing way longer than 9 months.
2025-02-27 17:47:58 <ser> I did push a new version in October; maybe that saved it from The Purge.
2025-02-27 17:53:08 <fossdd[m]> its a soft deadline, nothing has been implemented yet to realise it
2025-02-27 17:54:04 <fossdd[m]> but yeah just send a MR with mv testing/pkgname community and it should get pushed if there are no other packaging issues
2025-02-27 17:54:15 <fossdd[m]> and thanks for maintaining it this long!
2025-02-27 17:55:33 <ser> Y/w. Although, like I said, I have no idea if anyone else is using it. Although I did get a comment once from an alpine user that it "looked like something they'd been looking for." So, maybe one other? 
2025-02-27 17:56:31 <fossdd[m]> no complaints is already a good indicator that stuff "just" works :)
2025-02-27 17:57:07 <ser> or, nobody's using it. But I like your perspective better.
2025-02-27 17:57:19 <fossdd[m]> (there are a lot of silent users and even users unconsciously using it)
2025-02-27 17:58:03 <ser> So, literally just `git mv` and push?
2025-02-27 17:58:21 <ser> And an MR.
2025-02-27 17:58:57 <fossdd[m]> yes
2025-02-27 18:05:32 <ser> kthx
2025-02-27 18:12:05 <sertonix[m]> Is anyone interested in maintaining testing/sssd? The current maintainer isn't active and someone is asking for some changes in #16943
2025-02-27 18:13:11 <fossdd[m]> had a look at the issue and it seems to request samba and --enable-samba, but there were still some missing deps
2025-02-27 18:20:54 <ser> I think I just broke gitlab.alpinelinux.org
2025-02-27 18:21:31 <ikke> It's still online
2025-02-27 18:22:01 <fossdd[m]> if while opening a MR, try rebasing against aports master
2025-02-27 18:23:31 <ser> That causes a 500 internal error?
2025-02-27 18:23:53 <fossdd[m]> yeah probably because it took too long to diff
2025-02-27 19:03:44 <streampunk> sertonix fossdd I can try to enable sssd-ipa and I am around for the next few months, but I do not no what happens then and I do not need sssd.
2025-02-27 19:05:32 <streampunk> I mean I'll be here for few months.
2025-02-27 19:08:11 <ser> I really don't want to screw up the git repository, so can someone please confirm: I've pulled the aports master and I'm about to push it to my origin; it's, like, 23k commits behind, and the push is huge, which makes me really nervous.
2025-02-27 19:09:26 <ser> But this is the right thing to do, right? push --set-upstream origin master? where origin is git@gitlab.alpinelinux.org:ser/aports.git
2025-02-27 19:09:28 <streampunk> ser: if the branch you push is uptodate with origin/master everything is fine.
2025-02-27 19:10:00 <ser> Yeah, I'm siting on upstream/master (which is https://gitlab.alpinelinux.org/alpine/aports)
2025-02-27 19:10:09 <ikke> ser: yeah, should not be an issue
2025-02-27 19:10:11 <streampunk> With origin I mean alpine/aport.
2025-02-27 19:11:19 <streampunk> push into git@gitlab.alpinelinux.org:ser/aports.git and if gitlab cannot handle it, just your worker will die. you cannot break anything.
2025-02-27 19:11:27 <ser> Ok, thanks.
2025-02-27 19:11:41 <ser> Oh, no. I can tell you that I _can_ break things.
2025-02-27 19:13:04 <ser> Patrycja had to fix something when I was first trying to get rook in.
2025-02-27 19:13:58 <ser> I'd completely messed something up. This is what comes from using git once every 6 months; my understanding of it is so superficial. Anyway, here  goes nothing.
2025-02-27 19:14:14 <streampunk> ser: I just jinxed it? :-) but seriously you should not be able to break 12-factor app like that.
2025-02-27 19:15:15 <ser> Hm.
2025-02-27 19:16:19 <ser> But, hey! Go 1.24 landed in Alpine, so I can clean up the rook package which had a tooling solution which -- although guided by Patrycja -- was totally hacky and I can now eliminate. So, looking forward to that.
2025-02-27 19:16:54 <ser> And then I'll try moving it to community and I can feel as if I've accomplished something today.
2025-02-27 19:20:29 <streampunk> ser: I would do the following:... (full message at <https://matrix.org/oftc/media/v1/media/download/AY4KB-uQlbwZ_Q0NKz4pBg9cA206YMTkwVqIqyG6RhodjkZ9uNaa9U9B1pXKSu3Kpg9l3LLwlpyI13t5Jcf6siRCeVkPN1fAAG1hdHJpeC5vcmcvUmhjSHlDa1h4cWlYdEtFelBpQnpmcFpS>)
2025-02-27 19:21:44 <streampunk> git psuh ser branch-you-worked-on
2025-02-27 21:13:07 <skarnet> git psuh for the win
2025-02-27 22:17:04 <Ariadne> streampunk: please be mindful that super long messages don't get carried over matrix bridges
2025-02-27 22:29:19 <streampunk> got it, thanks. :-)
2025-02-27 22:32:34 <ser> sertonix[m]: what does your comment (in rook) mean? That I should create a separate -doc apk? Or is it a different subsection in the main APK?
2025-02-27 22:34:35 <ser> I think I never understood what that subpackage did, because there wasn't anything specifically done for it in the previous version.
2025-02-27 22:36:29 <ser> I mean: in the previous APKBUILD, the man pages were built in build(). Aside from having a subpackage specified, the APK didn't _do_ anything. Is the -doc subpackage a magic function?
2025-02-27 22:39:29 <ser> ok. Nevermind. It must be; b/c ; sampling of other APKBUILDs which have it do nothing more than include it. Magic.
2025-02-27 22:40:21 <sertonix[m]> Subpackages are used to reduce size and sometimes dependencies of packages. They all end up being different APK files. For example documentation isn't usefull when a system is embedded. The -doc subpackage is handled in abuild by default.
2025-02-27 22:42:50 <ser> I was wondering how abuild detects the man pages.
2025-02-27 22:43:11 <ser> https://media.tenor.co/images/7f6402cf7df54cdf24505ee7895326aa/raw
2025-02-27 22:44:39 <ser> 'cause there's no separate "docs()" function. So it just looks for man pages in? I guess I don't need to know. IF my build creates man pages, add a -doc subpackage and magic happens.
2025-02-27 22:50:51 <sertonix[m]> The code is here if you want to read it: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/fb2543ffb9db77d0fb9e85c420fdbde9673481bb/abuild.in?page=2#L1974
2025-02-27 22:51:56 <sertonix[m]> It can only find manpages that have been installed under $pkgdir though.
2025-02-27 23:13:28 <ser> Ok. Thanks. The comments have been resolved; thanks for the review.
2025-02-27 23:41:41 <selene> would someone be able to take a quick look at !79260 and !79262? they've both been sitting for a while, and the first is just a font package
2025-02-28 01:34:58 <prabu>  following packages anki, apk-snap, catdoc, cliphist-fzf,doasedit,powerctl,py3-stringcase and swappy from 
2025-02-28 01:35:35 <prabu> testing are working great in v3.21 stable..
2025-02-28 02:42:46 <navi> openrc-0.60 released, we have user services now!
2025-02-28 07:22:29 <ikke> \o/
2025-02-28 08:21:53 <fabricionaweb> Needs to document it \o/
2025-02-28 08:24:33 <fossdd[m]> pj new spam here,,,
2025-02-28 08:28:25 <ikke> https://github.com/OpenRC/openrc/blob/master/user-guide.md#user-services----experimental
2025-02-28 08:36:50 <fabricionaweb> Where is the spam fossdd
2025-02-28 08:40:49 <fossdd[m]> just on matrix, oftc already blocked it
2025-02-28 08:41:40 <fabricionaweb> Ah ok ty
2025-02-28 09:24:49 <fabricionaweb> it is experimental but looks nice, I see the upgrade MR is opened !80670
2025-02-28 09:25:23 <fabricionaweb> is there any plan about what to do with aports to use user services?
2025-02-28 10:14:02 <navi> there's a few examples of user initds here https://github.com/gentoo/gentoo/pull/40798 also -- for common things i tested with, dbus, pipewire, ssh-agent, plus some profile.d scripts to set up user's env (which i gotta improve a bit still)
2025-02-28 10:42:35 <fabricionaweb> I mean, how can apk-tools know the user to create the initd for that user - or it wont be like that? just instead of enable the root one copy to user directory before run the -U ? so many questions
2025-02-28 10:47:05 <navi> pam_openrc creates `/run/openrc/init.d/user.<username> -> /etc/init.d/user` at login automatically, if `/etc/init.d/user.<username>` doesn't already exist
2025-02-28 10:47:52 <navi> the package manager should install services meant for users in /etc/user/init.d
2025-02-28 14:01:53 <ser> So, when I submitted a new package, I failed to follow the commit message format. If I amend it and do a force-push, is that going to break anything? Or is it safe?
2025-02-28 14:03:22 <PureTryOut> Would be nice if we could install service files to /usr/share/init.d/user or something instead 😅
2025-02-28 14:04:27 <PureTryOut> Anyways let's see if we can move pipewire to be a user service, would be nice to get rid of the hacky launcher script
2025-02-28 14:10:30 <mio> ser: safe, it's on your own branch (and no one else is pushing to it)
2025-02-28 14:12:19 <mio> (the branch may get rebased when the MR is merged, but should be okay)
2025-02-28 14:13:23 <mio> usually trouble arises for force-push when multiple people are pushing to the same branch, best not to force-push in that case
2025-02-28 14:19:32 <WhyNotHugo> can someone merge !77155?
2025-02-28 14:38:32 <WhyNotHugo> thanks!
2025-02-28 14:49:09 <navi> PureTryOut: /usr/libexec/rc/{,user/}init.d is where i'm eventually thinking of supporting
2025-02-28 14:50:42 <navi> and then we'd have the precedence go `{ /etc, /etc/rc, /usr/libexec/rc, /run/openrc/ }`
2025-02-28 14:52:55 <WhyNotHugo> can a package be both "noarch" and only limited to two architectures?
2025-02-28 14:53:14 <WhyNotHugo> E.g.: hare-cairo depends on hare (only two arches), but the package has nothing architecture-specific
2025-02-28 14:58:06 <ikke> Yes, but only by excluding other arches 
2025-02-28 14:58:42 <ikke> There's no way to specify no arch but only these 2 arches 
2025-02-28 15:25:02 <streampunk> Doesn't tracing detect noarch and override it? so you could specify the two arch and the package is still noarch?
2025-02-28 15:32:36 <ikke> ser: could you also fixup the commits so that you only keep the last commit (but with all the changes)?
2025-02-28 15:33:15 <ikke> streampunk: it will not override package metadata, at most warn or error
2025-02-28 16:09:00 <bl4ckb0ne> > ERROR: intel-graphics-compiler-2.7.11-r0.apk: package file format error
2025-02-28 16:09:04 <bl4ckb0ne> what causes that error?
2025-02-28 16:09:32 <bl4ckb0ne> builds and packaging are going fine, repository index fails
2025-02-28 16:10:31 <ikke> Sometimes invalid metadata
2025-02-28 16:16:09 <pj> fossdd: thanks, cleared
2025-02-28 16:19:40 <bl4ckb0ne> could a retry fix it?
2025-02-28 16:20:22 <ikke> bl4ckb0ne: can you share the APKBUILD?
2025-02-28 16:20:34 <ikke> bl4ckb0ne: I don't think just rebuilding would fix such an issue
2025-02-28 16:20:54 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71645/diffs?commit_id=c6b8cff6326ac3aa94a4e560b4fb974616c9a157
2025-02-28 16:21:07 <bl4ckb0ne> it was working before, I did a bump to 2.7.11 through abump
2025-02-28 16:22:01 <bl4ckb0ne> i had the issue locally but thought it was a fluke and pushed it
2025-02-28 16:30:05 <ikke> bl4ckb0ne: maybe the unicode characters in the package description?
2025-02-28 16:38:10 <bl4ckb0ne> no diff with iconv beside the mode
2025-02-28 16:39:48 <bl4ckb0ne> locally i see a lot of `libfakeroot internal error: payload not recognized!
2025-02-28 16:46:25 <bl4ckb0ne> upgrading the local system fixed the libfakeroot issue
2025-02-28 16:46:32 <bl4ckb0ne> rebuilding still fails, ends with `abuild-rmtemp: No such file or directory`
2025-02-28 16:48:35 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10119 might be related
2025-02-28 16:50:02 <bl4ckb0ne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71645/diffs?diff_id=1363768&start_sha=46f0e5bb1919b69d20933d51473ca157cc697372 thats the whole diff of the bump
2025-02-28 18:40:24 <bl4ckb0ne> 2.5.6 fails locally now 
2025-02-28 18:46:51 <psykose> the /usr/lib/pkgconfig/igc-opencl.pc it installs most likely has an invalid version that looks like 2.7.0+0 or whatever
2025-02-28 18:48:42 <psykose> hm nah abuild would catch that
2025-02-28 18:48:46 <psykose> anyway the pkginfo shows the issue
2025-02-28 18:48:48 <psykose> provides = so:libigc.so.2=2.7.0+0
2025-02-28 18:50:06 <psykose> the shared lib is libigc.so.2.7.0+0 so the way abuild uses the name makes it put that =2.7.0+0 which is then invalid cause it's not validated
2025-02-28 18:50:12 <psykose> i think
2025-02-28 18:50:27 <psykose> easiest fix is patching the version in cmake or whatever the source is to not add the +0
2025-02-28 18:56:23 <bl4ckb0ne> thanks psykose 
2025-02-28 18:57:05 <psykose> some shit like https://img.ayaya.dev/nPE9pZkAMJZ8
2025-02-28 18:59:20 <bl4ckb0ne> https://github.com/intel/intel-graphics-compiler/commit/70a2fbc3d6eb3929c8c9ef367e593228fb0fc480 it was introduced in a recent commit 
2025-02-28 19:01:12 <bl4ckb0ne> hm nope its in 2.9
2025-02-28 19:03:55 <bl4ckb0ne> https://github.com/intel/intel-graphics-compiler/commit/44118b4fbe1cf479257d3822e1c80db7c1f1a76d
2025-02-28 19:20:51 <bl4ckb0ne> fixed o/
2025-02-28 19:21:44 <bl4ckb0ne> thanks again psykose 
2025-02-28 20:37:40 <bl4ckb0ne> now that its fixed, new aports in !71645 are up for review pls