2025-05-01 01:02:54 <Asmadeus> I just got reminded about !82146 by stalebot -- would be great if someone could have a look/merge this when time allows. Thanks!
2025-05-01 04:23:35 <ikke> https://setuptools.pypa.io/en/latest/history.html#v80-1-0
2025-05-01 08:32:42 <witcher01> i'm trying to package something for alpine and it needs angular to compile part of the application. how is something like that handled in alpine? i couldn't find an angular package; should I just have (p)npm as a makedep and install angular/cli?
2025-05-01 08:33:44 <witcher01> upstream provides an already compiled tarball but I'd rather build from source
2025-05-01 09:42:28 <Habbie> gitlab runners are looking somewhat unhappy
2025-05-01 09:42:36 <Habbie> have had to restart three jobs today
2025-05-01 10:19:36 <ikke> hmm
2025-05-01 10:19:42 <ikke> Habbie: what kind of errors?
2025-05-01 10:21:33 <Habbie> https://gitlab.alpinelinux.org/Habbie/aports/-/jobs/1829352
2025-05-01 10:23:55 <ikke> That issue has been fixed already
2025-05-01 10:24:06 <Habbie> i now see that the failures were from yesterday, sorry
2025-05-01 10:27:05 <ikke> np
2025-05-01 11:42:58 <mid> Hi all, for a personal project I made 2 MRs, one 2 years ago !41484 and another last days !83479 . They both have been problematic for 2 different (good) reasons as stated by ncopa for the former and Jakub for the latter. I'd like to know if there could be other eyes to have a look at them to try to find a satisfying solution because 1) I'd like to use mainstream Alpine packages, of course but also 2) I'm sure there are other people 
2025-05-01 11:42:58 <mid> encountering the same issues. I tried to think and rethink but to no avail 😞 Of course I'd be happy to explain more the (different) 2 problems if asked, they are both related to packaging / dependencies in Alpine
2025-05-01 11:51:08 <mid> FWIW this personal project will be released with a Free license, later. That's why the need for "official" Alpine packages is relevant
2025-05-01 15:53:11 <candrews> Can someone please take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81925 ? I submitted it 5 weeks ago and haven't heard anything
2025-05-02 06:51:40 <Saijin_Naib[m]> I am stuck on !83090, and asking for help or for someone more knowledgeable to pick it up at this juncture
2025-05-02 07:01:14 <ikke> Not really something I can help with, but try to look in the meson build files how / where it tries to look for that header file versus where it's located
2025-05-02 10:15:40 <ikke> ncopa: fyi, gitlab built with grpc 1.71, though still have to test it
2025-05-02 10:18:24 <ncopa> 👍
2025-05-02 10:18:46 <ncopa> PureTryOut: can you please follow up the 3.21 amrhf build? its over a week now that it is stuck
2025-05-02 10:18:49 <ncopa> current error is
2025-05-02 10:19:06 <ncopa>   Version 6.8.2 of package Qt6QuickTest was requested but an incompatible
2025-05-02 10:19:06 <ncopa>   version was found: 6.8.0.  You can pass -DQT_NO_PACKAGE_VERSION_CHECK=TRUE
2025-05-02 12:25:43 <ncopa> looks like there are a lot of packages that needs to be disabled on armhf due to the missing qt6-qtdeclarative
2025-05-02 12:25:55 <ncopa> $ grep qt6-qtdeclarative */APKBUILD | wc -l
2025-05-02 12:25:55 <ncopa> 227
2025-05-02 13:02:21 <andypost[m]> I can't get why one test still fails but it should unblock builders at least !83560
2025-05-02 13:03:10 <andypost[m]> somehow 3.22 arm stuck on it
2025-05-02 13:18:56 <fossdd|m> ncopa: a lot of them are already disabled on armfh
2025-05-02 13:22:18 <ncopa> still build-3-21-armhf has been broken for a week
2025-05-02 13:22:41 <ncopa> i mean, breakages can happen. we try to avoid but is okish - in edge
2025-05-02 13:22:55 <ncopa> for stable branches we should be more careful
2025-05-02 13:23:00 <fossdd|m> they are disabled in edge but not in 3.21
2025-05-02 13:23:12 <fossdd|m> yes but qt has always been broken on armhf
2025-05-02 13:23:12 <ncopa> thats a problem
2025-05-02 13:23:47 <fossdd|m> and upstream doesnt care and neither we or they have the time to fix that
2025-05-02 13:24:07 <fossdd|m> and armhf is a dead platform anyway. if someone was using qt on armhf, i'd be wondered
2025-05-02 13:51:22 <ncopa> Rpi zero
2025-05-02 13:53:00 <ncopa> ptrc: can you help with webkit2gtk? The 32 bit can be solved by setting -g0
2025-05-02 13:53:25 <ncopa> And maybe do the 4 and 6 api in different MRs
2025-05-02 14:07:07 <ptrc> ikke: https://ptrc.gay/GMjmlZwK
2025-05-02 14:07:19 <ptrc> ncopa: sure, i'll take a look at it in a second
2025-05-02 14:07:28 <ptrc> been procrastinating too long on fixing webkit, really
2025-05-02 14:07:54 <ikke> ptrc: interesting, what pipeline?
2025-05-02 14:07:58 <ikke> / mr
2025-05-02 14:08:00 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1832799
2025-05-02 14:11:03 <ikke> Apparently it could not determine a merge base because it was too far away
2025-05-02 14:11:13 <ptrc> oh, huh
2025-05-02 14:11:26 <ikke> It fetches 500 commits
2025-05-02 14:11:42 <ikke> Before you rebased it I saw >1000 commits
2025-05-02 14:13:23 <ptrc> yeah, i rebased it against the mesa 25 MR
2025-05-02 14:13:34 <ptrc> ( !80291 )
2025-05-02 14:13:39 <ptrc> but there, the pipeline works..?
2025-05-02 14:14:16 <ikke> The MR only shows 1 commit
2025-05-02 14:14:29 <ikke> the other appeared to merge in >1000 commits
2025-05-02 14:14:33 <ptrc> ohhhhhhh
2025-05-02 14:14:42 <ptrc> i suppose i messed up the rebase
2025-05-02 14:15:15 <ptrc> ah, yes, it was (mesa 25) - (all of master) - (mesa-img)
2025-05-02 14:15:19 <ptrc> welp, thanks
2025-05-02 15:37:11 <ikke> gitlab will be upgraded at 16.00 UTC and will be briefly unavailable
2025-05-02 15:43:33 <quinq> Good luck :)
2025-05-02 15:48:32 <f_> ^ #hugops
2025-05-02 16:06:28 <ikke> It's back :)
2025-05-02 16:13:53 <f_> Nice
2025-05-02 19:12:57 <Xe> fossdd: I think you're shipping broken Anubis packages, you don't build the JavaScript/CSS assets on build. You probably want to use this source tarball instead: https://github.com/TecharoHQ/anubis/releases/download/v1.17.1/anubis-src-vendor-npm-1.17.1.tar.gz that includes the vendored go dependencies and pre-runs the `npm run assets` step for you.
2025-05-02 20:29:39 <fossdd|m> Xe: thanks! !83624 should fix that. i also added a openrc service, but i just lightly tested it
2025-05-02 20:44:34 <Xe> fossdd|m: i'm not familar with openrc, but does the /etc/conf.d/anubis get run and exported in the environment where anubis runs it?
2025-05-02 20:47:42 <ikke> Not exported automatically, it gets sources for the init.d script
2025-05-02 20:47:49 <ikke> gets sourced*
2025-05-02 21:30:26 <henrix> I was trying to update a python package (zim) but unfortunately an issue in py3-setuptools makes the package unnusable
2025-05-02 21:30:43 <henrix> the setuptools issue is still unsolved: https://github.com/pypa/setuptools/issues/4934
2025-05-02 21:31:29 <henrix> shall I just wait for it to be fixed? or can the setuptools be reverted?
2025-05-02 21:31:48 <henrix> (I suspect reverting https://github.com/pypa/setuptools/commit/c71266345c64fd662b5f95bbbc6e4536172f496d should fix it, but I haven't tried that)
2025-05-02 21:32:06 <fossdd|m> i'd rather wait for a proper fix before downgrading/reverting
2025-05-02 21:32:44 <henrix> fossdd|m: ack, thanks.
2025-05-03 01:57:14 <craftyguy[m]> uh oh, apk is trying to pull in mesa-asahi on my laptop that is definitely not using anything asahi/mac related
2025-05-03 01:57:32 <craftyguy[m]> https://bpa.st/5IJQ
2025-05-03 01:57:43 <craftyguy[m]> did someone goof up provides= or something recently?
2025-05-03 01:58:01 <craftyguy[m]> 
ACTION can debug later, has to go now though

2025-05-03 01:58:15 <ptrc> oh, some things in world depends on mesa-osmesa
2025-05-03 01:59:07 <ptrc> for me, it's openscad -> glu -> osmesa
2025-05-03 02:00:23 <ptrc> i can fix that one, i suppose
2025-05-03 02:13:17 <psykose> you should !check the nix on aarch64 so it can actually upload community/
2025-05-03 03:29:46 <craftyguy[m]> prtc: ah, and I guess osmesa was dropped in the v25.0 upgrade, so what's why the older mesa-asahi was pulled in (because it still has osmesa) ?
2025-05-03 03:30:09 <craftyguy[m]> s/prtc/ptrc/
2025-05-03 03:31:05 <psykose> yea
2025-05-03 03:32:37 <craftyguy[m]> Is the fix to just remove all depends on osmesa from stuff in aports, or have mesa provides=mesa-osmesa? (even though it technically doesn't 😅)
2025-05-03 03:35:26 <psykose> former
2025-05-03 10:16:37 <tokyovigilante> Hi, I'm trying to package a library that uses sphinx to build HTML docs from RST, but on non-x86-64 platforms the pipeline is failing with     clang.cindex.LibclangError: Error loading shared library libclang.so: No such file or directory.
2025-05-03 10:16:56 <tokyovigilante> I have specified clang, clang-libs and clang-libclang as makedepens
2025-05-03 10:17:38 <tokyovigilante> https://gitlab.alpinelinux.org/tokyovigilante/aports/-/pipelines/321577
2025-05-03 11:18:27 <rhizoome> tokyovigilante: the library tries to compile these python modules during creation of the docs, which is imo against packaging policies. I would try to convince that package to use a system sphinx. Maybe it is as simple as adding sphinx to the make depends and remove virtualenv.
2025-05-03 20:50:34 <tokyovigilante> rhizoome: thanks, will give that a try
2025-05-03 21:30:00 <tokyovigilante> ah yup, that worked locally, thanks!
2025-05-03 21:39:40 <tokyovigilante> hmm, still failing pipeline on other platforms though.
2025-05-03 21:58:12 <rhizoome> tokyovigilante: it seems like system sphinx has the same problem. but in the past sphinx had nothing to do with clang, expect of course if you were compiling it with clang, which alpine doesn't do.
2025-05-03 22:00:03 <rhizoome> tokyovigilante: I was wrong, this shows that it again installed something into a venv: env/lib/python3.12/site-packages/clang/cindex.py (lets see if alpine has that as a package)
2025-05-03 22:01:03 <rhizoome> tokyovigilante: yes. it is called py3-clang20. https://pkgs.alpinelinux.org/contents?file=cindex.py&path=&name=&branch=edge&repo=&arch=x86_64
2025-05-03 22:02:05 <rhizoome> tokyovigilante: as long as the package tries to compile this it wont work. this has many patches to work on alpine: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/clang20
2025-05-03 22:34:02 <rhizoome> I left a longer description on the issue.
2025-05-03 23:27:34 <tokyovigilante> thanks for reviewing, will take another look. sorry not very familiar with sphinx and was just following the build instructions from upstream.
2025-05-03 23:34:17 <Ermine> fossdd: do you mind taking over py3-setuptools maintainership? You're the one pushing updates anyway, and i'm out of bandwidth currently
2025-05-04 03:13:14 <andypost[m]> setuptools need some love for sure
2025-05-04 13:10:52 <fossdd> Ermine: sure, thanks for taking care of it
2025-05-04 13:13:27 <fossdd> added a commit to my py3-setuptools upgrade mr
2025-05-04 13:16:55 <Ermine> fossdd: thx
2025-05-04 13:59:46 <WhyNotHugo> Any feedback for !82215?
2025-05-04 14:36:03 <andypost[m]> @fossdd looks like shebang solved 2 days ago https://github.com/pypa/setuptools/commit/87633dd06511eda9bf9d7bfc4acff1fbc401c39b /cc @mio
2025-05-04 14:36:21 <andypost[m]> is it safe to upgrade while 3.22 is building?
2025-05-04 14:40:01 <fossdd|m> i would think so
2025-05-04 15:04:44 <andypost[m]> or maybe add it as a patch?
2025-05-04 15:21:15 <f_> andypost[m]: FYI fossdd answered at 14:40 but since you're chatting from the Matrix.org bridge you can't see the message (due to bugs) https://irclogs.alpinelinux.org/%23alpine-devel-2025-05.log
2025-05-04 15:45:21 <andypost[m]> f_: ty
2025-05-04 16:05:43 <mio> andypost[m]: great, maybe a rebuild will do
2025-05-05 19:49:55 <pc_magas> Hello I made this Request: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79350 and I try to diagnose what's wrong with my commits upon it according to commets it seem that I need to do a single commit?
2025-05-05 19:50:05 <pc_magas> What I need to do in order to achieve this?
2025-05-05 19:50:39 <ikke> Was just responding to you, but helping you here is easier
2025-05-05 19:50:55 <ikke> If you look at the list of commits here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79350/commits
2025-05-05 19:51:30 <ikke> You see that the top one says: "Merge branch aports:master into master"
2025-05-05 19:51:47 <pc_magas> So I should not merge master with remote one?
2025-05-05 19:52:01 <pc_magas> and keep my man as is?
2025-05-05 19:52:06 <pc_magas> main*
2025-05-05 19:52:21 <ikke> pc_magas: for future merge requests, it would be easier to create a new branch instead of using master
2025-05-05 19:52:23 <pc_magas> sry my master branch
2025-05-05 19:52:35 <ikke> But yes, we do not use merge commits in aports
2025-05-05 19:53:17 <pc_magas> Ok so I could just make one named `mkdotenv` and place my changes here then re-make a new one
2025-05-05 19:53:35 <pc_magas> So in my case I can make a new repo from aports and place my changes here?
2025-05-05 19:53:42 <pc_magas> because it seems kinda stale
2025-05-05 19:53:43 <ikke> No need to create a new repo
2025-05-05 19:54:37 <ikke> First, make sure you have alpine/aports as a remote
2025-05-05 19:54:52 <ikke> git remote add upstream https://gitlab.alpinelinux.org/alpine/aports.git
2025-05-05 19:56:09 <pc_magas> OK
2025-05-05 19:56:35 <ikke> then, git fetch upstream
2025-05-05 19:57:10 <pc_magas> fetching
2025-05-05 19:58:48 <pc_magas> done
2025-05-05 19:59:31 <ikke> Ok, let's first try this: git rebase upstream/master
2025-05-05 20:00:41 <pc_magas> https://pastebin.com/XpwD0Bdy
2025-05-05 20:00:52 <pc_magas> Causes me a conflict
2025-05-05 20:00:59 <pc_magas> do a reset --hard?
2025-05-05 20:01:08 <ikke> git rebase --abort
2025-05-05 20:01:27 <pc_magas> done
2025-05-05 20:02:29 <ikke> let's do a different approacgh
2025-05-05 20:02:35 <pc_magas> I aborted the rebase
2025-05-05 20:02:47 <ikke> git reset --hard upstream/master
2025-05-05 20:02:59 <ikke> This will temporarily get rid of your changes
2025-05-05 20:03:15 <pc_magas> No permanantely unless I back it up first
2025-05-05 20:03:22 <ikke> It's still in git
2025-05-05 20:04:16 <ikke> pc_magas: after you did that, you can do: git cherry-pick ce23f67d1c1ed402e2be3f0aeffe93eb033fa246
2025-05-05 20:04:39 <f_> Git never forgets
2025-05-05 20:05:03 <pc_magas> Done both reset anc cherry-pick
2025-05-05 20:05:05 <pc_magas> and*
2025-05-05 20:05:13 <pc_magas> git push --force?
2025-05-05 20:05:27 <ikke> yes
2025-05-05 20:06:50 <pc_magas> Now I've released new versions of mkdotenv whilst I have one waiting for approval. How should approach it commit-wise?
2025-05-05 20:07:02 <pc_magas> The new versions is in my github
2025-05-05 20:07:04 <ikke> You can amend the commit with the new version and force push
2025-05-05 20:07:18 <pc_magas> OK
2025-05-05 20:09:44 <pc_magas> and once released upon testing I would need to follow the upgrade commit as COMMITSTYLE says right?
2025-05-05 20:10:01 <ikke> yes
2025-05-05 20:10:17 <skarnet> util-linux is failing one test (out of 331) on riscv, and only on riscv: lslocks/lslocks. Is it known? Should I do something special to make it pass? (it is blocking a MR I'm working on, I needed to rebuild util-linux because of a utmps change)
2025-05-05 20:10:38 <ikke> skarnet: haven't heard of it myself
2025-05-05 20:11:02 <skarnet> ikke: if you have the time and inclination to take a look: https://gitlab.alpinelinux.org/skarnet/aports/-/jobs/1838587/artifacts/file/logs/build-util-linux.log
2025-05-05 20:11:15 <skarnet> everything passes everywhere except that one thing on that one arch
2025-05-05 20:11:32 <skarnet> and I need to go to sleep so in any case I'll take a look again tomorrow
2025-05-05 20:11:53 <ikke> skarnet: We can also try to ping Meng Zhuo
2025-05-05 20:11:58 <ikke> has been active for riscv64
2025-05-05 20:15:49 <pc_magas> I am unable to forse push https://pastebin.com/u1kNpevc
2025-05-05 20:16:21 <f_> pc_magas: Try pushing to another branch
2025-05-05 20:16:37 <ikke> pc_magas: because it's protected, you need to explicitly allow force pushes
2025-05-05 20:16:46 <f_> master is protected by default, that's why you shouldn't create MRs merging your master to aports master
2025-05-05 20:16:53 <ikke> f_: pc_magas already has an MR for master
2025-05-05 20:16:59 <ikke> to update it, master would have to be updated
2025-05-05 20:17:10 <f_> alrighty.
2025-05-05 20:17:13 <f_> For next time then :)
2025-05-05 20:17:31 <ikke> pc_magas: can you try again?
2025-05-05 20:19:20 <pc_magas> ikke: I tried and could do it.
2025-05-05 20:20:11 <ikke> pc_magas: that looks better
2025-05-05 20:21:58 <pc_magas> For my APKBUILD I made some staging repository that allows me to create and test the `APKBUILD`: https://github.com/pc-magas/mkdotenv-alpine-staging
2025-05-05 20:22:43 <pc_magas> The idea is to use a staging Area where I can commit anc do any checks. Is there a way to run the linter there for `APKBUILD` before commit it back to aports>
2025-05-05 20:23:50 <pc_magas> My flow is that I haver a template upon apps' repository: https://github.com/pc-magas/mkdotenv/blob/master/alpinebuild/APKBUILD-template Then once local alpine is build I use staging area to prepare the APKBUILS for aports.
2025-05-05 20:24:16 <pc_magas> Then I place it upon aports and do if possible either a MR or update the branch.
2025-05-05 20:24:54 <pc_magas> And I want to run the linter and some `linting` fix scripts before submitting to apports? Is ther a way to run the linter locally?
2025-05-05 20:27:31 <ikke> pc_magas: apk add atools
2025-05-05 20:27:38 <ikke> atools-go
2025-05-05 20:27:53 <ikke> sorry, the program is called apkbuild-lint
2025-05-05 20:28:12 <pc_magas> @ikke: I am using makefile for building tbw
2025-05-05 20:29:04 <ikke> pc_magas: `cd "$builddir"` is redundant
2025-05-05 20:29:49 <ikke> at least, in the prepare, build, check and package functions
2025-05-05 20:31:06 <pc_magas> referring to this https://github.com/pc-magas/mkdotenv-alpine-staging/blob/master/APKBUILD
2025-05-05 20:31:13 <pc_magas> ?
2025-05-05 20:31:17 <pc_magas> ikke: 
2025-05-05 20:31:46 <ikke> !79350
2025-05-05 20:32:23 <pc_magas> Yes I would fix this. I already brewing a new APKBUULD file
2025-05-05 20:32:31 <pc_magas> APKBUILD file
2025-05-05 20:33:12 <ikke> fyi, I've left a review. On alpine, the architecture you want is x86_64
2025-05-05 20:33:16 <ikke> Now, nothing is built
2025-05-05 20:33:45 <pc_magas> Would fix it l8er
2025-05-05 20:33:57 <ikke> sure
2025-05-05 20:34:37 <f_> pc_magas: The "# Maintainer:" comment should be also filled with your name + email
2025-05-05 20:34:45 <f_> Doesn't have to be a real name, it can be your nickname.
2025-05-05 20:38:50 <f_> pc_magas: Consider also adding other arches in `$arch`, if possible
2025-05-05 20:39:54 <f_> And finally the `$license` should be either `GPL-3.0-only` or `GPL-3.0-or-later` (assuming your tool is some sort of GPL-3.0 license)
2025-05-05 20:40:04 <f_> It needs to be a valid SPDX license identifier
2025-05-06 10:38:52 <ncopa> i think mono deadlocks during build. no idea why
2025-05-06 10:39:06 <ncopa> fossdd|m: do you think you could have a look at that?
2025-05-06 10:40:10 <ncopa> i cheated on aarch64, where i manually built it
2025-05-06 10:40:18 <ncopa> but it appears to happen on arm* too now
2025-05-06 11:18:21 <ikke> bootstrapping openjdk21 on ppc64le
2025-05-06 11:32:56 <fossdd|m> ncopa: well id love to take a look but i have no idea how to debug this
2025-05-06 11:33:13 <fossdd|m> on CI everything went well
2025-05-06 11:33:45 <fossdd|m> i wonder why manually running abuild on the builder is any different that what buildrepo does
2025-05-06 11:34:54 <ikke> There's no tty
2025-05-06 11:36:11 <ncopa> im able to reproduce it on my dev lxc box
2025-05-06 12:46:36 <rhizoome> could somebody look at this !82560. over in alpine-linux somebody wanted to use it, but it is still broken.
2025-05-06 13:39:53 <ncopa> rhizoome: marked as draft?
2025-05-06 13:39:57 <ncopa> is it ready?
2025-05-06 14:41:50 <jvoisin> do I need to do anything to get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81582 reviewed/merged? aports-qa-bot nudged me
2025-05-06 15:20:56 <ncopa> jvoisin: merged. thanks!
2025-05-06 15:28:24 <jvoisin> <3
2025-05-06 15:51:29 <rhizoome> ncopa: got another review, then some runners were blocked. now it is ready !82560.
2025-05-06 19:53:48 <ikke> bootstrapping ghc on x86_64
2025-05-06 20:30:32 <craftyguy[m]> hmmm after upgading, there's a /deleteme/info directory on my system 😆
2025-05-06 20:58:36 <fossdd|m> yo can someone merge !82912?
2025-05-06 20:58:52 <fossdd|m> and maybe add !83054 to the 3.22 milestone
2025-05-06 21:00:49 <Ariadne> craftyguy[m]: from what package does it come?  apk info -W /deleteme/info ?
2025-05-06 21:35:31 <Arnavion> A bunch of *-cross-embedded in aports have --infodir=/deleteme/info
2025-05-06 21:37:44 <Arnavion> Ah I see, expected to be deleted in corresponding _install_subpkg()
2025-05-07 07:11:49 <ncopa> Service 'avahi-daemon.apk-new' needs non existent service 'dbus'
2025-05-07 07:11:49 <ncopa> Service 'polkit.apk-new' needs non existent service 'dbus' 
2025-05-07 07:11:49 <ncopa> Service 'avahi-dnsconfd.apk-new' needs non existent service 'avahi-daemon'
2025-05-07 07:12:17 <ncopa> some packages ends up creating .apk-new in /etc/init.d which makes no sense
2025-05-07 07:16:18 <ikke>  /q ncopa 
2025-05-07 08:17:35 <WhyNotHugo> Should /etc/init.d be a non-protected path?
2025-05-07 08:29:53 <fabricionaweb> will go 1.24 go to 3.21 ?
2025-05-07 08:30:10 <fabricionaweb> that question looks so wrong LOL
2025-05-07 08:32:43 <rhizoome> WhyNotHugo: Wouldn't that overwrite peoples changes in /etc/init.d? Today, I never edit files in /etc/init.d and only add new services if I need a change. But in the past I had edited services.
2025-05-07 08:34:29 <ikke> fabricionaweb: no
2025-05-07 08:36:48 <fabricionaweb> ok thanks
2025-05-07 08:56:51 <WhyNotHugo> rhizoome: that would overwrite them. i believe you're not supposed to edit those files, but used conf.d instead.
2025-05-07 08:58:50 <rhizoome> WhyNotHugo: I understand that now, but there are probably a lot of people out there, like me in the past, who did that, despite it being wrong.
2025-05-07 09:04:00 <fossdd|m> you can do that, you just have to make sure to run update-conf after upgrades
2025-05-07 09:08:22 <rhizoome> fossdd|m: that is unrelated to making /etc/init.d non-protected, right? or do I missunderstand somthing. If it is not protected update-conf can't do much.
2025-05-07 15:46:13 <iggy> that feels like a change that should be communicated in advance... I've certainly edited files in /etc/init.d and I can't imagine I'm the only one
2025-05-07 17:43:41 <sertonix[m]> iggy: This isn't a change. As far as I am aware it was always meant to be that way.
2025-05-07 17:50:00 <iggy> was it documented clearly? If not, that doesn't feel like a bugfix, it feels like a change
2025-05-07 18:01:00 <iggy> a concrete example that I have is that I have to change command_user for a certain init script... if the package manager starts overwriting my change to do that, I'm going to have to fix that init script every time I do package upgrades... and that's after something breaks and I have to go through the whole process of figuring out what is wrong and what the fix is
2025-05-07 18:18:17 <fossdd|m> thats why conf.d is used
2025-05-07 18:24:54 <ikke> Not everything can be set / overridden in conf.d
2025-05-07 18:28:29 <iggy> can you override command_user in conf.d? If so, that's... not clear (or documented anywhere that I've ever seen)
2025-05-07 18:29:07 <ikke> You cannot
2025-05-07 18:29:44 <ikke> conf.d is sourced before init.d, so if command_user is set, it overwrites conf.d
2025-05-07 18:30:30 <ikke> So it would already need to do something like command_user="${COMMAND_USER-default}"
2025-05-07 19:09:21 <maribu> I'm trying to reproduce a build issue on s390x locally. Upstream asked for the autogenerated headers in the bug report. I assumed the easiest would be to go with qemu, but the installed system is not booting (stuck at "loading drivers"). Is qemu the best workflow to reproduce issues when native hardware is not available? If so, is there a known working qemu command line for s390x?
2025-05-07 19:17:45 <rhizoome> maribu: have you tried https://github.com/multiarch/qemu-user-static ?
2025-05-07 19:28:36 <maribu> That is nice! Thx for the pointer :)
2025-05-08 06:01:18 <quinq> “Gajim 2.1.1 has been released” :>
2025-05-08 09:46:09 <bitblt> hello!
2025-05-08 09:46:41 <bitblt> ncopa: kind reminder for this package update https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/83659
2025-05-08 09:50:26 <bitblt> (the wlroots ci is needs the new pixman version for some new feature branches)
2025-05-08 09:51:35 <fossdd|m> ci failed because it couldnt resolve x.org
2025-05-08 09:51:39 <fossdd|m> i retried them now
2025-05-08 09:52:23 <bitblt> i'm not talking about the alpine ci, i'm talking about the freedesktop/wlroots ci
2025-05-08 09:52:44 <fossdd|m> yeah i know, but the alpine ci has to suceed that the MR can get merged
2025-05-08 09:52:51 <bitblt> ah yeah ofc
2025-05-08 09:53:03 <fossdd|m> (btw since you already have pixman as subproject couldnt you just use meson to build/install a newer pixman?)
2025-05-08 09:53:12 <fossdd|m> uhhh still wget: bad address 'www.x.org'
2025-05-08 10:03:26 <bitblt> yeah, but wlroots uses only latest stabled released dependencies in general
2025-05-08 10:36:09 <ncopa> bitblt: the CI fails, which is why i havent looked at it
2025-05-08 10:37:17 <ncopa> lto1: fatal error: target specific builtin not available
2025-05-08 10:37:20 <ncopa> on riscv64
2025-05-08 10:37:25 <bitblt> hmm I can resolve www.x.org fine, and only 2 jobs seem to be failing
2025-05-08 10:37:51 <bitblt> >>> ERROR: pixman: fetch failed
2025-05-08 10:37:51 <bitblt> wget: bad address 'www.x.org'
2025-05-08 10:38:07 <bitblt> Is this some temporary dns issue?
2025-05-08 10:38:59 <ncopa> dunno. the question has been raised in #alpine-infra
2025-05-08 10:40:58 <bitblt> fossdd|m: it seems that build-loongarch64 fails due to the x.org dns issue but build-riscv64 fails with `lto-wrapper: fatal error: cc returned 1 exit status`
2025-05-08 11:15:46 <bitblt> maybe it has something to do with this? https://www.phoronix.com/news/Pixman-0.46-Released
2025-05-08 11:16:46 <fossdd|m> possible
2025-05-08 11:25:08 <psykose> it's a gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812
2025-05-08 11:25:19 <psykose> you can disable lto on riscv to get around it
2025-05-08 11:32:55 <bitblt> fossdd|m: I see that the workaround is to pass -march=rv64gcv1p0 to link flags
2025-05-08 11:35:38 <psykose> that's not a valid workaround
2025-05-08 11:36:23 <bitblt> only for the riscv platform ofc
2025-05-08 11:37:14 <psykose> yes, it wouldn't be valid to pass that on riscv
2025-05-08 11:37:27 <psykose> just disable lto on riscv and it's fixed
2025-05-08 11:43:26 <bitblt> ah it seems like an easy fix, just change `armhf` to `armhf|riscv64` here: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/pixman/APKBUILD#L23
2025-05-08 11:43:48 <psykose> yep
2025-05-08 11:43:50 <bitblt> fossdd|m: can you add this change and try building for riscv64 again?
2025-05-08 11:47:50 <fossdd|m> sure
2025-05-08 11:47:55 <fossdd|m> thanks alice! much appreciated
2025-05-08 11:52:43 <bitblt> riscv64 job passed now, loongarch64 still fails with the x.org dns problem
2025-05-08 11:55:22 <psykose> replace it with https://xorg.freedesktop.org/releases/individual/lib/pixman-$pkgver.tar.xz and see if that works
2025-05-08 11:55:44 <psykose> same tarball same checksums etc
2025-05-08 11:58:25 <fossdd|m> pushed
2025-05-08 11:58:34 <fossdd|m> apaprently the docker dns problem is still not solved
2025-05-08 12:01:57 <bitblt> I think we could replace the https://www.x.org/releases/individual/lib/pixman-0.46.0.tar.xz with the upstream tarball here https://gitlab.freedesktop.org/pixman/pixman/-/archive/pixman-0.46.0/pixman-pixman-0.46.0.tar.gz
2025-05-08 12:06:09 <bitblt> ci passed \o/
2025-05-08 12:06:58 <bitblt> ncopa: it should be ready now :)
2025-05-09 04:54:42 <Saijin_Naib[m]> libva/libva-glx bump looks like a major project
2025-05-09 04:54:49 <Saijin_Naib[m]> A ton of packages depend upon them
2025-05-09 04:55:28 <Saijin_Naib[m]> I'm trying to bump the other components of the onevpl stack but got stuck on those two
2025-05-09 08:14:56 <ptrc> https://build.alpinelinux.org/buildlogs/build-3-22-riscv64/community/scummvm/scummvm-2.9.0-r0.log
2025-05-09 08:15:03 <ptrc> this looks silly
2025-05-09 08:15:13 <ptrc> because the "missing" package is noarch
2025-05-09 08:15:46 <ptrc> but i assume it being in `depends_libs` makes the solver miss it, or something
2025-05-09 08:15:50 <fossdd|m> maybe the build order is screwed up
2025-05-09 08:29:35 <psykose> depends_libs doesn't work on the buildorder i think
2025-05-09 08:32:35 <mzh> ptrc I can build it with `abuild -r`
2025-05-09 08:33:16 <ptrc> yeah, it's about the builder and its repos
2025-05-09 08:45:02 <ncopa> maybe add $depends_libs to makdepends?
2025-05-09 08:45:34 <ncopa> > depends_libs doesn't work on the buildorder i think
2025-05-09 08:45:41 <ncopa> i believe that is correct
2025-05-09 08:45:58 <ncopa> only makedepens and depends is taken in consideration for build order calculation
2025-05-09 08:46:24 <ncopa> which means that the depends to all subpackages needs to be added to makedepends to help the build order get correct
2025-05-09 08:58:07 <ptrc> to be fair, it would be lovely to get rid of the silly multiple ways to set dependencies for a subpackage
2025-05-09 08:58:23 <ptrc> and just settle on `dev() { default_dev; depends="..." }`
2025-05-09 08:58:30 <ptrc> but that would require a massive tree-wide change
2025-05-09 08:59:26 <skarnet> the dependencies of the foo-dev package are *not* necessarily the dependencies needed to build the foo package
2025-05-09 08:59:48 <skarnet> so the existence of makedepends makes sense
2025-05-09 09:01:24 <skarnet> but I agree that setting the dependencies of foo-sub via sub() { depends=something } would be logical
2025-05-09 09:02:00 <ptrc> i mean, that's already what we have
2025-05-09 09:02:16 <ptrc> and that's how all the non-"standard" subpackages set dependencies
2025-05-09 09:02:22 <skarnet> yeah
2025-05-09 09:02:49 <skarnet> I'm just agreeing with you that depends_dev and depends_libs feel weird
2025-05-09 09:02:56 <ptrc> ah, oki
2025-05-09 09:03:39 <skarnet> sorry if I'm not clear, morning fog brain
2025-05-09 12:03:33 <sertonix[m]> ptrc: Currently makedepends often includes depends_dev. Your suggestion would require duplicating all of that or add a new _depends_dev variable which would be worse that before.
2025-05-09 12:04:36 <sertonix[m]> (If we change things I would prefer setting all subpackage dependencies in the global scope)
2025-05-09 12:12:47 <ptrc> i mean
2025-05-09 12:13:15 <ptrc> sure, depends_dev is used as a variable in makedepends
2025-05-09 12:13:24 <ptrc> but depends_libs or depends_lang or depends_openrc pretty much never is
2025-05-09 12:15:47 <Piraty> what is the recommended way to run abuild on a foreign distro?
2025-05-09 12:16:28 <Piraty> abuild refuses to run as root in podman, as user it fails to write to /var/cache et al.  
2025-05-09 12:16:42 <Piraty> (podman + alpine container)
2025-05-09 12:17:14 <Piraty> abuild in host context implies a lot of paths specific to apk managed systems
2025-05-09 12:18:21 <ptrc> `abuild rootbld`?
2025-05-09 12:18:40 <ikke> Piraty: you need to add the user to the abuild group
2025-05-09 12:18:58 <ptrc> that too, there's some setuid binaries with abuild
2025-05-09 12:19:42 <Piraty> ptrc: yes, i tried to use abuild rootbld. code setting up the bwrap rootfs implies alpine-like systems
2025-05-09 12:19:53 <ikke> And /var/cache/distfiles 
2025-05-09 12:20:26 <Piraty> ah it's hardcoded. abuild-fetch.c: char *destdir = "/var/cache/distfiles";
2025-05-09 12:21:07 <fossdd|m> abuild-rootbld works fine on other distros see also https://wiki.archlinux.org/title/Abuild
2025-05-09 12:21:32 <Piraty> in a chroot
2025-05-09 12:21:36 <ikke> Piraty: if you use registry.alpinelinux.org/alpine/infra/docker/build-base, it should, except for running abuild-keygen -ain, ve ready to go 
2025-05-09 12:25:33 <Piraty> thank you, will try that one.
2025-05-09 12:45:08 <Piraty> -F did the trick btw :)
2025-05-09 12:46:05 <Piraty> can i limit makejobs via abuild ?
2025-05-09 12:53:15 <ikke> Exporting JOBS
2025-05-09 12:53:55 <ikke> In /etc/abuild.conf or ~/.abuild/abuild.conf
2025-05-09 12:56:23 <Piraty> thank you
2025-05-09 13:02:54 <Piraty> cross compilation only supported for bootstrap?
2025-05-09 13:05:44 <Piraty> hm i misread
2025-05-09 13:22:10 <rhizoome> CI build-ppc64le says: "There are no active runners online"
2025-05-09 13:23:38 <Piraty> podman ... --arch seems to do it. qemu to the rescue
2025-05-09 13:25:25 <Piraty> now wait for frigging firefox to finish building lol. let's see if this works
2025-05-09 13:47:43 <sertonix[m]> Piraty: abuild can be used on other distros (without any hardcoded paths) but you would need to set a few variables.
2025-05-09 13:49:41 <Piraty> i looked at abuild.in and there some hardcoded paths that need to be made configureable like /etc/apk/keys and some more
2025-05-09 13:50:36 <Piraty> and then, apk-add doesn't really like being called as user, installing into user-owned rootfs. of course some postinst hooks to chown files fail, but that should be no issues for bwrap later on
2025-05-09 13:50:57 <sertonix[m]> To be fair abuild rootbld needs patches. But cross compilation doesn't.
2025-05-09 13:51:20 <Piraty> i didn't imply that crossompilation does need patches
2025-05-09 13:51:30 <Piraty> at least on a abuild side of things
2025-05-09 13:51:58 <Piraty> firefox bailed out early though when crosscompiling on x86 to aarch64
2025-05-09 13:52:28 <Piraty> *firefox-esr
2025-05-09 13:52:46 <Piraty> which is broken as is on 3.21 btw , which is why i tried to bump+build in the first place
2025-05-09 13:52:46 <sertonix[m]> I think no one has ever tried to cross compile firefox :p
2025-05-09 13:53:31 <fossdd|m> cross compiling firefox seems like a huge pile of resource waste lol
2025-05-09 13:54:08 <Piraty> well i didn't find my pinephone (postmarketos) equipped to this task, so ...
2025-05-09 13:55:21 <Piraty> well Void Linux crossbuilds firefox{,-esr}  (hi duncaen :p)
2025-05-09 13:55:54 <psykose> cross compiling isn't supported at all outside of bootstrap
2025-05-09 13:56:05 <psykose> qemu-user wrapping is emulation
2025-05-09 13:56:22 <psykose> why do people call it "cross compiling"
2025-05-09 13:56:26 <Piraty> i'm aware, i'm doing it now
2025-05-09 13:56:35 <Piraty> i didn't.
2025-05-09 13:56:49 <Piraty> i tried it , naively 
2025-05-09 13:57:14 <sertonix[m]> psykose: maybe not supported but it works in a lot of cases or is a very simple change.
2025-05-09 13:58:10 <psykose> yes, people like wasting their time on it
2025-05-09 13:58:11 <fossdd|m> yea
2025-05-09 13:58:26 <fossdd|m> basically every cmake package has 3 lines dedicated to it :p
2025-05-09 13:58:53 <sertonix[m]> It's quicker than a vm without kvm
2025-05-09 15:32:40 <adhawkins> Can anyone assist with some warnings I'm seeing on one of my packages? https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/1844638
2025-05-09 15:33:37 <adhawkins> There's a warning on line 200 about pytest-asyncio not having a configuration option set, then on line 351 it skips some of the tests. Is this something missing in upstream?
2025-05-09 16:20:20 <fossdd|m> you need to install something like py3-pytest-asynco first
2025-05-09 16:20:25 <fossdd|m> add it to checkdepends
2025-05-09 16:21:06 <adhawkins> fossdd|m: It already is I thought.
2025-05-09 16:21:23 <adhawkins> I added it to makedepends too just to give it a try
2025-05-09 16:22:07 <fossdd|m> oh ehh
2025-05-09 16:22:37 <adhawkins> MR is #83974
2025-05-09 16:23:40 <rhizoome> fossdd|m: since you're active, you asked me to resolve the thread in !82376, was this because you wanted to merge?
2025-05-09 16:25:45 <adhawkins> Whoops, it's a ! not a # !83974
2025-05-09 17:00:41 <fossdd|m> rhizoome: i dont have the permissions to merge, but resolving the thread makes it more visible to those who can
2025-05-09 17:01:28 <rhizoome> fossdd|m: I see, thanks.
2025-05-09 18:30:45 <andypost[m]> both x86_64 builders lack of disk
2025-05-09 21:24:28 <fossdd> is it just me or got commenting on MRs really laggy
2025-05-09 21:55:35 <ptrc> can't relate
2025-05-09 21:55:37 <ptrc> works okay for me
2025-05-09 23:17:16 <rhizoome> new openrc moved the cachedir from /usr/libexec/rc/cache/ to /var/cache/rc/, but localmount unmounts /var before savecache is run. The variable is called $RC_CACHEDIR, but I don't see how I cache that. Any ideas? Is this a bug?
2025-05-09 23:17:58 <rhizoome> s/how I cache that/how I change that/
2025-05-09 23:22:56 <rhizoome> fossdd: gitlab loads huge diffs into the browser, even though it says it did not load them. I checked browser memory.
2025-05-09 23:47:24 <rhizoome> also apk does not update or write an apk-new for /etc/init.d/termencoding so there it uses the old cache dir. 
2025-05-09 23:49:08 <psykose> has the correct one for me
2025-05-09 23:52:15 <rhizoome> it does not update a bunch of files in /etc/init.d all of them are in openrc. apk fix openrc does not fix or write an apk-new.
2025-05-09 23:58:25 <elagost> would anyone be able to review !82241? It's been sitting a while
2025-05-10 00:02:01 <rhizoome> also zfs-mount in zfs-openrc
2025-05-10 00:14:37 <rhizoome> ok, found an explanation for the not updating, but the RC_CACHEDIR thing is still open.
2025-05-10 02:18:19 <rhizoome> ok, I added "sh" to savecache and created /var/cache/rc on the rootfs. now it is working, it is even correct since when the cache is read /var is not yet mounted.
2025-05-10 09:09:38 <psykose> that seems very suboptimal
2025-05-10 09:29:50 <buinb> Hola
2025-05-10 09:30:33 <buinb> It seems that most webkitgtk-based web browsers crash since last webkitgtk update (ptrc?)
2025-05-10 09:32:38 <buinb> The webprocess crashes when started
2025-05-10 09:34:58 <buinb> Even the provided MiniBrowser
2025-05-10 09:35:03 <buinb> ** (MiniBrowser:10585): WARNING **: 11:34:46.221: WebProcess CRASHED
2025-05-10 09:35:48 <buinb> (that's on amd64)
2025-05-10 12:43:16 <ptrc> buinb: should be fixed now
2025-05-10 12:43:20 <ptrc> as in
2025-05-10 12:43:29 <ptrc> in an hour, when the builders go through the packages
2025-05-10 12:43:34 <ptrc> and actually upload it
2025-05-10 12:57:57 <buinb> Thank you ptrc!! :D
2025-05-10 13:11:22 <psykose> also have to kick edge-armhf and v7 since they're stuck
2025-05-10 16:58:15 <andypost[m]> psykose: is it mono build again?
2025-05-10 16:58:26 <psykose> already was kicked
2025-05-11 06:26:17 <qaqland> Would anyone be able to help merge !82591 ? It would be greatly appreciated :)
2025-05-11 07:45:17 <caskd> Does fastly intentionally have no v6 for their DNS authoritative servers? Just noticed after i've set up a purely v6 recursive resolver
2025-05-11 07:45:32 <caskd> and as such dl-cdn fails to resolve even though it would work via v6
2025-05-11 07:45:37 <caskd> :/
2025-05-11 07:59:51 <caskd> sent a mail, hope they handle it
2025-05-11 07:59:53 <caskd> :P
2025-05-11 08:36:57 <buinb> caskd, IPv6 is fairly new to ISP / network service providers, it's only been around for ~30 years, they can't just switch like that
2025-05-11 08:41:52 <skarnet> buinb: that's mostly true for French ones, in other European countries IPv6 usually works fine
2025-05-11 08:42:56 <caskd> :P
2025-05-11 08:43:02 <buinb> https://stats.labs.apnic.net/ipv6
2025-05-11 08:43:14 <buinb> 
ACTION coughes

2025-05-11 08:43:28 <skarnet> interesting
2025-05-11 08:43:55 <caskd> well, then it's my job to bother net admins to use ipv6
2025-05-11 08:43:57 <skarnet> I tested in Germany, Belgium, the UK and Ireland, I suppose I got lucky
2025-05-11 08:45:06 <buinb> Maybe it's corelated with just Internet coverage in general
2025-05-11 08:45:23 <caskd> or the skill of the net admins in the region :P
2025-05-11 08:45:29 <buinb> Like main actors might support IPv6, but not necessarily having large coverage
2025-05-11 08:45:59 <buinb> (or just the will to spread it outside of bigger cities, I don't know)
2025-05-11 08:46:11 <buinb> Yeah caskd 
2025-05-11 08:46:27 <buinb> Replacing “internet boxes”, etc.
2025-05-11 08:46:33 <caskd> yeah
2025-05-11 08:47:12 <caskd> well, i don't wanna force every ISP to support v6, but if you're a content provider on the internet you should have it
2025-05-11 08:47:33 <caskd> *cough cough* microsoft
2025-05-11 08:47:50 <f_> "only" 30 years
2025-05-11 08:48:14 <buinb> Here in Spain, it's pretty bad, it seems it's mostly all CGNAT (though I might be missing some info)
2025-05-11 08:55:32 <proek> # apk add chromium ERROR: unable to select packages:   so:libsimdutf.so.19 (no such package):     required by: chromium-135.0.7049.95-r0[so:libsimdutf.so.19] :(
2025-05-11 08:55:47 <proek> edge x86_64
2025-05-11 09:03:50 <ikke> !83616
2025-05-11 09:13:59 <proek> "Does not include chromium rebuild" Why? I don't understand. Doesn't that break it?
2025-05-11 09:15:12 <ikke> proek: Because chromium takes ages to build, and a separate chromium upgrade is/was probably already pending
2025-05-11 09:19:57 <proek> I see, makes sense. Chromium build failed though :( I think will get it from v3.21 for now.
2025-05-11 09:38:28 <prabu> can i request for the following packages be moved from testing to community gufw,refind,powerctl,cliphist-fzf,catdoc,swappy,apk-snap. i have tested all the above except gufw.   
2025-05-11 10:05:06 <fossdd|m> prabu: if you can, opening a MR would be good so that we can ping all of the related maintainers
2025-05-11 10:18:41 <ikke> ideally a separate MR per maintainer
2025-05-11 10:18:47 <ikke> or package even
2025-05-11 10:51:08 <elagost> if the gitlab builders are running out of memory building a package, will the "real" builders also not be able to do it? mr in question is !83505
2025-05-11 10:52:09 <ptrc> more interesting is why it would OOM on gnome-podcasts
2025-05-11 10:52:13 <psykose> not a real oom
2025-05-11 10:52:29 <ptrc> yeah
2025-05-11 10:52:35 <ptrc> was about to say, it's a segfault and an abort
2025-05-11 10:54:49 <elagost> what does that mean in practical terms? Something like using a `isize` where it whould be using `i32` or something?
2025-05-11 10:56:52 <psykose> no, ran out of the 4g address space on 32-bit
2025-05-11 10:57:19 <psykose> you can get around it by exporting CARGO_PROFILE_RELEASE_DEBUG=0 prolly
2025-05-11 10:59:56 <elagost> thanks psykose, I'll try that.
2025-05-11 11:08:17 <elagost> well that at least worked for x86, so the other 32 bit environments might pass too. Thanks!
2025-05-11 11:09:13 <psykose> you can set it globally, doesn't have to be conditional
2025-05-11 11:09:27 <psykose> -dbg is already disabled so it would just save a bit of time on all arches
2025-05-11 11:10:00 <psykose> the default for cargo build --release is to disable it, the project just re-enables it, but there's also no benefit in enabling it without a -dbg subpackage
2025-05-11 12:05:27 <Saijin_Naib[m]> @buinb your ISP supports IPV6‽
2025-05-11 12:06:53 <Saijin_Naib[m]> @prabu been using gufw on three machines for over a year. No issues outside of breakage of needing a rebuild when python upgrades
2025-05-11 12:11:09 <sertonix[m]> I noticed that some patches replacing python with python3 aren't needed anymore since they are symlinked now. Any opinion whether or not we should drop these patches?
2025-05-11 12:31:32 <elagost> noticed a TODO in networkmanager, so added a virtual package here: !84059 anyone got thoughts on this?
2025-05-11 12:54:58 <adhawkins> Any python / pytest experts help with this? !83974 It's not running the asyncio tests, but I've put the package in the 'check_depends' list.
2025-05-11 14:34:55 <rhizoome> adhawkins: I am testing it locally.
2025-05-11 14:46:26 <rhizoome> adhawkins: fixed.
2025-05-11 14:47:07 <adhawkins> How rhizoome?
2025-05-11 14:49:08 <rhizoome> adhawkins: I commented on the issue. I ran pytest locally with --help, to if what arguments pytest-asyncio has, then I saw the deprecation error: --asyncio-mode= has no more a default.
2025-05-11 14:49:43 <adhawkins> Ah ok, thanks. Would that be better fixed in the package, or having upstream set that option in the .toml file?
2025-05-11 14:52:34 <rhizoome> adhawkins: yes usually it is possible to set pytest arguments in the toml file. I'll test it and give you a diff to upstream.
2025-05-11 14:52:50 <adhawkins> Great, thanks rhizoome.
2025-05-11 15:45:35 <prabu> ikke, i've created a MR !84076 from gitlab web interface after doing a git commit.. is that all?
2025-05-11 15:50:41 <prabu> @Saijin_Naib, thanks for the confirmation on gufw.
2025-05-11 15:51:11 <ikke> prabu: seems like the maintainer is not really active anymore, so it most likely will need a new maintainer
2025-05-11 15:56:05 <prabu> ikke, i see that ptrc has added two patch files to refind packages. currently i lack the knowledge to maintain this package... how to proceed?
2025-05-11 15:59:18 <ikke> ask ptrc if they want to maintain the package, otherwise try to find someone else
2025-05-11 16:30:52 <ptrc> i mean
2025-05-11 16:31:00 <ptrc> there hasn't really been any updates of refind
2025-05-11 16:31:26 <ptrc> and the patches have been unmodified for ages
2025-05-11 16:31:28 <ptrc> shrug
2025-05-11 16:31:34 <ptrc> i can take it over if nobody else wants it
2025-05-11 16:31:54 <ptrc> but i haven't used refind besides one attempt in 2016 so
2025-05-11 16:54:58 <prabu> ptrc/ikke, based on this https://wiki.alpinelinux.org/wiki/Package_Maintainers, i can test, follow up and keep it updated as long as it doesn't break. if it breaks i may need to ask for help here, if i lack the knowledge until then... 
2025-05-11 16:58:19 <adhawkins> rhizoome: I think I've applied that patch, created a PR for upstream, and have added a comment to that effect in the APKBUILD. Is that enough? )!83974)
2025-05-11 18:28:43 <rhizoome> adhawkins: I think so. Thank you!
2025-05-12 07:05:05 <wiktor> Hi folks! I've noticed that a package that I maintain is in edge/testing: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/py3-pysequoia but it's seriously outdated (0.1.20 vs 0.1.28) and the project has been moved from Codeberg to GitHub since then: https://github.com/wiktor-k/pysequoia I don't see a way to contact the maintainer (None). What is the procedure here to get that fixed? Thanks in advance!
2025-05-12 07:10:52 <f_> wiktor: you could take over maintenance
2025-05-12 07:11:30 <lotheac> wiktor: click on "git repository" on that page. you could create pull requests to update the package and make yourself maintainer if the alpine package doesn't currently have a maintainer.
2025-05-12 07:12:09 <wiktor> hmm... okay, seems do-able, do I have to be in some special alpine maintainer role or something?
2025-05-12 07:12:27 <lotheac> nope, just need an account on gitlab
2025-05-12 07:12:51 <wiktor> okay, great, I'll see how far can I go and in case of problems ping you all here :)
2025-05-12 08:43:57 <Kladky> Could someone please take a look at !83105? I haven't moved any of my aports to community myself yet, so I wanted to do that now.
2025-05-12 09:36:47 <angeloverlain[m]> Is there something wrong with the ppc64le builder? It says it got stuck https://gitlab.alpinelinux.org/vixalien/aports/-/pipelines/324556
2025-05-12 09:37:44 <ikke> angeloverlain[m]: the ci host is AWOL 
2025-05-12 09:38:36 <angeloverlain[m]> oh.
2025-05-12 09:58:22 <rhizoome> is ppc64le currently used for build of 3.22? or is it "more" serious, as in the server broke?
2025-05-12 10:21:03 <ikke> It still pings, so it's still functioning somewhat
2025-05-12 10:47:05 <andypost[m]> looks like mariadb unpublished security release https://build.alpinelinux.org/buildlogs/build-3-22-x86_64/main/mariadb/mariadb-11.4.6-r0.log
2025-05-12 12:06:46 <ncopa> https://lists.mariadb.org/hyperkitty/list/packagers@lists.mariadb.org/thread/TP74ZU2ARZOQBLUNPT63I2A6LNB54XLJ/
2025-05-12 12:39:46 <andypost[m]> thank you
2025-05-12 12:52:08 <adhawkins> angeloverlain[m]: You saved me asking the same question :)
2025-05-12 14:14:36 <mcrute> I have an existing package that I want to rename to a versioned name so that the new and old (compatible but not drop-in replacements for each other) can be considered sufficient for the old package name, can I just rename it and add a provides to both packages?
2025-05-12 14:15:16 <mcrute> Concretely bird exists today and I want to split it into bird2 and bird3 but not break anyone's installations while still allowing people to install bird and by default get bird2 but give them the option to pick bird3 instead.
2025-05-12 14:17:10 <mcrute> provides seems like the simple obvious option here but I'm not quite sure what would happen for people who have bird (currently version 2) installed today. I'm assuming if bird2 has a higher provider_priority then when they did an upgrade that package would be installed.
2025-05-12 14:21:59 <ncopa> i think you can just add a package named bird3
2025-05-12 14:22:52 <mcrute> you're suggesting just leave bird as version 2 and let people install bird3 if they want it?
2025-05-12 14:24:10 <ncopa> yeah
2025-05-12 14:24:52 <mcrute> eventually upstream wants bird v3 to replace bird v2 but they're not there yet in terms of stability. My hope was to make that transition a little easier for people in the short term.
2025-05-12 14:25:24 <ncopa> alternatively, you could rename current bird to bird2, and upgrade bird to 3. since it is not a drop-in replacement people will have to deal with the upgrade when upgrading. Those who dont want deal with it can install bird2 instead
2025-05-12 14:25:29 <mcrute> I guess once upstream drops bird v2 support I could just drop the bird package entirely and always use versioned names going forward
2025-05-12 14:26:11 <ncopa> the second alternative is more "future-proof" but more disruptive
2025-05-12 14:26:38 <mcrute> yeah, but I think I like that a little better
2025-05-12 14:27:17 <mcrute> plus people would only deal with this issue when they pulled a new major release and we could call it out in the release notes
2025-05-12 14:29:21 <mcrute> ncopa: is there a place where you draft release notes for the next major revision that I could put a note about this?
2025-05-12 14:31:10 <ikke> The Wiki 
2025-05-12 14:31:22 <mcrute> just found it :-)
2025-05-12 14:43:26 <fossdd|m> you could also add a provides="bird" and replaces="bird" to bird2 or 3 without interrupting users and still having users who want depend on a major version
2025-05-12 14:44:43 <ikke> You want to add =$pkgver-r$pkgrel to the provides 
2025-05-12 14:45:28 <ikke> You should at least not combine virtual provides with concrete packages 
2025-05-12 14:46:21 <mcrute> if I went the path of splitting them I would make bird the virtual package and bird2/3 the concrete packages
2025-05-12 14:46:37 <fossdd|m> that would work
2025-05-12 14:46:37 <mcrute> I just wasn't sure what the implication of making a currently concrete package into a virtual package was
2025-05-12 14:46:44 <mcrute> I'm still kinda curious about that tbh
2025-05-12 14:49:56 <mcrute> ikke: if I want to drop a package (in testing) is it sufficient to just push a delete commit or is there some other process to purge it from pkgs.a.o?
2025-05-12 14:50:17 <fossdd|m> nope just rm -fr it, the builder will handle removing it from APKINDEX
2025-05-12 14:50:43 <mcrute> excellent
2025-05-12 14:52:41 <mcrute> oh I see, I guess the builders are just pretty far behind for certain archs right now
2025-05-12 19:00:01 <ptrc> hm, does `apk dot` not work for virtual packages?
2025-05-12 19:00:18 <ptrc> i tried it on a makedepends package generated by `abuild deps`
2025-05-12 19:00:28 <ptrc> and it just returns error code 1 with no message
2025-05-12 19:45:16 <rhizoome> Yes, virtual packages are invisible in some contexts, which has caused me to be confused in the past.
2025-05-13 04:49:14 <candrew> I think MR !84012 is ready to be merged
2025-05-13 09:48:27 <sertonix[m]> ptrc: It seems fixed in apk3. Not sure why though
2025-05-13 17:30:50 <fossdd|m> so apparently protobuf got merged again and missed a couple of rebuilds
2025-05-13 17:32:23 <mio> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82994#note_507428
2025-05-13 17:32:44 <mio> if there are any others, feel free to mention them as well
2025-05-13 17:35:00 <fossdd|m> https://paste.sr.ht/~fossdd/e2d60859045993cce38dcb45ad87e15223037866
2025-05-13 17:35:14 <fossdd|m> these are the packages (but including subpackages)
2025-05-13 17:35:18 <fossdd|m> i can try to open a rebuild MR
2025-05-13 17:35:31 <mio> great, thanks
2025-05-13 17:49:38 <fossdd|m> !84165
2025-05-13 17:49:58 <fossdd|m> also a few other missing rebuilds if somebody wants to take care about it: https://paste.sr.ht/~fossdd/02b432a624ecb5f5a94c545e3167faf45e4e51da
2025-05-13 17:50:23 <fossdd|m> (a few are probably in testing and not worth it)
2025-05-13 17:54:25 <ptrc> i'll wait for builders to finish testing and bump whatever's left
2025-05-13 17:56:21 <fossdd|m> i think a few have open MRs with the CI failing so watch out
2025-05-13 17:57:04 <fossdd|m> but yeah the builder queue is high rn
2025-05-13 17:59:38 <fossdd|m> if i think about it, maybe checkapk or something similar could check if the necessary pkgrels are bumped using git diff
2025-05-13 17:59:44 <fossdd|m> or just that the apkbuild got changed
2025-05-13 22:23:32 <craftyguy[m]> does the helix editor work for anyone with the tree-sitter grammars in aports?
2025-05-13 22:46:14 <craftyguy[m]> helix build for 3.22 is failing, !70759 fixes/avoids the issue altogether ;)
2025-05-14 06:48:26 <fossdd|m> !83714 !83715 !83717 are ready to merge again
2025-05-14 09:38:32 <wiktor> hi folks! I've mentioned outdated testing package and got the suggestion to update it, I've filed an MR and was wondering if someone could take a look if there are any obvious deficiencies or improvements: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/84107 thanks for help in advance :) 
2025-05-14 15:10:46 <ncopa> fossdd|m: seeps like redis/redict tests fails on builders for some reason
2025-05-14 15:11:28 <fossdd|m> probably just the flaky tests
2025-05-14 15:11:48 <fossdd|m> i feel like its a 50% change wheater check() fails or not
2025-05-14 15:11:58 <fossdd|m> maybe i should just disable check altogether
2025-05-14 15:12:34 <ikke> it seems to fail consistently on x86
2025-05-14 15:12:46 <ncopa> tests that are known to be flaky can be disabled
2025-05-14 15:12:59 <ncopa> they apparently passed on the CI?
2025-05-14 15:13:07 <ikke> Should be reported upstream
2025-05-14 15:13:10 <fossdd|m> after like a dozen retries
2025-05-14 15:13:12 <ikke> flaky tests help no one
2025-05-14 15:14:04 <ncopa> i have spent a day or two on a test in gettext that deadlocks on riscv64
2025-05-14 15:14:31 <ncopa> turns out the test is completely meaingless. it tests something for gnulib, that has nothing to do with gettext at all
2025-05-14 15:53:42 <ikke> I think lego is fixed with the latest version of github.com/yandex-cloud/go-genproto
2025-05-14 16:08:57 <ncopa> thanks. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/84215
2025-05-14 16:17:13 <ikke> ncopa: http://dup.pw/alpine/aports/dbb6afc02945
2025-05-14 16:20:37 <psykose> 3.22 aarch64 is stuck too
2025-05-14 17:40:43 <angeloverlain[m]> I think !83422 is ready for another look
2025-05-15 07:02:44 <ncopa> why is dotnet8-sdk failing? there is a dotnet8-stage0
2025-05-15 19:11:10 <Kladky> Hi all, do you think it would possible to get !83105 merged before 3.22? I wanted to get most of the "stable" packages I maintain into the next release.
2025-05-15 19:11:58 <ikke> Kladky: it's a large MR, won't help
2025-05-15 19:12:29 <Kladky> Would breaking it down into multiple MRs be any better?
2025-05-15 19:13:14 <ikke> Definetely, especially because the pipelines are failing for certain arches
2025-05-15 19:13:31 <Kladky> Ok, noted. I will do that now.
2025-05-15 19:30:53 <Kladky> Done.
2025-05-15 19:33:05 <ikke> 216 pending jobs.. nice
2025-05-15 19:33:07 <ikke> :P
2025-05-15 19:37:49 <Kladky> Part of the reason I initially did it all in one.
2025-05-15 19:38:15 <Kladky> Since I didnt think there would really be much reviewing required, since its just moving files from one directory to another (mostly)
2025-05-15 19:39:50 <ikke> It does at least require some review
2025-05-15 19:40:25 <Kladky> All the MRs are listed here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/83105#note_508170
2025-05-15 19:40:41 <Kladky> (Didnt want algitbot sending dozens of messages)
2025-05-15 19:41:55 <Kladky> What sort of review does it require ikke?
2025-05-15 19:42:22 <Kladky> I would have thought the review it got when it was added to testing would have been enough
2025-05-15 19:43:13 <ikke> Just a final check, sometimes things are allowed in testing that should be fixed before moving packages to community
2025-05-15 20:54:03 <dne> is the gitlab ci armv7 runner emulated?
2025-05-15 20:55:58 <ikke> It's running in 32-bits mode on aarch64, but not emulated
2025-05-15 20:56:51 <dne> ah ok
2025-05-16 08:49:50 <ncopa> Kladky: I'm working on the MRs now. would have been nice if those that are related were grouped (eg libunicode and contour)
2025-05-16 12:19:02 <Kladky> Yeah, sorry about Contour + deps, slipped my mind.
2025-05-16 12:19:57 <Kladky> Besides those, none of the other aports depend on one another.
2025-05-16 12:59:10 <mikethe1wheelnu__> greetings.. testing.. testing.. was it really this easy to join this chat?  ..is there anybody actually here? 
2025-05-16 12:59:43 <mikethe1wheelnu__> I'm posting this in multiple places, deliberately, in hopes of figurring out which one works, where everybody is..
2025-05-16 12:59:59 <mikethe1wheelnu__> ..I have a problem.  I have tried to install ungoogled-chromium on my new install of alpine-linux via flathub / flatpak, and failed.  all I'm looking for, for now, is confirmation that the official instructions for how to do so are correct.  https://flathub.org/apps/io.github.ungoogled_software.ungoogled_chromium had an "install" link, a nice blue button..
2025-05-16 13:00:10 <mikethe1wheelnu__> there is also a drop-down menu for a manual install.  I have tried all combinations I can think of, with different errors.  I can report all of them, but prefer to wait until I at least get a reply, confirming that I'm in the right place, and there are people here :-)
2025-05-16 15:38:40 <f_> Huh, what is apk 
2025-05-16 16:12:45 <skarnet> baby don't hurt me
2025-05-16 16:44:31 <buinb> no more
2025-05-16 16:49:08 <skarnet> wrong, it was "don't hurt me"
2025-05-16 16:51:48 <buinb> I skipped the redundancy 
2025-05-16 16:53:09 <skarnet> there's no redundancy in Art
2025-05-16 16:54:06 <buinb> And yet, it was skipped
2025-05-16 16:54:24 <craftyguy[m]> skarnet: never gonna let you down
2025-05-16 17:02:56 <f_> we're no strangers to love, you know the rules and so do I
2025-05-16 19:55:42 <craftyguy[m]> Where does apkbrowser's db come from? (pkgs.alpinelinux.org) I want to do a lot of querying but would rather do it on a local copy of it.. Is there an easy way to create it locally?
2025-05-16 19:57:58 <ikke> craftyguy[m]: it scrapes dl-cdn
2025-05-16 20:02:49 <craftyguy[m]> so I would need to rsync a mirror locally, then I could run my own copy of apkbrowser?
2025-05-16 20:05:05 <craftyguy[m]> I want to query a bunch of things to try and find packages that conflict with busybox applets, when doing usr merge. , I have a janky script to do this but would probably send 100+ http requests to pkgs.alpinelinux.org. I don't know if that's acceptable or not... I could rate limit it so it's like 1 every few seconds. wdyt? This is a one-off thing, I hope I never have to do this again 😅
2025-05-16 20:31:37 <ptrc> hm, at which point do we disable half the community just to get the release out?
2025-05-16 20:31:47 <ptrc> i'd give it a week more
2025-05-16 20:54:11 <psykose> don't 4get that 3.22-x86_64 is stuck too
2025-05-17 06:34:51 <qaqland> i want to upgrade community/grpc, but it internally download bazel. I didn't find any relevant handling in the previous build-log :(
2025-05-17 06:38:27 <qaqland> https://github.com/grpc/grpc/blob/v1.72.0/tools/bazel#L84
2025-05-17 06:40:22 <qaqland> what should I do? i have little experience with bazel
2025-05-17 09:05:04 <fossdd|m> can someone merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75066 or add to the 3.22 milestone?
2025-05-17 09:24:35 <qaqland> !75066
2025-05-17 13:36:40 <qaqland> if !84386 is merged, then !83742 and !84168 may also require some rebuilt
2025-05-17 14:45:56 <mikethe1wheelnu> Ftr, I have solved my probem :-)  Than answer was in the "Flatpack" section of the wiki :-)  It was also linked to from the "advanced" section of "setting up a desktop environment".  I hadn't realized that this was "advanced" :-)
2025-05-17 15:44:27 <sertonix[m]> craftyguy: Isn't it enough for your goal to do `apk list -p cmd:<applet>`?
2025-05-17 15:44:46 <sertonix[m]> s/-p/-P/
2025-05-17 16:49:46 <craftyguy[m]> No because I also need paths
2025-05-17 16:50:55 <craftyguy[m]> I no longer need to do this though, I just went for querying the site with a very relaxed rate limit and have what I need 😁
2025-05-18 02:42:26 <qaqland> need help in !84386, i described problem in the comment.
2025-05-18 02:42:27 <qaqland> Any suggestions would be greatly appreciated.
2025-05-18 02:45:53 <qaqland> I have contacted the maintainer and he is quite busy recently. ¯\_(ツ)_/¯
2025-05-18 08:15:10 <buinb> qaqland, without much context why not having bazel as a build dependency?
2025-05-18 08:15:17 <buinb> If it looks for bazel
2025-05-18 08:17:22 <qaqland> buinb: bazel is still in testing
2025-05-18 08:23:05 <buinb> Well, then this grpc should either move to testing too or waiting for a more mature version I suppose
2025-05-18 08:28:51 <ikke> Or check if it's possible to build without bazel
2025-05-18 09:24:36 <yabobay> i tried signing up on the alpine gitlab, but i'm not receiving my confirmation email. i definitely checked spam, and i definitely entered the right address. is there a known server problem going on right now?
2025-05-18 09:26:52 <ikke> yabobay: what mail provider?
2025-05-18 09:26:59 <yabobay> yahoo
2025-05-18 09:28:41 <ikke> can you try again?
2025-05-18 09:29:36 <yabobay> i tried again once, trying again again now
2025-05-18 09:29:56 <yabobay> wait. try to resend the email, or try to register from scratch?
2025-05-18 09:30:04 <ikke> resend the mail
2025-05-18 09:33:23 <yabobay> well i just tried registering again just to make sure and it says the username is taken
2025-05-18 09:33:34 <yabobay> oh sorry i didn't see that
2025-05-18 09:33:37 <yabobay> lemme try resending
2025-05-18 09:34:45 <yabobay> oh i got it now
2025-05-18 09:34:46 <yabobay> thanks
2025-05-18 09:35:27 <ikke> There's an issue with the RDNS record for the host sending the emails, causing our spam filter to reject it
2025-05-18 10:40:28 <vmignot> Hi fossdd|m ! I tried to make enable the nouveau vulkan driver a month ago, and was blocked by one dependency that is currently on community. I closed the PR since I switched to an AMD GPU. The NVK developper would like to see a port to Alpine, so I'll work on it once again. You told me at the time that I could move the dependency to the main repo. I guess I should write to its current maintainer 
2025-05-18 10:40:34 <vmignot> right ?
2025-05-18 10:55:29 <ikke> Yes, the maintainer would need to approve it
2025-05-18 10:58:46 <vmignot> I'll try to contact them, but it seems they are currently busy IRL. In this case, I would not mind taking the maintainership
2025-05-18 15:51:23 <ncopa> Ariadne: can you please help me with  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69891
2025-05-18 18:10:32 <fossdd|m> hiya! can someone press the big button in !84018?
2025-05-18 18:16:52 <fossdd|m> thanks!!
2025-05-18 19:58:59 <Ariadne> ncopa: patch looks fine, it can go in
2025-05-18 19:59:06 <Ariadne> i merged it upstream
2025-05-19 06:54:34 <ncopa> Thanks!
2025-05-19 08:21:22 <ildar[m]> Greetings!
2025-05-19 08:21:22 <ildar[m]> I experience `main/glib` doesn't rebuild anymore:
2025-05-19 08:21:22 <ildar[m]> > >>> ERROR: glib-doc*: Missing /usr/src/aports/glib/pkg/glib-doc
2025-05-19 08:21:35 <ildar[m]> Can anyone please quickcheck?
2025-05-19 08:22:10 <ildar[m]> I suspect newer meson recently came in.
2025-05-19 09:38:30 <rhizoome> ildar[m]: yes same problem: >>> ERROR: glib-doc*: Missing /home/ganwell/aports/main/glib/pkg/glib-doc
2025-05-19 09:39:02 <ildar[m]> thank you for comfirming
2025-05-19 09:44:38 <rhizoome> ildar[m]: » find pkg | grep man > shows that the man-pages where not built. 
2025-05-19 09:45:13 <ildar[m]> <ildar[m]> "I suspect newer meson recently..." <- ⬆️ ?
2025-05-19 10:30:23 <ildar[m]> Ah! already filed: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17162
2025-05-19 16:27:53 <craftyguy[m]> sertonix: hey thanks a lot for reviewing those MRs I sent wrt avoiding busybox symlink conflicts. I'll work on making the changes you proposed over the next day or so, but just wanted to say thanks :D
2025-05-19 21:04:25 <craftyguy[m]> could someone add the MRs listed here to the 'usr merge' milestone please? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/?sort=updated_desc&state=opened&author_username=craftyguy&search=busybox&first_page_size=20
2025-05-19 21:04:45 <craftyguy[m]> this milestone: https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16
2025-05-20 06:56:50 <qaqland> when doing “rebuild against”, should it be one commit for each package or one commit for all packages? !84502
2025-05-20 08:09:51 <Piraty> qaqland: ` git log [--oneline] --grep rebuild ` will tell you
2025-05-20 08:51:07 <ncopa> qaqland: do whatever is practical for you
2025-05-20 08:51:56 <rhizoome> ikke: I could open an MR including the fix I found for this: !81671 if that helps
2025-05-20 08:52:21 <ikke> rhizoome: thanks, please do
2025-05-20 08:55:42 <NN708> Hi all, could someone help review/merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77702 ? It's been open for almost 5 months, and I'd like to avoid it missing Alpine 3.22. Thanks!
2025-05-20 09:04:56 <ikke> rhizoome: seems to fail on ppc64le still 
2025-05-20 10:49:23 <Habbie> the size report at the end of abump is nice
2025-05-20 10:49:51 <ikke> That's produced by checkapk :)
2025-05-20 10:50:10 <Habbie> ah :)
2025-05-20 10:50:11 <ikke> (in case you want to run it manually)
2025-05-20 10:50:19 <Habbie> i might! thanks
2025-05-20 10:50:33 <Habbie> >>> Size difference for dnsdist-doc: 2119 B -> 2117 B
2025-05-20 10:50:37 <Habbie> sometimes i wonder if separating this is worth it
2025-05-20 10:50:59 <Habbie> but i guess it's quite a generic mechanism
2025-05-20 10:51:09 <ikke> Yes
2025-05-20 11:18:17 <fossdd|m> nice that people get to know checkapk by abump :)
2025-05-20 11:18:33 <Habbie> :)
2025-05-20 11:39:45 <qaqland> it is really useful to check file_list changes :D
2025-05-20 12:17:37 <rhizoome> ikke: we mave "internal compiler error: Illegal instruction" happending on some runners. 84514!
2025-05-20 12:18:08 <skarnet> "happending" sounds frighteningly accurate
2025-05-20 12:18:48 <rhizoome> lol
2025-05-20 15:02:25 <ncopa> i think i found the problem with lastpass-cli, which appears to be broken with openssl 3.5.
2025-05-20 15:19:05 <mio> good to see another one fixed
2025-05-20 15:29:32 <ncopa> any suggestion which I should look at next?
2025-05-20 15:29:46 <ncopa> will be tomorrow
2025-05-20 15:30:15 <mio> rutorrent?
2025-05-20 15:31:00 <mio> gimp can be rebuilt with ninja as fallback, but would be better of course to have it fixed to work with samurai
2025-05-20 15:31:27 <ncopa> maybe we should report it to samurai?
2025-05-20 15:32:44 <ncopa> https://github.com/michaelforney/samurai/issues/117
2025-05-20 15:33:02 <mio> possibly?
2025-05-20 15:34:21 <mio> ah thanks for the link
2025-05-20 15:36:09 <mio> rutorrent, py3-skia-pathops are the two main ones, followed by gimp and wezterm
2025-05-20 15:36:23 <mio> nextcloud-client failed tests only seem to occur on armv7
2025-05-20 15:37:41 <mio> cyclone test is a known prior issue, maintainer already notified but there's some difficulty reproducing the issue
2025-05-20 16:15:37 <pc_magas> Hello I fixed any issues upon this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79350 Should I resolve any chat?
2025-05-20 16:21:46 <ikke> Yes
2025-05-20 16:27:36 <pc_magas> Ok now I need to wait in order to be aproved?
2025-05-20 16:27:48 <ikke> yes
2025-05-20 16:29:50 <ikke> pc_magas: you received new feedback
2025-05-20 16:32:50 <pc_magas> Also fixed these
2025-05-20 17:57:42 <craftyguy[m]> a quick test says: no
2025-05-20 20:06:52 <f_> craftyguy[m]: what do you mean?
2025-05-20 20:16:55 <craftyguy[m]> I was wondering if apk passed any additional info to commit hooks when they are called pre-commit and post-commit, but it seems like they only get a single parameter ('pre-commit' or 'post-commit') and no additional info in env about what will or has changed during the apk db commit
2025-05-20 20:21:03 <f_> craftyguy[m]: what's your usecase?
2025-05-20 20:21:50 <f_> because I see no messages from you about post/pre-commit until now
2025-05-20 20:46:11 <craftyguy[m]> I wanted to run something when a specific package was changed
2025-05-20 20:46:40 <craftyguy[m]> without having to package a trigger somewhere. but I found another way to do it
2025-05-21 06:36:57 <fabricionaweb> wireguard-tools got updated
2025-05-21 07:22:54 <Saijin_Naib[m]> ERROR: gnucash-5.11-r0: trying to overwrite usr/share/glib-2.0/schemas/gschemas.compiled owned by soundconverter-4.0.6-r0
2025-05-21 07:23:06 <Saijin_Naib[m]> Is this a packaging or build issue with gnucash or soundconverter?
2025-05-21 07:23:21 <Saijin_Naib[m]> apk fix can not resolve this, and it is stopping me from using abuild
2025-05-21 07:23:40 <Saijin_Naib[m]> I can of course uninstall one/both, but I would like to open an Issue so it gets fixed, but I don't understand exactly what is going wrong
2025-05-21 08:46:10 <witcher01> I'm maintaining gnucash but I'm not familiar with the gschemas.compiled file. Does anyone know more about this? Surely every glib program *should* have their own file? Or is it a shared thing that we need to handle somewhow?
2025-05-21 08:54:08 <angeloverlain[m]> I'm having issues with !84411, I can't get the session to start anyway after installing with mrtest. gnome-session --session=pantheon or gnome-session --session=patheon-wayland both fail and I can't pick up why.  If you get to test the MR, just a heads up that you can't install both elementary-session and gnome-shell because of conflicting mutter versions
2025-05-21 14:19:57 <Hello71> Saijin_Naib[m], witcher01: probably both, and it should be compiled by glib trigger. seems soundconverter is fixed now
2025-05-21 14:22:42 <dne> it seems shared-runner x86-64.ci.alpinelinux.org has run out of disk
2025-05-21 14:24:00 <witcher01> Hello71: I'll look into it when I can, thanks!
2025-05-21 14:24:16 <psykose> gnucash is also fixed
2025-05-21 14:27:14 <Hello71> oh, right, I was looking for gschemas.compiled but gnucash takes -DCOMPILE_GSCHEMAS=OFF
2025-05-21 14:40:21 <Saijin_Naib[m]> Thanks, all!
2025-05-21 14:40:59 <Saijin_Naib[m]> I might need some help with vtk. It is very backlevel, and I need it updated to package f3d and exhibit
2025-05-21 14:41:53 <Saijin_Naib[m]> It also has no maintainer, so I can take it over once it is fixed up, but I think it needs a bunch of patches (not the current ones though)
2025-05-21 15:19:59 <fossdd|m> i would start with upgrading
2025-05-21 15:21:36 <fossdd|m> its a beast so good luck and i personally would be in favor of moving it to testing if no one cares to fix it
2025-05-21 15:22:04 <fossdd|m> so by all means, i hope that you succeed :)
2025-05-21 17:36:08 <witcher01> ptrc: thanks for fixing the gschemas.compiled thing in gnucash :)
2025-05-21 19:31:57 <realroot[m]> projectm-pulseaudio looks in /usr/local/share/... by default while projectm-presets installs in /usr/share/...
2025-05-21 20:48:35 <angeloverlain[m]> <dne> "it seems shared-runner x86-64.ci..." <- I think I'm the one that caused it, sorry.
2025-05-21 20:48:46 <angeloverlain[m]> because of !84540
2025-05-21 20:56:02 <ikke> angeloverlain[m]: it's fixed already
2025-05-21 20:57:41 <angeloverlain[m]> ikke: okay nice. I'll hold off trying to rerun that pipeline again (not sure if I'm the actual culprit)
2025-05-21 20:58:04 <ikke> nah, the cron job to clean up old builds was missing
2025-05-21 20:58:10 <ikke> so the server slowly filled up
2025-05-21 21:06:12 <angeloverlain[m]> okay
2025-05-21 21:06:19 <angeloverlain[m]> should I rerun the pipeline then?
2025-05-21 22:01:18 <Saijin_Naib[m]> @[fossdd|m] it honestly might be beyond me, unfortunately. It is failing compiling vendored depends. Gotta try using all-system depends first if I can, I guess
2025-05-21 22:01:46 <Saijin_Naib[m]> If I can figure it out, anyone want like $20 to help 😭
2025-05-21 22:02:01 <Saijin_Naib[m]> Cant, sorry
2025-05-21 22:04:07 <Saijin_Naib[m]> FreeCAD uses it, so it is important I get it working for that at least, nevermind for f3d and exhibit for me
2025-05-22 07:37:16 <ncopa> seems like chromium fails to build with new rust
2025-05-22 07:37:29 <ncopa> ld.lld: error: undefined symbol: __rustc::__rust_dealloc
2025-05-22 07:37:54 <ncopa> https://issues.chromium.org/issues/407024458
2025-05-22 08:45:40 <fossdd|m> ncopa: seems like https://chromium-review.googlesource.com/c/chromium/src/+/6439711 should fix that
2025-05-22 08:51:14 <ncopa> yeah. I would appreciate help with that. i have meetings today
2025-05-22 08:51:32 <ncopa> will try fix the py3-skia-pathops now
2025-05-22 08:51:34 <fossdd|m> sure i can take a look
2025-05-22 11:52:14 <Kladky> Btw, when moving some of my aports to testing, I accidnetially moved some of them into subdirectories, causing them to not be built. I have made merge requests fixing that: !84611 !84612 !84613 !84614
2025-05-22 11:52:36 <Kladky> Sorry about that
2025-05-22 12:08:31 <Kladky> s/to/from
2025-05-22 13:09:18 <mla> could someone merge or provide further feedback on !83007
2025-05-22 14:53:09 <khem> dalias:I am seeing an sign-compare warning/error when building seatd with clang/musl - https://gist.github.com/kraj/89c38d2b8570829d7796de87cbe70a10
2025-05-22 17:03:23 <rhizoome> these are getting old, the qa-bot starts complaining: !82447, !82251 and !82445 
2025-05-22 17:20:18 <ncopa> reported wezterm: https://github.com/wezterm/wezterm/issues/6984
2025-05-22 17:20:48 <ncopa> rhizoome: im kinda ignoring anyting in testing at the moment, due to we are working on 3.22 release
2025-05-22 17:33:36 <invoked> does wezterm use libssh2? i think it does. anyways, just a thought
2025-05-22 17:34:10 <ikke> rhizoome: just fyi, we won't close MRs that are just waiting for us
2025-05-22 19:56:03 <rhizoome> ikke: ncopa: np. it can wait.
2025-05-22 20:01:33 <angeloverlain[m]> does alpine have a system of "trusted contributors" such as postmarketOS? https://postmarketos.org/trusted-contributors/ It would be nice to know who to pester sometimes...
2025-05-22 20:02:49 <ikke> https://gitlab.alpinelinux.org/groups/team/developers/-/group_members
2025-05-22 21:55:33 <Ermine> seems like there's some nmi testsuite enabled in the kernel on boot, is this intentional?
2025-05-23 06:18:39 <ncopa> Ermine: probably not?
2025-05-23 06:31:59 <ncopa> Ihttps://github.com/wezterm/wezterm/issues/6984
2025-05-23 06:32:10 <ncopa> I'm gonna work on wezterm later today
2025-05-23 13:08:15 <pabloyoyoista|m> ncopa: regarding https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/84385#note_510087 and further similar comments
2025-05-23 13:08:25 <pabloyoyoista|m> Did the reply there satisfy you?
2025-05-23 13:10:10 <pabloyoyoista|m> We did in fact avoid the oposite on purpose, after several back and forth discussions with you and Sertonix
2025-05-23 13:10:35 <pabloyoyoista|m> So we're a bit confused now 😅
2025-05-23 13:15:01 <ncopa> my thinking is that we need to move it back at some point in the future? when we do should also update absolute paths to point to /usr?
2025-05-23 13:15:52 <ncopa> when /usr is merged, we will no longer get failures when absolute paths point "wrong", so they will be undetected
2025-05-23 13:16:08 <ncopa> and they will never be "cleaned up"
2025-05-23 13:16:31 <fossdd|m> i think we dont really have to. for "correctness" sure, but in the end the result will be exactly the same.
2025-05-23 13:16:47 <fossdd|m> the symlink isnt going likely never going away
2025-05-23 13:17:01 <pabloyoyoista|m> Does fakeroot depende on alpine-baselayout? I was under the impression that it does not
2025-05-23 13:17:13 <pabloyoyoista|m> And abuild will warn (we can even err in the future) for those paths
2025-05-23 13:17:35 <ncopa> so we are burning the bridge to revert /usr merge if we'd ever want
2025-05-23 13:17:50 <ncopa> anyway
2025-05-23 13:17:56 <ncopa> i need to work on 3.22 now
2025-05-23 13:18:15 <pabloyoyoista|m> I'm confused what does have be with the packging bug we're fixing 😅
2025-05-23 13:18:16 <ncopa> im thinking of some of those are relatively low risk
2025-05-23 13:19:00 <ncopa> i mean moving the busybox symlink to /usr is relative low risk in some of those cases?
2025-05-23 13:19:46 <pabloyoyoista|m> Yeah. The problem is that we've been shouted at before because the user base in alpine is big enough that low risk is still high 😅
2025-05-23 13:20:20 <pabloyoyoista|m> How we fix the issue is completely irrelevant for the usr merge
2025-05-23 13:20:40 <pabloyoyoista|m> We're just trying to fix it safest after we got multiple issues, and were asked to do things in another way
2025-05-23 13:25:26 <pabloyoyoista|m> We could do something like evaluate each of those for their risk, form an opinion, write patches conditionally to that, and then convince reviewers that X package is low risk
2025-05-23 13:26:44 <pabloyoyoista|m> I'm not sure that's helping anybody 😅
2025-05-23 13:45:49 <ncopa> is this needed before 3.22?
2025-05-23 13:51:34 <ncopa> i dont know whats up with protobuf and google-cloud-cpp. all of a sudden the tests have started to segfault
2025-05-23 13:51:41 <ncopa> but apparently they passed at some point
2025-05-23 13:52:06 <ncopa> so something changed in last week or so, that causes it to segfault
2025-05-23 13:58:15 <pabloyoyoista|m> We would really like to have it before 3.22, but I understand if there are other priorities
2025-05-23 13:58:16 <pabloyoyoista|m> I know the release process is not fun 😅
2025-05-23 13:59:13 <pabloyoyoista|m> Having all pre-existing packaging bugs fixed makes the whole usr-merge thing less risky
2025-05-23 13:59:36 <ncopa> e5d215a66e33714bfbec5131f47906ec2f59711a
2025-05-23 13:59:51 <ncopa> thats why it "passed" last time
2025-05-23 13:59:57 <ncopa> because it actually didnt pass
2025-05-23 14:01:10 <ncopa> pabloyoyoista|m: i think its gonna be a mess to clean it up afterwords, find all those places wher we mobed stuff to /bin and move it back
2025-05-23 14:01:26 <ncopa> i am afraid that this cleanup will be "forgotten" or ignored
2025-05-23 14:01:42 <pabloyoyoista|m> That's literally what we have the abuild error for
2025-05-23 14:02:03 <pabloyoyoista|m> But I mean, we've done all this work, we'll keep fixing mistakes, we've added all the MRs to the milestone
2025-05-23 14:02:22 <pabloyoyoista|m> I can promise we will go through the list reverting whatever needs to be reverted if that's the issue
2025-05-23 14:03:44 <pabloyoyoista|m> If you want that cleaned, and abuild does not catch those errors, we will fix them. That's part of the work we signed up for
2025-05-23 14:07:32 <ncopa> did google-cloud-cpp ever successfully build against protobuf-29.4?
2025-05-23 14:09:20 <ncopa> fossdd|m: do you remember if 76c09980c1bd10f8718dd10e84f27c18afcddf51 ever passed in CI?
2025-05-23 14:09:30 <fossdd|m> it didnt
2025-05-23 14:11:13 <psykose> the ci was missing some rebuilds in it i think
2025-05-23 14:11:19 <psykose> it was bumped afterward
2025-05-23 14:11:47 <ncopa> so we never had a successful build of google-cloud-cpp against protobuc 29.4
2025-05-23 14:11:53 <ncopa> protobuf*
2025-05-23 14:11:57 <psykose> nope
2025-05-23 14:12:02 <ncopa> and now it segfaults friday evening
2025-05-23 14:12:20 <psykose> and google-cloud-cpp has been out of date for a long time as well
2025-05-23 14:12:35 <ncopa> the update appears to also not build
2025-05-23 14:12:58 <psykose> yeah, it didn't build before protobuf too i think
2025-05-23 14:14:43 <sertonix[m]> I didn't have time to look at the /usr stuff recently. But I think that we should wait for some time after the merge was done to move binaries from /bin to /usr/bin.
2025-05-23 14:15:06 <ncopa> sh: ./APKBUILD: line 159: amove: not found
2025-05-23 14:15:06 <ncopa> sh: ./APKBUILD: line 160: amove: not found
2025-05-23 14:15:06 <ncopa> sh: ./APKBUILD: line 161: amove: not found
2025-05-23 14:15:06 <ncopa> sh: ./APKBUILD: line 162: amove: not found
2025-05-23 14:15:06 <ncopa> sh: ./APKBUILD: line 163: amove: not found
2025-05-23 14:16:52 <ncopa> who wants to fix google-cloud-cpp/protobuf?
2025-05-23 14:17:12 <pabloyoyoista|m> Sertonix: that would make sense. I'll open an issue and set it to start-time 1 release after the /usr merge. Then assign it to Clayton and me
2025-05-23 14:17:34 <psykose> i can try reproduce google-cloud-cpp locally first and see if it's obvious
2025-05-23 14:18:00 <ncopa> i have a gdb backtrace
2025-05-23 14:18:13 <ncopa> its not obvious
2025-05-23 14:18:55 <psykose> show
2025-05-23 14:19:15 <ncopa> im running out of time
2025-05-23 14:19:22 <ncopa> need to run in a few mins
2025-05-23 14:19:42 <ncopa> i can probably post it somewhere later tonight
2025-05-23 14:19:53 <psykose> sure
2025-05-23 14:20:39 <ncopa> https://tpaste.us/QK7l
2025-05-23 14:20:46 <ncopa> protobuf is built with debugging
2025-05-23 14:27:00 <socksinspace> sertonix[m]: fossdd|m you two seem to have more opinions on !74816 than i do, which direction should i contiunue with that mr?
2025-05-23 14:27:59 <fossdd|m> which directions do you mean?
2025-05-23 14:28:24 <fossdd|m> regarding "explictly mention which langs to enable" vs ".. to disable"?
2025-05-23 14:29:26 <socksinspace> that too, but just in general, since i was mostly interested in deactivating D for getting in the way of bootstrp builds, while you two actually want to fix the problems :)
2025-05-23 15:29:46 <Ermine> ncopa: re nmi test suite, i can probably patch it out
2025-05-23 18:31:39 <ncopa> Ermine: already did 335152d6a955a797d6bbf6e7ddbc685d23df9883
2025-05-23 18:36:25 <ncopa> libgpod broke. I suspect the recent m4 update
2025-05-23 18:37:55 <mio> !84650
2025-05-23 19:29:24 <Ermine> ncopa: thank you
2025-05-23 23:35:55 <sertonix[m]> socksinspace: I did fix the issue but wanted to wait for upstream to accept the MR before backporting
2025-05-24 07:47:41 <socksinspace> sertonix[m]: that will be a separate MR to what i am doing then?
2025-05-24 09:05:19 <sertonix[m]> I am uncertain what yoz mean with separate. If we fix the issue your MR would be superseded.
2025-05-24 09:05:37 <sertonix[m]> s/yoz/you/
2025-05-24 09:09:12 <socksinspace> yes, my MR will be superseded, should i close it now, or will that happen when you make a new MR?
2025-05-24 18:19:33 <e510> hi
2025-05-24 18:19:56 <e510> who online
2025-05-24 18:20:07 <e510> türk varmı
2025-05-25 06:24:36 <Saijin_Naib[m]> If anyone uses GOG for games, I'd love a review/merge/usage test for !84710
2025-05-25 06:24:48 <Saijin_Naib[m]> I am (naively) hoping I can tackle Lutris next
2025-05-25 06:25:39 <Saijin_Naib[m]> Minigalaxy seems to work fairly well here, but not all WINE games run, but then again, I can't run Sonique Media Player on this machine under WINE but I can on my desktop so :shrug:
2025-05-25 06:29:54 <Saijin_Naib[m]> After I clear the builder failures, natch
2025-05-25 09:33:47 <buinb> Saijin_Naib[m], does Sonique even run on actual current Windows? :D
2025-05-25 13:14:09 <kchr> oh man, sonique. the pinnacle of UI design :-)
2025-05-25 13:33:47 <Saijin_Naib[m]> buinbYep, has been working perfectly fine since Windows 95, haha, even onto current Windows 11
2025-05-25 13:34:20 <Saijin_Naib[m]> kchrYou don't even know! I have my own skins from when I was like, 10
2025-05-25 13:34:25 <Saijin_Naib[m]> The visualizers are really what I love most
2025-05-25 13:34:35 <Saijin_Naib[m]> milkdrop/projectm just doesnt match
2025-05-25 16:52:58 <Saijin_Naib[m]> !84725 is ready for testing if anyone is super bored
2025-05-25 16:53:21 <Saijin_Naib[m]> mio already gave me great feedback on runtime deps I missed just by having a pretty extensive apk world, so if you run into anything, please do let me know
2025-05-25 17:08:24 <fossdd|m> aaaaaaa
2025-05-25 17:08:25 <fossdd|m> Error relocating /usr/bin/node: EVP_MD_CTX_get_size_ex: symbol not found
2025-05-25 17:10:21 <fossdd|m> oh was apparently missing a apk upgrade
2025-05-25 17:49:59 <Barnaba> Hello, 
2025-05-25 17:50:28 <Barnaba> anybody here ?
2025-05-25 17:53:08 <Barnaba> I found intresting to do init system based on MicroPython: https://github.com/tools200ms/mpy_init
2025-05-25 17:53:39 <Barnaba> I see Alpine as a good base for this project
2025-05-25 17:57:02 <Saijin_Naib[m]> That does seem neat
2025-05-25 17:57:34 <Saijin_Naib[m]> Is compatibility or translation of OpenRC services or systemd units a goal?
2025-05-25 17:57:59 <buinb> “shell scripts can be replaced by Python code that is easier to read and audit” proof needed
2025-05-25 17:59:36 <buinb> Ah, it actually doesn't exist yet
2025-05-25 18:01:19 <Saijin_Naib[m]> I just follow Alpine defaults, so I learned enough OpenRC to start my stuff
2025-05-25 18:01:28 <Saijin_Naib[m]> When we go s6, I'll do that
2025-05-25 18:06:39 <skarnet> with the next release of OpenRC you'll be able to use supervisor=s6 and it will work the exact same way as with OpenRC's supervise-daemon today
2025-05-25 18:07:28 <skarnet> I'm now in the process of writing a higher level interface to s6, similar to openrc's "service foobar start"
2025-05-25 18:08:13 <skarnet> then submit a plan to let users choose their service manager
2025-05-25 18:08:36 <skarnet> if all goes well, it will be possible this year :)
2025-05-25 18:14:59 <Barnaba> what is git link for that s6 project you wrok on ?
2025-05-25 18:16:33 <Barnaba> It's that, isn't: https://github.com/skarnet/s6 ?
2025-05-25 18:26:25 <Saijin_Naib[m]> @skarnet this sounds amazing! Thank you for all your work on this
2025-05-25 18:26:52 <skarnet> Barnaba: that's the github mirror, yes. The original is here: https://cgit.skarnet.org/s6
2025-05-25 18:27:42 <skarnet> Saijin_Naib[m]: don't thank me, I'm way overdue on this, I've been promising it for years.
2025-05-25 18:45:04 <Saijin_Naib[m]> @skarnet oh in that case, hurry the f up 🤣
2025-05-25 18:45:15 <Saijin_Naib[m]> I demand my money's worth
2025-05-25 18:48:37 <Saijin_Naib[m]> (Not being serious, btw)
2025-05-25 19:19:45 <Barnaba> @skarnet I can contribue
2025-05-25 19:58:18 <skarnet> Barnaba: thank you, I really appreciate it! You can join us on #s6. But to be fully honest, I'm not looking for contributors atm, because it's a design/coding phase and I generally do these alone; I tap the community a bit later, for feedback, testing, use cases I forgot, etc.
2025-05-25 21:32:58 <Saijin_Naib[m]> @skarnet have you used s6 as init/supervisor (whole suite/stack) on alpine x86_64 with qemu/libvirt guests? 
2025-05-25 21:33:38 <Saijin_Naib[m]> I ask because with OpenRC, I can only get the services to start and not crash if I use rc_parallel
2025-05-25 21:34:23 <Saijin_Naib[m]> My understanding of s6 as a supervisor is that it can start/restart stuff on its own and prevent something like the above?
2025-05-25 21:34:45 <ptrc> probably a long shot, but has anyone looked into implementing recommended packages in apk-tools / apk format?
2025-05-25 21:34:48 <Saijin_Naib[m]> It doesnt work every boot, either 😭
2025-05-25 21:37:31 <ptrc> also
2025-05-25 21:37:33 <ptrc> $ doas apk upgrade -Uai  NOTE: Consider running apk upgrade with --prune and/or --available.
2025-05-25 21:38:07 <ptrc> i believe that note should not show up when -a is passed
2025-05-25 21:42:56 <psykose> ptrc: https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/2089f8a8225b812c982cd253aa5fcd74d5099c3a
2025-05-25 21:43:08 <fossdd|m> it just adds the field
2025-05-25 21:44:06 <fossdd|m> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11066#note_510612
2025-05-25 22:42:58 <ptrc> oh huh, good timing
2025-05-25 22:43:08 <ptrc> but then, not used for anything just yet :/
2025-05-25 23:34:07 <fossdd|m> yeah i mean there isnt even a concept what it should actually do afaik
2025-05-25 23:36:06 <fossdd|m> i think https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10722 is the relates issue
2025-05-26 05:05:08 <skarnet> Saijin_Naib[m]: I haven't explicitly used it with qemu/libvirt, but unless there's a bug in these, it should make no difference to s6 at all. And it should also be true for OpenRC, unless OpenRC uses nonportable constructs (which is possible, I'm not sure). I would look at your services architecture first and the backend second, tbh.
2025-05-26 05:06:12 <skarnet> (but rc_parallel doesn't work well, that is known, so if you can find a way to start your services *without* rc_parallel that should help)
2025-05-26 05:25:08 <Saijin_Naib[m]> Yeah, no, amazingly, they only ever sort of work with rc_parallel, so there is some timing/race thing happening with order of services starting and requires/depends/waits I guess
2025-05-26 05:26:28 <Saijin_Naib[m]> In any case, from what I've read on your site, I think s6 will be more robust for my (very basic) desktop usage
2025-05-26 05:26:57 <skarnet> yeah if your set of services *only* works with rc_parallel then there's definitely something cursed going on in it :P
2025-05-26 05:28:13 <Saijin_Naib[m]> That's my life! I just reboot until they all start so I can run the Windows VM I need to publishs software
2025-05-26 05:30:01 <skarnet> then yeah you may benefit from s6, it will restart all your processes until they eventually succeeds. Not the best way to get there, but it will get you there. :P
2025-05-26 05:30:19 <skarnet> s/succeeds/succeed/
2025-05-26 06:23:11 <Saijin_Naib[m]> I'm over my head here, and could use a pointer
2025-05-26 06:24:21 <Saijin_Naib[m]> I'm enabling tests for minigalaxy, and the test_ui_window.py is failing because python can't find Gtk.Dialog
2025-05-26 06:24:58 <Saijin_Naib[m]> I tried adding gtk+3.0-dev to checkdepends, as well as py3-gobject3 to checkdepends, but neither satisfies that test. I am missing something obvious here, but I can't figure out how to find what provides that class
2025-05-26 06:25:29 <skarnet> can't help yo with that, sorry
2025-05-26 06:25:32 <skarnet> you*
2025-05-26 06:26:50 <Saijin_Naib[m]> haha, that's okay, you're busy making s6 so I can use computer, so you're off the hook
2025-05-26 07:02:43 <Saijin_Naib[m]> !84710 and !84725 fixed up and out of draft
2025-05-26 12:07:18 <jvvv> sertonix[m]: I added a suggested change to the patch for !83165. Works for me when I test it locally.
2025-05-26 15:19:49 <elagost> would someone mind reviewing !84059 ?
2025-05-26 15:46:57 <Riolku> Hello! Please redirect me if this is a bad place to ask package related questions. I'm trying to build a package of hedgedoc.org for my personal use. It's a big nodejs application. I'm primarily following the steps of https://docs.hedgedoc.org/setup/manual-setup, but when tracing dependencies abuild gives "ERROR: hedgedoc*: libc.so.6: path not found". Any ideas?
2025-05-26 15:48:14 <ikke> It means it tries to install binaries linked to glibc
2025-05-26 15:53:01 <elagost> Riolku: either because you're putting some downloaded test programs in $pkgdir or something. Might want to back up node_modules after install, before running any tests, then restore it after the tests are done. Sometimes testing suites pull down binaries that are linked to glibc.
2025-05-26 15:53:33 <Riolku> Hmmmmm ok, how can i quickly locate the glibc binary?
2025-05-26 15:53:48 <Riolku> & if its necessary at runtime, ig i just add a glibc dep?
2025-05-26 15:55:14 <Riolku> mm gcompat at least lets the package build
2025-05-26 15:56:48 <vmignot> Seems like mesa is currently broken on master
2025-05-26 15:57:01 <elagost> it's probably not necessary at runtime; can you share the APKBUILD?
2025-05-26 15:59:03 <Riolku> https://0x0.st/8xfY.txt is my WIP
2025-05-26 15:59:17 <Riolku> I need to clean out a lot of stuff from the pkgdir, I plan to follow https://wiki.alpinelinux.org/wiki/APKBUILD_examples:JavaScript
2025-05-26 16:01:16 <elagost> you may want to check out the setup script and run some parts of that manually, and not run others, depending on what it does
2025-05-26 16:03:06 <Riolku> It primarily just runs `yarn workspace focus --production` it seems
2025-05-26 16:03:49 <Riolku> And then some stuff i dont care about (checking up to date node version, copy config.json.example)
2025-05-26 16:04:11 <Riolku> Mostly figured using bin/setup is nicer for avoiding issues when upgrading? In case the script changes
2025-05-26 16:17:26 <Riolku> ./src/hedgedoc-1.10.3/node_modules/sqlite3/build/Release/node_sqlite3.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped
2025-05-26 16:17:53 <Riolku> It would be this... I imagine this actually does need to be around at runtime
2025-05-26 16:20:09 <elagost> Riolku: the bin/setup script says "If you want to build the frontend yourself, you need to run 'yarn install --immutable' before 'yarn build' to install the devDependencies for the build process." so you probably do want to build the frontend yourself.
2025-05-26 16:21:01 <Riolku> maybe... it's optional bc the release tarball has the frontend in it as of 1.7.0 i think
2025-05-26 16:21:58 <elagost> that's likely the bit that's dependent on glibc.
2025-05-26 16:24:49 <Riolku> It wouldnt be the sqlite3 node dependency i mentioned? 
2025-05-26 16:25:38 <Riolku> The frontend precompiled in public/ and contains a bunch of static files
2025-05-26 16:30:25 <Riolku> ah the sqlite3 module is pulling a prebuilt binary
2025-05-26 16:31:06 <elagost> yeah this is a frequent problem with nodejs applications...
2025-05-26 16:31:49 <Riolku> mmk I think I have the info to figure out this mess now ty for your help :)
2025-05-26 16:40:29 <elagost> o7
2025-05-26 17:30:35 <omni> hmm... I wonder why I now, and since when, manually have to mount filesystems in my fstab that are on ZVOLs..
2025-05-26 18:00:00 <omni> and `doas mount -vfa` says mount: according to /proc/mounts, /dev/zvol/zpool/X/Y/Z is already mounted on /X/Y/Z
2025-05-26 18:00:41 <omni> but the folders are empty until I manually `doas mount /X/Y/Z` for each of them
2025-05-26 18:03:08 <ikke> is the zfs-mount service enabled?
2025-05-26 18:06:27 <omni> yes, at boot, but I don't think that is needed for this, since these are ext4 filesystems on zfs volumes
2025-05-26 18:08:20 <omni> I run root on zfs but these are additional mounts like that for.. reasons
2025-05-26 18:08:29 <omni> and it has been working for years
2025-05-26 18:22:06 <omni> unfortunately I haven't taken snapshots often enough lately
2025-05-26 18:41:24 <omni> ok, in my hunt for finding what it was, it went away
2025-05-26 18:42:05 <omni> I keep a cache of previously installed .apk files, tried downgrading linux, reboot, still the same issue
2025-05-26 18:43:32 <omni> then upgraded the kernel again, rebooted, issue still there, downgraded openrc to 0.62.2-r0 followed by doas mkinitfs $(/bin/ls /lib/modules) and the issue went away
2025-05-26 18:44:49 <omni> "aha!", I thought, and upgraded openrc to 0.62.2-r1 followed by mkinitfs and rebooted, still no issue, and then the same for the current version of openrc, 0.62.2-r2, and the issue is still gone
2025-05-26 18:45:14 <omni> very frustrating, but I guess I should be happy that the issue is gone
2025-05-26 18:45:59 <omni> I just think that's the worst, when things stop working and then start working again, without you having an idea what caused it
2025-05-26 18:46:17 <ikke> Indeed
2025-05-26 19:49:20 <ncopa> elagost: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/84059 LGTM but its still draft?
2025-05-26 20:08:17 <ncopa> need to get the 3.22 builders pass tomorrow morning so we can create rc1
2025-05-26 20:17:21 <sertonix[m]> valgrind is broken on s390x as far as I can tell. This makes debugging of some issues a lot harder than on other arches. Does anybody have an idea how to fix that?
2025-05-26 20:18:14 <sertonix[m]> (Also I think we aren't actually running any valgrind tests, just building them)
2025-05-26 23:55:30 <elagost> ncopa: thanks for review, marked 84059 as ready. Had not noticed it was still a draft.
2025-05-27 03:58:21 <qaqland> Nodejs does not use the llhttp provided by the system, but instead uses a statically linked internal version.
2025-05-27 03:58:29 <qaqland> Is there any specific consideration behind this?
2025-05-27 05:03:51 <qaqland> i got it :)
2025-05-27 08:31:14 <p_6f3Ik7Suw> TFW someone asks a question on the internet, and then a follow-up "gotit" or "solved", but not the answer itself...
2025-05-27 10:48:23 <ncopa> I have opened an issue for the 3.22/main dependency graph: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17191
2025-05-27 14:21:39 <ncopa> reminder that i will try hard to get 3.22 out this week
2025-05-27 14:22:09 <ncopa> was hoping to get rc1 out today
2025-05-27 14:23:31 <ncopa> things that gets in the way risk to be deleted/disabled
2025-05-27 14:24:24 <ncopa> or reverted
2025-05-27 14:31:09 <omni> would it be ok to still merge things in testing/ during this phase?
2025-05-27 14:33:23 <fossdd|m> i think its fine to merge anything aslong its not related to the toolchain
2025-05-27 14:33:39 <fossdd|m> at least this was the case the last releases iirc
2025-05-27 14:35:27 <ncopa> its fine to merge things to testing, unless it is a huge build, which takes hours to compile
2025-05-27 14:35:44 <ncopa> i would prefer that we wait with testing til 3.22 is out though
2025-05-27 14:35:58 <omni> how do we know if builders pass if they are not allowed to be idle?
2025-05-27 14:36:11 <ncopa> ?
2025-05-27 14:36:39 <omni> why I thought it could still maybe be ok to merge things to testing/ as that won't be run on the 3.22 builders
2025-05-27 14:37:35 <omni> but I could move my hands to some other projects for a while
2025-05-27 14:38:30 <omni> ncopa: you said you wanted the 3.22 builders to pass so that you could cut rc1
2025-05-27 14:39:49 <ncopa> right, but they will consume CPU resources and CI runners so the other stuff may end up wait
2025-05-27 14:43:29 <omni> maybe !84688 could go in, if it is in order, it doesn't take half a minute to build
2025-05-27 14:44:27 <omni> and nushell should pass on ppc64le next time around
2025-05-27 14:44:37 <omni> so I'll move to other stuff for a while
2025-05-27 16:45:47 <rhizoome> after a scary situation with a upgrade I did. I'd like to find the origin of packages that depend on the package I am working on (and build them). I scripted it so far: apk list -d py3-click | spy -l 'pipe.partition(" ")[0]'. Is there a way to get this out of apk or do I have to match with the directory names? (apk list -o py3-click does not want I wanted)
2025-05-27 16:57:04 <jahway603[m]> What's the best way to add new a new aport which depends on other new aports? I'm talking about !84830, which relies on two new other packages I opened MRs for. Or should these 3 new aports all be in the same MR?
2025-05-27 16:58:47 <omni> jahway603[m]: best would be to add the dependencies in the same MR, as separate "new aport" commits, that way you can early discover potential issues you would otherwise hit later and also get it in faster
2025-05-27 16:59:24 <omni> as those dependencies are available to build the main aport you want to add
2025-05-27 18:23:27 <rhizoome> the orgin is in the default output! :-)
2025-05-27 18:31:30 <rhizoome> all the source of packages that depend on py3-click: apk list -d py3-click | spy -l 'pipe.partition(" ")[0].rpartition("-")[0].rpartition("-")[0]' | xargs apk list | spy -l 'pipe.partition("{")[2].partition("}")[0]' | sort -u
2025-05-27 18:31:48 <rhizoome> s/source/origins/
2025-05-27 21:15:05 <ncopa> alright, I'll tag rc1 tomorrow
2025-05-27 21:15:16 <fossdd|m> nice thanks for your work :3
2025-05-27 21:15:43 <omni> ok!
2025-05-27 23:26:20 <omni> user reports /etc/dovecot/dovecot.conf missing after an upgrade
2025-05-27 23:26:26 <omni> https://pkgs.alpinelinux.org/contents?file=&path=&name=dovecot&branch=v3.21&repo=main&arch=aarch64
2025-05-27 23:26:32 <omni> https://pkgs.alpinelinux.org/contents?file=&path=&name=dovecot&branch=edge&repo=main&arch=aarch64
2025-05-28 04:50:57 <jvvv> sertonix[m]: I've posted the correct patch for docbook2mdoc that should fix up !83165. sorry for delay.
2025-05-28 05:23:19 <ncopa> tagged 3.22.0_rc1
2025-05-28 05:23:57 <ncopa> will try tag new release of alpine-conf, mkinitfs etc asap and do rc2
2025-05-28 07:36:15 <ovf> gitlab frontend is kill
2025-05-28 07:41:14 <ovf> ah no, just timeouts on log filtering, e.g. https://gitlab.alpinelinux.org/alpine/aports/-/commits/master/testing/quodlibet/APKBUILD
2025-05-28 08:10:06 <omni> anubis on gitlab.gnome.org doesn't work for me, but it does on other sites
2025-05-28 08:10:56 <omni> (and I'm not using old 87-based chromium atm :p)
2025-05-28 08:13:33 <macmpi> testing 3.22.0_rc1 on Pi: wifi seems very unstable: known issue?
2025-05-28 08:23:30 <ncopa> maybe the firmware is not updated?
2025-05-28 08:23:36 <ncopa> not a known issue
2025-05-28 08:51:36 <macmpi> ncopa: hum... exact same firmware files than in working good 3.21 setup (dmesg | grep brcmf identical)
2025-05-28 08:54:05 <macmpi> wpa_supplicant ?
2025-05-28 09:07:36 <fossdd|m> omni: you basically need the very latest chromiu
2025-05-28 09:08:24 <f_> in the past gnome gitlab's anubis had blocked me entirely, but now it seems working fine
2025-05-28 09:08:28 <f_> Have not changed anything I think
2025-05-28 09:08:56 <omni> fossdd|m: so 122-based is not new enough?
2025-05-28 09:09:14 <omni> it works with anubis everywhere else
2025-05-28 09:09:26 <f_> omni: What does it say?
2025-05-28 09:09:38 <f_> does it say something along the lines of "access denied" or?
2025-05-28 09:09:38 <omni> it just stays there and does nothing
2025-05-28 09:09:46 <omni> the progressbar doesn't move
2025-05-28 09:09:50 <f_> hmm
2025-05-28 09:10:04 <omni> "Difficulty: 4, Speed: 0kH/s" forever
2025-05-28 09:10:24 <fossdd|m> maybe reload? idk
2025-05-28 09:10:30 <omni> no
2025-05-28 09:10:56 <f_> very strange
2025-05-28 09:11:15 <f_> but not the first time I (hear of) having issues with gitlab.gnome.org's anubis
2025-05-28 09:49:43 <DWwanghao> omni:Me too. When accessing gitlab.gnome.org, it shows 'Difficulty: 4, Speed: 0kH/s', but sometimes it suddenly unblocks at night and works normally.
2025-05-28 10:02:11 <macmpi> ncopa: wpa_supplicant connects a little while, then fails, retries for long period, connects again and fails again shortly after, etc.... Can see pings on other end working/failing
2025-05-28 10:03:02 <macmpi> wlan0: Authentication with 5c:7b:5c:b3:3b:36 timed out.
2025-05-28 10:03:02 <macmpi> nl80211: send_event_marker failed: Source based routing not supported
2025-05-28 10:03:02 <macmpi> wlan0: CTRL-EVENT-DISCONNECTED bssid=5c:7b:5c:b3:3b:36 reason=3 locally_generated=1
2025-05-28 10:03:02 <macmpi> wlan0: Added BSSID 5c:7b:5c:b3:3b:36 into ignore list, ignoring for 10 seconds
2025-05-28 11:13:13 <Kladky> omni: Check browser logs
2025-05-28 11:13:39 <Kladky> Only case I've had that happen when it's not a secure context (i.e. not HTTPS)
2025-05-28 12:05:02 <omni> sure, but I have more important things to debug, it's just annoying
2025-05-28 12:13:22 <ncopa> TIL that busybox `dd bs=32 skip=96 count=1` is unreliable when input is a pipe. You may or may not get full block
2025-05-28 12:14:04 <ncopa> while GNU dd sets iflag=fullblock if in put file handle is pipe
2025-05-28 12:37:15 <ncopa> and of course are all the CI runners busy when you need them
2025-05-28 12:42:12 <ikke> Sorry
2025-05-28 12:56:34 <ncopa> no worries
2025-05-28 14:47:03 <Kladky> I'm guessing no one has automated aport bumping beyond rss feed + abump wrapper?
2025-05-28 14:49:09 <orbea> Kladky: automated aport bumping would be bad if an upstream ever becomes compromised
2025-05-28 14:50:24 <Kladky> I mean, do people actually check the new code in releases of software before they bump the aport?
2025-05-28 14:51:06 <Kladky> As xz has shown, manual bumping isn't gonna mean comprimises are suddenly gonna be detected.
2025-05-28 14:51:23 <orbea> it increases the chances they are
2025-05-28 14:51:36 <Kladky> Barely.
2025-05-28 14:51:49 <orbea> i dont maintain packages for alpine, but I do look at what changed between releases
2025-05-28 14:51:59 <Kladky> The actual code?
2025-05-28 14:52:05 <Kladky> Or just the changelog?
2025-05-28 14:52:08 <orbea> yes, github makes it easy by showing diffs
2025-05-28 14:52:46 <Kladky> Ok, nice, but I can gaurentee you are in a tiny minority, but good on you ig.
2025-05-28 14:53:23 <orbea> i cant speak for other distro package maintainers, but I imagine at least some of them do similar
2025-05-28 14:54:01 <Kladky> Maybe some that maintain a few, but once you're in the 10s of packages you maintain, you really don't have time to do that for every package.
2025-05-28 14:55:03 <orbea> im usually only updating a few at the time at most
2025-05-28 14:55:14 <lotheac> you're not making a very strong argument by just asserting that everyone except a "tiny minority" acts a certain way
2025-05-28 14:55:51 <lotheac> i mean, even if you're right, then what?
2025-05-28 14:57:34 <Kladky> My point is that automating upgrades won't suddenly make QA drop to the floor, since there really isn't much QA in the first place.
2025-05-28 14:57:48 <Kladky> Or in this case, make security of comprimise drop.
2025-05-28 14:58:49 <Kladky> But on the other hand, it means that people get up to date packages faster, which not only helps upstream by them not getting reports due to issues of outdated versions, but can also improve security in case of security releases.
2025-05-28 14:59:46 <Kladky> Anyways, I'm not proposing package upgrades to be merged automatically.
2025-05-28 14:59:55 <lotheac> i am not trying to say "don't automate upgrades" - of course you're free to implement anything you want :) but what is the point in speculating?
2025-05-28 15:00:00 <Kladky> Just for the merge requests themselves to be created automatically.
2025-05-28 15:00:29 <Kladky> lotheac: I am just asking so I don't re-implement something that already exists.
2025-05-28 15:00:48 <lotheac> fair enough
2025-05-28 15:01:14 <fossdd|m> Kladky: mrs do require a certain amount of manual interaction, e.g. reviewing changelogs, check abuild's warnings and errors, check file diff, sodiff, etc
2025-05-28 15:01:25 <lotheac> i would not personally use a thing that automates abump, i feel it removes maintainer agency
2025-05-28 15:01:30 <lotheac> others may have different opinions
2025-05-28 15:02:01 <fossdd|m> i have a single command that basically checkouts master, creates a new branch, abumps, pushes and creates a new draft MR
2025-05-28 15:02:15 <Kladky> fossdd|m: Like I said, I am just considering automatic creation of bump MRs, not automatically merging
2025-05-28 15:02:15 <fossdd|m> but i would be careful with anything further
2025-05-28 15:03:05 <fossdd|m> you still should check the mentioned points, the merger will do it aswell, but i dont think you want this back-and-fourth
2025-05-28 15:03:22 <Kladky> Hmm, surprised there is so much pushback.
2025-05-28 15:03:41 <Kladky> Would have thought people would have wanted automation like scoop and nix do.
2025-05-28 15:05:19 <fossdd|m> im just saying that imo there should to be some manual interaction before passing it over to the merger, at least thats what i would do myself, i'm not trying to push things back, i'd love to find out ways to make bumping versions easier but imo not with skipping changelogs etc
2025-05-28 15:05:48 <lotheac> don't let a few comments stop you from implementing your idea if you think it's good. worst case you can use it yourself even if nobody else does?
2025-05-28 15:06:12 <lotheac> it's hard to review a thing that does not exist
2025-05-28 15:14:08 <orbea> ^
2025-05-28 15:32:41 <invoked> it would be nice to have a pkgdiff type thing
2025-05-28 15:37:11 <fossdd|m> you mean like checkapk?
2025-05-28 16:08:01 <qaqland> like this: https://github.com/lvc/pkgdiff ?
2025-05-28 16:10:06 <ikke> https://diffoscope.org/
2025-05-28 16:10:34 <ikke> Although that does not seem to support alpine apk files
2025-05-28 16:15:24 <invoked> oh, hadn't seen diffoscope. thanks
2025-05-28 16:16:16 <invoked> ~300 releases, i'm evidently living under a rock
2025-05-28 16:20:29 <invoked> but ... yeah. i would blindly bump some things when i was at gentoo. not proud of that. a good diff tool seems important
2025-05-28 16:24:27 <invoked> also hugo was asking about a tool to make reproducible tarballs.
2025-05-28 16:24:38 <prabu> updated v3.21 installation to v3.22rc1 and everything works great..
2025-05-28 16:25:13 <prabu> OpenRC User services works great for pipewire and wlsunset
2025-05-28 16:26:36 <fossdd|m> can someone merge !84674?
2025-05-28 16:35:47 <omni> perhaps mergiraf could be taught the language of APKBUILD
2025-05-28 18:46:33 <fossdd|m> <omni> perhaps mergiraf could be taught the language of APKBUILD
2025-05-28 18:46:33 <fossdd|m> woah that would be awesome
2025-05-28 18:47:04 <fossdd|m> that would also help with having "backports" labels to MRs and a bot can automatically rebase it to stable versions
2025-05-28 18:47:36 <fossdd|m> (https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/20)
2025-05-28 19:16:04 <leg> new aport: femto editor. pipeline fails because on several architectures pandoc is not available. pandoc is minor build depency for documentation of femto. Recommendations?
2025-05-28 19:16:43 <ikke> You could only enable documentation on architectures where pandoc is available
2025-05-28 19:18:18 <leg> ok - I see: pandoc-cli is available on all architectures. I'll try again
2025-05-28 19:19:26 <ikke> Is it? https://pkgs.alpinelinux.org/packages?name=pandoc-cli&branch=edge&repo=&arch=&origin=&flagged=&maintainer=
2025-05-28 19:19:56 <leg> Yes
2025-05-28 19:20:25 <ikke> I only see aarch64 and x86_64
2025-05-28 19:21:26 <leg> Oh: I went to the commit of pandoc-cli, and they build on all pipelines. Why are they not on pkgs then?
2025-05-28 19:22:24 <ikke> # limited by ghc
2025-05-28 19:22:26 <ikke> arch="aarch64 x86_64"
2025-05-28 19:22:40 <ikke> Note that the pipeline will create jobs for all arches, even if it's not enabled on that arch
2025-05-28 19:26:20 <leg> A hint on how to selectively enable documentation for specific archictectors (I'll RTFM though)
2025-05-28 19:27:25 <ikke> case $CARCH in; x86_64|aarch64) subpackages="$subpkgs $pkgname-doc";; esac
2025-05-28 19:27:53 <ikke> (but without the typos and on multiple lines)
2025-05-28 19:28:58 <leg> thanks so much!
2025-05-28 19:34:20 <realroot[m]> i searched femto on gitla.alpine but i did not find it.
2025-05-28 19:35:03 <realroot[m]> since it was discussed here does somebody have the link?
2025-05-28 19:35:11 <ikke> !84918
2025-05-28 19:51:28 <leg> femto piplines are all green now, thanks.
2025-05-28 21:22:41 <ncopa> tagged 3.22.0 rc2 now
2025-05-28 21:35:48 <psykose> edge-aarch64 seems missing
2025-05-28 21:43:38 <omni> yes
2025-05-28 22:53:36 <ffoss> Any obvious reason this mako userservice doesn't properly work? https://tpaste.us/Xv48
2025-05-28 22:54:15 <ffoss> GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
2025-05-28 22:54:15 <ffoss> notify-send "yo"
2025-05-28 22:58:00 <psykose> is wayland_display set in it
2025-05-28 23:53:20 <ffoss> .config/rc/rc.conf has: rc_env_allow="WAYLAND_DISPLAY"
2025-05-28 23:53:52 <ffoss> then in sway config i set `exec openrc --user gui` instead of `exec mako`
2025-05-28 23:56:58 <ffoss> just having `exec mako` worked, not even after restarting it
2025-05-28 23:57:38 <ffoss> "..., but not as a service, not even ..."*
2025-05-29 06:44:36 <ncopa> i restarted build-edge-aarch64
2025-05-29 09:43:52 <Kladky> What would be the best way to try out the rc? Is there some repo url for it?
2025-05-29 09:47:01 <ikke> https://cdn.alpinelinux.org/v3.22/releases/
2025-05-29 09:47:10 <ikke> https://cdn.alpinelinux.org/v3.22/main/
2025-05-29 10:09:41 <Kladky> Thanks
2025-05-29 10:13:26 <Kladky> I get the following error when upgrading from v3.21: https://tpaste.us/Lyaa
2025-05-29 10:13:40 <ncopa> ikke: reminds me, it is probably time to apply the Fastly config to "merge" dl-cdn.a.o and cdn.a.o
2025-05-29 10:14:04 <Kladky> And now I can't run apk
2025-05-29 10:14:12 <Kladky> Whenever I do, I get that error
2025-05-29 10:14:51 <Kladky> Error relocating /usr/lib/libapk.so.2.14.9: EVP_MD_CTX_get_size_ex: symbol not found
2025-05-29 10:14:52 <Kladky> Error relocating /sbin/apk: EVP_MD_CTX_get_size_ex: symbol not found
2025-05-29 10:14:58 <ikke> Kladky: can you provide the apk upgrade output?
2025-05-29 10:15:35 <ikke> Kladky: you can download apk.static from https://gitlab.alpinelinux.org/alpine/apk-tools/-/releases
2025-05-29 10:15:54 <Kladky> ikke: https://tpaste.us/ZKka
2025-05-29 10:16:23 <ncopa> did you upgrade from 3.21?
2025-05-29 10:16:39 <Kladky> Yes
2025-05-29 10:16:52 <ncopa> let me try to reproduce that
2025-05-29 10:17:01 <Kladky> 3.21.3
2025-05-29 10:17:14 <ncopa> you also have edge repo there
2025-05-29 10:17:27 <Kladky> Yeah, testing edge repo
2025-05-29 10:18:05 <ncopa> oh
2025-05-29 10:18:07 <ncopa> hm
2025-05-29 10:18:16 <ikke> Seems to be related to openssl
2025-05-29 10:18:19 <ncopa> yes
2025-05-29 10:18:32 <ncopa> good catch
2025-05-29 10:18:35 <ncopa> i think what happens is
2025-05-29 10:18:40 <ncopa> apk will self upgrade
2025-05-29 10:18:47 <ncopa> but the self upgrade will not upgrade openssl
2025-05-29 10:19:23 <ncopa> so old openssl is installed, trying to run new apk which was linked to old openssl
2025-05-29 10:19:47 <ncopa> i think we can fix that by adding a versioned dependency
2025-05-29 10:20:20 <ikke> yes, that would make sense
2025-05-29 10:20:37 <ncopa> how do we test this
2025-05-29 10:20:42 <Kladky> I'll reset the repos back to 3.21 and downgrade
2025-05-29 10:20:46 <Kladky> then try again
2025-05-29 10:20:55 <Kladky> with apk upgrade -a, right?
2025-05-29 10:20:56 <ncopa> same will probably happen again
2025-05-29 10:21:00 <ncopa> yes
2025-05-29 10:21:06 <ncopa> actually, try apk upgrade -U -a
2025-05-29 10:21:29 <Kladky> Yeah, ok
2025-05-29 10:21:29 <ikke> Curoius if that will affect self-upgrade as well
2025-05-29 10:21:55 <ncopa> if it does, it all makes the difference
2025-05-29 10:21:57 <Kladky> Tell me when apk has been rebuilt with the versioned openssl dep and is in the repos, and ill see if that fixes it
2025-05-29 10:24:04 <ikke> on edge, openssl has been upgraded to 3.5.0 on the 10th of april
2025-05-29 10:29:29 <ncopa> apk upgrade -U -a does not solve it. we need to add versioned openssl dependency
2025-05-29 10:30:30 <Kladky> Yes, ik. I just needed to fully revert to 3.21.3 so that I can test whether the versioned openssl fixes the upgrade.
2025-05-29 10:31:15 <ncopa> Kladky: can I ask you a favor? can you please create an issue with the about upgrade output. "upgrade to 3.22 fails with EVP_MD_CTX_get_size_ex: symbol not found" or similar
2025-05-29 10:31:29 <Kladky> Sure
2025-05-29 10:31:36 <ncopa> then I will include the URL to the issue with details in the commit message
2025-05-29 10:38:12 <ncopa> not sure how to do the versioned dependency properly
2025-05-29 10:39:08 <Kladky> #17199
2025-05-29 10:39:13 <ncopa> I suppose it needs to be so:libcrypto.so.3>=3.5
2025-05-29 10:40:10 <ncopa> no
2025-05-29 10:40:18 <ncopa> so:libcrypto.so.3=3
2025-05-29 10:40:18 <ncopa> libcrypto3-3.5.0-r0 provides:
2025-05-29 10:42:01 <ncopa> it needs to be `libcrypto3>=3.5`
2025-05-29 10:42:09 <ncopa> would be nice to have a way to add this automatically
2025-05-29 10:43:01 <ncopa> oh, openssl does not properly version their SO
2025-05-29 10:43:30 <ncopa> thats why
2025-05-29 10:44:00 <psykose> rather than .so.3=soversion abuild could >=soversion
2025-05-29 10:44:02 <psykose> (in general)
2025-05-29 10:44:17 <psykose> i'm not sure what negative effects it would have for like every package
2025-05-29 10:44:20 <ncopa> yea
2025-05-29 10:44:34 <ncopa> i remember we talked about that a decade ago
2025-05-29 10:44:56 <psykose> maybe >= makes everything way slower when there's 10000 of them
2025-05-29 10:45:21 <ncopa> and it also will force upgrade dependencies when maybe not needed
2025-05-29 10:45:39 <psykose> eh i think that's more of a good side effect
2025-05-29 10:45:45 <psykose> if you install something you probably do want to upgrade
2025-05-29 10:45:59 <ncopa> lets say you have a broken service. I build a package from edge and ask user to test. they cant test it without also upgrading all the gazillion deps
2025-05-29 10:46:10 <psykose> true
2025-05-29 10:46:24 <ncopa> so it was a tradeoff
2025-05-29 10:46:28 <psykose> but that mix-edge thing is in a permanent state of 'dont do this' and also exceptions like this :P
2025-05-29 10:46:40 <ncopa> but ideally, we should add versioned >= when needed
2025-05-29 10:46:49 <ncopa> that said
2025-05-29 10:46:57 <ncopa> well first
2025-05-29 10:47:16 <ncopa> what I thought was that we could have an option to enforce this when needed
2025-05-29 10:47:21 <ncopa> like in apk-tools case
2025-05-29 10:47:51 <ncopa> somethign like options="version-so-deps" something
2025-05-29 10:47:54 <psykose> ah, a toggle for >= or =
2025-05-29 10:48:07 <ncopa> yeah
2025-05-29 10:48:13 <ncopa> now, that said
2025-05-29 10:48:24 <psykose> even just for putting it on apk-tools that sounds fine, though apk-tools only uses libz (never changes) and openssl (doesnt even have a full version)
2025-05-29 10:48:27 <ncopa> it wont help in openssl case we have at hand anyway
2025-05-29 10:49:05 <ncopa> it wont help openssl due to it does not have full soversion anyway
2025-05-29 10:49:33 <ncopa> annoying
2025-05-29 10:50:32 <ncopa> a perfect system would do:
2025-05-29 10:50:46 <ncopa> collect a list of all symbols needed
2025-05-29 10:51:16 <ncopa> find the lowest ABI compatible version that has all those symbols, and use that as >=
2025-05-29 10:51:53 <ncopa> but that means we'd need to keep a db for all libs, with all the symbols and all the historical data
2025-05-29 10:52:05 <ncopa> which is meh...
2025-05-29 11:20:52 <ncopa> apk-tools fix is still waiting for available CI runner
2025-05-29 11:29:34 <sam_> it's not reliable anyway, e.g. if something has a configure test or other #ifdef based on the version built against
2025-05-29 11:29:42 <sam_> (suppose it uses different behaviour to work around a bug or similar, not using a new symbol)
2025-05-29 12:22:41 <ncopa> can someone with zfs root please test and verify that mkinitfs-3.12.0_rc2 didnt break anythign for you? I just pushed it.
2025-05-29 12:29:04 <Kladky> Trying the upgrade again...
2025-05-29 12:30:56 <Kladky> ncopa: new openssl was pulled, but it still failed with the same error
2025-05-29 12:31:32 <Kladky> https://tpaste.us/lbJX
2025-05-29 12:32:02 <Kladky> (All those other packages being pulled is cause of the `apk upgrade -Ua` I did earlier deleted packages that were moved from testing)
2025-05-29 12:32:27 <lotheac> i can see mkinitfs 3.12.0_rc1-r0 in edge but not _rc2
2025-05-29 12:33:06 <lotheac> https://termbin.com/al5u _rc1 seems ok but dunno if you also wanted /boot to be zfs
2025-05-29 12:44:36 <ncopa> Kladky: works for me:
2025-05-29 12:44:40 <ncopa> $ docker run --rm  alpine:3.21 sh -c "sed -i -e 's/3.21/3.22/g' /etc/apk/repositories && apk upgrade -U -a" | tpaste
2025-05-29 12:44:40 <ncopa> https://tpaste.us/4vj4
2025-05-29 12:46:38 <Kladky> Hmm
2025-05-29 12:48:16 <ncopa> weird
2025-05-29 12:48:31 <ncopa> i also cannot reproduce in the VM i tested on earlier
2025-05-29 12:49:04 <ncopa> lotheac: needs to be _rc2, which introduced some zfs related stuff
2025-05-29 12:49:19 <lotheac> i guess the cdn's not serving that to me yet
2025-05-29 12:49:41 <lotheac> ah now it is
2025-05-29 12:50:05 <lotheac> https://termbin.com/qufs
2025-05-29 12:51:05 <lotheac> do you want me to test if it boots too? :)
2025-05-29 12:51:53 <ncopa> yes please
2025-05-29 12:52:21 <ncopa> we should probably add a zfs root test to alpine-installer-testsuite
2025-05-29 12:53:02 <ncopa> drats, chromium is in the pipe. i wanted to tag rc3, run the testsuite and tag 3.22.0
2025-05-29 12:53:02 <Kladky> ncopa: what now?
2025-05-29 12:53:21 <ncopa> Kladky: i dont know. makes no sense
2025-05-29 12:53:57 <ncopa> can you nm -D /usr/lib/libcrypto.so.3 and grep for the missing symbol?
2025-05-29 12:54:04 <ncopa> it should show up as T
2025-05-29 12:54:48 <lotheac> ncopa: booted just fine.
2025-05-29 12:54:55 <ncopa> thank you!
2025-05-29 12:55:29 <Kladky> 000000000014cc16 T EVP_MD_CTX_get_size_ex@@OPENSSL_3.4.0
2025-05-29 12:57:33 <Kladky> ncopa: It's there
2025-05-29 12:59:17 <ikke> @OPENSSL_3.4.0..
2025-05-29 12:59:22 <ncopa> so why is apk complaining?
2025-05-29 12:59:35 <ncopa> its symbolversioning
2025-05-29 12:59:58 <ncopa> i guess the symbol was introduced in 3.4
2025-05-29 13:00:38 <ncopa> can you do ldd /sbin/apk ?
2025-05-29 13:02:39 <Kladky> https://tpaste.us/MYam
2025-05-29 13:02:50 <Kladky> ncopa
2025-05-29 13:03:18 <Kladky> hmm, /lib
2025-05-29 13:03:24 <Kladky> instead of /usr/lib
2025-05-29 13:04:19 <ncopa> apk info --who-owns /lib/libcrypto.so.3
2025-05-29 13:04:47 <Kladky> ERROR: /lib/libcrypto.so.3: Could not find owner package
2025-05-29 13:04:52 <psykose> haha
2025-05-29 13:04:59 <ncopa> is it a symlink?
2025-05-29 13:05:20 <Kladky> No
2025-05-29 13:05:32 <Kladky> Created September 2024
2025-05-29 13:05:59 <Kladky> Maybe the /usr move didnt delete those files
2025-05-29 13:06:01 <ikke> /lib/libcrypto.so.3 is owned by libcrypto3-3.1.4-r6 on 3.19
2025-05-29 13:06:04 <Kladky> Not sure
2025-05-29 13:06:15 <psykose> it does on upgrade, same package
2025-05-29 13:06:33 <psykose> only way that happens is with some apk edgecase bug or somehow manually installing the file
2025-05-29 13:06:53 <ncopa> or failed install soemthing
2025-05-29 13:06:53 <Kladky> Well, I don't remember installing openssl manually, and definitely not anywhere but /usr/local
2025-05-29 13:07:26 <ncopa> you may have other files under /lib that is not owned by anything
2025-05-29 13:07:28 <Kladky> I think I remember something similar happening a while ago
2025-05-29 13:07:37 <ncopa> i think you can delete it
2025-05-29 13:07:41 <ncopa> and things should work
2025-05-29 13:07:47 <ncopa> apk cannot fix this for you
2025-05-29 13:08:03 <Kladky> Some of them are owned
2025-05-29 13:08:28 <Kladky>  /lib/ld-musl-x86_64.so.1 is owned by musl-1.2.5-r9
2025-05-29 13:08:44 <ncopa> i think you can and should delete those are not owned by anything, but keep stuff that is owned
2025-05-29 13:08:52 <Kladky> ok
2025-05-29 13:08:55 <pabloyoyoista|m> apk audit might be able to tell you
2025-05-29 13:09:06 <psykose> apk audit --full | grep 'A lib/'
2025-05-29 13:09:52 <ncopa> you gotta be kidding...
2025-05-29 13:09:54 <ncopa> >>> chromium: Build complete at Sat, 24 May 2025 12:50:28 +0000 elapsed time 10h 11m 34s
2025-05-29 13:09:57 <ncopa> 10 hours!!!
2025-05-29 13:10:32 <psykose> yeah takes forever
2025-05-29 13:10:58 <psykose> the x86_64 builder is also relatively a bit slow though, it takes me like 7 on a 5800x
2025-05-29 13:11:06 <ncopa> still
2025-05-29 13:11:21 <ncopa> this killed my plan on getting 3.22 out today
2025-05-29 13:11:29 <ncopa> i cannot even do rc3 today
2025-05-29 13:12:04 <psykose> there's always nuclear option
2025-05-29 13:12:09 <psykose> kill it, revert, do release, ..
2025-05-29 13:12:26 <ikke> Yeah, was thinking the same
2025-05-29 13:12:39 <ncopa> on aarch64 it takes 7 hours
2025-05-29 13:12:56 <ncopa> it will cost me 30mins though?
2025-05-29 13:13:03 <ncopa> maybe less
2025-05-29 13:14:54 <ncopa> allright
2025-05-29 13:14:58 <ncopa> lets kill it
2025-05-29 13:16:04 <Kladky> Ok, the issue is fixed now, thanks!
2025-05-29 13:18:25 <Kladky> But now it seems some packages need to be rebuilt, since I am having some nasty conflicts when upgrading: https://tpaste.us/EbaR
2025-05-29 13:19:55 <Kladky> Or actually, it seems that the revision number on cdn.a.o is outdated
2025-05-29 13:20:10 <ikke> try to remove the edge/testing repo first
2025-05-29 13:20:29 <ikke> though, probably not the issue
2025-05-29 13:20:38 <ncopa> killing edge was a mistake, but ok
2025-05-29 13:21:06 <psykose> how come
2025-05-29 13:21:20 <ncopa> i dont need tag rc3 in edge
2025-05-29 13:21:32 <Kladky> Yeah, removing the testing repo didnt fix it
2025-05-29 13:21:50 <ikke> Kladky: I think chromium was not rebuilt with some resent upgrades 
2025-05-29 13:22:03 <ncopa> and while chromium finishes, I may be able to tag rc3 and reapply the chromium build
2025-05-29 13:22:26 <Kladky> I don't think that's the main issue
2025-05-29 13:22:37 <Kladky> It seems that its trying to select out of date packages
2025-05-29 13:22:46 <ikke> Kladky: are you providing --available?
2025-05-29 13:22:47 <psykose> did you run upgrade -a or just upgrade
2025-05-29 13:22:57 <Kladky> I am doing apk upgrade -Ua
2025-05-29 13:23:27 <psykose> hm since when is it cdn.a.o and no dl-cdn.a.o
2025-05-29 13:23:44 <ncopa> I added cdn half year ago or so
2025-05-29 13:23:51 <psykose> makes sense
2025-05-29 13:23:51 <Kladky> No, doesnt matter either way
2025-05-29 13:23:57 <ncopa> but it has not been publicly announced
2025-05-29 13:24:01 <ncopa> and isnt really official yet
2025-05-29 13:24:07 <Kladky> even dl-cdn doesnt change it, even though its there in the repo
2025-05-29 13:24:19 <Kladky> So I'm not sure why it isnt selecting it
2025-05-29 13:24:30 <ikke> Kladky: try to explicitly request the newest version
2025-05-29 13:24:33 <psykose> but yeah the issue in that thing is just new chromium cant select cause it wasnt rebuilt against some stuff
2025-05-29 13:24:35 <ikke> then it should tell what is breaking it
2025-05-29 13:24:37 <ncopa> Kladky: you need to find out what packages are holding back they upgrade
2025-05-29 13:24:40 <psykose> and that blocks icu and so on
2025-05-29 13:24:48 <psykose> the chromium upgrade will fix it
2025-05-29 13:24:50 <Kladky> Maybe its trying to resolve conflicts before considering that the packages itself that depend on them are being upgraded
2025-05-29 13:25:01 <ncopa> apk version -l '?'
2025-05-29 13:25:16 <ncopa> may show you have unavailable packages installed that depends on those old libs
2025-05-29 13:25:23 <ncopa> in which case apk wont be able to upgrade
2025-05-29 13:26:16 <ikke> like psykose says, chromium is most likely the issue
2025-05-29 13:26:20 <Kladky> apk version -l android-tools
2025-05-29 13:26:21 <Kladky> Installed:                                Available:
2025-05-29 13:27:02 <psykose> it breaks like that all the time because simdutf was unbundled but that breaks abi every release so it needs a rebuild every time but it takes too long so it's intentionally skipped
2025-05-29 13:27:05 <psykose> (cue laugh track)
2025-05-29 13:27:13 <psykose> does not make much sense to debundle that imo
2025-05-29 13:27:31 <Kladky> nothing i have installed depends on android-tools
2025-05-29 13:27:39 <Kladky> It's only installed cause its in world
2025-05-29 13:28:19 <Kladky> apk info android-tools shows both r7 and r11 (the latest one)
2025-05-29 13:28:34 <psykose> the issue has nothing to do with android-tools
2025-05-29 13:28:37 <Kladky> and world isnt pinning a specific version
2025-05-29 13:28:54 <Kladky> I am just using android-tools as an example
2025-05-29 13:28:59 <ikke> apk list -qO
2025-05-29 13:29:09 <Kladky> since for some reason its ignoring the fact it can upgrade android-tools
2025-05-29 13:29:16 <Kladky> to resolve part of the conflict
2025-05-29 13:29:42 <psykose> it can't resolve part of the conflict like that
2025-05-29 13:29:56 <Kladky> ikke: https://tpaste.us/0xv6
2025-05-29 13:31:14 <psykose> you have to delete all of those
2025-05-29 13:31:57 <Kladky> Ok
2025-05-29 13:32:01 <ikke> webkit2gkt is now provided by versioned packages
2025-05-29 13:32:07 <ikke> webkit2gtk-6.0
2025-05-29 13:32:25 <psykose> nah, webkit2gtk was 4.0 which doesn't exist anymore
2025-05-29 13:32:33 <psykose> versioned are separate
2025-05-29 13:32:38 <ikke> There's are 4.1
2025-05-29 13:32:40 <ikke> right
2025-05-29 13:32:44 <psykose> 4.1 is something else
2025-05-29 13:32:46 <ikke> ok
2025-05-29 13:33:52 <ncopa> I killed 4.0. there was nothing that needed it.
2025-05-29 13:34:03 <Kladky> https://tpaste.us/avqo
2025-05-29 13:34:23 <psykose> looks ok
2025-05-29 13:34:35 <psykose> as long as they're not in world it's fine
2025-05-29 13:34:58 <psykose> the print in this case is from the installeddb state of 3.21 repos (and the -qO is against 3.22 where the packages don't exist)
2025-05-29 13:35:21 <psykose> only thing left then is the chromium upgrade then
2025-05-29 13:35:50 <Kladky> The conflict when upgrading didnt really change though
2025-05-29 13:36:37 <psykose> type `apk add chromium>=136.0.7103.113-r1` to see something more readable
2025-05-29 13:37:27 <Kladky> I can just uninstall chromium
2025-05-29 13:37:32 <Kladky> I don't really use it anyways
2025-05-29 13:37:37 <psykose> but basically nobody can read the conflict output except 7 people in the world dw about it
2025-05-29 13:39:04 <Kladky> https://tpaste.us/qYJ9
2025-05-29 13:39:55 <Kladky> I don't get how this could possibly make sense
2025-05-29 13:40:29 <ncopa> apk policy chromium
2025-05-29 13:40:36 <psykose> either a bug or the upgrade also pulls one of https://img.ayaya.dev/AAf13AciwHnV
2025-05-29 13:40:38 <ncopa> where does chromium come from, you just uninstalled
2025-05-29 13:41:07 <ikke> chromius was not rebuilt against simdutf 7.2.1 yet
2025-05-29 13:41:09 <Kladky> chromium policy:
2025-05-29 13:41:09 <Kladky>   136.0.7103.113-r1:
2025-05-29 13:41:09 <Kladky>     https://dl-cdn.alpinelinux.org/v3.22/community
2025-05-29 13:41:10 <ikke> chromium*
2025-05-29 13:41:13 <ikke> So that's expected
2025-05-29 13:41:31 <Kladky> But chromium isnt even installed
2025-05-29 13:41:36 <ikke> simdutf-7.2.1-r0 provides:
2025-05-29 13:41:38 <ikke> so:libsimdutf.so.24=24.0.0
2025-05-29 13:41:40 <Kladky> So why would that prevent an upgrade?
2025-05-29 13:41:43 <psykose> you can `apk add !chromium` and try again
2025-05-29 13:41:49 <psykose> if even that fails it will be incredibly funny
2025-05-29 13:41:53 <ncopa> what psykose said, something pulls in chromium
2025-05-29 13:42:36 <Kladky> Ok, that worked
2025-05-29 13:42:46 <Kladky> But what would be pulling chromium?
2025-05-29 13:43:16 <ncopa> psykose> either a bug or the upgrade also pulls one of https://img.ayaya.dev/AAf13AciwHnV
2025-05-29 13:43:18 <Kladky> Ohh
2025-05-29 13:43:20 <Kladky> vhs
2025-05-29 13:43:37 <ikke> py3-pyppeteer
2025-05-29 13:43:39 <ikke> vhs
2025-05-29 13:43:41 <ikke> ojksjdqaksdhjapk list -qd chromium
2025-05-29 13:43:42 <Kladky> It's vhs
2025-05-29 13:43:43 <ikke> sorry
2025-05-29 13:43:53 <ncopa> lol
2025-05-29 13:43:55 <Kladky> Idk why vhs needs chromium
2025-05-29 13:44:07 <ncopa> rc3 is out
2025-05-29 13:44:24 <Kladky> It just records scripted terminal output into a video file
2025-05-29 13:44:29 <ncopa> thank you for the emotional support getting it out :)
2025-05-29 13:44:51 <psykose> it puts it in the video file with chromium
2025-05-29 13:45:10 <Kladky> https://gitlab.alpinelinux.org/alpine/aports/-/commit/cf80e28fefb5665baeb053ae0c7d33373f421066
2025-05-29 13:45:17 <Kladky> Wait
2025-05-29 13:45:24 <Kladky> Weird
2025-05-29 13:45:38 <Kladky> Seems like overkill, but whatever
2025-05-29 13:45:51 <Kladky> Thanks for all the help!
2025-05-29 13:46:09 <psykose> you might prefer asciinema but it's not a video i don't think
2025-05-29 13:47:12 <ikke> Why do you need a browser engine to render a video?
2025-05-29 13:47:27 <Kladky> Hmm, no no, why chromium?
2025-05-29 13:47:46 <Kladky> https://github.com/search?q=repo%3Acharmbracelet%2Fvhs%20chromium&type=code
2025-05-29 13:47:58 <Kladky> Chromium is only mentioned in the dockerfile
2025-05-29 13:48:07 <Kladky> Everywhere else just says "browser"
2025-05-29 13:48:27 <ikke> There is no general 'browser' provider
2025-05-29 13:48:53 <psykose> the dependency uses chromium
2025-05-29 13:48:59 <psykose> for devtools stuff
2025-05-29 13:49:04 <psykose> related to the terminal sharing
2025-05-29 13:49:09 <psykose> this is not really just a terminal recorder
2025-05-29 13:51:04 <Kladky> I mean, the code says its needed to "create the gif"
2025-05-29 13:51:21 <Kladky> And I dont see anything related to terminal sharing
2025-05-29 13:51:58 <Kladky> But either way, not much we can do about it downstream, so whatever.
2025-05-29 13:54:03 <Kladky> https://tpaste.us/xD6w
2025-05-29 13:54:05 <Kladky> Hmm
2025-05-29 13:54:09 <Kladky> oh
2025-05-29 13:55:13 <ikke> -EONOPC
2025-05-29 13:55:16 <Kladky> Looks like there are some img.bak using up space
2025-05-29 13:55:23 <Kladky> Not sure why those are there
2025-05-29 13:57:46 <Kladky> And some /boot/.apk.defcac5781e48cbaa583522bca12760938df8c4dd3cd9c94
2025-05-29 13:58:40 <psykose> those were from a failed transaction in some form
2025-05-29 13:58:57 <ikke> apk writes to those files before renaming / overwriting the target file
2025-05-29 13:59:06 <psykose> like installing/upgrading a package that writes to /boot, it hits a post/pre trigger in the middle, then the actual upgrade fails for the package
2025-05-29 13:59:23 <psykose> or something around that i don't remember the order
2025-05-29 13:59:35 <Kladky> Weird that they are kept in case of failure though
2025-05-29 14:03:12 <Kladky> Is it intentional that the flathub system repo was removed after upgrading?
2025-05-29 14:11:36 <Kladky> Known issue ig#16912 
2025-05-29 14:13:46 <Kladky> Is this not kind of a big deal? Since flatpak is pretty popular on the desktop, especially with proprietary applications linked against glibc
2025-05-29 14:15:12 <psykose> not really because you can just add the repo back and it's also only for non- --user installs
2025-05-29 14:15:14 <psykose> pretty sure
2025-05-29 14:16:08 <Kladky> Yes, it only effects system installs
2025-05-29 14:51:42 <ncopa> and of course there are new kernels
2025-05-29 14:51:51 <qaqland> Kladky: vhs would try to find or download chromium to render gif, it is so weird :(
2025-05-29 14:53:10 <invoked> is there a tracking bug for stuff that needs to be checked for 3.22
2025-05-29 14:53:40 <ikke> https://gitlab.alpinelinux.org/groups/alpine/-/milestones/18#tab-issues
2025-05-29 14:53:49 <invoked> thanks
2025-05-29 14:54:17 <fossdd|m> ncopa: always after tagging a alpine release 🙃
2025-05-29 14:55:26 <ncopa> or right before enter git push
2025-05-29 15:00:07 <ncopa> can this be closed? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16106
2025-05-29 15:04:12 <Kladky> Rebooting my system, kde/sddm failed to start it seems.
2025-05-29 15:04:22 <Kladky> sddm isnt running.
2025-05-29 15:08:48 <ncopa> yup
2025-05-29 15:08:55 <ncopa> sddm appears to be broken
2025-05-29 15:08:56 <ncopa> bah
2025-05-29 15:09:10 <Kladky> https://tpaste.us/yBnx
2025-05-29 15:09:46 <ikke> 0(EE) HELPER: Failed to take control of "/dev/tty1" ("root"): Operation not permitted
2025-05-29 15:09:54 <p_6f3Ik7Suw> akms install zfs is throwing this: bwrap: Can't mkdir parents for /var/lib/akms/6.15.0-0-edge/zfs/2.2.4-r1/build: Permission denied - is this of interest?
2025-05-29 15:10:14 <ikke> p_6f3Ik7Suw: as what user are you executing this?
2025-05-29 15:10:19 <fossdd|m> https://gitlab.alpinelinux.org/alpine/aports/-/issues/16802
2025-05-29 15:10:28 <p_6f3Ik7Suw> root
2025-05-29 15:10:44 <p_6f3Ik7Suw> it first happened during apk upgrade
2025-05-29 15:11:48 <ikke> p_6f3Ik7Suw: maybe open an issue about it
2025-05-29 15:12:11 <Kladky> fossdd|m: I guess sddm should probably be rolled back then?
2025-05-29 15:12:55 <Kladky> Since this is definitely not something that should be shipped in 3.22
2025-05-29 15:13:51 <fossdd|m> rolling it back doesnt fix it
2025-05-29 15:13:59 <fossdd|m> it seems like the issue is very old
2025-05-29 15:14:21 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/16802 has a propsed fix?
2025-05-29 15:14:35 <Kladky> Well it worked fine in 3.21
2025-05-29 15:15:27 <Kladky> ncopa: If you can build it, I'll try it out
2025-05-29 15:15:46 <ncopa> dont have time now sorry
2025-05-29 15:15:53 <ncopa> gnome appears to work
2025-05-29 15:16:11 <fossdd|m> yes
2025-05-29 15:17:13 <ncopa> serial console is broken
2025-05-29 15:17:13 <ncopa> bah
2025-05-29 15:17:40 <Ermine> https://security.opensuse.org/2025/05/28/kea-dhcp-security-issues.html --- worth checking before release
2025-05-29 15:18:02 <ncopa> TL;DR
2025-05-29 15:18:38 <Ermine> 
ACTION still reads it

2025-05-29 15:19:03 <fossdd|m> Ermine: can you open a issue and tag jakub?
2025-05-29 15:20:35 <ncopa> serial console appears to be broken since rc2
2025-05-29 15:34:59 <Ermine> fossdd|m: done
2025-05-29 15:36:41 <fossdd|m> thx
2025-05-29 15:40:51 <Kladky> Hmm, I can try to do it myself, but will be a bit of a pain since I only have a tty now lol
2025-05-29 15:48:27 <Kladky> How would I apply those udev changes as part of the aport?
2025-05-29 15:51:35 <fossdd|m> you write it to a file somewhere in something like /usr/share/udev. if you grep around aports with udev files youre gonna find some example
2025-05-29 15:52:13 <ncopa> bummer
2025-05-29 15:52:30 <ncopa> my installer testsuite wont work without the serial console
2025-05-29 15:52:36 <ncopa> so i cannot test the rc3
2025-05-29 15:53:21 <ncopa> and chromium will build for another 8-9 hours
2025-05-29 15:57:56 <Kladky> fossdd|m: I see quite a few, but I can't seem to find one that uses a local udev file, instead of the upstream one.
2025-05-29 15:58:59 <Kladky> (i have no idea what udev is or how it works)
2025-05-29 16:16:23 <jvvv> Kladky: it's been a while since i looked at that (i stopped using sddm), but the udev rules should be fine in something like: /usr/lib/udev/rules.d/60-sddm.rules (i think that about matches what i remember doing). a different prefix number may be more appropriate, not sure.
2025-05-29 16:30:41 <Kladky> Right, managed to get it to work
2025-05-29 16:32:26 <Kladky> jvvv: do you want me to set you as the commit author or co-author?
2025-05-29 16:32:29 <Kladky> Or just not at all?
2025-05-29 16:34:19 <jvvv> any are fine, but since I'm not currently using sddm, i think you are better off taking it from there... i'm not interested in credit, really. just happy to help
2025-05-29 16:39:18 <Kladky> !84947
2025-05-29 16:47:35 <jvvv> nice
2025-05-29 17:17:41 <ncopa> hmpf, also xfce-wayland is broken out of the box
2025-05-29 17:23:56 <ncopa> nope
2025-05-29 17:24:00 <ncopa> i think my iso was broken
2025-05-29 17:24:03 <ncopa> need to test again
2025-05-29 17:26:01 <ncopa> well greeter works but i get some error when logging in
2025-05-29 17:31:34 <ncopa> https://imgur.com/EpZaMXF
2025-05-29 17:36:35 <ncopa> mate desktop works
2025-05-29 17:38:29 <ncopa> sway appears to work. it does not start any login manager, but logging in in TUI and starting sway appears to work
2025-05-29 17:38:34 <ncopa> no idea how to exit it though
2025-05-29 17:38:44 <f_> How to exit sway?
2025-05-29 17:38:50 <ncopa> yup
2025-05-29 17:38:50 <f_> Mod + shift + Q
2025-05-29 17:39:17 <f_> with mod being either Alt or Super
2025-05-29 17:39:30 <jvvv> ncopa: maybe adding WL_RENDERER_ALLOW_SOFTWARE=1 to the environment could help?
2025-05-29 17:39:52 <jvvv> WLR_RENDERER_ALLOW_SOFTWARE
2025-05-29 17:40:06 <ncopa> jvvv: where?
2025-05-29 17:40:12 <ncopa> im moving on to sway now
2025-05-29 17:40:25 <ncopa> Mod + shift + Q doesnt work for me in qemu
2025-05-29 17:40:53 <f_> ah wait no
2025-05-29 17:41:11 <f_> yeah mod+shift+q should work?
2025-05-29 17:41:27 <f_> and mod is either Alt or the super key depending on your config
2025-05-29 17:41:38 <ncopa> no config
2025-05-29 17:41:52 <ncopa> I'm testing the experience of clean install and then setup-desktop
2025-05-29 17:41:53 <f_> then the default config should use Alt
2025-05-29 17:42:28 <jvvv> i think adding it to commandline before running xfce-wayland or export it to environment... but i guess not applicable now if you are moving away from that
2025-05-29 17:43:01 <ncopa> i just tested what happens if you boot alpine iso, run setup-alpine -q && setup-desktop
2025-05-29 17:43:22 <ncopa> what will a new alpine linux user experience
2025-05-29 17:43:54 <ncopa> so far, if you select plasma: sddm fails to start. bad distro
2025-05-29 17:44:08 <ncopa> gnome: gdm starts and works
2025-05-29 17:44:13 <psykose> its e not q pretty sure
2025-05-29 17:44:22 <psykose> and default config is super
2025-05-29 17:44:25 <f_> Oh yes
2025-05-29 17:44:34 <f_> somehow my config had Q :p
2025-05-29 17:44:34 <ncopa> xfce: lighdm starts and xfce works. excepts some icons are missing
2025-05-29 17:44:36 <f_> sorry
2025-05-29 17:44:46 <f_> ncopa: probably missing icon pack, easy to fix
2025-05-29 17:45:12 <ncopa> xfce-wayland: greetd starts and appears to work, but fails to launch xfce
2025-05-29 17:45:40 <ncopa> mate: lighdm+mate works works
2025-05-29 17:45:43 <ncopa> sway
2025-05-29 17:45:45 <ncopa> starts up
2025-05-29 17:45:58 <ncopa> but then i can exit :q
2025-05-29 17:46:00 <ncopa> :)
2025-05-29 17:46:43 <ncopa> i figured that Command + enter starts a terminal at least
2025-05-29 17:47:14 <ncopa> we also removed the acpid so user cannot press poweroff button either
2025-05-29 17:47:15 <f_> ncopa: then Command + Shift + E should work
2025-05-29 17:47:31 <f_> (is this a macbook keyboard? :)
2025-05-29 17:47:33 <ncopa> f_: thank you! that works
2025-05-29 17:47:35 <ncopa> yup
2025-05-29 17:47:46 <ncopa> alright
2025-05-29 17:47:50 <ncopa> sway isnt for kids
2025-05-29 17:48:01 <ncopa> but it appears to work fairly good otherwise
2025-05-29 17:48:01 <f_> wait I thought it was!
2025-05-29 17:48:14 <f_> launching multiple terminals with htop to hack the nasa
2025-05-29 17:48:29 <ncopa> right. its not for old people then
2025-05-29 17:48:50 <f_> (I'm kidding ofc, ^^)
2025-05-29 17:49:28 <ncopa> qemu-system-x86_64 -m 2048 -enable-kvm -serial stdio -cdrom alpine-virt-3.22.0_rc3-x86_64.iso
2025-05-29 17:49:44 <ncopa> and run: setup-alpine -q && setup-desktop
2025-05-29 17:49:51 <ncopa> plasma and gnome meeds more memory
2025-05-29 17:50:10 <ncopa> incase you wan test it
2025-05-29 17:50:17 <ncopa> oh serial is broken in rc3
2025-05-29 17:50:24 <f_> Is xfce-wayland still experimental?
2025-05-29 17:50:32 <Saijin_Naib[m]> Yes
2025-05-29 17:50:33 <ncopa> yeah, i think so
2025-05-29 17:50:40 <f_> okay
2025-05-29 17:51:03 <ncopa> i saw there were a bunch of xfce package updated recently but I have simply not had time to bump the packages in alpine
2025-05-29 17:51:33 <f_> if only we all had infinite time ;)
2025-05-29 17:51:36 <Saijin_Naib[m]> @ncopa lots of meson enabling mostly
2025-05-29 17:51:45 <ncopa> I figured
2025-05-29 17:51:55 <Saijin_Naib[m]> I want to tackle my testing ones, then I can try and help with community
2025-05-29 17:52:12 <ncopa> which is why I didnt spend time on it. its easy to fix, just a bit time consuming
2025-05-29 17:52:24 <ncopa> 3.22 is planned for tomorrow
2025-05-29 17:53:00 <ncopa> meh. lxqt does not work with 2G mem
2025-05-29 17:57:05 <ncopa> lxqt+sddm works. except you cannot shutdown the machine
2025-05-29 17:57:56 <Saijin_Naib[m]> lxpolkit present?
2025-05-29 17:58:01 <ncopa> https://imgur.com/M1TfqMz
2025-05-29 17:58:03 <ncopa> no diea
2025-05-29 17:58:41 <ncopa> lxqt-policykit is there
2025-05-29 17:59:00 <Saijin_Naib[m]> Hmm
2025-05-29 17:59:01 <ncopa> alpine:~# apk info | grep pol | tpaste
2025-05-29 17:59:01 <ncopa> https://tpaste.us/5QDN
2025-05-29 17:59:21 <ncopa> anyway, at least half of the desktop envs works
2025-05-29 19:10:37 <ncopa> I have started draft the release notes: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/103
2025-05-29 19:10:52 <ncopa> I think we should mention dovecot 2.4 but dont know where
2025-05-29 19:11:41 <ncopa> we should link to https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2.4.html in the wiki release notes at least
2025-05-29 19:14:50 <ncopa> maybe we should mention experiemntal support for xfce on wayland
2025-05-29 19:15:00 <ncopa> or is it worth mentioning?
2025-05-29 19:15:17 <f_> isn't it broken currently?
2025-05-29 19:15:46 <p_6f3Ik7Suw> i managed to run akms install zfs --no-overlay, but now the build fails with: This kernel has unused symbols trimming enabled, please disable. Rebuild the kernel with CONFIG_TRIM_UNUSED_KSYMS=n set.
2025-05-29 19:17:28 <ncopa> f_: thats why I'm asking
2025-05-29 19:17:49 <ncopa> p_6f3Ik7Suw: what kernel?
2025-05-29 19:18:46 <f_> probably mention that it's experimental and may not work but that it is there now?
2025-05-29 19:18:52 <f_> ¯\_(ツ)_/¯
2025-05-29 19:19:20 <p_6f3Ik7Suw> ncopa: zfs/2.2.4-r1 for 6.15.0-0-edge
2025-05-29 19:21:35 <ncopa> its edge kernel which does not support 3rd party modules
2025-05-29 19:21:54 <p_6f3Ik7Suw> ah. ok. TIL
2025-05-29 19:22:46 <ncopa> im not the edge maintainer and we have our disagreements, but its not a hill im gonna die on
2025-05-29 19:22:48 <ikke> There's linux-stable in testing now
2025-05-29 19:23:02 <ncopa> and i dont have resources to maintain the kernel
2025-05-29 19:23:15 <ncopa> yeah, linux-stable is more in sync with -lts
2025-05-29 19:24:23 <ncopa> i mean i have more than enough with the -lts and rpi kernels which I maintain
2025-05-29 19:25:00 <p_6f3Ik7Suw> ack. no worries, i just thought this might be a bug for the release, i was just toying with zfs to see if i might want to use it despite my reservations (i was the guy porting zfs to grsec/musl back a few years back, which carlo landed then in alpine)
2025-05-29 19:26:41 <ncopa> aha!
2025-05-29 19:27:39 <ncopa> i think that work is appreciated! seems be pretty popular in alpine
2025-05-29 19:27:51 <ikke> We have some servers running it even
2025-05-29 19:33:32 <p_6f3Ik7Suw> yeah. that and emacs ;)
2025-05-29 19:34:03 <p_6f3Ik7Suw> anyway good luck with the release.
2025-05-29 19:34:07 <ncopa> thanks!
2025-05-29 19:34:51 <ncopa> anything we should mention under "significant changes"?
2025-05-29 19:49:13 <durrendal> woodpecker has been upgraded to 3.6.0, and the move from 2.8.0 in 3.21 to 3.6.0 in 3.22 may require users to modify their CI configuration
2025-05-29 19:49:15 <durrendal> https://woodpecker-ci.org/migrations#300
2025-05-29 19:49:23 <durrendal> lol thanks algitbot but no
2025-05-29 19:49:48 <durrendal> we can link to that woodpecker migration notice in the announcement to direct anyone on what to do. Might save someone some heartache
2025-05-29 19:51:11 <ikke> durrendal: you could add that to the draft release notes in the wiki
2025-05-29 19:51:21 <ncopa> do you mind adding a couple of lines to https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.22.0
2025-05-29 19:51:47 <durrendal> sure thing ^^
2025-05-29 19:52:45 <ncopa> ah, thats the drone fork
2025-05-29 19:53:40 <ncopa>   DOC   Building HTML                                                                     
2025-05-29 19:53:40 <ncopa> I/O error : unsupported protocol: https  
2025-05-29 19:53:40 <ncopa> warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl"
2025-05-29 19:54:02 <ncopa> i saw some change recently
2025-05-29 19:54:48 <ikke> I think you need to add a dependency to resolve that
2025-05-29 19:55:36 <ncopa> but why did it pass on 3.22 builders?
2025-05-29 20:01:41 <durrendal> well, I went to edit the wiki page, but I got a warning about my change being harmful. I assume because I had to create an account, and did so moments ago
2025-05-29 20:02:07 <ncopa> it is the docbook-xsl-nons that is missing. it was pulled in during 3.22 build https://build.alpinelinux.org/buildlogs/build-3-22-x86_64/community/libxfce4ui/libxfce4ui-4.20.0-r1.log
2025-05-29 20:02:38 <ncopa> durrendal: yeah, sorry about that
2025-05-29 20:03:58 <durrendal> gotta prevent people from spamming things somehow, no worries. Any work around, or is the answer to just wait it out. I know there's a lot going on so no need to prioritize this over release issues.
2025-05-29 20:07:06 <ikke> durrendal: should be fixewd now
2025-05-29 20:07:49 <durrendal> thank you both :) it's definitely fixed now
2025-05-29 20:11:30 <ncopa> no, its not docbook-xsl-nons that is missing. it builds in rootbld, without net
2025-05-29 20:14:48 <ncopa> no idea what introduced this
2025-05-29 20:27:13 <ncopa> it may have been libxml2 2.13.8
2025-05-29 20:30:40 <ikke> another sddm issue which appears to be unrelated to the previous issue
2025-05-29 20:30:53 <ikke> #17204
2025-05-29 21:17:31 <dne> Ermine: I can't find the issue you opened, but I've created !84954
2025-05-29 21:18:44 <ikke> The issue is hidden
2025-05-29 21:19:08 <dne> oh, right
2025-05-30 08:43:33 <ncopa> morning!
2025-05-30 08:43:40 <ncopa> i tagged rc4
2025-05-30 08:44:02 <ncopa> if that passes the tests I'll ship 3.22.0
2025-05-30 08:45:08 <ncopa> please dont push anything that takes more than ~30mins to build today
2025-05-30 08:48:57 <DWwanghao> Awesome! Can't wait for 3.22.0 - thanks for all your hard work ncopa!
2025-05-30 08:58:25 <fossdd|m> nice
2025-05-30 08:58:51 <fossdd|m> well in that regard someone minds pushing !84239 and !84674 in? ^^
2025-05-30 09:02:19 <ncopa> seems like gitlab just died
2025-05-30 09:06:33 <ncopa> pipewire looks okish
2025-05-30 09:06:40 <ncopa> wlroots too intrusive for 3.22
2025-05-30 09:07:01 <ncopa> but the x86_64 CI is busy with something
2025-05-30 10:49:55 <Kladky> ncopa: what about sddm?
2025-05-30 10:51:37 <ncopa> nobody appear to have time to fix it before 3.22, and I dont want block the release
2025-05-30 10:52:54 <Kladky> I have time
2025-05-30 10:56:24 <ncopa> i will do the 3.22 release the nearest hour. ping me if you have a fix ready to merge before that and I'll merge it
2025-05-30 11:25:58 <ncopa> i repeat: please dont push anything that takes longer than 30 mins to build today
2025-05-30 11:32:31 <ncopa> drats
2025-05-30 11:32:47 <ncopa> nodejs was pushed and kea
2025-05-30 11:33:06 <fossdd|m> oh no
2025-05-30 11:33:13 <ncopa> nodejs takes 2.5 hours and kea 2 hours on riscv64
2025-05-30 11:33:17 <ncopa> jirutka is not on IRC
2025-05-30 11:33:41 <ncopa> it means I will have to wait 5 hours to be able to do release
2025-05-30 11:33:51 <ncopa> cant wait for that
2025-05-30 11:35:14 <ikke> ncopa: you could use gitlab broadcasts for that
2025-05-30 11:36:30 <ncopa> ikke: can you please help me with that?
2025-05-30 11:37:56 <ikke> https://gitlab.alpinelinux.org/admin/broadcast_messages
2025-05-30 11:39:38 <ncopa> oh no ppc64 is unresonsive
2025-05-30 11:39:41 <ncopa> probaly overloaded
2025-05-30 11:39:48 <ncopa> this is a nightmare
2025-05-30 11:39:52 <ncopa> i need to kill the build
2025-05-30 11:57:57 <Kladky> only saw message now, but ill try see if sddm works without the udev rules if sddm is in the tty group
2025-05-30 12:02:40 <ncopa> dont stress with ti
2025-05-30 12:02:42 <ncopa> it
2025-05-30 12:02:46 <Kladky> it works
2025-05-30 12:03:02 <Kladky> lemme commit and push ncopa
2025-05-30 12:03:18 <ncopa> how long time does it take to build sddm?
2025-05-30 12:03:26 <Kladky> like 2 mins
2025-05-30 12:03:55 <ncopa> link to MR?
2025-05-30 12:04:14 <Kladky> !84947
2025-05-30 12:04:14 <ncopa> im stressing myself to death here
2025-05-30 12:04:41 <ncopa> dont ahve time to waith for CI
2025-05-30 12:04:50 <ncopa> are you 100% it will not break anything?
2025-05-30 12:05:03 <ncopa> you know what
2025-05-30 12:05:08 <ncopa> lets waith with it
2025-05-30 12:05:19 <ncopa> machine died
2025-05-30 12:05:24 <ncopa> and i need to make release
2025-05-30 12:05:43 <ncopa> wanted to tag release and revert the revert patches before buidlers finished nodejs/kea builds
2025-05-30 12:05:52 <ncopa> but problems with ppc64le
2025-05-30 12:07:26 <Kladky> ncopa: I don't see why it would break anything
2025-05-30 12:07:34 <Kladky> just adds sddm user to tty group
2025-05-30 12:14:08 <fossdd|m> we can still backport it
2025-05-30 12:16:15 <Kladky> After peoples sddm breaks and have to open a tty...
2025-05-30 12:20:14 <Kladky> hmm
2025-05-30 12:21:28 <Kladky> seems like now the sddm fix doesnt work anymore without the udev rules (wierd that it worked twice, then stopped)
2025-05-30 12:24:19 <Kladky> oh, nvm
2025-05-30 12:24:30 <Kladky> seems like they arent in tty group
2025-05-30 12:32:29 <Kladky> I guess the udev rules are truely necessery
2025-05-30 12:36:59 <Kladky> No actually, just changing the default tty
2025-05-30 12:37:04 <Kladky> to tty7
2025-05-30 12:37:29 <Kladky> which was already part of the MR, was just testing if it was needed
2025-05-30 12:39:16 <Kladky> So yeah, sorry for the confusion, it works and can be merged
2025-05-30 13:06:34 <fabricionaweb> cool the git remote message
2025-05-30 13:28:43 <f_> "Please to merge anything til the 3.22-stable branch has appeared" did you mean s/to/don't/ ?
2025-05-30 13:30:31 <f_> 
ACTION pours tea

2025-05-30 14:34:07 <ncopa> is this acceptable? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/1e8b7d1a7fb807bf28d6f4cb0ede3d1e8b3f8927/posts/Alpine-3.22.0-released.md
2025-05-30 14:34:11 <ncopa> if so I will push it
2025-05-30 14:36:19 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.22.0-released.html
2025-05-30 14:36:54 <p_6f3Ik7Suw> lgtm
2025-05-30 14:39:15 <f_> \o/
2025-05-30 14:40:18 <skarnet> lgtm as well
2025-05-30 14:40:22 <qaqland> there is a slash in Contributors list
2025-05-30 14:41:17 <skarnet> I assumed it was the name of a contributor, like "root" and "real root"
2025-05-30 14:41:24 <omni> could we add Xen 4.20 to the list of highlights?
2025-05-30 14:42:11 <ncopa> that was a typo
2025-05-30 14:42:15 <ncopa> the slash
2025-05-30 14:42:16 <ncopa> yeah
2025-05-30 14:42:23 <ncopa> xen 4.20 sounds good
2025-05-30 14:44:13 <ncopa> alright
2025-05-30 14:44:38 <omni> other than that, I don't think I have anything to add that cannot go into the wiki page, if needed
2025-05-30 14:45:18 <fossdd|m> nice work everybody
2025-05-30 14:45:23 <ncopa> im publishing it. Thank you all for helping review
2025-05-30 14:45:45 <ncopa> this has release is taking a toll on me. been pretty stressful
2025-05-30 14:45:57 <ncopa> so all the help and support is very appreciated
2025-05-30 14:46:12 <f_> 
ACTION pours tea for ncopa

2025-05-30 14:46:25 <f_> ;)
2025-05-30 14:48:24 <fossdd|m> https://alpinelinux.org/posts/Alpine-3.22.0-released.html
2025-05-30 14:48:25 <skarnet> 
ACTION pours coffee for ncopa, knowing what he likes best. :P

2025-05-30 14:48:47 <f_> eh, both have caffeine
2025-05-30 14:48:54 <f_> same thing :p
2025-05-30 14:49:07 <f_> Congrats on the 3.22.0 release!
2025-05-30 14:49:10 <qaqland> \o/
2025-05-30 14:49:10 <ncopa> 
ACTION carefully sips tea and coffe to not get burned

2025-05-30 14:49:12 <skarnet> grats!
2025-05-30 14:49:15 <ncopa> thanks \o/
2025-05-30 14:49:19 <f_> \o/ !!!
2025-05-30 14:49:26 <ncopa> still have a few todo items on the release list
2025-05-30 14:49:45 <skarnet> is "releasing on a friday afternoon" the new "deploying to production on a friday afternoon"? :D
2025-05-30 14:50:07 <ncopa> skarnet: it wasnt without drama
2025-05-30 14:50:18 <ncopa> we lost pcc64le in the process
2025-05-30 14:50:34 <ncopa> ppc64le
2025-05-30 14:51:03 <skarnet> what happened? did a builder die, or did some packages not build and you absolutely wanted the release this week?
2025-05-30 14:51:22 <f_>  13:39 <@ncopa> this is a nightmare
2025-05-30 14:51:22 <f_>  13:39 <@ncopa> probaly overloaded
2025-05-30 14:51:22 <f_>  13:39 <@ncopa> oh no ppc64 is unresonsive
2025-05-30 14:51:22 <f_>  13:39 <@ncopa> i need to kill the build
2025-05-30 14:51:39 <ncopa> both
2025-05-30 14:51:50 <ncopa> someone pushed a 4-5 hours build right before I tagged
2025-05-30 14:51:55 <skarnet> ouch
2025-05-30 14:52:10 <ncopa> and I couldnt wait til 20:00 to do release
2025-05-30 14:52:36 <ncopa> so I killed the build, reverted the upgrade
2025-05-30 14:52:56 <ncopa> and hoped to tag, branch and re-apply the 2 commits
2025-05-30 14:53:06 <ncopa> so edge builder wouldnt notice
2025-05-30 14:53:22 <skarnet> narrator: the edge builder noticed
2025-05-30 14:53:29 <ncopa> didnt
2025-05-30 14:53:32 <skarnet> wow
2025-05-30 14:53:43 <ncopa> but at that time ppc64le machine stopped to respoind
2025-05-30 14:54:16 <ncopa> and I had 30-60? mins to fix it before edge builders completed the build and noticed that it got reverted andtarted to rebuild the old version
2025-05-30 14:54:35 <ncopa> the fastest edge builders that is
2025-05-30 14:54:39 <skarnet> this needs to be a TV show
2025-05-30 14:54:43 <ncopa> slowes still would take 4 hours
2025-05-30 14:55:16 <ncopa> at that time the panic started to creep up
2025-05-30 14:55:23 <ncopa> the weekend killing monster
2025-05-30 14:55:50 <ncopa> the weekend killing moster not only threatened to kill the weekend, but also next weeks vacation
2025-05-30 14:55:55 <skarnet> "someone pushed a 4-hour build" "but we must release in one hour tops!" "we have to kill the build, now" "Captain, the ppc64le builder is unresponsive, what do we do!" *commercial break*
2025-05-30 14:56:03 <invoked> aw man. it shouldn't be this way
2025-05-30 14:56:09 <ncopa> it shouldnt
2025-05-30 14:56:15 <f_> clearly shouldn't
2025-05-30 14:56:21 <f_> :/
2025-05-30 14:56:34 <ncopa> shouldnt release on firdays somebody told me
2025-05-30 14:56:43 <skarnet> no idea who that could be
2025-05-30 14:56:44 <invoked> i've heard that before
2025-05-30 14:57:11 <ncopa> skarnet: i dont remember who but it was someone wise, someone with scars
2025-05-30 14:57:21 <ncopa> and probably with a beard as well
2025-05-30 14:57:42 <skarnet> we are legion
2025-05-30 14:58:07 <ncopa> anyway, to kill the weekend killing monster I had to sacrifice the ppc64le
2025-05-30 14:58:28 <ncopa> filed an issue to whoever can powercycle the ppc64le
2025-05-30 14:58:37 <ncopa> and cut the rope
2025-05-30 14:58:41 <ncopa> and clossed the door
2025-05-30 14:58:45 <ncopa> closed*
2025-05-30 14:58:48 <invoked> godspeed
2025-05-30 14:59:32 <f_> looks pretty stressful
2025-05-30 14:59:37 <skarnet> the image of the sacrificed ppc64le falling down into the abyss after ncopa cuts the rope is now seared in the audience's eyes
2025-05-30 14:59:54 <skarnet> half the audience hates you, the other half agrees it was a necessary sacrifice
2025-05-30 15:00:07 <ncopa> a voice in my head told me that if the machines are not reliable enough to survive a Friday release, it does not deserve to be on the Alpine Linux architecture list
2025-05-30 15:00:07 <skarnet> the fanbase erupts in online controversies, and the show ratings explode
2025-05-30 15:00:42 <ncopa> but the rope is not entirely cutted
2025-05-30 15:00:55 <ncopa> just enough to be able to close the door
2025-05-30 15:01:03 <ncopa> ppc64le still hangs in a thin thread
2025-05-30 15:01:07 <ncopa> the thing is
2025-05-30 15:01:24 <skarnet> accidents happen. It is a momentary setback.
2025-05-30 15:01:29 <ncopa> if the machine comes back, 
2025-05-30 15:01:55 <ncopa> it will start build the 3.22.0 release, and there I have a window
2025-05-30 15:02:32 <ncopa> i can log in and manually change the branch to 3.22-stable, *while it builds the release*
2025-05-30 15:02:37 <ncopa> and it will not notice anything
2025-05-30 15:03:07 <fossdd|m> my ppc64le machines are on edge anyway :p
2025-05-30 15:03:23 <ncopa> but I have to do it between the machine comes up, and before the release build completes
2025-05-30 15:03:41 <ncopa> otherwise it will start build the tsunami of stuff in git master
2025-05-30 15:04:28 <invoked> this hypervigilance is a bug
2025-05-30 15:04:48 <skarnet> saving ppc64le is the focus of the next episode
2025-05-30 15:05:17 <ncopa> i wish I could blame someone for all this, but its me who designed it when I was young and not so wise
2025-05-30 15:05:57 <fossdd|m> i hope with a new build system this can be fixed including all the other problems
2025-05-30 15:06:04 <ncopa> yeah
2025-05-30 15:06:16 <ncopa> i will design a new build system from scratch
2025-05-30 15:06:22 <ncopa> it will solve all the problems in all the world
2025-05-30 15:06:27 <ncopa> for everyone
2025-05-30 15:06:29 <invoked> (all new problems) /s
2025-05-30 15:06:30 <fossdd|m> i recently tried out buildbot and it seems it could do the job with a abuild wrapper
2025-05-30 15:06:45 <ncopa> it will be perfect
2025-05-30 15:07:07 <ncopa> I just wait for the perfect time to start with it. at a point where I have time
2025-05-30 15:07:19 <ncopa> been waiting for that moment 8-10 years now :)
2025-05-30 15:07:25 <fossdd|m> haha
2025-05-30 15:08:05 <fossdd|m> soon (tm)
2025-05-30 15:08:10 <f_> Hope you'll have fun and it won't be stressful :)
2025-05-30 15:18:36 <tomalok> and just like that Docker releases 28.2.2
2025-05-30 15:28:21 <strophy> I'm afraid I might be the one responsible for triggering the 4h builds! Are the CI runners the same machines as the release builders?
2025-05-30 15:29:55 <strophy> I was trying to get protobuf v31 over the line, and I guess the message appearing in Gitlab saying "don't merge" also means "don't push"?
2025-05-30 15:29:56 <strophy> Apologies if it was me, this is very much my first rodeo!
2025-05-30 15:30:24 <ncopa> how dare you! :)
2025-05-30 15:30:27 <ncopa> no dont worry
2025-05-30 15:30:56 <ncopa> i did consider cancel the protobuf in CI
2025-05-30 15:31:24 <strophy> haha thanks for being so gracious about it, I know it's a huge set of things to rebuild and I've been really struggling with random failures
2025-05-30 15:31:24 <ncopa> but CI was not the real problem
2025-05-30 15:31:33 <strophy> ah ok
2025-05-30 15:31:45 <strophy> Can you explain what is going on with the circular dependencies here while I have you? https://gitlab.alpinelinux.org/alpine/aports/-/issues/17191
2025-05-30 15:31:49 <strophy> I thought this would have been a blocker
2025-05-30 15:32:02 <ncopa> the builders taking care of the builds once its merged was the problem https://build.alpinelinux.org/
2025-05-30 15:32:51 <ncopa> i dont have mental energy for circular deps this week
2025-05-30 15:32:54 <ncopa> i dont know whats going on
2025-05-30 15:33:04 <ncopa> i posted it there, hoping that someone else could figure it out
2025-05-30 15:33:11 <ncopa> so I woudlnt need spend time on it
2025-05-30 15:33:53 <ncopa> if nothign happens after a week or two, please feel free to ping me again and I 'll have a look
2025-05-30 15:35:15 <strophy> sure, no hurry from my side
2025-05-30 15:35:15 <strophy> enjoy your well-deserved weekend and holiday, i'm excited about the new release!
2025-05-30 15:45:31 <ncopa> ppc64le is back!
2025-05-30 15:46:23 <p_6f3Ik7Suw> this dovecot 2.4.0 thing is a nightmare to update manually. and the package is not compiled with --with-pam - which breaks the old config without upgrade path for me.
2025-05-30 15:46:41 <ncopa> 
ACTION throw him self on the ground and grab the string that holds ppc64le, and prevent it to fall down the abyss

2025-05-30 15:49:10 <p_6f3Ik7Suw> i was using /etc/passwd for userdb and /etc/shadow for passdb before. i guess i can make a passwd-file from shadow? i know this has nothing to do with alpine. sorry, will take my frmblgrmbl somewhere else.
2025-05-30 15:51:36 <ncopa> i'm sorry bout that. would it help if we build it with pam?
2025-05-30 15:52:09 <ncopa> please create an issue
2025-05-30 15:52:23 <ncopa> with good ideas how to make the upgrade smoother
2025-05-30 16:05:10 <f_> yay ppc64le is back
2025-05-30 16:11:35 <skarnet> \o/
2025-05-30 16:27:53 <fossdd|m> https://www.phoronix.com/news/Alpine-Linux-3.22
2025-05-30 16:29:25 <ncopa> ha
2025-05-30 16:29:28 <ncopa> Alpine Linux 3.22 Replaces Gummiboot With systemd-efistub
2025-05-30 16:29:38 <ncopa> that was the news
2025-05-30 16:29:40 <ncopa> headline
2025-05-30 16:29:41 <fossdd|m> ye
2025-05-30 16:29:54 <fossdd|m> but this time there wasnt that much new
2025-05-30 16:30:14 <fossdd|m> next time we apk v3 will be the headline
2025-05-30 16:30:26 <ncopa> just that it gives the impression that you get systemd-boot if you install alpine from iso
2025-05-30 16:31:14 <omni> gummiboot is a way better name
2025-05-30 16:31:30 <omni> I hope we can replace it with something with a better name
2025-05-30 16:31:33 <omni> very important to me
2025-05-30 16:31:34 <omni> :D
2025-05-30 16:31:37 <fossdd|m> systemd-boot is still codenamed gummiboot afaik
2025-05-30 16:32:57 <craftyguy[m]> are you sure about that? when grepping the systemd repo there's just one match for gummiboot, and it's in some obscure doc about portability :P
2025-05-30 16:33:39 <fossdd|m> huh, maybe i was just the one calling it gummiboot lol
2025-05-30 16:34:58 <ncopa> the bootloader was originally a separate git repo and project and it was named gummiboot.
2025-05-30 16:35:11 <ncopa> at some point it was integrated into systemd project
2025-05-30 16:35:21 <ncopa> one monorepo with everything
2025-05-30 16:35:34 <ncopa> and it was renamed to systemd-boot
2025-05-30 16:38:26 <f_> 🤣headline
2025-05-30 16:38:26 <omni> katamari damacy
2025-05-30 16:38:28 <f_> oops
2025-05-30 16:38:32 <f_> 🤣  @ headline *
2025-05-30 16:41:13 <craftyguy[m]> ya it used to be called gummiboot before it was folded into systemd and renamed to the much less exciting name 'systemd-boot'
2025-05-30 16:43:22 <ncopa> and ofcourse they we use systemd as clickbait in headline
2025-05-30 16:44:06 <fossdd|m> "openrc distro uses systemd-boot as bootloader"
2025-05-30 16:44:50 <invoked> systemd-networkd-resolvconf-resolved-serviced-factoryd.service
2025-05-30 16:45:20 <fossdd|m> https://github.com/search?q=FROM+alpine%3A3.18+language%3ADockerfile&type=code&l=Dockerfile
2025-05-30 16:45:26 <fossdd|m> 13.6k
2025-05-30 16:45:29 <fossdd|m> now EOL
2025-05-30 16:45:37 <fossdd|m> thats a lot
2025-05-30 16:46:02 <ncopa> interesting
2025-05-30 16:46:31 <ncopa> https://github.com/search?q=FROM+alpine%3A3.22+language%3ADockerfile&type=code
2025-05-30 16:46:39 <ncopa> zero uses 3.22
2025-05-30 16:46:46 <f_> fossdd|m: add "BRRRREAKING NEWS: " at the beginning and it'll be perfect
2025-05-30 16:47:02 <ncopa> but that may be because the 3.22 image is not uplaoded yet :)
2025-05-30 16:47:11 <fossdd|m> hehe yeah
2025-05-30 16:53:44 <rhizoome> I often think setting alpine:latest would be wiser, yes it is not reproducible but we all trust alpine that much, that we run large parts of the internet on it.
2025-05-30 19:07:19 <realroot[m]> when you install a package e.g. konsole should it install the font as dep?
2025-05-30 19:19:00 <rhizoome> realroot[m]: no
2025-05-30 19:19:48 <realroot[m]> users then have to seach for it and install it as there is no option to change it
2025-05-30 19:19:56 <realroot[m]> unless I missed it
2025-05-30 19:23:15 <rhizoome> realroot[m]: alpine only sets hard depenecies. if you don't use setup-*, you have to research what soft dependenecies are needed.
2025-05-30 19:24:59 <realroot[m]> isn't this the same case https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81858 ?
2025-05-30 19:29:17 <rhizoome> realroot[m]: maybe, you can open an MR and find out. usually if the program is totally unusable you get an dependency. if only a feature is missing, you don't. but policies aren't that well defined.
2025-05-30 19:34:49 <realroot[m]> suggested or something in packages could be useful
2025-05-30 19:36:01 <rhizoome> realroot[m]: In my experience, it is complicated. Sometimes there is a dependency but it can be replaced via "provides". libudev-zero for example can replace eudev.
2025-05-30 19:37:07 <realroot[m]> is it usable instead of eudev no?
2025-05-30 19:37:51 <rhizoome> realroot[m]: libudev-zero replaces eudev well. I am currently using it.
2025-05-30 19:38:05 <realroot[m]> i mean supported, like you install it and you do not have to tinker
2025-05-30 19:39:13 <rhizoome> realroot[m]: what on alpine does not need tinkering?
2025-05-30 19:40:31 <realroot[m]> i never changed eudev so I am not sure but for example if i change system init i will have to make my own services etc.
2025-05-30 19:49:39 <rhizoome> realroot[m]: suggested is basically the reason I do not use dpkg based distros. if you install suggested you get a ton of crap and if you don't: Your alone, because everybody else installs all the crap. In alpine you know what get: You trade lots of tinkering for a nice system and everybody else is doing the same, so the information how things work is available.
2025-05-30 19:51:11 <realroot[m]> the point if that is that you can avoid to install them. like pacman does not by default
2025-05-30 19:51:18 <realroot[m]> *the point of
2025-05-30 19:53:20 <realroot[m]> dpkg has 3 levels deps, recommended and suggested. not sure about the names
2025-05-30 20:03:41 <realroot[m]> of course by deafult only deps will be installed by apk
2025-05-30 20:34:16 <invoked> rhizoome: or, at the least, apk is treading very slowly and carefully into features like that. see: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10722
2025-05-30 20:41:23 <rhizoome> the fixed dependencies are what makes apk great. /etc/apk/world exactly defines your system. people always want to have the cake and eat it. ok, weird al might only want to eat it. :-)
2025-05-30 20:49:02 <invoked> it would probably create more complexity, problems, and therefore work. very hard to get that right without stepping on a rake
2025-05-30 20:54:05 <Ariadne> congrats to everyone on the 3.22 release :)
2025-05-30 20:54:20 <Ariadne> about to make a bunch of upgrades to ifupdown-ng
2025-05-30 21:01:11 <Ariadne> invoked: just because we do something in apk does not mean alpine will adopt it necessarily.
2025-05-30 21:01:52 <Ariadne> i think it is unlikely alpine will adopt recommends/suggests, even if we add awareness to apk for those.  but openwrt, for example, wants them.
2025-05-30 21:05:16 <caskd> Hi, is it intentional that the new directory perms fix also changes ownership of /home/$USER ?
2025-05-30 21:05:45 <caskd> i just ran apk fix with --directory-permissions and it did that
2025-05-30 21:06:04 <caskd> ^^'
2025-05-30 21:11:15 <Ariadne> that's odd, but i defer to fabled
2025-05-30 21:31:41 <rhizoome> caskd: apk-tools3 do that on my machine, but apk-tools don't
2025-05-30 21:32:09 <caskd> i'm on 2.14.8
2025-05-30 21:32:14 <caskd> .9*
2025-05-31 01:34:38 <lotheac> congrats and well done on the release!
2025-05-31 06:38:49 <fabled> caskd: it should not unless there's packaged files
2025-05-31 07:37:22 <caskd> oh
2025-05-31 07:37:25 <caskd> i'm stupid
2025-05-31 07:37:44 <caskd> soo, it's because i bind mounted my home to /mnt
2025-05-31 07:37:52 <caskd> and /mnt is part of baselayout
2025-05-31 07:37:57 <caskd> welp, that makes sense
2025-05-31 07:37:59 <caskd> fchownat(3, "mnt", 0, 0, 0)             = 0
2025-05-31 08:27:39 <quinq> Hi
2025-05-31 08:29:41 <quinq> There was an update, but it seems that libressl-dev openssl/libressl/libretls are still broken
2025-05-31 08:30:31 <quinq> https://clbin.com/Z3uoL
2025-05-31 08:30:42 <quinq> (just part of the log)
2025-05-31 12:36:03 <quinq> Is that expected?
2025-05-31 12:43:41 <Alisa[m]> 😍😍😍🥰🥰🥰❤️‍🔥❤️‍🔥❤️‍🔥💖💖💖 VIP AI VR GAMES https://tk32grz.hotgamequest.com/nglperh?s1=elemvipchat
2025-05-31 13:19:01 <ncopa> quinq: not sure, but I would think it is expected. libressl is sort of a drop-in-replacement for openssl at compile time, so make sense that they cannot be installed in parallel.
2025-05-31 13:24:33 <rhizoome> I have been building testing with buildrepo and rootbld. There is a considerable amount of packages that need net but don't have option "net". Have we given up on that or is something I could try to script to fix?
2025-05-31 13:25:49 <rhizoome> Like cargo on prepare: warning: spurious network error (3 tries remaining): [6] Could not resolve hostname (Could not resolve host: index.crates.io)
2025-05-31 13:27:25 <ikke> rhizoome: ideally we have some solution where net is not required to fetch those dependencies, but we need some extra abuild support for that (like an extra phase that still has network to fetch dependencies)
2025-05-31 13:27:56 <qaqland> rhizoome: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/33
2025-05-31 13:35:46 <rhizoome> ikke: I see, I was also patching the way bwrap is called. If you are already in a container - in my opnion it still makes sense, you get a clean enivronment per build via buildrepo - you cannot mount --proc /proc because it alredy a "magic" /proc. So you have to do --bind /proc /proc. So maybe calling bwrap in two phases would be helpful? And also an option that helps if you are in a container? Maybe I can try to come up with a patch from 
2025-05-31 13:35:46 <rhizoome> my use-case.
2025-05-31 13:37:20 <quinq> ncopa, but they can, that's part of the issue :D
2025-05-31 13:38:50 <FAQ_> why is systemd boot disable?
2025-05-31 13:39:11 <quinq> And libretls seems to be abandoned
2025-05-31 18:20:37 <Kladky> How would I go about fixing OOMs in compilation like https://gitlab.alpinelinux.org/Matthias/aports/-/jobs/1877502#L1553 ?
2025-05-31 18:22:42 <quinq> Download moar ram
2025-05-31 18:23:43 <quinq> Or build software in a more efficient language
2025-05-31 18:24:54 <psykose> it runs out of 32-bit 4g address space so adding more ram wouldn't do anything
2025-05-31 18:27:02 <quinq> haha
2025-05-31 18:53:20 <roselandgoose> Kladky: yeah youre gonna need to find a hardcore rust person who also remembers that not everyone has top-of-the-line systems. such people exist, I'm told..
2025-05-31 18:55:11 <roselandgoose> i know there are ways to reduce the memory footprint of llvm+rustc, but i dont know how many would translate well to the (transient) build runners.
2025-05-31 19:08:33 <psykose> you can try export CARGO_PROFILE_RELEASE_LTO=false
2025-05-31 19:37:34 <Kladky> thanks psykose, I'll give that a go
2025-05-31 19:38:27 <Kladky> quinq, roselandgoose, I would appreciate it if you kept comments like those to yourself in the future 🙂
2025-05-31 19:40:57 <Kladky> I found it strange that x86 worked fine though, even though it also only has a 32-bit address space
2025-05-31 19:40:59 <psykose> what does the ldap3 manual download do, the cargo.lock version is the same one
2025-05-31 19:41:16 <Kladky> It's to upgrade ring in that dependency
2025-05-31 19:41:24 <Kladky> check the patch file
2025-05-31 19:41:31 <psykose> oh i see
2025-05-31 19:42:53 <Ariadne> harrumph, seeing firefox segfaults after upgrading to 139.0 on my loongarch machine
2025-05-31 19:42:58 <Ariadne> downgraded to firefox-esr...
2025-05-31 19:44:37 <Ariadne> Kladky: usually with rust on 32-bit systems, the issue is that the compiler runs out of VA space as psykose noted, not actual physical memory.  solution is usually to reduce parallelism or disable LTO or disable debug symbols
2025-05-31 19:45:21 <Kladky> what is LTO btw?
2025-05-31 19:45:28 <Ariadne> link-time optimization
2025-05-31 19:45:34 <Kladky> ahh ok
2025-05-31 19:45:37 <Kladky> thanks
2025-05-31 19:45:44 <Ariadne> since rustc builds very fat binaries, the linker can run out of VA space while linking them
2025-05-31 19:46:01 <Kladky> yeah, ill try the LTO variable later
2025-05-31 19:46:02 <Ariadne> specifically fat intermediate binaries
2025-05-31 19:52:49 <quinq> Kladky :)
2025-05-31 20:03:10 <Kladky> it would probably be a good idea to only set that for arches that need ir (armhf, armv7), right?
2025-05-31 20:03:20 <Kladky> s/ir/it
2025-05-31 23:22:24 <xe> how do you make your own repos again? been a few years lol