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
2025-06-13 13:29:26 <elagost> would someone be able to look at !85111 too? It's been sitting for a little bit.
2025-06-13 15:32:04 <ikke> FYI, restarting gitlab for security updates
2025-06-13 15:37:54 <ikke> gitlab is back
2025-06-13 16:40:21 <quinq> ikke, back in fashion?
2025-06-13 16:41:48 <ikke> quinq: I'll let you be the judge of that
2025-06-13 16:42:46 <realroot[m]> xlibre xorg fork would be welcome in alpine?
2025-06-13 16:43:08 <quinq> ^^
2025-06-13 16:47:35 <ikke> realroot[m]: what I read about it, I would not expect a lot from it
2025-06-13 16:48:36 <quinq> Maybe let's see if it actually fixes issues and gets some traction
2025-06-13 16:50:20 <ikke> So far the author mostly seem to have broken stuff
2025-06-13 16:50:38 <realroot[m]> well redhat killed xorg development and >Btw, X11Libre's X server got 1.3K commits in 2 weeks.
2025-06-13 16:51:06 <ikke> 1.3K commits to X11 would rather worry me
2025-06-13 16:51:18 <quinq> realroot[m], wait and see :)
2025-06-13 16:52:38 <invoked> the person who created xlibre is leading with political positions, so it does not bode well
2025-06-13 16:53:09 <realroot[m]> there is PR to add apolitical etc. to readme
2025-06-13 16:53:12 <quinq> Why not
2025-06-13 16:53:14 <quinq> Open source is politics
2025-06-13 16:53:23 <realroot[m]> i was thinking maybe to try it
2025-06-13 16:53:32 <invoked> there'
2025-06-13 16:53:38 <invoked> s politics and then there's politics
2025-06-13 16:53:45 <invoked> anti-DEI specifically is quite toxic
2025-06-13 16:54:04 <quinq> What's DEI?
2025-06-13 16:54:19 <invoked> which just says it's not about the software, really, it's just a means to poke at some people
2025-06-13 16:54:45 <skarnet> yup, they pretend to be all about the software first, and lead with a political stance, so it's really not about the software first
2025-06-13 16:55:23 <quinq> Opus DEI?
2025-06-13 16:55:38 <invoked> quinq: initialism for diversity equity inclusion
2025-06-13 16:55:57 <skarnet> quinq: hey, that was almost a good one
2025-06-13 16:56:13 <quinq> oh ok, thanks invoked :)
2025-06-13 16:56:30 <quinq> Well, wasn't the text saying the opposite? That they welcome all kinds of furries?
2025-06-13 16:56:40 <quinq> Maybe I misread, I admit I skipped a bit over that part
2025-06-13 16:59:42 <skarnet> yeah but when from one side of your mouth you say "we're accepting of everyone" and from the other side you say "except for those who won't abide by our stated position that is generally seen as hateful and bigoted even though we say the opposite", it's hard to take you at face value
2025-06-13 17:00:24 <quinq> Finally some politics! ^^
2025-06-13 17:00:34 <quinq> ok, I didn't read that part well enough I suppose
2025-06-13 17:01:06 <realroot[m]> >It doesn't matter which country you're coming from, your political views, your race, your sex, your age, your food menu, whether you wear boots or heels, whether you're furry or fairy, Conan or McKay, comic character, a small furry creature from Alpha Centauri, or just an boring average person. Anybody who's interested in bringing X forward is welcome.
2025-06-13 17:01:08 <skarnet> if they wanted to be as apolitical as they pretend they are, they could just... *not mention politics at all*
2025-06-13 17:01:11 <abby> the forker is this guy, so lol https://www.theregister.com/2021/06/11/linus_torvalds_vaccine_smackdown/
2025-06-13 17:01:38 <ikke> Maybe this can continue in #alpine-offtopic?
2025-06-13 17:01:51 <skarnet> fair
2025-06-13 17:02:29 <quinq> y
2025-06-13 17:46:55 <eletrotupi> heya, noticed that svg icons doesn't seems to work within regular. i do have librsvg and gdk-pixbuf-loaders installed
2025-06-13 17:47:16 <eletrotupi> the app in question is foliate, and regular apps works, but all icons specified on their repository as svg doesn't
2025-06-13 17:47:25 <eletrotupi> https://github.com/johnfactotum/foliate/tree/gtk4/src/icons/hicolor/scalable/actions
2025-06-13 17:47:55 <eletrotupi> i'm using niri, so it might have something to do with that, too, but I don't even know where to poke at it
2025-06-13 17:51:11 <eletrotupi> i do see the svg loader on query-loader: /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader_svg.so
2025-06-13 18:06:09 <psykose> you mean these? https://img.ayaya.dev/woBKWjKIUQso
2025-06-13 18:06:27 <psykose> you probably have some broken gtk theme set
2025-06-14 03:37:42 <Saijin_Naib[m]> Thanks for the fixups jvvv
2025-06-14 03:38:13 <Saijin_Naib[m]> I'm going to try to tackle flatsweep and varia next
2025-06-14 04:02:33 <jvvv> Saijin_Naib[m]: i looked at the pipeline job log for flatseal armhf. it fails because gjs is not built for armhf. i'm looking into that now.
2025-06-14 04:09:04 <Saijin_Naib[m]> Ahh, sweet!
2025-06-14 04:09:16 <Saijin_Naib[m]> I am just pushing a change where I skip armhf with a note about gjs
2025-06-14 04:10:07 <Saijin_Naib[m]> May I ping you in the future to review drafts for flatsweep and varia? I can't get them to show a GUI, so I am wondering if the fixes you made for flatseal might not apply given they are meant to be GNOME Builder assembled and only flatpak'd
2025-06-14 04:11:54 <jvvv> that would be fine
2025-06-14 04:13:46 <Saijin_Naib[m]> Thank you so much for the assistance
2025-06-14 04:14:06 <jvvv> yw
2025-06-14 04:15:33 <jvvv> fixes were necessary in order to build flatseal, gnome builder should not matter in this case one way or another
2025-06-14 04:50:39 <jvvv> Saijin_Naib[m]: yeah, i thought you might need to disable armhf... is due to gjs depending on mozjs which has #14232 (linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1786619).
2025-06-14 06:03:39 <Saijin_Naib[m]> Ah, my Pi 1B will be sad it cant run flatseal 🤣
2025-06-14 06:06:47 <jvvv> Saijin_Naib[m]: i'm looking at some patches that debian uses and originate for the same time as the mozilla bug
2025-06-14 06:06:58 <jvvv> no promises
2025-06-14 06:27:50 <Saijin_Naib[m]> Hey, if you think it is worthwile, that's amazing
2025-06-14 06:28:44 <Saijin_Naib[m]> Some nice GNOME apps rely upon gjs/mozjs, so it can open the door to them on ARMHF
2025-06-14 06:31:25 <Saijin_Naib[m]> jvvv, !85655 is for flatsweep if you get time to take a look. I am missing something, it fails to run with missing Gtk.py in the trace, same as varia
2025-06-14 06:31:44 <Saijin_Naib[m]> I hope it is simple and I'm just not getting it
2025-06-14 06:52:34 <jvvv> flatsweep has some brokeness in its data/meson.build file... it does not set the installation directory correctly. strange because author got it right elsewhere
2025-06-14 06:56:11 <Saijin_Naib[m]> So, an upstream thing to fix ideally?
2025-06-14 06:59:00 <jvvv> i've got at patch, will upload it to the MR, after i've tested it
2025-06-14 06:59:33 <jvvv> s/\(got a\)t \(patch\)/\1 \2/
2025-06-14 06:59:36 <Saijin_Naib[m]> Oh, sweet
2025-06-14 06:59:46 <Saijin_Naib[m]> Want me to try and upstream it, crediting you of course?
2025-06-14 07:07:20 <jvvv> sorry, i gotta rework the patch... my meson foo is ok, but i gotta read the manual to see where this is going wrong
2025-06-14 07:22:52 <jvvv> Saijin_Naib[m]: actually, patch is not needed... i thought i was seeing an error, but it was just a warning that it's skipping stuff like updating the icon cache, which makes sense
2025-06-14 14:58:35 <Saijin_Naib[m]> Ah, good news!
2025-06-15 15:03:47 <myryk[m]> Good evening,... (full message at <https://matrix.org/oftc/media/v1/media/download/AUGdcPukOifnzxhJEJodO60ZbpDMgZQ_GB6XcipJPiqDBeKjjWzijCen-3oiI8C3mP8aEZr0KgfM3zzPu1FJH7JCeXvDdDBwAG1hdHJpeC5vcmcveFBkbkdwY1NJbHlsWFpoTFBtV2lTQW9V>)
2025-06-15 21:11:00 <rhizoome> myryk[m]: it sounds like you are trying to mix postmarkedos and alpinelinux, since I cannot find a vlc package in pmos. I don't know much about pmos, but I don't think you can mix it with alpine. https://pkgs.postmarketos.org/packages?name=vlc*&branch=v24.12&repo=&arch=&origin=
2025-06-15 21:12:45 <myryk[m]> rhizoome: Postmarketos is using alpine as its base, any packages that are not it their package list are coming from alpine
2025-06-15 21:13:22 <rhizoome> myryk[m]: ok. thanks. so lets check in alpine. a moment...
2025-06-15 21:15:46 <rhizoome> myryk[m]: v3.22 of alpine linux seems consistent. which version of alpine is your current pmos based on?
2025-06-15 21:16:24 <myryk[m]> rhizoome: its based on edge.
2025-06-15 21:17:38 <rhizoome> myryk[m]: yes edge is inconsistent, lets see if there is already a rebuild merge request.
2025-06-15 21:19:45 <myryk[m]> While we're at it `ffmpeg-libavcodec` also had dependency issues
2025-06-15 21:20:05 <myryk[m]> What would the proper place to report that be, for the next time?
2025-06-15 21:25:52 <rhizoome> myryk[m]: imo it is ok to say it here, especially since you already checked what the problem is, but here someone may react or not. officially you should use issue-tracker https://gitlab.alpinelinux.org/alpine/aports/-/issues
2025-06-15 21:27:37 <myryk[m]> rhizoome: okay great. Thx for the help, heading to bed now. One last question: what's the meaning of a "special" dependency?
2025-06-15 21:31:24 <rhizoome> myryk[m]: you mean like so:libprotobuf-lite.so.29? These are automatically generated by the build-system. When a package is built, the system lists all shared-objects the package depends on and all shared-objects a package provides. This saves a lot of manual work.
2025-06-15 21:49:57 <rhizoome> myryk[m]: VLC rebuild has been commited. Should be built by tomorrow.
2025-06-15 22:08:31 <rhizoome> myryk[m]: ffmpeg-libavcode has also been fixed today.
2025-06-15 22:19:30 <rhizoome> a follow-up to the rebuild of vlc !85738
2025-06-15 22:58:46 <ayakael> Hey all, is there an easy way to resign apk packages? I'm struggling with integrating in a repo a package that was built on a different machine, and there doesn't seem to be a documented way to resign packages. Thanks!
2025-06-15 22:59:23 <ayakael> (basically getting ERROR: package.apk: UNTRUSTED signature when rebuilding repo index with abuild index)
2025-06-15 23:01:53 <pbui> i believe there is abuild-sign command: https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers
2025-06-15 23:02:46 <ayakael> Unfortunately it only seems to work for sign APKINDEX files.
2025-06-15 23:04:48 <pbui> after signing the index, you will need to copy the corresponding public key to /etc/apk/keys
2025-06-16 09:18:43 <strophy> Hi, I'm running into a CI error while trying to add an aport that depends on a package in edge/testing https://gitlab.alpinelinux.org/strophy/aports/-/jobs/1897733
2025-06-16 09:19:21 <strophy> Do I need to move the bazel8 dependency to edge/community first? Or how can I get it to run in CI?
2025-06-16 09:21:50 <ikke> Yes, packages in community cannot depend on packages in testing
2025-06-16 09:23:02 <strophy> Thanks, I'll do an MR to move bazel8 to community since I'm maintainer of that as well
2025-06-16 09:24:49 <ikke> You could do it in the same MR
2025-06-16 09:27:13 <strophy> Good point, I did it like that
2025-06-16 11:45:24 <Kladky> Could someone please take a look at !85021? The assigned reviewer (Jirutka) hasn't reviewed it yet, but they tend to be pretty slow to respond, and all it does is merge one of their packages into mine, so I think it should be fine with only my approval
2025-06-16 13:52:01 <ncopa> im trying to move py3-crpytography to main and the rabbit hole is deep
2025-06-16 14:41:43 <Piraty> pbui: hi :)
2025-06-16 14:42:57 <pbui> wow, long time no see Piraty
2025-06-16 16:01:52 <rhizoome> myryk[m]: By chance I just encountered a special dependency, I tried to find out what definition of a special dependency is, but I did not find it. So I don't know.
2025-06-16 16:05:07 <myryk[m]> rhizoome: Okay :D, I just noticed that both times the broken dependency was marked as special. Thanks for fixing vlc, wi try installing again today
2025-06-16 16:54:08 <craftyguy[m]> @fossdd is there a reason why we aren't packaging linux-stable for armhf?
2025-06-16 16:54:16 <achill> no device runs on it
2025-06-16 16:54:58 <achill> raspberries runs linux-rpi and all other devices can run in v7 mode anyway
2025-06-16 23:25:32 <elagost> would anyone be able to review !84228 ? It's been sitting for a while.
2025-06-17 03:12:40 <Saijin_Naib[m]> This looks amazing!
2025-06-17 08:09:29 <nightlight> I try to compile Gimp from source to a flatpak. the first part is done I have a build folder. But when I try to run 2_build-gimp-flatpak.sh the terminal puts out a error: "ninja: error: '/usr/lib/libappstream-glib.so', needed by 'app/config/test-config', missing and no know rule to make it"
2025-06-17 08:12:30 <nightlight> If I look in the /usr/lib folder I can't find it. but with apk info appstream-lib it is installed. Should I change that line to find the right package?
2025-06-17 08:20:43 <psykose> you need appstream-glib-dev
2025-06-17 08:21:56 <nightlight> psykose: I Have that installed but the same error
2025-06-17 08:23:52 <psykose> ah you're running that gimp build script
2025-06-17 08:24:03 <psykose> no idea then, you'll have to figure out why it fails
2025-06-17 16:51:14 <pabloyoyoista|m> Hi, has anybody had issues recently with Firefox crashing?
2025-06-17 16:51:58 <pabloyoyoista|m> I have been getting some recurrently since a few weeks, after one of the last firefox-esr upgrades
2025-06-17 16:52:33 <craftyguy[m]> no issues here, but I'm on 139 on aarch64
2025-06-17 18:32:24 <craftyguy[m]> any chance someone can take a look at merging !85702 ? thanks :)
2025-06-17 18:38:00 <craftyguy[m]> thank you ikke!
2025-06-17 18:46:48 <hjaekel> Where do I get zstdConfig.cmake from? It's not included in zstd-dev
2025-06-17 18:47:46 <ikke> There does not appear to be a package that contains it
2025-06-17 18:47:53 <ikke> https://pkgs.alpinelinux.org/contents?file=zstdConfig.cmake&path=&name=&branch=edge&repo=&arch=
2025-06-17 18:48:58 <hjaekel> I know. The CMakeLists.txt of my project uses find_package(zstd CONFIG REQUIRED) and that fails
2025-06-17 18:49:29 <hjaekel> Why is zstd not build with cmake?
2025-06-17 18:50:01 <abby> iirc cmake can use pkg-config/pkgconf if available
2025-06-17 18:52:19 <hjaekel> Can I replace the find_package statement with something that uses pkgconfi? Sorry, I am not familiar with cmake
2025-06-17 18:56:00 <abby> a project just needs to have a find_package(PkgConfig REQUIRED) line then it should work
2025-06-17 18:56:38 <abby> maybe
2025-06-17 18:56:40 <abby> idk
2025-06-17 18:56:43 <hjaekel> Thanks, I will try that
2025-06-17 19:16:18 <hjaekel> abby that worked, thank you
2025-06-18 07:08:23 <rhizoome> I think (hope) this one should be an easy one: !85521
2025-06-18 14:45:47 <ncopa> I am moving a significant number of py3- packages to main in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85756
2025-06-18 14:45:52 <ncopa> any objections?
2025-06-18 16:51:52 <caskd> PureTryOut: do you still use kaidan?
2025-06-18 16:52:09 <caskd> tried installing on latest-stable and it complains about a bunch of symbols missing
2025-06-18 16:58:10 <caskd> rebuild doesn't seem to help
2025-06-18 16:58:13 <caskd> ...
2025-06-18 17:15:27 <PureTryOut> caskd: I've never used Kaidan, or XMPP for that matter. Do you mean "3.22" with "latest-stable" or edge?
2025-06-18 17:15:37 <caskd> 3.22
2025-06-18 17:15:44 <caskd> ur the maintainer for it
2025-06-18 17:15:47 <caskd> so i assumed you use it
2025-06-18 17:15:49 <caskd> ^^'
2025-06-18 17:16:12 <caskd> or maybe because alpine-desktop?
2025-06-18 17:16:22 <PureTryOut> I'm the maintainer for all of KDE but that doesn't mean I use all of it 😅
2025-06-18 17:16:42 <caskd> oh okay
2025-06-18 17:17:04 <caskd> welp, that one is broken so i'll try to figure out what's wrong
2025-06-18 17:17:07 <caskd> sorry for the ping
2025-06-18 17:17:18 <PureTryOut> no don't worry, I do have the responsibility to fix it 😉
2025-06-18 17:17:31 <PureTryOut> What symbols is it complaining about? Probably just needs a rebuild
2025-06-18 17:17:43 <caskd> its qt
2025-06-18 17:17:47 <caskd> not linker
2025-06-18 17:17:56 <caskd> i tried rebuilding and it didnt help
2025-06-18 17:18:06 <PureTryOut> Hmm at least it's missing a runtime dep on QtLocation
2025-06-18 17:18:54 <caskd> https://envs.sh/tz.txt
2025-06-18 17:19:15 <PureTryOut> Seems to work otherwise though
2025-06-18 17:19:24 <caskd> oh?
2025-06-18 17:19:38 <caskd> for me not even a window shows up
2025-06-18 17:19:39 <PureTryOut> ACTION sent a code block: https://matrix.org/oftc/media/v1/media/download/ATgNneE7lO1D_wg6dRikFIua3s9jjLZREq23x3IopOQpdqlW8vOz9qz84gfAh3akbHZd6NbJ6gBajqKwxb3GnFxCeXzCa3-QAG1hdHJpeC5vcmcvZnZVWE9mRFRqemxHQ2xkVW5WbUp2SHBE
2025-06-18 17:19:52 <PureTryOut> yeah what you posted is a missing runtime dep on qt6-qtlocation
2025-06-18 17:19:56 <PureTryOut> Install it, I'll fix the packaging
2025-06-18 17:20:23 <caskd> oh
2025-06-18 17:20:27 <caskd> ur right
2025-06-18 17:20:48 <caskd> to be fair i don't know qt libraries and what they contain
2025-06-18 17:20:52 <caskd> so i didnt know what to look for
2025-06-18 17:21:22 <PureTryOut> Well it's not a missing symbol 😄
2025-06-18 17:21:31 <caskd> yes, that's the difficult part
2025-06-18 17:21:40 <caskd> despite me having a copy of package repo locally
2025-06-18 17:21:45 <caskd> i will not grep it all
2025-06-18 17:21:46 <caskd> lol
2025-06-18 17:22:23 <PureTryOut> `module "<something>" is not installed` are Qt errors telling you're missing QML modules
2025-06-18 17:23:09 <caskd> should i open a mr or will you?
2025-06-18 17:24:26 <PureTryOut> Already have, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85843. Will backport to 3.22 after
2025-06-18 17:24:32 <caskd> okay, thanks :D
2025-06-18 20:33:57 <haesbaert> Is there any compat package that includes a b64_ntop (that's in glibc's libresolv). It seems there isn't as openbsd-netcat includes its own. I'm porting some software and just wanted to double check before I include my own copy
2025-06-19 06:24:53 <Saijin_Naib[m]> Can !85647 get a review/merge?
2025-06-19 06:25:09 <Saijin_Naib[m]> Same with !84917
2025-06-19 14:20:52 <el[m]1> fwiw there seems to be some udisks normal-to-root-privilege-escalation security hole, CVE-2025-6019. if you havent heard yet
2025-06-19 14:23:52 <el[m]1> and some PAM privilege escalation exploitable over SSH affecting a bunch of distributions: https://www.openwall.com/lists/oss-security/2025/06/17/4 CVE-2025-6018
2025-06-19 15:29:02 <ncopa> nasty
2025-06-19 16:32:19 <dalias> as usual polkit=rootkit
2025-06-19 16:33:29 <dalias> this whole thing is basiscally the interaction of 3+ bad components intentionally disregarding unix permissions model and doing their own shit
2025-06-19 16:33:39 <dalias> (polkit, pam, and systemd)
2025-06-19 16:34:11 <dalias> i doubt any of it affects alpine, especially not in a default or reasonable configuration, but i guess it should be checked if folks with polkit installed are affected
2025-06-19 16:39:00 <craftyguy[m]> in other news, if you enable a deprecated feature with known security issues, you might have security issues.
2025-06-19 20:40:20 <rickard0> Hello, I have been trying to build the HSR kernel module under alpine 3.22 all day but I have had trouble. I think I have all the versioning correct, but I still get "Invalid module format" when trying to load the built module with insmod.
2025-06-19 20:40:32 <rickard0> Here is my current procedure: apk add nano git alpine-sdk build-base linux-lts-dev sed installkernel bc linux-headers linux-firmware-any openssl-dev ncurses-dev diffutils && git clone --depth 1 --branch 3.22-stable https://git.alpinelinux.org/aports && cd aports/main/linux-lts && abuild -F fetch unpack prepare && cd src/linux-* && cp /usr/src/linux-headers-$(uname -r)/.config . && cp /usr/src/linux-headers-$(uname -r)/Module.
2025-06-19 20:40:54 <rickard0> #ENABLE WITH CONFIG_HSR=m && make -j$(nproc) modules_prepare && make -j$(nproc) M=net/hsr modules
2025-06-19 21:14:40 <rhizoome> rickard0: https://tpaste.us/6K4z lts.x86_64.config created with "make menuconfi", loading lts.x86_64.config, enabling HSR, saving lts.x86_64.config. Copy into aport/main/linux-lts, abuild checksum, abuild -r. I don't know if it works I am currently building it.
2025-06-19 21:15:28 <rickard0> You need to rebuild the whole kernel everytime instead of just the module?
2025-06-19 21:16:53 <craftyguy[m]> look into AKMS
2025-06-19 21:17:00 <rhizoome> rickard0: I guess you can do that, but for me it is not worth the hassle. if you rebuild the whole thing, you have to wait longer, but work less.
2025-06-19 21:17:22 <craftyguy[m]> https://github.com/jirutka/akms
2025-06-19 21:17:32 <rickard0> Ok, thank you for your help, ill try building overnight
2025-06-19 21:17:45 <craftyguy[m]> oh if it's in-tree.. ya you have to build the whole kernel I guess
2025-06-19 21:18:20 <craftyguy[m]> or sent a MR (or file an issue) requesting that module is enabled by default in the config
2025-06-19 21:23:05 <rhizoome> rickard0: and as craftyguy[m] said, HSR sounds like something alpine-linux would enable by default, so you can send an MR or open an issue.
2025-06-20 06:30:44 <srcfn> I was getting frequent segfaults with firefox-esr on v3.22. This patch from firefox (non-ESR) seems to fix it: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17131 .
2025-06-20 06:34:10 <srcfn> @ptrc maybe?
2025-06-20 06:57:11 <liske> weird issue I observedon two Alpine 3.22 hosts running in diskless mode: "lbu st" doesn't cleanup its working files in /tmp/lbu-*
2025-06-20 06:57:59 <liske> (and lbu status is issued by our monitoring system to detect uncommitted changes… so the root (tmpfs) gets filled up)
2025-06-20 06:59:06 <liske> is this known?
2025-06-20 07:07:12 <ikke> liske: haven't heard any reports yet myself
2025-06-20 10:57:59 <liske> I've upgraded another host running in diskless mode from 3.21 to 3.22 and the issue occurs :-O
2025-06-20 11:10:48 <liske> #17283
2025-06-20 11:34:14 <liske> it is a regression in alpine-conf: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/258
2025-06-20 17:18:21 <Ariadne> please do not import xlibre into alpine under any circumstance
2025-06-20 17:18:59 <ikke> ack
2025-06-20 17:28:42 <realroot[m]> too late
2025-06-20 17:35:25 <Ariadne> i do not presently see it in aports :)
2025-06-20 17:36:04 <ikke> And no merge requests for it
2025-06-20 17:36:29 <realroot[m]> tomorrow is the first release I've heard so it cannot be there now
2025-06-20 17:36:31 <craftyguy[m]> yeah it's not "too late" because it's not there 🤷♂️
2025-06-20 17:36:41 <realroot[m]> I meant that xlibre has gained a lot of traction
2025-06-20 17:36:51 <ikke> Doesn't mean we have to include it
2025-06-20 17:39:22 <Sheila> my understanding is that the people among whom it's gaining traction are not people who would be valuable community members, and moreover the main dev has a history of losing interest once he discovers that Doing The Thing is hard, actually.
2025-06-20 17:42:08 <realroot[m]> my understanding is that people interested in xorg are interested
2025-06-20 17:42:10 <psykose> i browse the issues on it for fun and the only traction i see it gaining is an alarming amount of conspiracy theory discussion and regressions from xorg
2025-06-20 17:42:23 <Ariadne> let me be more direct: if anyone merges xlibre i will be pursuing a code of conduct violation against them
2025-06-20 17:42:46 <realroot[m]> really? for what reason?
2025-06-20 17:43:11 <Ariadne> because the xlibre project represents an unacceptable ideology
2025-06-20 17:43:27 <realroot[m]> updating xorg?
2025-06-20 17:43:44 <realroot[m]> this is about software
2025-06-20 17:43:56 <Sheila> this is about politics, not just software.
2025-06-20 17:44:42 <pabloyoyoista> Is there even anything about software in that discussion?
2025-06-20 17:44:57 <psykose> regressing it a bunch
2025-06-20 17:44:59 <psykose> ends there though
2025-06-20 17:45:17 <Sheila> I know that a lot of people think that you can be apolitical in technology, but refusing to engage with politics is de facto supporting the status quo, which is a political position.
2025-06-20 17:45:26 <realroot[m]> i am talking about updated xorg fork therefore it's only related to software
2025-06-20 17:45:36 <Sheila> it is not 'updated' in any useful sense.
2025-06-20 17:45:47 <psykose> are you pretending to be wilfully obtuse and blind to reality
2025-06-20 17:45:48 <skarnet> even if you make abstraction of the politics of it (which, you shouldn't) I'm not fully convinced that the technical acumen of the Xlibre team will make it easy and burdenless to interact with for the Alpine team
2025-06-20 17:46:02 <Sheila> if you look at fd.o's Xorg repos recently they've been reviewing metux's contributions and stripping them out.
2025-06-20 17:46:10 <Ariadne> i am not opposed to other forks of X.org, just that specific one.
2025-06-20 17:46:34 <Sheila> which is not exactly an indication that xlibre has technical merit.
2025-06-20 17:47:50 <Sheila> furthermore, xlibre is motivated primarily by the part where he was booted from fd.o due to CoC violations, as evidenced by his efforts to remove any such barriers to contributing to his petty fork.
2025-06-20 17:48:30 <Sheila> but sure, it's totally just about the software. pull the other one, it's got bells on.
2025-06-20 17:48:55 <Ariadne> i mean, it is pretty clear that fd.o does not give a single shit about X anymore
2025-06-20 17:49:06 <Ariadne> so if someone who is not metux wishes to do a fork, cool
2025-06-20 17:49:31 <Sheila> they have even put out calls asking for anyone who wants to maintain X to step up
2025-06-20 17:49:42 <quinq> Maybe move the discussion to #off-topic
2025-06-20 17:49:57 <Ariadne> it is on-topic, because this is actually a security problem for alpine
2025-06-20 17:50:06 <quinq> What is?
2025-06-20 17:50:14 <quinq> Some software fork politics?
2025-06-20 17:50:43 <Ariadne> the X implementation, and the ability of the security team to have productive collaboration with said X implementation is relevant to alpine
2025-06-20 17:51:05 <quinq> wa
2025-06-20 17:51:06 <quinq> t
2025-06-20 17:51:28 <Ariadne> what part of that did you misunderstand?
2025-06-20 17:53:09 <quinq> The part how your own view (which is legit to have) on some software fork in the wild and continue arguing about it is relevent to Alpine linux security
2025-06-20 17:53:17 <Ariadne> major pieces of software, such as X, require more effort to provide security support for. the security team prefers working with upstream to provide this security support to alpine users. in this case, i seriously doubt we can work with xlibre.
2025-06-20 17:53:43 <quinq> Did anybody ask?
2025-06-20 17:53:53 <psykose> eyy it's the #1 troll
2025-06-20 17:53:57 <psykose> what up quinq
2025-06-20 17:55:06 <quinq> Do I know you?
2025-06-20 17:55:08 <Sheila> <quinq> Did anybody ask? // a user, in this channel, literally suggested that xlibre might have technical merit.
2025-06-20 17:56:27 <quinq> I must have missed it, looked like that came out of the blue
2025-06-20 17:57:02 <f_> 19:43 <Sheila> this is about politics, not just software.
2025-06-20 17:57:08 <f_> Free Software *IS* politics
2025-06-20 17:57:25 <Ariadne> i'm not going to bother asking a project whose community is filled with conspiracy theories
2025-06-20 17:58:07 <Ariadne> xlibre is security NAK unless something substantially changes with their project
2025-06-20 17:58:17 <ikke> Can we please let this rest for now?
2025-06-20 18:00:42 <Ariadne> as long as the security NAK is respected :))))
2025-06-20 18:02:40 <quinq> noted :)
2025-06-20 18:24:37 <valerius> if you care about the opinions of who wrote the software you use, you might as well shut down your computer and never turn it on again
2025-06-20 18:25:00 <valerius> but with that said, I think once people experience a functional Wayland compositor they will have little desire to go back to X
2025-06-20 18:25:16 <valerius> in other words, the discussion above is actually a non-issue long term
2025-06-20 18:26:48 <Sheila> <valerius> but with that said, I think once people experience a functional Wayland compositor they will have little desire to go back to X // Wayland accessibility is a significant issue still.
2025-06-20 18:27:08 <valerius> accessibility in what sense?
2025-06-20 18:27:34 <Sheila> screen readers and other support for print-disabled users.
2025-06-20 18:27:42 <valerius> ahh... yeah, I know nothing about that
2025-06-20 18:28:37 <valerius> but I am sure it will improve as more distros are defaulting to Wayland based desktops and interest in fixing that problem will rise
2025-06-20 18:29:02 <f_> yes there's work ongoing AFAIK, it's going slow but it's going
2025-06-20 18:29:03 <Ariadne> to be clear, i understand the need for an X fork. i am just skeptical based on what i've seen that Xlibre will succeed
2025-06-20 18:29:53 <valerius> I would say wait for any fork to prove itself by being integrated into a niche distro and showing that it is being actively developed over the long term in a way that doesn't entirely break it
2025-06-20 18:29:59 <Ariadne> X has a ton of packages, DDXes (graphics drivers), input methods, extensions, etc.
2025-06-20 18:30:59 <Ariadne> i see no tangible plan to properly maintain these components, instead i see anti-DEI marketing
2025-06-20 18:33:07 <valerius> politics first and software second is rarely successful
2025-06-20 18:33:26 <valerius> I don't care about people's politics if they are developing quality software, and neither do the majority of people
2025-06-20 18:33:29 <Ariadne> we are going from a world where these components are barely maintained by the companies that make the relevant hardware, to a world where these components are maintained by people who want to complain about politics
2025-06-20 18:33:36 <Ariadne> valerius: correct
2025-06-20 18:33:43 <valerius> but it becomes hard to develop quality software when your focus is politics
2025-06-20 18:34:51 <valerius> anyway, I say shelve the Xlibre conversation for at least a year :p
2025-06-20 18:35:28 <Ariadne> anyway, given that, it is my belief that an Xlibre world will place further burden on alpine's security team, because the corporate maintainers will continue to fix issues in Xorg, and we will have to triage whether those issues were correctly ported to Xlibre in a way that does not introduce security regressions
2025-06-20 18:35:37 <Ariadne> hence the security NAK
2025-06-20 18:36:47 <Ariadne> based on knowledge and experience, this is 100% likely to happen that Xlibre will miss or intentionally reject security fixes, because the project is reactionary
2025-06-20 18:48:14 <abby> the fork will probably die in a few months, because it is reactionary
2025-06-20 18:50:07 <orbea> if it dies so quickly all on its own then there is no reason to even worry about it, any X11 fork should prove themselves on merit before being widely adopted
2025-06-20 18:50:28 <Ariadne> this is basically my point: security NAK until proven
2025-06-20 18:51:15 <Ariadne> i would propose an alternative strategy: fork the core X server, xf86-video-modesetting, xf86-input-libinput, and that's all
2025-06-20 18:51:30 <orbea> tbf forking and improving upon X11 doesn't seem at all trivial
2025-06-20 18:52:32 <abby> because it's already perfect /s
2025-06-20 18:52:47 <orbea> i'm still on the amdgpu ddx, modesetting wasn't quite right last I tried, but maybe its been since fixed
2025-06-20 18:53:39 <Ariadne> the point is that any fork should focus on DDXes that are generic and do not require domain-specific knowledge to maintain
2025-06-20 18:53:58 <Ariadne> e.g. it is better to fix bugs in modesetting than fork amdgpu
2025-06-20 18:54:05 <orbea> true
2025-06-20 18:54:34 <Ariadne> there is a high degree of risk in introducing new regressions forking hardware-specific DDXes
2025-06-20 18:54:56 <orbea> yea, that is a good point
2025-06-20 18:55:36 <Ariadne> and given that X has features like surfaces which must be securely erased when destroyed, those regressions could become security regressions
2025-06-20 18:55:57 <f_> or more than 'just' that
2025-06-20 18:56:05 <valerius> I remember the days when X.Org was forked from XFree86
2025-06-20 18:56:14 <valerius> I think these cases are compared, but it is apples to oranges
2025-06-20 18:56:44 <Ariadne> X.Org was forked by people with appropriate domain knowledge; Xlibre is forked by politically-motivated reactionaries
2025-06-20 18:56:46 <valerius> the reasons for the fork are different, and the developer support as well
2025-06-20 18:57:27 <valerius> also the ecosystem has changed significantly since then
2025-06-20 19:00:02 <Sheila> I mean, I am not, in general, sanguine about a fork where the main developer had to have the XOR operator explained to them.
2025-06-20 19:01:12 <Sheila> even without his politics, I cannot trust that someone who is not familiar with C enough to understand that '2^16' is not 2 to the 16th power knows what they're doing with any other part of the project, much less anything with security implications.
2025-06-20 19:01:48 <Ariadne> i don't care about his politics if there is a path that involves not interacting with him that is sustainable
2025-06-20 19:03:07 <Ariadne> what i care about is: X.org patches a vulnerability, did Xlibre correctly patch the vulnerability as well
2025-06-20 19:03:29 <valerius> in 2 years 85% of desktop Linux users will be on Wayland
2025-06-20 19:03:36 <Ariadne> right now, there are two paths to figuring that out
2025-06-20 19:04:05 <Ariadne> option 1: ask Xlibre developers. this involves interacting with Xlibre developers, which seems... unpleasant given the reactionary nature of the project
2025-06-20 19:04:46 <Ariadne> option 2: audit Xlibre codebase ourselves. this involves monitoring many packages on freedesktop.org *and* in Xlibre, to ensure bugfixes are synced
2025-06-20 19:05:04 <valerius> oh, but there is a third option
2025-06-20 19:05:14 <Ariadne> option 3: don't care and stick with X.org?
2025-06-20 19:05:16 <Ariadne> ;)
2025-06-20 19:05:18 <valerius> that is to simply wait it out, and see if a competent group of devs makes a different fork :p
2025-06-20 19:05:43 <Ariadne> i mean the adelie people love X
2025-06-20 19:05:47 <Ariadne> maybe they will fork it
2025-06-20 19:05:53 <orbea> short term option 3 seems the best
2025-06-20 19:05:56 <Ariadne> i would have a higher degree of confidence in them doing it :P
2025-06-20 19:06:00 <orbea> long term, hard to predict
2025-06-20 19:06:35 <valerius> what I suspect will happen is Xlibre will die, X.Org will remain effectively in a zombified state, and everyone moves to Wayland
2025-06-20 19:06:44 <Ariadne> this is my prediction too
2025-06-20 19:07:38 <valerius> and I say this as a curmudgeon who went to Alpine to avoid systemd and other "modern" stuff :p
2025-06-20 19:09:01 <f_> ACTION installs systemd on valerius' laptop
2025-06-20 19:09:30 <Ariadne> i mean one of the reasons i have worked on Alpine for 15 years is because i want a distribution that is simple and easy to model in my head :p
2025-06-20 19:09:56 <Ariadne> i don't care about old vs new, i care about simplicity and usability
2025-06-20 19:10:03 <valerius> yeah, this is where I am at also
2025-06-20 19:10:12 <valerius> I will accept "new" if it is actually better
2025-06-20 19:10:24 <valerius> "new" does not always imply better
2025-06-20 19:10:30 <Ariadne> correct
2025-06-20 19:12:23 <Sheila> <Ariadne> i mean the adelie people love X // we recently put in a significant effort toward Wayland support, actually.
2025-06-20 19:13:22 <Sheila> (and I'm still looking for Wayland compositors that do interesting things or at least port popular X wms to Wayland)
2025-06-20 19:18:26 <valerius> hyprland is working well for me after I removed all the default "glitz and glam"
2025-06-20 19:18:43 <valerius> I have heard labwc is good for people who like stacking
2025-06-20 19:21:45 <valerius> seatd is also working well for me, no need for elogind
2025-06-20 19:22:37 <Ariadne> i think seatd is more "alpine" style anyway
2025-06-20 19:22:50 <Ariadne> small components which are composable and understandable
2025-06-20 19:23:11 <orbea> i was hoping someone would add seatd for x11
2025-06-20 19:23:26 <f_> Sheila: I used to use dwl back in my early wayland days, I am now using sway
2025-06-20 19:23:37 <Ariadne> i just use plasma
2025-06-20 19:23:41 <Ariadne> i am lazy
2025-06-20 19:23:48 <f_> I am also lazy
2025-06-20 19:24:59 <f_> I was tired of having to rebuild/repatch dwl on every upgrade, hence why I switched to sway. I just mostly added my keybindings, changed the colourscheme, and mostly moved on
2025-06-20 19:29:53 <Sheila> f_: yeah, we have sway. :)
2025-06-20 19:30:09 <f_> nice
2025-06-20 19:34:10 <Ariadne> tbh what someone should do is make a wayland compositor which just acts as an x server directly
2025-06-20 19:34:24 <Ariadne> so it's wayland under the hood, but you can still use whatever X window manager you want, etc
2025-06-20 19:34:39 <ikke> What is xwayland?
2025-06-20 19:34:44 <Ariadne> the opposite of that
2025-06-20 19:34:51 <ikke> ah right
2025-06-20 19:35:50 <orbea> i like that idea
2025-06-20 19:36:05 <valerius> that might be the future of compatibility with the existing X ecosystem
2025-06-20 19:36:50 <valerius> surely other people are thinking about the same thing, just a matter of someone whipping out the text editor to make it happen
2025-06-20 19:37:20 <Ariadne> i guess technically Xwayland is about 90% of what you would need, but you need it to go both ways
2025-06-20 19:37:30 <Ariadne> so wayland clients can be managed by the X window manager
2025-06-20 19:38:04 <f_> you can get close by running e.g. weston inside your X11 .. but that's not letting your X11 manage those
2025-06-20 19:38:06 <kapad> so, out of `linux wars`, is there actually an official Xorg development tree by Xorg foundation, or is over/done/end ?
2025-06-20 19:38:14 <f_> There is
2025-06-20 19:38:29 <orbea> it still exists and it still gets commits and even tags, but there is not heavy development
2025-06-20 19:38:38 <Ariadne> anyway my ask is simply: please do not burden the alpine security team with having to track differences between X.org and reactionary forks with no real maintenance plan
2025-06-20 19:38:42 <Ariadne> :P
2025-06-20 19:38:45 <kapad> ok! thanks.
2025-06-20 19:38:47 <orbea> and there is a lot of legacy baggage that is hard to identify and clean up
2025-06-20 19:39:20 <Ermine> devuan people have tried to patch x to support seatd
2025-06-20 19:39:36 <orbea> i wish this would be upstreamed
2025-06-20 19:40:42 <Ariadne> kapad: X.org is uhh, i would say "barely maintained"
2025-06-20 19:40:54 <Ariadne> a fork with an actual plan focused around sustainability wouldn't be the worst thing
2025-06-20 19:40:55 <Ermine> I need to see if rootful xwayland + cage is viable
2025-06-20 19:40:59 <Ariadne> this one just ain't it
2025-06-20 19:45:24 <Ermine> The problem is that maintaining Xorg requires actual expertise in DRM/KMS and, more importantly, Xorg architecture, but all people with such expertise are doing Wayland now
2025-06-20 19:46:32 <kapad> Ariadne: but watch all the above discussion so much time, and forks are not considered as something possible and viable. ok, most negative talk was about xlibre, but to me seems Xorg is not a simple project to maintain in many aspects. not anyone can do it
2025-06-20 19:47:10 <Ariadne> kapad: correct, X is a difficult project to maintain, and failures can lead to reliability and security regressions
2025-06-20 19:47:25 <Ariadne> however, there is a path to a sustainable fork of X
2025-06-20 19:47:45 <Ariadne> that would involve forking only the generic components
2025-06-20 19:48:06 <Ariadne> this is still not easy to do, but forking a subset is more likely to succeed
2025-06-20 19:49:58 <ikke> Just tried wayland (with sway) for the first time
2025-06-20 19:50:28 <Ermine> Xorg + -modesetting + -libinput and hopefully that works
2025-06-20 19:52:20 <Ermine> (but i'm repeating what other people said)
2025-06-20 19:53:24 <kapad> ACTION i use openbox, plus a pannel of lx or xfce4. thats my setup, i really need nothing else from a gui
2025-06-20 20:43:24 <ikke> Anyone got flameshot to work under sway?
2025-06-20 20:45:54 <xe> Hey I'm thinking about doing a bit, would you accept an alpine mirror at the domain probably-not-malware.lol?
2025-06-20 20:46:57 <craftyguy[m]> totally not a suspicious domain 😂
2025-06-20 20:51:45 <xe> incredibly normal domain tbh
2025-06-20 20:53:04 <Ariadne> #alpine-infra for mirrors :)
2025-06-20 21:13:19 <xordspar0> Can anyone think of a reason why a package like community/glfw wouldn't have a debug symbols package? Can I make an MR to add it?
2025-06-20 21:13:25 <xordspar0> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/glfw/APKBUILD
2025-06-20 21:18:25 <craftyguy[m]> go for it. it probably isn't there because no one has cared to add it... until now/you :P
2025-06-20 23:18:59 <jvvv> ikke: i tried flameshot w/ sway: 'flameshot screen -n 0 ss.png' .. https://tpaste.us/9X8Z and just plain 'flameshot' .. QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
2025-06-20 23:21:37 <jvvv> i tried 'export XDG_CURRENT_DESKTOP=sway', then flameshot just hangs until ^C
2025-06-21 02:02:21 <xordspar0> craftyguy[m]: Thanks for the encouragement :) !85926
2025-06-21 06:34:46 <realroot[m]> <Ariadne> "X.Org was forked by people..." <- xlibre dev is the most active. what are other forks?
2025-06-21 06:34:46 <realroot[m]> <psykose> "are you pretending to be..." <- what do you mean
2025-06-21 06:35:02 <Ariadne> we're not doing this
2025-06-21 06:35:17 <ikke> Yes, please stop
2025-06-21 06:35:37 <Ariadne> besides, i am working on a better solution to this problem as we speak
2025-06-21 06:35:52 <realroot[m]> can't I know this other better forks?
2025-06-21 06:36:16 <Ariadne> they don't exist, because nobody wants to maintain a legacy graphics stack
2025-06-21 06:37:48 <Ariadne> however, i am working on an extremely simple wayland compositor that is essentially only useful for running Xwayland as a rootful server (e.g. it speaks just enough wayland to give surfaces to Xwayland for drawing). this allows for running X11 environments without full Xorg.
2025-06-21 06:39:39 <Ariadne> this is particularly nice because it allows fully de-privileging the X server
2025-06-21 06:39:57 <jvvv> nice!
2025-06-21 06:41:12 <realroot[m]> so if someone stiil wants to run improved x11 with xnamespace etc, they cannot cause you do not want it.
2025-06-21 06:41:53 <Ariadne> what is "xnamespace"
2025-06-21 06:42:11 <realroot[m]> it's to aboiv keylogger
2025-06-21 06:42:15 <realroot[m]> *avoid
2025-06-21 06:42:27 <realroot[m]> isolating windows
2025-06-21 06:42:50 <Ariadne> i have no objection to this feature as long as it is supplied as part of freedesktop X server
2025-06-21 06:43:06 <Sheila> this is some xlibre meme, afaict
2025-06-21 06:43:12 <Ariadne> or any other X server that has a viable maintenance plan
2025-06-21 06:43:33 <Sheila> the only other 'xnamespace' I was able to find is C# or XML, and thus not relevant.
2025-06-21 06:43:40 <Ariadne> hence why i ask
2025-06-21 06:43:58 <Ariadne> also, can you not use Xnest in rootless mode to accomplish the same goal?
2025-06-21 06:44:40 <realroot[m]> if you ask me idk
2025-06-21 06:45:02 <Ariadne> (you can. you definitely can.)
2025-06-21 06:46:13 <Ariadne> i would be skeptical of anything that uses namespace-based virtualization (the design primitive, not the linux feature) to protect X sessions, personally
2025-06-21 06:46:43 <Ariadne> it is better to use Xnest to isolate the untrusted process in a separate X server entirely
2025-06-21 06:47:29 <realroot[m]> i have no idea of how that works maybe namespace it's just the name
2025-06-21 06:47:50 <Ariadne> i looked at the patches
2025-06-21 06:48:07 <Ariadne> admittedly a glance, but it's just protocol-based namespace separation
2025-06-21 06:48:22 <Ariadne> it's not a robust security boundary
2025-06-21 06:50:52 <Ermine> Ariadne: there's cage compositor that seems to fit the bill
2025-06-21 06:51:12 <Ariadne> i already wrote one with wlroots
2025-06-21 06:51:40 <Ariadne> though we also need the reverse: a wayland to X11 proxy
2025-06-21 06:52:04 <Ariadne> then you'll be able to manage wayland clients as if they were traditional X clients too
2025-06-21 06:53:16 <Ermine> oh, hypothetical waylandX is a meme at fdo discord
2025-06-21 06:53:28 <Ariadne> excellent
2025-06-21 06:54:44 <Ariadne> anyway this compositor is entirely useless as an actual wayland compositor. it provides just enough wayland to run Xwayland, and then spawns xinitrc with WAYLAND_DISPLAY unset
2025-06-21 06:56:42 <jvvv> is this something that might be available for testing in the next year or so?
2025-06-21 06:56:49 <Ariadne> tomorrow
2025-06-21 06:56:55 <jvvv> oh, wow
2025-06-21 06:56:57 <Ariadne> there's a couple of finishing touches i want to do
2025-06-21 06:57:01 <Ariadne> i wrote it tonight
2025-06-21 06:57:09 <jvvv> very cool
2025-06-21 06:57:10 <Ariadne> after proposing it here this afternoon :D
2025-06-21 06:58:07 <Ermine> though xwayland part would probably need some adjustments as well
2025-06-21 07:12:24 <Ariadne> Ermine: it will, especially for multihead, but i believe this to be a much more viable path to keeping X desktop environments working
2025-06-21 07:13:50 <Ariadne> it is certainly more aligned with alpine design ideology
2025-06-21 07:14:05 <Ermine> it is, and that's what wayland folks were talking about
2025-06-21 07:18:28 <Ermine> but i mean, i've tested sway (in minimal configuration) + rootful xwayland, and it 1) selects incorrect default mode, and 2) when its mode doesn't match output mode set by sway, xwayland stretches stuff, and does that poorly
2025-06-21 07:20:57 <Ariadne> those are just bugs, and they can be fixed ;)
2025-06-21 07:21:35 <Ariadne> though i do not see that with Xwayland -fullscreen here
2025-06-21 07:22:41 <Ermine> i've tried -fullscren. Maybe they have changed something in meantime, in which case, great
2025-06-21 13:32:53 <Ermine> https://groups.google.com/a/chromium.org/g/chromium-dev/c/v-WOvWUtOpg
2025-06-21 13:34:03 <ikke> lnl: ^
2025-06-21 17:20:34 <skarnet> when you're out of ideas about what to do to keep downstream annoyed, change the build system!
2025-06-21 17:29:09 <craftyguy[m]> It's google, they don't care about downstream
2025-06-21 17:29:34 <quinq> AI-driven project decisions
2025-06-21 17:43:33 <Saijin_Naib[m]> I think "they dont care" is accurate enough 😭
2025-06-21 19:31:25 <lnl> Ermine: I see siso as a non-change since it's supposed to be more strict ninja, and we never even used real ninja in the first place. Though I haven't tested yet
2025-06-21 19:33:07 <Sheila> still puzzled over 'like ninja but with remote exec capabilities', which is a little bit of a horror.
2025-06-21 19:33:27 <ikke> RCE as a service
2025-06-21 19:34:17 <lnl> It's just yet another Chromium distcc
2025-06-21 22:22:09 <f_> craftyguy, they did care enough to say "heya we have more work for you! :3"
2025-06-22 06:47:09 <el[m]1> <dalias> "i doubt any of it affects alpine..." <- polkit seems to be a required unremovable dependency for plasma at least on postmarketOS, so that's probably going to be a lot of people who have polkit installed
2025-06-22 06:55:05 <el[m]1> it seems liek it's a dependency for phosh on postmarketOS as well
2025-06-22 07:42:54 <sewn> Ariadne: have you seen xwayland-satellite
2025-06-22 07:50:51 <Sheila> it's not rootful, so it wouldn't help.
2025-06-22 15:20:57 <invoked> Ermine: sounds like what they really wanted to do was go into bazel but instead of doing that, they just made another build tool
2025-06-22 15:24:36 <Ermine> google being google, nothing new
2025-06-22 15:26:19 <craftyguy[m]> @el IIUC you have to enable some deprecated option in PAM that's disabled by default, and I don't think we do that.
2025-06-23 14:43:15 <Habbie> is strophy in here?
2025-06-24 07:47:48 <Saijin_Naib[m]> Is anyone able to assign Guy Godfroy to !16902
2025-06-24 07:48:13 <Saijin_Naib[m]> QuodLibet media player is missing fsnative from senf python package, so we need a new aport to provide py3-senf
2025-06-24 07:52:53 <ikke> I guess you meant #16902
2025-06-24 08:14:34 <Saijin_Naib[m]> Yeah, sorry, haha
2025-06-24 08:15:04 <Saijin_Naib[m]> We are also backlevel a few releases, but I just setup the release-monitoring mapping so hopefully Guy is notified of that
2025-06-24 08:16:55 <Saijin_Naib[m]> Thanks for adding them, ikke
2025-06-24 09:20:08 <roxedus> Seems like the renewed interest from OSWAP re modsecurity is going strong, is the norm to bump existing issues like #9418, or is creating a new one preferred?
2025-06-24 09:36:59 <ikke> roxedus: we have no issues with bumping old issues. Having another open issue for the same thing just clutters things
2025-06-24 12:02:39 <Kladky> messagelib seems to have the 3.22 builder stuck since 04:xx
2025-06-24 12:02:42 <Kladky> https://build.alpinelinux.org/buildlogs/build-3-22-x86_64/community/messagelib/messagelib-25.04.2-r0.log
2025-06-24 12:03:35 <Kladky> it mentions that "caught signal 15", so im not sure if its just an OOM that will fix itself, or if tests just need to be disabled for now
2025-06-24 12:10:26 <ncopa> maybe we need to back port 8236a134a972b192188368369c263579b97fa920
2025-06-24 12:15:26 <ncopa> PureTryOut: can you please try follow up the messagelib build failure on 3.22-stable?
2025-06-24 12:59:55 <liske> ncopa: to get #17283 fixed in 3.22 - need I wait for alpine-conf!258 + release or should I open a PR on aports adding the patch for the regression?
2025-06-24 13:18:18 <ncopa> liske: best would be if we could wait til its merged upstream in alpine-conf and after that we backport patch to edge and 3.22-stable.
2025-06-24 13:41:56 <Kladky> ncopa: it's just loongarch and x86_64 failing /w messagelib, not aarch64
2025-06-24 13:47:06 <Kladky> Also PureTryOut, consider cranking up your project timeout, so you can see the full build process and catch these issues before they get merged
2025-06-24 13:47:24 <Kladky> mine is currently at 1 day, as opposed to your current 6 hours
2025-06-24 17:05:57 <achill> <Kladky> mine is currently at 1 day, as opposed to your current 6 hours
2025-06-24 17:05:57 <achill> mine is a 30days since i kept hitting the limit :p
2025-06-24 17:07:16 <Kladky> I don't even want to think about how there could be a (set of) package(s) that take over a day to build 😵💫
2025-06-24 17:08:20 <achill> i'm not sure what it was or what i had beforel. maybe it was some ffmpeg rebuild or something idk
2025-06-24 17:51:34 <craftyguy[m]> sertonix: fyi I'm resolving threads in that abuild MR but making changes in fixup commits locally and will push once I have a chance to test things out a bit to make sure these changes aren't causing regressions
2025-06-25 03:02:03 <Saijin_Naib[m]> Whoever made apkbuild-pypi, thank you so much!
2025-06-25 04:13:12 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86066
2025-06-25 04:13:36 <Saijin_Naib[m]> Can Guy Godfroy get assigned to this as well? I've opened an MR for py3-senf, so to get things rolling a bit
2025-06-25 04:13:48 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86065
2025-06-25 05:24:22 <indy> ncopa, ptrc !70554
2025-06-25 11:39:27 <Kladky> cause of bystander effect: !86078
2025-06-25 11:44:27 <f_> 7104
2025-06-25 11:44:30 <f_> oops
2025-06-25 11:45:40 <Kladky> Seems CI is failing cause it depdends on other packages to be upgraded, which they have, but the builds aren't avilable cause builds are failing
2025-06-25 11:46:16 <Kladky> Not too sure what to do abt that...
2025-06-25 11:46:47 <achill> yeah someone can just merge it without the ci succeeding
2025-06-25 11:47:17 <achill> you could add a rebuild commit to your MR but its pointless i guess
2025-06-25 11:48:28 <Kladky> Yea, that's what I was thinking
2025-06-25 11:48:49 <ikke> Changing anything in the APKBUILD, even whitespace, would trigger the packages to be built in CI
2025-06-25 11:49:13 <ikke> But, not really a good idea
2025-06-25 11:49:37 <Kladky> Actually, do I even need to bump the pkgrel?
2025-06-25 11:50:08 <Kladky> Since this just fixes builds, hence pkgrel=0 version has never been built
2025-06-25 11:50:24 <ikke> Correct, it doesn't
2025-06-25 11:50:35 <Kladky> Too late, oh well
2025-06-25 11:50:39 <Kladky> Not a big deal
2025-06-25 11:50:51 <achill> yeah :)
2025-06-25 12:21:29 <Kladky> Why does it seem the x86_64 builder isn't even trying to pull from git?
2025-06-25 12:21:49 <Kladky> I mean, surely 30 mins is enough time
2025-06-25 12:22:08 <Kladky> loongarch64 has pulled from git and has built the fix
2025-06-25 12:22:22 <Kladky> So does anyone know why x86_64 hasn't?
2025-06-25 12:31:29 <achill> the builder is still building
2025-06-25 12:36:18 <Kladky> x86_64 doesn't seem to be
2025-06-25 12:36:26 <Kladky> its latest log is from 2 days ago
2025-06-25 12:36:32 <Kladky> which is messagelib
2025-06-25 12:36:48 <Kladky> but for some reason, it hasnt seemed to register it as a failure
2025-06-25 12:37:07 <Kladky> at least, not in the "last error" column
2025-06-25 12:37:09 <achill> hmm then i guess down or stuck
2025-06-25 12:37:16 <lotheac> x86_64 build worked fine for me 1h ago https://gitlab.alpinelinux.org/lotheac/aports/-/jobs/1908495
2025-06-25 12:37:54 <Kladky> im talking about build.a.o, not the gitlab CI
2025-06-25 12:37:59 <Kladky> lotheac
2025-06-25 12:38:01 <lotheac> okay, my mistake
2025-06-25 12:40:23 <Kladky> #alpine-infra
2025-06-26 01:29:55 <sertonix[m]> Alpine x86 isn't compatible with AMD Geode 😢
2025-06-26 01:48:29 <quinq> It was in the good old days
2025-06-26 02:35:23 <feespay[m]> Get in touch with this platform for greatness you’ll definitely thank me later... (full message at <https://matrix.org/oftc/media/v1/media/download/AVe-vBBfM-gp0BFVpBOVvCqmksCb6wBnNjMcaxi37B2u6y_JliwM6sDunrzD110bDMFWM_MuISF6irD_eTb_-oVCeX8jAJQwAG1hdHJpeC5vcmcvU3dWUVpuZWF4bEZsYmtYTnB0b1diRUpw>)
2025-06-26 08:12:01 <krystianch> could someone please merge !82861 ? it's testing but libcamera update broke this package
2025-06-26 08:20:38 <krystianch> thanks Patrycja!
2025-06-26 11:47:11 <ikke> gitlab will be upgrade to 17.11 at 12:00 UTC (in about 15 minutes) and will be briefly unavailable
2025-06-26 12:10:55 <ikke> gitlab is back and upgraded
2025-06-26 12:14:01 <fabricionaweb> Congratulations fossdd
2025-06-26 12:14:25 <achill> thanks!
2025-06-26 12:53:05 <Kladky> idk how I only just realised that you're fossdd lol
2025-06-26 12:53:54 <Kladky> actually, don't you usually use the matrix bridge?
2025-06-26 12:54:01 <Kladky> that's probably why
2025-06-26 12:55:46 <achill> i am! just using the postmarketos bridge since the matrix bridge is completely unreliable and here i know the infra team and can annoy them :)
2025-06-26 12:59:28 <f_> sshhhhh
2025-06-26 12:59:32 <f_> call it a bouncer not a bridge
2025-06-26 12:59:33 <f_> :P
2025-06-26 13:00:44 <f_> (Imo the pmos bridge is way less noticeable too! As you can see you didn't even notice achill was still using a bridge :p)
2025-06-26 16:36:44 <donoban> entre las 12:19
2025-06-26 16:37:00 <donoban> (ouch wrong window) :\
2025-06-26 17:49:11 <Saijin_Naib[m]> Que hicistes a las 12:19? 👀
2025-06-26 17:55:10 <donoban> 😮
2025-06-26 17:55:30 <donoban> ACTION can't see emojs here lol
2025-06-27 08:08:33 <Habbie> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86005 was about dnsdist tests failing on riscv64 but the simpler story now appears to be 'our LMDB build does not work on riscv64'
2025-06-27 08:09:12 <Habbie> (our = alpine)
2025-06-27 08:10:33 <Habbie> in fact `abuild -r` in main/lmdb also fails check()
2025-06-27 08:11:28 <Habbie> but there is a package in the apk repo so somebody managed to build&test it successfully before
2025-06-27 08:30:51 <Habbie> are the gitlab riscv64 runners real, or qemu?
2025-06-27 09:41:09 <achill> they are real, and really slow
2025-06-27 09:41:21 <Habbie> ok
2025-06-27 09:41:48 <Habbie> the lmdb failure above has so far been reproduced in qemu alpine, qemu debian 13, and on the gitlab runners. it does not reproduce in debian 12 on a real board
2025-06-27 09:41:51 <achill> afaik they are milk-v pioneers
2025-06-27 09:42:23 <achill> Habbie: classic riscv64 annoyance
2025-06-27 09:42:31 <Habbie> i bet
2025-06-27 17:15:21 <Ariadne> apropos to nothing, can someone from the CoC team lock https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86092? thanks
2025-06-27 18:55:43 <elagost> Ariadne did you ever put out that wayland compositor that just runs startx under xwayland? That sounded like a really cool idea.
2025-06-27 19:10:17 <Ariadne> elagost: i've been busy with more urgent things, but hope to release it soon
2025-06-27 19:17:18 <Saijin_Naib[m]> In theory, that could put XFCE under wayland before they finish their own work with labwc, right? Because that sounds so cool
2025-06-27 19:24:15 <abby> yes, we've done that on void for the asahi iso
2025-06-27 19:31:34 <Saijin_Naib[m]> Oh, freaking sweet! And I can keep xfwm and other components in place‽
2025-06-27 19:33:36 <Ariadne> that is the idea
2025-06-27 19:33:50 <Ariadne> essentially a backwards compatibility layer for X
2025-06-27 19:35:37 <abby> oh, i misread
2025-06-27 19:35:48 <abby> we used labwc with xfce on void asahi
2025-06-27 19:39:30 <elagost> That's awesome, don't mean to press you on it, it just sounds neat.
2025-06-27 19:40:17 <Ariadne> anyway my position essentially breaks down to "can we ask the alpine security team to endure content which violates alpine's code of conduct to do their work of security maintenance in alpine?"
2025-06-27 19:40:23 <Ariadne> and my position is "no"
2025-06-27 19:57:00 <elagost> yeah the xlibre thing really looks like the audacity and gimp forks that appeard a while back. they were essentially one-person efforts and fizzled out after a while. Best not to pay attention to it for a while yet.
2025-06-27 19:59:11 <Sheila> the difference is that the gnu imp and audacity forks had actual work they wanted to get done and the technical means to do it, just not the community support. xlibre is the opposite of that and the person in charge is an ignoramus who's going to drop it in a few months once he realises this is hard. (he has a whole pattern, so I wouldn't bet money on it.)
2025-06-27 20:02:59 <elagost> fair enough. I think forking would be reasonable if it had been, say, a full year or two with zero commits or activity from any maintainers at all, but I don't think xorg is in that state yet. Still very much "maintenance mode", but not fully dead yet.
2025-06-27 20:14:50 <pj> if it's "so dead" then how it got merged commits from that xlibre dude to the point where they reverted heavy amounts of them
2025-06-27 20:14:51 <Saijin_Naib[m]> Plus Glimpse did fill a need. I couldnt get GIMP approved at a small/local govt for usage because the branding was a slur
2025-06-27 21:41:34 <Habbie> achill, i have a rude question. are you -sure- all riscv64 builders are real hw? because between the 6 datapoints i have now about lmdb working or not working, alpine gitlab is the outlier that would be explained by "oh turns out it's qemu". but i could very well be wrong
2025-06-27 21:42:17 <achill> i could be wrong, i guess its better to ask in #alpine-infra