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
2026-01-18 15:52:22 <realroot[m]> WhyNotHugo can I try to help with some package/s maybe?
2026-01-18 16:33:17 <jahway603[m]> Can I please have !95884 and !95886 merged?
2026-01-18 19:19:12 <Kladky> hey, I no longer use Alpine on my laptop, yet I still want to keep my aports up to date, so I tried using distrobox to build packages, but I get the following error:
2026-01-18 19:19:15 <Kladky> >>> wild: Entering fakeroot... grep: error while loading shared libraries: libc.musl-x86_64.so.1: cannot open shared object file: No such file or directory >>> ERROR: wild*: No such function set_source_date >>> ERROR: wild: rootpkg failed
2026-01-18 19:23:40 <ikke> set_source_date is defined in abuild itself, sounds like something strange is happening in that environment
2026-01-18 19:25:48 <Kladky> i'll double check this later, but I'm pretty sure the issue persists even when using abuild-rootbld.
2026-01-18 19:28:12 <Kladky> Do you think this is more likely a Distrobox issue?
2026-01-18 19:28:48 <ikke> error while loading shared libraries: libc.musl-x86_64.so.1 seems like something is pretty broken, so I guess?
2026-01-18 19:29:34 <Sertonix[m]> Maybe distrobox tries to do something similar to fakeroot which causes conflicts?
2026-01-18 19:35:29 <abby> distrobox is a wrapper around docker/podman/etc
2026-01-18 20:13:22 <Kladky> Wait nevermind, it doesn't happen with abuild rootbld
2026-01-18 20:13:27 <Kladky> just abuild -r
2026-01-18 20:13:34 <Kladky> Anyways, I'll report this to distrobox
2026-01-18 20:32:07 <Kladky> https://github.com/89luca89/distrobox/issues/1978, if anyone's interested
2026-01-18 21:22:17 <WhyNotHugo> realroot[m]: feel free!
2026-01-18 23:06:19 <andypost[m]> any idea what's wrong with armhf builder for edge?
2026-01-19 01:03:39 <Sertonix[m]> It seems stuck
2026-01-19 01:09:55 <ds> I'm trying to fix a broken package in testing, getting this warning. Did I miss a setup step somewhere?
2026-01-19 01:10:00 <ds> `WARNING: opening /home/alpine/packages//main/aarch64/APKINDEX.tar.gz: No such file or directory`
2026-01-19 01:10:25 <ds> running on a freshly upgrade alpine edge install, if that matters
2026-01-19 01:19:02 <Sertonix[m]> It looks like you compiled your own packages at some point and have deleted the repo since then
2026-01-19 01:19:57 <Sertonix[m]> Or do you get that while building a package?
2026-01-19 01:36:18 <ds> I get that when running abuild, yeah
2026-01-19 01:46:30 <ds> And another question, policy: when is it preferable to use a Python package's github release tarball vs github tag tarball vs pypi source tarball? 
2026-01-19 01:49:22 <JustSouptheyhe[m]> Usually the github tag tarball, but if the project preps the release tarballs specially, then sometimes the tarball. If in doubt, use the tag.
2026-01-19 01:55:10 <omni> I made a `apk -aU upgrade` and some -doc and -completion packages got purged and I don't get why
2026-01-19 01:55:22 <omni> they're available and can be manually installed
2026-01-19 01:57:12 <ds> justsouptheyhe: In this case (barman), the project doesn't include tests with the release tarball
2026-01-19 01:57:23 <ds> They added a hard dependency on distutils (py3-setuptools) at some point, wondering if there's a way this could've been caught during packaging instead of abuild -r then running barman
2026-01-19 01:59:32 <omni> oh, wow, maybe it's due to some conflicts, I tried removing buildah to then add it again...
2026-01-19 02:02:54 <omni> so how many gpgme rebuilds are we missing
2026-01-19 02:05:58 <achill> less and less
2026-01-19 02:06:00 <achill> but still a lot
2026-01-19 02:06:02 <achill> e.g. libreoffice
2026-01-19 02:09:52 <omni> and appimagetool and gmime and gpg-tui and gpgmepp and libjcat and opkg-libs and podman and podman-tui and skopeo
2026-01-19 02:10:26 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/2175804#L1066
2026-01-19 02:10:52 <omni> apk list --depends so:libgpgme.so.11
2026-01-19 02:11:39 <omni> CI pipelines are not just there to show a green check mark or a red X
2026-01-19 02:11:43 <omni> ffs
2026-01-19 02:12:29 <omni> edge used to be fairly stable, I don't know what the fuck is going on
2026-01-19 02:14:05 <achill> that doesnt help :) i mean running the hard-erroring the buildrepo consistency checker would certainly solve that i guess (with the implementation of cross repo deps)
2026-01-19 02:32:59 <omni> more diligence would help
2026-01-19 02:59:51 <lotheac> incidentally i just now read https://utcc.utoronto.ca/~cks/space/blog/tech/PeopleCannotPayAttention which seems relevant to this
2026-01-19 05:24:23 <SandeepGupta__> IBM
2026-01-19 07:28:49 <anjan> can someone please merge: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95176
2026-01-19 07:36:04 <ikke> Done
2026-01-19 09:08:42 <daydub[m]> Get in touch with this platform for greatness you’ll definitely thank me later
ℹ️❤️
👇🏻👇🏻👇🏻
2026-01-19 09:08:42 <daydub[m]> https://t.me/+pa-CiKYv9-5lNWM8
2026-01-19 09:49:05 <Sertonix[m]> ds: In that case the warning is harmless
2026-01-19 09:51:04 <Sertonix[m]> omni: When packages are installed by install_if and not available in the repo anymore they are removed. Mainly happens when rebuilds are not complete
2026-01-19 10:10:02 <omni> I didn't properly get the connection with that and conflicts before, now I know that I need to look into missing rebuilds when I see it (and the builders are idle)
2026-01-19 12:34:03 <realroot[m]> WhyNotHugo: can you tell me what package should I try maybe?
2026-01-19 13:19:16 <WhyNotHugo> realroot[m]: See 88906, it has a list of packages which are done, packages which are broken, and packages which are missing. I beleive they're in the order in which they need to be addressed.
2026-01-19 13:41:34 <jvoisin> https://wiki.alpinelinux.org/wiki/How_to_setup_a_Alpine_Linux_mirror it would be nice to update this page, given the latest blogpost
2026-01-19 13:42:46 <ikke> jvoisin: anything spcific?
2026-01-19 13:44:20 <jvoisin> the size required/expected from a mirror
2026-01-19 13:44:43 <ikke> Ack
2026-01-19 13:44:45 <jvoisin> (and removing unsupported versions from the stats)
2026-01-19 13:45:13 <jvoisin> (as Alpine 3.0 was released in 2014, and had its support end 10 years ago in 2016)
2026-01-19 13:47:36 <ikke> They are still mirrored, so they still take up space 
2026-01-19 13:49:31 <jvoisin> why :<
2026-01-19 14:00:00 <achill> https://linuxiac.com/alpine-linux-turns-last-year-hosting-trouble-into-long-term-stability/
2026-01-19 14:10:19 <ncopa> they picked up what was just posted on https://alpinelinux.org/posts/2026-01-18-new-sponsors-strenghten-infrastructure.html
2026-01-19 14:24:12 <achill> yeah im just usually posting news articles here so people know how the "media" picks our posts up
2026-01-19 14:25:17 <achill> in german we call that pressespiegel, dont know if thats even a thing in english
2026-01-19 14:28:18 <ncopa> 👍
2026-01-19 14:45:07 <lotheac> there's a few typos/adjustments i'd like to suggest on that post. i forgot, are those in a gitlab repo?
2026-01-19 14:53:48 <ikke> infra/alpine-mksite
2026-01-19 14:54:07 <lotheac> thanks!
2026-01-19 15:10:40 <lotheac> ikke: some of it may be a bit subjective, but i made an MR anyway
2026-01-19 15:12:09 <lotheac> feel free to take any of it or none (:
2026-01-19 15:16:02 <quinq> achill, translator says “press review”
2026-01-19 15:16:26 <quinq> I believe that's kind of a universal concept in journalism/news :)
2026-01-19 15:17:59 <achill> I guess so yeah
2026-01-19 15:19:38 <achill> lotheac: I think in General your changes look fine
2026-01-19 15:20:26 <lotheac> thanks
2026-01-19 16:01:53 <elagost_> would someone be able to look at !95290 ? It's cleaned up enough to merge and failing CI is just due to library lag on slower builders.
2026-01-19 16:11:46 <lotheac> elagost: as a committer i don't want to take the risk that the MR actually breaks things on builders, so i don't merge MRs that failed CI
2026-01-19 16:11:57 <lotheac> (because then i have to fix them)
2026-01-19 16:15:10 <elagost> lotheac: fair enough. It was fine before I rebased it, but no rush I guess. 
2026-01-19 16:16:08 <lotheac> your patience is appreciated :)
2026-01-19 16:16:24 <elagost> o7
2026-01-19 16:40:00 <knuxify|m> could someone take a look at !93171 and !82911? they've been stalled for a while but should be ready
2026-01-19 17:04:41 <elagost> lotheac: removed make -e without issue on that MR. Thanks!
2026-01-19 18:34:06 <PureTryOut> ikke: Idk what changed but now `ap builddirs baloo kcodecs kconfigwidgets` gives me the right build order. Any clue what happened?
2026-01-19 19:09:02 <ikke> PureTryOut: no, not really sure, but you have to remember that, with cyclic dependencies, the build order is undefined, so any change in dependecies can change the order
2026-01-19 19:10:08 <ikke> I still have the test container with the old behavior
2026-01-19 19:13:31 <PureTryOut> Hmm, it's hard to find these cyclic dependencies
2026-01-19 19:15:18 <ikke> ncopa mentioned 2 cycles
2026-01-19 19:15:31 <ikke> cycle: freerdp -> webkit2gtk-4.1 -> kwallet -> kconfig -> xwayland-run -> weston -> freerdp
2026-01-19 19:15:33 <ikke> cycle: ghostscript -> gtk+3.0 -> gtk4.0 -> gst-plugins-bad -> zbar -> imagemagick -> ghostscript
2026-01-19 19:17:33 <PureTryOut> but the dbus:org.freedesktop.Secrets dependency on webkit2gtk that's pulling in kwallet has been there since 2022. I don't see why it suddenly behaves different
2026-01-19 19:29:33 <ikke> We'd need to find what tries to pull in kwallet instead of gnome-keyring
2026-01-19 19:29:38 <ikke> Some hidden dependency
2026-01-19 20:19:45 <realroot[m]> does alpine have something like mrtest maybe?
2026-01-19 20:20:03 <realroot[m]> to install alpine MRs
2026-01-19 20:20:28 <ikke> realroot[m]: mrtest also claims to work for alpine
2026-01-19 20:21:50 <JustSouptheyhe[m]> @realroot:nadeko.net mrtest [add/upgrade] -a uses aports instead of pmaports.
2026-01-19 20:22:23 <realroot[m]> i see thanks
2026-01-19 20:26:57 <ncopa> I think freerdp was fixed
2026-01-19 20:29:00 <PureTryOut> yeah webkit2gtk has been removed from it it seems
2026-01-19 20:29:27 <ikke> !96002
2026-01-19 20:30:10 <ikke> !96002
2026-01-19 20:30:41 <ncopa> 52ce616eb022954f4e88af09db609dbf1a2615f0
2026-01-19 20:31:15 <ncopa> we currently have those:
2026-01-19 20:31:18 <ncopa> cycle: ghostscript -> gtk+3.0 -> gtk4.0 -> gst-plugins-bad -> zbar -> imagemagick -> ghostscript
2026-01-19 20:31:18 <ncopa> cycle: py3-jaraco.collections -> py3-jaraco.text -> py3-jaraco.context -> py3-jaraco.test -> py3-jaraco.collections
2026-01-19 20:40:04 <iodomi[m]1> Does lint fail matter?
2026-01-19 20:42:03 <ikke> iodomi[m]1: It depends on why it fails
2026-01-19 20:46:15 <iodomi[m]1> I'm not sure could you take a look?
2026-01-19 20:46:16 <iodomi[m]1> https://gitlab.alpinelinux.org/iodomi/aports/-/jobs/2181153
2026-01-19 20:46:37 <achill> then just remove the builddir= line?
2026-01-19 20:47:31 <iodomi[m]1> oh right I missed it
2026-01-19 20:47:33 <iodomi[m]1> thank you
2026-01-19 20:55:05 <realroot[m]> `Remote server does not have any packages to download for MR 88906!`
2026-01-19 20:55:05 <realroot[m]> `Please trigger again the MR 88906 to generate the packages.`
2026-01-19 20:55:05 <realroot[m]> Would that be possible?
2026-01-19 20:55:38 <ikke> realroot[m]: What MR?
2026-01-19 20:55:55 <realroot[m]> !88906
2026-01-19 21:00:59 <realroot[m]> maybe cause is a draft https://paste.trom.tf/ivokiqisok.yaml
2026-01-19 21:01:52 <ikke> No, last pipeline is 4 months ago, so all artifacts have already expired
2026-01-19 21:06:53 <realroot[m]> could someone trigger it again?
2026-01-19 21:07:02 <ikke> I've just rebased it
2026-01-19 21:07:13 <ikke> You need to wait for the job for the relevant arch to finish
2026-01-19 21:30:49 <ncopa> getting the riscv64 builders complete is a high priority now, so the CI jobs can get green even if package has icu in dependency chain
2026-01-19 21:35:29 <ikke> ack
2026-01-20 01:09:19 <Saijin_Naib[m]> iodomi thanks for stewarding Pinta!
2026-01-20 01:09:32 <Saijin_Naib[m]> Can someone give a look over https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95272
2026-01-20 08:11:43 <realroot[m]> x86_64 failed https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/397639
2026-01-20 08:46:31 <iodomi[m]1> <Saijin_Naib[m]> "iodomi thanks for stewarding..." <- No problem :)
2026-01-20 16:40:39 <bl4ckb0ne> is `replaces` the right way to add a conflict between two versions of the same package?
2026-01-20 16:43:17 <ikke> 2 versions of the same package already conflict by definition
2026-01-20 16:43:27 <ikke> and no, replaces is not a way to declare conflicts
2026-01-20 16:43:37 <bl4ckb0ne> they have a different name, packaging different versions
2026-01-20 16:43:46 <bl4ckb0ne> so they install the same files
2026-01-20 16:43:59 <ikke> bl4ckb0ne: then I would add a provides of the old package
2026-01-20 16:44:08 <bl4ckb0ne> gotcha
2026-01-20 16:44:16 <ikke> provides="old-pkg-name=$pkgver-r$pkgrel"
2026-01-20 16:45:19 <bl4ckb0ne> so thats `provides="intel-compute-runtime-legacy=intel-compute-runtime-r$pkgrel` in intel-compute-runtime-legacy ?
2026-01-20 16:45:46 <bl4ckb0ne> oh no i got it wrong
2026-01-20 16:46:11 <bl4ckb0ne> `provides="intel-compute-runtime=$pkgver-r$pkgrel"`
2026-01-20 16:46:21 <ikke> ack
2026-01-20 16:47:14 <bl4ckb0ne> ty
2026-01-20 21:38:55 <s10gopal> ikke: Thanks for the earlier review. I’ve made the requested changes. Could you please take another look when you have time? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/95996
2026-01-21 06:50:15 <Ermine> !96053 -- seems like py3-truststore didn't propagate to riscv64 builder
2026-01-21 06:59:26 <ikke> Ermine: the builder is still ~300 packages behind
2026-01-21 07:04:55 <Ermine> oh geez
2026-01-21 08:20:28 <ikke> Sadly the HW+kernel we have atm is not really stable
2026-01-21 10:34:02 <qaqland> !95130 fails on riscv
2026-01-21 10:36:27 <qaqland> so:libicui18n.so.76 (no such package), it is required by: qt6-qtbase
2026-01-21 11:17:56 <ikke> qaqland: same reply as to Ermine, the builder is still catching up
2026-01-21 11:22:19 <ikke> lnl: ftr, we have some new ci servers for x86_64 with more resources, so hopefully chromium builds properly on there (I noticed that server picked it up now)
2026-01-21 11:24:34 <lnl> Yeah the edge MR already just passed it today
2026-01-21 11:26:03 <ikke> ool
2026-01-21 11:26:05 <ikke> cool*
2026-01-21 11:29:45 <ncopa> Awesome!
2026-01-21 11:31:00 <ncopa> We need to have the stable builder idle Tuesday morning so we can tag releases.  
2026-01-21 11:31:08 <ncopa> https://marc.info/?l=openssl-users&m=176892398005379&w=2
2026-01-21 11:31:10 <ikke> right
2026-01-21 11:31:35 <ikke> I can schedule a banner on gitlab
2026-01-21 11:32:10 <ncopa> 👍
2026-01-21 11:35:01 <ikke> done
2026-01-21 11:35:12 <ikke> It should appear on monday
2026-01-21 12:44:25 <qaqland> :D
2026-01-21 13:35:21 <s10gopal> seeking guidance on migrating krane package from the testing repo to the community repo. The package installs and works as intended. A testing screenshot is attached to the MR. Please advise on next steps. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96204
2026-01-21 13:36:06 <telmich> Good day everyone
2026-01-21 13:36:45 <telmich> A heads up: I'm in exchange with the bird developers and maybe they are interested in maintaining the bird, bird2 packages in Alpine directly...which would be really cool having upstream involved
2026-01-21 13:47:04 <s10gopal> !96204
2026-01-22 01:48:49 <Eighth_Doctor> achill, ncopa: hi from the dracut project! we got a PR about handling alpine kernels with dracut (https://github.com/dracut-ng/dracut-ng/pull/2068) and I wound up being a bit concerned because we don't have a precise way to pick up the correct vmlinux/vmlinuz file. Would you be opposed to adding some kind of exact versioned path in your kernel packaging that we can reliably pick up on? most distributions have a copy as
2026-01-22 01:48:49 <Eighth_Doctor> `/lib/modules/$(uname -r)/vmlinux` (or `vmlinuz` as appropriate)... would you consider adding this so we can pick it up safely?
2026-01-22 01:50:35 <achill> i think in general i'm not opposed to the idea
2026-01-22 01:51:16 <achill> we also have the way too old issue about installing kernels side-by-side: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12157
2026-01-22 01:51:36 <achill> but with no actionable solution in sight
2026-01-22 01:52:52 <Eighth_Doctor> the approach used in fedora probably doesn't work fully for your case, I guess? we install all the files into the versioned modules path in /usr and copy the files to /boot as namespaced files
2026-01-22 01:53:11 <Eighth_Doctor> it works in fedora because we have a kernel install hook that generates the bootloader config snippet at the same time
2026-01-22 01:53:30 <achill> in the end, that would probably result to it, but nobody is working on it
2026-01-22 01:54:29 <Eighth_Doctor> I'm not terribly familiar anymore with how this stuff works without the kernel-install machinery, do you guys have an equivalent?
2026-01-22 01:54:34 <Eighth_Doctor> or is it just direct installed files?
2026-01-22 01:54:54 <achill> the package manager currently writes to /boot directly
2026-01-22 01:55:39 <achill> the installkernel script is https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/installkernel/installkernel
2026-01-22 01:56:19 <Eighth_Doctor> so at least the trivial case I'm asking for seems to be fixable, extending that script to copy vmlinux/vmlinuz would be easy enough
2026-01-22 01:56:25 <Eighth_Doctor> but yeah, the broader problem is much tougher
2026-01-22 02:03:15 <Eighth_Doctor> achill: would it help if I create an issue to ask for my specific case?
2026-01-22 02:05:45 <achill> that would make sense yeah
2026-01-22 02:06:12 <Eighth_Doctor> alright, let me do that now
2026-01-22 02:06:31 <achill> thanks
2026-01-22 02:07:01 <Eighth_Doctor> oof, uhh should I do it as a task or an issue?
2026-01-22 02:11:26 <achill> doesn't matter I thinks
2026-01-22 02:11:55 <achill> I guess issue is the right thing for this one in case I guessed correctly
2026-01-22 02:17:41 <Eighth_Doctor> ok
2026-01-22 02:23:26 <lotheac> this is the first time i've heard of a distribution having a copy of the kernel image in /lib/modules :thinking: certainly does not seem to be the case on ubuntu
2026-01-22 02:23:35 <lotheac> Eighth_Doctor: so which distro(s) do that?
2026-01-22 02:24:59 <Eighth_Doctor> Fedora, Arch, and openSUSE all do
2026-01-22 02:25:16 <lotheac> thanks
2026-01-22 02:25:21 <Eighth_Doctor> Debian and Ubuntu install versioned files in /boot instead, it seems
2026-01-22 02:25:46 <Eighth_Doctor> though I suspect this might change as they move from initramfs-tools to dracut in Debian 14
2026-01-22 02:26:28 <Eighth_Doctor> from the dracut point of view, either way works, as we can pick up vmlinux-$kver or /lib/modules/$kver/vmlinux
2026-01-22 02:33:58 <Eighth_Doctor> achill, ncopa: filed https://gitlab.alpinelinux.org/alpine/aports/-/issues/17907
2026-01-22 02:34:54 <Eighth_Doctor> thanks folks :)
2026-01-22 02:35:21 <lotheac> the /lib/modules seems reasonable enough... the alternatives don't seem great to me. /boot can be space-constrained and it may not support symlinks (eg. if it's ESP) - and it would in general be a big change to add version numbering to the kernel images. i personally rely on it as a feature on some systems that the bootloader always loads the same kernel filename
2026-01-22 02:35:58 <Eighth_Doctor> yeah
2026-01-22 02:36:02 <lotheac> and adding a /lib/modules/lts -> $(uname -r) link just seems a bit dangerous in the case where you've updated your kernel package but not rebooted yet
2026-01-22 02:36:27 <Eighth_Doctor> that's what I figured as well
2026-01-22 02:36:56 <Eighth_Doctor> (though I personally think using the ESP for boot is probably a bad idea, if you support it, you have the constraint of no symlinks allowed)
2026-01-22 02:38:13 <lotheac> i don't think we "officially" support or endorse any way of booting, but IME it's important to allow flexibility
2026-01-22 02:38:24 <lotheac> some architectures can be very different than others too
2026-01-22 02:38:35 <Eighth_Doctor> yeah sadly I'm way too aware of this
2026-01-22 02:39:05 <lotheac> personally i use zfs rootfs and that mostly means i have to have /boot as something that a simpler early bootloader can read
2026-01-22 02:39:20 <lotheac> EFI firmware can even do that
2026-01-22 02:39:25 <lotheac> for vfat
2026-01-22 02:44:26 <lotheac> Eighth_Doctor: why the カタカナ in your display name? :)
2026-01-22 02:45:30 <Eighth_Doctor> lol it's an old habit
2026-01-22 02:47:01 <lotheac> next time you're in tokyo let's go get a beer and you can tell me about it ;)
2026-01-22 02:58:32 <Eighth_Doctor> lotheac: I so badly want to go to Tokyo some day
2026-01-22 02:58:38 <Eighth_Doctor> never have been and really want to
2026-01-22 03:14:31 <lotheac> sounds like a plan then :)
2026-01-22 12:24:10 <ikke> 194 packages to go for riscv64
2026-01-22 12:27:44 <realroot[m]> ikke can you make x86_64 build succeed maybe? https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/397639pipelines
2026-01-22 13:13:50 <ikke> realroot[m]: it has passed now
2026-01-22 16:05:06 <realroot[m]> Which packages to install? 0 of 0 selected.
2026-01-22 16:12:25 <jvoisin> dumb question, but is there a way to make the zlib-ng package replace zlib? like a `provides` field?
2026-01-22 16:13:04 <ikke> jvoisin: it would need to provide the same soname as zlib
2026-01-22 16:21:35 <ikke> right now it provides so:libz-ng.so.2
2026-01-22 16:21:49 <achill> afaik it can probide a compat lib or so
2026-01-22 16:22:38 <achill> ah yes -DZLIB_COMPAT=ON
2026-01-22 16:23:02 <achill> i think packaging with that option side-by-side with libz-ng.so.2 would make sense
2026-01-22 16:26:58 <jvoisin> https://www.gentoo.org/news/2026/01/05/new-year.html → We have introduced initial support for using zlib-ng and minizip-ng in compatibility mode in place of the reference zlib libraries.
2026-01-22 18:54:06 <Saijin_Naib[m]> Ooh, that would be sweet
2026-01-22 20:51:14 <jvoisin> achill: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79637/
2026-01-23 05:39:44 <qaqland> runxiyu: welcome ^^
2026-01-23 05:39:50 <runxiyu> thanks!
2026-01-23 06:44:26 <runxiyu> https://gitlab.alpinelinux.org/runxiyu/aports/-/jobs/2186865/raw
2026-01-23 06:44:26 <runxiyu> wget: can't connect to remote host (209.51.188.20): Operation timed out
2026-01-23 06:44:34 <runxiyu> (it's https://ftp.gnu.org/gnu/make/make-4.4.1.tar.gz)
2026-01-23 06:44:50 <runxiyu> guess ill just re-run the build?
2026-01-23 06:47:41 <ikke> Yes, I'd try that first
2026-01-23 06:48:53 <ikke> Seems like it's unavailable from that CI host for some reason
2026-01-23 07:34:26 <runxiyu> alr
2026-01-23 07:34:32 <runxiyu> well, nvm for this instance in particular since merged
2026-01-23 10:22:02 <dne> would someone like to merge !95700?
2026-01-23 10:58:55 <omni> dne: would you like to ask them if you could take over maintainership? I think they won't take too long to respond to an email
2026-01-23 11:00:08 <dne> omni: yup, can try
2026-01-23 11:03:58 <achill> z
2026-01-23 11:06:17 <achill> funny enough their email server bounces back so they only get notification if they actively look in gitlab
2026-01-23 11:06:53 <omni> dne: you may need to use an email client
2026-01-23 11:07:24 <dne> hah ok
2026-01-23 11:17:30 <dne> done, and it didn't bounce right away at least
2026-01-23 11:23:40 <omni> 👍
2026-01-23 11:25:34 <achill> oh okay maybe its fixed then
2026-01-23 11:49:40 <achill> i think we should move more package to maintainer-groups, i think that can reduce burnout and major changes when someone leaves the project.
2026-01-23 11:49:41 <achill> i'm already doing this for alpine-desktop/gnome things, but we have so many more groups like toolchain and stuff
2026-01-23 11:50:24 <achill> we should really try to use these groups more
2026-01-23 11:50:50 <achill> i mean the tsc already decided on it, but as with many things just the implementation is missing
2026-01-23 11:54:14 <achill> anyway, here is a list of unmaintained packages for people to grab through: https://gitlab.alpinelinux.org/fossdd/nvchecker-aports/-/blob/main/UNMAINTAINED.md
2026-01-23 11:54:50 <achill> i wanted to do a list of maintainers of packages depending on unmaintained packages, but now i have to go to the mensa, maybe afterwards
2026-01-23 11:55:22 <omni> or https://pkgs.alpinelinux.org/packages?name=&maintainer=None
2026-01-23 11:55:25 <ikke> Most groups just end up having a single person responsible for it though
2026-01-23 11:55:43 <omni> yes
2026-01-23 11:55:45 <achill> ikke: but it allows easier adding of people
2026-01-23 11:56:02 <achill> which i think is very important to onboard new folks interested in e.g. desktop stuff
2026-01-23 11:57:22 <achill> and i can be sure that there are multiple people behind it, even if not actively maintaining it, but they could
2026-01-23 11:59:12 <Sertonix[m]> It does still require privilidged action. It would be nice to sign up for changes/MRs/Antija for a list of packages without extra permissions
2026-01-23 12:00:05 <achill> thats a nice idea actually, never thought of that
2026-01-23 12:00:18 <achill> like "subscribing" to package changes
2026-01-23 12:01:45 <achill> also another thing that is in my mind: co-maintainers, for less packages where a group is too much overhead, but it still makes sense to be maintained by multiple people if they want to
2026-01-23 12:02:09 <Sertonix[m]> security.a.o could also be included.
2026-01-23 12:02:18 <achill> right
2026-01-23 12:03:09 <Sertonix[m]> My hope is to have something generic enough that makes stuff like co-maintainers redundant.
2026-01-23 12:04:15 <achill> woah, i'm not sure, co-maintainers can also be a step in between, but i'm don't khow to generalize maintainership of packages with it
2026-01-23 12:04:19 <Sertonix[m]> I would just be uncertain on how one could set something like that up without making it very easy to DOS the infra
2026-01-23 12:05:37 <achill> i think the maintainer lines are already a great way to define the person(s) who care about a package
2026-01-23 12:05:56 <achill> and how are actively involved in updating ig
2026-01-23 12:05:58 <achill> *it
2026-01-23 12:06:33 <Sertonix[m]> achill: idea being to have maintainer be the point of contact (be it a mailing list or whatever) and then the only use-case left for co-maintainers should be notifications which could be handled in a way which helps a lot of other use cases
2026-01-23 12:07:07 <Sertonix[m]> (note that I don't imply that maintainer is a (single) person)
2026-01-23 12:10:01 <Sertonix[m]> Hm, I forgot the ACK use-case of co-maintainers
2026-01-23 12:11:07 <achill> hmm thats interesting, my hunch tells me that a definite list upstream (also who have a final say?) of packagers still is important but maybe i just have to sleep over it and give it some thought
2026-01-23 13:41:39 <dne> omni: they've replied to the MR (and my email)
2026-01-23 16:41:34 <achill> jvvv: you can just do a single "take over maintainership"-MR, that makes it much easier
2026-01-23 16:46:25 <jvvv> achill: oh, wish i'd thought of that... i can close the open ones and consolidate them in one MR if you would prefer
2026-01-23 16:53:45 <Saijin_Naib[m]> @achill an xfce group would be nice. I want to help maintain it as much as possible and expand our XFCE ecosystem, but I need assistance a lot. 
2026-01-23 16:54:55 <achill> yeah indeed, i would also join a xfce group since i sometimes upgrade the whole xfce suite wtihout even being a maintainer
2026-01-23 16:55:11 <achill> mind opening a MR at https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf?
2026-01-23 16:58:51 <Saijin_Naib[m]> Will do later tonight. Do we have meta groups, it seems? Like desktop metagroup that contains gnome/kde/lxqt/xfce/et al?
2026-01-23 16:59:01 <ikke> No nested groups
2026-01-23 17:02:11 <achill> also don't think thats necessary, or whats the usecase for that?
2026-01-23 17:02:31 <achill> currently all groups are on the same level
2026-01-23 17:05:32 <ikke> It doesn't make sense to ping every wm specific team by pinging the desktop team for example
2026-01-23 17:05:33 <Saijin_Naib[m]> @achill I'll grab dissent, mp3gain, mugshot, Pinta if it isnt grabbed already, thunar-media-tags-plugin, thonny, tdp, xfce4-weather-plugin, 
2026-01-23 17:06:36 <Saijin_Naib[m]> Makes sense. I was thinking for coordinating for major changes that may affect both (like QT changes affecting KDE and LXQT), syncing up rebuilds and library upgrades, etc
2026-01-23 17:07:01 <Saijin_Naib[m]> But I likely dont understand the problemspace well enough
2026-01-23 19:45:29 <jvvv> i'm  running into a problem with CI failing trying to download. only happening with armhf, armv7 and loongarch64. MR !96373
2026-01-23 19:46:36 <jvvv> it's weird, because the source is always for texinfo from https://ftp.gnu.org
2026-01-23 19:47:33 <ikke> jvvv: Only explenation I have is that some of our hosts are blocked
2026-01-23 19:47:43 <ikke> jvvv: not aarch64?
2026-01-23 19:48:00 <jvvv> no, that arch worked fine
2026-01-23 19:48:03 <ikke> huh
2026-01-23 19:48:06 <ikke> that's strange
2026-01-23 19:48:19 <ikke> aarch64, armv7 and armhf share the same host / ip address
2026-01-23 19:49:06 <jvvv> yeah, thought that might be the case. i'm thinking of a transitive upstream network issue
2026-01-23 19:49:19 <ikke> It's at least >24h
2026-01-23 19:56:44 <ikke> 157 packages to go for riscv64
2026-01-23 19:59:00 <Saijin_Naib[m]> @achill i dont seem able to view that project to make an Issue
2026-01-23 20:02:25 <ikke> Saijin_Naib[m]: you should if you're logged in
2026-01-23 20:10:03 <jvvv> ikke: i'm wondering if the issue I'm having could be that the gnu server is blocking due to too many requests seen in some time frame. i notice that !96363 seems to be running into same issue
2026-01-23 20:15:12 <jvvv> maybe changing the url base to https://ftpmirror.gnu.org could help?
2026-01-23 20:20:07 <Saijin_Naib[m]> Ah, indeed. I need to login again when accessing that link. Weird!
2026-01-23 20:27:45 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf/-/issues/2
2026-01-23 23:45:25 <Ariadne> achill: o.o;;;;
2026-01-23 23:46:11 <achill> lol?
2026-01-23 23:47:02 <Ariadne> i just pushed that package like 10 minutes ago
2026-01-23 23:47:06 <Ariadne> lol
2026-01-23 23:47:09 <achill> yeah
2026-01-23 23:48:52 <Ariadne> anyway, testing is encouraged.  i've been using it instead of doas for a couple of weeks now
2026-01-23 23:49:07 <Ariadne> the manpage has some examples
2026-01-23 23:49:20 <Ariadne> you can also do the openrc dotted service thing with the init script
2026-01-23 23:49:32 <achill> ill try it tomorrow morning
2026-01-24 04:04:02 <runxiyu> this is more of an SPDX issue than an alpine-specific issue (though, yeah, in context of APKBUILDs)
2026-01-24 04:04:47 <runxiyu> how should i write the license= field for projects that specify a proxy under section 14 of the AGPL?
2026-01-24 04:10:02 <runxiyu> (not about this package specifically, but an example that i use: https://git.runxiyu.org/furweb.git// (note the double-slash)
2026-01-24 07:31:47 <Saijin_Naib[m]> Ariadne is adding the GTK build to Audacious a possibility?
2026-01-24 07:38:07 <ikke> runxiyu: I'm not sure that matters for the SPDX license field, just like we don't record the copyright holder for things like MIT license
2026-01-24 07:38:09 <ikke> licenses
2026-01-24 07:38:11 <ikke> IANAL
2026-01-24 07:43:37 <Saijin_Naib[m]> Is bumping libpeas1 to 1.38 trivial, or does that require rebuilds?
2026-01-24 07:43:46 <Saijin_Naib[m]> That should (finally) fix Rhythmbox being broken
2026-01-24 07:43:58 <Saijin_Naib[m]> It just got tagged a few hours ago
2026-01-24 07:44:56 <ikke> Depends if the soname changed
2026-01-24 07:45:45 <Saijin_Naib[m]> I believe not, just a fix to girepository that apparently broke like last year
2026-01-24 07:46:05 <Saijin_Naib[m]> https://gitlab.gnome.org/GNOME/libpeas/-/issues?show=eyJpaWQiOiI1OCIsImZ1bGxfcGF0aCI6IkdOT01FL2xpYnBlYXMiLCJpZCI6MjE4MTY2fQ%3D%3D
2026-01-24 07:46:11 <Saijin_Naib[m]> Here's the thread discussing it
2026-01-24 07:46:28 <ikke> If you run checkapk after building it, it will tell you
2026-01-24 07:46:36 <ikke> (abump will automatically invoke checkapk)
2026-01-24 07:46:59 <Saijin_Naib[m]> oh, sweet
2026-01-24 07:47:33 <Saijin_Naib[m]> It isn't mirrored on the download.gnome.org page yet, so I'd have to change the source line to go to the gnome gitlab. Okay or nah?
2026-01-24 07:49:41 <Ariadne> I would rather not
2026-01-24 07:49:48 <Ariadne> I want the GTK backend to die entirely
2026-01-24 07:52:26 <Ariadne> saijin_naib[m]: why do you want it
2026-01-24 07:52:46 <Saijin_Naib[m]> Ah, okay, fair enough
2026-01-24 07:53:14 <Saijin_Naib[m]> Basically, I dislike how QT apps integrate or not in my XFCE environment, and I built it locally and it seems to work nicely
2026-01-24 07:53:29 <Saijin_Naib[m]> But I know the QT engine allows for the skins and such, so yeah
2026-01-24 07:53:55 <Ariadne> what?
2026-01-24 07:54:11 <Saijin_Naib[m]> Which part?
2026-01-24 07:54:30 <Saijin_Naib[m]> QT interface is needed for the winamp-like skins, right?
2026-01-24 07:54:55 <Saijin_Naib[m]> I imagine that is a far bigger user want/need than someone just preferring how the GTK interface integrates with the rest of their GTK DE and apps
2026-01-24 07:55:25 <Ariadne> gtk has skins plugin
2026-01-24 07:56:08 <Saijin_Naib[m]> Oh. I did something wrong, then, haha
2026-01-24 07:57:29 <Ariadne> I would be OK with it under the condition that toolkit specific plugins are isolated into subpackages
2026-01-24 07:57:47 <Saijin_Naib[m]> So audacious-gtk, basically?
2026-01-24 07:57:59 <Ariadne> No
2026-01-24 07:58:12 <Ariadne> one set of aports
2026-01-24 07:58:48 <Ariadne> just subpackages for Qt that get installed if Qt is present and same for GTK
2026-01-24 07:59:17 <Saijin_Naib[m]> Oh, like how LibreOffice handles it?
2026-01-24 08:00:01 <Ariadne> same idea I think
2026-01-24 08:01:32 <Saijin_Naib[m]> Okay, that might be beyond me at present, but I'll take a look into it
2026-01-24 08:01:37 <Saijin_Naib[m]> Thanks for considering it
2026-01-24 08:04:31 <Ariadne> also coming soon: kigigami frontend
2026-01-24 08:05:28 <Saijin_Naib[m]> Oh, the adaptive widget set?
2026-01-24 08:05:31 <Saijin_Naib[m]> That will be sweet
2026-01-24 08:05:52 <Ariadne> yes have been porting to android
2026-01-24 08:06:09 <Saijin_Naib[m]> Also, I believe you created Audacious, so kudos to you on how efficient it is with playback. Lowest CPU draw of all the players I've tested thus far, with the exception of maybe pragha
2026-01-24 08:06:32 <Saijin_Naib[m]> It made a huge difference on my n3450 craptop when I was working out of home and without a charger while listening to music
2026-01-24 08:07:02 <Saijin_Naib[m]> So, thanks for what you do, and did? I guess
2026-01-24 08:16:11 <Ariadne> the gtk backend is slightly more efficient
2026-01-24 08:16:41 <Ariadne> or at least was with GTK2.
2026-01-24 08:19:03 <Saijin_Naib[m]> I was using the default build, so QT. It made over an hour difference in battery autonomy vs Lollypop or playing in Tuniac via WINE
2026-01-24 10:42:04 <ikke> riscv64 status: 103 packages remaining, qemu seems to be still failing
2026-01-24 12:12:41 <omni> ikke: looks like the last run acctually succeeded https://build.alpinelinux.org/buildlogs//build-edge-riscv64/community/qemu/qemu-10.2.0-r3.log
2026-01-24 12:12:50 <ikke> ok, cool
2026-01-24 12:13:01 <ikke> But annoying that it's flaky
2026-01-24 12:13:02 <omni> and before that I saw some test fail, not sure if the same test failed every time
2026-01-24 12:13:51 <ikke> tailscale is a test timeout it seems
2026-01-24 12:14:26 <omni> the qemu test I saw fail on riscv64: ▶  120/1037 /sparc64/prom-env/sun4u - ERROR:../tests/qtest/prom-env-test.c:43:check_guest_memory: assertion failed (signature == MAGIC): (0x00000000 == 0xcafec0de) FAIL
2026-01-24 13:35:57 <durrendal> omni: highlight of my week has been all of the "your new aports MR has been merged notifications
2026-01-24 13:36:18 <durrendal> i keep seeing from you. Absolutely crushing it dude
2026-01-24 14:17:29 <elagost> is there a way to use stable repos with abuild-rootbld?
2026-01-24 14:22:13 <quinq> elagost, the version isn't a proberty of abuild, but of the repository
2026-01-24 14:22:22 <quinq> So you have to prepare your repository for this
2026-01-24 14:24:04 <quinq> In Alpine's aport, the releases are managed through git tags
2026-01-24 14:24:29 <quinq> There are development branches also
2026-01-24 14:28:50 <elagost> interesting - I should just use branches then?
2026-01-24 14:34:12 <quinq> It all depends :D
2026-01-24 14:34:22 <quinq> If you want to stick to the last release, use the last tag
2026-01-24 14:34:33 <quinq> If you want to follow the development on a stable branch, use that stable branch
2026-01-24 14:35:17 <quinq> Though I don't really know Alpine specific release model, so judge yourself :D
2026-01-24 14:38:53 <elagost> hm - I found if I modify `.rootbld-repositories` in the repo directory (aports/main/.rootbld-repositories) that works too.
2026-01-24 14:40:24 <quinq> nice
2026-01-24 15:35:47 <ikke> Wil update gitlabn at 16:00 UTC and do some configuration tweaks. It will be briefly unavailable
2026-01-24 16:01:21 <ikke> Gitlab is being upgraded / restarted
2026-01-24 16:15:08 <jvvv> ikke: sorry for stopping that CI job. I restarted it.
2026-01-24 16:15:35 <ikke> No worry, just wanted to let you know that CI jobs are not interrupted by gitlab restarting
2026-01-24 16:17:47 <jvvv> It's good to know. I really appreciate you pointing that out. I'll be less likely to embarass myself over that one in the future.
2026-01-24 18:25:17 <runxiyu> ikke: alr, ty
2026-01-24 23:18:34 <skarnet> Hello! It's been a long time coming, but finally, here's progress: !96428
2026-01-24 23:19:48 <skarnet> next week I'll start porting boot scripts and stuff to s6-rc, and work on a way to support multiple service managers in Alpine
2026-01-24 23:20:33 <skarnet> s6-frontend was a prerequisite to that work, and now it's here at last :)
2026-01-24 23:23:04 <achill> you know that this needs to be a tsc decision first to actually use it
2026-01-24 23:23:05 <achill> and the tsc basically doesn't exist currently
2026-01-24 23:24:56 <skarnet> we can talk about using it when the infrastructure is there for it to be used
2026-01-24 23:25:02 <skarnet> this gives some time for the TSC to exist again
2026-01-24 23:25:27 <skarnet> I'm willing to help with this if it's needed
2026-01-24 23:26:21 <achill> im just saying that usually to save time and unnecessary work, the process is tsc => implementation (this is not ideal because the implementation often never happens, but that is clearly not the issue here)
2026-01-24 23:27:09 <skarnet> oh the work is going to be used, if not in Alpine then somewhere else
2026-01-24 23:27:19 <achill> then sure i guess
2026-01-24 23:28:02 <skarnet> it's just that I like Alpine and it's a really good fit, given it's using OpenRC and the s6-frontend approach is very similar
2026-01-24 23:28:36 <skarnet> and some people (Ariadne and also ncopa) had expressed interest
2026-01-24 23:29:51 <skarnet> but regardless of the matter of init and service management, the fact that "the tsc basically doesn't exist currently" sounds like something we might want to address for the health of Alpine
2026-01-24 23:34:30 <omni> I'm looking forward to using s6
2026-01-24 23:34:56 <skarnet> so am I :D
2026-01-25 02:13:51 <Ariadne> achill: the TSC has to approve alternatives to openrc?  that does not sound right to me
2026-01-25 02:16:14 <Ariadne> there are already other alternatives in alpine, after all
2026-01-25 03:22:21 <Sertonix[m]> As long as it's optional and does not break systems when installed I would conaider it fine without the TSC
2026-01-25 10:20:10 <runxiyu> +1 to Ariadne and Sertonix[m] 
2026-01-25 10:56:12 <achill> Ariadne: i meant the switch over
2026-01-25 10:56:45 <achill> since that is skarnets goal afaik
2026-01-25 11:14:03 <ikke> achill: no, skarnet has always been clear that his goal is to be able to choose 
2026-01-25 11:14:31 <achill> oh i see then i must have misinterpreted things
2026-01-25 11:20:04 <quinq> Lessons were taken from other implementations
2026-01-25 11:20:23 <achill> ?
2026-01-25 11:21:28 <quinq> Be collaborative
2026-01-25 11:21:46 <achill> yeah all implementations do that
2026-01-25 11:24:01 <quinq> We must be living in different perception of reality ^^
2026-01-25 11:46:12 <achill> you're probably speaking of systemd,  but as someone who has collaborated with systemd developers I can say they are very collaborative
2026-01-25 11:46:18 <achill> lol
2026-01-25 11:47:49 <omni> =/
2026-01-25 11:49:11 <omni> I'm sure they're collaborative in getting their way
2026-01-25 11:51:14 <achill> anyway, multiple server managers are allowed to be packaged, but choosing between them what https://gitlab.alpinelinux.org/alpine/tsc/-/issues/78 or https://gitlab.alpinelinux.org/alpine/tsc/-/issues/84 is for
2026-01-25 11:59:33 <quinq> jaja
2026-01-25 13:37:56 <Sertonix[m]> riscv64 builder has finished the community repo :)
2026-01-25 16:03:49 <achill> yaay
2026-01-25 16:12:19 <dne> \o/
2026-01-25 16:56:06 <f_|m> \o/ nice
2026-01-25 18:45:38 <jvoisin> \o/
2026-01-25 18:46:07 <quinq> _o/
2026-01-25 18:46:13 <quinq> \o_
2026-01-25 21:29:02 <user0> \o/
2026-01-26 00:48:10 <unrznbl> can a sub-package be simply some symlinks to files installed by a "parent" package?
2026-01-26 05:46:20 <qaqland> unrznbl: -dev subpackages always do that
2026-01-26 08:59:10 <Saijin_Naib[m]> I fixed the anyita/release-monitoring check for libpeas~1, so the current 1.38 release shows now, which should fix Rhythmbox, and possibly pitvi as well
2026-01-26 08:59:17 <Saijin_Naib[m]> pitivi
2026-01-26 12:54:20 <indy> hi all, what are plans for apk v3 packages when it comes to alpine releases? i noticed, that with alpine 3.22 repos are still in v2 format
2026-01-26 12:56:48 <indy> oops - 3.23 are still v2 format
2026-01-26 12:56:56 <indy> fabled, ^^
2026-01-26 12:57:10 <ikke> It's expected
2026-01-26 12:57:42 <ikke> Changing the format is a larger change that needs to be coordinated
2026-01-26 12:58:00 <indy> so also 3.24 will be v2?
2026-01-26 13:11:19 <Sertonix[m]> Changing abuild is relatively easy. The complex part is to migrate all code which expects .apk files to be parsable as a tar archive
2026-01-26 13:18:33 <PureTryOut> Oh I missed that, v3 is not a "regular" archive anymore? I find it very convenient to just open an .apk with an archiver sometimes
2026-01-26 13:19:55 <achill> or we implement apk v3 capabilities in archivers xd
2026-01-26 13:21:25 <Ermine> "Hey is it alpine apk or android apk"
2026-01-26 13:21:45 <PureTryOut> I mean, if doable yes please lol
2026-01-26 13:39:25 <Sertonix[m]> It surely is doable but I don't think it is simple enough to reimplement for multiple archivers.
2026-01-26 13:40:58 <Sertonix[m]> I don't know the different use cases well enough but I considered creating a tool which converts v3 packages to a json metadata file, signature and a tar archive with the contents.
2026-01-26 13:42:34 <Sertonix[m]> Not sure when I will have time for that though.
2026-01-26 13:46:37 <achill> Ermine: i mean we already have a mime type in shared-mime-info: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/336
2026-01-26 13:47:13 <achill> (that is for v2 afaik)
2026-01-26 14:02:40 <Sertonix[m]> stuff like that will break as well
2026-01-26 14:05:36 <ncopa> FYI i will try make new stable releases tomorrow due to the OpenSSL vulnerability. please avoid merge stuff to stable branches that will not be able to complete today including riscv64
2026-01-26 14:07:04 <abby> which vuln?
2026-01-26 14:20:34 <qaqland> ncopa: could you take a look at !95130, it is ready
2026-01-26 14:28:40 <ncopa> can you please remind me again on Wednesday? it looks like it takes 2hours+ on riscv64
2026-01-26 14:28:52 <ncopa> I need to get new kernels out for release tomorrow
2026-01-26 14:29:28 <ncopa> abby: there was an announcement that there will be a new openssl release tomorrow which fixes something
2026-01-26 14:32:33 <qaqland> i see, thanks
2026-01-26 15:20:09 <ffoss> Could mawk replace /usr/bin/awk when installed? Or maybe a separate mawk-awk package for that?
2026-01-26 15:32:43 <jvoisin> OpenSSL really is a running-gag
2026-01-26 15:40:32 <indy> ikke, Sertonix[m], PureTryOut, achill, Ermine so alpine 3.24/3.25 will be still apk v2 packages? :)
2026-01-26 15:50:39 <unrznbl> qaqland: you say -dev subpackages always do that, but what about other subpackages... I was going to make a -opinionated and maybe an -initfs subpackage for some packages and would expect that the parent package would be a dependency but wasn't sure :)
2026-01-26 15:55:50 <Sertonix[m]> indy: There is no plan yet
2026-01-26 15:56:55 <Sertonix[m]> unrznbl: abuild tries to automatically trace dependencies based on symlinks as long as they come from the same APKBUILD
2026-01-26 15:58:20 <unrznbl> ok! cool Sertonix[m], I will give it a shot! thanks.
2026-01-26 18:21:13 <PureTryOut> Huh, I have packages failing to build because of libva-dev=2.23.0 being pulled in by gst-plugins-bad-dev, but something (not the package itself) pulling in libva-dev=2.22.0...
2026-01-26 18:25:24 <ikke> is libva being upgraded in the same MR?
2026-01-26 21:09:19 <PureTryOut> No I did not touch libva. It did get upgraded in aports recently but that's been a while ago
2026-01-26 21:09:27 <PureTryOut> (recently is today, a while ago is a few hours)
2026-01-26 21:42:51 <ncopa> I think I may have upgraded libva today
2026-01-26 21:43:46 <skarnet> "oops, I accidentally upgraded libva" :D
2026-01-26 21:46:29 <ncopa> I suppose this is the fix? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96511
2026-01-26 21:47:45 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96486
2026-01-26 23:24:13 <kpcyrd> > This job is stuck because of one of the following problems. There are no active runners online, no runners for the protected branch , or no runners that match all of the job's tags: docker-alpine ci-build x86_64 
2026-01-26 23:24:34 <kpcyrd> is this a known problem? I have a merge request stuck since yesterday because x86 and x86_64 times out
2026-01-26 23:33:05 <ncopa> kpcyrd: which MR?
2026-01-26 23:33:42 <kpcyrd> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/94886/pipelines
2026-01-26 23:56:47 <skarnet> kpcyrd, ncopa: oof, yes, I'm also getting clogged pipelines on the x86_64 builder
2026-01-26 23:56:55 <skarnet> sounds like something is overloading it
2026-01-27 00:03:56 <ncopa> not sure how this works, but there appears to be some runners idle
2026-01-27 00:07:53 <OlalaH> hi everyone! :D just wanna share that https://bluetorrents.com is open for registration...new releases and old releases
2026-01-27 00:15:40 <jvvv> meh
2026-01-27 00:23:47 <qaqland> spam?
2026-01-27 00:44:54 <Habbie> spam
2026-01-27 14:04:36 <eletrotupi> this build for my MR is failing due to cargo incompat with longaaarch64? I dunno if that's common or there's a specific fix that needs to be applied that I'm unaware of... https://gitlab.alpinelinux.org/eletrotupi/aports/-/jobs/2186683
2026-01-27 14:07:04 <qaqland> bump linux-raw-sys?
2026-01-27 14:10:05 <user0> hi, any idea why the riscv64 ci failed here? https://gitlab.alpinelinux.org/user0-07161/aports/-/jobs/2188456
2026-01-27 14:10:38 <ncopa> new openssl release is out
2026-01-27 14:10:41 <eletrotupi> sure, but what is the current state of rust on alpine? it should build for all platforms?
2026-01-27 14:10:57 <Biswa96[m]> user0: "took longer than 1h0m0s seconds"
2026-01-27 14:10:57 <ikke> user0: Job failed: execution took longer than 1h0m0s seconds
2026-01-27 14:11:06 <user0> ahh
2026-01-27 14:11:16 <user0> how could i not notice
2026-01-27 14:12:06 <user0> well, should i just disable riscv64 then?
2026-01-27 14:13:13 <ncopa> anyone working on openssl upgrade?
2026-01-27 14:13:42 <ikke> user0: you can increase the timeout on your project
2026-01-27 14:14:18 <qaqland> i have set it to 24 hour ;)
2026-01-27 14:14:43 <user0> ahhh
2026-01-27 14:15:22 <qaqland> eletrotupi: reference this comment https://github.com/sunfishcode/linux-raw-sys/issues/34#issuecomment-1608873853
2026-01-27 14:15:59 <eletrotupi> ah ok
2026-01-27 14:16:04 <eletrotupi> i'll send a patch upstream then
2026-01-27 14:19:20 <dne> ncopa: no, haven't seen the (official) announcement yet ;)
2026-01-27 16:17:51 <ncopa> The OpenSSL  release is out
2026-01-27 16:21:22 <achill> are you upgrading it?
2026-01-27 16:37:17 <ncopa> I started to look at it bu have been on the move
2026-01-27 16:37:31 <achill> pushed the upgrade to edge & 3.23
2026-01-27 16:37:33 <ncopa> the auxv.patch needs to be rebased
2026-01-27 16:37:39 <ncopa> thanks!
2026-01-27 16:37:51 <achill> will test on a few systems and backport to the other stable versions aswell
2026-01-27 16:38:05 <ncopa> thank you very much
2026-01-27 16:38:15 <ncopa> im babysitting the build-3-22-riscv64 machine
2026-01-27 16:38:34 <ncopa> it is very unstable and is unable to build nodejs
2026-01-27 16:39:06 <f_|m> :\
2026-01-27 16:40:46 <f_|m> What riscv64 board is it again?
2026-01-27 16:41:02 <ikke> milk-v pioneer
2026-01-27 16:42:10 <f_|m> 64 cores.. and it's slow.. interesting
2026-01-27 16:42:17 <achill> 64 very very slow cores
2026-01-27 16:42:33 <ikke> And not everything runs in parallel
2026-01-27 16:42:44 <f_|m> very
2026-01-27 16:43:38 <f_|m> I heard risc-v these days is about as fast as an RPi3
2026-01-27 16:52:52 <ncopa> the milk-v pioneer is okish, except that one of them are very unreliable
2026-01-27 16:52:55 <ncopa> i dont know why
2026-01-27 17:05:35 <user0> another question about the riscv64 ci check, why is it so slow compared to others?
2026-01-27 17:06:12 <craftyguy[m]> is there any "fast" riscv64 hardware out there?
2026-01-27 17:11:55 <f_> user0: because the hardware is slow
2026-01-27 17:12:57 <user0> ah
2026-01-27 17:13:23 <ncopa> as far I know the currently available fastest hardware out there is the milk-v pioneer with 64 cores and 128GB ram
2026-01-27 17:14:00 <ikke> What is scaleway using?
2026-01-27 17:14:31 <ncopa> head something. I think it's equivalent to leeche pi or what it was called. but it has 16G ram
2026-01-27 17:14:54 <ncopa> it is not the faster ones currently available
2026-01-27 17:15:03 <ncopa> from what I understand, currently on second place is the hifive premiere p550
2026-01-27 17:15:07 <ncopa> but it only has 4 cores
2026-01-27 17:15:51 <ncopa> what is interesting is that pioneer is only 4x faster than p550 on parallel workloads using all 64 cores
2026-01-27 17:17:05 <ncopa> i am very curious about the titan, which should be faster than p550 and have 8 cores.
2026-01-27 17:18:07 <ncopa> it may be generally faster even if it is half the speed of pioneer on parallel workloads, because not everything is parallelized
2026-01-27 17:18:49 <ncopa> and if it is more stable that pioneer we could have a possible replacement
2026-01-27 17:19:31 <ncopa> speaking of Scaleway runners. I dont remember if we allow two build jobs on each
2026-01-27 17:19:42 <ncopa> maybe we only should allow a single job on each node
2026-01-27 17:19:43 <ikke> Me neither, I was not involved
2026-01-27 17:19:54 <ncopa> I think I used the defaults IIRC
2026-01-27 17:20:11 <ikke> Probably 2 jobs then pur runner
2026-01-27 17:20:32 <ncopa> I think I may have added your keys there ikke
2026-01-27 17:20:45 <ncopa> the IPs should be documented in netbox
2026-01-27 17:21:02 <ikke> Ok, I'll take a look in a bit
2026-01-27 17:21:24 <ncopa> but I have also been thinking of setting up the p550 as a runner
2026-01-27 17:21:41 <ncopa> wanted to have a recent kernel first but have not had time to work on it
2026-01-27 17:36:40 <jvvv> Anitya flagged mawk. I think that it got flagged because our version semantics are different than what Anitya expects. Does anyone know if there is a way to get Anitya to not flag it?
2026-01-27 17:37:41 <jvvv> I'm logged in on Anitya, but the only thing I see to adjust is the regex and changing that concerns me that I might mess it up for other distros
2026-01-27 17:38:20 <ikke> ptrc knows maybe
2026-01-27 17:40:02 <jvvv> ok, thanks. maybe I will luck out and ptrc will time to chime in eventually
2026-01-27 17:41:15 <achill> maybe we should allow the apkbuild checker to be manually adapted for exceptions like this. this question is asked a lot and we dont really have a answer for that
2026-01-27 17:42:43 <achill> ncopa: can you reopen https://gitlab.alpinelinux.org/alpine/council/-/issues/6?
2026-01-27 17:43:55 <achill> thanks!
2026-01-27 17:48:41 <ncopa> i dont think trademark will bring much value at this point
2026-01-27 17:49:07 <ikke> It costs a lot, and without enforcement, looses its value
2026-01-27 17:49:41 <ikke> and iirc, we cannot selectively enforce it
2026-01-27 17:51:07 <ncopa> that's how it was explained to me by a lawyer. and exactly what would we trademark? "Linux" is already trademarked.
2026-01-27 17:51:18 <ikke> ncopa: seeing 8 running riscv64 jobs atm
2026-01-27 17:51:19 <ncopa> so we cannot trademark "Alpine Linux"
2026-01-27 17:51:44 <achill> afaik if we get approval by the linux foundation or something that could work
2026-01-27 17:51:55 <achill> as an example, arch linux also trademarked arch linux
2026-01-27 17:51:56 <achill> https://terms.archlinux.org/docs/trademark-policy/
2026-01-27 17:53:44 <achill> "The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis."
2026-01-27 17:54:48 <achill> okay so apprently here is information about the sublicense: https://www.linuxfoundation.org/legal/the-linux-mark
2026-01-27 17:54:58 <ncopa> what value does it bring?
2026-01-27 17:55:57 <achill> enforcement of issues like https://gitlab.alpinelinux.org/alpine/council/-/issues/699
2026-01-27 17:57:21 <ncopa> i dont think it will help. I mean it would have symbolic value, but not much more than that.
2026-01-27 17:57:48 <ncopa> we could come with the trademark and ask them to stop or remove Alpine Linux, but if they refuse? what do we do?
2026-01-27 17:59:23 <ncopa> according to lawyers I spoken to in the past, we would not win in a court. to actually have any value we would need to be very strict and enforce it hard everywhere
2026-01-27 17:59:28 <achill> platforms like telegram or discord might take us more seriously
2026-01-27 18:00:23 <achill> but of course i have no legal background, and if you talked to them youre probably more aware of it
2026-01-27 18:01:30 <ncopa> as ikke said, it costs a lot, and requires strict enforcement to have any real value.
2026-01-27 18:01:46 <ncopa> so I'm skeptic to it
2026-01-27 18:01:54 <ncopa> but im not a lawyer so I dont know really
2026-01-27 18:11:27 <ikke> We could ask how Arch Linux is handling it
2026-01-27 18:12:15 <achill> i think i can talk to them at fosdem
2026-01-27 18:17:24 <ncopa> sounds good
2026-01-27 18:17:32 <ncopa> too bad I cannot join fosdem
2026-01-27 18:19:41 <achill> yeah would be cool to meet you in person :)
2026-01-27 18:24:57 <adhawkins> Odd CI failure on my latest upload: https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/2194365
2026-01-27 18:25:05 <adhawkins> Can I safely ignore it? It passed on all the builds except this one.
2026-01-27 18:26:53 <ikke> adhawkins: maybe related? https://github.com/matplotlib/matplotlib/issues/23326
2026-01-27 18:32:27 <ncopa> achill: thank you very much for bumping openssl
2026-01-27 18:32:47 <ncopa> I think we are ready to tag release. only need get build-3-22-riscv64 solved
2026-01-27 18:32:57 <achill> sure youre welcome
2026-01-27 18:33:25 <ncopa> I think I know why it never finishes, even if I continue the nodejs build on failure
2026-01-27 18:33:32 <achill> but i think in future it would be good to open issues or so for upcoming cves, like i had the whole day free and only by accident saw youre message
2026-01-27 18:33:39 <achill> i couldve upgraded it much sooner :)
2026-01-27 18:33:51 <ncopa> ok
2026-01-27 18:34:01 <ikke> Wasn't the release only later today?
2026-01-27 18:34:14 <ncopa> it happened earlier today
2026-01-27 18:34:22 <ncopa> the openssl releases
2026-01-27 18:34:25 <ikke> ncopa: your early, or our early?
2026-01-27 18:35:20 <ncopa> https://github.com/openssl/openssl/releases says 4 hours ago
2026-01-27 18:35:48 <achill> ahh
2026-01-27 18:36:13 <ncopa> so I think we did good. very good
2026-01-27 18:36:19 <ncopa> the fix is out
2026-01-27 18:36:36 <ncopa> now we only need to tag new alpine releases so we get the docker image updated
2026-01-27 18:37:03 <ncopa> but build-3-22-riscv64 needs to complete nodejs build and then do the kernel updates I pushed yesterday
2026-01-27 18:37:18 <f_> Oof.
2026-01-27 18:37:26 <ncopa> nodejs has been problematic
2026-01-27 18:37:32 <f_> you can't skip it?
2026-01-27 18:37:42 <ncopa> not really
2026-01-27 18:38:14 <ncopa> well, everything is possible, but would be good to make the build pass
2026-01-27 18:38:30 <ncopa> which what I have been trying to achieve the last day
2026-01-27 18:38:34 <f_> I don't see any nodejs in https://build.alpinelinux.org/
2026-01-27 18:38:48 <ncopa> i have disabled the builder, because it will start over from scratch
2026-01-27 18:38:59 <f_> ah
2026-01-27 18:39:05 <ncopa> and machine is unreliable to compiler fails randomly
2026-01-27 18:39:16 <ncopa> so I try to make it continue where it failed
2026-01-27 18:39:33 <ikke> tps://paste.pictures/h9OA_49gvI.png
2026-01-27 18:39:37 <ncopa> but it builds in two passes, one with --shared something 
2026-01-27 18:39:41 <ikke> https://paste.pictures/h9OA_49gvI.png
2026-01-27 18:40:05 <f_> Doesn't show that for me
2026-01-27 18:41:35 <ikke> Yeah, doesn't show on refresh
2026-01-27 18:41:43 <f_> right I see the log..
2026-01-27 18:41:47 <ncopa> so if the second pass fails, it will rebuild the first pass, (or at least 1900 files of it)
2026-01-27 18:42:04 <ncopa> so I need both passes succeed in one go. without failure
2026-01-27 18:42:11 <user0> hi, is using `case` to set vars in APKBUILDs like here (https://gitlab.alpinelinux.org/alpine/aports/-/blob/da90a5ef967058ebdf926e360f52ccdcf958e912/testing/p2pool/APKBUILD) allowed? it was the best i could think of, to not have multiple `case`s in the entire APKBUILD
2026-01-27 18:42:35 <f_> yes I think so
2026-01-27 18:42:59 <user0> great, thanks
2026-01-27 18:43:10 <f_> probably misremembering, but I think there's a way to apply patches on an arch basis?
2026-01-27 18:43:16 <ikke> user0: This would break abump, though
2026-01-27 18:43:22 <ikke> or abuild checksum
2026-01-27 18:43:29 <user0> yes, i know
2026-01-27 18:43:49 <ikke> The common approach is to include the patch with something like a .noauto extension, and then manually applying the patch per arch
2026-01-27 18:43:53 <ncopa> i was to say that it would fail to build on some arches due to checksums, but I see they hacked around it
2026-01-27 18:44:19 <f_> Also, `arch` should be arch="all !arches !that !dont !build" preferably
2026-01-27 18:44:32 <f_> but that's just personal preference
2026-01-27 18:44:47 <user0> well, the issue is, if a new arch is added to alpine it's unlikely that p2pool will support it
2026-01-27 18:45:42 <user0> it's monero mining software, new arch support will need to be added to the randomx algo codebase
2026-01-27 18:45:47 <f_> New arches aren't added to alpine very often I think so it's reasonable Imo
2026-01-27 18:45:55 <user0> hmm
2026-01-27 18:46:07 <f_> But I guess if you prefer that I'm not going to stop you
2026-01-27 18:46:18 <f_> Makes sense
2026-01-27 18:46:32 <user0> well i'd obviously change it if it's a req for my mr to be merged
2026-01-27 18:46:44 <ikke> It's not a requirement
2026-01-27 18:46:45 <f_> I don't think it is a requirement
2026-01-27 18:47:14 <ikke> If an application only supports specific arches, it makes more sense to list those arches
2026-01-27 18:47:16 <f_> Like I said, just personal preference
2026-01-27 18:47:27 <f_> yeah pretty much
2026-01-27 18:48:41 <ncopa> looking at those patches, I would think it makes sense to drop support for the 32 bit arches and drop  the patches
2026-01-27 18:50:21 <user0> well, 32 bit support is important to me personally
2026-01-27 18:50:52 <ncopa> i guess upstream does not support 32bit?
2026-01-27 18:51:00 <user0> no, it doesn't
2026-01-27 18:51:50 <ncopa> I suppose the bus error on arm* is due to memory alignment
2026-01-27 18:51:56 <user0> the device i run my p2pool node on is 32 bit, and it's the only device i can run it on 24/7
2026-01-27 18:52:12 <user0> ncopa: yeah, the robin_hood_hashing code is quite a mess and a pain to debug
2026-01-27 18:52:45 <ncopa> i had a mom alignment issues on 32 bit arm recently
2026-01-27 18:53:02 <ncopa> i dont remember which package
2026-01-27 18:53:20 <ncopa> dash
2026-01-27 18:53:45 <ncopa> I used memcpy to solve it
2026-01-27 18:54:09 <user0> mmh
2026-01-27 18:55:23 <user0> yeah, i won't be able to debug this in the next two weeks probably, i'm not at home and therefore don't have access to my laptop
2026-01-27 18:55:31 <ncopa> \o/ nodejs completed!
2026-01-27 18:55:38 <ikke> cool
2026-01-27 18:55:47 <f_> \o\ /o/   !!
2026-01-27 19:01:36 <ikke> now bind fails
2026-01-27 19:01:41 <ikke> collect2: fatal error: ld terminated with signal 15 [Terminated]
2026-01-27 19:01:59 <ncopa> I killed it
2026-01-27 19:02:07 <ncopa> it looked like it was deadlocked
2026-01-27 19:02:08 <ikke> ah ok :)
2026-01-27 19:02:16 <ncopa> which was kinda lucky
2026-01-27 19:02:17 <ikke> That explains signal 15
2026-01-27 19:02:33 <ncopa> I though I had sopped the build so it was unexpected that bind was building
2026-01-27 19:03:19 <ncopa> if it would have succeeded it would delete the nodejs build and start over, so it was kinda lucky that it deadlocked :(
2026-01-27 19:03:22 <ncopa> :)
2026-01-27 19:03:58 <ikke> heh
2026-01-27 19:04:39 <ncopa> but we need to do something about that builder. it is kinda useless as is
2026-01-27 19:04:54 <ikke> bld2?
2026-01-27 19:04:56 <ncopa> yeah
2026-01-27 19:05:17 <ikke> wasn't it bld1 which was the one with issues?
2026-01-27 19:05:55 <ncopa> right now bld1 appears to be ok, but bld2 is struggling 
2026-01-27 19:06:02 <ncopa> compiler error or deadlocks
2026-01-27 19:06:07 <ikke> because it has all the load I suppose
2026-01-27 19:06:16 <ncopa> sorry
2026-01-27 19:06:21 <ncopa> im mistaken
2026-01-27 19:06:25 <ncopa> its bld1 indeed
2026-01-27 19:11:16 <ncopa> build-3-20-riscv64 appears to be deadlocked
2026-01-27 19:11:22 <ncopa> im gonna try fix it
2026-01-27 19:59:10 <ncopa> now its only build-3-22-riscv64 we are waiting for to be able to do release
2026-01-27 19:59:34 <ikke> building the kernel now
2026-01-27 20:00:38 <ncopa> yup
2026-01-27 20:00:43 <ncopa> does this look good? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/blob/ba6ef9ffc848f8fa595f61916e72d4b504540282/posts/Alpine-3.20.9-3.21.6-3.22.3-3.23.3-released.md
2026-01-27 20:01:47 <ikke> I was already checking it, but waiting for the tags to appear
2026-01-27 20:13:16 <user0> ncopa: is it a requirement for me to remove the patches and disable 32 bit for the mr to get merged?
2026-01-27 20:13:32 <user0> or is it fine for me to keep it as it is for now
2026-01-27 20:15:09 <ncopa> dunno. imho, it would be ok to merge, as long as I dont need to maintain it.
2026-01-27 20:15:29 <ncopa> would be better to have patches that can be applied equally on all arches
2026-01-27 20:16:11 <ikke> Or at the minimum, static in sources, and then applied selectively
2026-01-27 20:16:40 <ncopa> right now im kinda busy with the release for openssl fixes
2026-01-27 20:17:56 <ncopa> the linux-its build deadlocked apparently :/
2026-01-27 20:18:25 <user0> yeah i'll apply them selectively then, like ikke said
2026-01-27 20:18:55 <user0> i'd be maintaining the patches and the package so that'd be no issue
2026-01-27 20:36:22 <ikke> ncopa: I've added match rules for all the openssl vulnerabilities
2026-01-27 20:36:26 <ikke> on security.a.o
2026-01-27 20:38:01 <Ariadne> do yourselves a favor and explicitly put polkit-elogind in /etc/apk/world
2026-01-27 20:38:26 <Ariadne> i just spent 2 hours banging my head against the wall in the middle of an airport debugging my laptop :D
2026-01-27 20:38:33 <ikke> ouch
2026-01-27 20:39:05 <Ariadne> 
ACTION thinks the polkit systemd(tm) variation should explicitly depends=!elogind

2026-01-27 20:48:51 <adhawkins> ikke: That does sound like the same thing. Odd that I've never run into it before, *and* all the other pipelines run just fine...
2026-01-27 20:51:33 <adhawkins> Just tried re-running it, getting a slightly different error now: Could not save font_manager cache Lock error: Matplotlib failed to acquire the following lock file: /home/buildozer/.cache/matplotlib/fontlist-v390.json.matplotlib-lock
2026-01-27 20:52:06 <ikke> Something flaky going on
2026-01-27 20:54:57 <ikke> ncopa: https://www.openwall.com/lists/oss-security/2026/01/27/7
2026-01-27 20:55:49 <ikke> Oh, I see they are already included
2026-01-27 20:58:11 <adhawkins> ikke: https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/2194535
2026-01-27 20:58:17 <adhawkins> I'm of a mind just to ignore it seeing as it only affects that one build.
2026-01-27 21:02:21 <ncopa> I think we have a problem 
2026-01-27 21:02:27 <ncopa> 1 / 298 (0%)
2026-01-27 21:02:44 <ncopa> I dont know what happened 
2026-01-27 21:04:07 <ncopa> But if we are gonna build 300 packages on this machine it’s gonna take weeks before we can get the release out
2026-01-27 21:07:36 <ikke> oof
2026-01-27 21:08:03 <ncopa> I think I will have to disable community on build 3-22 riscv64
2026-01-27 21:08:18 <ncopa> At least for the release
2026-01-27 21:08:34 <ncopa> But I’m currently on the move
2026-01-27 21:08:50 <ncopa> Need to find a place where I can work
2026-01-27 21:09:48 <ikke> I can help disabling community
2026-01-27 21:11:36 <ikke> ncopa: done
2026-01-27 21:17:37 <ncopa> thanks
2026-01-27 21:18:50 <ncopa> ok im tagging releases
2026-01-27 21:28:43 <ncopa> releases are tagged now
2026-01-27 21:28:55 <ikke> approved the release post MR
2026-01-27 21:28:58 <adhawkins> ikke ncopa I wonder if my build issue on riscv64 is related to what you're seeing? Is it so busy the matplotlib initialisation process is taking longer than it normally would?
2026-01-27 21:29:30 <ikke> adhawkins: It's running on nld-bld-2, which the unaffected host
2026-01-27 21:30:17 <adhawkins> Ok, scratch that idea then! Is this build target relatively new? Don't think there's been an update to this package for a while, so possibly previous builds didn't build for this target?
2026-01-27 21:30:54 <adhawkins> Last update was May 2025.
2026-01-27 21:30:55 <ikke> adhawkins: No, not that new
2026-01-27 21:31:21 <adhawkins> This package was enabled on riscv64 in December 2024 it seems.
2026-01-27 21:48:33 <WhyNotHugo> package gajim has a comment that builders cannot fetch upstream tarballs, and use a mirror in dev.alpinelinux.org. Can somebody confirm if the builders in the new infrastructure are also blocked?
2026-01-27 21:53:00 <ikke> WhyNotHugo: what site?
2026-01-27 21:53:17 <ikke> WhyNotHugo: ftr, the builders have not moved, only CI
2026-01-27 21:53:43 <WhyNotHugo> https://gitlab.alpinelinu.org/alpine/aports/-/blob/master/community/gajim/APKBUILD#L41-42
2026-01-27 21:53:54 <WhyNotHugo> Do the builders have known IPs which we can ask upstream to unblock?
2026-01-27 21:55:39 <ikke> Seems to work now
2026-01-27 22:02:37 <ncopa> whee! I was able to tag all releases, including edge snapshot
2026-01-27 22:02:52 <achill> great
2026-01-27 22:02:57 <ncopa> im gonna continue with the docker images in a bit
2026-01-27 22:03:08 <ncopa> ikke: I think we can remove the announcement now
2026-01-27 22:03:10 <ncopa> thanks!
2026-01-27 22:03:29 <ncopa> in gitlab
2026-01-27 22:03:40 <ikke> done
2026-01-27 22:09:25 <ncopa> Thank you!
2026-01-27 22:16:25 <WhyNotHugo> ikke: great, I'll send an MR with package updates then
2026-01-27 22:22:13 <skarnet> grats on the releases!
2026-01-27 23:04:27 <ncopa> thanks!
2026-01-28 00:24:01 <Habbie> grats!
2026-01-28 13:43:17 <jahway603[m]> Can I please have !96627 and !96628 merged?
2026-01-28 13:44:01 <fabricionaweb> bot is 🛌
2026-01-28 13:48:45 <f_> \o/
2026-01-28 13:48:49 <f_> :(
2026-01-28 13:50:55 <fabricionaweb> jahway603[m], these MR are very new, I would wait a bit longer before "ask to be merged" lol
2026-01-28 16:19:17 <kchr> \:D/
2026-01-28 19:30:29 <Antiz1> ncopa: I guess I forgot to bump pkgrel for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96543 😕 
2026-01-28 19:31:58 <Antiz1> Habit from the Arch Linux side where we specifically ask people *not* to bump pkgrel. Sorry 😅 Should I send another MR for this?
2026-01-28 19:32:19 <achill> fixed that already in alpine hehe https://gitlab.alpinelinux.org/alpine/aports/-/commit/5b2ac7dd1021903c1b1c257f13c905bd9151f846
2026-01-28 19:32:39 <Antiz1> achill: Thanks <3
2026-01-28 19:32:40 <achill> but yeah i wanted to look at your MR but it kept pushing down in my email client lol
2026-01-28 19:33:04 <Antiz1> No problem, I'm about to send you another one actually :P
2026-01-28 19:33:12 <achill> noice
2026-01-28 19:34:04 <Antiz1> (Also, keeping in mind that I *should* bump pkgrel for package changes MRs in Alpine 👼)
2026-01-28 19:35:01 <Antiz1> achill: There :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/96651
2026-01-28 19:35:27 <achill> awesome, will merge once CI passed :)
2026-01-28 19:35:39 <Antiz1> \o/ Thanks!
2026-01-28 19:46:58 <ikke> Antiz1: technically, when adding a new subpackage, bumping pkgrel is not even required, but it works better with our CDN to force a new package name
2026-01-28 20:22:53 <achill> ikke: just generally forcing a pkgrel bump for functional changes has other benefits, like -dbg containing also debuginfos of the subpackage
2026-01-28 20:23:10 <achill> or if files are being split away, this anyway is a must
2026-01-28 20:24:15 <ikke> achill: the entire package is rebuilt when adding a new subpkg
2026-01-28 20:25:00 <ikke> (abuild cannot build just a subpkg)
2026-01-28 20:25:20 <achill> right, i was thinking that the rsync just pushed filename changes but that makes no sense
2026-01-28 20:25:52 <ikke> correct, it updates existing files as well
2026-01-28 20:25:57 <achill> yeah im in general more the fan of a single $pkgname-$pkgver-r$pkgrel.apk combo is identical to a single build and a single checksum
2026-01-28 20:25:58 <ikke> just the CDN that caches based on filename
2026-01-28 20:26:12 <ikke> nod
2026-01-28 20:52:56 <Sertonix[m]> v3 indexes would allow --pkgname-spec ${hash}.apk but there are probably some downsides woth that
2026-01-28 21:06:24 <Antiz1> ikke: Right, makes sense. Thanks :)
2026-01-28 21:07:11 <user0> any idea whats causing this weird error? https://gitlab.alpinelinux.org/user0-07161/aports/-/jobs/2196102
2026-01-28 21:32:05 <ikke> Irm: can't remove '/builds/user0-07161/aports/testing/p2pool/src/p2pool/external/src/grpc/third_party/googleapis/google/appengine/v1/version.proto': No such file or directory
2026-01-28 21:33:34 <ikke> Not sure what's causing that
2026-01-28 21:47:14 <user0> ikke: just re-ran the job and it passed now /shrug
2026-01-28 21:54:20 <jvvv> my gut reaction is that https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/2195931#L128 is unrelated to user0's CI issue, but similarly when I reran the CI job, it passed...
2026-01-28 21:56:01 <jvvv> I tried to repreduce the segfault in a qemu-user chroot, but the command succeeded there and so I restart the CI job
2026-01-28 21:56:01 <user0> yes riscv64 seems a bit unstable recently
2026-01-28 23:28:27 <jvoisin> lanodan: how would you feel about deleting py3-pygelbooru?
2026-01-28 23:29:34 <jvoisin> (it's depending on py3-furl->py3-orderedmultidict->py3-six, and I'm working on getting rid of py3-six in https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17822)
2026-01-28 23:30:07 <jvoisin> also, the API of gelbooru looks simple enough that an asynchronous library for it seems a tad completely overkill (https://gelbooru.com/index.php?page=wiki&s=view&id=18780)
2026-01-29 07:19:46 <lanodan> Would rather not have it deleted but I guess I can look (likely not this weekend, will be at fosdem) at patching py3-pygelbooru to get rid of furl (since furl itself depends on six).
2026-01-29 07:38:06 <Saijin_Naib[m]> If anyone is free, can they look at !96672?
2026-01-29 07:38:21 <Saijin_Naib[m]> The libpeas bump fixes Rhythmbox and Pitivi, which have been broken for like a year
2026-01-29 07:39:48 <PureTryOut> bl4ckb0ne: could you take a look at !96673?
2026-01-29 11:56:50 <quinq> Hummm, is that expected that openal depends on qt5?!
2026-01-29 11:57:27 <quinq> and qt5-wayland/x11, what does that has to do with sound?
2026-01-29 13:17:13 <fabricionaweb> hi, someone wants to review this? !96626
2026-01-29 14:36:34 <bl4ckb0ne> what's the correct permission for a bin installed in /usr/bin, 755 ?
2026-01-29 14:39:31 <quinq> y
2026-01-29 14:55:54 <omni> or 0755?
2026-01-29 15:15:37 <quinq> You just repeated it
2026-01-29 15:17:58 <user0> arent 755 and 0755 equal?
2026-01-29 15:18:42 <quinq> They are for files
2026-01-29 19:06:05 <jvvv> I know I've asked this before, but I think I get this wrong more often than not ... moving package from testing to community requires rel bump?
2026-01-29 19:14:42 <achill> not if there are no other changes
2026-01-29 19:16:35 <jvvv> thanks! should I do a MR for COMMITSTYLE.md so that the description of a move is explicit about it?
2026-01-29 19:19:54 <achill> i guess it doesnt hurt, but im trying to rewrite the docs about that in whole anyway, but its not going to be finished tomorrow, so yeah i think that would be usefull?
2026-01-29 19:21:24 <jvvv> would you prefer I wait for you to finish your work on that first? I don't mind waiting.
2026-01-29 19:21:58 <achill> oh no, its more of a long term project
2026-01-29 19:22:49 <jvvv> ok, thanks for your input. I will work on that today.
2026-01-29 20:26:38 <omni> quinq: I guess I just like being explicit about it
2026-01-29 20:33:57 <user0> are there any blockers for !96377 to be merged?
2026-01-29 21:57:01 <jvoisin> ayakael: can you please bump community/py3-pyrad to the latest available release?
2026-01-30 00:01:59 <omni> !96702
2026-01-30 00:07:31 <jvoisin> <3
2026-01-30 12:43:43 <ikke> rebooting deu1-dev1, which means algitbot and some other services will be temporarily be unavailable
2026-01-30 12:50:36 <ikke> Ok, everything should be back
2026-01-30 15:48:44 <quinq> o/
2026-01-30 18:14:43 <ikke> \\o
2026-01-31 19:34:20 <borgserk> Hello, I am checking aports and wondering whether tmpfiles.d and sysusers.d were considered for the base system. They seem really useful, as they point to which file was responsible for creating a user and group for a package. I am seeing adduser and addgroup in lighttpd.pre-install file. I beleive introducing sysusers.d in base system and modifying APKBUILD scripts would improve stability, as sysusers.d can do rollbacks of user acc
2026-01-31 19:34:20 <borgserk> hts?
2026-01-31 19:35:18 <pj> Are you proposing to use sd-{sysusers,tmpfiles} or reimplementing their behaviour?
2026-01-31 19:36:16 <borgserk> Yes using sd-tools
2026-01-31 19:37:09 <pj> Alpine doesn't have systemd and some people are very against (including|using) it
2026-01-31 19:39:25 <achill> borkserk: there are ideas floating around to use it but it's difficult and needs further discussions until we can open a TSC issue with a proposal and a way for a implementation
2026-01-31 19:40:09 <achill> but it certainly crossed my (and other) mind
2026-01-31 19:40:54 <borgserk> I am not advocating for systemd as a whole but this small sliver of it. sd-tools README says it cleans up the original code quite a bit. I am talking specifically about https://github.com/chimera-linux/sd-tools implementation from chimera linux project
2026-01-31 19:41:46 <borgserk> achill: Thats cool! Can anyone open a issue in TSC?
2026-01-31 19:41:59 <achill> (the idea of mine is also not specific to sd-tools/systemd, I mainly want declarative system users and maybeeeee runtime directories, and would use whatever suits us best)
2026-01-31 19:43:12 <achill> borgserk: yeah as I said I would still need to think a bit further until I want to open a TSC issue to invite more discussion; stuff like what if the user changes a Service-User in the confd override and doesn't want the sysusers user
2026-01-31 19:44:26 <achill> and as pj said, opening a TSC issue can invite more controversies and distract from the actual problem we're trying to solve
2026-01-31 19:44:42 <achill> so Ill try to do it carefully:)
2026-01-31 19:45:16 <borgserk> nice great
2026-01-31 19:45:21 <pj> just talking on irc is controversial :> 
2026-01-31 19:45:54 <borgserk> anything is controversial these days :(
2026-01-31 19:46:22 <Sertonix[m]> Somewhere I have already mentioned the issues sd-tools causes for bootstrapping. So I think there was an open issue for this somewhere already
2026-01-31 19:47:59 <achill> I know sertonix and I have that in my mind
2026-01-31 19:51:50 <borgserk> achill: is there any problem with the current sysusers.d and tmpfiles.d format to think of a different format. I read them both last night, and except for the overrides(useful but too much redirection?) and multiple files, the config itself looks quite minimal. And having them compatible will surely help my PKGBUILD2APKBUILD(yet to hash out) thing easy to make :)
2026-01-31 19:58:10 <achill> borkserk: I don't see a problem with the format, but the bigger problem is, well, these user-changable strings
2026-01-31 20:00:44 <borgserk> achill: ha! yes I did not think from that angle
2026-01-31 20:02:17 <borgserk> achill: but in other ways it can be seen similar to the /etc/apk/world file, where the system eventually gets to the state of the file?
2026-01-31 20:10:26 <borgserk> achill: maybe we can disable the overrides of user and have one and only /etc/sysusers.d/ with 444 and root:root?
2026-01-31 23:27:39 <WhyNotHugo> !96053 looks okay to merge