2026-01-01 02:35:57 <ryanwiseman> Hi, I recently submitted a Merge Request adding JUCE to Alpine Linux in testing/. If someone could review this MR, that would be greatly appreciated. Thanks!
2026-01-01 16:24:26 <Sertonix[m]> ncopa: Could you comment on https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/427#note_565637 ?
2026-01-01 17:25:32 <ncopa> some general thoughts I have had around abuild, I think it would be interesting to move to OCI images for building instead of our bubblewrap hack. we could for example use crun instead
2026-01-01 17:30:58 <ncopa> I have also been playing with a mkinitfs rewrite
2026-01-01 17:31:17 <ncopa> the idea is to make it modular, and event driven
2026-01-01 17:31:38 <ncopa> I'm thinking of implement it in C and Lua
2026-01-01 17:31:47 <ncopa> so modules are implemented in Lua
2026-01-01 17:32:39 <ncopa> it will work like nlplug-findfs, but instead or handle the uevents from C, it will simply run Lua hooks
2026-01-01 17:34:01 <ncopa> the Lua hooks can then signalize when the rootfs is found and mounted and the evenloop can exit and do the switch_root
2026-01-01 17:53:38 <achill> i dont have any experience iwth crun but that sounds sane, there are many ways to sandbox for example for pmbootstrap people were thinking about using uprivileged user namespaces by using mkosi-sandbox
2026-01-01 17:54:21 <achill> and yeah mkinitfs really could use a rewrite
2026-01-01 18:40:52 <Sertonix[m]> ncopa: I am looking at sandboxed building but that mostly does not effect abuild or the usefullness of rootbld.
2026-01-01 18:43:26 <Sertonix[m]> achill: using unpriviliged user namespaces can already be easily done with abuild rootbld. There is no need to pull in extra dependencies: https://codeberg.org/sertonix/aports/src/branch/main/custom/0+abuild/abuild.conf.in
2026-01-01 18:44:46 <omni> sydbox/sydbox-oci comes to mind, but I haven't played enough with it yet
2026-01-01 21:07:43 <ryanwiseman> If someone could review this code, that would be great, because it is ready to be merged per the recent fixes I made: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95261
2026-01-02 13:10:54 <ikke> ryanwiseman: Just fyi, there are many MRs needing reviews / getting merged, so please be patient.
2026-01-02 16:28:58 <f_> ryanwiseman: reviewed a few things in your MR I spotted
2026-01-02 16:31:17 <ikke> gitlab is being upgrades and briefly unavailable
2026-01-02 16:31:51 <f_> ack, thanks :)
2026-01-02 16:34:28 <achill> oki
2026-01-02 16:39:10 <ikke> gitlab is back
2026-01-02 16:39:55 <f_> welcome back
2026-01-02 18:34:40 <JustSouptheyhe[m]> Is there a way to define a subpackage for more than one architechture in an APKBUILD. For example, I am trying to build a subpackage for only x86_64 and aarch64. I know I can't do `arch="aarch64 x86_64"` in the subpackage, but doing
2026-01-02 18:34:40 <JustSouptheyhe[m]> ```
2026-01-02 18:34:40 <JustSouptheyhe[m]> ```
2026-01-02 18:34:40 <JustSouptheyhe[m]> $pkgname-subpackage:subpackage_function:x86_64:aarch64
2026-01-02 18:34:41 <JustSouptheyhe[m]> and variations doesn't work.
2026-01-02 18:35:41 <achill> case $CARCH in; x86_64|aarch64) subpackages="$subpackages $pkgname-meow";; esac
2026-01-02 18:37:06 <achill> see rg 'subpackages=..subpackages' for examples
2026-01-02 18:38:01 <JustSouptheyhe[m]> Ah, thanks a lot!
2026-01-02 18:38:19 <JustSouptheyhe[m]> abuild silently crashes when doing what I tried, so maybe that should be checked
2026-01-02 18:39:16 <ikke> The 2nd : separates the split function
2026-01-02 18:40:47 <JustSouptheyhe[m]> I thought that was it, but I didn't know if there was logic around multiple arches maybe.
2026-01-02 18:41:40 <ikke> If any, it would be separate by spaces
2026-01-02 22:25:16 <linux_head> Hi guys, are there any paying postisions available with alpine linux?
2026-01-02 22:29:37 <linux_head> ??
2026-01-02 22:35:02 <ryanwiseman> As a note, the runner for Alpine is down to where there is a node timeout. It's a problem preventing linting from happening, and has failed the last 3 merge requests (including mine) that attempted to go through the standard pipeline
2026-01-02 22:40:05 <achill> linux_head: it is a volunteer project, nobody is getting payed (at least by the project)
2026-01-02 22:40:35 <linux_head> ok thanks @achill
2026-01-03 05:23:47 <Saijin_Naib[m]> Anyone taken a stab at pinta 3.1 upgrade yet?
2026-01-03 05:29:21 <Saijin_Naib[m]> It looks like they changed some things that make the current APKBUILD fail to build
2026-01-03 05:29:30 <Saijin_Naib[m]> https://github.com/PintaProject/Pinta/pull/1403
2026-01-03 05:29:44 <Saijin_Naib[m]> This seems to be the PR that changed how GirCore was referenced, but I don't see how to fix that
2026-01-03 05:57:42 <Saijin_Naib[m]> nvm, I dit it, incoming MR
2026-01-03 14:35:42 <f_> ryanwiseman: it happens sometimes as they're busy with other MRs
2026-01-03 14:35:54 <f_> runners not available I mean
2026-01-03 14:36:15 <f_> As I wrote in your MR, if these pass locally you shouldn't worry too much about it.
2026-01-04 00:49:11 <omni> does anyone have an alternative to having to mouseclick in the new UI to be able to scroll? (arrows, pgup/pgdn etc)
2026-01-04 02:02:39 <jvvv> omni: i have not found one. not for lack of looking.
2026-01-04 07:32:16 <ikke> https://gitlab.com/gitlab-org/gitlab/-/issues/580678
2026-01-04 07:32:58 <ikke> https://gitlab.com/gitlab-org/gitlab/-/issues/577384
2026-01-04 09:45:27 <ffoss> omni: the aports mailing list but it's been down for a while now
2026-01-04 09:51:14 <ikke> The list is still up, but it requires people to manually import the patches into aports
2026-01-04 09:51:26 <ikke> (like it was before, but less people that do that)
2026-01-04 09:58:27 <ffoss> Right, but was thinking of the automatic gitlab integration, or was that always just someone manually creating a mr? :p
2026-01-04 09:58:58 <ikke> No, that was briefly there
2026-01-04 10:11:43 <ffoss> Is it much work to get it up again?
2026-01-04 10:15:59 <ikke> I don't know, not sure what's broken
2026-01-04 10:18:55 <ikke> One issue is that it stimulates drive-by patches. Just dropping patches without any follow up
2026-01-04 10:31:05 <ffoss> I don't know how integrated the integration was, but if comments to the mr were converted to email replays and visa versa, and sending an updated patch series updated the same mr, I think it would be pretty simple to follow up if you wanted at least
2026-01-04 11:56:27 <f_> IIRC it did work like that ffoss 
2026-01-04 11:59:48 <ikke> iirc updates to a patch would open a new MR
2026-01-04 15:56:54 <omni> but that's not an alternative I'm looking for, just not having to have a rodent to interact with the ever changing web ui
2026-01-04 15:58:44 <omni> and I understand that there is not much we can do here, other than bring it up with upstream and that is not something I have time or energy for (nor hope, with the trajectory of ui changes seen)
2026-01-04 15:59:09 <omni> so I was just hoping that someone had found something that I, or jvvv, hadn't
2026-01-04 16:01:29 <omni> I wish there was some lightweight and functional alternative frontends for GitHub® and GitLab® to make them as easy to interact with as they used to
2026-01-04 16:02:26 <omni> I should look into using glab and whatnot more than I do, I just have my workflows (flawed, I'm sure) that I'm used to
2026-01-04 16:03:20 <f_> It's actually not hard to write a lightweight frontend for GitLab
2026-01-04 16:03:50 <f_> I wrote a read-only one a few years back
2026-01-04 16:04:34 <f_> I think I should probably finish it at this point, I don't really enjoy gitlab's "let's change UI every few months to confuse our users!" strategy ..
2026-01-04 16:18:21 <ikke> The reason I haven't noticed is that I use vimium keybindings, and they are not affected
2026-01-04 16:28:18 <quinq> /4/4
2026-01-04 16:38:54 <ikke> ?
2026-01-04 17:07:48 <quinq> PEBKAC
2026-01-04 21:08:08 <omni> I use qutebrowser, also vim-like keybindings, but cannot scroll without clicking somewhere in the interface
2026-01-04 21:54:08 <achill> yeah qutebrowser is great but that doesnt change that gitlabs ui is not very intuitive imo
2026-01-04 21:54:38 <quinq> You just need to plugin your A.I. UI helper device
2026-01-05 02:14:21 <omni> I can use `wl-kbptr click`, instead of attaching a rodent
2026-01-05 13:58:55 <invoked> dunno if this is affecting anybody, but the bsds consider it worth patching. https://github.com/Perl/perl5/issues/23405#issuecomment-3056302325
2026-01-06 07:33:32 <Saijin_Naib[m]> Anyone else getting timeouts connecting to https://gitlabl.alpinelinux.org/alpine/aports.git when using git in cli?
2026-01-06 07:33:44 <Saijin_Naib[m]> I can clone just fine, but trying to checkout that as upstream to reset my master branch in my fork is broken
2026-01-06 07:35:41 <Saijin_Naib[m]> https://bpa.st/S3RQ
2026-01-06 07:41:17 <Biswa96[m]> it's gitlab, not gitlabl.
2026-01-06 07:43:41 <Biswa96[m]> you can sync fork repo in gitlab.
2026-01-06 07:43:44 <Biswa96[m]> 
ACTION uploaded an image: (17KiB) < https://matrix.org/oftc/media/v1/media/download/AW8cSNXMadpjRvWFVdNktN_3ASbwsXqr6czyJ4L1-l7pIszrcwdkA4UTHP8ttkrodx6Ruq60D2Nx38iwA771AY5Ceb2lwOSQAG1hdHJpeC5vcmcveEpMQ1h2ckROc29obWhqR1RRYUFSanNa >

2026-01-06 07:44:49 <Saijin_Naib[m]> yeah, sorry, typo here but properly configured in my clone
2026-01-06 07:45:08 <Saijin_Naib[m]> I also use the gui sync, but I have an alias that syncs for me before I make a branch locally to do any MRs
2026-01-06 07:45:30 <Saijin_Naib[m]> I just cant reach gitlab.alpinelinux.org/alpine/aports.git via git cli, and I don't understand why
2026-01-06 07:58:20 <ikke> Saijin_Naib[m]: But you said you could clone the repo?
2026-01-06 08:42:08 <Saijin_Naib[m]> ikkeI can clone my fork, and add the alpine repo as upstream, but I can't fetch from it to sync
2026-01-06 08:42:50 <Saijin_Naib[m]> also, sorry for all the MR churn. I found a script that cleans up stale branches more than a year old, but doesn't fail gracefully if it can't determine the age and it just nuked every single branch in my fork
2026-01-06 08:43:20 <Saijin_Naib[m]> So, I'm re-opening and re-committing all my old MRs from the (thankful!) cache in Gitlab
2026-01-06 08:53:50 <ikke> Saijin_Naib[m]: so perhaps difference between ssh and https?
2026-01-06 08:58:05 <Saijin_Naib[m]> Maybe? I have no idea how to setup SSH cloning, but I thought HTTPS ShouldJustWork(TM), and it has in the past
2026-01-06 08:59:21 <ikke> Yes, it should definitely work. Just trying to explain the difference
2026-01-06 09:03:12 <Saijin_Naib[m]> Ah, yeah, thanks
2026-01-06 09:03:27 <Saijin_Naib[m]> I don't think it is an IP ban or anything, because I can reach it via the web gui and ping it
2026-01-06 11:49:46 <Saijin_Naib[m]> Does the colord openrc service need to be manually written for our colord package, or is it a build setting to enable it?
2026-01-06 11:50:05 <Saijin_Naib[m]> I am trying to get xiccd and XFCE setup with color management, but colord system service needs to be running
2026-01-06 12:22:07 <ikke> Saijin_Naib[m]: It does not come with an openrc service afaik, so we would need to create it ourselves
2026-01-06 14:35:20 <Saijin_Naib[m]> 😭
2026-01-06 14:35:45 <Saijin_Naib[m]> @ikke Artix OpenRC ships one. Likely drop-in? 
2026-01-06 15:47:17 <Sertonix[m]> Has anybody else seem sway to suddenly ignore one finger on a touchpad for multi-finger gestures?
2026-01-06 16:50:34 <Saijin_Naib[m]> Is the riscv64 builder having a moment for everyone, or just me?
2026-01-06 16:50:46 <Saijin_Naib[m]> Gitlab says "There has been a runner system failure, please try again"
2026-01-06 17:03:00 <ikke> Which runner? Carlo is working on one
2026-01-06 18:25:54 <Saijin_Naib[m]> Oh, shoot. Are they named or IDd in the log? I assumed we had one of each arch only. I'll check back at home and report which one if not resolved
2026-01-06 18:45:25 <ikke> Especially for riscv64, we have multiple runners to handle the load
2026-01-06 21:54:57 <ryanwiseman> Can someone please review my new aports code? It went through an extensive review period, everything was fixed that was suggested, and now just awaits to be merged: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95261
2026-01-06 22:04:26 <ikke> ryanwiseman: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/?sort=created_asc&state=opened&label_name%5B%5D=aports%3Aadd&draft=no&first_page_size=20\
2026-01-06 22:26:51 <Sertonix[m]> ryanwiseman: Checking for the existance of directories seems useless at best, --parallel can be removed, -DCMAKE_CXX_FLAGS should include $CXXFLAGS and packages should not depend on gcompat
2026-01-07 00:10:02 <ryanwiseman> Sertonix[m]: updated all said changes, code compiles on all platforms. please let me know if there is anything left, because if possible, it would be great for this large framework to be moved into testing (it took me about 2 months to get this working on Alpine because of how giant JUCE is)
2026-01-07 00:40:06 <quinq> ryanwiseman, that version is quite old, why not packaging the last version?
2026-01-07 00:42:34 <quinq> Then https://github.com/juce-framework/JUCE/blob/8.0.12/docs/Linux%20Dependencies.md says that it builds with webkit 4.1
2026-01-07 07:21:40 <Saijin_Naib[m]> ikke it was "Running with gitlab-runner 18.0.2 (4d7093e1)
2026-01-07 07:21:40 <Saijin_Naib[m]>   on shared-runner pioneer1 (riscv64) JZnuypS7T, system ID: r_TaK2ET0XIXsO"
2026-01-07 07:21:41 <Saijin_Naib[m]> resolved now
2026-01-07 07:22:40 <ikke> Yes, that was the runner with issues
2026-01-07 07:31:35 <Saijin_Naib[m]> If I want to package colord-openrc from Artix linux alongside our colord, is that possible? Is this file correct? Is it best to just file a Feature Request against colord with the info about this package and the why (for DE color managment with XICCD) or do it myself and see>?
2026-01-07 07:31:37 <Saijin_Naib[m]> https://gitea.artixlinux.org/packages/colord-openrc
2026-01-07 07:46:29 <ikke> If the license of the file in Artix is clear, we could adopt it
2026-01-07 07:50:55 <thwr> How is the transition to s6 looking?
2026-01-07 07:52:24 <Saijin_Naib[m]> They are saying it is GPLv2, but they have assigned the Copyright to the Artix Linux team. Is that a blocker?
2026-01-07 07:57:12 <ikke> thwr: There is no planned transition just yet
2026-01-07 07:57:31 <ikke> The maintainer is still working on providing a front-end to s6
2026-01-07 07:57:46 <thwr> Alr
2026-01-07 07:58:04 <PureTryOut> Is the goal to move away from OpenRC to it at some point? 🤔
2026-01-07 07:58:15 <thwr> That's what I've heard
2026-01-07 07:58:36 <thwr> I hope it will make bootstrapping Alpine a little easier
2026-01-07 07:58:36 <ikke> PureTryOut: No decision has been made
2026-01-07 07:58:45 <thwr> Aw
2026-01-07 07:58:59 <PureTryOut> Ah ok, I thought so haha
2026-01-07 07:59:53 <ikke> And most likely it will be an option at first anyway
2026-01-07 08:00:26 <ikke> It is already an option today anyway
2026-01-07 08:01:32 <PureTryOut> Just like any init you want is an option atm, yeah
2026-01-07 08:32:41 <thwr> My main issue with OpenRC is that installing it by hand requires you to manually set up all the necessary services
2026-01-07 08:32:50 <thwr> That is, put them in the correct runlevels
2026-01-07 08:33:42 <thwr> Which is tedious. Plus up until a month or two ago, there had been no proper coverage of the process anywhere
2026-01-07 08:34:30 <thwr> For example, not enabling the firstboot service will cause the system to hang during boot, even though the init script doesn't actually do anything important
2026-01-07 08:34:31 <thwr> Weird
2026-01-07 08:48:23 <ikke> How would switching to s6 solve that issue?
2026-01-07 08:48:50 <ikke> I expect you would still need to do similar things, at least make sure the right services start in the right order
2026-01-07 09:12:01 <skarnet> s6-rc has a notion of essential services, that you cannot disable (except by providing a special option)
2026-01-07 09:12:30 <skarnet> it's mostly complete now, I'm writing the documentation, it will release this month
2026-01-07 09:13:03 <skarnet> after which I'll be taking a look at all of the Alpine services and how to make a framework for choosing your service manager
2026-01-07 09:14:10 <skarnet> the goal isn't to "move from OpenRC", but to provide users with a choice
2026-01-07 09:14:24 <skarnet> openrc will likely remain the default for the foreseeable future
2026-01-07 09:22:32 <ikke> skarnet: I suppose it has to be configured somewhere what the essential services are, right?
2026-01-07 09:23:29 <skarnet> Yes, it's in the service definitions, provided either by the packages themselves (most of them won't have the flag) or by the distro
2026-01-07 09:29:58 <Saijin_Naib[m]> Hey, if it starts stuff more deterministic than OpenRC without me needing to set depends, I'm sold
2026-01-07 09:31:08 <skarnet> part of the point is to have stricter guardrails on the service set and fewer dynamic shenanigans, yes (which is a double-edged sword)
2026-01-07 09:52:42 <f_> It's nice to see more choices wrt init systems
2026-01-07 09:52:46 <f_> keep it up!
2026-01-07 10:00:07 <quinq> skarnet, will it provide the systemd feature of having indefinite auto-renewed timeouts?
2026-01-07 10:01:56 <skarnet> indefinite what now
2026-01-07 10:03:11 <ikke> The feature where systemd tries to shutdown a service, notices that the timeout has passed, and just increases the timeout so that it has sufficient time to stop the service
2026-01-07 10:03:30 <quinq> I just remember systemd would lock the computer often on shutdown because it wouldn't abort some running process
2026-01-07 10:03:44 <skarnet> with s6-rc, stopping a service never fails
2026-01-07 10:03:52 <quinq> That's the sane way
2026-01-07 10:04:04 <ikke> skarnet: ftr, that's meant sarcastically
2026-01-07 10:04:12 <quinq> yes :)
2026-01-07 10:04:20 <skarnet> I got that much :P
2026-01-07 10:04:59 <skarnet> but it's a design principle I've been very vocal about for a long time: destructors should never fail
2026-01-07 10:05:15 <skarnet> that systemd "feature" is but one of many examples of what can happen if they do
2026-01-07 10:07:06 <achill> what does it do if it fails to stop a service?
2026-01-07 10:07:55 <f_> I suppose force killing said service
2026-01-07 10:08:28 <skarnet> it depends on how the service is implemented exactly, but yeah, for longruns it force kills it after a timeout
2026-01-07 10:08:49 <skarnet> and worst case it just ignores the error
2026-01-07 10:09:04 <skarnet> it's all configurable per service
2026-01-07 10:09:25 <achill> so for oneshots like wg-quick it just ignores it i guess?
2026-01-07 10:10:03 <skarnet> it depends on how the down script is written, if you end the script with "exit 0" it will ignore failures to shut it down :)
2026-01-07 10:10:17 <skarnet> you can make the shutdown fail if you insist but why would you
2026-01-07 10:10:41 <achill> because if the shutdown failed, something failed and the user who wanted the service tto be stopped should know
2026-01-07 10:10:54 <skarnet> oh there's plenty of logging
2026-01-07 10:10:57 <ikke> In systemd this is all also configurable
2026-01-07 10:12:17 <skarnet> in general when a service fails to shut down it's not the service that's at fault (it *can* be a bug in the program, e.g. failure to react to a signal, but it's rare) - more often it's the service manager that lost its tracking somewhere
2026-01-07 10:13:09 <skarnet> such failures are best ignored, they're unlikely to happen again
2026-01-07 10:13:23 <ikke> Some services stopping safely can take quite some time due to synchronization
2026-01-07 10:13:24 <skarnet> and if they happen again then the service manager should be looked at, not the service
2026-01-07 10:13:30 <achill> for that kind of stuff, sure
2026-01-07 10:13:41 <skarnet> yeah and it's fine
2026-01-07 10:14:00 <skarnet> if a service shutting down needs a long time to synchronize... then define a long timeout
2026-01-07 10:14:49 <skarnet> it's a trade-off between wanting to do things cleanly and how much time the user is willing to wait before getting convinced something has stalled
2026-01-07 10:14:57 <ikke> Yes
2026-01-07 10:27:02 <achill> yup
2026-01-07 11:04:46 <achill> ncopa: can you verify if the vlc qt6 plays any video for you?
2026-01-07 11:04:50 <achill> for me it doesnt
2026-01-07 11:09:14 <ncopa> ok. im building it locally now
2026-01-07 11:16:55 <ncopa> achill: it plays the video, but stop/pause buttons does not work
2026-01-07 11:17:04 <ncopa> the next/prev buttos responds
2026-01-07 11:40:41 <achill> intersting i just get errors when trying to play a video
2026-01-07 13:54:54 <jvoisin> skarnet: speaking of s6¸ can I have cool stuff like https://wiki.archlinux.org/title/Systemd/Sandboxing ? :P
2026-01-07 15:25:37 <skarnet> jvoisin: Everything is theoretically possible if we have process state change commands (and for this, we need unshare + utilities to process capabilities + probably some cgroups stuff), so yeah, sure, but not tomorrow ^^' ideally I'd like to have a declarative syntax first so everything we add later can be supported by s6 and by openrc as well
2026-01-07 15:29:35 <skarnet> In general, when you wonder "how difficult would it be to have <systemd feature> with s6?" the answer on a scale from 1 to 10 can be found at https://skarnet.org/software/s6/unit-conversion.html :)
2026-01-07 15:31:30 <jvoisin> :D
2026-01-07 15:31:37 <jvoisin> and also, ♥
2026-01-07 20:09:24 <pabloyoyoista> Could somebody add these things to the /usr-merge milestone?
2026-01-07 20:09:26 <pabloyoyoista> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/100
2026-01-07 20:09:32 <pabloyoyoista> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/93880
2026-01-07 20:09:38 <pabloyoyoista> https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/113
2026-01-07 20:45:18 <achill> did the aports one, for the others i dont have the permissions
2026-01-07 23:59:33 <jvoisin> ptrc: what's the current usecase of py3-twiggy? The last meaningful upstream commit is from 2021 (or 2017 depending what you count as meaningful), and the package doesn't have any reverse-dependencies in Alpine
2026-01-08 00:53:13 <craftyguy[m]> what's up with the aarch64 edge builder? I think duckdb has had it stuck for a day?
2026-01-08 00:58:41 <achill> wanted to disable checks already 3 times but got distraced loo
2026-01-08 00:59:23 <achill> 127e5820a470c0f665e86fb2848d584027a46306
2026-01-08 01:00:25 <craftyguy[m]> how about: !95571
2026-01-08 01:00:43 <craftyguy[m]> that test (along with some others) were disabled before the upgrade, but I guess that one test still needs to be excluded...
2026-01-08 01:02:02 <HarryN[m]> Okay, so I had a question about packaging [AMF](https://github.com/GPUOpen-LibrariesAndSDKs/AMF) to allow AMD hardware acceleration on all versions of ffmpeg and the fork used by jellyfin-ffmpeg. How should I actually package it for use during building ffmpeg?
2026-01-08 01:02:40 <craftyguy[m]> killing all tests wfm too :P
2026-01-08 01:17:16 <HarryN[m]> It looks like there's nothing really comparable with NVIDIA since the headers for NVIDIA are already included in ffmpeg
2026-01-08 05:21:30 <Saijin_Naib[m]> Anyone have the bandwidth to take a pass at updating greybird theme packeage? It is like 7 years behind, and I got confused trying to bump it because it was restructured along the way and all the subpackage splits/moves/etc need adjusting
2026-01-08 05:29:50 <ikke> achill: why disable all checks if just one check fails on one arch?
2026-01-08 05:32:36 <ikke> The reason I think it fails on the aarch64 builder is due the the amount of cores it has
2026-01-08 08:43:51 <qaqland> the source link in community/xscreensaver is 404 now
2026-01-08 08:54:53 <ikke> Is there an alternative?
2026-01-08 09:04:37 <pj> achill: you're opening can of worms
2026-01-08 09:05:41 <pj> there's no possibility of reasoning with mckay and telegram group is just a lost cause
2026-01-08 09:07:33 <pj> the only thing we have achieved so far is that he changed the group picture to slightly worse quality
2026-01-08 09:17:36 <qaqland> ikke: find one mirror on GitHub, but no actual commit information https://github.com/Zygo/xscreensaver/commits/master/
2026-01-08 09:21:10 <ikke> qaqland: We would just need to bump the version. Jwz is quite adamant that people should use the latest version only 
2026-01-08 09:22:27 <ikke> https://www.jwz.org/xscreensaver/xscreensaver-6.13.tar.gz
2026-01-08 09:53:12 <ikke> qaqland: and we should also still have the existing version on distfiles
2026-01-08 10:08:34 <quinq> s/6.11/6.13/
2026-01-08 17:58:45 <WhyNotHugo> I have a template for an APKBUILD for a Go package which does not use `options="net"`: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95601/diffs
2026-01-08 17:59:25 <WhyNotHugo> The logic in the helper functions could be moved into an `abuild-go` package, and have that become a makedepends for Go packages.
2026-01-08 18:09:30 <Sertonix[m]> The curl invocation is insecure
2026-01-08 19:08:33 <WhyNotHugo> True, added --fail
2026-01-08 19:09:08 <ikke> I think also checksums
2026-01-08 19:22:47 <Sertonix[m]> And putting the contents into a shell variable is UB
2026-01-08 21:22:53 <ptrc> jvoisin: i think we can remove it, it was added ages ago by fab and it got barely enough maintenance to just build
2026-01-08 21:25:32 <jvoisin> I'll send an MR, thanks
2026-01-08 21:41:36 <jvoisin> there: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95607
2026-01-08 21:46:35 <jvoisin> ptrc: same question for things listed there that you're maintaining https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17822, if you have ~5min to check <3
2026-01-09 16:31:21 <Saijin_Naib[m]> Can I get a check on !95344 and !95727
2026-01-09 16:36:26 <PureTryOut> I might have missed an obvious change, but do $depends not get installed during build anymore? 🤔
2026-01-09 16:37:08 <ikke> PureTryOut: It still should, unless I have missed it as well
2026-01-09 16:37:17 <ikke> But that would be a massive breaking change
2026-01-09 16:41:37 <achill> the behaviour is still the same
2026-01-09 16:42:02 <achill> downstream in pmOS we sometimes dont install depends when building metapackages (since for metapackages they are not required to build)
2026-01-09 19:31:53 <Ariadne> pj: well, that is not precisely accurate.  we got him to stop shitting up the alpine wiki with disinformation
2026-01-09 19:35:29 <Ariadne> however, i do not believe mckay will ever stop misusing the alpine marks as part of his disinformation project
2026-01-09 19:47:09 <achill> i wish we would just own a trademark over the name
2026-01-09 19:49:28 <ikke> It's not so simple and not cheap to register a trademark worldwide
2026-01-09 19:49:44 <ikke> And it would require us to enforce it
2026-01-09 19:49:50 <achill> yeah
2026-01-09 19:56:21 <Ariadne> on the other hand, we have an open collective account which has a decent amount of money in it
2026-01-09 19:57:02 <Ariadne> and while we do need to spend those funds responsibly, i do think going from an implicit mark to a registered mark in the EU would at least be enough to spook mckay into stopping this behavior
2026-01-09 19:57:38 <Ariadne> in the meantime: https://social.treehouse.systems/@ariadne/115866862178424270
2026-01-09 19:59:48 <Ariadne> (though in the US and EU, implicit marks still have legal protection)
2026-01-09 20:10:41 <Ariadne> anyway, regardless of trademark status, i do not think we will ever compel Telegram to do what is legally and morally correct
2026-01-09 20:11:08 <Ariadne> i have contacted Telegram trust and safety dozens of times about this issue, and never hear anything back
2026-01-09 20:18:35 <Ariadne> the problem as ikke alludes to, is, every time anyone contacts Telegram about this, we are told they will only take things down with a court order
2026-01-09 20:18:57 <Ariadne> (gee i wonder why there is so much scams happening on Telegram, can't put my finger on it)
2026-01-09 20:19:44 <achill> the open collective has been advertised as to only spend that mondey on infra costs afaik
2026-01-09 20:20:13 <Ariadne> yes
2026-01-09 20:20:43 <Ariadne> but i think in this case, an exception would be OK
2026-01-09 20:21:21 <Ariadne> and it's not like we have spent any major funds on infrastructure programs yet anyway
2026-01-09 20:21:25 <achill> i guess thats for the board to decide but there should be at least a OC "update" or how they call it
2026-01-09 20:21:47 <Ariadne> create a ticket in alpine/council?  i will gladly +1 it
2026-01-09 20:22:14 <Ariadne> but i do not know how effective going from an implicit mark to a registered one will be
2026-01-09 20:22:23 <Ermine> something tells me that mckay is not a EU resident
2026-01-09 20:22:29 <Ariadne> telegram don't care, they still won't care about it
2026-01-09 20:22:46 <achill> i feel like a mark will be diffiult without a legal entity
2026-01-09 20:22:52 <achill> which i also want to bring up again
2026-01-09 20:22:55 <Ariadne> Ermine: yes, i think he is in panama or something, but registrations have reciprocity
2026-01-09 20:22:59 <Ariadne> achill: +1
2026-01-09 20:29:15 <Ariadne> i will say that my latest look at those channels, it has gotten worse, and we should try to at least publicize that these channels are unauthorized
2026-01-09 20:29:35 <Ariadne> (hence the above post)
2026-01-09 20:29:48 <achill> +1, do you mind commenting that on the council issue?
2026-01-09 20:29:55 <Ariadne> yes, do you have a link?
2026-01-09 20:30:01 <Ermine> maybe that should pe posted on Alpine's account as well
2026-01-09 20:30:16 <achill> https://gitlab.alpinelinux.org/alpine/council/-/issues/699
2026-01-09 20:30:20 <Ariadne> i don't have access to those accounts, as i don't manage communications
2026-01-09 20:31:45 <Ermine> Well, the one who has the access is here
2026-01-09 20:40:36 <Saijin_Naib[m]> Does Alpine have contacts with folks that went through setting up an org, etc?
2026-01-09 20:40:57 <Saijin_Naib[m]> I might be able to get our director to give some advice/help since I know we did so in the US, and are working on the EU now
2026-01-09 20:41:21 <Saijin_Naib[m]> From what they said, the legal side is a bit of a nightmare, but we had help from knowledgeable folks, so maybe I can link you up?
2026-01-09 20:41:38 <ikke> We tried to contact nlnet, but that died
2026-01-09 20:41:44 <achill> i know many people who set up a e.v. in germany and also in postmarketos we're trying to move a legal entity forward at FOSDEM
2026-01-09 20:42:08 <achill> i would happily report to the council how the process will go
2026-01-09 20:48:02 <Ariadne> achill: added: https://gitlab.alpinelinux.org/alpine/council/-/issues/699#note_573160
2026-01-09 20:48:08 <achill> thx :3
2026-01-09 20:52:24 <pj> Ariadne: sure but that is a platfom you can control (e.g. ban)
2026-01-09 20:52:27 <Ariadne> setting up a legal entity would also allow us to retain more of the donated funds to Alpine
2026-01-09 20:52:53 <Ariadne> pj: we already banned mckay is my point, years ago
2026-01-09 20:53:35 <Ariadne> so litigation is the only step remaining from that direction (i do not know that engaging in litigation with mckay is useful here, it seems like he would play on it)
2026-01-09 20:53:58 <Ermine> He would. He's a fascist after all
2026-01-09 20:54:00 <Ariadne> debian has had a similar problem with daniel pocock
2026-01-09 20:54:17 <pj> i would ban them from accessing internet permanently
2026-01-09 20:54:33 <Ariadne> i do not believe alpine has that capability :p
2026-01-09 20:54:51 <ikke> Well, our plan is to have every router run alpine linux
2026-01-09 20:54:53 <Ermine> I'd go further but that's probably against CoC to discuss there
2026-01-09 20:55:31 <pj> you can try to seize the bridged matrix rooms
2026-01-09 20:55:58 <pj> for example: #alpinelinux:matrix.org
2026-01-09 20:56:00 <Ariadne> there are matrix rooms?
2026-01-09 20:56:12 <Ariadne> can you update the council ticket with that information?
2026-01-09 20:56:14 <pj> way too many unfortunately
2026-01-09 20:57:07 <Ariadne> matrix, i think i can do something about.  the director of matrix.org is a personal friend of mine.
2026-01-09 20:59:31 <pj> btw. that message in screenshot bridged to matrix
2026-01-09 20:59:46 <pj> so you can unleash whatever hell on it
2026-01-09 21:00:49 <Ermine> inb4 he sets up his own server
2026-01-09 21:01:54 <pj> hopefully
2026-01-09 21:02:00 <pj> that way we can blackhole it
2026-01-09 21:02:03 <Ariadne> if he sets up his own server, then he has to pay for it
2026-01-09 21:02:36 <Ariadne> it will also impact discoverability
2026-01-09 21:09:58 <pj> Ariadne: #alpinelinux:matrix.org is not the mckay room actually
2026-01-09 21:10:09 <Ariadne> interesting
2026-01-09 21:10:11 <pj> it's also telegram bridged but with something? no idea
2026-01-09 21:10:20 <Ariadne> regardless, i will direct them to the ticket
2026-01-09 21:10:52 <pj> @evilenzo:matrix.org is admin of that room
2026-01-09 21:11:33 <pj> @mckaygerhard:matrix.org is :>
2026-01-09 21:11:53 <pj> (in case you want some account to ban)
2026-01-09 21:24:45 <Ariadne> i do not have any desire, personally, to go after mckay's account, just to degrade his ability to impersonate the Alpine project
2026-01-09 21:26:26 <Ariadne> if he has to move the content to his own homeserver, then that will cost him money and reduce his discoverability, thus degrading his ability to impersonate the Alpine project (my understanding is that mckay does not have much resources, and so forcing him to spend money to continue impersonating the project will likely reduce the scope of his impersonation)
2026-01-09 21:27:19 <pj> well, yes, he is using codeberg
2026-01-09 21:27:28 <Ariadne> oh is he?
2026-01-09 21:27:36 <pj> https://codeberg.org/alpine
2026-01-09 21:29:26 <Ermine> > Updated 5 months ago
2026-01-09 21:46:40 <jvoisin> why the hell is he even doing this
2026-01-09 21:51:27 <Ariadne> i haven't any clue, but he's been doing it since 2015
2026-01-09 21:51:46 <socksinspace> codeberg folks seem chill, you could probably contact them to have that part sorted out
2026-01-09 21:52:20 <Ariadne> yeah they are already on it
2026-01-09 21:53:55 <Ariadne> so he will likely be taking at least one L today
2026-01-09 22:08:14 <Ariadne> pj: codeberg has given mckay a 14 day deadline to rebrand the account or it will be deleted
2026-01-09 22:28:49 <Ariadne> telegram says in their FAQ:
2026-01-09 22:28:54 <Ariadne> > Note: If a scammer is pretending to be you, contact @NoToScam
2026-01-09 22:29:16 <Ariadne> I will try to contact this account and explain the situation, maybe it will be more productive
2026-01-09 22:43:05 <Ariadne> abuse report sent
2026-01-09 22:43:16 <Ariadne> and cc'd to the tracking bug
2026-01-09 22:43:23 <Ariadne> well, copied rather
2026-01-09 22:58:16 <markand> if you want to find against misinformation you'd rather had bad times
2026-01-09 22:58:47 <markand> I mean, if people can't distinguish by themselves what is an official Alpine channel and what it's not then you can't do anything about those lost cases
2026-01-09 22:59:50 <markand> and fighting against people creates streisand effects. I remember this old blog aboutthebsd which spreaded like a disease while people were activelty against
2026-01-09 23:04:07 <Ariadne> yes, which is why i propose in council#669 to explicitly communicate to the public that we do not operate any groups on Telegram, Discord, etc.
2026-01-09 23:04:24 <Ariadne> thanks algitbot :))))))
2026-01-09 23:04:41 <markand> haha
2026-01-09 23:06:51 <quinq> jaja
2026-01-09 23:06:52 <pj> algitbot spreading misinformation please ban
2026-01-09 23:28:45 <Ariadne> markand: anyway, i do not care what misinformation mckay wishes to spread, but many do care (myself included) about the use of alpine's identity as part of his campaign
2026-01-09 23:29:11 <Ariadne> if he wants to call his telegram group anything other than 'Alpine Linux' and use any other icon, i could not care less
2026-01-09 23:29:45 <Ariadne> the issue is his impersonation
2026-01-10 07:18:03 <ncopa> Someone once created a telegram account in my name, impersonating myself to try to force me create my own telegram account
2026-01-10 07:18:58 <ncopa> oh well, i merged community/pinta becuase the CI was green. now there is a checksum  error
2026-01-10 07:24:38 <ikke> 2 source files are not versioned
2026-01-10 07:25:00 <ikke> if they changed, the builders would get the old version from distfiles
2026-01-10 07:25:41 <ncopa> I need to eat breakfast and then I need to go out. If anyone has time to help me: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95344#note_573280
2026-01-10 07:25:47 <ncopa> ikke: yes, that is what is happening
2026-01-10 07:27:13 <ncopa> I'm also working on the icu 78 upgrade
2026-01-10 07:27:14 <ikke> The question is why these files are downloaded separately
2026-01-10 07:27:28 <ikke> I guess they are not part of the release archive
2026-01-10 07:27:31 <ncopa> because its dotnet
2026-01-10 07:27:35 <ncopa> sigh
2026-01-10 07:32:19 <ikke> working on it
2026-01-10 07:34:50 <ncopa> thanks!
2026-01-10 07:34:59 <ncopa> sorry
2026-01-10 07:43:32 <ikke> fixed
2026-01-10 09:07:48 <quinq> gg
2026-01-10 14:35:42 <ncopa> Bug #52820 (writes to fopencookie FILE* not committed when seeking the stream) [ext/standard/tests/f
2026-01-10 14:35:43 <ncopa> ile/bug52820.phpt]  
2026-01-10 14:35:56 <ncopa> i think that test fails on php83, php84 and php85
2026-01-10 14:36:55 <ncopa> ikke: thanks for fixing pinta
2026-01-10 15:42:32 <jvvv> seems like the x86 and x86_64 CI runners have issue?
2026-01-10 15:51:54 <jvvv> maybe just busy
2026-01-10 16:06:38 <ikke> At least right now they're quiet
2026-01-10 16:11:18 <jvvv> huh, i have CI that is stuck for x86 and x86_64. i tried restarting them, but didn't help
2026-01-10 16:13:46 <ikke> which?
2026-01-10 16:15:13 <jvvv> https://gitlab.alpinelinux.org/jvvv/aports/-/pipelines/394712
2026-01-10 16:15:13 <ikke> jvvv: the branch needs to be rebased
2026-01-10 16:15:26 <ikke> I've made a small tweak to .gitlab-ci.yaml
2026-01-10 16:15:53 <jvvv> ok, so cancel that one, rebase then run again?
2026-01-10 16:15:56 <ikke> yes
2026-01-10 16:16:04 <jvvv> thanks, appreciated
2026-01-10 16:19:17 <jvvv> that did it. in future, when I have MR that is growing stale and need to run CI for a change, i should rebase?
2026-01-10 16:20:31 <ikke> yeah, that's how I typically do it
2026-01-10 16:23:04 <jvvv> ok, thanks again. i will adjust my work flow going forward.
2026-01-10 19:07:19 <lnl> Hi, I can't get x86_64 CI to pass a chromium build since last month, could we get !95268 and !95270 merged?
2026-01-10 19:10:36 <ikke> We lost our x86_64 servers, we have replacements, but those are multiple smaller servers
2026-01-10 19:41:17 <achill> lnl: merged the edge one, will try to push the 3.23 one after the edge builders are clear (if i dont forget)
2026-01-11 08:48:33 <ncopa> achill, lnl: I merged 3.23 one. edge builders were clear. Thanks!
2026-01-12 04:05:51 <achill> so the glycin/gdk-pixbuf changes will soon hit the mirrors, it got a bit messy but most stuff should be fine now as soon as the builder finish
2026-01-12 04:05:55 <achill> tldr: gdk-pixbuf uses glycin, glycin got split into subpkgs
2026-01-12 04:05:56 <achill> its also quite likely that there will rise up a few issues by this. if you think this might be related, please ping me! :3
2026-01-12 04:14:06 <Saijin_Naib[m]> Does the gdk-pixbuf package pull in all glycin subpackages?
2026-01-12 04:15:16 <Saijin_Naib[m]> Or do I have to specify, say, svg, png, webp subpackages if the program uses themm
2026-01-12 04:15:59 <achill> it doesnt pull in the loaders, but you'll get a post-upgrade with a warning and available loaders to install
2026-01-12 04:17:00 <achill> if a package uses a specific loader, it should depend on that. if a packages uses glycin for general image display, it should depend on glycin-image-rs.
2026-01-12 04:18:26 <achill> oh and also glycin-image-rs is automatically installed with glycin
2026-01-12 04:24:05 <Saijin_Naib[m]> Okay, so for instance, a package that one can expect to load any* type of images, I would just have it depend upon glycin, and that pulls glycin-image-rs, and then all the subpackage loaders?
2026-01-12 04:24:39 <Saijin_Naib[m]> There are a few aports I'll need to change, I think
2026-01-12 04:25:40 <achill> no for any file type, use glycin-image-rs since that has basic file type support
2026-01-12 04:26:18 <achill> for existing packages, i already updated it (917961f26db7691a715b6b7a123689b4af661b7d)
2026-01-12 04:27:21 <Saijin_Naib[m]> Ahh, cool, okay
2026-01-12 04:27:24 <achill> and if it just uses C libglycin, you can just let abuild take care of it and dont have to manually depend on anything
2026-01-12 04:27:46 <Saijin_Naib[m]> Thanks abuild 😍
2026-01-12 04:42:45 <achill> but now i can finally go to bed
2026-01-12 07:59:55 <kunkku> at least my xfce desktop broke completely :(
2026-01-12 08:09:03 <kunkku> symptoms: no background/icons are rendered, xfce4-panel crashes when on opening the Applications menu
2026-01-12 08:11:36 <kunkku> screensaver does not work: if the desktop gets locked, there is no way to get back
2026-01-12 08:19:37 <ikke> kunkku: ouch
2026-01-12 08:47:35 <ncopa> my guess is that it is related the recent gdk-pixbu / glycin change
2026-01-12 08:47:59 <ncopa> I also use xfce but I havent upgraded yet
2026-01-12 08:54:56 <kunkku> glycin-loaders-all has broken dependencies, but fixing those does not seem to resolve the desktop issue
2026-01-12 11:00:14 <ncopa> zotero dependencies fails to install now
2026-01-12 11:00:41 <ncopa> https://tpaste.us/voQk
2026-01-12 11:13:03 <fcolista> same issue with mkvtoolnix
2026-01-12 11:36:22 <ncopa> gtk-update-icon cache moved to gtk4
2026-01-12 11:36:42 <ncopa> can gtk3 use icon cache gnereated from gtk4?
2026-01-12 11:39:47 <ncopa> seems like that should work
2026-01-12 12:12:40 <achill> ncopa: thanks for fixing that
2026-01-12 12:12:47 <achill> i'll try to boot a xfce4 vm
2026-01-12 12:36:28 <PureTryOut> I already PR'ed a fix for it earlier 🤔
2026-01-12 12:43:43 <ncopa> this one: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95758 for some reason gtk4 build failed. it also did not delete the manpage
2026-01-12 12:44:37 <ncopa> i think it may have passed once build-edge-riscv64 passed and uploaded the latest stuff, but that could take the entire day and I didnt want to wait more than necessary
2026-01-12 12:53:50 <PureTryOut> yeah riscv64 builder was just behind. It's fine, you saw it and linked your PR at least 😉
2026-01-12 13:36:36 <ptrc> https://ptrc.gay/VWykLEIv.png
2026-01-12 13:36:46 <ptrc> i assume there's a $pkgname missing somewhere?
2026-01-12 13:37:04 <achill> yeah already fixed it a few mins ago
2026-01-12 13:37:07 <achill> apk upgrade :p
2026-01-12 13:37:21 <achill> I messed up a lot more than expected
2026-01-12 13:37:51 <ptrc> must not be in my mirror yet, welp
2026-01-12 13:40:00 <achill> oh yeah I know the feeling, I use the mirror of my uni, so I have not a lot of latency, but if I have to wait x hours for the packages to arrive, ehh
2026-01-12 13:40:16 <ptrc> speaking of, the svg loader might be needed by a lot of desktop components 
2026-01-12 13:40:22 <ptrc> i've had apps crashing on a failed assertions
2026-01-12 13:40:30 <ptrc> because image-missing.svg can't be loaded
2026-01-12 13:40:40 <achill> yeah I've also added that back
2026-01-12 13:40:57 <achill> the bootstrap is still broken but at least apps work lol
2026-01-12 13:41:12 <ptrc> ohhhh i just saw 3f7645107b0f
2026-01-12 13:41:13 <ptrc> right
2026-01-12 13:41:15 <ptrc> thanks <3
2026-01-12 13:56:51 <achill> kunkku: so now with -svg now, xfce works for me
2026-01-12 15:04:58 <kunkku> achill: +1
2026-01-12 19:58:34 <ffoss> anyone using firefox-developer-edition on edge with custom userContent.css? mine stopped working for non-builtin websites it seems like
2026-01-12 20:35:31 <PureTryOut> Could somebody explain why in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95675 community/kconfigwidgets keeps pulling in the wrong version of community/kcodecs? It really wants 6.21.0 while it should just install 6.22.0, and I don't understand why that is the case
2026-01-12 20:36:07 <ikke> PureTryOut: without looking, maybe some version constraint from another dependency?
2026-01-12 20:37:20 <achill> yeah try adding a constraint e.g. kcodecs~6.22.0 in the depends on kconfigwidgets and see what apk complaints
2026-01-13 05:41:27 <Saijin_Naib[m]> Does linux-lts for x86_64 include NTSYNC? If not, is it likely to be accepted if I open an MR? Better WINE perf is important to me for various tools and games I can use otherwise
2026-01-13 05:41:37 <Saijin_Naib[m]> Cant
2026-01-13 05:50:31 <ikke> Saijin_Naib[m]: zgrep -i ntsync /proc/config.gz returns nothing
2026-01-13 05:50:35 <ikke> not sure if it's supposed to
2026-01-13 05:51:08 <ikke> lts.x86_64.config
2026-01-13 05:51:10 <ikke> 752:CONFIG_NTSYNC=m
2026-01-13 05:51:13 <ikke> It's a module you can load
2026-01-13 07:31:35 <PureTryOut> achill: already did, it _still_ tries to install 6.21.0. And apk doesn't tell me anything useful on why this happens
2026-01-13 07:32:52 <PureTryOut> ikke: kcodecs itself depends on almost nothing, and at least nothing that could cause a circular dependency for example. If another dep of kconfigwidgets is pulling it in then 1. apk should complain and 2. `ap builddirs` should probably sort that dep to build before kconfigwidgets
2026-01-13 07:37:14 <Biswa96[m]> I semi-maintained kde frameworks in a repository. splitting the update in tiers helps to prevent those kind of conflicts, like these https://invent.kde.org/packaging/craft-blueprints-kde/-/tree/master/kde/frameworks?ref_type=heads
2026-01-13 07:39:42 <ikke> PureTryOut: it may be me, but I don't see it installing kcodecs at all in the last pipeline
2026-01-13 07:42:16 <ikke> If you explicitly request one version and something else wants another version, then apk should indeed complain
2026-01-13 07:42:34 <ikke> If apk does not complain, maybe something else is happening
2026-01-13 07:45:46 <PureTryOut> ikke: that seems to be just you. In the latest pipeline it reports trying to install `kcodecs-dev=6.21.0-r0` and then fail because the APKBUILD is specifically requesting `6.22.0`. I'm looking at the ppc64le pipeline specifically if that helps, but behaviour is the same on all arches
2026-01-13 07:46:11 <ikke> I was checking x86_64
2026-01-13 07:46:52 <PureTryOut> seems that arch hasn't gotten that far yet, the builder appears to be way slower recently
2026-01-13 07:47:01 <PureTryOut> (not that fur until it timed out)
2026-01-13 07:47:33 <PureTryOut> You could check aarch64 as well, it got to building that but fails the same
2026-01-13 07:50:19 <PureTryOut> Biswa96: I'm not sure how that would help anything in this case. No matter in what order I package things, eventually it'll have to try building kconfigwidgets with kcodecs in the right version. And I can't first push an updated kcodecs to the repos and only kconfigwidgets afterwards as until everything has built you wouldn't be able to upgrade your system due to soname differences and such. It all has to be pushed at once.
2026-01-13 08:07:26 <omni> I looked a little bit at it and don't get why it would try to build kconfigwidgets before kconfig, regardles of setting kconfig-dev>=$pkgver or not
2026-01-13 08:11:42 <PureTryOut> well, kcodecs, but yeah same
2026-01-13 08:15:03 <omni> ah, yes, that was what I meant
2026-01-13 08:25:36 <staceee> I'm trying to package something, and it conflict with another package, even with replaces=. Is that known?
2026-01-13 08:26:37 <ikke> staceee: all that "replaces" does is to tell apk that it's okay that one package has the same files as another packagee
2026-01-13 08:26:53 <ikke> In what way does the package conflict?
2026-01-13 08:27:03 <staceee> both provides usr/bin/xdg-open
2026-01-13 08:27:14 <staceee> so my package replaces=xdg-utils
2026-01-13 08:27:45 <ikke> It still does not mean they can be installed at the same time
2026-01-13 08:27:45 <staceee> is it possible the -doc package, that also provides usr/share/man/man1/xdg-open.1.gz cause a problem?
2026-01-13 08:27:51 <staceee> ah?
2026-01-13 08:28:34 <staceee> the doc does not say that
2026-01-13 08:28:55 <staceee> > Allow this package to be installed at the same time as the listed packages, even if they have conflicting files. The files from this package will override ("take over") the conflicting files.
2026-01-13 08:29:25 <ikke> Sorry, yes, the problem is the cmd: provides that conflicts
2026-01-13 08:30:52 <staceee> what should I do? just add :provides="cmd:xdg-open" ?
2026-01-13 08:31:43 <staceee> nah it seems not enough
2026-01-13 08:31:53 <ikke> Abuild automatically adds thosee
2026-01-13 08:34:55 <staceee> so, is there a problem with abuild? or apk?
2026-01-13 08:35:20 <ikke> No problem with either, they behave as expected
2026-01-13 08:35:38 <staceee> how can I fix this recipe?
2026-01-13 08:36:10 <ncopa> ayakael: I have rebuilt all packages against icu 78 - except zotero. I wonder if I can merge icu 78 and let you deal with zotero?
2026-01-13 08:37:58 <ikke> staceee: first, you have to adjust your expectations. Using replaces for this can work, but is not going to give a nice experience
2026-01-13 08:38:33 <ikke> If you install that package, and then remove it, your system will be without xdg-open until you run apk-fix on xdg-utils
2026-01-13 08:39:49 <staceee> oh, that looks like an apk issue to me
2026-01-13 08:41:06 <ikke> 2nd: you cannot install 2 packages with same provides at the same time
2026-01-13 08:42:40 <staceee> the project I'm working on would just provides a xdg-open, not the whole binaries from xdg-utils. So I can not just take its whole place
2026-01-13 08:43:58 <staceee> and afaik I can not configure which xdg-open binary is used by the ecosystems. So taking its place in the PATH seems to be the only way
2026-01-13 08:47:18 <ikke> A proper/explicit way (if accepted by the xdg-utils maintainer) would be to create a split package for xdg-utils xdg-open 
2026-01-13 08:48:46 <ncopa> hum i think maybe zotero built for me?
2026-01-13 08:49:33 <ikke> And more scalable would be implementing something like alternatees
2026-01-13 08:49:54 <staceee> ikke: another idea I have could be to install binaries in sub-directories, somewhere, and adjust the PATH using some profiles.d/ script
2026-01-13 08:50:19 <staceee> how would works alternatees?
2026-01-13 08:50:22 <ikke> staceee: that would count as an alternate-like system I suppose
2026-01-13 08:50:36 <ikke> Similar, but with symlinks I believe
2026-01-13 08:50:45 <ikke> A script that would adjust the symlinks
2026-01-13 08:51:58 <ncopa> icu 78 is merged
2026-01-13 08:52:51 <staceee> I still think that replaces currently have big limitations that could be solved
2026-01-13 08:53:40 <staceee> it should resolve cmd: provides, it should make apk fix the removed path on uninstall
2026-01-13 08:54:12 <staceee> I'd say apk got all the data to deal correctly with this situation no?
2026-01-13 08:55:13 <ikke> Replaces is a broad hammer, not very specific. The main goal was to fix conflicts when you for example renamed a package, or some file was moved from one package to another
2026-01-13 08:58:55 <staceee> symlinks are not really the same thing as regular files. I fear it might break some programs if some of their file can become symlink
2026-01-13 08:59:29 <ikke> staceee: debian/ubuntu have an alternate system
2026-01-13 09:00:00 <staceee> well
2026-01-13 09:00:09 <ikke> But without it, having dedicated subpackages with a proper priority would work
2026-01-13 09:00:35 <staceee> where should we open a ticket to? let's put this down
2026-01-13 09:00:50 <staceee> for the alternate system
2026-01-13 09:01:10 <ikke> That's a larger system change
2026-01-13 09:04:31 <ikke> So that would be the alpine/tsc project
2026-01-13 09:24:47 <ncopa> we kind of have alternatives feature already in different forms
2026-01-13 09:26:12 <ncopa> one very hackish is busybox which provides symlinks for cp ls etc, and then coreutils can replace those. apk del coreutils restores the busybox symlinks
2026-01-13 09:26:42 <ncopa> but that implementation is very hackish and I don't think we want that for xdg-open
2026-01-13 09:28:06 <ncopa> other, better, example is "initramfs-generator". kernel needs an initramfs-generator. kernel does not care which but needs something to generate initramfs
2026-01-13 09:28:40 <ncopa> mkinitfs, dracut are different initramfs generators
2026-01-13 09:31:01 <ncopa> i think we had some sort of alterates for openjdk at some point too, but I don't know what the status is there
2026-01-13 09:31:25 <ncopa> we also have different sshd builds, with and without PAM support
2026-01-13 09:31:47 <ncopa> same with zabbix binary IIRC, depening on what database you want use
2026-01-13 09:36:30 <staceee> interesting, one thing at a time. I've openned up the mr for xdg-utils ncopa. At least now I have a working recipe
2026-01-13 09:39:43 <ikke> Zabbix is building the same source multiple times with different options and then splitting them in subpackages
2026-01-13 09:39:53 <ikke> And you install the varian that you wnaat
2026-01-13 09:40:00 <ikke> Want*
2026-01-13 09:48:11 <staceee> ikke: I've mentionned that this could suport multiple version, by example for postgres
2026-01-13 09:48:32 <staceee> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/105
2026-01-13 09:49:28 <ncopa> we have discussion about alternate system in the past
2026-01-13 10:16:33 <ikke> postgres on alpine already has an alternate like system
2026-01-13 10:17:45 <ikke> pg_versions
2026-01-13 10:33:34 <staceee> yap, and it does something very similar
2026-01-13 11:19:36 <ncopa> smeels like circular dep: https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/qt6-qtbase/qt6-qtbase-6.10.1-r1.log
2026-01-13 11:20:04 <ncopa> yup
2026-01-13 11:20:10 <ncopa> we have circular deps somewhere
2026-01-13 11:20:31 <ncopa> qt6-qtbase is in the dependency tree for qt5-qtbase and the other way around
2026-01-13 11:31:04 <staceee> the first version was working, even with circular dep
2026-01-13 14:08:45 <jvvv> if someone with commit rights has time, could !95745 be merged?
2026-01-13 14:50:26 <jvvv> fossdd: thanks for the review. i added a comment and attached a patch.
2026-01-13 14:58:37 <jvvv> qaqland: for the xboard MR, if you add the patch i attached, that will remove the need for the added compiler flag
2026-01-13 15:01:02 <lotheac> clandmeter: is major upgrade of py3-pybind11 to 3.0.1 ok with you? !94584
2026-01-13 15:24:26 <Saijin_Naib[m]> @ikke thanks, I'll test that against WINE11 which uses it by default now
2026-01-13 17:59:40 <Ariadne> why would qt6 pull in qt5
2026-01-13 18:07:50 <Biswa96[m]> any steps to reproduce it?
2026-01-13 18:19:00 <ikke> Some transitive dependency
2026-01-13 18:20:03 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17887#note_574339
2026-01-13 23:10:54 <Saijin_Naib[m]> Is there a reccommended/maintained drop-in replacement for libxml2-dev when we are packging/building?
2026-01-13 23:20:23 <achill> not really
2026-01-13 23:20:33 <achill> you mean because of the maintainance state?
2026-01-13 23:22:55 <ptrc> does anyone else get random segfaults from stuff like gimp/darktable after the pixbuf update
2026-01-13 23:23:25 <achill> yes thats on me :)
2026-01-13 23:24:00 <achill> librsvg had ABI changes because i removed the gdk-pixbuf-specific API because it couldnt depend on it since then we'd have another dep cycle
2026-01-13 23:24:20 <ptrc> ohh hm
2026-01-13 23:24:23 <achill> im currently working on splitting libglycin with glycin-loaders, so that librsvg can properly depend on gdk-pixbuf
2026-01-13 23:24:37 <achill> and gdk-pixbuf just depends on libglycin
2026-01-13 23:25:14 <achill> real shame that i didnt found that out before merging, and edge has to go through all of my changes
2026-01-13 23:30:26 <Saijin_Naib[m]> achillyesterday both my XFCE craptop and my wife's GNOME craptop were broken, but they at least work today, so thanks for all your work fixing that up
2026-01-13 23:31:13 <Saijin_Naib[m]> achillyeah, the unmaintained state of libxml2. If I am adding a new aport, even just into testing, I wanted to see if there is a new best-practice for replacing that dep since we know now it is unmaintained, before I add the new aport
2026-01-13 23:31:30 <achill> now feel free to continue to use it
2026-01-13 23:31:40 <achill> it's also maintained again, but still way too over use
2026-01-13 23:31:54 <Saijin_Naib[m]> This is incredibly low stakes (aqualung GTK music player), but just checking for future reference and my other aports
2026-01-13 23:32:23 <achill> but from the alpine side there is no decision, maybe an interesting idea to the security team
2026-01-13 23:32:57 <Saijin_Naib[m]> I'm not knowledgeable enough to argue one way or another, just asking because it keeps coming up in my news reader and my fedi feed
2026-01-13 23:33:06 <Saijin_Naib[m]> I trust you all, haha
2026-01-13 23:33:51 <achill> yeah libxml is certainly not in a great place, but at least there are new maintainers on it
2026-01-13 23:34:24 <Saijin_Naib[m]> That one XKCD comic comes to mind, as ever
2026-01-13 23:34:56 <Saijin_Naib[m]> ikkeNTSYNC works great, btw. Thanks for confirming its inclusion
2026-01-13 23:45:26 <achill> okay i think i'll push in a few mins the libglycin/glycin split
2026-01-13 23:49:19 <Ariadne> i haven't any clue what to do about libxml2 tbh
2026-01-14 00:00:17 <jxanthony> Hi, all. Just wanted to quickly flag that librdkafka is currently showing as out of date on pkgs.alpinelinux.org, but the new tag is v2.13.0-deleted-20260105060516 and shouldn't be used: https://github.com/confluentinc/librdkafka/tags
2026-01-14 00:00:26 <jxanthony> Not sure if there's anything I can do to get it back to green
2026-01-14 00:13:06 <achill> if its a false-positive, do nothing. if you feel so, you can try tickling anitya into giving a correct latest version
2026-01-14 00:14:03 <achill> the aniya project for librdkafka would be https://release-monitoring.org/project/12573/
2026-01-14 00:15:01 <achill> Ariadne: yeah i think we are not in power to change the landscape in that aspect, libxml2 is just way too much used
2026-01-14 00:31:14 <jxanthony> Yeah, it's definitely a false positive
2026-01-14 00:31:53 <jxanthony> I'll take a look at aniya maybe in the morning
2026-01-14 07:04:17 <ncopa> cycle: colord-dev <- gtk-update-icon-cache <- gtk+3.0-dev <- qt6-qtbase-dev <- v4l-utils-dev <- sane-dev <- colord-dev
2026-01-14 07:17:41 <craftyguy[m]> another one needing to be rebuilt against icu: !95868
2026-01-14 07:18:24 <ikke> craftyguy[m]: it's already being rebuilt, but due to a decency cycle, failing to build 
2026-01-14 07:18:53 <craftyguy[m]> ahh, sorry for the noise then
2026-01-14 07:19:07 <ikke> dependency cycle*
2026-01-14 07:19:47 <ikke> ncopa: But that cycle does not explain why qt5-qtbase is being pulled in, does it?
2026-01-14 07:21:16 <PureTryOut> yeah that part makes no sense to me at all
2026-01-14 07:23:26 <PureTryOut> I'll see if I can just remove the gtk dep from Qt, having that also makes no sense to me 😛
2026-01-14 07:25:00 <ncopa> yeah, I was just thinking that. why does qt6-qtbase need gtk+3.0?
2026-01-14 07:25:06 <ncopa> i think that is leftover cruft
2026-01-14 07:25:16 <PureTryOut> I'm not sure why it was added. But first test indicates it can be removed, I'll MR it
2026-01-14 07:25:37 <ncopa> thanks!
2026-01-14 07:28:32 <ncopa> even with that fixed we still get:
2026-01-14 07:28:35 <ncopa> cycle: colord-dev -> sane-dev -> v4l-utils-dev -> qt6-qtbase-dev -> libinput-dev -> gtk+3.0-dev -> gtk-update-icon-cache -> colord-dev
2026-01-14 07:29:32 <ncopa> ikke: I believe this is the reason qt5 got pulled in yes
2026-01-14 07:30:26 <ncopa> or... maybe not
2026-01-14 07:31:37 <PureTryOut> and why does libinput depend on gtk? 😅
2026-01-14 07:32:13 <ncopa> you are asking the correct question
2026-01-14 07:32:46 <ncopa> meson.build:676:12: ERROR: Dependency "gtk+-3.0" not found, tried pkgconfig
2026-01-14 07:33:43 <ncopa> 	pkgdesc="GTK-based visual debug helper for libinput"
2026-01-14 07:34:03 <PureTryOut> Huh, ok... Maybe we can just make a separate package if that's useful to have
2026-01-14 07:34:13 <ikke> -Ddebug-gui=true
2026-01-14 07:34:45 <ncopa> or we use gtk4.0
2026-01-14 07:35:37 <ncopa> using gtk4.0 does not solve it
2026-01-14 07:35:51 <ncopa> then we get cycle: colord-dev -> sane-dev -> v4l-utils-dev -> qt6-qtbase-dev -> libinput-dev -> gtk4.0-dev -> colord-dev
2026-01-14 07:36:24 <PureTryOut> preferably such a package does not depend on a GUI toolkit at all. I can imagine the application being useful though so maybe we can build it as it's own package
2026-01-14 07:36:33 <ncopa> yeah
2026-01-14 07:36:40 <ncopa> that makes sense
2026-01-14 07:36:59 <ncopa> ncopa-desktop:~/aports/community (master)$ ap circular-deps libinput
2026-01-14 07:36:59 <ncopa> ncopa-desktop:~/aports/community (master)$ 
2026-01-14 07:37:03 <ncopa> that solves it
2026-01-14 07:37:17 <ncopa> it does
2026-01-14 07:37:19 <PureTryOut> Awesome. Also good to know that command exists!
2026-01-14 07:37:23 <ikke> ncopa: did you add that subcommand to lua-aports?
2026-01-14 07:37:30 <ikke> Mine doesn't have  it
2026-01-14 07:37:37 <ncopa> i kinda vibecoded it yesterday and today...
2026-01-14 07:37:44 <PureTryOut> oh...
2026-01-14 07:37:46 <ncopa> but it works surprisingly well
2026-01-14 07:37:59 <PureTryOut> That's disappointing 😢
2026-01-14 07:38:59 <ncopa> not sure I want to push it for prod for that reason
2026-01-14 07:39:13 <ncopa> without a proper review
2026-01-14 07:39:29 <ikke> And licensing uncertainty
2026-01-14 07:41:38 <PureTryOut> seems you can't easily build libinput's GUI standalone (without writing your own meson.build at least) so I guess we'll have to build the whole thing twice and just remove everything that's not the GUI
2026-01-14 07:42:38 <ikke> But it needs to be a separate package to avoid the makedepends, right?
2026-01-14 07:42:46 <ncopa> yes
2026-01-14 07:43:10 <PureTryOut> Yeah
2026-01-14 07:49:39 <ncopa> im creating a MR for libinput
2026-01-14 07:50:57 <PureTryOut> 👍️
2026-01-14 07:51:02 <ikke> PureTryOut did also push a commit to remove gtk+3.0 from qt6-qtbase
2026-01-14 07:51:14 <ikke> Most builders are idle,
2026-01-14 07:52:40 <ncopa> this is the circular-deps branch: https://gitlab.alpinelinux.org/ncopa/lua-aports/-/tree/circular-deps?ref_type=heads
2026-01-14 08:13:28 <PureTryOut> for librsvg it's now also somehow pulling in qt5-qtbase, that makes no sense
2026-01-14 08:49:52 <ikke> Why is this only affecting loongarch? Are we missing some rebuilds on the other arches?
2026-01-14 09:13:03 <ncopa> we have more apparently
2026-01-14 09:22:51 <ncopa> its gdk-pixbuf
2026-01-14 09:23:23 <ncopa> and this I suspect: fbfe1b462e7ccfe9e8147950a3ba9f0099d394e5
2026-01-14 09:32:12 <ncopa> ok. it fails on build-edge-loongarch64 because it has not yet built glycin-2.0.7-r9
2026-01-14 09:32:22 <ncopa> it is still glycin-2.0.7-r7
2026-01-14 09:34:19 <ncopa> i think dependeny order may have been changed in the middle of the build or something
2026-01-14 09:36:59 <ncopa> i deleted glycin-2.0.7-r7 package
2026-01-14 09:37:06 <ncopa> on build-edge-loongarch64
2026-01-14 09:42:05 <ncopa> i think moving gtk-update-icon-cache to gtk4 was a bit problematic
2026-01-14 09:42:13 <ncopa> we still have circular deps
2026-01-14 09:42:20 <ncopa> cycle: colord-dev -> sane-dev -> v4l-utils-dev -> sdl2-dev -> libdecor-dev -> gtk+3.0-dev -> gtk-update-icon-cache -> colord-dev
2026-01-14 09:46:31 <ncopa> in theory, I dont think sane-dev needs the v4l-utils-dev 
2026-01-14 10:00:05 <PureTryOut> Glad to see Qt is out of that chain at least
2026-01-14 10:17:16 <ncopa> yeah
2026-01-14 10:17:54 <ncopa> but its all a mess, everything expects to build in two stages to bootstrap things
2026-01-14 10:18:53 <ncopa> eg, gtk4.0 should in theory be built twice, one time without colord and then a second pass with colord enabled
2026-01-14 10:19:18 <ncopa> and colord should also be built two-pass. first with out sane and second with sane
2026-01-14 10:20:38 <ncopa> can we really remove gtk-update-icon-cache from gtk+3.0 deps?
2026-01-14 10:21:50 <ncopa> im pretty sure this will pop up again when we build 3.24
2026-01-14 10:28:19 <PureTryOut> v4l is Video4Linux right? Why would sane need anything of that?
2026-01-14 10:28:44 <ikke> Was wondering the same
2026-01-14 10:29:17 <ikke> Apparently sane-v4l exists
2026-01-14 10:30:44 <ikke> I guess to use cameras as scanners?
2026-01-14 10:36:21 <PureTryOut> Ah I suppose
2026-01-14 11:09:50 <ncopa> rust stuff is painfully slow to build
2026-01-14 11:19:48 <qaqland> fossdd: imo the pace of merging !95744 is a bit too fast, and it's feeling a bit overwhelming
2026-01-14 12:28:13 <achill> qaqland: well i dont know what to expect. if you dont feel comfortable with something being merged, maybe can you set it to draft? or some comment with "meow please keep it open for a few days to catch some more eyes".
2026-01-14 12:32:58 <ikke> achill: there were some maintainers pinged that have not given feedback yet
2026-01-14 12:44:43 <achill> right, i suppose i could've waiting for their approval, but on the other hand it was pretty trivial, but yeah i guess waiting a few more days don't hurt
2026-01-14 17:00:29 <ncopa> I am working on the ap circular-deps thingy
2026-01-14 17:00:58 <ncopa> it is a bit noisy. it for example flags packages that depends on its own subpackages
2026-01-14 17:01:20 <ncopa> which does not matter when looking for build time circular deps
2026-01-14 17:01:47 <ncopa> so I'm building a graph based on the aport (the dir it comes from)
2026-01-14 17:03:33 <ncopa> but then it won't flag stuff like openjdk21 which needs openjdk21-bootstrap at build time
2026-01-14 17:03:58 <ncopa> so I dont know what is worse. flagging to much (and be very noisy)
2026-01-14 17:04:40 <ncopa> or not flag things that depends on it self and need bootstrapping (eg openjdk21-bootstrap)
2026-01-14 17:05:22 <achill> can you just do manual exceptions, there aren't toooo many packages that are self-bootstrapped
2026-01-14 17:05:42 <ncopa> the noisy variant will also tell the exact package, eg: colord-dev -> sane-dev -> v4l-utils-dev -> sdl2-dev -> libdecor-dev -> gtk+3.0-dev -> gtk-update-icon-cache -> colord-dev
2026-01-14 17:05:52 <ncopa> whil i think the non-noisy will only report the aport name
2026-01-14 17:06:18 <achill> yeah i think knowning the full cycle is quite important
2026-01-14 17:06:29 <achill> so i'd tend to that :)
2026-01-14 17:06:40 <ncopa> noisy variant?
2026-01-14 17:06:45 <achill> yeah
2026-01-14 17:07:18 <ncopa> let me show you why I started to work on the non-noisy variant
2026-01-14 17:08:46 <ncopa> $ ap circular-deps | tpaste
2026-01-14 17:08:46 <ncopa> https://tpaste.us/gbrd
2026-01-14 17:09:01 <ncopa> and here I have already filtered out direct dependencies on itself
2026-01-14 17:09:54 <ncopa> in that list there are only two that are really relevant
2026-01-14 17:10:03 <ncopa> cycle: dbus:org.freedesktop.Secrets -> kconfig-dev -> xwayland-run -> weston-backend-headless -> freerdp-dev -> webkit2gtk-4.1-dev -> dbus:org.freedesktop.Secrets
2026-01-14 17:10:03 <ncopa> cycle: colord-dev -> sane-dev -> v4l-utils-dev -> sdl2-dev -> libdecor-dev -> gtk+3.0-dev -> gtk-update-icon-cache -> colord-dev
2026-01-14 17:10:15 <ncopa> the others are just noise
2026-01-14 17:10:21 <achill> yeah hmmm
2026-01-14 17:10:44 <ncopa> but it also shows that something is weird with the openjdk*-bootstrap
2026-01-14 17:10:49 <ncopa> which is correct
2026-01-14 17:11:00 <ncopa> i mean, it may be a good thing to see that
2026-01-14 17:11:12 <achill> but i think if you take into account which of them are subpackages and built together anyway, that should be less?
2026-01-14 17:11:47 <ncopa> yes
2026-01-14 17:11:49 <ikke> ncopa: Do you know the origin of subpackages? You could filter out if the cycle is between a subpackage and its origin?
2026-01-14 17:11:56 <ncopa> yes
2026-01-14 17:11:59 <ncopa> i can filter
2026-01-14 17:12:01 <ncopa> but
2026-01-14 17:12:47 <ncopa> rather than build a huge graph and afterwards spend cpu cycles filtering it (both may be costly) - it is much more efficient to build the graph on the origin only
2026-01-14 17:13:15 <ncopa> the graph becomes significantly smaller and we dont need to filter
2026-01-14 17:14:09 <achill> btw your script also didn't notice https://gitlab.alpinelinux.org/alpine/aports/-/issues/17770
2026-01-14 17:14:14 <ncopa> so I started to work on that, but then I realized that we may lose the exact package names, and the real self depends (eg openjdk*-bootstra)
2026-01-14 17:14:17 <achill> or wait maybe the loop was jsut fixed
2026-01-14 17:14:29 <ncopa> i think the loop was fixed
2026-01-14 17:14:34 <achill> ah
2026-01-14 17:15:24 <ncopa> sorry, no it wasnt
2026-01-14 17:15:29 <ncopa> and it detects it
2026-01-14 17:15:32 <ncopa> cycle: py3-execnet -> py3-pytest -> py3-iniconfig -> py3-pytest-xdist -> py3-execnet
2026-01-14 17:15:54 <ncopa> this one is real as well cycle: bison -> flex -> bison
2026-01-14 17:16:11 <ikke> Yeah, we need to take that into account when bootstrapping
2026-01-14 17:16:54 <ncopa> the nice thing is that with `APORTS_BOOTSTRAP=1 ap circular-deps` it no longer show bison
2026-01-14 17:17:01 <ikke> ack
2026-01-14 17:17:37 <ncopa> in main: $ ap circular-deps | tpaste
2026-01-14 17:17:37 <ncopa> https://tpaste.us/e6JE
2026-01-14 17:18:13 <ncopa> i dont think that is very useful
2026-01-14 17:18:32 <ncopa> the other option is that I implement both
2026-01-14 17:18:58 <ncopa> as `ap circular-deps` and `ap circular-builddeps` or similar
2026-01-14 17:19:12 <ncopa> but it is the buildtime deps that is interesting
2026-01-14 17:20:09 <ncopa> also note that this script cannot pick up hacks where depends= are set inside of package() and in the split functions
2026-01-14 17:20:33 <ncopa> which makes me think that the verbose variant is not that useful
2026-01-14 17:21:20 <ncopa> the idea here is to run this from CI, so we get notified when reviewing
2026-01-14 17:21:48 <ikke> yeah, was thinking the same, but it should be clean then (no false positives, things that don't need to be fixed)
2026-01-14 17:22:07 <ncopa> yeah false positives is a killer here. it will only make people ignore it
2026-01-14 17:22:23 <ncopa> its better that it misses the openjdk*-bootstrap things then
2026-01-14 17:23:07 <ikke> And I guess bison -> flex -> bison as well
2026-01-14 17:24:00 <craftyguy[m]> in apkbuild / abuild, the list of subpackages to build can't be modified e.g. in package(), right?
2026-01-14 17:24:08 <ncopa> i think that may be the only exception. alternatively we drop testing for bison/flex
2026-01-14 17:24:23 <ikke> craftyguy[m]: abuild needs to know it before building the package
2026-01-14 17:24:25 <ncopa> craftyguy[m]: correct
2026-01-14 17:24:47 <craftyguy[m]> thanks :)
2026-01-14 18:26:17 <craftyguy[m]> this gitlab runner seems reeeeeally unhappy: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/2174152
2026-01-14 18:31:43 <ikke> Not sure why, it claims that there is no node available with sufficient memory available versus what's requested
2026-01-14 18:32:43 <ikke> But the nodes don't show more than 50% used (but not sure what's requested)
2026-01-14 18:38:20 <Profilerrrr> What's the proper way to compile C code for profiling under Alpine? The -pg option for gcc fails at linking due to gcrt1.o being unavailable.
2026-01-14 19:12:52 <ikke> craftyguy[m]: I've identified an issue with the mount of resources requested, which I'm addressing
2026-01-14 19:13:22 <ikke> The irony is that the CI job to adjust is runs into the same issue
2026-01-14 19:17:47 <bl4ckb0ne> im getting `Cannot utime: No such file or directory` when running `abuild` to unpack sources, is there anything I can do?
2026-01-14 19:19:23 <ikke> bl4ckb0ne: perhaps https://askubuntu.com/a/631570?
2026-01-14 19:19:51 <bl4ckb0ne> its a sshfs mounted folder, the other deps are unpacking fine
2026-01-14 19:20:03 <bl4ckb0ne> im trying to untar it manually, see if it helps
2026-01-14 19:20:13 <bl4ckb0ne> its a source for llvm, quite big
2026-01-14 19:21:07 <bl4ckb0ne> it works in rootbld but i need to check the build folder
2026-01-14 19:29:23 <bl4ckb0ne> seems like it worked!
2026-01-14 19:29:39 <ikke> Package epoxy was not found in the pkg-config search path.
2026-01-14 19:29:51 <ikke> for qt6-qtwebengine on loongarch
2026-01-14 19:31:15 <ikke> Why does it fail only on loongarch..
2026-01-14 19:33:04 <Ariadne> please don't blame pkgconf like macports already did today ^.^
2026-01-14 19:34:28 <ikke> heh, I'm not
2026-01-14 19:36:59 <ikke> bl4ckb0ne: not sure why it does not work with abuild then
2026-01-14 19:37:06 <craftyguy[m]> ikke oh no! well, I'm glad you identified it :) Thanks for the help!
2026-01-14 19:37:14 <ikke> craftyguy[m]: It's fixed now :)
2026-01-14 19:37:21 <bl4ckb0ne> no clue
2026-01-14 19:44:04 <ikke> hmm, the runner is still misbehaving. It's set to accept at most 4 concurrent jobs, but it's accepting a 5th one
2026-01-14 19:50:31 <ikke> oh, we're setting the wrong value
2026-01-14 19:52:43 <ncopa> I think it works now
2026-01-14 19:52:43 <ncopa> cycle: freerdp -> webkit2gtk-4.1 -> kwallet -> kconfig -> xwayland-run -> weston -> freerdp
2026-01-14 19:52:43 <ncopa> cycle: colord -> sane -> v4l-utils -> sdl2 -> libdecor -> gtk+3.0 -> gtk4.0 -> colord
2026-01-14 19:52:43 <ncopa> ncopa-desktop:~/aports/community (master)$ ap circular-aports
2026-01-14 20:16:36 <Ariadne> nice
2026-01-14 20:20:29 <lnl> Something's very wrong on loongarch64 because it errors from `#include <cstring>`
2026-01-14 20:20:38 <lnl> https://gitlab.alpinelinux.org/selfisekai/aports/-/jobs/2174281#L359
2026-01-14 20:21:50 <Ariadne> lnl: most likely this is actually a problem with simdutf's lasx intrinsics
2026-01-14 20:21:57 <Ariadne> i can look in a bit
2026-01-14 20:25:17 <ncopa> cycle: freerdp -> webkit2gtk-4.1 -> kwallet -> kconfig -> xwayland-run -> weston -> freerdp
2026-01-14 20:25:17 <ncopa> cycle: ghostscript -> gtk+3.0 -> gtk4.0 -> gst-plugins-bad -> zbar -> imagemagick -> ghostscript
2026-01-14 20:25:17 <ncopa> cycle: py3-jaraco.collections -> py3-jaraco.text -> py3-jaraco.context -> py3-jaraco.test -> py3-jaraco.collections
2026-01-14 20:25:47 <lnl> 
ACTION facepalms

2026-01-14 20:27:43 <Ariadne> lnl: ?
2026-01-14 20:34:42 <lnl> Not sure how did I misread it that bad
2026-01-14 20:35:12 <Ariadne> if i were to guess, i think memcpy() is being shadowed somehow
2026-01-14 20:35:33 <Ariadne> i have a loongson machine locally, i can dig into it after doing some work-related stuff (which will also benefit alpine)
2026-01-14 20:37:46 <ncopa> https://build.alpinelinux.org/buildlogs/build-edge-x86/community/ktextaddons/ktextaddons-1.9.0-r0.log looks like a real bug
2026-01-14 20:37:55 <ncopa> either in testsuite or in app
2026-01-14 21:14:12 <ikke> I think I fixed the runner picking up too many jobs. After the current jobs finished, I expect the runner to behave again
2026-01-14 21:21:20 <quinq> gg
2026-01-14 23:28:13 <Sertonix[m]> ncopa: I have already written a bootstrap path solver. So be aware that some stuff might be duplicated effort. The project it is included in is just not yet ready
2026-01-15 02:03:14 <qaqland> it shows rebase failed in !95745, but there are no conflicts in its "Changes" page
2026-01-15 02:04:17 <qaqland> does anyone know what happened?
2026-01-15 02:39:00 <jvvv> qaqland: i just looked at it, and i don't see what it's talking about either. i've run into similar issue before. i don't know any other way forward other than what it says about rebasing locally then push the branch again
2026-01-15 07:12:23 <ryanwiseman> Can someone review and merge this code if possible? I really would love to see JUCE approved for Alpine Edge: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95261
2026-01-15 07:35:39 <ncopa> I wonder if we should add support for a rundepends in APKBUILD
2026-01-15 07:35:58 <ncopa> this is excluded from the build time dependencies
2026-01-15 07:36:18 <ncopa> it can help us to avoid circular depends at build time
2026-01-15 07:36:50 <ncopa> cycle: freerdp -> webkit2gtk-4.1 -> kwallet -> kconfig -> xwayland-run -> weston -> freerdp
2026-01-15 07:37:16 <PureTryOut> Basically just depends but not installed on buildtime?
2026-01-15 07:37:22 <ncopa> exactly
2026-01-15 07:37:54 <PureTryOut> Makes sense to me, although I'd find it a bit confusing to have both rundepends and depends
2026-01-15 07:37:55 <ncopa> webkit2gtk-4.1 -> kwallet  is a bit weird but it comes from webkit2gtk-4.1 has a depends=dbus:org.freedesktop.Secrets
2026-01-15 07:38:03 <ncopa> and kwallet has a provides of it
2026-01-15 07:38:36 <PureTryOut> Makes sense, kwallet is a valid provider for it. Not sure if webkit2gtk needs to depend on it, but I suppose behaviour is broken without it
2026-01-15 07:38:51 <ncopa> and I don't think we need dbus:org.freedesktop.Secrets at buildtime
2026-01-15 07:39:00 <PureTryOut> Lol definitely not
2026-01-15 07:39:34 <quinq> Especially that kwallet is… KDE while webkitgtk is… GTK
2026-01-15 07:40:01 <PureTryOut> It's just a runtime thing, and there are GTK-based providers for that service as well. It's no issue
2026-01-15 07:40:02 <ncopa> the current build order resolver is not very clever when it comes to provides
2026-01-15 07:40:25 <ncopa> there is also gnome-keyring
2026-01-15 07:40:55 <ncopa> i suppose the "provides=" thingy makes it complicated for build order solver
2026-01-15 07:41:27 <ncopa> other option is that hide the dbus:* depends at build time. eg we add it in package() function
2026-01-15 07:41:43 <PureTryOut> Feels more like a workaround than a fix tbh
2026-01-15 07:41:49 <ncopa> package() { depends="$depends dbus:org.freedesktop.Secrets" 
2026-01-15 07:42:04 <quinq> How is having an unnecessary kde build dependency a no issue
2026-01-15 07:42:44 <ncopa> yeah, thats why I though that a rundepends would solve it while still be backwards compat
2026-01-15 07:43:00 <quinq> yeah
2026-01-15 08:00:03 <ikke> https://cryptography.io/en/latest/statements/state-of-openssl/
2026-01-15 09:25:03 <ncopa> interesting read. looks like openssl has lots of complicated solutions for problems that shouldn't be there in the first place
2026-01-15 10:01:55 <ikke> "They were so preoccupied with whether or not they could, they  didn't stop to think if they should"
2026-01-15 11:14:40 <lotheac> ever since libressl became a thing i've had those thoughts about openssl tbh
2026-01-15 11:25:49 <ikke> But libressl diverged too much from openssl to remain a viable general alternative
2026-01-15 11:27:56 <ikke> gitlab server seems to be unreachable
2026-01-15 11:36:10 <ncopa> Sertonix[m]: I am interested in your bootstrap path solver. would it be possible to have a look at it?
2026-01-15 11:48:38 <ncopa> on a second thought, I don't think rundepends will solve anything
2026-01-15 11:49:25 <ncopa> what we really need is a soft depends, which will install if a provider exists, but will not fail if it doesnt
2026-01-15 11:51:06 <ikke> Is that something that would be generally usable, or only in a very specific usecase?
2026-01-15 11:51:45 <ikke> A way to implement that is to have a dummer provider that does not depend on anything with a low priority
2026-01-15 11:51:50 <ikke> dummy
2026-01-15 11:52:08 <ikke> If the actual provider is available, that gets installed, otherwise it will fall back on the dummy provider
2026-01-15 11:52:30 <ncopa> hm
2026-01-15 11:52:53 <ncopa> that would work
2026-01-15 11:54:28 <ncopa> an example, the previous mentioned webkit2gtk-4.1, which depends on dbus:org.freedesktop.Secrets
2026-01-15 11:54:57 <ncopa> if there are no provider for that before webkit2gtk-4.1 is built, it will fail during installation
2026-01-15 11:55:48 <ncopa> so the webkit2gtk-4.1 package could have a subpackage with a dummy provider for that
2026-01-15 11:56:03 <ikke> Does that work?
2026-01-15 11:56:13 <ncopa> only with the rundepends hack
2026-01-15 11:56:39 <ikke> I mean, before webkit2gtk-4.1 is built, apk is not aware of that provider, is it?
2026-01-15 11:56:55 <ncopa> correct
2026-01-15 11:57:06 <ncopa> nor is the aports build order resolver
2026-01-15 11:57:13 <ikke> ack
2026-01-15 11:57:45 <ikke> So even a separate package would not help consistently, because the build order would be random
2026-01-15 11:57:47 <ncopa> what is worse, the build order resolver is not taking provider priority in consideration
2026-01-15 11:57:58 <ncopa> correct
2026-01-15 11:58:10 <ikke> But I don't think for this case the priority matters too much, does it?
2026-01-15 11:58:17 <ncopa> it doesnt
2026-01-15 11:59:01 <ncopa> but it would work if it provides a dummy provider as a subpackage, and we hide the dep from buildtime solver
2026-01-15 11:59:38 <ikke> Another question is: what does the dbus dependency give us versus what it costs
2026-01-15 12:00:06 <ikke> It's apparently not a hard requirement, otherwise you would not try to solve it like this
2026-01-15 12:00:18 <ncopa> i suspect it is no hard requirement
2026-01-15 12:00:42 <ncopa> i think it provides a secrets manager to store passwords
2026-01-15 12:00:54 <ikke> Yes
2026-01-15 12:00:57 <ncopa> i suppose it is not a hard requirement, but a nice-to-have thingy
2026-01-15 12:01:05 <ikke> Which is contacted via dbus
2026-01-15 12:01:10 <ncopa> so we should probably just drop it and call it a day
2026-01-15 12:01:46 <ncopa> while at it, I think we should rename it to webkit2gtk4.1 (drop the dash)
2026-01-15 12:04:55 <lotheac> ikke: right (re: libressl). it's unfortunate but the choice of tls library is more or less fixed to whatever the upstream developers of any given software chose
2026-01-15 12:05:22 <ikke> lotheac: but it's a choice to deviate from the API
2026-01-15 12:05:31 <lotheac> of course
2026-01-15 12:06:06 <lotheac> and it's annoying that the libraries share naming :)
2026-01-15 12:07:05 <ikke> We did for a while switch to libressl, but had to switch back
2026-01-15 12:07:18 <ikke> (as default tls provider)
2026-01-15 13:25:01 <ncopa> I am investigating https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/fungw/fungw-1.2.2-r0.log
2026-01-15 13:25:12 <ncopa> i was able to repro in my dev env
2026-01-15 13:25:20 <ncopa> and it is *weird*
2026-01-15 13:26:12 <ncopa> it turns out that the Bus error happens in /bin/sh
2026-01-15 13:26:32 <ncopa> but, /bin/sh is not ash
2026-01-15 13:26:35 <ncopa> its dash
2026-01-15 13:27:01 <ncopa> and when I try to delete it:
2026-01-15 13:27:03 <ncopa> doas (ncopa@ncopa-edge-armv7) password: 
2026-01-15 13:27:03 <ncopa> $ doas apk del dash
2026-01-15 13:27:03 <ncopa>   dash: alpine-base abuild lua-aports abuild-rootbld doas openssh-server
2026-01-15 13:27:03 <ncopa> World updated, but the following packages are not removed due to:
2026-01-15 13:28:59 <ikke> Sounds like an old bug / issue
2026-01-15 13:29:04 <ikke> where old is relative
2026-01-15 13:29:25 <ncopa> so, dash is buggy on armv7
2026-01-15 13:29:39 <ncopa> but I wonder why it uses dash-binsh
2026-01-15 13:29:39 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11142
2026-01-15 13:29:50 <ncopa> its needed for checkdepends
2026-01-15 13:30:15 <ikke> ncopa: celeste has mentioned it before why
2026-01-15 13:30:49 <ncopa> well, running apk upgrade -U -a solves it
2026-01-15 13:33:32 <ikke> https://tpaste.us/Lyl0 
2026-01-15 13:33:54 <ikke> apparently due to issues with busybox sh
2026-01-15 16:34:36 <Sertonix[m]> ncopa: I added you to a repo with the solver code
2026-01-15 16:34:50 <Sertonix[m]> (on codeberg and I hope the user name is right)
2026-01-15 17:39:02 <cely> Sertonix[m]: i'm also interested in the boostrap path solver. my codeberg user name is the same as gitlab.a.o
2026-01-15 17:41:22 <Sertonix[m]> Ok, but be aware that the code is a mess
2026-01-15 18:37:24 <PureTryOut> I still don't understand why https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95675 has kconfigwidgets building before kcodecs, the former depending on the latter. It's blocking that MR and it's starting to block more now 😢
2026-01-15 19:11:34 <ikke> PureTryOut: there is a cyclic dependency somewhere
2026-01-15 19:12:10 <ikke> https://tpaste.us/ZKvZ 
2026-01-15 19:17:20 <ikke> PureTryOut: the xwaylad-run checkdepends
2026-01-15 19:17:26 <ikke> ap recursive-deps xwayland-run |  grep kconfigwidgets
2026-01-15 19:23:01 <PureTryOut> How the hell does xwayland-run pull that in...?
2026-01-15 19:26:44 <ikke> weston-backend-headless
2026-01-15 19:27:01 <ikke> and weston-shell-desktop
2026-01-15 19:53:24 <PureTryOut> Huh
2026-01-15 19:54:45 <PureTryOut> I don't actually see how that's possible, they don't seem to depend on it?
2026-01-15 20:01:35 <ikke> ap recursive-deps freerdp-dev | grep kconfigwidgets
2026-01-15 20:01:37 <ikke> kconfigwidgets-dev
2026-01-15 20:01:39 <ikke> kconfigwidgets5-dev
2026-01-15 20:03:58 <ikke> xwayland-run -> weston -> freerdp -> ebkit2gtk-4.1
2026-01-15 20:04:07 <ikke> xwayland-run -> weston -> freerdp -> webkit2gtk-4.1
2026-01-15 20:04:59 <ikke> xwayland-run -> weston -> freerdp -> webkit2gtk-4.1 -> dbus:org.freedesktop.Secrets
2026-01-15 21:04:33 <PureTryOut> Oh that thing again 😅
2026-01-15 21:04:37 <PureTryOut> Ok how are we getting rid of that loop
2026-01-15 21:05:13 <PureTryOut> Although I do wonder why that suddenly comes up now and hasn't been a problem in previous versions, there were no relevant changes to KDE at least
2026-01-15 21:07:04 <PureTryOut> Also strange that it pulls in kwallet at all, because gnome-keyring provides the same thing with a higher provider_priority...
2026-01-16 00:07:03 <omni> maybe it would have been better to let the community/go upgrade finnish on most architectures befor upgrading also on 3.23
2026-01-16 00:09:14 <omni> or at least wait with 3.22 until both of those branches are done, since community/ in 3.22 is not expected to receive updates and the builds are competing for our limited resources
2026-01-16 00:11:27 <omni> and, as always, some way of keeping track of what actually needs to be rebuilt would be super-duper-nice
2026-01-16 00:12:35 <omni> where should such SBOMs be searchable?
2026-01-16 00:22:05 <omni> for many aports, the relevant information is in their build logs, but not all golang aports are built with go build -v
2026-01-16 00:38:18 <omni> and I was waiting for loongarch to complete the icu rebuilds...
2026-01-16 07:41:21 <lindsay> ikke, PureTryOut : Sorry, when I upgraded freerdp to ver 3, I forgot why webkit2gtk-4.1-dev was introduced in freerdp. It's only need when has WITH_WEBVIEW=ON flag, which is default OFF [1].
2026-01-16 07:41:21 <lindsay> [1] https://github.com/FreeRDP/FreeRDP/commit/2175428df590e45d84828347fb6ba7f015aef6ac
2026-01-16 07:41:21 <lindsay> I will try to remove unnecessary dependencies for freerdp later today
2026-01-16 07:58:55 <PureTryOut> Ah, thanks!
2026-01-16 08:00:14 <PureTryOut> Imo that in itself is not wrong though, I think it's just revealing a bug with providers. kwallet shouldn't have been pulled in as it's provider_priority is lower than gnome-keyring.
2026-01-16 08:17:51 <ikke> PureTryOut: Would be interesting to see what happens if you explicitly pull in gnome-keyring
2026-01-16 08:18:50 <ikke> The priority is not absolute, if something else causes kwallet to be pulled in, the provider_priority is ignored
2026-01-16 08:27:47 <ikke> To be more precise, provider_priority is one of the final (if not the final) tie-breaker
2026-01-16 09:47:37 <LuisLindet[m]> Get in touch with this platform for greatness you’ll definitely thank me later
ℹ️❤️
👇🏻👇🏻👇🏻
2026-01-16 09:47:37 <LuisLindet[m]> https://t.me/+pa-CiKYv9-5lNWM8
2026-01-16 10:41:11 <mlock> heyhey! could someone pls take a quick look at !94655? would be appreciated
2026-01-16 15:58:14 <PureTryOut> ncopa: could you have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95976?
2026-01-16 16:08:46 <ncopa> the CI is red due to the icu 78 rebuilds has not completed yet and and all builders are failing for different reasons
2026-01-16 16:19:10 <PureTryOut> I know, but if it looks ok to you otherwise and if I need to do something else 😉
2026-01-16 17:08:36 <ikke> PureTryOut: I'm not sure why yet, but if I leave out baloo in the builddirs command, kcodecs gets sorted before kconfigwidgets
2026-01-16 17:11:35 <ikke> compare `ap builddirs baloo kcodecs kconfigwidgets` versus `ap builddirs kcodecs kconfigwidgets`
2026-01-16 17:13:15 <ncopa> looks like there are lots of bugs in dash nowadays https://lore.kernel.org/dash/
2026-01-16 17:22:30 <PureTryOut> ikke: ok wtf, that makes no sense haha
2026-01-16 17:23:16 <ncopa> PureTryOut: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95976 LGTM
2026-01-16 17:23:25 <ncopa> I usually dont look at MRs until they are green
2026-01-16 17:24:31 <PureTryOut> Makes sense, but it's a bit annoying with the icu stuff atm 😅
2026-01-16 17:24:35 <PureTryOut> Thanks for looking at it!
2026-01-16 17:34:22 <ncopa> it is generally a bit annoying when builders fails, yes
2026-01-16 17:34:47 <ncopa> and when new failures are added faster than we manage to solve the old ones
2026-01-16 17:35:10 <ncopa> and faster than the builders manages to catch up on the builds
2026-01-16 17:35:31 <ncopa> whats wrong with etcd? https://build.alpinelinux.org/buildlogs/build-3-23-x86/community/etcd/etcd-3.6.4-r4.log
2026-01-16 17:40:38 <ikke> ncopa: go behavior where it makes GOMODCACHE directories ro
2026-01-16 17:41:05 <ncopa> what is the proper fix?
2026-01-16 17:41:15 <ikke> We provide -modcacherw via GOFLAGS, but some projects overwrite GOFLAGS
2026-01-16 17:41:22 <ikke> I manually cleaned up the tmp dir
2026-01-16 17:42:06 <ikke> ncopa: so the proper fix is making sure projects respect our GOFLAGS
2026-01-16 17:43:53 <ncopa> i wonder if it would make sense to point that to some tmpfs mount
2026-01-16 17:43:58 <ikke> ncopa: ah, etcd provide -mod=readonly
2026-01-16 17:43:59 <ncopa> so it goes away on reboot
2026-01-16 17:44:35 <ikke> ncopa: that could quickly fill up memory
2026-01-16 17:45:50 <ncopa> other option is to chmod -R +w before cleanup, but I'm not sure we want that either
2026-01-16 17:46:07 <ikke> ncopa: we have chmod-clean already as an option
2026-01-16 17:46:43 <ikke> This is something that is already a problem for a longer time, though not sure why it comes back now
2026-01-16 17:55:35 <ikke> ncopa: I've pushed a fix, although that's not going to fix the current issues
2026-01-16 17:59:31 <ikke> PureTryOut: next hint: Only after I remove both kbookmarks-dev and kcompletion-dev from makedepends of baloo, the order is as you expect
2026-01-16 18:02:50 <PureTryOut> This is getting weirder and weirder...
2026-01-16 18:08:37 <ikke> Hmm, even the order that baloo is listed affects the output (but theoretically that could be explained by a dependency cycle)
2026-01-16 18:35:07 <ncopa> $ ap circular-aports  baloo kcodecs kconfigwidgets
2026-01-16 18:35:07 <ncopa> cycle: ghostscript -> gtk+3.0 -> gtk4.0 -> gst-plugins-bad -> zbar -> imagemagick -> ghostscript
2026-01-16 18:35:07 <ncopa> cycle: freerdp -> webkit2gtk-4.1 -> kwallet -> kconfig -> xwayland-run -> weston -> freerdp
2026-01-16 18:36:32 <ncopa> i think those two are the reason
2026-01-16 18:37:43 <ikke> That first cycle we already discovered yesterday, indeed, but not sure how baloo is involved with that, (but could just happen to affect the order enough to cause the change
2026-01-16 18:38:56 <ncopa> those two cycles affect all 3: baloo kcodecs kconfigwidgets
2026-01-16 18:40:28 <ikke> So the freerdp MR should fix at least one of those then
2026-01-16 18:41:01 <ikke> !96002
2026-01-16 19:23:37 <ncopa> achill: I wonder if we should move back gtk-update-icon-cache to gtk3. It would solve cirular dep for ghostscript i think
2026-01-16 19:23:55 <achill> fine by me
2026-01-16 19:24:04 <achill> looks like we're gonna keep gtk3 around forever anyway
2026-01-16 19:25:35 <ncopa> we could also drop gtk support for ghostscript
2026-01-16 19:25:50 <achill> also fine by me
2026-01-16 19:25:52 <ncopa> but I think it may be nice to have gtk loader for postscript
2026-01-16 19:26:08 <ncopa> not sure if glycin supports that yet
2026-01-16 19:28:59 <ncopa> why does gtk4 need gstreamer and gst-plugins-bad?
2026-01-16 19:35:13 <ncopa> I think the simplest thing is to switch back to gtk3 gtk-update-icon-cache
2026-01-16 19:35:46 <ncopa> alternatively we can build it in separate APKBUILD
2026-01-16 19:37:36 <ncopa> i also wonder how hard we should enforce avoid circular deps
2026-01-16 19:38:07 <ncopa> im thinking we should make make it hard fail in CI
2026-01-16 19:38:46 <ncopa> and maybe not even try build if there are circular deps
2026-01-16 20:18:18 <ncopa> sigh there are more bugs in dash
2026-01-16 20:18:42 <ikke> Interesting
2026-01-16 20:18:46 <ncopa> those could been easily caught with a test suite
2026-01-16 20:18:56 <ikke> Isn't that the shell that debian uses for /bin/sh?
2026-01-16 20:19:05 <ncopa> i think it is
2026-01-16 20:19:46 <ncopa> I suppose they dont use 0.5.13
2026-01-16 20:20:55 <ikke> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Apatch&exclude=tags%3Apending&pend-exc=done&repeatmerged=no&src=dash
2026-01-17 09:19:03 <wen> help! would some committer merge this MR ?
2026-01-17 09:19:06 <wen> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95323
2026-01-17 09:20:01 <wen> It is required by the update of perl-dancer2
2026-01-17 09:20:15 <wen> Thanks at advance !
2026-01-17 14:39:37 <haesbaert> heya, can I have eyes on: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95982 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96014. These fixes touchpad and bluetooth on lunar lake laptops that are becoming more common.
2026-01-17 17:13:13 <realroot[m]> WhyNotHugo is rocm stalled?
2026-01-17 17:31:04 <craftyguy[m]> hmm libreoffice-common is broken because it depends on the old libgpgmepp
2026-01-17 21:38:37 <WhyNotHugo> craftyguy[m]: ditto notmuch, but I noticed a large queue on the builders at th etime.
2026-01-17 22:01:23 <WhyNotHugo> realroot[m]: yeah