2025-06-01 00:38:46 <lotheac> xe: semi-sure that you just run abuild and you magically get a repo under ~/packages/ which you could just put behind http
2025-06-01 00:45:08 <xe> lotheac: let's say that i have a strange workflow that involves nfpm, a program that builds apk packages without the abuild tooling
2025-06-01 00:50:45 <lotheac> that sounds like a different question then :D
2025-06-01 01:50:00 <Arnavion> As long as it also generates an APKINDEX.tar.gz with all the packages it generated, then that in a directory with all the .apk's can be used as a repository
2025-06-01 02:12:47 <xe> is APKINDEX.tar.gz's format documented?
2025-06-01 02:33:13 <roselandgoose> as much as I might make stupid comments about rust evangalists, I do want rust packages on Alpine to succeed. might the CARGO_PROFILE_RELEASE_LTO env variable be something worth mentioning in the wiki re: APKBUILDs ?
2025-06-01 03:36:12 <Arnavion> xe:   https://wiki.alpinelinux.org/wiki/Apk_spec
2025-06-01 03:36:42 <xe> thanks Arnavion <3
2025-06-01 03:37:18 <Arnavion> That page says the tarball contains two files. For my custom packages built using pmos's pmbootstrap it additionally contains the (public) signing key. I can't check regular aports index atm
2025-06-01 03:51:24 <jvvv> !79766 is stale (3 months old) and has not had any comment. should i close it?
2025-06-01 03:53:43 <jvvv> at this point, i'm pretty sure i would have to rebase it just make it mergable again
2025-06-01 04:38:24 <jvvv> never mind, closed
2025-06-01 10:57:59 <f_> jvvv: you didn't have to close it
2025-06-01 10:58:42 <f_> When it is stale like this it's usually because the relevant people are busy and did not have time to review
2025-06-01 13:28:19 <orbea> f_: it helps to keep a consistent schedule to review stuff promptly, stay on top of stuff instead of letting contributions stagnant and go to waste
2025-06-01 13:45:35 <ikke> No one gets payed to review merge requests. Live happens, motivation varies, sometimes technical challenges happen.
2025-06-01 13:45:49 <ikke> We receive 40-60 MRs per day
2025-06-01 14:02:44 <Kladky> Yeah, more people really need to be considered for the developer role
2025-06-01 14:04:54 <ikke> We are
2025-06-01 14:08:46 <Kladky> Nice
2025-06-01 14:11:25 <omni> also, maintainers need to approve MRs
2025-06-01 14:12:10 <omni> I think most of the ones open await approval or need to be sorted before they can go in
2025-06-01 14:25:11 <ikke> yup
2025-06-01 14:26:20 <omni> I sometimes, when I have time and energy, try to go through them all, back from the oldest
2025-06-01 14:26:39 <omni> but still, some are missed, when they are so many
2025-06-01 14:27:28 <omni> and I'm guilty myself, I have few broken ones open myself that I should take time to look into
2025-06-01 14:29:30 <Kladky> Hahah yeah, lemme try fix one of mine actually
2025-06-01 14:31:45 <orbea> omni: it could help if you set aside a certain time per week to do a bunch and then made it a habit, and if several devs did similar than the backlog would probably decrease over time, i do realize its hard work and a volunteer position, but it also sucks being on the other side where you spend bunch of effort to do something and then it just bitrots for months or longer
2025-06-01 14:32:49 <orbea> i went to fix a bug reported for the gentoo tracker the other day, fixed it and went to submit it upstream to find I already fixed it and submitted upstream a little over a year ago, no response from upstream...
2025-06-01 14:34:07 <Kladky> I think just spreading the load between more people is a more sustainable strategy, which is being worked on, which is good
2025-06-01 14:34:15 <omni> oh god, don't be my manager, this is one of my hobbies
2025-06-01 14:36:27 <Kladky> Btw, for stuff like qt, where there are multiple packages that need to have the same version, i wonder if it would be a good idea for them all to be able to get the version all from a single file
2025-06-01 14:36:58 <Kladky> Or just something that would make upgrading it less tedious
2025-06-01 14:37:46 <ikke> Kladky: you would have to update the checksum for each package anyway, so it's not that you can skip touching each APKBUILD anyway
2025-06-01 14:38:29 <Kladky> And I guess having all those packages in a single APKBUILD file would be a big no-no?
2025-06-01 14:39:42 <ikke> If they don't come from the same source, it would complicate everything a lot
2025-06-01 14:41:17 <ikke> PureTryOut uses a custom comment to group packages together and has some automation around that to update all of them together
2025-06-01 14:43:18 <ikke> puretry
2025-06-01 15:15:29 <Kladky> Interesting, ig that's better than using an editor macro
2025-06-01 15:23:52 <PureTryOut> I'd love more official grouping so people can also do `apk add <some group>`, but yeah I have some custom scripts to automatic checksum generation and mass version bumping
2025-06-01 16:01:09 <sertonix[m]> PureTryOut: I think if we tweak the way install_if works for removed packages it could be safely used for grouping. What do you think?
2025-06-01 16:37:08 <PureTryOut> I'm not sure how that would work?
2025-06-01 17:11:00 <sertonix[m]> We could create an empty dummy package (eg. plasma-idk) and then packages which should be in the group specify install_if="plasma-idk". One issues that needs to be fixed are that install_if might keep packages installed after they were removed from the repos (should be a minor tweak to the solver). In some cases it might become a problem that install_if is always 'and' and never 'or'.
2025-06-01 17:15:53 <sertonix[m]> This would also allow to have testing packages in a group that are only installed when the testing repository is enabled (When using tags this can be configured on a per-group basis)
2025-06-01 20:41:32 <pabloyoyoista|m> ikke: regarding your work on increasing the number of alpine devs. I was thinking for a while, if an "alpine TC program" would be helpful for you
2025-06-01 20:42:58 <pabloyoyoista|m> If yes, do you have something specific in mind or that you would like to do different to pmOS? I could otherwise send a proposal to the TSC?
2025-06-01 20:43:24 <ikke> I'm not familiar with the details of the pmos TC program
2025-06-01 20:45:07 <pabloyoyoista|m> The basic idea is: people nominate themselves, so the burden to find new contributors is not on the team. They send a list of things they've done, and need 2 people from the team to recommend them, so that there is already some trust with that person
2025-06-01 20:45:47 <pabloyoyoista|m> There is a 1-week voting period, and some team members have veto rights, to avoid risk of big culture shift
2025-06-01 20:46:41 <pabloyoyoista|m> If the vote is positive, they get rights :)
2025-06-01 20:48:41 <pabloyoyoista|m> Compared to what alpine has now I think it would release the pressure to find members from your shoulders, and avoid requiring a TSC meeting to approve people, so things can move faster. But maybe wouldn't fit what you wanted?
2025-06-01 20:50:00 <invoked> no blood oath?
2025-06-01 21:03:56 <ikke> pabloyoyoista|m: it's something the tsc would have to decide, but from past discussions it seems we try to be a bit carefull and at least require something to be part of the community for some time for example
2025-06-01 21:04:30 <pabloyoyoista|m> Right, that's when the recommendations come in place :)
2025-06-01 21:05:22 <pabloyoyoista|m> > 
2025-06-01 21:05:22 <pabloyoyoista|m> Right. My idea is that if I bring a proposal, then the TSC "just" has to make a decision. But it does not have to craft a proposal, which is considerable more work
2025-06-01 21:05:22 <pabloyoyoista|m> it's something the tsc would have to decide
2025-06-01 21:06:09 <pabloyoyoista|m> Of course, if you think it makes sense, or that's something that would help
2025-06-01 21:19:14 <ikke> I'm not sure myself. We do get recommendations already for people to become developers. The current bottleneck is mostly lack of TSC meetings (in fact, I just started to arrange one)
2025-06-01 21:19:39 <pabloyoyoista|m> So then the only thing needed is an async vote?
2025-06-01 21:20:26 <ikke> Yes, if that's something we want
2025-06-01 21:20:55 <pabloyoyoista|m> Alright, then I'll forget about it for now :)
2025-06-02 04:02:12 <Saijin_Naib[m]> Could !84917 get a review/merge when someone gets a bit of free time?
2025-06-02 07:19:32 <jvvv> there is something hinky going on with the ppc64le runner. it errors out early trying cd to the aports dir. for example: https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/1879846 ... other recent ppc64le runners jobs error similarly.
2025-06-02 07:57:16 <jvvv> i wish i understood why that tests that pass on my laptop in rootbld fail in CI runner of same arch and differently in different retries
2025-06-02 09:20:55 <Kladky> seems that when building qt6-qtwebengine, the x86_64 gets a termination signal: https://gitlab.alpinelinux.org/Matthias/aports/-/jobs/1879247#L5048
2025-06-02 09:21:12 <Kladky> It's strange because it doesn't happen on any other architecture
2025-06-02 09:21:59 <Kladky> And if anything, you'd expect out of all the arches, x86_64 would be the one to function properly
2025-06-02 09:22:48 <quinq> But you're entering the web domain, lose all hope for sanity
2025-06-02 09:25:12 <Kladky> quinq: as I asked you yesterday, please keep comments like that to yourself, they are not helpful
2025-06-02 09:25:38 <Kladky> Or I guess 2 days ago
2025-06-02 09:33:45 <quinq> Kladky, and your request was noted, no need to repeat it :)
2025-06-02 09:39:26 <jvvv> Kladky: starting at line 6044 of the log... i wonder if these errors might have something to do with later compile errors
2025-06-02 09:40:37 <Kladky> Oh, maybe
2025-06-02 09:41:04 <Kladky> Strange those appeared after qtwebview started building
2025-06-02 09:42:04 <Kladky> Maybe I was missing a package.
2025-06-02 09:42:18 <jvvv> could be a build order thing, given how many aports are in that mr
2025-06-02 09:42:39 <Kladky> Since I just upgraded specifically all community/qt6-qt* and nothing else
2025-06-02 09:43:04 <jvvv> oh, that's worth looking into, i bet
2025-06-02 09:43:44 <Kladky> Ill just rg the group=qt6 comments I see now
2025-06-02 09:44:27 <jvvv> rg?
2025-06-02 09:44:45 <jvvv> ripgrep ?
2025-06-02 09:44:50 <Kladky> Yeah
2025-06-02 09:44:52 <jvvv> ah
2025-06-02 09:48:04 <jvvv> Kladky: you are maintainer of tree-sitter aport?
2025-06-02 09:48:17 <Kladky> Yep
2025-06-02 09:49:06 <jvvv> that mr i openned for combining with cli aport should be worth looking at when you have time... no rush
2025-06-02 09:49:20 <Kladky> I already did.
2025-06-02 09:49:23 <jvvv> cool
2025-06-02 09:49:27 <Kladky> @Matthias on gitlab
2025-06-02 09:49:37 <jvvv> i thought maybe
2025-06-02 09:49:40 <f_> jvvv: now that you're connected:
2025-06-02 09:49:41 <f_>  12:57 < f_> jvvv: you didn't have to close it
2025-06-02 09:49:41 <f_>  12:58 < f_> When it is stale like this it's usually because the relevant people are busy and did not have time to review
2025-06-02 09:49:48 <f_> in answer to
2025-06-02 09:49:48 <f_>  05:51 < jvvv> !79766 is stale (3 months old) and has not had any comment. should i close it?
2025-06-02 09:50:14 <jvvv> f_: well, another mr superceded it any way. so i closed it
2025-06-02 09:50:21 <f_> oh, okay
2025-06-02 09:50:40 <jvvv> and that mr had just been committed... no big deal
2025-06-02 09:50:51 <jvvv> thanks for your input though
2025-06-02 09:52:50 <jvvv> my mr for byacc had a change in it that may have been unpalatable... it got rid of it's need to conflict with bison which some might not have liked
2025-06-02 09:53:17 <jvvv> i just maintain a local fork to achieve that now anyway
2025-06-02 09:59:00 <angeloverlain[m]> I wanted to hear if there's any idea on how initramfs hooks would work in alpine. something like automatically unlocking the LUKS device with TPM2 if possible or displaying plymouth
2025-06-02 10:00:23 <jvvv> f_: that's really decent of you to pick that thread a day later... that is the kind of thing that i highly regard
2025-06-02 10:00:54 <jvvv> s/pick/pick up/
2025-06-02 10:01:19 <f_> Well you were disconnected by the time I saw your message and replied, so when I saw you again today I thought it'd make sense to resend my reply for you to see :)
2025-06-02 10:01:43 <f_> and I didn't know if you checked public irc logs
2025-06-02 10:02:11 <jvvv> sometimes i do, but thank you very much just the same
2025-06-02 10:09:55 <jvvv> angeloverlain[m]: i've only ever done kbd passwd for luks unlock so i've no experience with that, but there are some variables that can be passed on the kernel commandline
2025-06-02 10:11:09 <Kladky> Yeah, turns out I did actually upgrade all the qt6 aports, so I'm not sure what that error's on about
2025-06-02 10:13:20 <jvvv> Kladky: what i was pointing out could have just been line noise from the build system, i just noticed it... unfortunately i intentionally avoid qt so i guess i'm not going to be able to help much
2025-06-02 10:13:34 <jvvv> sorry
2025-06-02 10:14:01 <Kladky> Fair enough, but it still was helpful, since I know what the actual error is now, so thanks
2025-06-02 10:15:01 <Kladky> PureTryOut: any idea what this is about: https://gitlab.alpinelinux.org/Matthias/aports/-/jobs/1879247#L6045
2025-06-02 10:18:14 <Kladky> Wait no, that isn't the error
2025-06-02 10:18:42 <Kladky> That is for qtwebview, because qtwebengine failed to build, causing it to pull that older version
2025-06-02 10:19:14 <Kladky> So it really is just that qtwebengine was just killed for seemingly no reason: https://gitlab.alpinelinux.org/Matthias/aports/-/jobs/1879247#L5048
2025-06-02 10:29:10 <jvvv> Kladky: looking again at that error, perhaps ninja sent the kill sig reacting the the errors compiling ../../../../../src/3rdparty/chromium/content/browser/renderer_host/render_widget_host_view_base.cc
2025-06-02 10:29:36 <jvvv> probably i'm just stating the obvious
2025-06-02 10:30:24 <Kladky> Those looks like warnings to me
2025-06-02 10:30:43 <Kladky> Since they contain "warning: "
2025-06-02 10:30:49 <Kladky> but no "error: "
2025-06-02 10:34:28 <jvvv> yeah, i'm looking to see if -Werror is on the command line, but sheesh that is a loooonggg line of lines to try to decipher
2025-06-02 10:37:38 <jvvv> to note, the compile is probably multithreaded, so those warns maybe unrelated
2025-06-02 10:39:28 <jvvv> i wonder if there is any chance of getting the ppc64le CI runner looked at... it definitely is not working correctly
2025-06-02 10:41:54 <ikke> I am
2025-06-02 10:43:15 <ikke> ok, somethine like: have you tried to turn it off and on again
2025-06-02 10:43:30 <ikke> hmm, nope
2025-06-02 10:46:16 <jvvv> it's weird how it seems to be skipping the mkdir for the aports dir before cd to it... like maybe a script got corrupted or truncated
2025-06-02 10:47:05 <ikke> Check the line what it's doing before that
2025-06-02 10:48:13 <ikke> ldd /usr/bin/git
2025-06-02 10:48:15 <ikke> /lib/ld-musl-powerpc64le.so.1: /usr/bin/git: Not a valid dynamic program
2025-06-02 10:49:09 <ikke> git in the docker image seems to be corrupt
2025-06-02 10:49:36 <jvvv> damn, that's gotta make you wonder how that happened
2025-06-02 10:49:48 <ikke> yup
2025-06-02 10:50:00 <jvvv> i know, i'm awesome at pointing out the obvious
2025-06-02 10:50:21 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/jobs/1877860
2025-06-02 10:50:29 <quinq> I wonder why it runs ldd on the git binary
2025-06-02 10:50:58 <ikke> quinq: I did
2025-06-02 10:51:52 <quinq> ah :D
2025-06-02 10:52:28 <ikke> interesting, it's 3.3M of 0 bytes
2025-06-02 10:53:48 <quinq> https://dl-cdn.alpinelinux.org/alpine/edge/main/ppc64le/git-2.49.0-r0.apk looks ok
2025-06-02 10:54:16 <ikke> yeah, after apk fix, it's okay
2025-06-02 10:54:26 <ikke> so something must have gone bad when installing while building the image
2025-06-02 10:54:56 <ikke> (I'm rebuilding the image)
2025-06-02 10:55:03 <quinq> :)
2025-06-02 10:55:46 <jvvv> nice, you figured it out faster than i would have... i'd still be chasing down line 146 if you hadn't already pointed it out
2025-06-02 10:57:02 <ikke> My reasoning was that it's the git clone that must create that folder
2025-06-02 10:57:17 <ikke> so if that folder does not exist, something must go wrong while cloning
2025-06-02 10:58:51 <jvvv> that was a good point for beginning query and makes lots of sense to me after the fact
2025-06-02 11:00:39 <ikke> Hmm :/ https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/jobs/1880226
2025-06-02 11:04:08 <quinq> Missing openssl there?
2025-06-02 11:04:22 <ikke> no clue, but I don't have time anymore
2025-06-02 11:04:35 <quinq> Ah, or corrupted libcrypto
2025-06-02 11:05:36 <jvvv> angeloverlain[m]: i suggest reading up on mkinitfs, mkinitfs-bootparam, and nlplug-findfs (all man pages from the mkinitfs-doc pkg
2025-06-02 11:06:55 <jvvv> angeloverlain[m]: the bootparam i believe most pertinent is 'cryptkey'
2025-06-02 11:08:17 <jvvv> angeloverlain[m]: you will also need to configure mkinitfs for luks and anything else pertaining to your setup
2025-06-02 11:08:50 <angeloverlain[m]> jvvv: I did. I want to add a hook that unlocks the device with TPM using clevis 
2025-06-02 11:09:19 <angeloverlain[m]> this probably needs new support for hooks in mkinitfs
2025-06-02 11:10:24 <jvvv> i think the tpm might be doable if you knew in advance the device it would be named as, but as to clevis... never heard of it
2025-06-02 11:11:35 <jvvv> but i've reached the end of my depth, i always just enter the passwd when booting
2025-06-02 11:13:46 <Kladky> I'm just going to assume it was because the builders were overloaded or something, since the same merge request targeting edge was opened and worked fine, but it was significantly faster: !85079
2025-06-02 11:15:24 <Kladky> Considering my armv7 build took almost 1000 minutes...
2025-06-02 11:15:32 <Kladky> before it was terminated
2025-06-02 12:03:56 <jvvv> apk-tools for 3.19 needs rel bump to rebuild against openssl
2025-06-02 13:14:53 <jvvv> quinq: you pointed to it... apk-tools out of sync with openssl. i pushed MRs for 3.19-3.21. should fix the issue once the packages land and the container can be rebuilt successfully
2025-06-02 13:37:45 <f_> hmmm
2025-06-02 13:37:54 <f_> is the ppc64le CI runner having strange issues
2025-06-02 13:37:55 <f_> https://gitlab.alpinelinux.org/funderscore/aports/-/jobs/1880357
2025-06-02 13:38:05 <f_> cd: line 217: can't cd to /builds/funderscore/aports: No such file or directory
2025-06-02 13:38:40 <f_> (I'm trying to package alertmanager-irc-relay)
2025-06-02 13:40:03 <ikke> Yes, was already reported 
2025-06-02 13:40:20 <f_> alrighty
2025-06-02 13:40:29 <ikke> Issue is that git got corrupted in the docker image 
2025-06-02 13:40:39 <f_> Oof :/
2025-06-02 13:47:42 <quinq> jvvv, gg
2025-06-02 14:34:19 <WhyNotHugo> A couple of upgrade to qt6: !85112, !85114
2025-06-02 14:50:52 <roselandgoose> Kladky: glad to see the LTO fix worked! sorry for my stupid comment.
2025-06-02 14:51:21 <Kladky> Thanks :)
2025-06-02 15:37:09 <sertonix[m]> @angeloverlain:matrix.org The default clevis approach is to call cryptsetup itself but mkinitfs expects to just be send the luks key. You could copy and modify some logic from clevis-luks-common-functions to create a cryptkey=EXEC=<script> compatible script.
2025-06-02 15:50:39 <angeloverlain[m]> <sertonix[m]> "@angeloverlain:matrix.org The..." <- ooh I didn’t know cryptkey command supported scripts
2025-06-02 15:50:48 <angeloverlain[m]> any more resources for that ?
2025-06-02 15:54:59 <sertonix[m]> I have written the code so you can ask me. I don't know if there exists and good documentation.
2025-06-02 15:58:36 <quinq> Is there some qr-code decoder (from file) on alpine, besides zbarimg?
2025-06-02 16:06:54 <rhizoome> quinq: I use it for 2FA QR codes,  Inot aware of am 
2025-06-02 16:07:06 <rhizoome> an alternative 
2025-06-02 16:09:47 <quinq> I have some qr-code given by amazon it can't decode apparently
2025-06-02 16:15:43 <rhizoome> quinq: https://pkgs.alpinelinux.org/package/edge/community/x86_64/zxing
2025-06-02 16:15:51 <rhizoome> never tried it
2025-06-02 17:04:52 <quinq> rhizoome, works!
2025-06-02 17:04:55 <quinq> Thanks
2025-06-02 17:20:54 <rhizoome> d
2025-06-02 18:55:01 <jvvv> ikke: when you linked  https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/jobs/1880226, i saw on line 68 failure to load for /sbin/apk. isn't that a library mismatch? i was thinking rebuilding apk-tools should fix the problem. am i wrong in this?
2025-06-02 18:56:00 <ikke> jvvv: Thanks, I did not look deeply into that one yet
2025-06-02 18:57:06 <jvvv> i have mr's in for 3.19 and 3.20 assumming i had that right, maybe i jumped the gun, dunno... figured it was worth trying
2025-06-02 18:57:42 <jvvv> i saw that the docker image is based on 3.19
2025-06-02 18:58:55 <ikke> Yeah, this pipeline is building the images for multiple versions
2025-06-02 19:00:40 <jvvv> i dl'd the pkgs for ppc64le apk-tools, libssl3, and libcrypto (3.19, 3.20, and 3.21). 3.21 looks fine, but 3.19 and 3.20 were missing symbols for libapk
2025-06-02 19:02:17 <jvvv> i accidently did one for 3.21 anyway (fossdd helped me there, caught it and i closed that one)
2025-06-02 19:05:37 <jvvv> but if someone could pull the trigger on !85105 and !85107, i think it likely that ppc64le docker image will build successfully (i think)
2025-06-02 19:21:52 <ikke> I'll check it after I finish decoupling the pipeline
2025-06-02 19:25:55 <jvvv> ok, sounds good.
2025-06-02 20:30:26 <ikke> jvvv: okay, pipeline is still running, but it now at least builds a single release :)
2025-06-02 20:34:18 <ikke> jvvv: do we even know why that's necessary?
2025-06-02 20:34:56 <ikke> and why only ppc64le
2025-06-02 20:39:18 <jvvv> ikke: well easiest thing to answer is about ppc64le is that it is/was building a container from branch that needed apk-tools to be rebuilt.
2025-06-02 20:41:03 <ikke> jvvv: I mean, why does apk-tools need to be rebuilt in the first place?
2025-06-02 20:42:03 <jvvv> openssl had been upgraded to a new abi since last apk-tools upgrade, as near as i can tell
2025-06-02 20:42:15 <ikke> jvvv: not in 3.19
2025-06-02 20:42:24 <ikke> last upgrade was in february
2025-06-02 20:42:58 <jvvv> maybe i am wrong... wouldn't be first time
2025-06-02 20:44:30 <jvvv> yeah, looking at dates on the apks, seems i am wrong in that respect. i should do better investigating
2025-06-02 20:47:18 <omni> we're all wrong sometimes
2025-06-02 20:48:51 <ikke> It seems the docker images itself are not working properly
2025-06-02 20:48:53 <ikke> I need to fix that
2025-06-02 20:50:57 <ikke> I really need to add some acceptance tests to the image building pipelines to make sure I'm not pushing rubish
2025-06-02 20:52:28 <jvvv> i'm not a docker guru, but if i can spend some time learning more about it and playing with it at home... i have more time since i retired this month
2025-06-02 20:53:23 <ikke> "docker: layers from manifest don't match image configuration."
2025-06-02 20:53:44 <ikke> everything except edge fails with that for registry.alpinelinux.org/alpine/infra/docker/build-base on ppc64le
2025-06-02 20:54:54 <jvvv> ouch
2025-06-02 20:58:29 <jvvv> i've been meaning to setup auto builds for my private aports with mqtt and podman... i should get on that so that i can be more up to speed with these kind of things
2025-06-02 21:07:38 <ikke> fun, next issue: 6.790 cgo: exec cc: fork/exec /usr/bin/cc: exec format error
2025-06-02 21:07:42 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/jobs/1881016
2025-06-02 21:07:45 <ikke> What's up
2025-06-02 21:10:25 <ikke> Yup, also just zero bytes
2025-06-02 21:15:09 <ikke> yak yak yak
2025-06-02 21:18:44 <jvvv> sorry was just looking at the log then was looking into how to replicate it here
2025-06-02 21:19:22 <ikke> Seems like fs issues..
2025-06-02 21:20:01 <ikke> I give up for today
2025-06-02 21:20:32 <jvvv> i don't blame you
2025-06-02 21:31:18 <jvvv> i wonder why there's no alpine-minirootfs-3.22.0-ppc64le.tar.gz, only a dated one with 3.22.0_alpha20241224 for the version
2025-06-02 21:32:25 <jvvv> that's wrong, i was in the edge directory
2025-06-03 02:48:38 <Saijin_Naib[m]> Can linux-lts on edge get a r1 rebuild? Akms fails because kernel gcc is 14.2.0 and gcc in edge to build akms modules with is 14.3.0, so all builds fail
2025-06-03 08:08:33 <donoban> Hi, anyone knows if there is some problem with pythonhosted.org? https://files.pythonhosted.org/packages/source/f/frozenlist/frozenlist-1.6.1.tar.gz , I don't know if wait a little bit or change the source to github
2025-06-03 09:58:49 <ncopa> Ariadne: I'm trying to find out if ifupdown-ng can do normal VLANs? https://www.reddit.com/r/AlpineLinux/comments/1l1cjl7/upgrade_failing_321_322_cant_satisfy_dependency/
2025-06-03 09:59:08 <ncopa> I dont find anything about it in ifupdown-ng docs
2025-06-03 10:00:29 <ncopa> ah, its the link executor
2025-06-03 10:07:02 <f_> ot
2025-06-03 10:07:20 <f_> oops, irssi fuzzy finding fail
2025-06-03 14:31:12 <ffoss> Hm, now with openrc user services, greetd/agreety is causing an error. I believe the greetd user tries to start it's user services, but it fails
2025-06-03 14:31:19 <ffoss> Does that make sense?
2025-06-03 14:32:37 <ffoss> This is with the default /etc/greetd/config.toml, where `user` is set to `greetd`
2025-06-03 14:33:36 <f_> What error?
2025-06-03 14:36:49 <ffoss> f_: https://tpaste.us/W5OY
2025-06-03 14:38:06 <ffoss> Actually the login manager still works, but it does delays the start of it a bit, and print those messages
2025-06-03 14:45:14 <jvvv> after alpine switches to apk-tool3, will 'apk extract' be the only way to unpack an .apk file?
2025-06-03 14:46:04 <jvvv> i think i asked about this before. if i did, i can't remember the answer
2025-06-03 14:49:30 <fabled> jvvv: when the packaging format is changed, then yes
2025-06-03 14:50:42 <fabled> jvvv: that probably will take a longer time period to happen, and even then will happen gradually with 'testing' repository being switched first etc.
2025-06-03 14:51:40 <ffoss> Is it possible to disable user services for only a single user or group?
2025-06-03 14:51:46 <jvvv> i was just thinking that after the switch, that making apk.static available for download (not packaged) might make sense
2025-06-03 14:53:45 <ikke> jvvv: it already is 
2025-06-03 14:54:02 <ikke> Check apk-tools releases 
2025-06-03 14:54:45 <jvvv> ikke: hmmm, i was refering to a copy  that is not packaged in an .apk
2025-06-03 14:54:59 <jvvv> chicken and egg problem?
2025-06-03 14:55:48 <ikke> It's a regular download 
2025-06-03 14:56:02 <jvvv> i'm not looking hard enough
2025-06-03 14:57:17 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/releases
2025-06-03 14:58:24 <jvvv> facepalm
2025-06-03 14:58:56 <jvvv> that is a logical place for it
2025-06-03 14:59:32 <jvvv> thanks
2025-06-03 15:03:40 <omni> perhaps we can teach tar the new format? so that we can continue to `tar xvf package-1.0-r1.asdf.apk`..
2025-06-03 15:06:12 <abby> o.O
2025-06-03 15:23:12 <prabu> ffoss, the greetd user issue is documented in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81612#note_492385. I tinkered with it in multiple ways, unable to fix it when PAM support is enabled for openRC. When openrc-user package is installed, the error goes away, but the services like pipewire linger on after logout..i.e https://tpaste.us/e6ma
2025-06-03 15:25:26 <donoban> mm... if openrc-user.pam just does "session include base-session" it shouldn't exist
2025-06-03 15:25:38 <donoban> "other" policy already does that
2025-06-03 15:26:46 <donoban> ahh no it includes base-session-noninteractive
2025-06-03 15:44:23 <ffoss> prabu: ah I see, that is unfortunate
2025-06-03 15:47:34 <prabu> ncopa, thanks for the clarification on linker script. Does this mean interface file contents mentioned in VLAN page of wiki.a.o works as it's with ifupdown-ng? I can't find any example documentation for vlan in https://github.com/ifupdown-ng/ifupdown-ng/blob/main/doc/ADMIN-GUIDE.md.
2025-06-03 16:35:08 <Ariadne> ncopa: it can
2025-06-03 16:36:23 <Ariadne> prabu: it works just like before, just no vlan package needed.
2025-06-03 16:37:54 <prabu> Ariadne, thanks for the confirmation. i'll update wiki accordingly..
2025-06-03 16:58:38 <craftyguy[m]> ifupdown-ng is a drop-in replacement for a setup with bb ifupdown+vlan pkg? I'd like to move this system I have to use -ng but haven't had the motivation to work through issues I might have migrating my interfaces config, because I've been unsure if it's that easy 😅
2025-06-03 17:02:34 <Ariadne> craftyguy[m]: yes, a drop-in replacement.  only reason i did not just rip out all the old stuff was because it seemed rude.
2025-06-03 17:03:01 <craftyguy[m]> haha. nice, thanks :D
2025-06-03 17:03:48 <Ariadne> next ifupdown-ng release will feature native executors, so iproute2 will no longer be needed for many things
2025-06-03 17:35:37 <prabu> Ariadne, https://wiki.alpinelinux.org/wiki/VLAN page updated. Also the ifupdown-ng still refers and supports dhclient, which no longer is supported..
2025-06-03 17:36:05 <Ariadne> yes.  and?
2025-06-03 17:36:42 <prabu> the docs page interfaces-dhcp.scd needs updation
2025-06-03 17:36:53 <Ariadne> no, it doesn't
2025-06-03 17:39:42 <Ariadne> if alpine is no longer shipping dhclient, that is not relevant at all to ifupdown-ng.  ifupdown-ng will support dhclient if it is present.  if it is not present, due to lack of support in Alpine, then it doesn't matter.
2025-06-03 17:43:37 <Ariadne> i am personally tired of this whole thought process that just because upstream abandons a software that the rest of the surrounding ecosystem also abandons that software, all this does is lead to a more fragile ecosystem where user needs are not properly considered
2025-06-03 17:44:44 <prabu> ok. thanks. i believed so and i've already mentioned so in https://wiki.alpinelinux.org/wiki/Ifupdown-ng . Just wanted a reconfirmation from you. 
2025-06-03 17:57:03 <Ariadne> re: https://wiki.alpinelinux.org/wiki/Configure_Networking, loopback is always configured in ifupdown-ng explicitly, and ifquery always puts it first
2025-06-03 19:22:23 <Saijin_Naib[m]> !85173 is ready to review, but the release notes for packagers suggest passing O3 for build to improve performance, with they say, no noted downsides. Is that appropriate given Alpine Os default, or does that require discussion/review?
2025-06-03 22:55:24 <cannonical> you guys associate with freedesktop.org? they fuck kids just fyi
2025-06-04 01:15:33 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/Saijin-Naib/aports/-/jobs/1882788
2025-06-04 01:15:46 <Saijin_Naib[m]> ppc64le builder is busted?
2025-06-04 01:22:41 <mio> currently offline, yeah, infra team already looking into it
2025-06-04 03:11:55 <Saijin_Naib[m]> No rush! Thanks for confirming. Just wanted to make sure it's not on my side
2025-06-04 03:18:40 <Saijin_Naib[m]> Looks like infra folks fixed it
2025-06-04 10:04:54 <omni> \o/
2025-06-04 10:25:44 <ikke> We sent a support request to OSUOSL, and they fixed it 
2025-06-04 13:58:47 <fabricionaweb> fossdd should libgdiplus be a dependency from mono? I installed mono but it didnt came with, so it broke and I installed it a part
2025-06-04 14:26:43 <fabricionaweb> ah forget me I see it is different stuff
2025-06-04 18:27:55 <Saijin_Naib[m]> Is Taner Tas on here? I would appreciate a review/merge of !84917 so I can get deadbeef caught up to current and have it add a lot of nice-to-have improvements and features
2025-06-04 18:28:20 <Saijin_Naib[m]> Also, thanks ncopa for reviewing rawtherapee so quickly, It is a really nice upgrade from 5.11
2025-06-05 03:07:15 <Riolku> I'm interested in packaging https://codeberg.org/emersion/kimchi but the naming conflicts with a package in edge already, any ideas on what I should do?
2025-06-05 03:23:08 <jvvv> Riolku: i'm not sure about 'should', but i looked at arch linux's AUR and they have kimchi-server-git package that is for the same source. maybe call it kimchi-server?
2025-06-05 03:26:20 <Riolku> hmm maybe yeah
2025-06-05 05:39:17 <Ermine> Riolku: does already packaged kimchi differ from kimchi you want to package?
2025-06-05 06:36:50 <PureTryOut> Ermine: if you look up the source they linked vs what is packaged, yes it's completely different software
2025-06-05 12:37:23 <Riolku> existing one is some kubernetes plugin i think
2025-06-05 12:37:31 <Riolku> linked one is a simple http server
2025-06-06 02:09:25 <timlegge> !85279 fixes CVE-2011-10007 in perl-file-find-rule
2025-06-06 20:50:18 <funderscore> Uh? It seems sourcehut has both go-away and alertmanager-irc-relay in their repos but no effort seems to have been done to upstream them :(
2025-06-06 20:52:19 <funderscore> so I basically repackaged what they already have ...
2025-06-06 20:55:01 <funderscore> guess not a big deal, I like packaging stuff I need :p
2025-06-06 21:03:24 <psykose> why does it matter what downstream repositories have
2025-06-06 21:04:04 <funderscore> not that it matters that much
2025-06-06 21:04:32 <funderscore> part of me is just wondering why they didn't upstream that I guess
2025-06-06 21:05:09 <psykose> because it takes 5000x more effort to upstream something as opposed to just putting it in your own repo
2025-06-06 21:05:32 <funderscore> ¯\_(ツ)_/¯ Why not do it in parallel
2025-06-06 21:05:35 <funderscore> but I digress
2025-06-06 21:51:47 <Ermine> it would be 5001x more effort
2025-06-06 21:58:02 <funderscore> it is worth it.
2025-06-06 22:00:46 <skarnet> it removes the fun in funderscore.
2025-06-06 22:00:51 <sam_> it's completely legitimate to maintain something downstream
2025-06-06 22:01:01 <sam_> especially if they don't have resources yet to bring it up to QA standards and so on
2025-06-06 22:01:37 <funderscore> skarnet: but....but they're not funderscore!
2025-06-06 22:02:01 <skarnet> of course not. They're derscore.
2025-06-06 22:02:04 <funderscore> sam_: yes, never said it was not
2025-06-06 22:02:29 <funderscore> sleep.. \o
2025-06-07 08:53:56 <qaqland> https://gitlab.alpinelinux.org/qaqland/aports/-/jobs/1887102#L4403
2025-06-07 08:54:38 <qaqland> ERROR: unable to select packages: masked in: cache qemu-system-x86_64 (no such package)
2025-06-07 08:56:08 <qaqland> meet this error...
2025-06-07 08:58:52 <ikke> https://pkgs.alpinelinux.org/packages?name=qemu-system-x86_64&branch=edge&repo=&arch=&origin=&flagged=&maintainer=
2025-06-07 09:03:43 <qaqland> there is no x86 after 3.22
2025-06-07 09:12:00 <qaqland> thanks, i have created an issue #17242
2025-06-07 09:17:50 <ikke> unning 64-bits on 32-bits hosts is deprecated
2025-06-07 09:18:09 <ikke> or rather, running anything on 32-bits hosts
2025-06-07 13:34:29 <clandmeter> Ariadne: did you ever get megacli (or anything compatible)  working on alpine? 
2025-06-07 13:36:17 <sertonix[m]> psykose: I noticed that the testing/faust aports is out of date (and you were the last person to actually maintain it). Do you think it's worth it to upgrade or should we just drop the package?
2025-06-07 13:36:30 <psykose> i have zero idea
2025-06-07 13:38:27 <sertonix[m]> Ok
2025-06-07 13:58:23 <clandmeter> looks like storcli does work
2025-06-07 20:41:11 <jvvv> omni: about !84494, do you still need testing for this? i'm currently playing around with running xen-4.20 nested in an qemu vm. would not require much for me to test, i think, mainly getting the packages built correctly (because the ci artifacts were deleted last week).
2025-06-07 20:47:35 <ikke> !84494
2025-06-07 20:48:54 <jvvv> thanks
2025-06-07 23:14:52 <elagost> would someone be able to look at !85111 ?
2025-06-08 06:53:12 <kfx> what's the policy on device-specific kernels?  I see the package policies specify some naming conventions for kernel flavors; is a package for a specific computer welcome in aports?
2025-06-08 12:56:16 <ikke> kfx: generally, we try to avoid adding too specific kernels
2025-06-08 15:56:05 <omni> jvvv: feel free to try, but don't spend too much time on it, the original reporter reported said it didn't work and our 3.18-stable is out of support now with 3.22-stable out
2025-06-08 15:58:11 <funderscore> kfx: it's probably more welcome in postmarketos
2025-06-08 15:58:43 <funderscore> than alpine
2025-06-08 16:30:09 <jvvv> omni: thanks for heads up
2025-06-08 16:32:56 <jvvv> omni: i looked more closely at the iso image that was mentioned for testing... after loop mounting the iso and listing the apk files for xen, these were versioned at the unpatched release 4.17.5-r4 not 4.17.5-r5
2025-06-08 16:41:03 <jvvv> omni: but if we aren't supporting 3.18 anyways, seems like wasted effort at this point
2025-06-08 17:27:40 <omni> jvvv: interesting, I didn't look myself, thanks
2025-06-08 17:27:55 <omni> ncopa: ^^
2025-06-08 18:55:01 <Mohammad_> i install alpine 3.22 virt on VMWare that is in windows 11. and after login with root with setup-interfaces and rcservice networking start connect to internet but when use setup-alpine when in step alpine mirror stay in this step and get no error and no result!
2025-06-09 03:04:29 <Riolku> Mohammad_: wrong channel, use #alpine-linux
2025-06-09 04:34:55 <jvvv> omni: i recreated the 3.18.12 xen iso using patched xen pkgs. before, the dom0 boot got stuck at "Loading hardware drivers ...". now, with fresh iso, i'm doing usual alpine dom0 install. will let you know if reboot and domU creation goes smooth.
2025-06-09 06:20:18 <jvvv> omni: i succesfully booted recreated 3.18.12 iso in vmware, installed dom0, rebooted, and no boot hang. i didn't bother creating any domU's, was running vmware in debian vm... that was like walking thru knee deep mud
2025-06-09 06:22:49 <jvvv> it's funny, but running nested vm's with qemu and xen was much smoother, probably because the qemu vm is kvm and the dom0 and domU's are all pv's, not hvm's.
2025-06-09 07:46:03 <hjaekel> Is the x86_64 builder broken? I get "fatal: unable to create thread: Resource temporarily unavailable"
2025-06-09 07:53:13 <ikke> Builder or CI host?
2025-06-09 07:55:02 <hjaekel> CI host, sorry
2025-06-09 08:00:37 <ikke> Which runner (is shown on top of the log(
2025-06-09 08:01:20 <hjaekel> Running with gitlab-runner 17.10.0 (67b2b2db) on release-name-gitlab-runner-6b65c48dbc-n7jsc t1_rULRkb, system ID: r_gzosLMEuMOwO
2025-06-09 19:57:50 <jvvv> at the top of https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/mpfr4/mpfr4-4.2.2-r0.log, "bad number" error, seems could be avoided with https://tpaste.us/QKq4
2025-06-09 20:00:25 <jvvv> i noticed that ap for lua-aports was throwing "sh: 4.2.2: bad number" whenever i did 'ap -d ~/aports/main sources ...', but not on community or testing
2025-06-10 00:34:44 <sertonix[m]> jvvv: it would be nice to find a patch that simplifies the logic bu otherwise feel free to create a MR
2025-06-10 01:00:37 <jvvv> sertonix[m]: a good point. when i have something, i'll create a MR. thanks
2025-06-10 01:48:08 <jvvv> sertonix[m]: !85449
2025-06-10 06:57:55 <realroot[m]> soundconverter needs py3-setuptools
2025-06-10 10:29:40 <bitblt> new pixman version 0.46.2 is out: https://lists.freedesktop.org/archives/pixman/2025-June/005026.html
2025-06-10 10:29:52 <bitblt> can we bump this on aports?
2025-06-10 11:50:52 <ikke> bitblt: perhaps you can make an MR for it
2025-06-10 13:01:17 <ncopa> I think im gonna tag a edge snapshot
2025-06-10 15:11:02 <ikke> ncopa: when you do, I need to update gitlab.alpinelinux.org/img/alpine as well
2025-06-10 15:53:48 <pltrz[m]> maribu: ping to bump py3-pyperclip to v1.9.0 - I also went ahead and added a link to the alpine package on Anitya
2025-06-10 15:57:23 <maribu> pltrz: I will sadly not be able to look into that before Thursday. Feel free to remind me again if I haven't looked into it by Friday. (Alternatively, you could also open a merge request yourself.)
2025-06-10 15:58:00 <pltrz[m]> marubu: sure thing, no problem; thanks!
2025-06-10 16:16:02 <ncopa> ikke we dont seem to have 3.22 there
2025-06-10 16:16:09 <ncopa> on http://gitlab.alpinelinux.org/img/alpine
2025-06-10 16:17:42 <ikke> ncopa: Yeah, was working on that, but ppc64le outage threw in a spanner
2025-06-10 16:17:46 <ikke> and then other things came
2025-06-10 17:08:28 <ncopa> is build-edge-loongarch64 deadlocked?
2025-06-10 17:08:47 <ncopa> im killing the build
2025-06-11 06:24:59 <caskd> do abuild checks provide no network access?
2025-06-11 06:25:33 <caskd> i am working on a package which tries to fetch something from a remote as part of it's testsuite and despite net being defined in options it seems to fail?
2025-06-11 06:25:46 <caskd> yet in a clean container it's fine...
2025-06-11 06:27:28 <caskd> i am building with rootbld btw
2025-06-11 06:27:42 <ikke> caskd: only with rootbld and if option net is not specified 
2025-06-11 06:27:59 <caskd> but it is specified...
2025-06-11 06:28:02 <ikke> But then everything after fetch no longer has network 
2025-06-11 06:28:12 <caskd> hmm
2025-06-11 06:36:49 <caskd> hmm, i'm really not sure what is different in the environment provided by bwrap in comparasion
2025-06-11 06:36:53 <caskd> i'll try to debug it
2025-06-11 06:38:18 <ikke> https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/
2025-06-11 06:41:14 <jvvv> ugh
2025-06-11 06:45:27 <Ermine> seems like someone has to polyfill that userdb thing
2025-06-11 06:50:05 <caskd> yay, another systemd component which could've instead been generic
2025-06-11 07:11:55 <quinq> “Apologies for the short timeline, but this blog post could only be published after I knew how exactly I’m splitting up gnome-session into separate launcher and main D-Bus service processes.”
2025-06-11 07:12:00 <quinq> Is that the decision of a single person?
2025-06-11 07:34:48 <caskd> ikke: !85499 is the example for the failing tests in abuild
2025-06-11 07:38:11 <caskd> podman run --network=host --rm -i --pull=always docker.io/library/alpine:latest sh -c 'set -e -o pipefail; apk add curl go && curl -L https://github.com/openrdap/rdap/archive/refs/tags/v0.9.1.tar.gz | gzip -d | tar -xv && cd rdap-0.9.1 && go test ./...'
2025-06-11 07:38:19 <caskd> this is what i use to replicate it in a contianer
2025-06-11 07:38:32 <caskd> and in the container it works
2025-06-11 07:38:56 <ikke> caskd: CI does not even use rootbld
2025-06-11 07:39:18 <caskd> well, this is confusing me a lot
2025-06-11 07:39:48 <ikke> Can you try with registry.alpinelinux.org/alpine/infra/docker/build-base:edge?
2025-06-11 07:42:19 <caskd> works there too
2025-06-11 07:42:24 <caskd> ...
2025-06-11 07:50:37 <caskd> ohhh, i think i have it
2025-06-11 07:51:01 <caskd> GOFLAGS has -trimpath by default on abuild, and the module gets it's own path via runtime.Caller
2025-06-11 07:51:16 <caskd> so when the path is trimmed it doesn't match anymore what the test expects
2025-06-11 07:51:24 <caskd> :/
2025-06-11 07:51:37 <caskd> should i replace it removing -trimpath?
2025-06-11 07:51:45 <caskd> (for the test)
2025-06-11 07:52:02 <funderscore>  08:38 <@ikke> https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/
2025-06-11 07:52:19 <funderscore> does this mean alpine may drop gnome in the future
2025-06-11 07:53:13 <funderscore> to me it really sounds like "we will depend strongly on systemd, if you're not happy with that reimplement systemd yourself"
2025-06-11 07:59:20 <ikke> funderscore: I have no idea, it's up to the gnome maintainers to decide 
2025-06-11 12:30:45 <WhyNotHugo> Any feedback for !85002 ?
2025-06-11 13:03:20 <WhyNotHugo> nitpick: apk info --licence doesn't work, but apk info --license
2025-06-11 13:03:26 <WhyNotHugo> license is a verb, licence is the noun
2025-06-11 13:03:48 <WhyNotHugo> license is a common mis-spelling, but --licence should probably work too?
2025-06-11 13:10:16 <abby> license is the noun and verb in american english
2025-06-11 13:15:07 <WhyNotHugo> would still be convenient if --licence worked as an alias.
2025-06-11 13:44:27 <sertonix[m]> It seems to me that licence is british english.
2025-06-11 19:50:55 <realroot[m]> i just opened an issue but i did not realize that i was in apk-tools.
2025-06-11 19:50:55 <realroot[m]> Can somebody move it maybe ? https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11122
2025-06-11 19:51:32 <ikke> Done
2025-06-11 20:13:43 <vmignot> Hi there ! I was wondering what are the functionnal differences between using a "# Maintainer: ..." and setting the `maintainer` variable on a APKBUILD. By default, I would go for the variable, but `newapkbuild` seems to set the former
2025-06-11 20:14:01 <ikke> vmignot: functional there is no difference
2025-06-11 20:14:36 <achill> its just that the variable is not endorsed by the TSC: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/88
2025-06-11 20:15:21 <ikke> There is a bit of a conundrum regarding the # Contributor field if we change that
2025-06-11 20:15:53 <vmignot> Yup, I just gave a quick look to the TSC issue. Thanks !
2025-06-12 10:15:18 <kaathewise> Does anyone from the core team have direct access to buldozer?
2025-06-12 10:15:38 <ncopa> i do
2025-06-12 10:15:41 <kaathewise> I tried to updrade Nushell to 0.105, but the tests failed with a segfault which I wasn't able to reproduce locally
2025-06-12 10:16:10 <kaathewise> https://gitlab.alpinelinux.org/kaathewise/aports/-/jobs/1891920
2025-06-12 10:16:28 <kaathewise> https://gitlab.alpinelinux.org/kaathewise/aports/-/jobs/1891920
2025-06-12 10:16:38 <kaathewise> I was wondering if someone could run that test and get a backtrace
2025-06-12 10:21:17 <kaathewise> Ah, actually, a re-run of that job has just finished, and it completed successfully.  Bizarre
2025-06-12 10:26:30 <ikke> kaathewise: for the record, those are CI hosts, not what we call the builders, which are separate
2025-06-12 10:27:28 <kaathewise> Ah, didn't know that, ty
2025-06-12 10:28:33 <kaathewise> Well, and since I'm here now, the same 0.105 release replaced distro openssl with statically linked rustls
2025-06-12 10:28:33 <kaathewise> https://www.nushell.sh/blog/2025-06-10-nushell_0_105_0.html#no-more-openssl-toc
2025-06-12 10:28:50 <kaathewise> But it can still be disabled.  Should I do that for Nushell or is it alright to compile it as is?
2025-06-12 10:29:02 <ikke> kaathewise: If it's not a HW specific issue, you could try to run the build in the registry.alpinelinux.org/alpine/infra/build-base:edge conntainer
2025-06-12 10:29:17 <ikke> kaathewise: You should use the system openssl
2025-06-12 10:29:27 <kaathewise> ikke: got it
2025-06-12 10:30:00 <kaathewise> Also, yeah, I'm pretty sure that was some kind of low probablity event, because another job in literally the same environment didn't reproduce it
2025-06-12 10:30:19 <kaathewise> I think I'll just shrug it off and return to it if that ever happens again
2025-06-12 11:18:18 <ptrc> oh my god LMAO
2025-06-12 11:18:20 <ptrc> i just got an email
2025-06-12 11:18:25 <ptrc> definitely generated by AI
2025-06-12 11:18:33 <ptrc> from someone reporting "security vulnerabilities"
2025-06-12 11:18:46 <ptrc> their point? aports/community/py3-amqp/tests-server_key.pem
2025-06-12 11:18:56 <ptrc> > Impact: If production keys, they could allow impersonation, decryption, or unauthorized access.
2025-06-12 11:20:25 <funderscore> ptrc: it was me, funderscoreAI™ SecurityAgent® /j
2025-06-12 11:20:38 <ptrc> https://ptrc.gay/cNZGmhMH
2025-06-12 11:21:05 <ptrc> > check() { ./ssl-cert-check -b -c "$srcdir/keyStore.p12" -k "password" | grep " Jun 16, 2034 " }
2025-06-12 11:21:15 <ptrc> this is so silly i don't even know what to respond
2025-06-12 11:21:41 <psykose> just don't respond
2025-06-12 11:22:07 <funderscore> yeah why respond
2025-06-12 12:00:00 <lnl> One time I've had /metrics public and I got an e-mail to security.txt@ from a random ass gmail address. And I fixed it instantly but I've been getting next e-mails from other random gmail addresses for like a week anyway???
2025-06-12 12:02:36 <el[m]1> neat, i managed to join. the thunderbird version currently shipped by alpine edge arm64 seems to have multiple severe vulnerabilities, at least for me it says 138.0. the fixed one seems to be 139.0.2.
2025-06-12 12:02:36 <el[m]1> i dont know how to try to build and update alpine packages yet, but i got some C/C++ experience and i'm on a postmarketOS edge arm64 system right now which is relatively fast and has an SSD, a raspberry pi 5. if desired i could try to build the updated thunderbird package locally for testing, if that's possible with 16GB RAM (i assume it involves building the firefox engine and will therefore be relatively heavy to build).
2025-06-12 12:07:34 <Kladky> Yeah, if you look at https://pkgs.alpinelinux.org/packages?arch=x86_64&name=thunderbird you can see it is known to be out of date
2025-06-12 12:08:17 <Kladky> And there is a merge request to upgrade it: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85570
2025-06-12 12:08:24 <Kladky> !85570
2025-06-12 12:08:31 <Kladky> oh, algitbot works now
2025-06-13 10:13:58 <funderscore> I got inspircd to do an openrc service thing \o/
2025-06-13 10:16:03 <funderscore> well originally I wanted to DIY but Sadie decided to do it herself
2025-06-13 10:16:06 <funderscore> https://github.com/inspircd/inspircd/compare/insp4...SadieCat:inspircd:insp4+openrc
2025-06-13 10:16:19 <funderscore> if anyone is running an inspircd server...
2025-06-13 11:20:23 <Kladky> Could someone take a look at !84270 please? It's ready to be merged