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