2026-02-01 09:07:53 <ikke> Will reboot gbr2-dev1, which hosts a number of webfacing applications like pkgs.alpinelinux.org an security.alpinelinux.org
2026-02-01 09:11:38 <ikke> It's back
2026-02-01 10:33:59 <Newbyte> Anyone at Fosdem?
2026-02-01 15:14:43 <leviakatsuki> Heya heya! Can anyone lend me a small hand? Trying to update the branch I'm working on my fork of aports. it is behind by a... small margin(9600 commits behind, 19 commits ahead). I did added upstream(aports git repo directly), fetched master just to make sure that my local changes are right, then used 'git merge upstream/master' to merge it in. Is this correct? would this mess the git history?
2026-02-01 15:25:42 <ikke> leviakatsuki: you want to make sure it's a fast-forward merge
2026-02-01 15:26:14 <ikke> ie, it should not open an edit asking for a commit message for example
2026-02-01 15:27:39 <leviakatsuki> Yeah good thing I didn't pushed XD cuz it did asked
2026-02-01 15:35:11 <leviakatsuki> okay I can't use 'git merge --ff-only master' cuz it says I'm diverging? git tells me to either 'git merge --no-ff'(afaik that'd mess things up) or 'git rebase'
2026-02-01 15:41:51 <ikke> That means you have created commits on your local master branch
2026-02-01 15:42:17 <ikke> If you do not care about those commits, I would reset your local master branch to match the upstream version
2026-02-01 15:48:56 <leviakatsuki> my local master branch is clear? even did 'git branch -D master; git checkout -b master upstream/master', then 'git branch -D fchat-horizon; git checkout -b fchat-horizon origin/fchat-horizon', but when I do either 'git merge --ff-only master' or 'git merge --ff-only upstream/master', it says that the branches are diverging. 'fchat-horizon' is the branch I actually made changes to (the APKBUILD I'm working on to add the horizon package)
2026-02-02 00:42:07 <infinte[m]> anyone try virtualbox kvm backend
2026-02-02 07:11:39 <qaqland> ncopa: could you take a look at !95130, it is ready (copy from the past)
2026-02-02 11:44:23 <ikke> qaqland: ncopa is away atm
2026-02-02 12:23:52 <ffoss> In /etc/fonts/fonts.conf, only /usr/share/fonts and $XDG_DATA_HOME/fonts are listed as font directories, omitting /usr/local/share/fonts
2026-02-02 12:24:42 <ffoss> fc-list will still list fonts under /usr/local/share/fonts, but f.ex rust package fontdb won't detect them
2026-02-02 12:28:41 <ffoss> looking at fontconfigs configure script, im not quite sure how to add it
2026-02-02 13:39:49 <unrznbl> is there support for a pkgdesc for sub packages?
2026-02-02 13:41:31 <lotheac> sure there is. assign pkgdesc="whatever" in the subpackage function
2026-02-02 13:42:02 <unrznbl> yep, just found the example in aports, thanks!
2026-02-03 10:58:08 <Kladky> Hey, I'm having a little trouble upgrading `cargo-insta`, due to differences in behaviour with the `diff` command in CI vs local `abuild-rootbld`: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96906#note_580653
2026-02-03 15:01:01 <qaqland> it's so strange, two lines output are missing only on armv7 and s390x. https://gitlab.alpinelinux.org/qaqland/aports/-/jobs/2203641#L1354
2026-02-03 15:17:42 <Sertonix[m]> My only guess would be something like IO buffers that aren't flushed
2026-02-04 07:31:37 <qaqland> how can i reduce the number of jobs when building clang?
2026-02-04 07:32:23 <qaqland> i want to test it locally, but was oom killed :(
2026-02-04 07:32:31 <lotheac> it uses ninja? you can do ninja -j8
2026-02-04 07:33:23 <lotheac> or -j 8, i don't remember if it insists on that space
2026-02-04 07:35:30 <qaqland> https://github.com/ninja-build/ninja/pull/816
2026-02-04 07:35:44 <lotheac> yeah
2026-02-04 07:35:45 <qaqland> oh, there is no environment to set it
2026-02-04 07:35:52 <lotheac> no other way except command line
2026-02-04 07:35:53 <ikke> We use Samurai 
2026-02-04 07:36:12 <ikke> It should heed $JOBS
2026-02-04 07:36:15 <lotheac> oh
2026-02-04 07:37:30 <lotheac> i can't find that in the upstream samurai source
2026-02-04 07:37:55 <qaqland> https://github.com/michaelforney/samurai ?
2026-02-04 07:38:18 <lotheac> that's the one i'm looking at yeah
2026-02-04 07:40:18 <qaqland> https://github.com/michaelforney/samurai/blob/737f702fed670acb25e5e70b4b802690df7a4a8b/samu.c#L113
2026-02-04 07:40:50 <ikke> Ah, we set SAMUFLAGS="-j$JOBS"
2026-02-04 07:41:08 <qaqland> :)
2026-02-04 07:41:13 <lotheac> right, that makes sense
2026-02-04 07:41:20 <lotheac> i was just grepping for JOBS and coming up empty
2026-02-04 07:42:05 <lotheac> well, that's good to know
2026-02-04 07:42:56 <ikke> (default.conf in abuild source)
2026-02-04 11:02:13 <omni> /usr/libexec/rc/sh/openrc-run.sh: line 157: check_userns: not found
2026-02-04 11:02:15 <omni> ?
2026-02-04 11:07:19 <lotheac> i'm as confused as you are, git log -G check_userns in openrc upstream source returns nothing and so does rg check_userns /usr/libexec/rc on my machines
2026-02-04 11:24:40 <ikke> I don't see a version of openrc-run.sh that has a call to check_userns
2026-02-04 20:37:54 <jvvv> if an aport installs a file that replaces a busybox link, shouldn't that aport have to define a provider_priority for that replacement?
2026-02-04 20:43:19 <jvvv> when ever I start trying really understand all the ramifications of provides, replaces, and the *_priorities for these, after a while I give up, telling myself "OK, maybe come back to this later".
2026-02-04 20:44:09 <jvvv> does this topic make anyone elses' head hurt?
2026-02-04 20:47:12 <ikke> jvvv: BusyBox links are not tracked and automatically overwritten 
2026-02-04 20:47:29 <ikke> You don't need to do anything special 
2026-02-04 20:50:02 <jvvv> OK, let's take an example that I am looking at... gawk. it installs the link /usr/bin/awk -> gawk. so if I want a local aport to be able to 'own' that link, are there any options... kind of hypothetical, but I think this opens the point
2026-02-04 20:51:23 <jvvv> my local aport would need a replaces line?
2026-02-04 20:57:13 <jvvv> I guess I am bringing this up at a bad time, since the TSC issue about alternates is still a discussion point.
2026-02-04 20:57:30 <jvvv> *being discussed
2026-02-04 21:05:40 <runxiyu> so if i install and remove gnu coreutils... i end up with no ls?
2026-02-04 21:09:11 <jvvv> no, because the post-deinstall runs busybox -s to re-establish the links
2026-02-04 21:09:27 <jvvv> post-deinstall for coreutils
2026-02-04 21:14:19 <jvvv> unless, of course, you disable running the scripts (apk del --scripts=false coreutils). then you would end up with no ls... though you cound still run `busybox ls`
2026-02-04 21:15:10 <jvvv> and `doas busybox --install` to get missing symlinks installed
2026-02-04 21:16:32 <jvvv> * probably better with `doas busybox --install -s`
2026-02-04 21:19:44 <jvvv> without the -s would be hard links and you probably don't want that
2026-02-05 01:00:12 <Sertonix[m]> jvvv: Only if 2 packages should be installed at the same time and contain the same file you need a replaces. In almost all cases that means that it isn't really needed when stuff is properly put into subpackages
2026-02-05 01:08:01 <jvvv> Sertonix[m]: thanks for the added clarity
2026-02-05 01:10:33 <jvvv> I probably should have explained what I'm trying to use it for. I am working on a local copy of the chimerautils aport that can be used as a coreutils like package. Similar to what omni did with uutils.
2026-02-05 01:21:52 <Sertonix[m]> I would honestly just prepend it to PATH and complain to projects that don't use PATH to locate binaries
2026-02-05 01:28:49 <jvvv> yeah, well, that would work in the general case, I agree.
2026-02-05 06:20:53 <prabu> For the rtl8192eu-src package, the driver size shot up from 1M to 18M in the recent past: https://tpaste.us/me4g. Can someone suggest, if this is related to enabling of debug symbols discussed on this list earlier. should this be fixed? If yes, appreciate some pointers..
2026-02-05 06:28:21 <prabu> please ignore the above message.. the latest one has reverted to 1M. 
2026-02-05 09:42:19 <fabricionaweb> hi, I was checking with the developer if he plans to keep the repository/fork since is quite new, answer is positive, they enabled issues (was disabeld) and we have some plans moving on, so I think the testing aport could help us, if someone wants to review/check it !96626 
2026-02-05 12:10:30 <omni> lotheac: you use apparmor? I think it's since !96887 but haven't dug more into it
2026-02-05 12:12:35 <lotheac> i don't use apparmor
2026-02-05 12:13:03 <lotheac> i am still confused about your problem because i can't find any reference to "check_userns" anywhere
2026-02-05 12:13:23 <omni> ah, I thought you saw the same message on boot
2026-02-05 12:13:31 <lotheac> nope
2026-02-05 12:18:10 <omni> downgraded to *apparmor*4.1.3-r0*.apk, rebooted and the error was gone
2026-02-05 12:41:26 <lotheac> i'm curious how apparmor relates to openrc-run, but too busy to dig into it now
2026-02-05 12:41:31 <lotheac> maybe later
2026-02-05 12:41:42 <lotheac> i would have assumed they're completely separate
2026-02-05 13:37:36 <dne> when bumping a package on a stable branch, for which you've taken over maintainership (on master), is it expected/recommended that you also update the maintainer on that branch?
2026-02-05 13:38:32 <ikke> Good question, doesn't come up often, but I think it makes sense.
2026-02-05 13:39:20 <guisso> hello people, I'm new with alpine ecosystem, I just use alpine in my containers without knowing so much, but I want to learn more to contribute with the project, specially in security the ecosystem. Can anyone share with me what I need to study it?
2026-02-05 13:39:46 <dne> ikke: yes I thought so, thanks
2026-02-05 13:40:55 <ikke> guisso: welcome!
2026-02-05 14:39:18 <ayakael> jvoisin: I reviewed the MR, sorry for the wait!
2026-02-05 14:41:09 <jvoisin> it's ok <3
2026-02-05 18:17:31 <guisso> Thanks ikke can you help me or point someone that I can get some help?
2026-02-05 18:19:57 <f_> guisso: checkout the wiki - wiki.alpinelinux.org
2026-02-05 18:20:09 <f_> install it in a VM
2026-02-05 18:20:11 <f_> etc :)
2026-02-05 18:43:40 <ikke> guisso: anything specific regarding security you are interestede in? One way you could help is tracking packages with openstanding security issues and create MRs for them
2026-02-05 20:18:55 <ikke> Have we ever considered building go packages with -linkshared (requires go install -buildmode shared -linkshared std)
2026-02-05 20:21:22 <sam_> the docs say it is experimental, first I heard of it though
2026-02-05 20:21:56 <ikke> I just tried it with a project, at least with std it's working
2026-02-05 20:22:08 <ikke> libstd.so => /tmp/go/pkg/linux_amd64_dynlink//libstd.so (0x7ff64a600000)
2026-02-05 20:22:47 <ikke> Thinking of it, not sure it would help a lot, since I don't think the ABI will be stable
2026-02-05 20:24:06 <ikke> So you end up still needing to rebuild everything when go is upgraded
2026-02-05 20:33:10 <ikke> ok, so it's basically deprecated
2026-02-05 20:33:22 <ikke> "In particular, we're not fixing any bugs in it anymore, ..."
2026-02-05 20:35:29 <sam_> :(
2026-02-05 20:35:39 <ikke> https://github.com/golang/go/issues/47788#issuecomment-954890659
2026-02-05 22:23:53 <Ariadne> re: https://gitlab.alpinelinux.org/alpine/council/-/issues/702#note_581494 I do confirm that endorsement, I also think that it should not be surprising that an event intended to grow the development base would grow the development base.
2026-02-05 22:24:23 <Ariadne> I will comment on the issue when at a computer that can accept my FIDO token.
2026-02-05 22:25:35 <Ariadne> I also think durrendal's argument is a bit silly in #702
2026-02-05 22:26:04 <Ariadne> if someone is acting in bad faith then they act in bad faith and are removed from the project
2026-02-05 22:36:30 <sam_> i'm surprised someone is even making that argument
2026-02-05 22:36:36 <sam_> i don't think i've ever actually seen it before in a context like this
2026-02-05 22:36:49 <sam_> at most we've had it occasionally on our side when someone's employer uses $distro 
2026-02-05 22:36:58 <sam_> seems like concern trolling 
2026-02-06 13:23:20 <Sertonix[m]> Ariadne: It basically depends on what the rule of requiring 2 endorsments is meant to protect against
2026-02-06 13:25:06 <Sertonix[m]> (If it doesn't try to or can't protect against anything it seems useless)
2026-02-06 13:49:46 <durrendal> Essentially yes, that was my concern, that if it's a gating function it's a loose one. That may be intentional, which is fine if so
2026-02-06 13:50:22 <durrendal> It was a sincere concern from someone who has been around a decade and cares sincerely about the project.
2026-02-06 13:53:28 <Sertonix[m]> Is anybody interested in taking over maintainance of testing/ettercap? The current maintainer isn't interested anymore and otherwise I would remove the package
2026-02-06 13:54:25 <durrendal> I can take it if nobody else does, might actually use that
2026-02-06 13:59:40 <Sertonix[m]> Ok, I don't think there is competition since it's a few versions behind
2026-02-06 14:00:19 <Ariadne> Sertonix[m]: i think it is simply meant to ensure that the applicant has collaborated with more than one developer
2026-02-06 14:00:41 <Ariadne> i do not think it has any more meaning than that :)
2026-02-06 14:02:12 <Sertonix[m]> Sounds a bit like unnecessary complexity to me
2026-02-06 14:02:52 <Ariadne> how so?  the question is "list two developers that endorse the application"
2026-02-06 14:03:03 <Ariadne> i think that is a perfectly reasonable question
2026-02-06 14:03:35 <Ariadne> though i would suggest changing the question to: list two or more developers which endorse the application
2026-02-06 14:04:22 <Ariadne> and i think requiring at least two sponsors makes sense, because you want multiple views on whether the applicant should be trusted
2026-02-06 14:05:13 <Sertonix[m]> I mean that the existance of a rule can introduce edge cases which wouldn't exist otherwise. Eg. what is when everybody except for 1 person has to step down from their positions?
2026-02-06 14:06:25 <durrendal> Would you find it contextually helpful to know if both the endorsers and the endorsed worked for $company on the same department on the same team? Maybe just additional info on the relationship if any for the sake of transparency would help inform the application further. 
2026-02-06 14:08:34 <Sertonix[m]> durrendal: That answer to this question isn't bound insize
2026-02-06 14:09:58 <Sertonix[m]> Hence nobody would/could answer it correctly, making it useless.
2026-02-06 14:11:45 <Sertonix[m]> And I think it would be up to the council to track down any bad faith which would need to assume that give information is not right/complete. Again making it useless as protection
2026-02-06 14:15:10 <durrendal> if the assumption is that the protection is the councils vote, that the council will correct any issues where bath faith occurs, then early disclosure of such relationships acts to document and enrich the application process, nothing more.
2026-02-06 14:16:14 <durrendal> That is the intent of the developer endorsement as stated, a signal. So adding another signal provides more data to consider. Maybe it's important to note that someone has known good work on something like postmarket, or works for IBM maintaining powerpc systems. 
2026-02-06 14:16:43 <durrendal> If the intent is just data, then my argument is just that, would this bit of additional information help. 
2026-02-06 14:17:26 <durrendal> And the answer can be no, yes, indifference. It isn't my decision to make, and ikke's answer satisfied my curiosity on the matter.
2026-02-06 14:18:58 <Ariadne> Sertonix[m]: if an alpine developer retires, it would not impact any developer they sponsored
2026-02-06 14:19:06 <Ariadne> so i do not understand this edge case :)
2026-02-06 14:20:12 <Sertonix[m]> I mean that it would be impossible to propose a new developer in that state
2026-02-06 14:20:33 <Ariadne> or if you are implying that something happens where every alpine developer except for one person is not able to participate in the project anymore.  in that case, that one remaining person is effectively benevolent dictator and installs whatever governance they wish to install.  the old governance is moot at that point.
2026-02-06 14:21:26 <Sertonix[m]> Yes, it is an example of an edge case existing, not necesarrily with a bad effect in this case
2026-02-06 14:22:15 <achill> Ariadne: offtopic but i think for these cases it really benefit having a legal entity, this would clarify what happens and give some ensurance to users, instead of just yoloing it
2026-02-06 14:22:46 <Ariadne> i don't agree
2026-02-06 14:23:10 <Ariadne> because if all but one alpine developer are suddenly no longer in the picture, then the legal entity is also moot.
2026-02-06 14:23:22 <Ariadne> most likely anyway
2026-02-06 14:23:26 <Sertonix[m]> Who wants to be the person to get sued fot everything :)
2026-02-06 14:24:17 <achill> Sertonix[m]: i think documenting this or similar edgecases is really out of the scope of the developer process, this is really bike-shedding, you cant possibly document every possible scenerio lol
2026-02-06 14:24:19 <Ariadne> i also think this scenario is unlikely, and in the most likely outcome where this happens, it is some fallout hellscape where alpine maintenance likely is not a priority anyway
2026-02-06 14:25:16 <Sertonix[m]> achill: I was suggesting that the rule can be removed, not to document edge cases
2026-02-06 14:25:37 <achill> why would one remove the rule because of this edge case lol
2026-02-06 14:25:50 <Ariadne> achill: to be clear, i do think we should replace our informal collective with a legal entity, but i do not think a legal entity matters in a scenario where all but one alpine developer are suddenly unable to participate (because most likely some society-breaking event has happened anyway)
2026-02-06 14:26:25 <Sertonix[m]> achill: have you read my earlier comments?
2026-02-06 14:26:40 <achill> Ariadne: agreed, tbh i dont even know how to start imagining this scenario
2026-02-06 14:27:06 <Ariadne> well you can install fallout 3 (the newer ones are garbage and not worth playing IMO)
2026-02-06 14:27:29 <achill> bought fallout 4 like 2 years ago but never played it lol
2026-02-06 14:27:38 <achill> but then wouldnt be alpine dead as a whole?
2026-02-06 14:27:53 <Ariadne> yes, that is what i am saying
2026-02-06 14:27:54 <achill> Sertonix[m]: yeah?
2026-02-06 14:28:17 <Ariadne> there would be no time to maintain alpine because you have to drive to gas town or whatever
2026-02-06 14:29:20 <Sertonix[m]> You mean working on tooling to make distro maintainance a 1 person job isn't a good idea?!
2026-02-06 14:30:17 <achill> unpopular opinion, but imo distro maintainance with 13000 packages cant ever be a single-person-job
2026-02-06 14:30:24 <ptrc> to be fair, there's a surprising amount of distros where it's just a single person doing everything
2026-02-06 14:30:32 <ptrc> the fact that they haven't ever gotten a stable release is surely unrelated
2026-02-06 14:30:54 <ptrc> or, well, anything besides a really nice proof of concept
2026-02-06 14:31:01 <Sertonix[m]> Lazy maintainance, update only things which are in use
2026-02-06 14:31:08 <achill> stable release, what is that, we have our rolling branch for that
2026-02-06 14:31:22 <Ariadne> Sertonix[m]: i think efficiency gains are good, but the distributions that people actually build trust in have social capital behind them which requires more than one participant
2026-02-06 14:31:35 <ptrc> Sertonix[m]: i've been doing that for a while when i was more active in alpine, going through /lib/apk/db/installed and checking for updates :p
2026-02-06 14:32:13 <Ariadne> incidentally it would be nice to disable all this AI crap in mozilla packages by defualt :)
2026-02-06 14:32:39 <ptrc> i've been thinking of making a page with a master switch mere days before the firefox team announced it :p
2026-02-06 14:32:59 <Sertonix[m]> "How did we get here?"
2026-02-06 14:33:22 <ptrc> ( i even started working on some code based off of the mobile config from pmOS, but didn't find the time to ever finish it )
2026-02-06 14:33:52 <achill> ptrc: lol that sounds fun
2026-02-06 14:34:28 <ptrc> but then, yeah, i fully plan on making AI opt-in in firefox, possibly with a page added to the upstream onboarding flow that informs the user about it
2026-02-06 14:36:05 <ptrc> as an unrelated side note, i kinda wish apkbrowser supported regexes
2026-02-06 14:36:37 <achill> patches welcome /hides
2026-02-06 14:37:00 <achill> but seriously, i think that should be easy enough
2026-02-06 14:37:40 <ptrc> i mean, i feel like there's a reason someone made a silly glob format instead of just using regexes
2026-02-06 14:38:44 <ptrc> actually, hold on
2026-02-06 14:38:50 <ptrc> oh no
2026-02-06 14:39:58 <Sertonix[m]> I think it would be possible create an index with all ADB sections combined and then dump as json + jq to do everthing you want.
2026-02-06 14:40:25 <ptrc> i mean, i can just curl all the apk indexes and process them locally, i've been doing that for some usecases
2026-02-06 14:40:31 <ptrc> but apkbrowser is nice
2026-02-06 14:41:09 <ptrc> but then, yeah, it just puts the glob into the SQL query directly and uses the globbing feature of sqlite
2026-02-06 14:41:18 <Sertonix[m]> Oh, I need more than the indexes to search for files 😅
2026-02-06 18:43:47 <Saijin_Naib[m]> achill IIRC, you were fixing up gstreamer recently, right? Before I open a Bug, I wanted to ask if these behaviors are expected, or unexpected sideffects for the gstreamer upgrade. QuodLibet is showing as missing from gstreamer bs2b, chromaprint and Exaile is crashing because it can't find gstreamer element directsoundsink. Exail was working prior to the upgrade. From what I can tell, these should be in gst-plugins-base.
2026-02-06 18:55:55 <achill> we might miss a few plugijs
2026-02-06 18:57:03 <achill> if you can open issue I can take a look at it later
2026-02-06 18:57:22 <achill> am very exhausted right now xd
2026-02-06 19:26:35 <Saijin_Naib[m]> Yeah, no worries/rush. I just wanted to check first. I'll open an issue later tonight
2026-02-07 22:13:44 <eloy> is there a policy on packaging web applications? should it or not include a web server? or should it not be packaged at all?
2026-02-07 22:14:02 <quinq> Some are
2026-02-07 22:55:15 <logan2611> When backporting from edge to stable, do I need to have commit parity with edge or can I squash?
2026-02-08 07:33:37 <ikke> logan2611: If you would separate out changes in edge, you should keep them separate when backporting as well
2026-02-08 11:10:54 <quinq> it seems that the wiki is down on inet6
2026-02-08 11:11:37 <quinq> Hummm, now just very slow
2026-02-08 11:11:48 <quinq> It establishes connection directly, but content takes a while to come
2026-02-08 11:14:27 <quinq> Seems to be back now
2026-02-08 12:05:41 <achill> omni: oops looks like we have both our hands on the same MRs
2026-02-08 12:09:03 <omni> hard to avoid
2026-02-08 12:10:06 <omni> just trying to take the chance to suggest removal of superfluous golang envvars and such when I see them in MRs
2026-02-08 12:11:28 <achill> yeah i agree this is good
2026-02-08 12:12:22 <achill> in general, i just want to remove e.g. GO* treewide, but that needs probably a lot of manual checks
2026-02-08 12:13:33 <ikke> Yeah, better to handle it as you toch it
2026-02-08 12:13:35 <ikke> touch*
2026-02-08 12:14:00 <achill> yeah i guess so
2026-02-08 14:11:44 <lotheac> re: !96921 - imo, we should reject this sort of stuff
2026-02-08 14:12:51 <lotheac> 3.17 is so old that we cannot endorse it in any way, it's detrimental to make any change to it because someone might think we care about it now
2026-02-08 14:13:10 <achill> why would you reject something if people still care about it and do t he work
2026-02-08 14:13:21 <lotheac> because it's a statement
2026-02-08 14:13:33 <ikke> lotheac: our statement atm on https://alpinelinux.org/releases/ is "on request"
2026-02-08 14:14:10 <achill> tbh i dont think so, it shows that we're a community distro and if people work on stuff that doesnt hurt us, i would never reject it
2026-02-08 14:14:18 <lotheac> i guess then it depends on the definition of "request"
2026-02-08 14:14:52 <achill> request in the form of "you do work, we merge" and not "you file issues, we work on it"
2026-02-08 14:15:13 <lotheac> but just because someone made one MR against a really-old branch does not make it "supported" in any sense of the word, imo
2026-02-08 14:15:21 <achill> sure
2026-02-08 14:15:23 <achill> it is not
2026-02-08 14:15:45 <achill> but if somebody wants to add a commit to a completley-unsupported-EOL-branch, why would be block it?
2026-02-08 14:16:14 <ikke> And it's not a questionable patch, but updating it to an upstream release version
2026-02-08 14:16:15 <achill> if the actual changes look sane and doesnt add more work or disadvantages to us, the maintainers
2026-02-08 14:16:38 <lotheac> to the contrary, achill, why would we *not* block it?
2026-02-08 14:16:51 <achill> because it benefits at least a single person
2026-02-08 14:16:56 <lotheac> what can anyone gain from that merge?
2026-02-08 14:17:04 <achill> security fixes
2026-02-08 14:17:36 <achill> if issues are filed or something, we can still say "go upgrade". but in this case, they did the work
2026-02-08 14:17:58 <lotheac> so your point is that someone makes a request to merge a thing, and our infrastructure builds all that and makes a nice packaged thing for them
2026-02-08 14:18:27 <achill> in this case, its something that applies to almost every alpine 3.17 user, not just serves a single person
2026-02-08 14:18:55 <achill> but it was the request of a single person, that still benefits a lot of people, without us giving any disadvantages
2026-02-08 14:19:15 <achill> like, the infra build-time of a single openssl bump, is nothing
2026-02-08 14:19:24 <lotheac> i want to disincentivize people using alpine 3.17
2026-02-08 14:19:33 <lotheac> not give them anything more
2026-02-08 14:20:08 <lotheac> "oh, look, they still update it!"
2026-02-08 14:20:10 <ikke> ncopa has always been accomodating, not strict
2026-02-08 14:20:18 <achill> no lotheac
2026-02-08 14:20:21 <achill> its still EOL
2026-02-08 14:20:25 <achill> officially
2026-02-08 14:20:54 <achill> just because someone updates it unofficially doesnt make it official. what people assume of it, is of course out of the question
2026-02-08 14:21:18 <achill> and tbh i'd rather have 3.17 users have a security fix more, than not
2026-02-08 14:23:11 <lotheac> "official" does not matter at all when it's about "apk upgrade" being possible or not
2026-02-08 14:23:54 <ikke> We don't make any new releases or anything so that they get a clean docker image for example
2026-02-08 14:24:00 <lotheac> my opionion is that accommodating long-dead releases is actively harmful
2026-02-08 14:24:16 <lotheac> but it may be just me
2026-02-08 14:24:19 <achill> its not harmful? how does this harms people or us?
2026-02-08 14:24:44 <achill> if they use a EOL-branch they are on their own and they know that
2026-02-08 14:24:48 <achill> i have an idea
2026-02-08 14:25:32 <achill> what if we add a post-commit apk hook on EOL branches that say "your EOL". this will be visible to every alpine user of a EOL branch and communicates them the state in a transparent way
2026-02-08 14:25:46 <lotheac> "yeah, we still update those NN year old branches with security updates" sends a message that is _wrong_
2026-02-08 14:26:46 <lotheac> it creates expectations that we cannot adhere to
2026-02-08 14:26:56 <ikke> We're not actively providing fixes. They need to do the work for it.
2026-02-08 14:27:01 <achill> exactly
2026-02-08 14:27:12 <achill> what do you think about my idea? im happy to write a TSC issue about that
2026-02-08 14:27:54 <ikke> I recall something like that has come up before
2026-02-08 14:28:06 <lotheac> i would support that
2026-02-08 14:28:21 <lotheac> i actually would prefer those branches being RO
2026-02-08 14:29:06 <ikke> There may be good reasons to backport something
2026-02-08 14:29:10 <achill> lotheac: this would just hurt people. there are various reasons why people cant upgrade to a newer alpine version or need more time. and accomodating them, with: if they do work, we merge, jugs benefits both
2026-02-08 14:29:24 <lotheac> ikke: sure, but not forever
2026-02-08 14:29:46 <ikke> lotheac: looking at the release page, v3.13 is set to "none" support level
2026-02-08 14:29:51 <achill> i want to make the internet more stable, and this is a way that has no downsides for us, but actively helps users
2026-02-08 14:30:30 <achill> ikke: oh, then i think the infra team could also remove the 3.12 and 3.13 runners lol
2026-02-08 14:30:39 <achill> *builders on build.a.o
2026-02-08 14:31:13 <ikke> We don't actively define what builders are shown on there
2026-02-08 14:31:36 <ikke> It just shows which builders have sent messages since our mqtt broker last restarted
2026-02-08 14:31:44 <achill> ah
2026-02-08 14:32:15 <lotheac> ikke: i have no idea what your point is :)
2026-02-08 14:33:03 <ikke> lotheac: That v3.14-v3.19 still receive limited support
2026-02-08 14:33:21 <ikke> or in other words, not EOL yet
2026-02-08 14:33:52 <achill> yeah, the official support is ended, but its based on a best-effort base
2026-02-08 14:34:04 <achill> but no package maintainers have to backport there
2026-02-08 14:34:53 <lotheac> i don't understand why you're pointing that out
2026-02-08 14:35:05 <ikke> lotheac: You say we should make those branches read-only
2026-02-08 14:36:36 <lotheac> well, then i'm also saying that those branches should not receive limited support anymore
2026-02-08 14:37:13 <ikke> That's a policy change
2026-02-08 14:37:21 <lotheac> sure
2026-02-08 14:38:24 <lotheac> but it's not as if it's a written policy thus far anyway
2026-02-08 14:39:04 <achill> yes its a unwritten policy, but a policy currently in place, documentation of all our policies is on my todo, but unrelated to this
2026-02-08 14:39:54 <achill> there are written policies that maintainers just must backport to supported branches, which kinda implies un-supported branches dont have to be handeled by the maintainer
2026-02-08 14:41:07 <achill> but yeah, i disagree with your policy change, if the internet is a safer places with fewer security vulnerabilties because EOL branches are on a best-effort base instead of a no-go base, then i would keep it as is
2026-02-08 14:41:41 <ikke> The reason we don't update those branches is to reduce the amount of work we need to do
2026-02-08 14:41:57 <ikke> If others do the work, then what's a good reason to actively refuse that
2026-02-08 14:42:05 <achill> +1
2026-02-08 14:43:04 <lotheac> my entire point is that it's not about the work, it's an expression of assurance
2026-02-08 14:43:18 <ikke> There is no assurrance
2026-02-08 14:43:21 <lotheac> "oh, they updated this just now"
2026-02-08 14:44:27 <lotheac> if some random person updates openssl in 3.17, and alpine linux releases that update, it is in fact alpine linux that released that update
2026-02-08 14:45:17 <lotheac> which does give the feeling of "hey alpine is still updating 3.17"
2026-02-08 14:45:46 <ikke> Just a single package, out of many more that are not updated
2026-02-08 14:45:52 <lotheac> *that* is what i think is counterproductive
2026-02-08 14:45:59 <ikke> and stil may (and most likely have) security issues
2026-02-08 14:47:16 <lotheac> it's really hard to understand what was *not* updated
2026-02-08 14:51:28 <ikke> In the end, it's their own responsibility, not ours
2026-02-08 14:51:28 <achill> lotheac: we cant ever assume what people think about stuff and what not, and nor should we. we're a open source community where everything is more or less best-effort, and i wouldn't decline work only because "people might assume it official" even if its not
2026-02-08 14:51:29 <lotheac> in any case, sorry :) this is a mostly academic conversation imho
2026-02-08 14:51:59 <lotheac> achill: i agree
2026-02-08 14:52:23 <achill> the actual problem is communicating what is EOL and what not. we dont do that by declining work for EOL branches, we do that by adding something like this post-commit hook or something else that communicates it directly
2026-02-08 14:52:38 <lotheac> but a project like this isn't about accepting or rejecting "work", it's more than that
2026-02-08 14:52:42 <Sertonix[m]> lotheac: You are assuming somebody who didn't understand what alpine supports. If they didn't try to understand this it seems like their own fault and not something which people who understand should suffer from
2026-02-08 14:54:51 <achill> lotheac: yeah but as i said, we have no downsides by accepting work
2026-02-08 14:54:59 <achill> i mean this kind of work
2026-02-08 14:55:13 <lotheac> Sertonix[m]: i didn't understand what you just said, can you rephrase? :D
2026-02-08 14:56:02 <lotheac> achill: yeah, you're right on that
2026-02-08 14:58:15 <Sertonix[m]> The people who falsely think that an EOL branch has support will probably also use the non-EOL branches in ways that are not supported. So I see little use in bothering people who probably didn't try to understand what is supported in the first place
2026-02-08 14:59:21 <lotheac> this is exactly why i think it's not a good idea to update those branches
2026-02-08 14:59:46 <lotheac> it causes work
2026-02-08 15:00:42 <achill> to say it again: the actual problem is communicating what is EOL and what not. we dont do that by just not updating EOL-branches. we do that by communication this directly to users, e.g. with alpinelinux.org or a post-commit hook.
2026-02-08 15:00:49 <achill> lothec: not more work for us
2026-02-08 15:01:37 <lotheac> unnecessary work is unnecessary work, whether or not it's "us"
2026-02-08 15:01:52 <Sertonix[m]> I was not refering to the people who use EOL branches and ensure that their thread model isn't broken by that
2026-02-08 15:01:57 <achill> its not unnecessary. its affecting many many installations, that now get a security fix :)
2026-02-08 15:02:01 <achill> its never unnecessary
2026-02-08 15:02:12 <Sertonix[m]> Those people I see no problem in supporting
2026-02-08 15:03:11 <achill> Sertonix[m]: if they know that they are doing, they know what theyre doing. but people unaware of what EOL is, is who we should target to making them more aware
2026-02-08 15:03:31 <achill> but please dont do that, by "not updating EOL"
2026-02-08 15:03:37 <achill> it just hurts other people
2026-02-08 15:05:32 <lotheac> achill: i suppose what i want to say is, we as maintainers do not "accept work". we take on responsibility for someone else's work
2026-02-08 15:06:03 <achill> what kind of responsibility do you have in mind?
2026-02-08 15:06:24 <lotheac> you and me are responsible for what is in alpine
2026-02-08 15:06:39 <achill> sure, but how does that relate to the conversation?
2026-02-08 15:07:13 <achill> accepting security fixes for EOL branches is also being responsibile
2026-02-08 15:07:24 <achill> but something we do as a best effort base
2026-02-08 15:08:25 <achill> i'm happy to take responsibility for the 3.17 sec upgrade I merged. if it breaks people, nag me about it. if i blocked the builders with it, nag me about it. but what more do you have in mind?
2026-02-08 15:09:01 <lotheac> sorry. nothing further :)
2026-02-08 15:10:13 <lotheac> i would also like to take a moment to say that you're _amazing_ in how much you contribute to alpine
2026-02-08 15:10:29 <lotheac> and we all owe so much to you for that
2026-02-08 15:11:12 <achill> yeah i should probably learn more for my exams xd
2026-02-08 15:11:26 <lotheac> sometimes i'm grumpy, sorry for that. don't let it get to you :D
2026-02-08 16:36:50 <alimj[m]> Question: After submitting a PR to aports, if the PR is marked as merged blocked since there has been changes since the original PR, should I continuously rebase or wait for the reviewer advise? It passed the CI/CD workflow on the original PR.
2026-02-08 16:39:39 <iodomi[m]1> is anybody interested in dangerzone aport? i'm certain that i won't port it alone... here's the current progress: https://gitlab.alpinelinux.org/iodomi/aports/-/tree/dangerzone/testing/dangerzone?ref_type=heads
2026-02-08 17:11:06 <ikke> alimj[m]: no need to continuously rebase
2026-02-08 17:11:19 <ikke> alimj[m]: It will be rebased right before merging
2026-02-08 17:16:42 <alimj[m]> iodomi: I do not see why not to have an aport for it. Devs of Freedom of the press foundations are usually very helpful and usually supportive of such initiatives. That is based on my past experiences.
2026-02-08 17:29:28 <iodomi[m]1> alimj: i'm asking because i could either have you to help me or ask the devs for help, i'm not sure if i'm doing everything right and there are issues that need to be addressed..
2026-02-08 17:31:05 <alimj[m]> Contacting deeplow (of FOTPF) would be helpful. He does most of the coordination of their org with Qubes project. I might be able to get you in touch with him.
2026-02-08 17:32:37 <alimj[m]> iodomi:  As for the testing, I have two or three Alpine VMs of different versions on my Qubes machine. I might be able to test it.
2026-02-08 17:33:18 <iodomi[m]1> okay would be nice
2026-02-08 17:34:15 <alimj[m]> iodomi: Getting in touch with the FOTPF? Or the actual testing? Or both?
2026-02-08 17:35:05 <iodomi[m]1> you can try and test it for now and then maybe get in touch with the dev
2026-02-08 20:06:38 <user0> hi, could !96377 be merged?
2026-02-08 21:54:10 <alimj[m]> iodomi: For the Dangerzone, where you able to install `py3-pymupdf` from edge? That dependency appears to be broken?
2026-02-08 21:54:36 <alimj[m]> I just had some time to take a look
2026-02-08 21:56:12 <iodomi[m]1> alimj: what is broken? it is on edge/testing
2026-02-08 22:02:33 <alimj[m]> iodomi: When I try to install `py3-mupdf` manually (with edge/testing enabled), I get `so:libmupdf.so.26.12 (no such package)` and `so:libmupdfcpp.so.26.12 (no such package)`
2026-02-08 22:08:37 <iodomi[m]1> alimj: i don't have missing libs while installing it, must be something with your setup, do you use edge for main and community?
2026-02-08 22:08:48 <iodomi[m]1> also maybe try the APKBUILD
2026-02-08 22:09:14 <alimj[m]> Ok. I will check again
2026-02-08 22:11:56 <alimj[m]> 243 packages to upgrade this entire VM packages to edge. This should take some time
2026-02-08 22:12:21 <iodomi[m]1> okay we'll wait
2026-02-08 23:10:59 <alimj[m]> iodomi: The previous issue is solved. Wasn't it necessary to add `poetry` to build requirements in APKBUILD? And does `poetry run mazette install` part of the build complete successfully on your machine?
2026-02-08 23:16:15 <iodomi[m]1> alimj: you mean moving `poetry` from depends -> makedepends? yes mazette does build as well as the container, you see tests are a bit problematic
2026-02-08 23:17:58 <iodomi[m]1> about the container im not sure as it didn't seem to start but that i will have to recheck
2026-02-08 23:18:01 <alimj[m]> iodomi: I mean the main `poetry` package should be added to `makedepends`.
2026-02-08 23:18:43 <iodomi[m]1> alimj: oh sure i will add it
2026-02-08 23:20:50 <alimj[m]> At this level it is getting a little bit more involved than my general knowledge of this project. I guess it might be better to wait for deeplow to respond. He does the CI/CD work for Qubes OS build and has better experience.
2026-02-08 23:21:19 <alimj[m]> i.e. CI/CD of building dangerzone on Qubes OS
2026-02-08 23:21:52 <iodomi[m]1> altough py3-poetry-core has worked just fine under my circumstances i'm not sure if we really need the entire package
2026-02-08 23:22:55 <alimj[m]> Well. The main poetry command used in build section of the APKBUILD belongs to the main package. Not the python one
2026-02-08 23:24:10 <iodomi[m]1> right
2026-02-08 23:24:34 <iodomi[m]1> alimj: thanks for your help anyway i'll be waiting for deeplow's reply
2026-02-09 02:50:47 <Sertonix[m]> fossdd: Are you interested in https://codeberg.org/sertonix/rports/src/commit/3fc2926d0b523d2e5e10f62be7d782327756c03f/random/cinny-desktop/APKBUILD ?
2026-02-09 06:14:47 <Saijin_Naib[m]> achill I assigned the issue with gstreamer plugins seemingly missing to you
2026-02-09 09:00:10 <achill> Sertonix[m]: not really tbh, maybe if they merged it and released it
2026-02-09 09:47:21 <Saijin_Naib[m]> Can anyone help me with a package step where I have to put a .so in /usr/lib/deadbeef
2026-02-09 09:47:45 <Saijin_Naib[m]> I'm using install "soname.so" "/usr/lib/deadbeef/sonaome.so" but it errors out that a regular file can't be installed, permission denied
2026-02-09 09:47:47 <Saijin_Naib[m]> I'm missing something obvious here
2026-02-09 09:49:42 <Saijin_Naib[m]> install: cannot create regular file '/usr/lib/deadbeef/ddb_misc_waveform_GTK3.so': Permission denied
2026-02-09 09:52:27 <Biswa96[m]> mkdir -p /usr/lib/deadbeef/ ?
2026-02-09 09:52:44 <Biswa96[m]> * mkdir -p $pkgdir/usr/lib/deadbeef/ ?
2026-02-09 09:53:46 <Biswa96[m]> or, install -D
2026-02-09 09:57:24 <Saijin_Naib[m]> install -D "gtk3/ddb_misc_waveform_GTK3.so" "/usr/lib/deadbeef/ddb_misc_waveform_GTK3.so"
2026-02-09 09:57:26 <Saijin_Naib[m]> gives the same error
2026-02-09 09:57:40 <Saijin_Naib[m]> The file exists, compilation was successful, it stats, but the install is wrong
2026-02-09 09:58:13 <ikke> Saijin_Naib[m]: you miss $pkgdir
2026-02-09 09:58:35 <Saijin_Naib[m]> ahh, for the destination argument?
2026-02-09 09:59:33 <ikke> Yes
2026-02-09 10:00:39 <Saijin_Naib[m]> my hero haha
2026-02-09 10:00:47 <Saijin_Naib[m]> thank you
2026-02-09 10:00:57 <ikke> Biswa96[m]: already pointed it out indirectly
2026-02-09 10:01:16 <Saijin_Naib[m]> Oh yeah
2026-02-09 10:01:17 <Saijin_Naib[m]> haha
2026-02-09 10:01:26 <Saijin_Naib[m]> I'm bad at this and it is very late
2026-02-09 10:01:33 <Saijin_Naib[m]> Sorry, thanks for the help too, Biswa96
2026-02-09 11:03:48 <f_> oh wow riscv64 is slow
2026-02-09 11:04:26 <f_> if I'm packaging something and it doesn't build in a timely manner on the riscv64 CI builder, do I disable riscv64?
2026-02-09 11:39:53 <Sertonix[m]> What do you call a timely manner? But I know that at least some packages are disabled on riscv64 due to being slow
2026-02-09 11:52:55 <f_> Sertonix[m]: in time
2026-02-09 11:53:15 <f_> doesn't build in a timely manner   means it takes so long gitlab CI kills the build
2026-02-09 11:53:53 <f_> I think I'll just disable it, the stuff I'm packaging isn't really meant to be used on riscv
2026-02-09 11:54:07 <f_> except maybe PineTab-V
2026-02-09 11:55:25 <Sertonix[m]> gitlab CI has configurable timeout so that is not usable as unit
2026-02-09 12:00:33 <f_> How?
2026-02-09 12:06:19 <ikke> In CI/CD settings
2026-02-09 12:06:22 <ikke> Of your fork
2026-02-09 17:22:55 <ncopa> hi
2026-02-09 17:24:16 <ikke> ncopa: o/
2026-02-09 17:24:51 <ncopa> had some days off. feel refreshed
2026-02-09 17:25:04 <ikke> Nice
2026-02-09 17:27:55 <jvoisin> nice
2026-02-09 17:34:05 <quinq> Hi
2026-02-09 17:34:10 <quinq> I got a weird message when upgrading
2026-02-09 17:34:28 <quinq> “The /usr/libexec/pipewire-launcher script will be removed in the future to replace it with OpenRC user-services.”
2026-02-09 17:34:57 <quinq> I didn't install any /usr/libexec/pipewire-launcher
2026-02-09 17:35:25 <invoked> that is normal on adding the pipewire packages, iirc
2026-02-09 17:35:38 <invoked> i was using that script until yesterday
2026-02-09 17:36:45 <quinq> I mean how does that concern the pipewire package
2026-02-09 17:37:03 <invoked> because pipewire doesn't launch itself
2026-02-09 17:37:31 <quinq> But it's done through OpenRC
2026-02-09 17:37:37 <invoked> it can be.
2026-02-09 17:37:45 <quinq> Well, yeah
2026-02-09 17:38:01 <quinq> Does it use this internal pipewire-launcher?
2026-02-09 17:38:55 <invoked> pipewire-launcher is an alpine kludge that sets the env and runs pipewire for the user
2026-02-09 17:39:11 <invoked> at least i think it's specific to alpine
2026-02-09 17:39:17 <quinq> Ahhh, I get it now.
2026-02-09 17:39:26 <quinq> It was in the Alpine wiki
2026-02-09 17:39:33 <quinq> So I suppose some people did this instead of using user scripts
2026-02-09 17:39:56 <quinq> (https://wiki.alpinelinux.org/wiki/PipeWire)
2026-02-09 17:40:47 <invoked> yeah. the /etc/user/ scripts for pipewire also have some deprecated syntax that needs patching, which you'll see what i mean if start the user services interactively
2026-02-09 17:41:17 <invoked> i should create a bug about that but it'd be cool if someone would confirm i'm not high
2026-02-09 17:42:03 <quinq> Well, I have it installed on the laptop, because web browser are not able to work with alsa, they rely on complex sound management
2026-02-09 17:42:14 <quinq> I can try, what do you need?
2026-02-09 17:43:21 <quinq> Na, works for me
2026-02-09 17:43:37 <quinq> $ rc-service -U pipewire restart
2026-02-09 17:43:49 <quinq> No unexpected message 
2026-02-09 17:43:50 <invoked> yeah
2026-02-09 17:44:15 <invoked> hm. i wonder if i have config baggage somewhere. i'm not on that machine rn though
2026-02-09 17:45:00 <quinq> maybe yeah
2026-02-09 17:45:20 <invoked> user configs end up in ~/.config/pipewire ... but i remember checking the error against the /etc/user/ scripts and the error made sense
2026-02-09 17:45:34 <invoked> are you on edge?
2026-02-09 17:45:39 <invoked> the repo, not personally
2026-02-09 17:45:43 <quinq> I'm high and on edge
2026-02-09 17:45:46 <quinq> ah ;)
2026-02-09 17:45:52 <quinq> Yeah, the laptop is following edge
2026-02-09 17:45:59 <invoked> that's a difference.
2026-02-09 17:46:02 <quinq> But it's work laptop and has now been turned off ;p
2026-02-09 17:49:34 <invoked> as for alsa, and all that. i start alsa, and unmute the card in amixer, then install the pipewire stuff, and get that to run when my compositor starts (sway or river), by calling the gui runlevel as the wiki prescribed
2026-02-09 17:49:55 <invoked> it just works.  it shouldn't be that elaborate for users but, whatever.
2026-02-09 17:50:44 <invoked> for a mixer i use pulsemixer (which requires pipewire-pulse)
2026-02-09 18:25:50 <jvvv> May I get a review of !97252 ? I need it for rebuild of freecad against pyside6-dev.
2026-02-09 18:39:41 <ikke> jvvv: fyi, our preference is to use patches instead of sed
2026-02-09 18:39:55 <ikke> Though, not sure if standard patches work here
2026-02-09 18:40:16 <jvvv> that was my thinking... I can try, tho
2026-02-09 18:53:35 <achill> would be good yeah
2026-02-09 19:10:30 <jvvv> ok, I'm testing a patch now. thank you for reviewing.
2026-02-09 19:55:56 <jvvv> no good
2026-02-10 00:34:10 <jvvv> !97252 should be more satisfactory
2026-02-10 07:17:34 <Saijin_Naib[m]> If I'm trying to package a python package, but it needs to use/import itself for the testsuite, how the F do I do that
2026-02-10 07:17:57 <Saijin_Naib[m]> py3-librosa, audio analysis engine, runtime depends for Pitivi for audio features
2026-02-10 07:18:42 <Sheila> set PYTHONPATH?
2026-02-10 07:22:17 <Saijin_Naib[m]> Is there an example of a py3 aport that does that?
2026-02-10 07:22:36 <Saijin_Naib[m]> It isn't packaged yet, but it was sucessfully built with abuild just prior to the test part
2026-02-10 07:23:12 <quinq> $ grep -F PYTHONPATH */*/APKBUILD
2026-02-10 07:23:29 <Saijin_Naib[m]> I'm using the newapkbuild -e template
2026-02-10 07:23:55 <quinq> That won't help on your question
2026-02-10 07:48:09 <dne> Saijin_Naib[m]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/py3-django/APKBUILD#L152-156
2026-02-10 07:50:20 <Saijin_Naib[m]> Yeah, that is the default test block from the template
2026-02-10 07:50:37 <Saijin_Naib[m]> And that one skips tests so it might be broken like mine is currently
2026-02-10 07:50:47 <Saijin_Naib[m]> thank you, though
2026-02-10 07:51:18 <dne> oh, well, the pattern works
2026-02-10 07:51:29 <Saijin_Naib[m]> Hmm, okay
2026-02-10 07:51:35 <Saijin_Naib[m]> I must be missing something then
2026-02-10 07:52:16 <dne> how does the upstream run the tests?
2026-02-10 07:54:23 <Saijin_Naib[m]> https://github.com/librosa/librosa/tree/main/tests
2026-02-10 07:55:45 <Saijin_Naib[m]> It looks quite complicated, requires generating data with matlab and custom matlab functions, and internet access
2026-02-10 07:55:56 <Saijin_Naib[m]> and options="!check" it is haha
2026-02-10 07:56:59 <dne> right
2026-02-10 07:57:26 <Saijin_Naib[m]> The documented --librosa-isolation flag doesn't work either, causes the pytest check to fail due to unrecognized option
2026-02-10 07:57:33 <Saijin_Naib[m]> So, yeah, I'm at a loss
2026-02-10 07:57:36 <jvvv> Saijin_Naib[m]: you could look in the .github subdirectory of a project and look for how they run their CI
2026-02-10 07:58:04 <jvvv> I'm looking at their .github/workflows/ci.yaml right now
2026-02-10 07:59:00 <jvvv> *ci.yml
2026-02-10 08:01:18 <Saijin_Naib[m]> Oh, that is a good idea/tip, thanks
2026-02-10 08:02:32 <jvvv> so following what community/py3-django does in its test(), taking into consideration differences in where your package outputs its stuff (--wheel-dir arg for gpep57), then you should be able to adjust it to your needs
2026-02-10 08:02:54 <jvvv> *gpep517
2026-02-10 08:05:46 <jvvv> dne: sorry, I shouldn't step on toes... bad habit
2026-02-10 08:06:23 <dne> jvvv: no pb, I was done :)
2026-02-10 08:08:57 <Saijin_Naib[m]> hmm, okay
2026-02-10 08:09:03 <Saijin_Naib[m]> I'll see if I understand
2026-02-10 08:19:47 <staceee_> someone could give a review to this mr please? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91737
2026-02-10 08:19:56 <staceee_> am sitting on this for a while :3
2026-02-10 08:25:35 <Saijin_Naib[m]> I do not, haha
2026-02-10 08:45:34 <Saijin_Naib[m]> It built and works locally, so that is something
2026-02-10 08:45:36 <Saijin_Naib[m]> another night
2026-02-10 08:45:41 <Saijin_Naib[m]> thanks for the pointers
2026-02-10 10:48:23 <Habbie> gitlab broken?
2026-02-10 10:49:03 <ikke> Seems to work here
2026-02-10 10:49:23 <Habbie> fine again here as well, except my comment is gone
2026-02-10 10:49:45 <ikke> oof
2026-02-10 10:49:55 <ikke> I see a very brief spike in datrabase connections
2026-02-10 10:49:59 <ikke> database(
2026-02-10 10:50:33 <Habbie> oh wait. different problem.
2026-02-10 10:50:36 <Habbie> I accidentally started a review
2026-02-10 10:50:39 <ikke> aha
2026-02-10 10:50:41 <Habbie> gitlab's UX is not for me
2026-02-10 10:50:56 <Habbie> .. or did i
2026-02-10 10:50:58 <Habbie> i dunno
2026-02-10 10:51:00 <Habbie> typed the comment again
2026-02-10 10:51:02 <Habbie> !97245
2026-02-10 10:51:07 <Habbie> we are again collectively confused about how to use secfixes
2026-02-10 10:52:02 <ikke> secfixes document when a vulnerability is fixed
2026-02-10 10:52:07 <ikke> in aports
2026-02-10 10:52:13 <Habbie> ok
2026-02-10 10:53:19 <ikke> The primary purpose is to document things we fix ourselves. Oficially the CPEs on the CVE should suffice to determine whether an upgraded package is fixed, but people still want us to explicitly document it
2026-02-10 10:54:02 <Habbie> this time i did accidentally start a review, but managed to post it too
2026-02-10 10:54:08 <Habbie> ikke, ah!
2026-02-10 14:35:35 <dne> is it ok to use the (undocumented) variable $tmpdir in APKBUILD? (I see that a tiny number of existing APKBUILDs do)
2026-02-10 14:52:16 <ncopa> in theory it is not safe to use anything undocumented in APKBUILD that is not prefixed with _
2026-02-10 14:54:00 <dne> thanks
2026-02-10 19:37:31 <jvvv> is there anything that can be done abuild nodejs-current build failures for ppcle64... not sure this can be of help: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97122#note_582610
2026-02-10 19:38:26 <ikke> The builder has 128G memory
2026-02-10 19:40:44 <jvvv> oh, sounds that note is not the fix. ppcle64 assembler is outside of my knowledge. Wish I could find a fix.
2026-02-10 19:41:40 <ikke> "increase the addressable range"
2026-02-10 19:47:07 <ikke> cc1: error: '-mcmodel' incompatible with other toc options
2026-02-10 19:49:06 <ikke> jvvv: If you want me to test something on the builder, I'd be happy to test
2026-02-10 19:51:41 <jvvv> ikke: Thanks. I'm researching issue more so that I understand it better. I'll reach out if I come up with anything worth trying.
2026-02-10 19:51:48 <ikke> ack
2026-02-10 19:52:25 <ikke> jvvv: not certain, but I have a recollection this may have to do with binutils
2026-02-10 19:53:13 <jvvv> thanks! that may well help me
2026-02-10 19:54:49 <ikke> similar issue: https://github.com/ocaml/ocaml/issues/13220
2026-02-10 19:56:30 <ikke> context: https://stackoverflow.com/a/6490638
2026-02-10 19:58:13 <ikke> I guess some inline assemly that's not valid for ppc64le
2026-02-10 19:59:12 <jvvv> yeah, which why I was looking at 'as' docs. I'll look at those links. Thanks
2026-02-10 20:04:47 <ikke> go 1.26 has been released: https://go.dev/doc/go1.26
2026-02-10 20:51:46 <jvvv> As a side note about the ppcle64 build failures, the nodejs-current upgrade never passed CI for ppcle64
2026-02-11 07:48:13 <caskd> Could someone have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/91737 ?
2026-02-11 07:54:48 <jvvv> x86_64 CI is getting oom. Is there a work around?
2026-02-11 07:56:27 <ikke> jvvv: for what package?
2026-02-11 07:58:25 <jvvv> !97313
2026-02-11 08:01:14 <jvvv> I bumped the _MEMORY_REQUEST in the .gitlab-ci.yml. Is that OK?
2026-02-11 08:01:34 <ikke> No
2026-02-11 08:01:52 <jvvv> will change it back now
2026-02-11 08:01:52 <ikke> And that does not fix OOM in any case
2026-02-11 08:02:05 <ikke> jvvv: Let's see what it does now
2026-02-11 08:02:13 <ikke> Please leave that job running
2026-02-11 08:03:52 <jvvv> ikke: the x86_64 OOM again anyway, but the other arches are passing so far
2026-02-11 08:05:20 <jvvv> Strange that it OOM on x86_64, but not x86
2026-02-11 08:05:49 <ikke> Yes
2026-02-11 08:05:55 <ikke> I guess it uses more memory
2026-02-11 08:07:22 <ikke> Hmm, it's getting a different limit than expected
2026-02-11 08:35:35 <jvvv> frustrating
2026-02-11 08:36:00 <ikke> jvvv: I'm testing something
2026-02-11 08:37:42 <jvvv> cool
2026-02-11 08:39:57 <jvvv> I tried reducing the patch to just adress the ppc toc issue, but obviously it only seems to helping the ppc64le CI build. The other arches have me flummoxed... maybe I'm just getting over tired.
2026-02-11 08:43:01 <jvvv> The newer fails could be due to the simdutf changes but that seems unlikely
2026-02-11 08:46:16 <jvvv> ikke: I wasn't frustrated by the pipelines being cancelled, only the failures.
2026-02-11 08:46:47 <ikke> jvvv: understood
2026-02-11 08:46:54 <jvvv> I appreciate you trying to help
2026-02-11 08:48:19 <ikke> Let's see what happens now
2026-02-11 08:51:29 <ikke> It's a bit of a design decission, do we oversubscribe the ci hosts or not
2026-02-11 08:51:55 <ikke> It's now running on a node with more resources available, so wondering if that works
2026-02-11 08:52:49 <jvvv> well, the x86_64 has made it passed the previous failure point, so crossing my fingers
2026-02-11 08:54:40 <jvvv> It's this kind of thing that makes me think that work you do it some of the most crucial.
2026-02-11 08:54:52 <jvvv> s/it/is/
2026-02-11 08:57:31 <jvvv> I've spent no small amount of time trying to come up to speed with kubernetes, xen, and terraform so that some day maybe I could help you. Sadly, I'm still no where near knowledge with the parts and pieces to be of any real help. I keep at it, but this old brain of mine is not as quick as it used to be for learning.
2026-02-11 08:58:15 <jvvv> *knowledgable
2026-02-11 09:03:08 <jvvv> It's the terraform part that I find the most daunting.
2026-02-11 09:08:19 <ikke> Terraform for me has one of the more simple things to grasp, at least the basics
2026-02-11 09:08:49 <ikke> We could move this to #alpine-infra
2026-02-11 09:09:44 <jvvv> Sure, but first, should I restart the other arches CIs?
2026-02-11 09:10:35 <ikke> It would be good to make sure the other arches pass, otherwise we may fix ppc64le, but break other arches
2026-02-11 09:11:08 <jvvv> Thanks for all the help, I am very grateful.
2026-02-11 12:02:25 <ikke> jvvv: all jobs passed now
2026-02-11 16:44:54 <qaqland> https://git.alpinelinux.org/aports/tree/community/foot/APKBUILD#n56
2026-02-11 16:45:10 <qaqland> foot run test in its build part
2026-02-11 18:48:22 <jvvv> ikke: \o/
2026-02-11 18:48:32 <jvvv> thanks for the heads up
2026-02-11 18:48:36 <ikke> yw
2026-02-11 20:39:51 <iodomi[m]1> lnl
2026-02-11 20:39:51 <iodomi[m]1> seems like something's up with latest chromium build, i've just done upgrade
2026-02-11 20:39:51 <iodomi[m]1> [0211/213329.132065:WARNING:third_party/crashpad/crashpad/snapshot/linux/process_reader_linux.cc:95] sched_getscheduler: Function not implemented (38)
2026-02-11 20:39:51 <iodomi[m]1> ...
2026-02-11 20:39:51 <iodomi[m]1> [0211/213329.132292:WARNING:third_party/crashpad/crashpad/snapshot/linux/process_reader_linux.cc:95] sched_getscheduler: Function not implemented (38)
2026-02-11 20:39:52 <iodomi[m]1> zsh: illegal hardware instruction (core dumped)  chromium
2026-02-11 20:39:52 <iodomi[m]1> [0211/213329.143322:WARNING:third_party/crashpad/crashpad/snapshot/linux/process_reader_linux.cc:95] sched_getscheduler: Function not implemented (38)
2026-02-11 21:01:57 <achill> iodomi[m]1: can you open a issue? :)
2026-02-11 21:02:27 <iodomi[m]1> sure on a different browser :)
2026-02-11 21:12:32 <iodomi[m]1> here !17954
2026-02-11 21:13:07 <iodomi[m]1> not a MR lol
2026-02-11 21:13:08 <iodomi[m]1> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17954
2026-02-11 21:25:39 <jvoisin> can I get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97024 merged before the navidrome dev decides to make yet another point release? :P
2026-02-12 09:00:57 <qaqland> have a question about abuild-sudo, why not just set the file permissions to 4750, only users in abuild could use it
2026-02-12 10:21:20 <Sertonix[m]> Sounds like a good idea
2026-02-12 10:35:16 <ikke> Why not 4754?
2026-02-12 10:37:09 <ikke> Or even keep the x bit, if you are not in the abuild group, you'll get a helpful message
2026-02-12 10:39:08 <ikke> abuild-sudo itself directly not, but you execute it through symlinks)
2026-02-12 13:50:56 <Sertonix[m]> It would protect against potential bugs in our code.
2026-02-12 14:49:49 <bl4ckb0ne> fossdd: whats the insipiration for the branch name in !97408? (and thanks for handling the leftovers)
2026-02-12 14:50:12 <achill> was trying to write jellyfin but mistyping and then just pressed random letters on my keyboard lol
2026-02-12 14:50:18 <bl4ckb0ne> heh
2026-02-12 14:50:20 <ikke> lol
2026-02-12 14:50:45 <bl4ckb0ne> should've been more careful with the /etc/ change
2026-02-12 15:00:11 <lotheac> branch names are kinda pointless. jj generates mine :)
2026-02-12 15:03:13 <ikke> lotheac: I've noticed :P
2026-02-12 15:03:18 <ikke> They are usefull while working with them
2026-02-12 15:03:51 <ikke> I like somewhat descriptive branch names so it's easier to distinguish them
2026-02-12 15:04:08 <lotheac> i just look at jj log to find the changeid if i need to distinguish something /shrug
2026-02-12 15:04:27 <achill> i just type whatever comes to my mind, most of my branches are called meow or something
2026-02-12 16:53:42 <jvvv> something weird with asymptote for riscv64... it built in CI... nothing should be blocking it for riscv64 that I can find, but it does not show up in the buildlogs or in the riscv64 community repo
2026-02-12 16:55:37 <jvvv> it is not an arch that I have access to, so it is not pressing issue for myself, but does seem a bit odd
2026-02-12 16:58:20 <ikke> jvvv: it's still building main
2026-02-12 16:58:39 <ikke> may be hanging
2026-02-12 17:01:47 <jvvv> oh, good point. I forgot that I only just enabled it for riscv64 with the recent upgrade, so that makes sense
2026-02-12 17:05:16 <jvvv> after fixing the build issues for it, I have been keeping my eye on the build status. I will just have to be patient.
2026-02-12 17:32:15 <ikke> gnutls keeps hanging
2026-02-12 17:37:49 <jvvv> I notice for the  related MR, that rather than just riscv64 there is optional riscv64-emulated which does not seem to have run
2026-02-12 17:38:03 <jvvv> in the CI pipelines
2026-02-12 17:38:31 <ikke> That would be for an older release then
2026-02-12 17:39:40 <jvvv> that does not seem to be the case in the MR merged into master, but perhaps I am missing something
2026-02-12 17:39:49 <ikke> Before we had native hardware, we emulated rv64 on x86_64, and you could opt-in into running the pipeline
2026-02-12 17:39:55 <ikke> jvvv: which MR?
2026-02-12 17:41:38 <jvvv> ikke, sorry I am looking at an old MR
2026-02-12 17:47:03 <jvvv> perhaps adding a checkdepends of softhsm
2026-02-12 17:47:43 <jvvv> sorry, no wrong line
2026-02-12 17:48:13 <ikke> It hangs on test-pthread-rwlock
2026-02-12 18:00:13 <ikke> gitlab is restarting for security patches
2026-02-12 18:05:56 <ikke> gitlab is back
2026-02-12 18:14:22 <jvvv> the riscv64 builder is real hw? just wondering if trying to reproduce gnutls hang in container or vm will be worth it.
2026-02-12 18:14:55 <ikke> It's a container on real hw
2026-02-12 18:15:20 <ikke> fyi, it seems to be a known issue: https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00174.html
2026-02-12 18:16:54 <ikke> https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00174.html
2026-02-12 18:17:08 <ikke> https://git.alpinelinux.org/aports/commit/?id=75d3777e6a0e17aa6789dc7aa54cfc59ed9c1924
2026-02-12 18:17:33 <jvvv> i could prepare an MR addressing that, I have time, skip that test on
2026-02-12 18:17:45 <jvvv> riscv64, or all if preferred
2026-02-12 18:37:00 <ikke> That whould be helpful
2026-02-12 18:39:13 <jvvv> working on it
2026-02-12 18:39:49 <ikke> fyi, a pkgrel bump is not necessary
2026-02-12 18:54:57 <jvvv> thanks
2026-02-12 19:19:04 <jvvv> ikke: !97421
2026-02-12 19:32:46 <ikke> riscv64 is now building community, but I'm not sure it was due to that patch
2026-02-12 19:34:55 <jvvv> I don't think it has made it the builder yet. the current log file shows the failure
2026-02-12 19:49:19 <ikke> oh, I accidentally looked at 3-23
2026-02-12 21:01:12 <ikke> It's building gnutls now
2026-02-12 21:01:20 <ikke> And stuck again (which is expected)
2026-02-12 21:03:51 <pc_magas> Hello I had upon aports my package merged and released upon testing. I made a new version how should author the commit message for the new release?
2026-02-12 21:05:23 <ikke> testing/my-package: upgrade to <new-version>
2026-02-12 21:11:18 <pc_magas> Also why there are conflicts upon? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97429
2026-02-12 21:11:41 <ikke> "There are no changes yet "
2026-02-12 21:12:16 <ikke> The commits  that you pushed are already in master, and unrelated to your merge request
2026-02-12 21:16:32 <pc_magas> Ok I redit it.
2026-02-12 21:17:03 <ikke> pc_magas: my-package was supposed to be replaced with the name of your package
2026-02-12 21:17:29 <ikke> you can run `git commit --amend`
2026-02-12 21:17:33 <ikke> and then edit the message
2026-02-12 21:17:39 <ikke> and then run `git push --force-with-lease`
2026-02-12 21:18:30 <ikke> pc_magas: "make: *** No rule to make target 'bin'.  Stop."
2026-02-12 21:20:18 <pc_magas> hmm I need to look that 10q
2026-02-12 21:25:33 <jvvv> huh, did it same as in the gettext and diffutils fixes
2026-02-12 21:29:30 <ikke> jvvv: The builder only picks up new changes after it failed or finished
2026-02-12 21:29:44 <ikke> While it's in a build sequence, it will not run git pull
2026-02-12 21:30:28 <ikke> If built now: https://build.alpinelinux.org/buildlogs/build-edge-riscv64/main/gnutls/gnutls-3.8.12-r0.log
2026-02-12 21:39:55 <jvvv> thanks for heads up! saved me bunch of time researching needlessly
2026-02-12 21:40:43 <jvvv> gnulib is a bloat pita
2026-02-12 21:48:29 <jvvv> on the bug ml for the issue ncopa reported, at one point bruno admits it is useless in https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00179.html, then goes off on a tangent later about optimizing the mess... smh
2026-02-12 21:49:38 <jvvv> I feel confident that bh is much much better coder than me, but sounds like he (like me) also suffers from some ADHD
2026-02-12 21:50:10 <jvvv> sorry, rant done
2026-02-13 02:00:14 <AFdev[m]> Is there anyone looking for full stack and AI engineer?
2026-02-13 07:13:42 <puretryout[m]1> Lol no, spammer
2026-02-13 07:14:23 <sam_> he said it is useless _for gettext_ because gettext doesn't really use that module
2026-02-13 07:14:46 <sam_> i wouldn't diagnose him with adhd based on then analysing libc behaviour and refining it
2026-02-13 07:15:07 <sam_> (keeping in mind the reason it was failing)
2026-02-13 07:40:26 <Saijin_Naib[m]> Did the minizip-ng compat layer discussion ever wind up at a resolution?
2026-02-13 07:53:28 <Saijin_Naib[m]> Also, I need guidance here
2026-02-13 07:53:29 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97292
2026-02-13 07:53:47 <Saijin_Naib[m]> I fixed the shell escaping that the linter picked up, but now the pyc subpackage fails
2026-02-13 07:53:56 <Saijin_Naib[m]> If I go back to un-quoted, linter is mad, but pyc succeeds
2026-02-13 08:06:14 <lotheac> this is one case where you *need* the unquoted behavior. but why are you not using default_pyc?
2026-02-13 08:07:12 <lotheac> as for the actual shell behavior / shellcheck complaint, https://www.shellcheck.net/wiki/SC2046 also lists some alternative approaches you can use
2026-02-13 15:15:11 <Saijin_Naib[m]> Ah okay, I read that in ShellCheck sometimes it is needed, but dont understand why
2026-02-13 15:16:06 <Saijin_Naib[m]> As for not default_pyc, no idea, I didnt establish this aport. It may not have existed when they did contribute it. Let me try that instead, thanks!
2026-02-13 16:56:33 <jvvv> sam_: fair. I went back through the whole thread and I think you make a good point.
2026-02-13 16:57:22 <ikke> Saijin_Naib[m]: the distinction is between whether the command expects one argument or multiple arguments
2026-02-13 16:58:09 <ikke> Without quotes, the shell will split the contents of a variable by whitespace and provide that to the command as separate arguments
2026-02-13 16:58:21 <ikke> While with quotes, as a single argument
2026-02-13 16:59:15 <Saijin_Naib[m]> Ohh, okay. Thanks, much more clear
2026-02-13 16:59:49 <ikke> Since most people expect the latter (provided as single argument), shellcheck warns you about it
2026-02-13 17:00:15 <ikke> Either use quotes, or explicitly say otherwise
2026-02-13 21:55:09 <pc_magas> I made this PR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97430 but gitlab asks for rebase. Is it reccomended to do so?
2026-02-13 22:00:35 <achill> no need to do this; we'll do it right before merging
2026-02-14 02:05:48 <runxiyu> achill: im running abuild check for go locally, but i only currently have access to an amd64 machine
2026-02-14 02:13:52 <runxiyu>     on my 4-core system
2026-02-14 02:13:52 <runxiyu>  10:13:39 up 20:45,  0 users,  load average: 46.87, 33.23, 17.30
2026-02-14 02:13:53 <runxiyu> uh
2026-02-14 02:33:00 <runxiyu> ah right, you can't really run it on CI properly because of overlayfs/whatever issues
2026-02-14 10:09:14 <quinq> Hello
2026-02-14 10:09:42 <quinq> Is that expected that openrc-run checkpath only works for the last component of a path?
2026-02-14 10:10:18 <quinq> Like checkpath -d /foo/bar/baz, while -d is suppose to create the directory,
2026-02-14 10:10:27 <quinq> It'll fail if bar doesn't exist
2026-02-14 10:10:43 <quinq> Sounds a bit like not very useful
2026-02-14 10:11:19 <quinq> Is there an idiomatic way to work around this limitation?
2026-02-14 10:11:24 <quinq> Is it even intentional?
2026-02-14 10:12:01 <ikke> quinq: probably better to ask in the openrc channel
2026-02-14 10:12:02 <Ermine> you may want to use mkdir -p
2026-02-14 10:12:45 <quinq> Thank you ikke 
2026-02-14 10:13:23 <quinq> Ermine, I meant an openrc work-around, as in I suppose current behavior is intentional, but I'm surely not the first to encounter it as limiting
2026-02-14 10:13:45 <quinq> checkpath is made to not having to use mkdir + chown + chmod
2026-02-14 10:39:45 <quinq> Though maybe achill could help here :D
2026-02-14 10:39:57 <quinq> Sorry, forgot to say that was in the context of jellyfin port
2026-02-14 11:20:52 <quinq> achill, proposal: https://paste.nurd.space/9S3GBNMiaRASYAeh8ZjJX3y5Ouj7MFGexREF4WWfFU4
2026-02-14 11:21:51 <achill> looks good from the first glance
2026-02-14 11:23:13 <quinq> Context, it happened to me right now, the datadir isn't /var/lib/jellyfin, then jellyfin didn't start because /var/lib/jellyfin/config didn't exist (and couldn't be created)
2026-02-14 11:24:07 <quinq> The proposal is a bit hacky and not 100% fullproof, but it works
2026-02-14 11:25:00 <quinq> s/full/fool/
2026-02-14 11:26:04 <quinq> oops, typo there
2026-02-14 11:26:40 <quinq> Updated: https://paste.nurd.space/DBNswNjh9hfnzMCxrRspPunJnE_zr5WhMUIw0wjp8ug
2026-02-14 11:26:57 <quinq> (ffmpegpath wasn't set correctly)
2026-02-14 11:50:07 <quinq> Actually achill, I'm encountering another issue with the update
2026-02-14 11:50:15 <quinq> Will update the patch with a slightly different approach
2026-02-14 11:56:40 <quinq> Maybe this is simpler: https://paste.nurd.space/bCZ22CRuAbmBAlRB1EcR1UwaqFO-WEu3UUr5WVO3cPg
2026-02-14 14:03:15 <runxiyu> hi, is there a way to request temporary access to one of alpine's ppc64le dev servers, if such exists at all?
2026-02-14 14:03:23 <runxiyu> trying to port qbe to ppc64le but qemu emulation is too slow
2026-02-14 14:12:52 <quinq> chromium is dead here
2026-02-14 14:13:02 <quinq> [0214/151255.631484:WARNING:third_party/crashpad/crashpad/snapshot/linux/process_reader_linux.cc:95] sched_getscheduler: Function not implemented (38)
2026-02-14 14:13:05 <quinq> Illegal instruction
2026-02-14 14:13:06 <quinq> (edge/amd64)
2026-02-14 14:40:47 <lnl> #17954
2026-02-14 14:41:10 <quinq> Thank you lnl :)
2026-02-14 15:24:04 <quinq> I also get a segfault in librewolf, something related to gdk-pixbuf not able to load some icon
2026-02-14 15:33:49 <quinq> Coald not load a pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png
2026-02-14 15:35:09 <invoked> edge?
2026-02-14 15:35:40 <invoked> oh, i failed to read.
2026-02-14 15:36:46 <quinq> yep
2026-02-14 15:36:49 <quinq> Oh the frak
2026-02-14 15:36:54 <quinq> I found out why
2026-02-14 15:37:03 <quinq> Not that it justifies a crash, but the cause at least
2026-02-14 15:37:22 <quinq> For some reason there is a flatpak ugly thing that sets XDG_DATA_DIRS to its exclusive path
2026-02-14 15:37:45 <quinq> Unsetting it disables that error path
2026-02-14 15:37:57 <quinq> freaking flatpak, why is it even on my machine
2026-02-14 15:38:16 <quinq> /etc/profile.d/flatpak.sh is faulty
2026-02-14 15:38:39 <quinq> Well, maybe not.
2026-02-14 16:51:36 <invoked> my XDG_DATA_DIRS: ~/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
2026-02-14 16:52:33 <invoked> only reason i have flatpak on is for testing against tor-browser(-launcher) 
2026-02-14 20:35:16 <jvvv> grub-docs empty?
2026-02-14 20:36:34 <jvvv> *grub-doc
2026-02-14 20:43:08 <ikke> https://pkgs.alpinelinux.org/contents?name=grub-doc&repo=main&branch=edge&arch=x86_64
2026-02-14 20:43:10 <ikke> apparently
2026-02-14 20:49:30 <jvvv> just now looking at the APKBUILD for a straight forward way to get docs installed. I am thinking of a doc build _flavor, since no one _flavor is common to all arches.
2026-02-15 03:15:38 <jvvv> looking at https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in?ref_type=heads#L328
2026-02-15 03:20:26 <jvvv> I am conflicted about the --no-nvram switch and even more so that there is no warnings to the user about it. Seems misleading.
2026-02-15 06:44:45 <runxiyu> achill: i can't do it for any version of community/go
2026-02-15 06:44:45 <runxiyu> achill: unfortunately im currently unable to run check
2026-02-15 07:49:38 <ikke> Is the Matrix bridge still borked?
2026-02-15 07:57:46 <ikke> I don't see messages from achill
2026-02-15 08:08:53 <Newbyte> ikke: Do you see this
2026-02-15 08:09:32 <ikke> Newbyte: yes, I do
2026-02-15 12:26:26 <iodomi[m]1> lnl thank you, but should I leave the issue until fully fixed or close it?
2026-02-15 12:34:46 <lnl> I'd say downgrade is not a real fix and still needs a follow-up, especially in chromium
2026-02-15 12:35:24 <quinq> Of course, that'd be a temporal work-around for you to not get stuck
2026-02-15 13:22:43 <iodomi[m]1> yeah that's what I thought
2026-02-15 16:03:46 <quinq> btw, The following packages will be DOWNGRADED: chromium chromium-angle chromium-common
2026-02-15 16:40:24 <quinq> (claws-mail:13849): GdkPixbuf-WARNING **: 17:40:12.607: gdk-pixbuf XPM module lacks XPM data capability
2026-02-15 16:40:27 <quinq> stock_pixmap.c:832 Condition pix_d->pixbuf != NULL failed
2026-02-15 16:40:29 <quinq> Do you know how to solve that?
2026-02-15 16:40:56 <quinq> Most of my gtk software have lost icons for some time nouw
2026-02-16 03:04:09 <WhyNotHugo> Any further feedback for !97023?
2026-02-16 09:21:55 <Kladky> #17970 might be of interest to some people
2026-02-16 09:22:38 <Kladky> On a side note, idk why gitlab applies markdown in titles when viewing the issue, but not the issue list itself, kinda annoying :P
2026-02-16 15:48:56 <durrendal> achill: I see you're working on networkmanager recently, there's a CVE addressed in networkmanager-l2tp 1.52.0, but it's not compatible with 1.52.1, only 1.52.2 and later. I don't have full context on the rest of the networkmanager packages, but would it be safe to bump them to 1.52.2? I'd prefer to do that than downgrade networkmanager-l2tp to a known vulnerable version.
2026-02-16 15:49:30 <achill> oh yeah that should be safe
2026-02-16 15:51:21 <durrendal> Okay cool, wanted to make sure since it seemed like a bit of a fiddly issue. I'll make an MR in a second
2026-02-16 15:51:27 <durrendal> thanks for confirming :)
2026-02-16 15:59:32 <achill> i wish we could upgrade to 1.56 but there are some issues we had downstream with 3.54
2026-02-16 16:05:00 <durrendal> yeah was reading through the issue, we'll get there eventually, better to juggle things like this than break networkmanager though
2026-02-16 17:58:57 <staceee> is the edge x86_64 builder stuck?
2026-02-16 18:14:35 <Kladky> staceee: seems so, failing because of sdc: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/sdc/sdc-0.0.15_git20260102-r1.log
2026-02-17 10:56:33 <neal> Hi, I'm trying to report a bug against gnupg in Alpine.  I've created an account on the gitlab instance, but I don't know what project to file the issue under.
2026-02-17 10:57:40 <PureTryOut> https://gitlab.alpinelinux.org/alpine/aports/-/issues
2026-02-17 10:57:46 <neal> PureTryOut: thank you
2026-02-17 16:13:49 <jahway603[m]> Can I get some insight into !97343? If a user wants to make changes to a package for themselves to run it through AppArmor, wouldn't they just change their own local system instead or proposing changes to an aport package?
2026-02-18 07:12:58 <staceee> riscv64 builds seems to be really out of date. An aports merged two days ago is still not in the repositories
2026-02-18 11:31:15 <ikke> staceee: the community repo (let alone testing) have not been able to be uploaded due to recent rebuilds and upgrades
2026-02-18 21:46:47 <andar1an> is there a sime method when locally testing a package to build for a specific arch?
2026-02-18 21:50:56 <andar1an> also, I am noticing riscv ci builds are taking significant time when it is not specified. Is this normal?
2026-02-18 21:54:36 <ikke> andar1an: sorry, I have difficulties understanding your question
2026-02-18 22:09:51 <jvvv> andypost[m]: for your first question, so long as you have the qemu user package installed for the architecture and qemu-binfmt (from qemu-openrc) setup, you should be able to use abuild rootbld... this would be for riscv64: CBUILD=riscv64 abuild rootbld
2026-02-18 22:12:34 <jvvv> for this to example to work, it needs qemu-riscv64, abuild-rootbld, and qemu-openrc installed. also, need to run `rc-service qemu-binfmt start` prior to running the cross abuild rootbld command.
2026-02-18 22:13:29 <ikke> prepare for it to be slow. riscv64 is slow, riscv64 emulated is even slower
2026-02-18 22:13:47 <jvvv> that is so true
2026-02-18 22:13:50 <ikke> (only benefit is that you can have a lot more cores)
2026-02-18 22:19:37 <jvvv> just as a comfirmation that I remembered it right, I just ran that on the xz aport... for native x86_64 build, it took about 1-2 minutes. for riscv64, it took about 15 minutes
2026-02-18 22:23:12 <jvvv> oh, gees, i've been tagging the wrong nick... sorry andypost[m] 
2026-02-18 22:23:20 <jvvv> andar1an left
2026-02-19 00:13:27 <Ariadne> WhyNotHugo: thanks for your work on hier(7), it is nice to finally have a proper manpage for this
2026-02-19 00:20:23 <WhyNotHugo> cheers!
2026-02-19 00:25:26 <WhyNotHugo> I just noticed I had more local changes for that branch, !97718
2026-02-19 15:16:55 <ikke> Do we already have the uv_build python build backend packaged somewhere? py3-uv (which already depends on uv) does not
2026-02-19 15:21:59 <durrendal> ikke: I tried to package it during an upgrade to py3-bayesian-optimization, but lost track of the MR and it went stale
2026-02-19 15:22:04 <durrendal> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88097
2026-02-19 15:22:40 <durrendal> probably just needs to be rebased honestly, it built fine and the only issue was the loongarch64 CI was offline at the time the MR was created.
2026-02-19 15:25:06 <durrendal> I apparently also had my response to achill's question in pending status for the entire time the MR has been open, painful. Really thought I had responded.
2026-02-19 15:25:33 <ikke> heh, it happens
2026-02-19 15:26:02 <achill> yea
2026-02-19 15:26:19 <achill> but looks ready to merge
2026-02-19 15:27:37 <durrendal> yeah it should be good, I'd let the CI pass first since it's 6m old just to be safe
2026-02-19 15:44:35 <durrendal> looks like ci passed on it, should be safe to merge now :)
2026-02-19 15:47:38 <ikke> durrendal: should py3-uv-backend depend on py3-uv?
2026-02-19 15:47:51 <ikke> or are they distinct dependencies?
2026-02-19 15:54:14 <durrendal> https://github.com/astral-sh/uv/blob/main/crates/uv-build/pyproject.toml <- it's buried in the repo a bit, but it's a completely separate thing
2026-02-19 15:54:35 <ikke> durrendal: ok
2026-02-19 15:55:50 <durrendal> yeah a bit confusing, I initially thought they were more deeply coupled until bayseian-optimizations switched to it. you use them in tandem typically, but they're built separate without dependency on each other
2026-02-19 15:56:41 <durrendal> if it makes more sense for the maintainer of py3-uv to also maintainer py3-uv-build I'm happy to let them take it
2026-02-19 15:56:57 <durrendal> s/also maintainer/also maintain/
2026-02-19 16:29:42 <durrendal> achill: thanks for merging that
2026-02-19 20:19:01 <iodomi[m]1> hi, will !96143 be merged any time soon?
2026-02-20 02:08:38 <aelin> main appears to be inconsistent again, py3-dotenv depends on py3-click which is not in main
2026-02-20 02:23:37 <WhyNotHugo> what hardware are the s390x CI runners?
2026-02-20 02:26:38 <aelin> Should be IBM z15
2026-02-20 02:27:28 <WhyNotHugo> thnx
2026-02-20 02:38:58 <godSend23> hey guys
2026-02-20 02:39:10 <godSend23> why can't i join aspecific chan
2026-02-20 08:12:18 <Saijin_Naib[m]> Anyone have bandwidth to review !96397, !95272, !96672, !97218, !97224, !97229, !96398, !97292
2026-02-20 08:12:54 <Saijin_Naib[m]> Also, I need some help with !96399. Build fails for s390x since fish-dev does not exist, so I want to drop that dep just for s390x
2026-02-20 11:00:14 <Sertonix[m]> Something like: case "$CARCH" in s390x) ;; *) makedepends="$makedepends fish-dev" ;; esac
2026-02-20 12:55:33 <jvoisin> rnalrd: can you please bump https://github.com/ncclient/ncclient to the latest available version?
2026-02-20 13:27:01 <rnalrd> jvoisin: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97781
2026-02-20 13:27:20 <rnalrd> i had to disable tests, some fails. not sure if the package is broken
2026-02-20 13:27:33 <rnalrd> i have no time to investigate
2026-02-20 13:28:37 <jvoisin> <3
2026-02-20 13:29:01 <jvoisin> rnalrd: you can remove the dependency on py3-six, as it's not needed anymore \o/
2026-02-20 13:29:54 <rnalrd> done
2026-02-20 13:33:33 <jvoisin> <3
2026-02-20 19:37:56 <Sertonix[m]> [@_oftc_achill:matrix.org](https://matrix.to/#/@_oftc_achill:matrix.org) Would you mind taking a look at https://github.com/golang/go/issues/75868 ? It seems to me that we could get rid of some special casing if that is fixed
2026-02-21 07:07:10 <craftyguy[m]> FYI the builders are stuck because coreutils failed or something, sorry if this was already known
2026-02-21 08:43:09 <ikke> craftyguy[m]: there is something more going on, need to investigate 
2026-02-21 16:11:56 <craftyguy[m]> oh ok, no worries. I figured y'all probably know about it :)
2026-02-22 03:35:13 <ayakael> I'd like to bump dotnet9 security upgrade for edge !97365
2026-02-22 03:35:39 <ayakael> (backport to last stables releases was merged :) )
2026-02-22 03:45:20 <ayakael> Thank you omni :)
2026-02-22 03:46:37 <ayakael> Y'all do amazing work reviewing all of these MRs.
2026-02-22 03:50:30 <ayakael> One of these days, I'd like I'll get on the MR reviewing work. It's just, these days, the best I can hope for is keeping my [backlog](https://ayakael.net/forge/ayaports/issues) low.
2026-02-22 03:53:15 <ayakael> Also, I backported a fix for npm 11.6.3 that seems pretty important !97806
2026-02-22 03:53:55 <ayakael> How can I ping Jakub for view? I know they tend to be less active these days.
2026-02-22 03:53:59 <ayakael> review*
2026-02-22 07:40:31 <jvvv> !97878
2026-02-22 07:41:56 <jvvv> based on the build log, I think that should address the current build failures
2026-02-22 08:18:07 <jvvv> Does that need a rel bump? I didn't bump it because it wasn't getting built for so may arches, but perhaps it is needed for the builders to to pick up the change?
2026-02-22 08:22:22 <quinq> Hummm, it seems that opencl has a problem on amd64
2026-02-22 08:22:22 <quinq> $ clinfo
2026-02-22 08:22:22 <quinq> Segmentation fault
2026-02-22 08:22:59 <quinq> also, usr/lib/man/man1/clinfo.1.gz
2026-02-22 08:23:00 <quinq> the heck
2026-02-22 08:23:19 <quinq> And it seems that clinfo-icd-loader is just the same as clinfo
2026-02-22 08:52:49 <quinq> Yeah, they should conflict with each-other, but they don't
2026-02-22 10:45:39 <quinq> How can I force-remove a package (that other packages supposedly depend on)?
2026-02-22 11:43:05 <ikke> quinq: if another package depends on it, you generally don't want that, but if you know what you are doing, you can add the dependency as a virtual empty package
2026-02-22 11:44:27 <quinq> It's (I'm pretty sure) a bug with opencl and opencl-icd-loader
2026-02-22 11:44:43 <quinq> It seems they've been maintained in parallel by different people, and they provide the same file(s)
2026-02-22 11:45:31 <quinq> I can't remove either one, because apk tells me some packages depends on both (either)
2026-02-22 11:46:06 <ikke> apk should tell you why the package is kept when you try to remove it
2026-02-22 11:46:14 <quinq> Though the dependency isn't even explicit in the APKBULD(s)
2026-02-22 11:46:26 <quinq> ikke, sure, in an unclear way :D
2026-02-22 11:46:28 <ikke> dependencies can be through sonames, cmd: provides
2026-02-22 11:46:33 <ikke> can you paste it somewhere?
2026-02-22 11:47:04 <quinq> sure
2026-02-22 11:49:53 <quinq> https://paste.nurd.space/TJPtYuaEIoPMgmfhutoz8D_sKN4jNchGPkzq8RN6M-I
2026-02-22 11:51:38 <quinq> (problem is that they both provide libOpenCL.so.1)
2026-02-22 11:57:50 <quinq> (and its target libOpenCL.so.1.0.0)
2026-02-22 11:59:27 <ikke> apk will only allow one package to provide something
2026-02-22 11:59:37 <ikke> if 2 packages have the same provides, they would conflict
2026-02-22 12:00:59 <quinq> Well, apparently it didn't
2026-02-22 12:02:31 <quinq> Ah sorry, you meant the actual "provides" field
2026-02-22 12:02:35 <quinq> Yeah that's my point, they don't :)
2026-02-22 12:03:45 <quinq> Hummm, opencl-icd-loader doesn't, but opencl does
2026-02-22 12:04:01 <quinq> Is that why it's confused about package names?
2026-02-22 12:04:59 <quinq> ok, I think I get it now
2026-02-22 12:05:21 <quinq> It treats provides as if they were actual packages
2026-02-22 12:05:45 <quinq> Instead of saying that they're not installed
2026-02-22 12:10:11 <quinq> Si only opencl package is broken I suppose
2026-02-22 15:26:54 <ikke> So it seems like something in the coreutils gnulib tests is sending a sighup to the process group, causing the entire process group to get killed
2026-02-22 15:27:15 <ikke> When there is a tty present, this does not seem to happen
2026-02-22 15:27:23 <ikke> Trying to find out which test
2026-02-22 15:27:28 <ikke> https://tpaste.us/vonB
2026-02-22 15:29:39 <ikke> You can emulate it with: (setsid abuild check) </dev/null |& cat 
2026-02-22 15:30:48 <ikke> Or even just (setsid abuild check)
2026-02-22 15:40:01 <ikke> If I just execute the gnulib test (make check -j $(nproc) in gnulib-tests directory, it does not happen..
2026-02-22 15:46:48 <ikke> jvvv: as long as the builders are still trying to build that package, no pkgrel bump is necessary
2026-02-22 15:47:35 <ikke> (though, if some arches already completed it, and the change has material impact on the package, a pkgrel bump may still be required)
2026-02-22 15:55:44 <ikke> Ok, it's not the gnulib-tests, it's the coreutils tests themselves
2026-02-22 17:32:13 <ikke> After a lot of testing, it seems that the culprit is tests/timeout/timeout.sh
2026-02-22 17:35:31 <ikke> But not sure how, and it's not deterministic. It only fails if you have a lot of processes 
2026-02-22 17:53:07 <ikke> Ok, there's an interaction between tests/tail/overlay-headers.sh and ests/timeout/timeout.sh
2026-02-22 17:53:17 <ikke> I can reproduce it with only those 2 tests enabled
2026-02-22 17:55:29 <ikke> So reproducer: those to tests, with 2 concurrent tests..
2026-02-22 18:33:11 <jvvv> ikke: sorry the patch from gentoo isn't enough. maybe it is too little to late, but I can keep at from angle of those two tests.
2026-02-22 18:33:23 <ikke> jvvv: I think we need that patch
2026-02-22 18:33:32 <ikke> I've seen that test fail
2026-02-22 18:33:39 <ikke> but it's not the cause of the builders stopping
2026-02-22 18:33:40 <sam_> it's fixing a different problem
2026-02-22 18:33:47 <sam_> the patch you used from us is the /bin/sh one
2026-02-22 18:33:51 <sam_> the other one is unrelated and not one i've seen
2026-02-22 18:33:57 <ikke> I'm just curious how those 2 tests can cause SIGHUP to be propagated
2026-02-22 18:33:58 <sam_> but i think it depends on how the builder is run
2026-02-22 18:34:05 <jvvv> right, understood
2026-02-22 18:34:19 <ikke> sam_: it has to do with whether there is a tty or not
2026-02-22 18:34:28 <ikke> the builders are run as a service, so no tty
2026-02-22 18:34:32 <sam_> ahh
2026-02-22 18:35:05 <ikke> I have an strace, and I see processes receiving SIGHUP, but no smoking gun yet what sends it
2026-02-22 18:35:51 <ikke> That's why (setsid make check -j32) would reproduce it
2026-02-22 18:36:40 <jvvv> I have to be afk for a bit, but will return to it in a little while. Will try to help if I can.
2026-02-22 18:36:48 <ikke> I can try to share the strace
2026-02-22 18:37:46 <ikke> https://dev.alpinelinux.org/~kevin/coreutils-tests.strace
2026-02-22 18:40:50 <jvvv> Got it. I have to do some stuff for a bit, but will be working on it asap.
2026-02-22 18:44:51 <ikke> hmm
2026-02-22 18:44:57 <ikke> I reversed https://github.com/coreutils/coreutils/commit/e1cbe82cc6131b2cb8441b948f75a0eb28bdcc40
2026-02-22 18:45:16 <ikke> And that also seems to fix it
2026-02-22 18:46:40 <quinq> gg
2026-02-22 18:49:32 <ikke> Ok, I'll push that for now
2026-02-22 19:32:14 <ikke> If anyone wants to still help, would be nice if someone wants to report this to coreutils
2026-02-22 19:44:34 <realroot[m]> i have arc theme and now gtk doesn't find gnome so no background
2026-02-22 19:45:02 <realroot[m]> Theme parser error: gtk-dark.css:1:1-66: Failed to import: The resource at “/org/gnome/arc-theme/gtk-main-dark.css” does not exist
2026-02-23 00:13:57 <jvvv> Is anyone working on coreutils upstream report yet?
2026-02-23 02:07:02 <jvvv> ikke: Do you still have a copy of the full coreutils build log that includes the hangup?
2026-02-23 05:45:42 <ikke> jvvv: not at the moment, but you should be able to reproduce it by removing the patch and run it with setsid
2026-02-23 05:46:54 <jvvv> ok, thanks
2026-02-23 08:00:11 <z3ntu> hi, could somebody review/merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97345 please?
2026-02-23 09:28:03 <jvvv> ikke: I am not sure why, but I have not been able to reproduce the hang up with setsid. I even ran it on a relatively fresh VM, but no joy.
2026-02-23 09:28:28 <ikke> How many cores?
2026-02-23 09:28:42 <jvvv> 16
2026-02-23 09:28:47 <jvvv> no 14
2026-02-23 09:29:13 <ikke> Ok, that's probably too few for those tests to interact
2026-02-23 09:29:51 <ikke> What I did was remove all tests except those tests from the all_tests list in the Makefile
2026-02-23 09:30:02 <ikke> Then  -j2  should suffice
2026-02-23 09:30:28 <jvvv> I'll try that
2026-02-23 09:34:41 <jvvv> yep, that triggered it
2026-02-23 11:39:22 <ncopa> hi! thanks for following up coreutils tests
2026-02-23 11:39:53 <ikke> It was quite a peculiar situation
2026-02-23 16:29:30 <andar1an> for draft state mr's, would it be possible to have CI not run by default?
2026-02-23 16:30:24 <andar1an> e.g. for Draft: in title, pipelines must be manually run?
2026-02-23 16:31:46 <achill> what is the motivation for that?
2026-02-23 16:32:16 <andar1an> so not waste compute when pushing iterative commits
2026-02-23 16:32:20 <achill> you can also specify to not run CI with git push by: git push -o ci.skip
2026-02-23 16:32:40 <andar1an> cool, thanks achill
2026-02-23 16:32:44 <andar1an> will try that
2026-02-23 16:32:46 <achill> andar1an: well, most of my draft MRs only make sense so that CI can run
2026-02-23 16:33:14 <andar1an> sorry, I don't understand that meaning
2026-02-23 16:33:42 <andar1an> you only push mr's when it can run in CI? 
2026-02-23 16:33:52 <achill> when i open a Draft MR its often so i can verify my changes by CI
2026-02-23 16:34:08 <achill> draft doesn't necessariy mean that a CI verification is useless
2026-02-23 16:34:31 <achill> the draft-tag mainly represents wheather its in a mergeable state or not
2026-02-23 16:35:11 <andar1an> I am using draft more as a placehoder (dk if that is wrong) in case people search to see if one is in progress or they should start one
2026-02-23 16:36:16 <andar1an> So in my case, many runs are wasted when pushing intermittent commits. Then I squash and move out of draft. DK if this is bad flow, just been what I have been trying
2026-02-23 16:36:49 <andar1an> just been cancelling piplelines, but now gonna use your git push option. That seems like it will correct easily
2026-02-23 16:56:47 <Jarico[m]> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/kdeconnect/APKBUILD
2026-02-23 16:56:47 <Jarico[m]> Why does `60_kdeconnect.nft` get installed to `/usr/share/nftables.avail/60_kdeconnect.nft` and not `/etc/nftables.d/60_kdeconnect.nft`?
2026-02-23 16:57:39 <Jarico[m]> or not get symlinked to the latter target path by the APKBUILD.
2026-02-23 16:59:02 <ikke> Jarico[m]: because packages should not automatically open ports
2026-02-23 17:00:43 <Jarico[m]> ah, I see thank you.
2026-02-23 18:04:54 <Sertonix[m]> Huh, does this fail on other alpine systems as well? curl https://example.com
2026-02-23 18:08:29 <Arnavion> No, it fails sporadically on non-Alpine machine too. Also `</dev/null openssl s_client -connect example.com:443 -showcerts` -> `Verification error: unsuitable certificate purpose`
2026-02-23 22:03:53 <andar1an> Is it possible to use a makedepends masked in testing within an APKBUILD file?
2026-02-23 22:07:15 <pabloyoyoista> Would anybody be happy to have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95846? Seems ready for a bit
2026-02-23 22:09:07 <pabloyoyoista> And potentially https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96129 too?
2026-02-23 22:11:20 <andar1an> well, I can try updating repositories file, but if this is a no-no, please let me know haha
2026-02-23 22:22:29 <andar1an> no-go anyways. Shoulda assumed ro fs
2026-02-23 22:29:20 <Sertonix[m]> APKBUILD files should not be able to specify the wanted repositories. If you are using rootbld you can use the .rootbld-repositories file. Otherwise you can do something like SUDO_APK="abuild-apk -X <repo>"
2026-02-23 22:31:33 <andar1an> Thanks so much. I flick between rootbld and not, but it would be good at this stage to add like SUDO_APK. 
2026-02-23 22:36:20 <andar1an> ugh node and java are not my friends lol. I am not sure how to deal with this: babashka@testing is not a valid package dependency, format is name([<>~=]version)
2026-02-23 22:36:51 <andar1an> I have tried including in make depends with and without masking, varing repositories (my system has testing), and tried installing through prepare()
2026-02-23 22:36:58 <Sertonix[m]> By simply not specifying @testing in the APKBUILD
2026-02-23 22:37:11 <andar1an> when I do that it says it is masked
2026-02-23 22:37:23 <andar1an> ERROR: unable to select packages:   babashka-1.3.188-r0:     masked in: @testing     satisfies: .makedepends-penpot-20260223.223522[babashka]
2026-02-23 22:37:41 <pj> you have to remove mask from apk repositories
2026-02-23 22:38:07 <Sertonix[m]> Or overwrite SUDO_APK
2026-02-23 22:38:50 <andar1an> is it possible to reference a specific repositories file with abuild? 
2026-02-23 22:39:11 <andar1an> if not will try adding SUDO_APK to direnv
2026-02-23 22:39:23 <andar1an> will ci in aports have testing?
2026-02-23 22:39:41 <Sertonix[m]> SUDO_APK="abuild-apk --repositories-file /path" ?
2026-02-23 22:39:58 <andar1an> sweet! thank you
2026-02-23 22:40:06 <andar1an> will give that a shot
2026-02-23 22:57:59 <andar1an> why I haven't looked at bootstrap.sh before? I dk, thank you so much for pointing to SUDO_APK
2026-02-23 23:15:31 <andar1an> SUDO_APK change is supposed to work without chroot right?
2026-02-23 23:17:06 <andar1an> sorry i mean rootbld
2026-02-23 23:17:19 <andar1an> im not chrooting myself
2026-02-23 23:30:29 <andar1an> Couldn't figure out, but pj's suggestion works outside of rootbld. TY both! Is there any environment variables related to repositories? I can't find any, but that would be nice for something like direnv
2026-02-24 00:32:39 <jvvv> andar1an: abuild manual page has that information
2026-02-24 10:52:16 <dne> ncopa: now you can close #17990 ;)
2026-02-24 10:52:40 <ncopa> thanks!
2026-02-24 10:54:00 <dne> np
2026-02-24 16:30:06 <andar1an> few quick questions if possible please. When bumping into corepack for node, it is alpine practice to no use corepack right? 
2026-02-24 16:30:47 <andar1an> what is best practice when one bumps into emscripten sdk? Assuming to change to not use emscripten? I don't think anything is related to emsdk in aports
2026-02-24 16:34:12 <jvvv> ikke: already got a reply and a posted fix for the coreutils problem: https://lists.gnu.org/archive/html/bug-coreutils/2026-02/msg00041.html
2026-02-24 16:36:03 <jvvv> thank you for helping me to create a bug report that is so well received
2026-02-24 16:36:46 <ikke> jvvv: you're welcome, team effort :-)
2026-02-24 16:41:21 <jvvv> \o/
2026-02-24 16:41:38 <dne> nice!
2026-02-24 16:46:31 <andar1an> 🎊
2026-02-24 17:20:25 <jvvv> ikke: after replacing the work-around patch with the upstream patch, I cannot reproduce the hangup in coreutils, even when run with setsid and -j2
2026-02-24 17:23:53 <jvvv> Would you like me to prepare an MR with the upstream patch? With as much trouble as the issue caused on the builders, I'm feeling hesitant about running the gamut with it.
2026-02-24 20:44:48 <ikke> jvvv: We have to test it somehow
2026-02-24 20:45:13 <ikke> If you cannot reproduce it anymore, it's sufficient for me
2026-02-24 20:45:21 <ikke> And if it still causes issues, we can revert it
2026-02-24 22:21:43 <jvvv> Good points. !97976
2026-02-24 23:17:26 <xordspar0> There's a breaking change coming up this year in podman. In the version of podman that Alpine 3.23 ships with, 5.7, there's a warning that the existing database format, BoltDB, will be removed in 6.0, due for release in May 2026. However, there's no tool to automatically upgrade to the new SQLite format.
2026-02-24 23:19:00 <xordspar0> Recently, podman 5.8 shipped with a migration tool. However, if 6.0 ships in May, we may skip over 5.8 in Alpine 3.24. If that happens, Alpine users will never have a chance to upgrade before support for the old database format is removed. https://github.com/containers/podman/issues/27628#issuecomment-3951311346
2026-02-24 23:20:41 <xordspar0> Maybe the May release date for podman 6.0 is too late to make it into Alpine 3.24. In that case there would be no problem. I just want to make sure this is on the podman maintainers' radar.
2026-02-24 23:29:34 <xordspar0> I filed an issue to keep track of this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17991
2026-02-24 23:29:38 <craftyguy[m]> filing an issue in aports is probably a better way to make sure it's not missed (instead of a message in chat). also I wonder if it's worth upgrading podman in 3.23 to 5.8 to get the tool?
2026-02-24 23:29:45 <craftyguy[m]> nice :D
2026-02-24 23:31:33 <xordspar0> Yeah, as I see it there are at least 2 options: wait and hope that Alpine 3.24 ships with podman 5.8, or backport 5.8 to 3.23 so that users can deal with the issue ahead of time. Though I'm not sure what other implications there are of upgrading from podman 5.7 to 5.8 mid-release.
2026-02-25 08:53:23 <qaqland> omni: scenefx-dev doesn't depend on scenefx, is this the expected behavior?
2026-02-25 08:56:58 <eu> i'm looking into modernizing a init script to be able to use netns etc. there is some upgrade/compat handling for an old confd variable (TD_OPTS in transmission-daemon.initd for 2.4.0 -> 2.5.0 upgrades). should i just drop it or keep it?
2026-02-25 09:03:08 <ikke> qaqland: Normally abuild takes care of that, but the project only provides an unversioned .so file.
2026-02-25 09:09:44 <qaqland> ikke: thanks, got it.
2026-02-25 11:11:43 <ncopa> I wonder if we should aim for python 3.13 for alpine 3.24 or if we should skip python 3.13 and go directly to python 3.14?
2026-02-25 11:12:03 <ncopa> I'm thinking that maybe 3.13 would be better?
2026-02-25 11:12:22 <ncopa> but python 3.14 may save us for some work...
2026-02-25 11:12:44 <achill> a lot of projects have already support for 3.14
2026-02-25 11:12:56 <achill> major distros already switched to it
2026-02-25 11:13:05 <achill> i think currently it makes more sense to stick to 3.14
2026-02-25 11:13:20 <achill> the projects supporting 3.13 and not 3.14 will be fewer and fewer
2026-02-25 11:13:42 <achill> but i'm not sure how realistic a python upgrade is anymore for 3.24...
2026-02-25 11:14:10 <achill> i wish i had more time to actually work on it, but i have exams coming up and cant really help
2026-02-25 11:16:14 <achill> also llvm 22 got released, i wanted to work on
2026-02-25 11:16:32 <ncopa> I was thinking of start working on python upgrade
2026-02-25 11:16:53 <ncopa> I think if I start with it now we may get it ready for 3.24
2026-02-25 11:17:25 <ncopa> sounds good that you focus on llvm22
2026-02-25 11:18:13 <ncopa> the only thing is that it may be good to have an alpine release with 3.13. If we skip that we will not have any python 3.13 at all
2026-02-25 11:18:36 <achill> also cc WhyNotHugo <https://matrix.to/#/%40oftc_WhyNotHugo%3Apostmarketos.org> since you already worked a bit on the python upgrade
2026-02-25 11:19:07 <achill> ncopa: hmm, but that something people rely on?
2026-02-25 11:19:48 <achill> i personally feel like there is a greater benefit in having a newer python version than having every python version in a alpine release, but i of course dont have any evidence for that
2026-02-25 11:21:16 <ncopa> yeah
2026-02-25 11:21:38 <ncopa> I created a poll: https://fosstodon.org/@ncopa/116131001658774996
2026-02-25 12:15:00 <WhyNotHugo> ncopa: re python3.13, maybe addressing !85770 is a better fit?
2026-02-25 12:16:31 <WhyNotHugo> fwiw, python 3.13 only has 7 months of support left (after that it's only security support)
2026-02-25 15:21:50 <lotheac> ncopa: i don't see any point in going for 3.13. why would that even be on the table?
2026-02-25 15:25:18 <lotheac> alpine is not obligated to ship every release of every language
2026-02-25 15:25:54 <ncopa> im thinking: Q: I need python 3.12! - A: Use alpine:3.23.
2026-02-25 15:26:04 <ncopa> Q: I need python 3.13! ....
2026-02-25 15:26:12 <ncopa> A: use debian or something else
2026-02-25 15:26:34 <ncopa> yes we are not obligated
2026-02-25 15:26:53 <lotheac> i think the A: is pretty much "use docker.io/library/python:3.13-alpine" usually
2026-02-25 15:27:02 <ncopa> right... good point
2026-02-25 15:27:05 <ncopa> very good point
2026-02-25 15:27:42 <ncopa> next question, does it even make sense to support multi version python?
2026-02-25 15:27:54 <ncopa> eg https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85770
2026-02-25 15:27:59 <lotheac> in the same vein my answer is: no
2026-02-25 15:28:42 <ncopa> I am currently working on python3 to be an empty metapackage which only depends=python3.12
2026-02-25 15:28:45 <lotheac> but i imagine this is divisive
2026-02-25 15:29:51 <ncopa> I think being able to install python3.12 and python3.14 in parallel makes it easier for upgrading python versions
2026-02-25 15:30:23 <ncopa> it would allow us to have python3.14 installable while python3.12 is the default and supported python
2026-02-25 15:30:47 <ncopa> which makes it easier to fix packages that fails to build against python 3.14
2026-02-25 15:31:21 <lotheac> the problem is, py3-anything packages would all need to be built for all versions and somehow supported
2026-02-25 15:31:37 <ncopa> that we will not do
2026-02-25 15:32:15 <ncopa> but upgrading to python3.14 requires rebuild of 1000+ packages
2026-02-25 15:32:45 <ncopa> so it maybe be useful to ask people help with parts of it
2026-02-25 15:33:00 <lotheac> ah, so you want to do a gradual upgrade instead
2026-02-25 15:33:06 <ikke> Wonder if risc64 will make it in time..
2026-02-25 15:33:11 <ncopa> sort of
2026-02-25 15:33:33 <ncopa> i think it may if we start now(ish)
2026-02-25 15:33:52 <ncopa> I am still on the fence with multi version python support
2026-02-25 15:34:33 <ncopa> it will slow me down initially (to have it in place) but it may help speed up fixing build failures, as it will makes it much easier for more people to help with those
2026-02-25 15:34:38 <lotheac> gradual upgrades are a double-edged sword. i think they work if someone is paid to make progress on them, but i don't think they work in volunteer projects
2026-02-25 15:35:21 <ncopa> the other option is that i bump python3 to python 3.14 locally, and rebuild all the 1000+ packages and then push
2026-02-25 15:35:29 <ncopa> like I have done in the past
2026-02-25 15:35:33 <lotheac> yeah, i'm okay with that
2026-02-25 15:36:14 <lotheac> seems easier to me than the other option
2026-02-25 15:36:14 <ncopa> problem is that if there are build failures, it is slightly more inconvenient for people to help solve those, as they need to build python 3.14 first themselves
2026-02-25 15:36:22 <ncopa> yeah, its easier
2026-02-25 15:36:25 <ncopa> and simpler
2026-02-25 15:37:24 <ikke> Can we somehow setup a single arch builder that tracks the process?
2026-02-25 15:37:46 <lotheac> i will take "slightly more inconvenient" over perpetual "we're still trying to upgrade foobar X.Y to X.Z" any day
2026-02-25 15:38:25 <ikke> Yeah, like llvm
2026-02-25 15:38:39 <ncopa> I can also copy the temp built packages to dev.a.o something
2026-02-25 15:39:17 <ikke> We have 6 (six!) llvm versions atm..
2026-02-25 15:39:42 <ncopa> yes the donwside with multiversion python is that people *will* ask for py3.$minor-anything sooner or later
2026-02-25 15:39:52 <ncopa> even if we have policy that disallows that
2026-02-25 15:40:07 <ikke> And packages remaining on older versions due to reasons
2026-02-25 15:40:09 <ncopa> and we dont want py3.$minor-anything
2026-02-25 15:40:17 <ncopa> exactly
2026-02-25 15:45:42 <ncopa> alright: I pushed what I had done so far here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/98032
2026-02-25 15:46:20 <ncopa> I will start work on upgrade python3 to 3.14 only
2026-02-25 15:50:47 <lotheac> thanks! i will help on any upgrade issues
2026-02-25 15:51:03 <lotheac> ... i hope. a bit busy recently
2026-02-25 15:57:17 <ncopa> also been busy lately...
2026-02-25 16:06:49 <achill> ikke: as i have said in my RFC MR, the policy will be to only allow packages to depend on the default version. the alternative versions are only for virtualenvs
2026-02-25 16:07:32 <achill> and i'm the one who currently looks after old llvm versions, moves packages over to new ones, removes llvm versions, upgrades llvm. so i know how much pain it is
2026-02-25 16:09:48 <achill> lotheac: the python-images are horribly broken if people mix alpine packages using python and the local/bin python from the image. and people will do that. my first thing i say when people try to do that is dont
2026-02-25 16:11:38 <achill> you cant have packages in alpine depending on different python versions, once we try that, this will break stuff bad. it's not like llvm, where every package is self-contained, they depend on each other with the same python-version
2026-02-25 16:11:57 <achill> so once we introduce alt python installations, the policy should strictly be only-use-default-python
2026-02-25 16:16:08 <lotheac> achill: sorry, i'm not sure what you're recommending. that we should not do multi-version? or that we should do 3.13?
2026-02-25 16:17:35 <lotheac> i tend to err on the side of "one version is supported, if you do something else good luck"
2026-02-25 16:17:43 <achill> to use multi-versions, but still keep the python-package upgrades in another apk repo
2026-02-25 16:18:09 <achill> lotheac: but why? it makes the rebuilds still much much easier and allows collaboration
2026-02-25 16:18:24 <achill> and it'll change nothing for users or developers if they dont want to
2026-02-25 16:18:33 <achill> anyway, gotta continue studying
2026-02-25 16:18:44 <lotheac> does "another apk repo" entail "alpine-3.23-py3.11" and "alpine-3.23-py3.13"?
2026-02-25 16:18:54 <lotheac> if so, then "that's why"
2026-02-25 16:19:35 <achill> the train for 3.23 left half a year ago anyway lol
2026-02-25 16:19:47 <lotheac> because that version string will grow unboundedly when someone upgrades another language
2026-02-25 16:20:34 <lotheac> sorry, 3.23 was an example, not meant to be any particular real version
2026-02-25 16:24:36 <lotheac> achill: i hope i'm misunderstanding; are you advocating for making additional alpine releases (and thus release branches, builders, binaries and mirrors) for two python versions in the space of one alpine release?
2026-02-25 16:27:26 <lotheac> ah, i guess you meant separate apk repo for the different-version-python only?
2026-02-25 16:47:22 <ncopa> i think I will merge fortify-headers-3.0 now
2026-02-25 16:47:27 <ncopa> it may or may not break stuff
2026-02-25 16:47:52 <ncopa> but it is probably better to work out stuff now than wait close to release
2026-02-25 17:04:12 <ncopa> temp repo for python 3.14 work: https://dev.alpinelinux.org/~ncopa/py3.14/
2026-02-25 18:21:50 <ayakael> Hi all, ppdate for zotero 8.0.2 is ready for review, thanks! !97361
2026-02-25 18:24:31 <ayakael> I've also got electron 40 ready, !97817
2026-02-25 18:56:37 <jvvv> While I was waiting for coreutils-9.10-r1 to complete on the builders, I spent some time preparing a reply and thanks for the upstream fix. At that point, I reviewed the list and found that there was an update: https://lists.gnu.org/archive/html/bug-coreutils/2026-02/msg00042.html.
2026-02-25 18:59:04 <ikke> From the description, I guess it mostly affects their internal testing to prevent this from regressing again?
2026-02-25 19:00:35 <jvvv> The way I read it was that the setsid is an extra precaution for signals going up to parents, grandparents.
2026-02-25 19:01:04 <ikke> ah ok
2026-02-25 19:01:34 <jvvv> But since it is fixed for us I think we are probably good as we have thing right now.
2026-02-25 19:02:09 <jvvv> But I wanted to bounce that thought off someone else.
2026-02-25 19:02:33 <ikke> Yeah, I think we don't need to update the patch now, we can just wait for that to land in the next release
2026-02-25 19:03:14 <jvvv> OK, thanks! I just wanted to be sure before I send out the reply to the upstream list.
2026-02-25 19:03:17 <ikke> Like you said, it passed the builders now
2026-02-25 19:03:25 <jvvv> Yep.
2026-02-25 19:18:58 <Sertonix[m]> ncopa: This would only work if py3-* packages would be installable in parallel as well which would be a huge change. Otherwise imports will still fail if rdepends were not rebuild yet.
2026-02-25 19:22:44 <Sertonix[m]> Changing how build packages are commited to the binary repos would in my opinion be the only feasable way. But I still have to figure out how one could do that reliably.
2026-02-26 08:19:05 <ncopa> morning! I merged fortify-headers
2026-02-26 08:19:19 <ncopa> fortify-headers 3.0.1
2026-02-26 08:23:54 <achill> lets see what brakes
2026-02-26 10:13:20 <achill> umm loocks like the builder fail without a package
2026-02-26 10:23:00 <ikke> Syntax error in a package in community
2026-02-26 10:24:33 <achill> aha
2026-02-26 13:03:45 <achill> first fortify-headers issue: https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/transmission/transmission-4.1.1-r0.log
2026-02-26 13:12:38 <achill> and also: https://gitlab.alpinelinux.org/alpine/aports/-/issues/18000
2026-02-26 13:16:46 <jvoisin> > /usr/include/fortify/stdio.h:42:26: error: static declaration of 'fgets' follows non-static declaration
2026-02-26 13:16:48 <jvoisin> wat
2026-02-26 13:17:22 <jvoisin> conflict between the regular headers and fortify
2026-02-26 14:27:05 <qaqland> !97998 looks like it was written by LLM
2026-02-26 15:54:03 <MouriNaruto> Hi, I hope Alpine Linux's linux-virt package can set CONFIG_UIO_HV_GENERIC=m because it can enable us to use Hyper-V VMBus to do something.
2026-02-26 15:54:05 <MouriNaruto> I have made the Hyper-V Enhanced Session support over VMBus, which is out-of-the-box a.k.a. no need for setting PowerShell to use Hyper-V Socket transport. It's actually a VMBus to TCP proxy based on uio_hv_generic kernel module, which can make localhost's RDP server like xrdp can talk with Hyper-V Enhanced Session's VMBus pipe. Here is my source code: https://github.com/SherryPlatform/RelayLab/blob/main/RelayLab.Tools/RelayLab.Tools/main.cpp
2026-02-26 15:54:06 <MouriNaruto> Also, it should also be helpful for Alpine Linux to use Microsoft's hv_fcopy_uio_daemon which at https://github.com/torvalds/linux/blob/master/tools/hv/hv_fcopy_uio_daemon.c
2026-02-26 15:57:19 <MouriNaruto> Here is my implementation's demo video: https://x.com/MouriNaruto/status/1999733146250813756
2026-02-26 16:29:37 <ikke> Gitlab will be restarted at 17:00 UTC to apply security updates and will be briefly unavailable.
2026-02-26 17:08:00 <ikke> gitlab is back
2026-02-26 19:05:19 <Ariadne> qaqland: i think we need to pull in the pmOS AI policy into alpine proper to discourage this
2026-02-26 19:15:04 <fabricionaweb> that is super ironic qaqland haha
2026-02-26 19:42:25 <PureTryOut> 100% that's generated by AI 😅 They're repeating a ton of info that we can already just read in the APKBUILD, without actually explaining why it is like it is
2026-02-26 19:46:21 <achill> Ariadne: yup see https://gitlab.alpinelinux.org/alpine/council/-/issues/697
2026-02-26 19:55:41 <ikke> Just the headers are already a dead give-away
2026-02-26 20:42:42 <f_> Ariadne: you're coming just at the right time, that policy was made more strict just a few days ago :P
2026-02-26 21:10:44 <Sertonix[m]> Can !98101 be merged soon to unblock the builders?
2026-02-26 22:02:48 <Saijin_Naib[m]> I know I ask for help a lot, but I am rather stuck again with the pyc subpackge routine for two MRs I'm working on; !96399 and !97292
2026-02-26 22:03:23 <Saijin_Naib[m]> If I just put $pkgname-pyc in the subpackages line, they both fail as the pyc function doesn't pick up/include the pyc files properly for whatever reason
2026-02-26 22:03:36 <Saijin_Naib[m]> If I instead use this function I found in another APKBUILD, they work, but the linter is mad
2026-02-26 22:03:59 <Saijin_Naib[m]> https://bpa.st/LACA
2026-02-26 22:04:51 <Saijin_Naib[m]> I'm not understanding why the default one fails. But (with the full force of my ignorance), I feel like since this has happened a few times to me already, maybe the default pyc function should be modified to be more robust and pick up situations like this automatically
2026-02-26 22:07:58 <Saijin_Naib[m]> I think "this" is the pyc files being nested a few directories too deep vs what the default function looks for?
2026-02-26 22:20:44 <Saijin_Naib[m]> glances segfaults without py3-jinja2 installed. Proper way is to make an Issue and wait for the maintainer, right? But it is also a simple fix, so would opening an MR with the new depends be okay as well, so they can review it?
2026-02-27 07:15:34 <quinq> Hi
2026-02-27 07:15:48 <quinq> It seems that crystal (lang) has an issue
2026-02-27 07:15:55 <quinq> Upgrading crystal (1.18.2-r0 -> 1.19.1-r0)
2026-02-27 07:15:55 <quinq> ERROR: crystal-1.19.1-r0: failed to commit usr/lib/crystal/core/lib_c/aarch64-android: Is a directory
2026-02-27 07:38:18 <Saijin_Naib[m]> Thanks for the help, Sertonix!
2026-02-27 07:38:40 <ncopa> is anyone available to help me fix cython build against python 3.14?
2026-02-27 08:03:06 <jvvv> ncopa: I am
2026-02-27 09:14:48 <ncopa> jvvv: I have some built packages here so you dont need to build from scratch: https://dev.alpinelinux.org/~ncopa/py3.14/
2026-02-27 10:20:14 <fabricionaweb> I noticed one opened PR that is doing npm install -g in the package() step... looking into the aports repo, I see there is some others (not much) I dont know if is good to have that npm install there, it seems like it would skip abuild, at that point of the package
2026-02-27 10:52:01 <ikke> fabricionaweb: that would fail if --prefix is not provided as welll
2026-02-27 10:52:31 <ikke> All of the existing aports provide that
2026-02-27 10:52:46 <fabricionaweb> ah, the prefix is there yeah
2026-02-27 10:53:24 <ikke> Apparently I'm the maintainer of 2 of those packages
2026-02-27 10:53:33 <jvvv> ncopa: sorry, I stepped away. I have vm setup now with the pubkey and added your py3.14/main to the apk/repositories file
2026-02-27 10:53:37 <fabricionaweb> ok I wouldnt say more hahahah
2026-02-27 10:54:03 <ikke> fabricionaweb: no worry, if things can be improved, I'm happy to hear
2026-02-27 11:04:08 <jvvv> ncopa: what version of cython are you working with? I currently have cython-3.2.4 building against python3.14 from you repo
2026-02-27 11:04:44 <jvvv> *your
2026-02-27 11:13:19 <jvvv> should I be building from the 3.1.x branch?
2026-02-27 11:55:15 <ncopa> does cython 3.2.4 build with the current python 3.12? maybe we could upgrade cython then
2026-02-27 12:08:38 <jvvv> I'm trying abuild with py3.12 now. I should have thought to try that first.
2026-02-27 12:11:43 <jvvv> *a build
2026-02-27 12:32:55 <ncopa> it deadlocks for me in the tests
2026-02-27 12:33:00 <ncopa> with python 3.14
2026-02-27 12:49:45 <jvvv> I am trying a patch I that arch is using. They cherry picked commit d344f9b284549362dee39af7a74a9c669bb65ce8 from cython master branch. Might be unrelated but I'm trying it anyways.
2026-02-27 13:03:03 <jvvv> hanging for me also
2026-02-27 13:04:11 <ncopa> i suppose we need to identify which test it is that hangs and fix it, or maybe disable it
2026-02-27 13:04:18 <ncopa> not sure how to do that though
2026-02-27 13:04:24 <fabricionaweb> is gitlab 🛌
2026-02-27 13:06:06 <jvvv> looking to see if can disable all but one test, the enable one at a time maybe
2026-02-27 13:06:27 <ncopa> im running tests now with -j1 -v
2026-02-27 13:11:42 <ncopa> hum. needs -vv
2026-02-27 13:24:33 <jvvv> Was just looking at test-requirements.txt in the build directory. It lists numpy, coverage, pycodestyle, setuptools. Only coverage is in main.
2026-02-27 13:26:04 <ncopa> Doctest: cpp_condition_variables.test_cv_wait_for ... ok
2026-02-27 13:26:04 <ncopa> #### 2026-02-27 14:16:20.233310
2026-02-27 13:26:04 <ncopa> test_py_safe_wait_basic (cpp_condition_variables)
2026-02-27 13:26:04 <ncopa> Doctest: cpp_condition_variables.test_py_safe_wait_basic ... 
2026-02-27 13:26:18 <ncopa> looks like it is Doctest: cpp_condition_variables.test_py_safe_wait_basic that deadlocks
2026-02-27 13:26:33 <ncopa> I believe it deadlocks with python 3.12 as well
2026-02-27 13:27:04 <jvvv> Ok, I'm looking at how to mask it.
2026-02-27 13:27:54 <ncopa> woudl be nice to find out why if deadlocks and maybe try fix it
2026-02-27 13:57:22 <jvvv> agreed
2026-02-27 14:39:07 <andar1an> is alpine gitlab down? or just me?
2026-02-27 14:39:50 <fabricionaweb> it is dns
2026-02-27 14:39:51 <ikke> It's under load. I only have time to look at it later :(
2026-02-27 14:40:31 <andar1an> No urgency here, just wanted to make sure wasn't my end.
2026-02-27 14:41:19 <andar1an> is it an attack? or just settings?
2026-02-27 14:44:31 <andar1an> I have been wondering a lot about low layer network authentication recently, and how one may use keys at low layers so it is easier to firewall. Port Knocking seems pretty neat, but dk if that is applicable to ssh connections, but maybe it is possible to require a knock sequence for ssh connections 
2026-02-27 14:46:18 <andar1an> maybe users could have a unique and specific unique knock sequence. I dk. I think the moment keys come in you are at minimum layer 3
2026-02-27 14:53:17 <ikke> andar1an: I'd say abuse rather than attatck
2026-02-27 14:55:13 <andar1an> a darn. I hope I am not contributing to abuse haha, I just refreshed like a billion times lol. I am curious if there is such a thing as data link layer port knocking now though haha. Bigger switch = bigger security 😹
2026-02-27 14:58:43 <ikke> I believe they are trying to scrape gitlab by cloning many repos
2026-02-27 14:58:50 <andar1an> ugh :(
2026-02-27 14:58:51 <ikke> Most of the times, many aports forks
2026-02-27 15:03:21 <andar1an> Gotta reset to test something. Hope this doesn't affect your friday too badly. Happy weekend (good one to catch some lion dances!) 
2026-02-27 15:05:19 <ikke> Restarting gitlab did let it settle down for now it seems
2026-02-27 15:05:53 <Biswa96[m]> yup, it's working now \o/
2026-02-27 15:12:54 <andar1an> gosh darn it. I got my dates wrong. That's all I wanted to do this weekend lol
2026-02-27 15:29:13 <jvvv> ncopa: cython-3.2.4/tests/run/cpp_condition_variables_cpp20.pyx:28
2026-02-27 15:50:41 <craftyguy[m]> ikke: do you mind if I DM you about setting up OIDC auth between pmOS and Alpine gitlab instances?
2026-02-27 15:51:05 <ikke> craftyguy[m]: sure
2026-02-27 16:29:22 <Saijin_Naib[m]> Should gst-plugins-rs have an gst-plugins-rs-all that pulls in everything, or is it meant to be one by one when you add gst-plugins-rs
2026-02-28 09:46:37 <lindsay> fuse3-libs requires `fusermount3` to work, which is included in the fuse3 aport: https://github.com/libfuse/libfuse/blob/fuse-3.18.1/lib/mount.c#L581 .
2026-02-28 09:46:37 <lindsay> This leads some aports, such as sshfs and flatpak, to explicitly mark fuse3 as a dependency. I believe fuse3-libs should not be split out.
2026-02-28 09:46:37 <lindsay> If there are no objections, I'll submit a MR later today.
2026-02-28 09:46:37 <lindsay> See also this blog: https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/ .
2026-02-28 09:59:28 <lindsay> Or would it be more appropriate to move `fusermount3` into fuse3-libs? The fuse3 aport would only contain a single file `mount.fuse3`.
2026-02-28 10:05:26 <jvvv> sounds like wagging the dog
2026-02-28 11:14:39 <Sertonix[m]> The problem is that fuse3-libs is not always used and fusermount3 elevates privilidges. So I think it's a bit safer to have it split.
2026-02-28 12:41:33 <Wkaleign[m]> Get in touch with this platform for greatness you’ll definitely thank me later
ℹ️❤️
👇🏻👇🏻👇🏻
2026-02-28 12:41:34 <Wkaleign[m]> https://t.me/+pa-CiKYv9-5lNWM8
2026-02-28 12:42:27 <Wkaleign[m]> https://t.me/+pa-CiKYv9-5lNWM8
2026-02-28 12:42:27 <Wkaleign[m]> Get in touch with this platform for greatness you’ll definitely thank me later
ℹ️❤️
👇🏻👇🏻👇🏻
2026-02-28 17:00:39 <jvvv> ncopa: sorry it took so long, but here is what I came up with for cython: https://tpaste.us/JNX0
2026-02-28 17:04:08 <jvvv> works for both python 3.12 and 3.14
2026-02-28 17:21:13 <andar1an> is it possible with abuild-meson to allow automatic wrap based project downloading?
2026-02-28 17:22:09 <andar1an> the previous version of this package exists, so I don't know why it worked then, but not now for me. Is there something I need to do on my end? this is trying to work on an abump
2026-02-28 17:27:27 <andar1an> e.g. can I change this line maybe? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/meson/abuild-meson#L62
2026-02-28 17:30:39 <andar1an> I have tried explicitly passing --wrap-mode=default, and enabling net in options. But no bueno
2026-02-28 17:31:12 <andar1an> ah nvm new error
2026-02-28 17:31:18 <andar1an> maybe i need to at git dep
2026-02-28 17:32:09 <andar1an> sweet, sorry you can ignore this
2026-02-28 17:35:18 <andar1an> is gitlab still having a few issues (e.g. can merge requests be started right now)?
2026-02-28 17:35:59 <andar1an> nvm, just took a while