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